Архитектура катастрофоустойчивого сервиса
Продолжаю выполнять ТЗ.
Задача: предложить высокодоступную архитектуру игрового приложения на случай отказа ЦОДа. Приложение использует игровые сервера на Java и БД MySQL и Postgree. Имеется веб-сервер с которого осуществляется вход на сайт. Обеспечить отказоустойчивость или высокую доступность на уровне логики самого приложения нет возможности.
Высокая доступность при выходе из строя ЦОДа может быть обеспечена только путем размещения приложения в двух разных, географически-разнесенных ЦОДах. Желательно, чтобы эти ЦОДы принадлежали разным компаниям.
Обеспечить работу на одном 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 между ЦОДами, что очень затратно и коммерческие ЦОДы, скорее всего, такой услуги не предоставляют. Вариант стоит рассматривать если основной и резервный ЦОДы принадлежат самой организации.
2: Использование программного или аппаратного балансировщика нагрузки, на который вешаются игровые сервера и который балансирует трафик между ЦОДами. Плохо тем, что балансировщик становится единой точкой отказа.
3: Использование высокой доступности и Fault Tolerance системы виртуализации VMware HA Cluster. Система VMware Fault Tolerance позволяет иметь полную копию виртуальной машины при условии, что другая виртуальная машина работает на аналогичном оборудовании и имеет физический процессор из одной партии. При этом vCPU может быть только 1. Недостатка три: низкая производительность БД из-за одного vCPU, большя утилизация сети, требуется хранение дисков виртуальной машины на одной системе хранения (т.е. система хранения является единой точкой отказа).
В каждом ЦОДе установлен роутер, умеющий BGP.
За каждым роутером установлен балансировщик нагрузки (аппаратный или программный ipvs или haproxy), переключающий весь игровой трафик на сервера приложений активного ЦОДа.
БД в активном ЦОДе настроена на master-slave репликацию в резервный ЦОД.
Существует система мониторинга и управления состоянием системы, осуществляющая мониторинг работоспособности системы (например: pacemaker) и корректное переключение системы на резервный ЦОД.
При выходе из строя основного ЦОДа, система мониторинга должна поменять основной и резервный ЦОД ролями:
1) Отправить сигнал на отключение БД и серверов приложений в основном (активном) ЦОДе.
2) Создать задание для балансировщика нагрузки в основном ЦОДе на переключение игрового трафика в резервный ЦОД.
3) Запустить сервера приложений в резервном ЦОДе (если требуется уменьшить время простоя, сервера приложений можно держать запущенными в "горячем резерве").
4) Переключить балансировщик нагрузки в резервном ЦОДе на перенаправление всего трафика на сервера приложений в резервный ЦОД.
Теперь активный и резервный ЦОД поменялись ролями.
Пример 1: Можно представить ситуацию, когда в активном ЦОД1 происходит сетевой сбой на уровне провайдера и достучаться до своих серверов и роутера уже нельзя, но анонсы автономной системы из ЦОД1 по BGP все еще идут. В таком случае можно в обоих роутерах заранее добавить препенды и, в случае такого сбоя в ЦОД1, удалить препенды в ЦОД2, чтобы трафик перенаправить в него.
Пример 2: Падение одного сервера приложений еще не должно приводить к миграции работы в резервный ЦОД.
Пример 3: В момент сбоя из-за отставания реплики была потеряна часть транзакций. Соответственно, все критичные транзакции надо складывать в лог на отдельный сервер в ЦОД3. Если это невозможно, стоит рассмотреть вариант резервирования синхронной репликации на уровне блочного устройства (DRBD и подобные).
Читайте далее про доступность 24/7/365
Задача: предложить высокодоступную архитектуру игрового приложения на случай отказа ЦОДа. Приложение использует игровые сервера на 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
Комментарии
Отправить комментарий