Резервирование и геораспределение: зачем нужны несколько датацентров?¶

Когда обычный пользователь заходит на сайт или открывает мобильное приложение, он редко задумывается о том, где физически находится сервер, который обрабатывает его запрос. Для него существует только кнопки на экране и результат. Но за этим результатом стоит сложная физическая реальность: серверы стоят в стойках, стойки в зданиях, здания в конкретных точках на карте. И у этих точек есть уязвимости.

Представьте, что весь ваш бизнес работает на одном сервере в одной комнате. Что случится, если в этой комнате отключат электричество? Если прорвет трубу и вода зальет стойку? Если случится пожар? Ответ очевиден: ваш бизнес встанет. И в этот момент пользователю будет глубоко безразлично, как элегантно написан ваш код и как красиво выглядит интерфейс. Сервис не работает - значит, вас просто не существует.

Именно поэтому SRE не мыслят в категории "один датацентр/ЦОД" (ЦОД - Центр Обработки Данных). Они мыслят в категориях зон доступности, регионов и геораспределения.

Физическая реальность такова, что любые компоненты имеют конечную надежность. Жесткий диск однозначно выйдет из строя, это лишь вопрос времени, а не вероятности. Блок питания однозначно когда-нибудь перегорит. Сетевой коммутатор зависнет. Охлаждение откажется работать в самый жаркий день года. Это нормально. Это статистика. SRE не пытаются создать компонент, который никогда не ломается, это невозможно (может, и возможно, но ни у кого нет столько денег, чтобы проверить :)). Они проектируют системы, которые продолжают работать, когда отдельные компоненты ломаются.

Первый уровень защиты это резервирование внутри одного датацентра. Два блока питания, два жестких диска в RAID-массиве, два сетевых коммутатора, два сервера, работающих в кластере. Если что-то одно умирает, второе подхватывает. Это надежно, но не абсолютно.

Потому что остается единая точка отказа, сам датацентр. Наводнение не щадит резервные блоки питания. Пожар уничтожает и основной, и запасной сервер. Отключение электричества во всем районе не лечится вторым коммутатором. Датацентр, как целое - это такая же железная коробка, как и отдельный сервер. Просто больше размером. И у нее те же уязвимости.

Единая точка отказа в инженерии - это любой компонент, чей отказ приводит к отказу всей системы. И один датацентр, каким бы надежным он ни был внутри, остается единой точкой отказа относительно внешних событий. Пожар за стеной не различает основной и резервный сервер, он уничтожает все стойки одновременно. Поэтому для защиты от катастроф нужен второй датацентр. Желательно в другом районе, другой части города, а лучше в другом регионе страны.

Когда инженеры говорят о геораспределении, они оперируют двумя ключевыми понятиями: зона доступности и регион.

Зона доступности это изолированная физическая локация внутри одного региона. У нее свое независимое электричество, свое охлаждение, своя сеть, свои физические барьеры. Зоны доступности проектируются так, чтобы проблемы в одной зоне не влияли на другие. При этом зоны соединены между собой быстрыми, надежными, резервированными каналами связи с минимальной задержкой. Если вы разворачиваете систему в трех зонах доступности одного региона, вы защищены от выхода из строя любой отдельной зоны. Отключение электричества в одной зоне не затронет две другие. Пожар в одном здании не перекинется на соседнее, если они спроектированы правильно.

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

Кроме того, регионы решают проблему задержек. Геораспределение делает сервис не только надежнее, но и быстрее: данные отдаются пользователю из ближайшего датацентра.

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

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

Модель "активный-активный" сложнее, но эффективнее. Оба датацентра работают одновременно, делят трафик между собой. Если один падает, второй просто принимает всю нагрузку на себя. Мощности не простаивают, но возникает другая проблема: синхронизация данных. Пользователь может создать запись в базе данных в первом датацентре, а следующий запрос (когда ляжет первый) попадет во второй, где этой записи еще нет. Решение непростое: либо жесткая синхронизация с задержками, либо продуманная маршрутизация, которая привязывает пользователя к конкретному датацентру.

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

Выбор между этими моделями напрямую связан с двумя ключевыми метриками, о которых мы говорили в другой главе: "Про RTO и RPO".

RTO: Recovery Time Objective, время, за которое мы должны восстановить работоспособность после катастрофы. Если у вас активно-пассивный датацентр с автоматическим переключением, RTO может измеряться минутами. Если переключение ручное, RTO может растянуться на часы. Если резервного центра нет вообще, RTO равен времени восстановления сгоревшего датацентра, то есть никогда.

RPO: Recovery Point Objective, объем данных, который мы готовы потерять. В активно-пассивной модели с асинхронной репликацией вы можете потерять несколько последних транзакций, которые не успели скопироваться. В синхронной репликации потери нет, но платой будет задержка на каждый запрос. В активный-активной модели с мультимастер-репликацией потерь практически нет, но сложность многократно возрастает.

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

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

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

И здесь снова приходят на помощь SLO. Если наш целевой уровень доступности 99%, достаточно одного датацентра с базовым резервированием. Если мы обещаем клиентам 99,99% -то нам уже нужны как минимум две зоны доступности. Если контракты требуют 99,999% - речь уже идет о полноценном геораспределении с автоматическим переключением между регионами.

Важно понимать, что наличие второго датацентра само по себе не гарантирует надежности. Его нужно регулярно проверять. Огромное количество компаний строят резервную площадку, но ленятся писать DRP (disaster recovery plan) и проводить DRT (disaster recovery test), годами не проверяют, как они переключаются, а когда наступает настоящая катастрофа, обнаруживают, что резервный центр не работает или работает, но не совсем: конфигурация устарела, данные не синхронизировались, скрипты переключения никто не тестировал, люди, которые помнили, как это делать, уволились два года назад и тэдэ и тэпэ.

Поэтому учения, плановые переключения трафика - это не прихоть, а необходимость. Единственный способ убедиться, что резервирование работает - регулярно им пользоваться. В зрелых SRE-организациях переключение между датацентрами может происходить несколько раз в год просто для тренировки, даже когда нет никакой аварии. И каждый раз они проверяют, укладываются ли эти переключения в заявленные RTO и RPO.

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

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

В конечном счете, вопрос резервирования и геораспределения это вопрос зрелости. Зрелая компания понимает, что сбои неизбежны, и готовится к ним. Незрелая надеется на удачу и молится, чтобы труба не прорвалась именно сегодня.

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

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