Пятьдесят семь RDM

Филипп Зыков 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 шт. При переходе границы этого числа ничего не работало, совсем и никак.

57rdmТаким образом, методом нехитрого сложения показаний выясняется, что ограничение на 60 дисков на одну VM это не так, в случае RDM, это всего лишь 57.
Еще одной дивной особенностью оказалось их подключение через VI-клиент. На подобную операцию уходит примерно 1,5-2 часа из-за абсолютно неудачного интерфейса. Почему нельзя было сделать множественный выбор? Непонятно. Скриптами не пользовались принципиально, так как на написание нужно было потрать кучу времени, а это была разовая операция. Ну, так казалось в начале эксперимента.
Таким образом, подобная VM с 46 RDM «взлетает» за 3 минуты, а останавливается за 5 мин. Работа такой VM в кластере особых вопросов не вызывает.
По-поводу RDM и чем они лучше VMDK узнал на собственной шкуре. Случайно удаленный vmdk-файл в Vsphere восстановить нельзя. Про бэкапы я более чем в курсе, но не будешь же экспериментальные VM бэкапить постоянно.

Popularity: 2%

Опубликовать в Facebook
Опубликовать в Google Buzz
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс
Эта запись была опубликована в рубрике Новости и отмечена метками . Добавить в закладки ссылку.

3 в ответ на Пятьдесят семь RDM:

  1. Пинг: Пятьдесят семь RDM

  2. В принципе, восстановление VMDK тоже возможно на ESX 3.x (http://communities.vmware.com/docs/DOC-9972).

  3. phily пишет:

    Ага возможно только на ESX 3.X, причем в случае постоянного бэкапа заголовков метафайлов.
    В Vsphere только бэкап.
    ИМХО программистам в vmware надо бы подумать на эту тему!
    А способов восстановить данные и правда нет, сходу из-за схемы организации этих Vmdk.

    Да, забыл сказать, что при таком количестве файлов в каталоге VM – датасторе браузер тормозит до 5 мин. на открытии папки VM.
    Бесит ужасно.

Оставить комментарий

Ваш email не будет опубликован. Обязательные поля отмечены *

*

Вы можете использовать это HTMLтеги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Это не спам.
сделано dimoning.ru