Филипп Зыков aka philzy делится с нашими читателями опытом:
По целому ряду причин, а точнее из-за особенностей организации хранения данных пользователей потребовалось поэкпериментировать с массовым подключением RDM в MSCS кластере . Чтобы прекратить все вопросы почему так – отвечаю. У нас есть такое понятие как диск подразделения («исторически так сложилось»), оно реализуется через подключение сетевых дисков на рабочих станциях, которые смотрят в DFS. Для поддержания порядка в расходе дискового пространства первое время пользовались квотированием, но пользователи скандалили, так как свободное место показывалось некорректно. Поэтому соорудили систему с диким количеством LUN .
Всего было 46 LUN на EMC CX3-40F выбрано для эксперимента по их подключению.
При подключении 31 LUN начиналась череда дивных «глюков» связанных с вылетами по таймауту при запуске такой VM, проблемы с невозможностью сохранить конфигурацию VM.
Чтение документации от Vmware ничего не проясняло, кроме одного маленького упоминания о том, что кворумный диск лучше подключать на SCSI-адрес 1:1. О причинах и ограничениях там мило умолчали, предоставив пользователям строить догадки на эту тему. Методом научного тыка поиска было обнаружено, что адреса контроллеров 1:0, 2:0, 3:0 не пригодны для работы с RDM при количестве более 30 шт. При переходе границы этого числа ничего не работало, совсем и никак.
Таким образом, методом нехитрого сложения показаний выясняется, что ограничение на 60 дисков на одну VM это не так, в случае RDM, это всего лишь 57.
Еще одной дивной особенностью оказалось их подключение через VI-клиент. На подобную операцию уходит примерно 1,5-2 часа из-за абсолютно неудачного интерфейса. Почему нельзя было сделать множественный выбор? Непонятно. Скриптами не пользовались принципиально, так как на написание нужно было потрать кучу времени, а это была разовая операция. Ну, так казалось в начале эксперимента.
Таким образом, подобная VM с 46 RDM «взлетает» за 3 минуты, а останавливается за 5 мин. Работа такой VM в кластере особых вопросов не вызывает.
По-поводу RDM и чем они лучше VMDK узнал на собственной шкуре. Случайно удаленный vmdk-файл в Vsphere восстановить нельзя. Про бэкапы я более чем в курсе, но не будешь же экспериментальные VM бэкапить постоянно.
В принципе, восстановление VMDK тоже возможно на ESX 3.x (http://communities.vmware.com/docs/DOC-9972).
Ага возможно только на ESX 3.X, причем в случае постоянного бэкапа заголовков метафайлов.
В Vsphere только бэкап.
ИМХО программистам в vmware надо бы подумать на эту тему!
А способов восстановить данные и правда нет, сходу из-за схемы организации этих Vmdk.
Да, забыл сказать, что при таком количестве файлов в каталоге VM – датасторе браузер тормозит до 5 мин. на открытии папки VM.
Бесит ужасно.