 |
|
|
|
Кластеризация + виртуализация: Linux HA + OpenVZ. Часть 1: кластеризация на практике
Кластеризация + виртуализация: Linux HA + OpenVZ Часть 1: кластеризация на практике Как одновременно уменьшить количество физических серверов, требующих обслуживания, и при этом продублировать их, обеспечив автоматическое переключение на резервный сервер при отказе основного. Чем больше сервисов находится в вашем попечении и чем в большей степени от их работоспособности зависит нормальное функционирование предприятия, тем более актуальным становится обеспечение:
На первый взгляд эти задачи противоположны, однако их вполне можно совместить, если обеспечить отказоустойчивость не каждого сервиса в отдельности, а группы сервисов, работающих в виртуальных средах. Именно этим мы сейчас и займемся. Инструменты Сначала определимся с требуемым инструментарием исходя из того, что нас интересуют только решения с открытым исходным кодом. Если требуется гарантировать отказоустойчивость сервису, который сам по себе отказоустойчивым не является и встроенных механизмов кластеризации не имеет, то особых альтернатив проекту Linux HA (http://linux-ha.org) нет. Основным компонентом проекта является менеджер кластера Heartbeat, предоставляющий средства коммуникации между узлами кластера (в том числе механизм оповещения об отключении/включении узла) и управления ресурсами кластера. Для сервисов, решающих только вычислительные задачи, этого может быть достаточно, но большинство сервисов имеют привычку также хранить свои настройки и данные на диске. Чтобы они были доступны сервису независимо от того, на каком узле кластера он в данный момент работает, требуются внешние по отношению к проекту Linux HA средства организации распределенного файлового хранилища. В их качестве могут выступать:
Чаще всего в связке с Heartbeat используется DRBD (http://drbd.org), версия 7 которой обеспечивает более высокую производительность и надежность по сравнению с классическими распределенными файловыми системами. DRBD версии 8 движется в сторону своих конкурентов, пытаясь сохранить собственные преимущества, но к промышленной эксплуатации она пока еще не готова. Что же касается виртуализации, то здесь выбор гораздо шире, и определяется он тем, что именно мы собираемся виртуализировать и сколько аппаратных ресурсов мы готовы потратить. По этим критериям можно выделить 3 типа виртуализации (классификация приведена по докладу Кирилла Колышкина и Кирилла Коротаева, прозвучавшему во время Третьей Международной конференции разработчиков свободных программ на Протве – http://kir.vtx.ru/lj/openvz-intro-ru.pdf):
Как мне кажется, с точки зрения промышленной эксплуатации, а не тестирования различного ПО, наибольшее значение имеет именно виртуализация на уровне операционной системы, так как в этом случае достигается максимально возможная плотность размещения виртуальных сред по сравнению с двумя предыдущими типами. Из трех открытых проектов, предназначенных для Linux, наиболее функциональным и быстрее всего развивающимся выглядит OpenVZ, который также является основой для проприетарного продукта Virtuozzo фирмы SWSoft. Более того, на wiki проекта довольно коротко уже описана удачная попытка «скрестить» его с проектом Linux HA – http://wiki.openvz.org/HA_cluster_with_DRBD_and_Heartbeat. Поэтому пойдем уже проторенной дорогой и попытаемся построить аналогичное решение. В качестве платформы для построения нашего решения выбран ALT Linux Sisyphus (http://sisyphus.ru), и есть несколько причин такого выбора:
Что нам предстоит сделать В качестве простого примера возьмем ситуацию, когда нам требуется сконфигурировать почтовый сервер и сервер БД. Возможны следующие подходы к решению данной задачи:
Если не углубляться в детали, схема выбранного нами последнего способа построения системы изображена на рис. 1
Рисунок 1. Кластеризация + виртуализация Переходим к деталям. Строим кластер Более подробная схема, раскрывающая особенности внутрекластерных сетевых соединений, изображена на рис. 2.
Рисунок 2. Особенности внутрикластерных сетевых соединений Каждый узел кластера имеет по 3 сетевые карты:
Сначала настроим общие разделы узлов кластера средствами DRBD. Установка DRBD производится штатным для ALT Linux способом. Смотрим, какие пакеты имеются в наличии:
Затем определяем, какое у нас ядро:
На основании этой информации решаем, какие именно пакеты нам нужны, и устанавливаем их: [root@m1 ~]# apt-get install kernel-modules-drbd-std26-up drbd-tools Первый установленный нами пакет содержит модуль ядра, необходимый для работы DRBD, второй – userspace-инструменты для управления DRBD. Если вы используете другой дистрибутив Linux и уже готового модуля для вашего ядра нет ни в одном из репозиториев дистрибутива, модуль придется собрать самостоятельно – архив с последними исходными кодами DRDB доступен на http://oss.linbit.com/drbd. Конфигурирование DRBD сводится к редактированию файла /etc/drbd.conf. Минимальная, но вполне работоспособная конфигурация будет выглядит так: resource r0 { # протокол передачи # C: запись считается завершенной, если данные записаны на локальный и удаленный диск, подходит # для критически важных транзакций и в большинстве остальных случаев # B: запись считается завершенной, если данные записаны на локальный диск и удаленный буферный кэш # A: запись считается завершенной, если данные записаны на локальный диск и локальный буфер tcp # для отправки подходит для сетей с высокой задержкой protocol C; # описание узла m1 on m1.mydomain.com { device /dev/drbd0; # имя drbd-устройства disk /dev/hda3; # раздел диска, поверх которого оно работает address 192.168.200.1:7788; # адрес и порт демона drbd meta-disk internal; # хранить метаданные drbd на том же разделе диска } # описание узла m2 on m2.mydomain.com { device /dev/drbd0; # имя drbd-устройства disk /dev/hda3; # раздел диска, поверх которого оно работает address 192.168.200.2:7788; # адрес и порт демона drbd meta-disk internal; # хранить метаданные drbd на том же разделе диска } } В комплекте с DRBD поставляется очень детальный пример конфигурационного файла, в котором все параметры прокомментированы. Кроме того, если мы не используем udev (и создавать устройство /dev/drbd0 некому), придется создать его вручную: [root@m1 ~]# mknod /dev/drbd0 b 147 0 Также необходимо прописать автозапуск сервиса drbd при загрузке узла: [root@m1 ~]# chkconfig --level 2345 drbd on Эти операции необходимо повторить на узле m2, а затем на обоих узлах запустить сервис drbd:
После чего на обоих узлах кластера мы должны увидеть следующее:
Итак, раздел устройства /dev/drbd0 уже работает, но содержимое разделов /dev/hda3, лежащих уровнем ниже, еще не синхронизировано. Первый раз синхронизацию необходимо произвести вручную, выполнив на узле m1: [root@m1 ~]# drbdadm -- --do-what-I-say primary all После выполнения этой команды мы можем проследить за процесом синхронизации:
После окончания синхронизации на узле m1 мы увидим:
По строке Primary/Secondary можно определить, что сейчас узел m1 является ведущим. На ведомом узле m2 в выводе той же самой команды мы увидим Secondary/Primary. Все операции с устройством /dev/drbd0 необходимо выполнять только на ведущем узле, при этом все изменения будут автоматически применены к разделам /dev/hda3 на обоих узлах кластера. Создадим на устройстве /dev/drbd0 файловую систему и примонтируем ее:
Если теперь мы попытаемся примонтировать устройство /dev/drbd0 на узле m2, мы получим следующее:
Такое (вполне разумное) поведение гарантируется только для ядер 2.6, в 2.4 была возможность примонтировать устройство /dev/drbd0 на обоих узлах кластера одновременно, что в свою очередь могло привести к повреждению файловой системы. Чтобы все-таки примонтировать раздел /dev/drbd0 на узле m2, необходимо сделать его ведущим, выполнив на узлах m1 и m2 следующие команды: [root@m1 ~]# umount /d0 [root@m1 ~]# drbdadm disconnect all [root@m2 ~]# drbdadm disconnect all [root@m1 ~]# drbdadm secondary all [root@m2 ~]# drbdadm -- --human primary all [root@m1 ~]# drbdadm connect all [root@m2 ~]# drbdadm connect all [root@m2 ~]# mount /dev/drbd0 /d0 В случае отказа узла m1 достаточно выполнить только те команды, которые приведены выше для узла m2. По большому счету, любители велосипедостроения (или оптимальных решений – иногда трудно отличить одно от другого) могут этим и ограничиться: написать скрипт, который будет следить на доступностью соседнего узла, и монтировать раздел /dev/drbd0, если соседний узел умер, можно самостоятельно. Другой вопрос: зачем, если Heartbeat умеет делать и это, и многое другое? Устанавливаем Heartbeat штатным для ALT Linux способом: [root@m1 heartbeat]# apt-get install heartbeat Установка Heartbeat для других дистрибутивов Linux описана здесь http://www.linux-ha.org/DownloadSoftware. На главной странице проекта также написано, что кроме Linux Heartbeat, собирается и запускается на FreeBSD, Solaris и даже MacOS X. После установки Heartbeat на оба узла кластера на каждом узле необходимо создать файл /etc/ha.d/authkeys с правами доступа 600 и случайной строкой (ее можно придумать самому, а лучше сгенерировать с помощью apg), которая будет использоваться узлами для авторизации друг друга: auth 1 1 sha1 RcBkJzU8ClnrjWVRLv5EDsdRFQP1j1C Также необходимо создать конфигурационный файл Heartbeat, который на узле m1 будет выглядеть так: Logfacility local0 ucast eth2 192.168.200.2 auto_failback on node m1.mydomain.com m2.mydomain.com а на m2 – так: Logfacility local0 ucast eth2 192.168.200.1 auto_failback on node m1.mydomain.com m2.mydomain.com Затем необходимо описать ресурсы кластера в файле /etc/ha.d/haresources на каждом узле: m1.mydomain.com drbddisk Filesystem::/dev/drbd0::/d0::ext3 Такая запись означает, что кластер в штатном режиме будет использовать ресурсы drbddisk и Filesystem узла m1, а в случае его «смерти» – аналогичные ресурсы узла, оставшегося в живых, то есть m2. Для ресурса Filesystem заданы параметры: имя drbd-устройства, каталог, в который оно должно быть примонтировано (этот каталог мы должны создать самостоятельно на каждом узле кластера), и тип файловой системы. Узнать больше о ресурсах, поддерживаемых heartbeat, можно заглянув в каталог /etc/ha.d/resource.d – каждый ресурс представлен там соответствующим скриптом. Теперь можно запустить сервис heartbeat (не забыв перед этим размонтировать устройство /dev/drbd0, если оно было примонтировано):
После старта сервиса на ведущем узле кластера в логах можно увидеть такие сообщения:
В логах ведомого узла можно будет увидеть следующее:
После старта heartbeat на обоих узлах кластера устройство /dev/drbd0 будет примонтировано на ведущем узле. Если остановить сервис heartbeat на ведущем узле m1, ведомый m2 возьмет на себя функции ведущего, и устройство /dev/drbd0 будет примонтировано на нем, при этом в логах мы увидим:
Если просто выключить питание узла m1, чтобы он не успел оповестить m2 о том, что он завершает свою работу, m2 обнаружит отсутствие m1 и точно так же возьмет на себя функции ведущего узла и примонтирует раздел /dev/drbd0:
При повторном запуске сервиса heartbeat на m1 или при включении узла m1 он снова станет ведущим. Что дальше Традиционно после конфигурирования общего файлового хранилища файл /etc/ha.d/haresources дополняется списком сервисов, для которых необходимо гарантировать отказоустойчивость, а конфигурационные файлы и файлы данных этих сервисов перемещаются на файловую систему, созданную поверх drbd-устройства. Часто также конфигурируется алиас для сетевого интерфейса, который автоматически создается на ведущем узле, – тем самым все сервисы оказываются доступными по одному адресу. Недостатки такого подхода очевидны – чем больше сервисов, тем более запутанной становится такая конфигурация, а установка новых версий сервисов становится очень неудобной. Про общие проблемы сожительства различных сервисов на одном сервере я и не говорю – это специфично не только для Linux HA. Самым простым и изящным выходом в данной ситуации является виртуализация. Если использовать этот подход, нам потребуется обеспечить отказоустойчивость только для одного сервиса – контейнера, в котором будут жить виртуальные сервера, причем последние можно конфигурировать, не задумываясь о сложностях, связанных с кластеризацией... Но об этом читайте во второй части статьи, в следующем номере. Приложение Кластеры В Википедии (http://wikipedia.org) кластер определяется как группа серверов, связанных логически и способных обрабатывать идентичные запросы. Серверы в составе кластера называются узлами или нодами (Node). Каждый узел имеет собственный набор ресурсов, которые он предоставляет в пользование кластеру. Выделяют следующие типы кластеров:
В этой статье нас будет интересовать только последний тип – кластеры высокой готовности. Виртуализация Это система разделения ресурсов компьютера на множество независимых сред (виртуальных серверов), каждая из которых с точки зрения запущенных в ней программ выглядит как обычный выделенный сервер. Физический компьютер, на котором работают виртуальные среды, называется host-системой или HN (Hardware Node), для обозначения самих виртуальных сред часто используются такие термины, как гостевая система, раздел (partition), контейнер (container), VE, VPS, VDS. Основными областями применения виртуализации являются:
Проект «Sisyphus» Sisyphus (http://sisyphus.ru) – ежедневно обновляемый репозиторий пакетов свободных программ. Участие в Sisyphus открыто для всех желающих. В основе Sisyphus лежат технологии сборки программ и учета зависимостей между ними, а также отработанные процессы по взаимодействию между разработчиками. Для использования Sisyphus достаточно наличие любого дистрибутива ALT Linux (либо Sisyphus Live-CD) и средства управления пакетами программ APT. Sisyphus является постоянно развивающимся набором решений, на основе которого возможно создание универсальных или специализированных дистрибутивов Linux, а также одиночных решений. Таковыми являются все дистрибутивы, выпускаемые компанией ALT Linux (http://altlinux.ru), другим примером является дистрибутив RAD GNU/Linux (http://radlinux.org) для маршрутизаторов, Sisyphus Live-CD (http://www.unsafe.ru/lakostis/livecd) – еще один пример. ALT Linux Team, которая занимается развитием проекта, в настоящее время состоит из более чем 150 разработчиков, только 1/5 часть которых является штатными сотрудниками компании ALT Linux. Все остальные – это независимые разработчики, которые часто являются сотрудниками других организаций, использующих Sisyphus в своем бизнесе. Очень важно понимать, что Sisyphus в чистом виде, как и любая слишком быстро меняющаяся система, в большинстве случаев не предназначен для использования рядовыми пользователями, не принимающими даже минимальное участие в его развитии или хотя бы не отслеживающими состояние наиболее критичных для них компонентов системы, – и об этом явно сказано на сайте проекта. Для таких пользователей более удачным выбором будут дистрибутивы и специализированные решения на основе Sisyphus. К сожалению, пока не один из таких дистрибутивов не поддерживает описываемые в статье технологии виртуализации и кластеризации «из коробки», поэтому у вас есть выбор: использовать текущий репозиторий, дожидаться запланированного на ближайшее время стабильного среза или пытаться построить аналогичное решение на любом дистрибутиве Linux самостоятельно (и в этом случае тоже есть выбор: использовать дистрибутив, построенный на основе Sisyphus, или нет). Что выбрать, наверное, зависит в первую очередь от вашего опыта. Имя проекту дал Sisyphus (Сизиф) – персонаж греческой мифологии. Миф о Сизифе, который непрерывно катил в гору камни, символизирует постоянный труд ALT Linux Team по усовершенствованию решений, заложенных в репозиторий. В настоящее время в стадии подготовки находится книга «Сизифов труд: Ежегодный альманах о свободном ПО (Sisyphus 2006)», в которую в качестве главы войдет часть материала статьи. Эта книга должна стать чем-то вроде первого выпуска альманаха, в котором будет подробно раскрыто несколько самых актуальных тем, обсуждавшихся в прошедшие полгода в связи с разработкойSisyphus. Срок выхода книги планируется в соответствии с релиз-циклом Sisyphus, что позволит приложить к книге наиболее подходящий для использования стабильный срез репозитория. Дополнительная информация о книге доступна по ссылке https://heap.altlinux.ru/engine/Heap/Books/AltLibrary/Sisyphus2006. |
ЕВГЕНИЙ ПРОКОПЬЕВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
