Высокодоступная архитектура игрового сервиса: доступность 24/7/365

Продолжаем работать над задачей построения высокодоступной архитектуры для игрового сервиса, состоящего из серверов приложений (java), веб-сервера (сайт, форум), баз данных (MySQL, Postgree).

В прошлый раз была решена задача обеспечения катастрофоустойчивости на случай выхода ЦОДа из строя http://arsen-borovinskiy.blogspot.ru/2013/10/blog-post.html

Теперь надо обеспечить доступность 24/7/365.

Ну, первым делом надо оставить предыдущее решение из трех ЦОДов и обеспечить:

1) Предупреждение аварийных ситуаций.
2) Резервное копирование.
3) Быстрое реагирование на аварийную ситуацию.

Более подробно о схеме написано в посте.

Предупреждение аварийных ситуаций

В целях упрощения процедуры управления системой, снижения последствий человеческой ошибки и возможности быстрого отката сделанных изменений все сервера должны работать в виде виртуальных машин на хостах VMware ESX под управлением VMware vSphere (как наиболее развитой системы виртуализации).

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

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

Создание внутри каждого ЦОДа кластера высокой доступности средствами VMware High Availability (требуется общая система хранения образов виртуальных машин не менее чем из двух дисковых массивов и не менее двух серверов в качестве хостов).

Использование не менее двух хостов и не менее чем двух дисковых массивов позволяет выводить оборудование в техническое обслуживание не останавливая сервисы (мигрируя виртуальные машины с помощью VMware VMotion).

Аппаратная архитектура из двух хостов с развернутым VMware ESX хранящим диски виртуальных машин на двух дисковых массивах и работающих в режиме High Availability. Между собой хосты общаются через коммутатор. Балансировка нагрузки на сервера приложений и веб-сервера осуществляется балансировщиком нагрузки, на который подается трафик из интернета. Система мониторится отдельным физическим сервером с подключенным к нему напрямую GSM-шлюзом. При большем количестве хостов может понадобиться FiberChannel-коммутатор. Также можно рассмотреть вариант построения системы хранения на NFS-серверах.

Резервное копирование

Необходимо осуществлять ежесуточное резервное копирования виртуальных машин (подойдет Veeam backup) с глубиной хранения до 14 дней. Резервное копирование настраивается в каждом ЦОДе отдельно для экономии интернет-трафика. Дополнительно необходимо осуществлять резервное копирование с глубиной хранения 3 месяца и частотой 14 дней.

Реагирование на аварийную ситуацию

В каждом ЦОДе должен осуществляться мониторинг "здоровья" системы и рассылка SMS-уведомлений о критических сбоях через установленные в ЦОДах собственные GSM-шлюзы и на e-mail.

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

Загрузка ресурсов ЦОДов

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

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

Итоговая схема

Катастрофаустойчивость все еще организована master-slave репликацией из активного ЦОДа в резервный, как указано в статье.

P.S. При желании в ЦОДе еще есть что зарезервировать и, хотя, в бюджете меня никто не ограничивал, надо где-то остановиться :)