Шаг 6. Обеспечение доступности

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

Рассмотрим случай развертки системы на следующей инфраструктуре.

Распределение известных на этом шаге ролей может, например, выглядеть следующим образом:

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

Два сервера на одном сайте – это самая малая инфраструктура, на которой возможно обеспечить доступность через резервирование всех ролей. Поэтому альтернативные способы распределения ролей в приведенном примере сводятся к перемене последовательностей резервирования или частичного отказа от резервирования. То есть альтернатив нет.

При полной доступности серверов и связи любой экземпляр WS является полнофункциональной точкой доступа к API – это резервирование типа Active-Active, на схеме экземпляры ролей отображены одинаковым цветом. DC и MIC резервируются иначе – активен только один экземпляр роли на сайте, а второй активируется в тот момент, когда первый вдруг оказывается недоступен – это резервирование типа Active-Passive (альтернативное понятие – перетекание роли, связанные термины FailOver и TakeOver), на схеме активный и пассивный (резервный) экземпляры отображены разным цветом.

Все роли системы резервируются по одному из вышеописанных принципов (Active-Active или Active-Passive). И в том, и в другом случае резервирования может быть 2,3,10 и сколько угодно серверов с одной и той же ролью, но если для Active-Active это имеет смысл в части равномерного распределения нагрузки, то для ролей Active-Passive вряд ли целесообразно иметь более 3 резервных серверов под одну и ту же роль, если только не решается задача обеспечения доступности при одновременной выпадении 3 произвольных серверов.