Shit happens, или как не ломаться, когда у облака плохой день (и у вас тоже)
Облака учат нас жить в нескольких зонах доступности. Правда, до мультизоны редко доходят руки: то нет времени на развёртывание, то прикладные сервисы не умеют работать в нескольких экземплярах, то сетевые задержки мешают системам взаимодействовать. Так и живём, пока не падает зона. Пожар, сирены воют, инженеры в панике пытаются поднять системы, менеджеры ругаются и ищут виновных, бизнес теряет деньги. Спустя какое-то время провайдер восстанавливает работу зоны, а вы пишете постмортем. Представим, что команда не только пережила это падение, но и собрала мультизональную инсталляцию в облаке с маршрутизацией, репликацией и балансировкой. Она обслуживает пользователей и, главное, продолжает работать, когда падает одна из зон доступности. Казалось бы, всё хорошо. Но однажды у провайдера случается катастрофа: одна за другой падают зоны доступности, а сроки восстановления туманны. Публичные облака строят сверхнадёжными, и мало кто думает, что зрелое облако может отказать целиком. Шанс мал, но не равен нулю. Обычно на этом месте мы останавливаемся и, размахивая кружкой пива, уходим холиварить про BCP и DRP, но не в этот раз. Сегодня поговорим о том, как масштабировать мультизональную модель на несколько независимых площадок — и не утонуть в сложности их эксплуатации. Три поросенка кластера Допустим, мы учли опыт падения облака целиком и развернули инфраструктуру на нескольких площадках. Возьмём родное облако, соседнее облако и пару-тройку железных серверов в арендованных стойках надёжного ЦОДа — он-то уж точно упадёт последним. Читать далее