LXF102:Hardcore Linux

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

Виртуальный сервер Linux

Строить сбалансированный по нагрузке кластер с LVS – отличный способ согреться в зимний день: не хуже, чем колоть дрова, уверяет д-р Крис Браун.

Данный урок покажет вам, как создать сбалансированный по нагрузке кластер web-серверов, с масштабируемой производительностью, значительно превышающей возможности индивидуального сервера. Мы будем использовать программное обеспечение для кластеров от Red Hat, но основная функциональность, описанная в данном учебнике, основана на модуле виртуального сервера ядра Linux и не привязана к Red Hat.

Если вы захотите последовать уроку «в натуре», вам потребуется как минимум четыре компьютера, как показано на рис. 1 (на следующей странице). Я понимаю, что для некоторых читателей такой проект будет практически недосягаемым, но, надеюсь, он пригодится как мысленный эксперимент, вроде того, что Шредингер проделывал со своим котом.

Машина 1 – просто клиент, используемый для тестирования: ею может быть все, что имеет web-браузер. Я экспроприировал машину моей жены, на ней стоит Vista. Машина 2 – стенд для эксперимента. Она должна работать под Linux и, предпочтительно, иметь два сетевых интерфейса, как показано на рисунке. (Можно собрать кластер, используя всего одну сеть, но этот механизм не годится для промышленного применения и требует немного колдовства на уровне IP, чтобы заставить его работать.)

Эта машина выполняет обязанности балансировщика нагрузки и маршрутизатора в кластере, и в документации LVS ее называют “director” [активный маршрутизатор, – прим. пер.]. В моем случае на машине 2 запущен CentOS5 (по сути, эквивалент RHEL5). Машины 3 и 4 – дополнительные серверы [в документации их называют «реальными»]; в принципе, вы можете использовать что-то вроде webсерверов. Я использовал пару ноутбуков, один с SUSE 10.3, второй с Ubuntu 7.04. На деле вам потребуется больше дополнительных серверов, но двух достаточно для получения результата.

Вы, верно, недоумеваете, почему на всех четырех компьютеров я запустил разные ОС. Хороший вопрос – я сам часто его себе задаю! Увы, это просто факт из жизни тех из нас, кто зарабатывает на хлеб с Linux.

Как работает сбалансированный по нагрузке кластер

Машины клиентов посылают запрос (например, запрос на web-страницу HTTP GET) на публичный IP-адрес активного маршрутизатора (на рисунке, 192.168.0.41; для клиентов это адрес, по которому предоставляется услуга).

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

Выбранный реальный сервер обрабатывает запрос и отсылает HTTP-ответ, который теоретически содержит запрошенную страницу. Этот ответ адресован клиентской машине (192.168.0.2), но вначале он возвращается к активному маршрутизатору (10.0.0.1), потому что тот сконфигурирован как шлюз по умолчанию для реальных серверов. Активный маршрутизатор меняет IP-адрес источника в пакете на свой публичный IP-адрес и посылает пакет обратно клиенту.

Все эти трюки на уровне IP выполняются с помощью LVS-модуля ядра Linux. Активный маршрутизатор работает не просто в качестве обратного web-прокси, и команды типа netstat -ant не покажут каких либо процессов уровня пользователя, прослушивающих 80 порт. Перезапись адреса – это разновидность NAT (Network Address Translation), позволяющая активному маршрутизатору маскироваться под реальный сервер, скрыв наличие внутренней сети, выполняющей реальную работу.

Балансируя нагрузку

Балансировка нагрузки – ключевая особенность LVS: благодаря ей, можно быть уверенным, что каждый реальный сервер получает примерно одинаковый объем работы. LVS имеет для этого несколько алгоритмов; мы упомянем четыре из них.

• Циклическое распределение [round-robin scheduling] – самый простой алгоритм. Активный маршрутизатор просто работает по кругу, переходя снова на первый реальный сервер, когда исчерпает список. Этот метод хорошо подходит для тестирования, потому что позволяет легко проверить на работоспособность все реальные сервера, но он не самый лучший при промышленном применении.
• Циклическое распределение с весовыми коэффициентами [weighted round-robin] – аналогично, но позволяет назначать для каждого реального сервера «вес», соответствующий его относительной скорости. Сервер с весовым коэффициентом «два» считается в два раза мощнее сервера с весовым коэффициентом «один», и может обработать в два раза больше запросов.
• Минимум соединений [least-connection] – наименее нагруженный сервер отслеживается по количеству активных соединений, и запрос отправляется на сервер с наименьшей загрузкой.
• Минимум соединений с весовыми коэффициентами [weighted least connection] также выполняет подсчет относительной производительности (весов) серверов. Этот метод хорош для производственных кластеров, потому что он прекрасно работает, когда запросы сильно различаются по времени их обработки и/или когда реальные сервера в кластере имеют различную мощность.

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

Рис. 1. Простой кластер со сбалансированной нагрузкой.

Инструменты для работы

Чтобы все это заработало, ядро поддерживает таблицу виртуального сервера, которая содержит, кроме прочего, IP-адреса реальных серверов. Для поддержания и просмотра этой таблицы используется инструмент командной строки ipvsadm.

Если ваше ядро (как большинство других современных ядер) собрано с поддержкой LVS, то ipvsadm – единственная программа, которую вы обязаны иметь, чтоб заставить LVS работать; однако есть другие инструменты, облегчающие жизнь. (Ситуация похожа на механизм пакетной фильтрации в ядре. В теории для управления им и создания межсетевого экрана нужна только утилита командной строки iptables, на практике же большинство из нас использует для построения собственных правил фильтрации инструменты высокого уровня, часто графические). На данном уроке мы воспользуемся инструментами для кластеров от Red Hat, включая web-ориентированный инструмент настройки Piranha.

Основной недостаток конфигурации, показанной на рис. 1 – активный маршрутизатор является единой точкой отказа в пределах кластера. Чтобы этого избежать, можно использовать в качестве активного маршрутизатора пару серверов (основной и резервный); используя обмен сообщениями heartbeat, резервный сервер может определить сбой основного сервера и взять на себя его работу.

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

Настраиваем реальные сервера

Если вы хотите по-настоящему построить кластер, описанный на этом уроке, начните с реальных серверов. Это могут быть любые машины, имеющие web-сервер HTTP на 80-м порту; в моем случае на них был запущен Linux и Apache.

Нужно создать какие-нибудь данные в директории DocumentRoot на каждом сервере, и для тестирования было бы неплохо, чтобы на каждой машине эти данные были свои: тогда легко различить, какой сервер обрабатывает запрос в данный момент. Например, на реальном сервере 1 я создал файл proverb.html, содержащий строку «Дорога ложка к обеду». На сервере 2 строка была уже «Не зная броду, не суйся в воду». Конечно, в реальных условиях нужно, наоборот, «синхронизировать» все реальные сервера, чтобы они хранили одно и то же содержимое – к этой проблеме мы вернемся позднее.

Назначьте машинам реальные IP-адреса, предназначенные для внутренних сетей; в моем случае это 10.0.0.2 и 10.0.0.3. Установите маршрутизацию по умолчанию на этих машинах на приватный IP-адрес активного маршрутизатора (10.0.0.1).

Рис. 2. Конфигурирование виртуального сервера с Piranha.

Установка активного маршрутизатора

На активном маршрутизаторе начните с закачки и установки инструментов кластеризации Red Hat. В моем случае (вспомните, что я запустил на этой машине CentOS5) я просто использовал графический инструмент установки (pirut) для добавления пакетов ipvsadm и Piranha из репозитория CentOS5. Моим следующим шагом был запуск команды piranha-passwd для установки пароля на инструмент конфигурации piranha:

Рис. 3. Определяем реальные сервера.

Этот сервис слушает порт 3636 и предоставляет web-интерфейс для конфигурирования инструментов кластеризации, так что после его запуска мне осталось набрать в браузере http://localhost:3636 для доступа к нему. Далее мне нужно было зайти, используя имя пользователя piranha и пароль, который я установил. После этого стали доступны четыре основных окна: Control/Monitoring, Global Settings, Redundancy и Virtual Servers (вы можете увидеть ссылку на них на рис. 3). Для начала зайдите в окно Virtual Servers и добавьте новый сервис. На рис. 2 показана форма, которую вы должны заполнить. Среди прочего, вы должны задать имя сервиса, указать номер порта и интерфейс, через который он будет принимать пакеты, и выбрать алгоритм работы (для начального тестирования я выбрал ‘Round Robin’ [Циклическое распределение]). Кликнув на ссылку Real Server вверху этой страницы, вы попадете на страницу, показанную на рис. 3. Здесь вы должны указать имя, IP-адрес и веса ваших реальных серверов.

За кадром, большинство настроек, захваченных Piranha, хранятся в файле конфигурации /etc/sysconfig/ha/lvs.cf. Другие инструменты кластеризации читают его; это обычный текстовый файл, и ник-

то не запрещает вам редактировать его напрямую. Выполнив данную настройку, можно начинать. Запустите сервис кластеризации из командной строки:

# /etc/init.d/pulse start

(В реальности вы должны сделать этот сервис автоматически запускаемым при загрузке.)

Рис. 4. Экран управления и мониторинга Piranha.

Теперь идите на экран управления/мониторинга Piranha, как показано на рис. 4. Внимательно посмотрите на таблицу маршрутизации LVS. Вы должны увидеть записи о вашем виртуальном сервере (это строки, начинающиеся с TCP...), а пониже – строки для каждого реального сервера. Ту же информацию можно добыть из командной строки, набрав

# ipvsadm -L

Периодическая проверка здоровья

Также на экране управления/мониторинга есть таблица процессов LVS. Здесь вы можете увидеть множество «процессов-нянек». Они отвечают за проверку присутствия и работоспособности реальных серверов – по няньке на сервер. Их работа – периодически посылать простой запрос HTTP GET и проверять ответ. Внимательно рассмотрев опции -s и -x для няньки, вы распознаете посылаемые и ожидаемые строки, используемые для теста. (Вы можете задать эти строки, как вам нравится, используя страницу Virtual Servers > Monitoring Scripts Piranha.)

Просмотрев журнал доступа Apache на реальном сервере, вы увидите, что эти запросы выполняются каждые шесть секунд. Если нянька обнаружит, что ее сервер замолк, она вызовет ipvsadm для удаления записи о машине из таблицы маршрутизации LVS, и активный маршрутизатор не сможет пересылать запросы на эту машину. Нянька будет продолжать опрашивать сервер, и если он восстановится, она снова запустит ipvsadm для восстановления записи маршрутизации.

Вы можете наблюдать такое поведение, отключив сетевой кабель от реального сервера (или просто остановив демон httpd) и изучив таблицу маршрутизации LVS: окажется, что запись о вашем покойном сервере исчезла. Подключите сетевой кабель или перезапустите сервер, и запись возникнет снова. Будьте терпеливы: прежде чем эти изменения проявятся, может пройти 20 секунд, а то и больше.

Развязка

Если все в порядке, пора заняться клиентской машиной (под номером 1 на первом рисунке) и попробовать получить доступ к странице из браузера. В нашем примере, вы должны обратиться к http://192.168.0.41/proverbs.html и увидеть страницу с пословицей, хранящуюся на одном из ваших реальных серверов. Обновившись, вы увидите страницу с другой пословицей со следующего сервера в циклическом порядке. Можете также проверить поведение циклического распределения, изучив журнал доступа Apache на каждом реальном сервере. (Вглядевшись в записи журнала, вы увидите, что доступ был с 192.168.0.2, а няня запрашивала состояние с 10.0.0.1.) Если все заработало, поздравляю! Вы только что построили свой первый сбалансированный по нагрузке Linux-кластер.

Постскриптум

Давайте сделаем паузу и выясним, что мы изучили на двух наших уроках. Мы увидели, как построить отказоустойчивое кластерное решение, добавляющее лишнюю девятку к коэффициенту доступности вашего сервиса (например, с доступности 99.9% до 99.99%); и увидели, как построить сбалансированный по нагрузке кластер, превышающий по производительности индивидуальный web-сервер. В обоих случаях мы использовали свободное, открытое ПО, запускаемое на свободной открытой ОС. Иногда я представляю, что именно об этом думает Стив Балмер на сон грядущий; и всякий раз мне чертовски приятно. LXF

Если он не работает... (врезка)

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

Это, конечно, не конструктивная мера, хотя бы вы и почувствовали себя лучше. И Microsoft обвинять не за что, потому что мы не пользуемся никаким ее программным обеспечением. Второй вариант – сделать несколько глубоких вдохов, успокоиться и провести серию диагностических тестов.

Первым делом неплохо проверить соединение с LVS-машиной, используя старый добрый ping. Сперва убедитесь, что пингуется ваша тестовая машина (192.168.0.2). Затем проверьте доступность обоих реальных серверов (10.0.0.2 и 10.0.0.3). Если это не работает, запустите ifconfig -a и убедитесь, что eth0 имеет IP-адрес 192.168.0.41, а eth1 – 10.0.0.1.

Также запустите route -n для проверки таблицы маршрутизации – убедитесь, что вы имеете маршруты к сетям 192.168.0.0 и 10.0.0.0 через соответствующие интерфейсы.

Если ваши реальные серверы пингуются, запустите web-браузер на LVS-машине (исходя из того, что браузер установлен – вообще-то он там ни к чему). Убедитесь, что вы можете открыть URL http://10.0.0.2 и http://10.0.0.3 и видите содержимое web-страниц, хранящихся на этих серверах. (Если машины пингуются, но web-сервера недоступны, убедитесь, что они запущены на реальных серверах и эти сервера не имеют правил брандмауэра, запрещающих к ним доступ.)

Нужно также внимательно проверить таблицу маршрутизации LVS, отображаемую на странице Control/Monitoring в Piranha, и убедиться, что ваши реальные сервера там показаны. Если у вас опять ничего не вышло, проверьте, включена ли на LVS-машине маршрутизация IP-пакетов (IP-forwarding) – например, командой

 # cat /proc/sys/net/ipv4/ip_forward

Если она вернет 1, то все прекрасно, а если 0, включайте функцию командой:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Вы можете также проверить, настроено ли ваше ядро для работы с LVS. Если ваш дистрибутив содержит копию файла конфигурации, использованного при сборке ядра (с именем /boot/config-так-или-сяк), примените grep для поиска строки CONFIG_IP_VS и убедитесь, что вы видите CONFIG_IP_VS=m среди прочих. Вы также можете попробовать

# lsmod | grep vs

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

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