Наибольшим промахом своего предшественника я счел выбор GlusterFS. Для ядра linux существует модуль DRBD (Distributed Replicated Block Device), позволяющий создавать на машинах блочные устройства для репликации их по сети между распределенными узлами, который я и выбрал для решения поставленных целей. Для ОС Solaris, кстати, существует аналогичный DRBD проект Sun StorageTek Availability Suite. Для FreeBSD аналогов не существует, что не удивляет.

В качестве ОС было решено использовать SUSE Linux Enterprise Server 11 + дополнение High Availability Extention. SUSE поддерживается компанией Novell, включает в себя удобные утилиты конфигурирования и регулярно обновляется. А дополнение SLES-HA представляет собой набор ПО, организующего кластерные отношения между узлами, основанное на связке проектов Linux-HA и ClusterLabs. Другими словами – cluster membership service, графические утилиты настройки этих сервисов, утилиты для поддержки кластерных файловых систем и прочее. Хочу отметить что графические утилиты в ОС Linux по-прежнему остаются сыроваты, имеют очень ограниченный функционал и могут вызвать проблемы несовместимости. Пользоваться ими лучше аккуратно.

Итак, вышеописанное программное обеспечение было установлено на оба узла, поверх RAID-массивов. По значительному разделу было выделено под drbd-устройства, располагающиеся поверх логических томов LVM, позволяющих в будущем удобно менять размеры виртуальных машин. Загрузчик GRUB настроен на запуск по умолчанию ядра с поддержкой Xen. Все 4 сетевых интерфейса было решено агрегировать с помощью технологии linux bonding в 5 режиме адаптивной передачи нагрузки. В сети предприятия активно используются VLAN’ы, потому трафик на выходе кластера должен быть тэггированым по протоколу 802.1q, поддержка которого осуществляется модулем ядра Linux. Каждая виртуальная машина с помощью моста подключается к нужному VLAN’у. При выходе из строя 3 из 4 сетевых интерфейсов, вся система продолжает работать, но на скорости до 1 гигабита =)

С настройками DRBD все достаточно просто, единственное – рекомендовано не использовать внутренние meta-диски, особенно если в будущем понадобиться менять размеры устройств.

Теперь все готово для настройки самого кластера, которую можно разделить на 2 этапа: настройка основных компонент (OpenAIS + Pacemaker) и настройка ресурс-агентов кластера, непосредственно управляющих нашими сервисами.

При настройке OpenAIS и Pacemaker нужно учитывать что в 2х-узловой конфигурации не нужно использовать quorum.

Для нашего случая, в котором кластер следит за виртуальными машинами, для каждой из них необходимо настроить следующие ресурсы:

1. управляющие устройствами DRBD (один примитивный и один master/slave)
2. управляюший монтированием файловой системы
3. управляющий доменом Xen

После чего объединить их в группы и задать параметры order и colocation, объясняющие кластеру в какой последовательности запускать ресурсы.

На этом настройка кластера заканчивается. Используя продукты VMWare или Citrix осуществить эту задачу конечно легче и удобней, тк о многих вещах просто не приходится задумываться, но вместе с лицензией на ПО вам придется приобрести внешнюю СХД. Ни в ESX ни в XenServer нет поддержки репликации разделов между узлами, не смотря на то что построены они на базе того же ядра Linux с использованием утилит, разработанных в рамках проекта GNU.

PS. Недавно, на конференции «Russian Open Source Forum 2010», IT-директор АВТОВАЗа рассказывал про организацию инфраструктуры их головного офиса – все сервисы предоставлены почти таким же кластером, только с внешней СХД и другим дитстрибутивом GNU/Linux.

Компоненты интеграции предназначены для обоих версий платформы Hyper-V – как для первой версии, входящей в состав Windows Server 2008, так и для второй, входящей в состав Windows Server 2008 R2. Эти компоненты включают в себя:

• драйвер синтетической сетевой карты
• драйвер синтетического адаптера SCSI
• драйвер блочного устройства VSC – поддержка синтетического адаптера IDE для увеличения быстродействия при загрузке

Драйвер мыши для графической оболочки Linux в комплект не входит.

Обращаем внимание, что для большинства виртуальных машин Linux доступно использование только одного виртуального процессора. Полноценная поддержка Hyper-V в ядре начинается с ядра версии 2.6.32.