воскресенье, 6 ноября 2011 г.

Guest level disk mirroring

 

Интересный пост - Surviving SAN failure – Revisited (vSphere).

Можно взять ВМ, подцепить к ней второй диск (второй комплект дисков), и настроить на этот второй диск зеркалирование с исходного средствами гостя.

Если второй поместить на другое хранилище, то мы получим защиту от сбоя СХД.

В посте по ссылке инструкция по реализации такой схемы для Windows 2003. Так же, в официальной документации по vSphere 5 есть упоминание – что необходимо настроить на стороне vSphere чтобы такая фича заработала - Set Up Dynamic Disk Mirroring.

Ну а исходно я углядел пост на yellowbricks, где сожалелось о том, что такая конфигурация не поддерживается вместе с VMware Fault Tolerance. Было бы интересно, конечно, в некоторых сценариях.

3 комментария:

  1. >Если второй поместить на другое хранилище, то мы получим защиту от сбоя СХД.

    Хм-ммм...
    Если наша VM с "половинкой guest-зеркала" (АКА vmdk1) лежит на одном хранилище, а "вторая половинка guest-зеркала" (АКА vmdk2) лежит на другом хранилище, то при краше первого хранилища у нас останется только v-диск с данными.

    Т.е. это скорее защита данных внутри VM, а не защита самой VM.
    И FT-шностью здесь не пахнет, бо (при фатальной потере содержимого каталога VM на первом хранилище) придётся воссоздавать эту VM, прикручивая потом к ней vmdk2.

    Тогда уж лучше двунодовую хранилку с блочной репликацией между нодами - тогда продублируются даже не просто все файлы VM, а датасторы хостов.
    Впрочем, это уже К.О.-режим... :))))

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  2. да, решение далеко не законченное, зато довольно высокая доступность данных "из г... и палок" - а два хранилища с репликацией стоят денег.

    ну а создать копию vmx, к которому прицепим vmdk после сбоя одного из датасторов - несложно.

    ОтветитьУдалить
  3. Скажем так - не "стОят денег", а требуют ресурсов: даже в случае бесплатного drbd это время и знания (хотя типсов по A/P-drbd предостаточно);
    в случае же чего-то платного - ещё и деньги, да. Плюс тоже время-знания - степень "искаропковости" у таких решения не настолько велика, чтобы их (уплочено же!) развернул "простой советский человек".

    Про копию vmx согласен, хотя необходимость манипуляций уже выводит решение из ниши "FT-образных".

    Плюс ещё тот момент, что при задержках на одном из хранилищ (а в случае бюджетной инфраструктуры, для которой анонсируется данное софт-зеркало между хранилками, таковые задержки почти неизбежны) есть большой шанс, что софт-зеркало в госте просто развалится по тайм-ауту недоступности одного из "субзеркал". Не вспомню сходу, есть ли где в винде регулировка этого пар-ра.

    Плюс синхронизация между половинками зеркала (в случае возобновления доступности одного из дисков) - она обычно идёт в довольно муторном темпе.

    Собственно, я сейчас на виртуальных файлопомойках (коим не нужно онлайновое соответствие) просто делаю доп.диск на другой хранилке (как в обсуждаемом рецепте), на который ночью по шедулеру делается быкап (благо, существует VSS :))).
    Тот же принцип - если "чуть что", то основная VM восстанавливается из быкапа (ежемесячного, допустим), а данные с актуальностью в сутки разливаются на неё из vmdk с другой хранилки.

    С уважением,
    Umlyaut.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.