LXF100-101:Hardcore Linux

Материал из Linuxformat.

Кластеры: Повышаем отказоустойчивость.

Отказоустойчивость – то свойство, которое помогает кластеру пережить сбой электропитания и другие бедствия. Д-р Крис Браун покажет, как удержаться на плаву.

Журналы доступа к моей web-странице – не самое захватывающее чтиво. Если исключить случайные вторжения роботов поисковых систем, посетители заходят на сайт не чаще раза в неделю. Честно говоря, если сайт упадет, это заметят разве что через несколько месяцев. Даже грустно. Другая крайность – коммерческие web-сайты, приносящие владельцам ежедневный доход: несколько минут простоя такого сайта выливаются в ощутимые убытки для компании. На данном уроке я расскажу, как создать в Linux отказоустойчивый кластер. В случае краха основного сервера система автоматически переключается на запасной, а снаружи кластер выглядит как один очень надежный сервер. Нам поможет открытая программа Heartbeat, найти которую можно на сайте http://www.linuxha.org. Кластер мы построим из двух компьютеров (основной и запасной сервер). Heartbeat будет отвечать за обнаружение отказа основного сервера и управлять запуском нужного нам сервиса на запасном. Мы воспользуемся сервисом Apache (httpd), но эта технология подойдет и для любого другого сервиса: FTP, DNS или почтового. В общем, все будет работать примерно так:

1. В обычном режиме необходимые сервисы (типа httpd) предоставляются основным сервером.
2. Основной и запасной серверы постоянно обмениваются друг с другом сообщениями Heartbeat [англ. пульс], которые говорят запасному серверу, что с основным все в порядке.
3. Если запасной сервер не получает сообщения, он перенимает ресурсы основного сервера (например, запускает собственную копию сервера httpd).
4. Запасной сервер перенимает IP-адрес, по которому предоставлялся сервис на основном сервере.

Начинаем: компоненты системы

Рис. 1: Общая схема проекта; обратите внимание на IP-адреса.

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

На основном и запасном серверах должен быть установлен Linux, на клиенте – необязательно (хотя под Linux в вашем распоряжении окажутся лучшие средства диагностики). Компьютеры должны быть подключены к сети Ethernet. Для обмена сигналами Heartbeat на основном и запасном серверах должна быть вторая сетевая карта. Эти карты нужно соединить друг с другом либо перекрестным (crossover) кабелем, либо через мини-хаб. Если на обоих компьютерах есть последовательный порт, то вместо второго Ethernet-подключения можно соединить их последовательные порты перекрестным кабелем, по которому будет производиться обмен сигналами. Общая схема показана на Рис. 1.

Установка heartbeat-соединения

Если обмен сигналами Heartbeat будет осуществляться через Ethernet, соединить сетевые карты друг с другом можно двумя способами: либо через перекрестный кабель RJ45, либо парой обычных кабелей через мини-хаб. Первый вариант лучше, потому что здесь нечему выходить из строя. Каждой из карт нужно назначить статический IP-адрес, причем выбранный из частного диапазона, ни один адрес из которого не используется во внутренней сети. Например, первой карте можно назначить адрес 10.0.0.1, второй – 10.0.0.2. Убедитесь, что компьютеры могут достучаться друг до друга [ping].

Также можно использовать и соединение через последовательный порт. Тогда нам потребуется последовательный перекрестный кабель. На обоих концах этого кабеля, который еще называют нуль-модемным, имеется 9-контактный разъем типа «мама». Кабелем нужно соединить последовательные порты компьютеров. (Последовательные порты и кабели сейчас используются редко, и если на ваших компьютерах их нет, проще пойти и купить вторую сетевую карту для соединения по Ethernet.)

Чтобы проверить соединение через последовательные порты, выполните на основном сервере команду:

cat /dev/ttyS0

а на запасном – команду:

cat /etc/fstab > /dev/ttyS0

На основном сервере должно отображаться содержимое файла. Повторите эксперимент в обратном направлении.

Heartbeat будет прекрасно работать с соединением любого типа. Преимущество Ethernet-соединения – трафик Heartbeat в этом случае можно отслеживать с помощью одной из утилит для отслеживания пакетов (например, wireshark). Можно даже использовать одновременно оба соединения, что позволит обойтись без ненужных откатов, если только одно из них выйдет из строя.

Настройка сетевых интерфейсов

Оба сетевых интерфейса, которые участвуют в Heartbeat-соединении, должны быть настроены на статические IP-адреса, так как DHCP-сервера в этой «сети» точно нет. Статические адреса должны быть и на основных интерфейсах, которые используются для подключения к основному и запасному серверам. Обратите внимание, что это НЕ те адреса, на которых предоставляется сервис. Heartbeat назначит сетевой карте исправного компьютера второй IP-адрес, и именно он будет использоваться клиентами для доступа к ресурсу.

Три файла конфигурации

Сразу после установки Heartbeat нужно создать в каталоге /etc/ha.d три (да, три!) файла конфигурации, а именно:

• ha.cf Файл содержит настройки самого Heartbeat; в нем определяются используемые программой пути и устанавливаются некоторые временные параметры.
• haresources Этот файл определяет ресурсы (сервисы), которыми будет управлять Heartbeat, и основной сервер для каждого из этих ресурсов.
• authkey В этом файле задается пароль и метод шифрования, используемый для аутентификации Heartbeat-сообщений.

Начнем с ha.cf. Пример этого файла можно найти в документации на Heartbeat (/usr/share/doc/heartbeat/ha.cf). Это один из файлов типа «визгу много, проку мало», которые целиком состоят из документации и закомментированных примеров. Можно скопировать его в /etc/ha.d и использовать как отправную точку, или создать свой файл с нуля.

Вот минимальный вариант этого файла. Номера строк даны только для удобства ссылок, в самом файле их нет:

Строки 1 и 2 задают номер порта и сетевой интерфейс, используемые для Heartbeat-соединения. Для соединения через последовательные порты в строках 3 и 3 задается порт и скорость соединения. Можно (и рекомендуется) использовать оба типа, но у меня было только соединение через последовательные порты, и я закомментировал строки 1 и 2. В строке 5 задается тайм-аут между сообщениями, а строка 6 определяет время, по истечении которого, не дождавшись очередного сообщения от основного сервера, запасной сочтет его покойником. В строке 7 указывается время, необходимое для активации сетевого интерфейса после включения компьютера, после чего Heartbeat начинает функционировать. В строках 8 и 9 задаются имена хостов для основного и запасного серверов (те, что возвращает команда uname -n).

Для начала попробуем управлять полностью фиктивным сервисом tester. Мы напишем скрипт, /etc/ha.d/resources.d/tester, вызываемый Heartbeat. Он будет всего лишь вызывать команду logger, которая сообщит нам (через syslogd), что скрипт был запущен. Вот как он выглядит:

#!/bin/bash
logger $0 called with argument $1

Скрипт нужно сделать исполняемым, например, так:

chmod 755 tester

В следующем файле, haresources, содержится список ресурсов, которыми управляет Heartbeat. Когда компьютер выходит из строя, эти ресурсы перемещаются с одного узла сети на другой. (попробуйте произносить это как “ha-resources”, а не “hare-sauces” [англ. hare – заяц, source – источник, sauce – соус, – прим. ред.]. По правде говоря, я сроду не ел зайчатины, но первым делом подумал о кролике и решил, что подойдет клюквенный соус.) Опять же, пример этого файла можно найти в документации (/usr/share/doc/Heartbeat) – можете просто скопировать его в /etc/ha.d или создать свой собственный файл с нуля. Для нашего первого теста в этом файле должна быть всего одна строка:

 primary.example.com tester

Также нужно создать файл /etc/ha.d/authkeys, содержащий ключи, используемые для аутентификации Heartbeat-сообщений, например:

 auth1
 1 sha1 foobar

Нужно позаботиться, чтобы читать этот файл мог только администратор:

chmod 600 authkeys

Если права доступа к этому файлу есть у кого-то еще, Heartbeat не запустится.

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

Теперь можно запустить Heartbeat. Для отслеживания сообщений Heartbeat на обоих компьютерах запустите tail -f для файла журнала (/var/log/messages). Запустите программу с помощью команды:

/etc/init.d/heartbeat start

На обоих компьютерах действия Heartbeat будут писаться в журнал. На основном сервере среди прочего должно появиться сообщение типа:

 logger: /etc/ha.d/resource.d/tester called with argument start

Оно означает, что основной сервер, как и ожидалось, запустил сервис tester.

Heartbeat запущен, и мы можем проверить поведение системы в случае отказа. Я просто выдернул шнур электропитания из основного сервера и наблюдал за сообщениями в файле журнала запасного. По истечении заданного времени запасной сервер сообщил об отказе основного и запустил сервис tester. Вот соответствующие строки журнала:

 heartbeat: [9615]: WARN: node primary.example.com: is dead
 heartbeat: [9615]: WARN: No STONITH device configured.
 heartbeat: [9615]: WARN: Shared disks are not protected.
 heartbeat: [9615]: info: Resources being acquired from primary.example.com.
 heartbeat: [9615]: info: Link primary.example.com:/dev/ttyS0 dead.
 heartbeat: [10305]: info: No local resources [/usr/share/heartbeat/ResourceManager listkeys backup.example.com] to acquire.
 harc[10304]: [10323]: info: Running /etc/ha.d/rc.d/status status
 mach_down[10329]: [10350]: info: Taking over resource group tester
ResourceManager[10351]: [10362]: info: Acquiring resource group:primary.example.com tester
logger: /etc/ha.d/resource.d/tester called with argument status
 ResourceManager[10351]: [10379]: info: Running /etc/ha.d/resource.d/tester start
 logger: /etc/ha.d/resource.d/tester called with argument start
 mach_down[10329]: [10384]: info: mach_down takeover complete for  node primary.example.com.

Первая проверка завершилась успешно, и пора поручить Heartbeat управление полноценным сервисом. Для этого проекта я выбрал httpd. Таким образом, сейчас нам нужно убедиться, что Apache установлен на обоих компьютерах, и положить в корневой каталог web-сервера какие-нибудь легко распознаваемые файлы. Я просто создал два файла /var/www/html/index.html, по одному для основного и запасного серверов; в файле для основного сервера была строка “This is the website from the primary server”, для запасного – “This is the website from the backup server” («Это сайт с основного/запасного сервера»). На обоих компьютерах запустите httpd:

/etc/init.d/httpd start

и проверьте, что, открыв в браузере адрес http://localhost, вы видите эти файлы. Теперь остановите Apache и убедитесь, что он не запустится автоматически при загрузке системы. Воспользуйтесь командами:

/etc/init.d/httpd stop
  chkconfig httpd --del

Это важно, потому что Apache должен запуститься не во время загрузки, а только если Heartbeat запустил его.

Теперь нужно изменить файл haresources так:

 primary.example.com httpd
 primary.example.com 192.168.0.50

В первой строке указывается сервис, которым будет управлять Heartbeat, а во второй – IP-адрес, используемый клиентом для доступа к сервису. При запуске Heartbeat этот адрес назначается на основной сервер как второй IP-адрес. Если основной сервер откажет, копия Heartbeat, запущенная на запасном сервере, перенесет этот IP-адрес на свой сетевой интерфейс.

Предполагается, что Heartbeat будет управлять сервисами путем запуска скрипта, указанного в haresources, с аргументами start, stop или status. Конечно, это те самые аргументы скриптов каталога /etc/init.d, что используются для запуска сервисов во время загрузки системы, и, по правде говоря, Heartbeat будет автоматически искать скрипт httpd в каталоге /etc/init.d.

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

/etc/init.d/heartbeat start

Когда Heartbeat войдет в нормальный режим работы, нужно кое-что проверить. На основном сервере запустите:

ip addr show

и проверьте, что Heartbeat назначил второй IP-адрес (в нашем примере 192.168.0.50) на наш сетевой интерфейс. Также запустите команду

ps -ef | grep httpd

которая проверит, что сервис httpd запущен. На запасной сервер второй IP-адрес не назначается, а сервис httpd на нем не выполняется.

Теперь пора загрузить третий компьютер, чтобы использовать в качестве клиента. Убедитесь, что он может разрешить имя компьютера, на котором запущен сервис, по его IP-адресу. Для этого я просто добавил строку

192.168.0.50 www.example.com

в файл /etc/hosts. Проверьте, пингуется ли адрес www.example.com с компьютера клиента. Откройте в браузере на клиентском компьютере страницу http://www.example.com. Вы должны увидеть файл index.html основного сервера. На клиенте также можно проверить кэш arp, запустив команду

arp -a

и обратить внимание на MAC-адрес, связанный с IP-адресом 192.168.0.50. В моем случае результат работы команды был таким:

www.example.com (192.168.0.50) at 00:0C:F1:96:A3:F7 [ether] on eth0

Ладно, и как это работает?

Мы подошли к драматической развязке: демонстрации переноса сервиса на запасной сервер в случае отказа основного. Можно было просто отключить питание основного сервера, как и в предыдущем эксперименте, но на сей раз я избрал более кроткий способ – просто остановил Heartbeat на основном сервере командой:

/etc/init.d/heartbeat stop

Остановившись, Heartbeat остановит httpd на основном сервере и проинформирует запасной сервер об отключении основного (через Heartbeat-соединение). Запасной сервер сразу возьмет управление на себя, и в файле его журнала (/var/log/messages) появятся новые сообщения. Два из них наиболее важны (время и другую информацию в начале строки я удалил):

 Running /etc/init.d/httpd start
 Registering new address record for 192.168.0.50 on eth0

В этом случае все заняло пару секунд. Если бы я просто выдернул из сети шнур питания основного сервера, то на восстановление системы потребовалось бы больше времени: в этом случае перед тем, как сделать вывод об отказе основного сервера и взять управление на себя, запасной сервер ожидал бы ответа 20 секунд (параметр deadtime в файле ha.cf).

На клиентском компьютере следует провести пару важных тестов. Во-первых, попробуйте обновить страницу www.example.com в браузере. Должна появиться страница запасного сервера. Во-вторых, еще раз просмотрите содержимое ARP-кэша. На моем компьютере команда arp –a вернула следующий результат:

 www.example.com (192.168.0.50) at 00:10:60:60:3E:8E [ether] on eth0

Это означает, что пакеты, предназначенные для адреса 192.168.0.50, теперь будут направляться на запасной сервер.

А что же дальше? Ну, наверное, со временем кто-то доберется до основного сервера, починит его и перезапустит. Когда Heartbeat перезапускается, он сообщает об этом запасному серверу через Heartbeat-соединение. В журнале запасного сервера появятся такие строки:

 Heartbeat restart on node primary.example.com
 Releasing resource group: primary.example.com httpd
 Running /etc/init.d/httpd stop
 Withdrawing address record for 192.168.0.50 on eth0

Они означают, что запасной сервер освободил ресурсы и разрешил основному забрать их.

Если у вас хватило духу дочитать до конца, поздравляю! Вы создали отказоустойчивый кластер в Linux и можете начать делать на этом деньги в реальном мире! Однако прежде чем пойти на собеседование в Google, NASA или даже Krazy Ken’s 24x7 Liquorice Emporium, быть может, вы захотите узнать о некоторых вопросах подробнее.

Один из них – это концепция «ограждения» (fencing). Когда запасной сервер перенимает ресурсы основного, нужно как-то гарантировать, чтобы основной сервер не попытался снова предоставить эти сервисы. Heartbeat может использовать для этого механизм STONITH (“shoot the other node in the head” – «контрольный выстрел в голову»), если вы купите устройство, программно отключающее питание компьютера. Второй вопрос – как синхронизировать содержимое двух web-серверов. В нашем примере мы умышленно сделали его разным, но на практике может потребоваться какое-то средство синхронизации их содержимого (rsync или unison). LXF