Генеральному директору легко требовать нулевого простоя. Хотя такое возможно, это очень дорого и очень сложно, особенно если в инфраструктуре существуют компоненты, которые нельзя запустить в нескольких экземплярах. Яркий пример – обычная база данных: в большинстве организаций таблицы не спроектированы для легкой реализации резервирования в реальном времени (если вы полагаетесь на сгенерированные базой данных автоинкрементные первичные ключи, а не на GUID, то вам придется несладко). Старые системы или плохая архитектура просто не позволяют иметь дублирующую систему, на которую можно быстро переключиться.

При использовании для вашей системы двух географически разнесенных зон сложность (и стоимость) решения для аварийного восстановления будут определять два фактора:

• Технология синхронизации данных в обеих зонах.

• Способ перенаправления трафика (пользователей) на новую основную зону.

Синхронизация данных между двумя разнесенными в пространстве зонами требует времени – буквально. Для передачи данных по сети требуется время, и даже небольшая задержка в 50–100 мс может иметь огромное значение, когда речь идет о синхронизации баз данных. Даже если сеть в рабочем состоянии и не перегружена, вы будете ограничены временем, которое требуется для пересылки байтов. При выборе места для размещения резервной системы учитывайте схему пиринга между ЦОД (они должны быть связаны друг с другом напрямую, чтобы избежать влияния общей перегрузки каналов связи).

Хотя современные БД (такие как SQL Server и Oracle) имеют мощные функции синхронизации (из-за чего лицензия на них стоит дороже), скорость передачи данных по-прежнему ограничена физическими возможностями сети.

Таким образом, в зависимости от организации вашей инфраструктуры и конфигурации сети, нулевое время простоя может быть недостижимо. Отставив эту высокую цель, подумайте, какое время простоя допустимо для ваших клиентов: минуты, часы или дни? Определить эту величину можете только вы и генеральный директор, которому вы предоставите данные о финансовых потерях в результате простоя.

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

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