Привет всем!
Коллеги, помогите выбрать оптимальное решение.
Есть:
1. Несколько работающих на одном сервере (CentOS) виртуальных машин, которые реализованы на KVM.
2. Эти машины работают из img-файла, не из отдельного раздела. Так сложилось исторически и мне так удобно (в том числе и держать резервную копию машины).
Идея: перевести эти машины под управление pacemaker'a. Ввести их в отказоустойчивый кластер. Ну и соответственно - живая миграция этих машин между узлами кластера. Кластер уже развернут, кое-какие сервисы кластеризует. Но руки пока не доходили до виртуальных машин. Хотя это - основная цель кластера.
Реализация:
1. Есть пара небольших серверов, диски которых которые связаны по DRBD, и которые играют рояль простенького СХД.
2. На этих DRBD-дисках выделяем отдельный раздел, делаем его iSCSI-target, инициируем этот LUN с другого хоста, сажаем на него gfs2 и пользуемся кластерным разделяемым хранищем, куда складываем имеющиеся образы наших виртуальных машин. Вроде должно работать. Однако....
3. Есть иной вариант - делать на DRBD не один большой iSCSI-раздел, а несколько, по числу наших виртуалок и размером под виртуальную машину. Ну и потом настроить KVM, чтобы он работал не с образами, а с разделами на iSCSI-томах. Здесь, собственно две заморочки - перелить образ действущей виртуальной машины из файла в раздел, ну и потом - резервирование этой машины (простым копировнием не обойдешься). Но это - решаемо.
Коллеги, подскажите, какой вариант предпочтительнее, второй (машины в файлах) или третий (машины в отдельных разделах)? Ну и при условии, что пара машинок переедет с сервера, где они сейчас живут на компьютеры, которые играют рояль СХД...
То есть на чем лучше строить pacemaker'ную кластеризацию виртуальных машин?
LinuxForum.Fans
KVM на iSCSI под pacemaker'ом
Автор: Cruiser78
10 сообщений
4933 просмотров
Мне кажется будет шикарно ISCSI для каждого блочного устройства с DRBD и эти разделы в виртуалки как блочные устройства. Кластерная FS тут избыточна. Я сейчас делаю на ISCSI и ocfs2 почтовый кластер и после тестов понял что чем сложнее схема тем больше фактор отказа.
Я свое мнение уже не раз озвучил - нн надо страдать фигней, овирт, проксмокс и т.п. все умеют без глупостей с кластерным софтом
Я свое мнение уже не раз озвучил - нн надо страдать фигней, овирт, проксмокс и т.п. все умеют без глупостей с кластерным софтом
Я не об оболочках, которыми можно управляться с виртуальными машинами, спрашивал. Для моих задач вполне досаточно virt-manager'а.
Я о другом: если я имею iscsi, то как на нем лучше размещать виртуальные машиы? На кластерной файловой системе (в gfs2) образами или нарезать iscsi на кучу персональных LUN и в каждую лунку посадить свою виртуалку? Это первое.
И второе - я с большой опаской отношусь к режиму Primary/Primary в DRBD. Так как имел нару лет назад опыт борьбы со split-brian. Но там особых проблем не возникало, был режим Primary/Secondary, понятно было, где более актуальная версия лежит. А вот получить split-brian на Primary/Primary очень не хочется. Или надо для устойчивой работы виртуалки (в том числе и живой миграции) ставить раздел DRBD в режим Primary/Primary и делать к нему mutipath?
Хотя, я предпочел бы остаться в Primary/Secondary на DRBD и с файлами образов.
я бы сделал так, для каждой ВМ презентовал бы свой LUN.нарезать iscsi на кучу персональных LUN
Я не об оболочках, которыми можно управляться с виртуальными машинами, спрашивал. Для моих задач вполне досаточно virt-manager'а.
эта "оболочка" помимо прочего еще и управляет кластеризацией, без дополнительных костылей.
Я о другом: если я имею iscsi, то как на нем лучше размещать виртуальные машиы?
один LUN под LVM и LV для каждой машины
И второе - я с большой опаской отношусь к режиму Primary/Primary в DRBD. Так как имел нару лет назад опыт борьбы со split-brian. Но там особых проблем не возникало, был режим Primary/Secondary, понятно было, где более актуальная версия лежит. А вот получить split-brian на Primary/Primary очень не хочется. Или надо для устойчивой работы виртуалки (в том числе и живой миграции) ставить раздел DRBD в режим Primary/Primary и делать к нему mutipath?
Недавно говорил с основателем linbit, он прямым текстом сказал что для продакшен p/p не поддерживается.
я бы сделал так, для каждой ВМ презентовал бы свой LUN.
очень сложно управлять таким кол-вом LUNов
один LUN под LVM и LV для каждой машины
.....
Недавно говорил с основателем linbit, он прямым текстом сказал что для продакшен p/p не поддерживается.
По второму замечанию - видимо мой "спинной мозг" гениален. Чуял засаду... :)
А вот по первому - я, пока, сделал чуть иначе:
1. DRBD в режиме p/s;
2. LVM на DRBD;
3. LV на этом LVM для каждой машины и для иных целей (например, отдельный LV для samba-файлового сервера);
4. LUN'ы на LV, предназначенные для виртуальных машин. Думаю, что независимость LUN'ов позволит мне более спокойно разворачивать виртуальные машины на различных физических хостах кластера. Количество LUN'ов меня не слишком заботит, их у меня не тыща. Даже десятка не наберется. Максимум пяток. Так что говорить о проблемах с их управлением я бы не стал.
А вот дальше возникает вопрос. В умных книжках (от того же Linbit) пишется как поднять в HA-кластере под pacemaker'ом отдельно iSCSI-target с потребным количеством лунов. И отдельно пишется, как сделать отказоустойчивый кластер с виртуальными машинами. Первое сделано и работает. Более того, поднимаем (пока руками, вне кластера) iSCSI-инициатор и делаем на LUN'е виртуалку. Нет проблем. У меня нет сомнений в том, что оно (опять же отдельно) работать будет. Но вот как быть, если и LUN'ы (target) и инициаторы в одном кластере обитают? То есть - случай "для бедных", когда сервера тянут не только одну задачу (например, СХД и ничего больше), но и некоторые дополнительные и сведены в один кластер.
Получается следующее:
1. При нормальном запуске кластера с нодами А, В, С все ресурсы кластера расположатся на предписанных им местах и начнут работать. Предположим, что А и В - это НА-СХД, причем А выступает в роли Primary и является в штатном режиме iSCSI-Target'ом со всеми LUN'ами. С - сервер виртуальных машин. Машин, которые, случись неприятность c C, должны мигрировать на В или на А.
2. Прописываем, что в основе всего на кластере лежит Primary-DRBD диск. С этим диском связан ресурс LVM. Он будет запускаться только там, где Primary-DRBD. Соответственно файловый сервер и iSCSI-tagret с лунами будут запускаться только там, где работает ресурс LVM, и запускаться будут только после его запуска. Вполне естественно будет установить очередность запуска ресурса "iSCSI-инициатор" после запуска всех LUN'ов. Запускать его независимо от запуска LUN'ов... А что он увидит, если LUN'ов еще нет, если они еще не поднялись?
3. Итак, всё работает штатно, А и В - СХД, С - виртуалки. Если неприятность случается на С, то у меня нет сомнений, что машины переедут на В или на А (как в книжках написано). А вот что произойдет, если неприятность случится на А? На Primary-ноде DRBD? Primary-нода, отключив LVM, поедет на B (у меня этот переезд занимает не менее 40 секунд, долго щелкает переключение DRBD), при этом все ресурсы, которые были зависимы от LVM будут остановлены до окончания переезда мастера DRBD на новый, резервный узел кластера, и только после этого стартуют вновь, после старта LVM на этом резервном узле.
Отсюда вопрос - как будет чувствовать себя запущенная на С виртуальная машина, если она потеряет не только iSCSI-target (здесь может что-то на сетевом соединении может наиграться, перерыв в обслуживании), но отключится под ней сам iSCSI-том, на котором она развернута.... Не придет ли ей кирдык? Коллеги, наведите на правильное решение. Где я допускаю ошибку?
в случае с kvm кирдыка не будет, машина просто уйдет в паузу, заморозив все транзакции, и починив доступ к схд можно будет запустить ее с того же места. вмваревцы, кстати, только в 5.2 обещали начать работать на этой фичей, и наверное будут за нее деньги драть у бедных админов :)
в любом случае, я бы бросил drbd ко всем чертям, и если так нужен отказоустойчевый таргет, то тагеты отдельно, а хосты ВМ отдельно, то бишь 4 машины - актив/пассив сторедж с дрбд и пара хостов для овирта или RHEV. Более того, я так делал для клиентов, с запасным набором хостов и репликацией в метрокластерных масштабах - пашет вполне прилично. Ну а если серьезно, то для стореджа и одного хоста на нормальном железе и с рейдом вполне достаточно, раз мы делаем решение для бедных, то нечего выпендриваться, имхо.
в любом случае, я бы бросил drbd ко всем чертям, и если так нужен отказоустойчевый таргет, то тагеты отдельно, а хосты ВМ отдельно, то бишь 4 машины - актив/пассив сторедж с дрбд и пара хостов для овирта или RHEV. Более того, я так делал для клиентов, с запасным набором хостов и репликацией в метрокластерных масштабах - пашет вполне прилично. Ну а если серьезно, то для стореджа и одного хоста на нормальном железе и с рейдом вполне достаточно, раз мы делаем решение для бедных, то нечего выпендриваться, имхо.
C 4-мя машинами и дурак сможет... :) Нету у меня 4-й серверной машины. И, скорее всего, не будет. Хотя... Лет так через 5, когда придет срок сервера обновлять... Поэтому сейчас и выпендриваемся. Надо еще будет тщательно продумать, как фенсинг на моем кластере обеспечить, к чему его прицепить и как реализовать.
Войдите или зарегистрируйтесь, чтобы ответить.
