IT-блог компании "ЛанКей"

Не так давно нашими специалистами проводился аудит кластерной open-source системы, предназначенной для обеспечения высокой доступности сервисов телекоммуникационной компании. Физически система представляет собой 2 блэйд-сервера, соединенных через 2 коммутатора Cisco с использованием агрегированных сетевых интерфейсов. Бывший системный администратор этой организации решил использовать для достижения своих целей свободный аналог ОС RedHat – CentOS и монитор виртуальных машин Xen. В связи с отсутствием сети хранения данных, им был выбран путь репликации файловых систем виртуальных машин на физические машины посредством GlusterFS. Про саму задумку ничего плохого сказать не могу, разве что не известно как поведет себя живая миграция доменов Xen. Но когда мы выяснили, что работа не была доведена до конца: виртуальные машины работают на одном узле, автоматическая репликация не настроена, второй узел полностью простаивает, я предложил пересобрать эту конструкцию.

Наибольшим промахом своего предшественника я счел выбор 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.