Что делать, когда в вашем ЦОДе произошла авария?
Если время простоя имеет значение (нормальное такое, денежное значение), то вам нужна резервная площадка - резервный ЦОДик 🫰
Обычно на выбор два варианта:
Актив/пассив - когда резервный ЦОД стоит в режиме резерва и запускается только в случае необходимости.
Минусы: 99% времени простаивает, греет воздух за большие деньги.
Актив/актив - когда одновременно работают два ЦОДа и ваши системы крутятся и там, и там.
Минусы: сложная схема синхронизации инфраструктуры (как правило через метрокластер). Обязательный запас всех ресурсов в каждом ЦОДе (~ х2) на случай аварии и переезда всей нагрузки в один ЦОД.
Набирает популярность третий подход - N+1.
По нему строятся ЦОДы Google, Amazon и пр. Когда уходишь от всяких метрокластеров в сторону синхронизации «слоев приложений». Web с web, app с app, СУБД с СУБД.
Ребята из Джет Инфосистемс это красиво оформили и представили как концепт на ИТ.элементс. Откуда я и заснял это видео. Сорри, бро, что тебе придется долго его загружать 😔
5 февраля поедем в Новосибирск на Linkmeetup, пораспрашиваем их подробнее по этой теме.
Обещают рассказать, а мы поделимся:
Как перейти от растянутых сервисных слоёв к самодостаточным блокам, распределить нагрузку для 3 ЦОД на сетевом уровне
В этом посте есть большое видео, которое не загрузилось в Дзен. Откройте оригинал поста в телеграме, чтобы его посмотреть
