32
современном рынке, за счет широкой распространенности архитектуры x86-
64. При этом высокая надежность функционирования веб-приложений уже
будет обеспечиваться на программном уровне, а общесистемная надежность
может быть дополнительно повышена за счет увеличения надежности
аппаратных средств. Повышение производительности будет достигаться
посредством параллельной обработки клиентских запросов на множестве
кластерных узлов.
33
Глава 3. Создание и тестирование макетного варианта программно-
аппаратного комплекса
Макетный вариант кластера было решено развернуть на двух
виртуальных машинах, обслуживаемых одним гипервизором. Это очень
удобно для проведения тестовых испытаний, но оказывает влияние на
результаты оценки производительности. Проблема состоит в том, что обеими
виртуальными машинами используются ресурсы одного и того же
аппаратного сервера. В производственных условиях такая конфигурация
вовсе недопустима, так как игнорируются идея резервирования на уровне
аппаратной платформы.
Рисунок 3.1. Схема стенда для проведения тестирования
3.1 Принципы работы кластера
Процесс функционирования кластера можно приблизительно описать
следующим образом. Отправленный по сети клиентский HTTP-запрос
принимается обратным прокси-сервером nginx. Nginx определяет, какие
данные могут быть отданы из кэша, а затем передает запрос дальше
балансировщику нагрузки HAProxy. При первом открытии соединения
34
клиенту будут отправлены заголовки Set-Cookie с идентификаторами
обслуживающего веб-сервера, выбранного при помощи алгоритма leastconn,
и PHP-сессии, если таковая устанавливается. Этим обеспечивается обработка
запросов определенного клиента одним и тем же веб-сервером. Общее
количество открываемых одновременно соединений с веб-серверами
ограничено, при этом запросы, приходящие сверх установленной границы,
будут выстроены в очередь. Это позволяет избежать перегрузки веб-
серверов, так как время их ответа напрямую зависит от количества
одновременно обрабатываемых запросов. Также было ограничено количество
открываемых одним и тем же клиентом соединений для защиты от
проведения DDOS-атак на кластер.
Получив запрос от HAProxy, веб-сервер Apache обращается к
директориям с веб-страницами и файлами приложения для формирования
ответа. Эти директории располагаются на реплицируемом томе, который
подключен ко всем узлам кластера и обслуживается GlusterFS. Данное
обстоятельство позволяет веб-серверам на разных узлах работать с одними и
теми же данными, а любые изменения, сделанные на одном из узлов, сразу
будут распространены на весь кластер. В зависимости от типа запрошенной
веб-страницы сервер либо сразу передает ответ по цепочке назад, либо
вызывает PHP-интерпретатор и отсылает ответ после завершения обработки.
При обработке скрипта, скорее всего, будет осуществлено обращение к базе
данных, которая, как и данные веб-приложения, реплицируется между
узлами кластера. Схема последовательности обработки клиентский запросов
отображена в приложении А.
Если произойдет отказ одного из обслуживающих серверов, то
основной балансировщик просто перенаправит поступающие запросы на
рабочие серверы. Кластер будет оставаться работоспособным, пока
функционирует хотя бы один обслуживающий сервер и один балансировщик.
35
Рисунок 3.1. Схема работы кластера при отказе сервера
Каждый балансировщик представляет собой связку из Keepalived,
HAProxy и nginx. Keepalived необходим балансировщикам для того, чтобы
контролировать работоспособность друг друга и брать на себя нагрузку в
случае отказа партнера. Контроль осуществляется посредством обмена
сообщениями, отсутствие которых в течение заданного временного
интервала сигнализирует об отказе партнера. Балансировщик является
критическим узлом в кластере, резервировать который необходимо в первую
очередь, так как его отказ сделает бесполезными все обслуживающие
серверы, как много бы их не было.
HAProxy, помимо всего прочего, еще применяется для защиты от
выхода из строя серверов баз данных. Пропуская через себя все запросы к
серверам баз данных, HAProxy следит за их доступностью, как и в случае с
веб-серверами. При отказе, соответственно, осуществляет перенаправление
запросов на рабочие серверы.
36
Рисунок 3.2. Схема работы кластера при отказе балансировщика
Автоматическое неблокирующее резервное копирование на удаленную
систему хранения данных было реализовано при помощи программ rsync и
Percona XtraDB Backup.
Для мониторинга состояния узлов могут быть использованы система
журналирования событий RSYSLOG и программное обеспечение Net-SNMP,
настроенные на отправку сообщений мониторинговому серверу.
3.2 Оценка надежности аппаратных средств
Точная оценка надежности аппаратно-программного комплекса в
целом невозможна по причине отсутствия статистических данных о
надежности программного обеспечения. Однако влияние программных
отказов на всю систему значительно меньше за счет избыточности узлов в
кластере.
При использовании только одного сервера высокая доступность не
может быть обеспечена ввиду того, что время недоступности в год только
лишь из-за ненадежности аппаратной части может превысить установленные
границы. Продемонстрировать это можно на математической модели,
построенной с помощью аппарата теории цепей Маркова. Сервер может
находиться в одном из двух состояний:
1. Состояние 0 – сервер работоспособен и может из этого состояния с
интенсивностью отказов λ перейти в состояние 1.
37
2. Состояние 1 – сервер неработоспособен и может из этого состояния с
интенсивностью восстановления µ перейти в состояние 0.
Рисунок 3.3. Модель надежности восстанавливаемого сервера
Данная модель описывается следующей системой уравнений
Колмогорова:
????????
????
????
????
????
????????
????
????
????
????
????
????
????
????
(3.1)
????
????
и
????
????
– вероятности нахождения сервера в работоспособном и
неработоспособном состояниях в момент времени . Аналитические
выражения для стационарного случая , когда производные
вероятностей по времени стремятся к нулю, выводятся достаточно просто.
????
????
????
????
????
(3.2)
Соответственно, коэффициент готовности сервера равен вероятности
нахождения в работоспособном состоянии:
????????
(3.3)
Для определения интенсивностей отказов и восстановления можно
воспользоваться следующими соотношениями:
[8, c. 8], (3.4)
[8, с. 147]. (3.5)
MTBF ‒ среднее время между возникновениями отказов.
MTTR ‒ среднее время, необходимое для восстановления нормальной работы
после возникновения отказа.
38
Как показывает опыт эксплуатации серверов в дата-центре компании
Google [29], вполне логично положить, что сервер промышленного класса в
течение года по причине аппаратных сбоев и проблем с инженерным
обеспечением откажет хотя бы один раз. Время его восстановления в
зависимости от обстоятельств может занимать до девяти часов. Тогда
коэффициент его готовности будет равен:
При наличии такого же коэффициента готовности у программного
обеспечения система не может считаться высокодоступной.
Теперь построим модель для кластера, состоящего из двух серверов,
причем восстановление серверов может производиться только
последовательно. Положим, что серверы в кластере обладают такими же
характеристиками надежности. Кластер может находиться в одном из пяти
состояний:
1. Состояние 00 – оба сервера работоспособны, кластер функционирует.
2. Состояние 01 – второй сервер неработоспособен, кластер
функционирует.
3. Состояние 10 – первый сервер неработоспособен, кластер
функционирует.
4. Состояние 11’ – кластер неработоспособен, приоритет
восстановления у второго сервера.
5. Состояние 1’1 – кластер неработоспособен, приоритет
восстановления у второго сервера.
39
Рисунок 3.4. Модель надежности кластера из двух серверов
Модель описывается следующей системой уравнений Колмогорова:
????????
????
????
????
????
????
????
????????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????
????????
????
????
????
????
????
????
????
????
????
????
????
????
(3.6)
Нахождение аналитического решения такой системы уравнений очень
затруднено. Так как все коэффициенты в системе определены, можно
воспользоваться методом Гаусса для нахождения вероятностей пребывания
во всех состояниях. Решение находится, как и ранее, для стационарного
случая . Решения СЛАУ отражено в приложении Б.
Коэффициент готовности можно определить через ненадежность:
????
????
????
????
????
????
0,999998.
Таким образом, расчеты показывают, что для обеспечения высокой
доступности обязательно применение резервирования функциональных
узлов.
3.3 Варианты масштабирования системы
Масштабирование кластера осуществляется достаточно просто за счет
того, что используемое программное обеспечение совместимо с
большинством аппаратных платформ, и каждый сервер может быть
40
обеспечен любым программным набором. Как уже упоминалось, число узлов
в отказоустойчивом кластере должно быть от двух и более. Для оптимизации
конфигурации необходимо отталкиваться от того, под какой нагрузкой
работает кластер. Возможно, что в одной ситуации хватит и двух узлов с
полным программным набором, а в другой придется увеличить число веб-
серверов вдвое и отдельно расположить серверы баз данных.
Рисунок 3.5. Конфигурация из двух аппаратных серверов
Рисунок 3.6. Конфигурация из семи аппаратных серверов
В случае распределения кластера по нескольким дата-центрам
требуется настройка защищенного соединения.
41
Рисунок 3.7. Конфигурация географически распределенной системы
3.4 Результаты нагрузочного тестирования
В ходе нагрузочного тестирования было обнаружено узкое место в
производительности системы – низкая скорость работы GlusterFS с малыми
по объему файлами. Некоторые веб-приложения требуют запуска PHP-
скриптов с множеством зависимостей, что значительно увеличивает время
ответа на запрос по сравнению с ожидаемым. Для минимизации влияния
данной проблемы пришлось использовать кеширующее программное
обеспечение – PHP-акселератор Zend OPcache и программу memcached,
которая кэширует данные в оперативной памяти. Для обеспечения
отказоустойчивости memcached-сервер был дублирован, а все поступающие к
нему запросы проходят через HAProxy.
Тестирование надежности показало, что кластер функционирует, как и
предполагалось. При отключении питания на одном из узлов, другой
продолжает обрабатывать запросы и веб-приложения остаются доступными
для клиентов. После восстановления питания “отказавший” узел
автоматически выполнил инициализацию и вернулся в состав кластера.
После отключения питания на обоих узлах и последующего его