Архитектура катастрофоустойчивого сервиса

Продолжаю выполнять ТЗ.

Задача: предложить высокодоступную архитектуру игрового приложения на случай отказа ЦОДа. Приложение использует игровые сервера на Java и БД MySQL и Postgree. Имеется веб-сервер с которого осуществляется вход на сайт. Обеспечить отказоустойчивость или высокую доступность на уровне логики самого приложения нет возможности.

Предисловие

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

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

Один ip-адрес в двух ЦОДах

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

Обеспечить работу на одном ip-адресе двух ЦОДов предлагаю покупкой своей автономной системы (AS) и предоставлением доступа к серверам в разных ЦОДах по одному ip-адресу. Для реализации требуется договориться с ЦОДами о подключении своего оборудования к сети ЦОДа по BGP.

При нормальной работе трафик будет приходить в оба ЦОДа одновременно. При падении одного ЦОДа от него перестанут приходить keepalive-сообщения и на него перестанет посылаться трафик из интернета (стоит договориться об уменьшении keepalive-интервала с аплинком).

Репликация базы данных

Вторым вопросом является то, каким образом обеспечить одинаковые данные в разных ЦОДах при падении одного из них. Есть несколько вариантов:

1) Master-master репликация БД в случае, если оба ЦОДа работают одновременно и трафик между ними балансируется. Однако, в виду отсутствия нормальной поддержки master-master репликации в MySQL, в данном случае я такой вариант не рекомендую к использованию.

2) Master-slave репликация БД. При этом один ЦОД является активным, а второй резервным и включается в работу только при выходе из строя основного ЦОДа. Этот вариант я рекомендую к использованию и ниже он будет описан более детально. Однако, запросы на запись в БД должны удовлетворять требованиям к репликации (например: не содержать RAND).

3) Репликация блочного устройства диска с файлами БД. Аналогично master-slave репликации, резервный сервер БД находится в выключенном состоянии, но файлы БД реплицируются на него с основного сервера. При падении основного ЦОДа, репликация останавливается, БД в резервном ЦОДе запускается и резервный ЦОД с основным меняются ролями. Для репликации может использоваться DRBD или другие платные аналоги. Недостатки: много трафика между ЦОДами. Стоит использовать, если не подходит вариант №2.

4) Репликация блочного устройства на уровне системы хранения данных. Аналогично варианту №3, некоторые системы хранения данных (например: IBM XIV), имеют возможность реплицировать все операции записи на другие системы хранения. Однако, обычно имеются ограничения на расстояние между ЦОДами (до 50 км) и может потребоваться проброс FiberChannel между ЦОДами, что очень затратно и коммерческие ЦОДы, скорее всего, такой услуги не предоставляют. Вариант стоит рассматривать если основной и резервный ЦОДы принадлежат самой организации.

Антипаттерны

1: Использование round-robin DNS для обеспечения балансировки подключения на сервера разного ЦОДа. Плохо тем, что при падении ЦОДа изменения в записях DNS будет весьма инерционным и не быстро отразится на клиентских компьютерах из-за кеширования ответов DNS-сервера. Т.е. round-robin DNS применяется для балансировки трафика, а не высокой доступности.

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

3: Использование высокой доступности и Fault Tolerance системы виртуализации VMware HA Cluster. Система VMware Fault Tolerance позволяет иметь полную копию виртуальной машины при условии, что другая виртуальная машина работает на аналогичном оборудовании и имеет физический процессор из одной партии. При этом vCPU может быть только 1. Недостатка три: низкая производительность БД из-за одного vCPU, большя утилизация сети, требуется хранение дисков виртуальной машины на одной системе хранения (т.е. система хранения является единой точкой отказа).

Рекомендуемое решение обеспечения высокой доступности

Есть активный и резервный ЦОДы.

В каждом ЦОДе установлен роутер, умеющий BGP.

За каждым роутером установлен балансировщик нагрузки (аппаратный или программный ipvs или haproxy), переключающий весь игровой трафик на сервера приложений активного ЦОДа.

БД в активном ЦОДе настроена на master-slave репликацию в резервный ЦОД.

Существует система мониторинга и управления состоянием системы, осуществляющая мониторинг работоспособности системы (например: pacemaker) и корректное переключение системы на резервный ЦОД.



При выходе из строя основного ЦОДа, система мониторинга должна поменять основной и резервный ЦОД ролями:
1) Отправить сигнал на отключение БД и серверов приложений в основном (активном) ЦОДе.
2) Создать задание для балансировщика нагрузки в основном ЦОДе на переключение игрового трафика в резервный ЦОД.
3) Запустить сервера приложений в резервном ЦОДе (если требуется уменьшить время простоя, сервера приложений можно держать запущенными в "горячем резерве").
4) Переключить балансировщик нагрузки в резервном ЦОДе на перенаправление всего трафика на сервера приложений в резервный ЦОД.
Теперь активный и резервный ЦОД поменялись ролями.


Восстановление системы.

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

Замечание по использованию третьего ЦОДа

Возможна ситуация, когда основной и резервный ЦОДы потеряют между собой связь, сохраняя внутри себя работоспособность. При этом произойдет split-brain в мониторинге состояния системы, так как монитор в обоих ЦОДах не сможет точно узнать кого делать активным, а кого выводить в резерв. В классических системах высокой доступности эта проблема решается путем общения обеих систем не только через сеть, но и через разделяемое дисковое устройство, подключенного по FiberChannel. В случае двух ЦОДов от такого способа надо отказаться в пользу определения "здоровья" системы только через интернет. Поэтому следует разместить еще один сервер в третьем ЦОДе, чтобы при решении у кого произошел сбой можно было собрать кворум.

Дополнительные замечания.

Вся система нуждается в аккуратном тестировании и проработки всех возможных сценариев аварийных ситуаций.

Пример 1: Можно представить ситуацию, когда в активном ЦОД1 происходит сетевой сбой на уровне провайдера и достучаться до своих серверов и роутера уже нельзя, но анонсы автономной системы из ЦОД1 по BGP все еще идут. В таком случае можно в обоих роутерах заранее добавить препенды и, в случае такого сбоя в ЦОД1, удалить препенды в ЦОД2, чтобы трафик перенаправить в него.

Пример 2: Падение одного сервера приложений еще не должно приводить к миграции работы в резервный ЦОД.

Пример 3: В момент сбоя из-за отставания реплики была потеряна часть транзакций. Соответственно, все критичные транзакции надо складывать в лог на отдельный сервер в ЦОД3. Если это невозможно, стоит рассмотреть вариант резервирования синхронной репликации на уровне блочного устройства (DRBD и подобные).

Читайте далее про доступность 24/7/365

Комментарии

Популярные сообщения из этого блога

Обзор почтового клиента Pronto Pro!

Подключаем ZFS over iSCSI на Oracle Linux 8 (CentOS) в Proxmox