`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Что для вас является метрикой простоя серверной инфраструктуры?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Пример построения отказоустойчивого кластера

+33
голоса

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

И проблемы могут возникать в разных областях. Если они возникли с каналом провайдера, то весь трафик направляется по работоспособному каналу второго, резервного, провайдера. Если сбой произошел в ВМ, то трафик к такой ВМ блокируется, и для его возобновления необходимо вмешательство оператора. При проблемах в работе ЦОД или облака инфраструктура в них блокируется, и для возобновления работы необходимо частичное вмешательство администратора сервиса. Может случиться, что в одном из узлов недостаточно ресурсов, тогда трафик к ВМ будет уменьшаться до уровня, при котором данная ВМ начнет работать в штатном режиме. При сбое целого узла администратор может временно вывести его в режим технического обслуживания, при этом работа всей системы не останавливается.

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

Было принято решение осуществить переход в три этапа, каждый из которых описывается ниже.

Этап 1. Создание балансировки на уровне сети

Для балансировки использовался сервис HAProxy на серверах балансировки, находящихся в разных ЦОД, а над ними – сервис CloudFlare с балансировкой по DNS и проверкой по порту. Связь между серверами балансировки и остальными сервисами клиента обеспечивалась одним растянутым L2-доменом.

Пример построения отказоустойчивого кластера

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

Для каждого сервера балансировки понадобиться 2 ГБ дискового пространства, 256 МБ оперативной памяти и 4 процессора (будут использоваться только в пиках нагрузки).

Этап 2. Резервирование и балансировка веб-серверов
   
Для резервирования веб-сервера использовался сервер синхронизации lsyncd в режиме source—destination. Для включения данного режима нужно будет поочередно перезапустить каждый веб-сервер из кластера.

 

Пример построения отказоустойчивого кластера

 

При резервировании на уровне веб-сервера нагрузка может быть распределена между серверами. Соответственно для построения данной схемы понадобиться дополнительно 100% дискового пространства, ресурсы оперативной памяти и процессора распределяются между площадками поровну в размере 60-70% от существующей.

Пример построения отказоустойчивого кластера

Общая схема кластера

Этап 3. Резервирование и балансировка БД

Из полученных данных соотношения операций записи и чтения составляют 20 к 100 при общем уровне 75 операций записи-обновлений в секунду.

 

Пример построения отказоустойчивого кластера

Входная информация о БД

При условии, что задержка сети между двумя серверами базы данных будет составлять меньше 1 мс, можно будет использовать архитектуру master—master (серверы смогут гарантировано обработать более 1000 запросов «запись+обновление» в секунду).

 

Пример построения отказоустойчивого кластера

В случае архитектуры master—slave не может быть гарантирована как беспрерывность доступа (так как при недоступности основного сервера нужно время на ручную или автоматическую операцию назначения нового основного сервера), так и полная сохранность данных (в случае краха основного сервера все не реплицированные данные на ведомые сервера будут потеряны).

Для архитектуры master—master существуют готовые решения. Это можно реализовать над серверами Percona XtraDB или MariaDB Galera. У обоих вариантов решения есть свои плюсы и минусы.

Percona XtraDB - это сборка MySQL с включенным по умолчанию XtraDB storage engine. Отличается от MySQL+InnoDB plugin лучшей производительностью/масштабируемостью, особенно на современных многоядерных серверах. Собирается в вариантах, базирующихся на MySQL 5.0 и 5.1. Полностью совместима с таблицами innodb, то есть без проблем поддерживается конвертация innodb - xtradb и обратно (если не использовать некоторые специфичные для xtradb функции типа меньшего размера страницы).

Прирост производительности заметен только при уровне запросов больше 1000 на запись. Но данная конфигурация менее стабильно работает в случае сбоев в работе узлов или потери связи между узлами.

Для реализации понадобиться дополнительно 100% дискового пространства (под базу), ресурсы оперативной памяти и процессора распределяются между площадками поровну в размере 60-70% от существующей.

Преимуществом сервиса MariaDB Galera является стабильность и надежность работы, повышенная устойчивость и сохранение целостности данных после краха при полной совместимости с MyISAM. 

По остальным характеристикам данные сервисы являются аналогичными.

Было предложено построить решение, используя MariaDB Galera, так как при данном уровне запросов на запись и изменения разницы в скорости работы базы данных не будет, но можно будет получить более надежную систему. Запас масштабируемости есть, поскольку для достижения 1000 запросов в секунду можно увеличить нагрузку в 130 (!) раз.

Балансировка трафика, поступающего на серверы БД

Для балансировки предлагается использовать универсальный балансировщик трафика HAPRoxy с дополнительной настройкой для проверки состояния DB. Этот сервис устанавливается и запускается на веб-серверах, а не на отдельных виртуальных машинах.

Пример построения отказоустойчивого кластера

Схема подключения виртуальных машин

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

 

Пример построения отказоустойчивого кластера

Для максимальной сохранности информации резервирование можно делать на каждом узле независимо.

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

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

Пример построения отказоустойчивого кластера

Общая схема взаимодействия модулей

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

 

+33
голоса

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT