Кластеризация + виртуализация: Linux HA + OpenVZ. Часть 1: кластеризация на практике::Журнал СА 11.2006
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 1235
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 1257
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 3786
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 4009
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 3203
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Кластеризация + виртуализация: Linux HA + OpenVZ. Часть 1: кластеризация на практике

Архив номеров / 2006 / Выпуск №11 (48) / Кластеризация + виртуализация: Linux HA + OpenVZ. Часть 1: кластеризация на практике

Рубрика: Администрирование /  Виртуализация

ЕВГЕНИЙ ПРОКОПЬЕВ

Кластеризация + виртуализация: Linux HA + OpenVZ

Часть 1: кластеризация на практике

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

Чем больше сервисов находится в вашем попечении и чем в большей степени от их работоспособности зависит нормальное функционирование предприятия, тем более актуальным становится обеспечение:

  • отказоустойчивости – от простого резервного копирования важных данных до систем высокой готовности (High Availability), когда при выходе из строя основного сервера его функции автоматически берет на себя резервный сервер;
  • консолидации сервисов и сокращения количества физических серверов, требующих обслуживания, – от простого размещения нескольких сервисов на одном физическом сервере до использования различных систем виртуализации, изолирующих сервисы друг от друга.

На первый взгляд эти задачи противоположны, однако их вполне можно совместить, если обеспечить отказоустойчивость не каждого сервиса в отдельности, а группы сервисов, работающих в виртуальных средах. Именно этим мы сейчас и займемся.

Инструменты

Сначала определимся с требуемым инструментарием исходя из того, что нас интересуют только решения с открытым исходным кодом.

Если требуется гарантировать отказоустойчивость сервису, который сам по себе отказоустойчивым не является и встроенных механизмов кластеризации не имеет, то особых альтернатив проекту Linux HA (http://linux-ha.org) нет.

Основным компонентом проекта является менеджер кластера Heartbeat, предоставляющий средства коммуникации между узлами кластера (в том числе механизм оповещения об отключении/включении узла) и управления ресурсами кластера. Для сервисов, решающих только вычислительные задачи, этого может быть достаточно, но большинство сервисов имеют привычку также хранить свои настройки и данные на диске. Чтобы они были доступны сервису независимо от того, на каком узле кластера он в данный момент работает, требуются внешние по отношению к проекту Linux HA средства организации распределенного файлового хранилища.

В их качестве могут выступать:

  • классические распределенные файловые системы (OCFS, CODA, GFS, Lustre), позволяющие организовать параллельный доступ к файлам с нескольких компьютеров одновременно;
  • средства автоматического зеркалирования разделов жесткого диска на двух компьютерах, обеспечивающие доступ к файлам на чтение и запись только с одного компьютера (программные – DRBD и аппаратные – IBM ServeRAID);
  • прочие средства, которые в принципе использовать можно, но либо их надежность (NFS, CIFS), либо стоимость (SAN) являются неприемлемыми.

Чаще всего в связке с Heartbeat используется DRBD (http://drbd.org), версия 7 которой обеспечивает более высокую производительность и надежность по сравнению с классическими распределенными файловыми системами. DRBD версии 8 движется в сторону своих конкурентов, пытаясь сохранить собственные преимущества, но к промышленной эксплуатации она пока еще не готова.

Что же касается виртуализации, то здесь выбор гораздо шире, и определяется он тем, что именно мы собираемся виртуализировать и сколько аппаратных ресурсов мы готовы потратить. По этим критериям можно выделить 3 типа виртуализации (классификация приведена по докладу Кирилла Колышкина и Кирилла Коротаева, прозвучавшему во время Третьей Международной конференции разработчиков свободных программ на Протве – http://kir.vtx.ru/lj/openvz-intro-ru.pdf):

  • Эмуляция (примеры реализации: QEmu, Bochs) – фактически это полная эмуляция аппаратного обеспечения, позволяющая запускать в виртуальной среде любую операционную систему, однако производительность таких решений сравнительно низкая.
  • Паравиртуализация (примеры реализации: Xen, User-mode Linux) – позволяет запускать в виртуальной среде специально модифицированную для этой среды операционную систему, соответственно запустить можно не все, но то, что запустить удастся, будет работать быстрее.
  • Виртуализация на уровне операционной системы (примеры реализации: FreeBSD Jail, Solaris Zones/Containers, Linux VServer, Linux OpenVZ, Linux FreeVPS) – позволяет в наибольшей степени снизить накладные расходы и добиться максимальной производительности за счет того, что все виртуальные среды обслуживает одно специально модифицированное ядро операционной системы. Соответственно запускать не только различные операционные системы, но даже разные версии ядра не получится, да и доступ к аппаратным ресурсам внутри виртуальной среды во многом будет ограничен.

Как мне кажется, с точки зрения промышленной эксплуатации, а не тестирования различного ПО, наибольшее значение имеет именно виртуализация на уровне операционной системы, так как в этом случае достигается максимально возможная плотность размещения виртуальных сред по сравнению с двумя предыдущими типами. Из трех открытых проектов, предназначенных для Linux, наиболее функциональным и быстрее всего развивающимся выглядит OpenVZ, который также является основой для проприетарного продукта Virtuozzo фирмы SWSoft. Более того, на wiki проекта довольно коротко уже описана удачная попытка «скрестить» его с проектом Linux HA – http://wiki.openvz.org/HA_cluster_with_DRBD_and_Heartbeat. Поэтому пойдем уже проторенной дорогой и попытаемся построить аналогичное решение.

В качестве платформы для построения нашего решения выбран ALT Linux Sisyphus (http://sisyphus.ru), и есть несколько причин такого выбора:

  • у меня уже имеется опыт успешной эксплуатации решений на дистрибутивах от ALT вообще и Sisyphus в частности;
  • использование Sisyphus предполагает минимум ручной работы, т.к. Linux HA и OpenVZ уже работают в нем «из коробки».

Что нам предстоит сделать

В качестве простого примера возьмем ситуацию, когда нам требуется сконфигурировать почтовый сервер и сервер БД.

Возможны следующие подходы к решению данной задачи:

  1. Традиционный – для каждой задачи выделяется и конфигурируется отдельный физический сервер. В случае сбоя одного из серверов мы лишимся, как минимум, тех сервисов, которые этот сервер предоставляет. В худшем случае, учитывая, что сервисы могут зависеть друг от друга (а конфигурации, в которых почтовый сервер интенсивно использует сервер БД, не так уж редки), мы можем лишиться гораздо большего.
  2. Кластеризация – физические серверы (точнее, сервисы, работающие на этих серверах) дублируются средствами Linux HA. В этом случае надежность значительно увеличивается, но возрастает также количество серверов и затраты на их обслуживание.
  3. Виртуализация – для каждого сервера выделяется отдельная виртуальная среда на общем физическом сервере. В этом случае увеличивается гибкость, теперь мы не ограничены в количестве серверов и можем, например, выделить отдельную виртуальную среду для организации маршрутизатора/брандмауэра, ограничивающего доступ к почтовому серверу и серверу БД. Количество физических серверов и затраты на их обслуживание уменьшаются, но вместе с ними уменьшается и надежность, которая может оказаться даже ниже, чем в случае (1), если работоспособность серверов не зависит друг от друга.
  4. Кластеризация + виртуализация  – общий физический сервер (точнее, один-единственный сервис – система виртуализации) дублируется средствами Linux HA, тем самым мы совмещаем преимущества подходов (2) и (3) ценой увеличения нагрузки на сервера по сравнению с подходом (1).

Если не углубляться в детали, схема выбранного нами последнего способа построения системы изображена на рис. 1

Рисунок 1. Кластеризация + виртуализация

Рисунок 1. Кластеризация + виртуализация

Переходим к деталям.

Строим кластер

Более подробная схема, раскрывающая особенности внутрекластерных сетевых соединений, изображена на рис. 2.

Рисунок 2. Особенности внутрикластерных сетевых соединений

Рисунок 2. Особенности внутрикластерных сетевых соединений 

Каждый узел кластера имеет по 3 сетевые карты:

  • eth0 – используется для подключения к внешней сети;
  • eth1 – будет использована далее при создании виртуального сервера router, поэтому адрес ей не присвоен;
  • eth2 – специально выделена для коммуникации между узлами кластера.

Сначала настроим общие разделы узлов кластера средствами DRBD. Установка DRBD производится штатным для ALT Linux способом. Смотрим, какие пакеты имеются в наличии:

[root@m1 ~]# apt-cache search drbd

drbd-tools - Distributed Redundant Block Device utilities

kernel-modules-drbd-ovz-smp - Linux drbd kernel modules for DRBD.

kernel-modules-drbd-std-smp - Linux drbd kernel modules for DRBD.

kernel-modules-drbd-std-up - Linux drbd kernel modules for DRBD.

kernel-modules-drbd-std26-smp - Linux drbd kernel modules for DRBD.

kernel-modules-drbd-std26-up - Linux drbd kernel modules for DRBD.

kernel-modules-drbd-vs26-smp - Linux drbd kernel modules for DRBD.

kernel-modules-drbd-wks26-smp - Linux drbd kernel modules for DRBD.

kernel-modules-drbd-wks26-up - Linux drbd kernel modules for DRBD.

kernel-source-drbd-0.7.21 - Kernel source for DRBD.

Затем определяем, какое у нас ядро:

[root@m1 ~]# uname -a

Linux m1.mydomain.com 2.6.16-std26-up-alt10 #1 Wed Sep 13 20:06:02 MSD 2006 i686 GNU/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:

[root@m1 ~]# uname -a

Starting Starting DRBD resources:     service: [ d0 s0 n0 ].

...

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

[root@m1 ~]# service drbd status

drbd driver loaded OK; device status:

version: 0.7.21 (api:79/proto:74)

SVN Revision: 2326 build by builder@xeon.office.altlinux.ru, 2006-09-22 23:46:26

 0: cs:Connected st:Secondary/Secondary ld:Inconsistent

    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0

Итак, раздел устройства /dev/drbd0 уже работает, но содержимое разделов /dev/hda3, лежащих уровнем ниже, еще не синхронизировано.

Первый раз синхронизацию необходимо произвести вручную, выполнив на узле m1:

[root@m1 ~]# drbdadm -- --do-what-I-say primary all

После выполнения этой команды мы можем проследить за процесом синхронизации:

[root@m1 ~]# service drbd status

drbd driver loaded OK; device status:

version: 0.7.21 (api:79/proto:74)

SVN Revision: 2326 build by builder@xeon.office.altlinux.ru, 2006-09-22 23:46:26

 0: cs:SyncSource st:Primary/Secondary ld:Consistent

    ns:1972 nr:0 dw:0 dr:10164 al:0 bm:0 lo:0 pe:30 ua:2048 ap:0

       [>...................] sync"ed:  0.2% (3158696/3160552)K

       finish: 0:26:19 speed: 1,856 (1,856) K/sec

После окончания синхронизации на узле m1 мы увидим:

[root@m1 ~]# service drbd status

drbd driver loaded OK; device status:

version: 0.7.21 (api:79/proto:74)

SVN Revision: 2326 build by builder@xeon.office.altlinux.ru, 2006-09-22 23:39:33

 0: cs:Connected st:Primary/Secondary ld:Consistent

    ns:731068 nr:1052796 dw:1782732 dr:193337 al:20 bm:356

    lo:0 pe:0 ua:0 ap:0

По строке Primary/Secondary можно определить, что сейчас узел m1 является ведущим. На ведомом узле m2 в выводе той же самой команды мы увидим Secondary/Primary. Все операции с устройством /dev/drbd0 необходимо выполнять только на ведущем узле, при этом все изменения будут автоматически применены к разделам /dev/hda3 на обоих узлах кластера.

Создадим на устройстве /dev/drbd0 файловую систему и примонтируем ее:

root@m1 ~]# mkfs.ext3 /dev/drbd0

mke2fs 1.39 (29-May-2006)

Filesystem label=

OS type: Linux

Block size=4096 (log=2)

Fragment size=4096 (log=2)

395200 inodes, 790138 blocks

39506 blocks (5.00%) reserved for the super user

First data block=0

Maximum filesystem blocks=809500672

25 block groups

32768 blocks per group, 32768 fragments per group

15808 inodes per group

Superblock backups stored on blocks:

        32768, 98304, 163840, 229376, 294912

 

Writing inode tables: done

Creating journal (16384 blocks): done

Writing superblocks and filesystem accounting information: done

 

This filesystem will be automatically checked every 25 mounts or

180 days, whichever comes first.  Use tune2fs -c or -i to override.

[root@m1 ~]# mkdir /d0

[root@m1 ~]# mount /dev/drbd0 /d0

Если теперь мы попытаемся примонтировать устройство /dev/drbd0 на узле m2, мы получим следующее:

[root@m2 ~]# mkdir /d0

[root@m2 ~]# mount /dev/drbd0 /d0

/dev/drbd0: Input/output error

mount: block device /dev/drbd0 is write-protected, mounting read-only

/dev/drbd0: Input/output error

mount: /dev/drbd0 already mounted or /d0 busy

Такое (вполне разумное) поведение гарантируется только для ядер 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, если оно было примонтировано):

[root@m1 ~]# service heartbeat start

logd is already running

Starting High-Availability services:       [ DONE ]

После старта сервиса на ведущем узле кластера в логах можно увидеть такие сообщения:

m1 heartbeat: [3372]: info: Status update for node m2.mydomain.com: status active

m1 harc[3395]: info: Running /etc/ha.d/rc.d/status status

m1 heartbeat: [3406]: info: Local Resource acquisition completed.

m1 harc[3431]: info: Running /etc/ha.d/rc.d/ip-request-resp ip-request-resp

m1 ip-request-resp[3431]: received ip-request-resp drbddisk OK yes

m1 ResourceManager[3446]: info: Acquiring resource group: m1.mydomain.com drbddisk Filesystem::/dev/drbd0::/d0::ext3

m1 ResourceManager[3446]: info: Running /etc/ha.d/resource.d/drbddisk  start

m1 Filesystem[3569]: INFO: Running status for /dev/drbd0 on /d0

m1 Filesystem[3569]: INFO: /d0 is unmounted (stopped)

m1 Filesystem[3505]: INFO: Filesystem Resource is stopped

m1 ResourceManager[3446]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /d0 ext3 start

m1 Filesystem[3678]: INFO: Running start for /dev/drbd0 on /d0

m1 kernel: kjournald starting.  Commit interval 5 seconds

m1 kernel: EXT3 FS on drbd0, internal journal

m1 kernel: EXT3-fs: mounted filesystem with ordered data mode.

m1 Filesystem[3614]: INFO: Filesystem Success

В логах ведомого узла можно будет увидеть следующее:

m2 heartbeat: [3739]: info: Status update for node m1.mydomain.com: status up

m2 harc[3752]: info: Running /etc/ha.d/rc.d/status status

m2 heartbeat: [3739]: info: remote resource transition completed.

m2 heartbeat: [3773]: info: No local resources [/usr/lib/heartbeat/ResourceManager listkeys m2.mydomain.com] to acquire.

После старта heartbeat на обоих узлах кластера устройство /dev/drbd0 будет примонтировано на ведущем узле. Если остановить сервис heartbeat на ведущем узле m1, ведомый m2 возьмет на себя функции ведущего, и устройство /dev/drbd0 будет примонтировано на нем, при этом в логах мы увидим:

m2 kernel: drbd0: Secondary/Primary --> Secondary/Secondary

m2 heartbeat: [3739]: info: Received shutdown notice from "m1.mydomain.com".

m2 heartbeat: [3739]: info: Resources being acquired from m1.mydomain.com.

m2 heartbeat: [3850]: info: acquire local HA resources (standby).

m2 heartbeat: [3851]: info: No local resources [/usr/lib/heartbeat/ResourceManager listkeys m2.mydomain.com] to acquire.

m2 heartbeat: [3850]: info: local HA resource acquisition completed (standby).

m2 heartbeat: [3739]: info: Standby resource acquisition done [all].

m2 harc[3870]: info: Running /etc/ha.d/rc.d/status status

m2 mach_down[3880]: info: Taking over resource group drbddisk

m2 ResourceManager[3900]: info: Acquiring resource group: m1.mydomain.com drbddisk Filesystem::/dev/drbd0::/d0::ext3

m2 ResourceManager[3900]: info: Running /etc/ha.d/resource.d/drbddisk start

m2 kernel: drbd0: Secondary/Secondary --> Primary/Secondary

m2 Filesystem[4023]: INFO: Running status for /dev/drbd0 on /d0

m2 Filesystem[4023]: INFO: /d0 is unmounted (stopped)

m2 Filesystem[3959]: INFO: Filesystem Resource is stopped

m2 ResourceManager[3900]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /d0 ext3 start

m2 Filesystem[4132]: INFO: Running start for /dev/drbd0 on /d0

m2 kernel: kjournald starting.  Commit interval 5 seconds

m2 kernel: EXT3 FS on drbd0, internal journal

m2 kernel: EXT3-fs: mounted filesystem with ordered data mode.

m2 Filesystem[4068]: INFO: Filesystem Success

m2 mach_down[3880]: info: /usr/lib/heartbeat/mach_down: nice_failback: foreign resources acquired

m2 mach_down[3880]: info: mach_down takeover complete for node m1.mydomain.com.

m2 heartbeat: [3739]: info: mach_down takeover complete.

Если просто выключить питание узла m1, чтобы он не успел оповестить m2 о том, что он завершает свою работу, m2 обнаружит отсутствие m1 и точно так же возьмет на себя функции ведущего узла и примонтирует раздел /dev/drbd0:

m2 kernel: drbd0: PingAck did not arrive in time.

m2 kernel: drbd0: drbd0_asender [3566]: cstate Connected --> NetworkFailure

m2 kernel: drbd0: asender terminated

m2 kernel: drbd0: drbd0_receiver [3510]: cstate NetworkFailure --> BrokenPipe

m2 kernel: drbd0: short read expecting header on sock: r=-512

m2 kernel: drbd0: worker terminated

m2 kernel: drbd0: drbd0_receiver [3510]: cstate BrokenPipe --> Unconnected

m2 kernel: drbd0: Connection lost.

m2 kernel: drbd0: drbd0_receiver [3510]: cstate Unconnected --> WFConnection

m2 heartbeat: [3739]: WARN: node m1.mydomain.com: is dead

m2 heartbeat: [3739]: WARN: No STONITH device configured.

m2 heartbeat: [3739]: WARN: Shared disks are not protected.

m2 heartbeat: [3739]: info: Resources being acquired from m1.mydomain.com.

m2 heartbeat: [3739]: info: Link m1.mydomain.com:eth2 dead.

m2 harc[4383]: info: Running /etc/ha.d/rc.d/status status

m2 heartbeat: [4384]: info: No local resources [/usr/lib/heartbeat/ResourceManager listkeys m2.mydomain.com] to acquire.

m2 mach_down[4403]: info: Taking over resource group drbddisk

m2 ResourceManager[4423]: info: Acquiring resource group: m1.mydomain.com drbddisk Filesystem::/dev/drbd0::/d0::ext3

m2 ResourceManager[4423]: info: Running /etc/ha.d/resource.d/drbddisk  start

m2 kernel: drbd0: Secondary/Unknown --> Primary/Unknown

m2 Filesystem[4546]: INFO: Running status for /dev/drbd0 on /d0

m2 Filesystem[4546]: INFO: /d0 is unmounted (stopped)

m2 Filesystem[4482]: INFO: Filesystem Resource is stopped

m2 ResourceManager[4423]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /d0 ext3 start

m2 Filesystem[4655]: INFO: Running start for /dev/drbd0 on /d0

m2 kernel: kjournald starting.  Commit interval 5 seconds

m2 kernel: EXT3 FS on drbd0, internal journal

m2 kernel: EXT3-fs: recovery complete.

m2 kernel: EXT3-fs: mounted filesystem with ordered data mode.

m2 Filesystem[4591]: INFO: Filesystem Success

m2 mach_down[4403]: info: /usr/lib/heartbeat/mach_down: nice_failback: foreign resources acquired

m2 mach_down[4403]: info: mach_down takeover complete for node m1.mydomain.com.

m2 heartbeat: [3739]: info: mach_down takeover complete.

При повторном запуске сервиса 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.

  1. http://linux-ha.org
  2. http://drbd.org
  3. http://openvz.org
  4. http://altlinux.ru
  5. http://sisyphus.ru
  6. http://freesource.info

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru