Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ

Учреждение образования

«Гомельский государственный университет имени Франциска Скорины»

Пояснительная записка

Построение высоко доступного WEB кластера на базе GNU/LINUX

Исполнитель:

Глушак Е.С.

Научный руководитель:

Ковалев А.А.

Гомель 2019



Содержание

Введение

1. Кластер сервер

1.1 Описание, возможностей и модели кластер серверов

1.2 Виды кластер серверов

2. Разработка web кластера

2.1 Схема и модель работы web

2.2 Описание программных средств, используемых для построение кластера

3. Построение web кластера

3.1 Установка и настройка директоров LVS

3.2 Настройка Heartbeat на директорах

3.3 Создание правил LVS с помощью команды ipvsadm

3.4 Установка и настройка mon на директорах LVS

Заключение



Введение

Кластер -- группа компьютеров, объединённых высокоскоростными каналами связи и представляющая с точки зрения пользователя единый аппаратный ресурс[1].

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

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

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

Цель:

Разработать проект оптимального и работоспособного web кластера на основании требований заказчика.

Задачи:

- выполнить анализ предметной области;

- выполнить построение логической и физической моделей кластера;

- реализовать спроектированный кластер;

- оформить пояснительную записку.



1. Кластер сервер

1.1 Описание, возможностей и модели кластер серверов

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

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

Один из первых архитекторов кластерной технологии Грегори Пфистер дал кластеру следующее определение: «Кластер - это разновидность параллельной или распределённой системы, которая: состоит из нескольких связанных между собой компьютеров; используется как единый, унифицированный компьютерный ресурс».

Возможностями при использовании кластерами серверов являются:

- управлять произвольным количеством аппаратных средств с помощью одного программного модуля;

- добавлять и усовершенствовать программные и аппаратные ресурсы, без остановки системы и масштабных архитектурных преобразований;

- обеспечивать бесперебойную работу системы, при выходе из строя одного или нескольких серверов;

- синхронизировать данные между серверами - единицами кластера;

- эффективно распределять клиентские запросы по серверам;

- использовать общую базу данных кластера.

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

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

Принято считать, что кластеры серверов делятся на две модели:

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

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

В обоих случаях, существуют определенные и вполне эффективные инструменты для решения проблем, поэтому выбор конкретной модели кластера неограничен ничем, кроме требований к архитектуре системы[2].

1.2 Виды кластер серверов

Различают следующие основные виды кластеров[3]:

- отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности);

- кластеры с балансировкой нагрузки (Load balancing clusters);

- вычислительные кластеры (High performance computing clusters, HPC);

- системы распределенных вычислений.

Отказоустойчивые кластеры

Несомненно, основной характеристикой в кластере является отказоустойчивость. Это подтверждает и опрос пользователей: 95% опрошенных ответили, что в кластерах им необходимы надежность и отказоустойчивость. Однако не следует смешивать эти два понятия. Под отказоустойчивостью понимается доступность тех или иных функций в случае сбоя, другими словами, это резервирование функций и распределение нагрузки. А под надежностью понимается набор средств обеспечения защиты от сбоев.

Приемлемой цифрой для отказоустойчивости становится 99,999%, что эквивалентно 5 минутам в год. Таких показателей позволяет достичь сама архитектура кластера. Тесное взаимодействие серверов, образующих кластер (узлов кластера), гарантирует максимальную производительность и минимальное время простоя приложений за счет того, что:

- в случае сбоя программного обеспечения на одном узле приложение продолжает функционировать (либо автоматически перезапускается) на других узлах кластера;

- сбой или отказ узла (или узлов) кластера по любой причине (включая ошибки персонала) не означает выхода из строя кластера в целом;

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

Возможные простои, которые не в состоянии предотвратить обычные системы, в кластере оборачиваются либо некоторым снижением производительности (если узлы выключаются из работы), либо существенным сокращением (приложения недоступны только на короткий промежуток времени, необходимый для переключения на другой узел), что позволяет обеспечить уровень готовности в 99,99%.

Масштабируемость

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

Большинство компьютерных систем допускают несколько способов повышения их производительности: добавление памяти, увеличение числа процессоров в многопроцессорных системах или добавление новых адаптеров или дисков. Такое масштабирование называется вертикальным и позволяет временно улучшить производительность системы. Однако в системе будет установлено максимальное поддерживаемое количество памяти, процессоров или дисков, системные ресурсы будут исчерпаны. И пользователь столкнется с той же проблемой улучшения характеристик компьютерной системы, что и ранее.

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

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

В качестве варианта горизонтального масштабирования стоит также отметить использование группы компьютеров, соединенных через коммутатор, распределяющий нагрузку (технология Load Balancing). Такие решения находят основное применение на Web-узлах с высоким трафиком, где один сервер не справляется с обработкой всех поступающих запросов. Возможность распределения нагрузки между серверными узлами такой системы позволяет создавать на многих серверах единый Web-узел.

Вычислительные кластеры

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

Как показывает практика, построить такую систему довольно просто. Все, что для этого нужно, это высокопроизводительный коммутатор и несколько подсоединенных к нему рабочих станций (серверов) с установленной операционной системой Linux. Однако этого недостаточно. Для того чтобы эта система ожила, необходимо специальное программное обеспечение для параллельных вычислений. Наиболее распространенным интерфейсом параллельного программирования в модели передачи сообщений является MPI (Message Passing Interface).

Название «Интерфейс передачи сообщений» говорит само за себя. Это хорошо стандартизованный механизм для построения параллельных программ в модели обмена сообщениями. Существуют бесплатные и коммерческие реализации почти для всех суперкомпьютерных платформ, а также для сетей рабочих станций UNIX и Windows NT.



2. Разработка web кластера

2.1 Схема и модель работы web

Рассмотрим работу web кластера на примере реализации системы с применением Linux Virtual Server (далее LVS) и компонентов linux-ha.org, который показан на рисунке 2.1.

Рисунок 2.1 - Linux Virtual Servers и Apache

Как можно увидеть на рисунке 2.1, внешние клиенты отправляют трафик на единый адрес IP, который может существовать на любой машине директора LVS. Машины директора выполняют активный мониторинг пула Web-серверов, по которым они распределяют работу.

Следует обратить внимание, что рабочая нагрузка движется с левой стороны рисунка 2.1 на правую сторону. Плавающий адрес этого кластера в любой заданный момент времени принадлежать одному из экземпляров директора LVS. Адрес сервиса можно менять вручную посредством графической конфигурационной утилиты или он может изменяться автоматически, в зависимости от состояния директоров LVS. Если какой-либо из директоров становится неработоспособным (вследствие потери соединения, сбоя программного обеспечения и т.п.), адрес сервиса автоматически назначается доступному директору.

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

LVS-NAT работает на сервере директора, перехватывая входящие пакеты, адресованные на указанные в конфигурации порты, и динамически заменяя адрес назначения в заголовке пакета. Директор не обрабатывает данные, содержащиеся в самих пакетах, направляя их вместо этого на реальные серверы. Адрес назначения в пакетах заменяется адресом заданного реального сервера из кластера. После этого пакет передаётся в сеть для доставки на реальный сервер; при этом реальный сервер не видит, что что-то произошло. С точки зрения реального сервера он просто получает запрос напрямую из внешнего мира. После этого ответы реального сервера отправляются директору, где они снова переписываются так, что в качестве адреса отправителя устанавливается плавающий IP-адрес, указанный клиентом, и отправляются исходному клиенту.

Использование подхода LVS-NAT требует наличия на реальных серверах базовой функциональности TCP/IP. В других режимах работы LVS, а именно, в LVS-DR и LVS-Tun, требуются более сложные сетевые подходы. Основное преимущество выбора LVS-NAT состоит в том, что для настройки реальных серверов требуется минимум изменений конфигурации.

2.2 Описание программных средств, используемых для построение кластера

Linux Virtual Server (LVS) - это набор интегрированных программных компонентов для распределения нагрузки между несколькими реальными серверами. LVS работает на двух одинаково настроенных компьютерах: один из них является активным LVS-маршрутизатором, а второй- резервным LVS-маршрутизатором. Активный LVS-маршрутизатор выполняет две задачи:

- распределение нагрузки между реальными серверами;

- проверка работоспособности сервисов на каждом реальном сервере[4].

Heartbeat - это программа с открытым исходным кодом, которая предоставляет возможности кластерной инфраструктуры и обмен сообщениями для клиентских серверов. Эти функции являются критическими в инфраструктуре сервера высокой доступности (НА)[5].

Mon -- это инструмент для мониторинга доступности услуг. Услуги могут быть связаны с сетью, условиями окружающей среды или чем-либо, что может быть протестировано с помощью программного обеспечения. Если услуга недоступна, mon может рассказать пользователю с помощью syslog, электронной почты, пейджера или сценария по выбору. Можно контролировать, кто получает каждое оповещение в зависимости от времени дня или дня недели, и вы можете контролировать, как часто повторно возникает проблема с существующей проблемой[6].

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

Сами директоры LVS должны иметь возможность передавать ресурсы (в частности, виртуальный адрес IP, по которому они принимают входящий трафик) друг другу, чтобы они не стали единичной точкой отказа. Директоры LVS выполняют передачу адреса IP с помощью компонента Heartbeat в составе LVS. Это позволяет каждому директору, на котором работает Heartbeat, гарантировать, что один и только один директор отвечает за обслуживание входящих запросов на обслуживание на адрес IP.

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

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

В этом проекте на всех реальных серверах работает Web-сервер Apache.



3. Построение web кластера

3.1 Установка и настройка директоров LVS

Работа с LVS на кластере была организована посредством установки SUSE Linux Enterprise Server 12 для каждого из директоров LVS, показанной на рисунке 3.1. В ходе установки SUSE Linux Enterprise Server 12 так же устанавливаются пакеты высокой готовности, относящиеся к heartbeat, ipvsadm и mon, посредствам выбора соответствующих опций[7].

Рисунок 3.1 - Установка SUSE Linux Enterprise Server 12

После была проведена установка на сервер пакетов ipvsadm, Heartbeat и mon из инструмента управления пакетами. Далее Heartbeat будет использоваться для связи между директорами, а mon - каждым директором для получения информации о состоянии реальных серверов.



3.2 Настройка Heartbeat на директорах

Настройка Heartbeat производится посредством внесения изменений в конфигурационный файл ha.cf. Содержание конфигурационного файла представлено на рисунке 3.2.

Рисунок 3.2 - Содержание ha.cf

Для указания запускаемой и контролируемой программы используется директива respawn. Если программа завершает свою работу с кодом, отличным от 100, она будет автоматически запущена снова. В качестве первого параметра используется идентификатор пользователя, под которым будет запускаться программа, а в качестве второго - программа, которую нужно запускать. Параметр -m устанавливает атрибуту pingd значение, равное умноженному на 100 числу узлов, доступных для ping с текущей машины, а параметр -d определяет задержку в 5 секунд перед изменением атрибута pingd в CIB (Cluster Information Base).

Этот файл идентичен на всех директорах. В файле устанавливаются права доступа такие, чтобы его смог прочитать демон hacluster. Если этого не сделать, в файл журнала будет выдана масса предупреждений.

Файл haresources указывает название узла и сетевую информацию (плавающий IP, соответствующий интерфейс и широковещательная рассылка сообщений). В данном случае оставим файл без изменений.

Содержимое haresources представлен на рисунке 3.3.

Рисунок 3.3 - Содержимое файла haresources

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

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

Пример содержимого authkeys файла представлен на рисунке 3.4.

Рисунок 3.4 - Содержимое файла authkeys

По завершению настройки heartbeat был добавлен в автозапуск при загрузке системы на каждом директоре.

На рисунке 3.5 показано, как выглядит графическая консоль после входа в систему, на ней показаны управляемые ресурсы и связанные с ними параметры.



Рисунок 3.5 - Графическая утилита конфигурации процесса heartbeat, hb_gui

3.3 Создание правил LVS с помощью команды ipvsadm

Поскольку LVS должен быть прозрачным для клиентов удалённых браузеров, все запросы должны направляться через директоры и передаваться одному из реальных серверов. После этого все необходимые результаты возвращаются директорам, которые направляют ответ клиенту, инициировавшему запрос Web-страницы.

Чтобы организовать такой поток запросов и ответов, для начала нужно настроить все директоры LVS, включив на них пересылку пакетов IP (таким образом разрешив передачу запросов на реальные серверы), выполнением команд, показанных на рисунке 3.6.

Рисунок 3.6 - Включение пересылки пакетов на директорах

Далее необходимо зафиксировать последние настройки посредством добавление строки 'IP_FORWARD="yes" 'в файл /etc/sysconfig/sysctl.

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

При получении запроса от клиента директор назначает клиенту реальный сервер на основе "графика"; режим составления этого графика устанавливается с помощью команды ipvsadm. Доступны следующие режимы[8]:

- Круговое обслуживание (RR): Новые входящие соединения будут назначаться каждому реальному серверу по очереди.

- Взвешенное круговое обслуживание (WRR): Режим RR с дополнительным весовым коэффициентом, компенсирующим различие мощностей реальных серверов, таких как процессоров, памяти и т.п.

- По наименьшему числу соединений (LC): Новые соединения передаются к реальному серверу с минимальным числом соединений. Это не обязательно менее загруженный сервер, но это шаг именно в этом направлении. вычислительный кластер программный команда

- По наименьшему числу соединений с весовыми коэффициентами (WLC): Режим LC с взвешиванием.

Для целей тестирования разумно использовать график RR, поскольку его легко проверить.

Далее для того, чтобы получить трафик от реальных серверов и выполнить обратную обработку перед возвращением ответа клиенту, отправившему запрос, необходимо изменить ряд сетевых настроек директоров. Это необходимо вследствие реализации директоров LVS и реальных серверов в плоской сетевой топологии (имеется в виду, что все они находятся в одной подсети). Для того чтобы направить трафик ответа Apache через директоры, а не напрямую, нам нужно выполнить действия, представленные на рисунке 3.7.



Рисунок 3.7 - Настройка направления трафика ответа через директоров

Это было сделано для того, чтобы не допустить попытки активного директора LVS установить короткий путь TCP/IP напрямую между реальным сервером и плавающим IP сервиса (поскольку они находятся в одной подсети). Обычно используется переадресация, поскольку она повышает производительность путём отбрасывания ненужных посредников сетевых соединений. Но в этом случае не получится выполнить исправление пакетов в исходящем трафике, как это необходимо для обеспечения прозрачности для клиента.

3.4 Установка и настройка mon на директорах LVS

Выше был установлен IP-адрес сервиса высокой готовности и связан с пулом экземпляров реальных серверов. Однако никогда не стоит доверять работоспособности отдельного сервера Apache в произвольный момент времени. Если в режиме RR какой-либо из реальных серверов отключается или не отвечает своевременно на сетевой трафик, каждый шестой запрос HTTP будет приводить к отказу.

Поэтому необходимо реализовать мониторинг реальных серверов на каждом директоре LVS, чтобы динамически добавлять их в рабочий пул и удалять их из него. Для этой цели отлично подходит ещё один хорошо известный пакет с открытым исходным кодом под названием mon.

Решение mon обычно используется для мониторинга реальных узлов LVS. Mon относительно прост в настройке и очень хорошо расширяем для людей, знакомых с написанием сценариев командного процессора. Для организации работы требуется выполнить три основных шага: установка, настройка службы мониторинга и создание уведомлений.

Установка mon происходит с помощью инструмента управления пакетами. По завершении установки остаётся только скорректировать конфигурацию мониторинга и создать несколько сценариев предупреждения. Сценарии предупреждения срабатывают в случаях, когда мониторы определяют отключение или включение реального сервера.

По умолчанию mon поставляется с несколькими готовыми к использованию механизмами. Для данного кластера необходимо изменить файла конфигурации /etc/mon.cf на использование службы HTTP.

SLES12 является 64-разрядной версией Linux, а пример конфигурации, входящий в комплект поставки, был создан для систем по умолчанию (31- или 32-разрядных). В файле конфигурации предполагалось, что предупреждения и мониторы находятся в папке /usr/lib, что неверно для нашей конкретной системы. Поэтому следует изменить соответствующие параметры, изменение показаны на рисунке 3.8.

Рисунок 3.8 - Изменение путей к файлам мониторинга mom

Следующее изменение файла конфигурации состоит в указании перечня контролируемых реальных серверов. Это делается посредством директив, представленных на рисунке 3.9.

Рисунок 3.9 - Указание перечня реально контролируемых серверов



После того как все определения будут сделаны, нужно сообщить mon, каким образом будет обнаруживаться сбой и что делать в случае сбоя. Для этого следует добавить следующие секции мониторов (по одной для каждого реального сервера). После этого нужно разместить файлы конфигурации mon и предупреждения на каждый узел LVS heartbeat, включив на каждом узле heartbeat независимый мониторинг всех реальных серверов.

На рисунке 3.10, 3.11, 3.12 представлено содержимое файла mon.cf[9].

Рисунок 3.10 - Содержимое файла mon.cf



Рисунок 3.11 - Содержимое файла mon.cf

Рисунок 3.12 - Содержимое файла mon.cf

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

В строках alert и upalert вызываются сценарии, которые должны быть размещены в папку alertdir, указанную в начале файла конфигурации. Как правило, в качестве директории используется какая-либо из директорий по умолчанию дистрибутива, например "/usr/lib64/mon/alert.d", которая и была использована. Предупреждения сообщают LVS о необходимости добавления и удаления серверов Apache из списка доступных.

Когда один из реальных серверов не проходит тест http, mon автоматически выполняет команду dowem.down.alert с несколькими аргументами. И наоборот, когда мониторы определяют, что реальный сервер включился, процесс mon автоматически выполняет dowem.up.alert с несколькими аргументами. Можно изменять названия сценариев предупреждений в соответствии с потребностями системы.

На рисунке 3.13 и 3.14 показан пример создание простого сценария в папке alertdir при помощи простого сценария bash[10].

Рисунок 3.13 - Пример предупреждения: появилось соединение



Рисунок 3.14 - Пример предупреждения: потеря соединения

Оба этих сценария используют инструмент командной строки ipvsadm для динамического добавления и удаления реальных серверов из таблиц LVS.



Заключение

В результате выполнения курсового проекта было построен высоко доступный web кластер на базе GNU/Linux. В проекте использовались такие средства как Linux Virtual Server, Heartbeat, mon, ipvsadm. Была произведена балансировка нагрузки IP, настройка обработки web и SSL запросов на плавающий IP-адрес сервера, создание автоматически обрабатываемых базовых сценариев, подготовлена среда для дальнейшего конфигурирования и эксплуатации серверного web кластера.

Результатом выполнения курсовой работы стал кластер серверов, предоставляющий функционал для поддержания непрерывной работы web сайта и его высокой доступности для пользователя.

Размещено на Allbest.ru

...