История пути: от первого тревожного звонка до катастрофоустойчивой инфраструктуры
Как розничный бизнес, зависящий от непрерывной работы ИТ, прошёл путь от единственного дата-центра до катастрофоустойчивой инфраструктуры из нескольких гео распределенных площадок — и какие решения оказались ключевыми на этом пути.
Зачем всё это затевалось
В основе проекта лежал простой, но жёсткий бизнес-принцип: БДРВ — «Бизнес должен работать всегда». Для розничной компании остановка ИТ-инфраструктуры означает прямые и колоссальные финансовые потери, и чем глубже анализировать риски, тем очевиднее становится их масштаб.
Из этого принципа родились четыре ключевые цели проекта:
Потеря одного ЦОДа не должна влиять на работу бизнеса.
Показатели RTO и RPO должны стремиться к нулю.
Инфраструктура должна поддерживать органический рост компании — с возможностью наращивания стоечного пространства.
При взломе или потере всех продуктивных ЦОДов резервные копии должны оставаться целыми и доступными для восстановления.
Три звоночка, после которых стало не до дискуссий
Решение не появилось на пустом месте — к нему подвели три последовательных сигнала.
Триггеры проекта • Пожар в одном из известных ЦОДов Москвы — первый звоночек о том, что физическая единая точка отказа реальна. • Участившиеся взломы дата-центров с крупными потерями для бизнеса — второй сигнал задуматься о безопасности и изоляции. • Финальная капля: действующий ЦОД сообщил, что свободных стоек для аренды больше нет — рост компании уперся в потолок инфраструктуры. |
Требования к новой площадке
Когда стало понятно, что нужен новый ЦОД, требования к нему формулировались уже не абстрактно, а исходя из целей БДРВ:
Уровень надёжности Tier III и выше.
Географическое удаление от текущей площадки.
В договоре — стартовое количество стоек плюс резерв на ближайшие 5–10 лет.
Вхождение в ТОП-10 дата-центров России.
Отдельного внимания заслуживает практический урок выбора площадки: обязательным условием стало личное посещение всех кандидатов и осмотр инфраструктуры изнутри.
На бумаге у всех красиво, на деле всё бывает очень печально.
Проектирование катастрофоустойчивости
Требование «бизнес работает всегда» декомпозировалось на конкретные инженерные принципы для каждого уровня инфраструктуры.
Все компоненты — по схеме N+1
Резервирование закладывалось на уровне каждого элемента инфраструктуры — от инженерных систем до сетевого оборудования. Всё сетевое оборудование дублируется по схеме N+1.
Каналы связи — дублирование от разных операторов
Каждое направление связи получило независимое резервирование, чтобы отказ одного канала или одного оператора не приводил к потере связности:
Интернет — 2 канала от разных операторов.
Каналы до головного офиса (HQ) — 2 канала от разных операторов.
Каналы до других ЦОДов — 4 канала (по 2 в каждое ядро сети) от разных операторов.
Каналы до облачных провайдеров — 2 канала от разных операторов.
Сеть: независимость каждой площадки
Ключевой архитектурный принцип — каждый ЦОД самодостаточен и не зависит от работоспособности других площадок. На каждой площадке организованы собственные сегменты:
DMZ
Internet
VPN
Сервера и сервисы: полный дубль нагрузки
Продуктивная нагрузка полностью дублируется, с кластеризацией на нескольких уровнях: серверы, системы хранения данных, виртуализация и сами сервисы. Цель одна — при потере площадки сервис продолжает работать без остановки бизнес-процессов.
Резервная (бэкап) площадка: изоляция как основа безопасности
Отдельным и, пожалуй, самым чувствительным блоком проекта стала организация выделенной площадки для резервного копирования — на случай, если скомпрометированы или потеряны все продуктивные ЦОДы одновременно.
К бэкап-площадке предъявлялись строгие требования по географической и сетевой изоляции:
Географически разнесена относительно продуктивных ЦОДов.
Географически разнесена относительно расположения облачных провайдеров.
Изолирована от продуктивных площадок.
Площадка может инициировать соединения к продуктивным ЦОДам, но не наоборот — с продуктивных площадок доступа на бэкап-площадку нет.
Периметр площадки защищён NGFW.
На площадке отсутствует выход в интернет.
Доступ технического персонала возможен только из выделенной сети; рабочие компьютеры сотрудников ни при каких условиях не должны находиться в этом сегменте.
Итоговый принцип резервной площадки был сформулирован предельно чётко: разрешать только соединения, инициированные из изолированной зоны (stateless firewalls).
Самым сложным было «подружить» инфраструктуру, о которой продуктивная площадка ничего не знает и знать не должна. Пришлось не раз вспотеть и наморщить мозг, чтобы добиться нужного результата.
Как итог: Мы написали собственное решение СРК на базе открытой платформы Aweb. Данная платформа располагается в изолированной зоне бэкап площадки и может создавать соединения на продовые площадки используя технологию сети Stateful. Продовые площадки создавать соединения на бекап площадку при данной настройке NGFW конечно же не могут.
Итоговая схема:
Схема показывает четыре площадки — ЦОД-1 (текущий, в роли резерва), ЦОД-2 (новый, продуктив), ЦОД-3 (СРК — резервная площадка) и Центральный офис. Ядра сети каждой площадки связаны крест-накрест дублирующими каналами, а доступ к резервной площадке (ЦОД-3) проходит через два независимых NGFW-периметра, что физически реализует принцип одностороннего доступа, описанный выше.
Путь к цели:
Реализация проекта проходила в несколько крупных этапов, каждый из которых был по-своему сложен.
Продажа проекта бизнесу
Дорогостоящий инфраструктурный проект пришлось буквально «продавать» руководству — и это оказалось непросто. Потребовалось значительное время, чтобы подобрать аргументы, убедительные именно для бизнеса.
Все аргументы формировались из первоначальных Целей с уклоном, что при срабатывании любой ситуации: пожар, выход из строя оборудования, взлом и т.д. - бизнес останавливается на время восстановления из бэкапов. А при потере бэкапов, бизнес просто прекращает существовать.
Главным аргументом стал риск полной остановки розничного бизнеса и связанные с этим колоссальные потери. Анализ показал, что даже при наличии бекапов, восстановление бизнес критичных систем займет от 5 до 7 дней(При условии, что все пройдет без запинки). Это будет полная остановка бизнеса без возможности торговать на торговых точках(1000 ТТ) и невозможности работать в офисе и на складах.
Запуск инфраструктуры
Сеть: интеграция с уже действующими площадками без остановки работоспособности и без деградации сервисов, в режиме 24/7.
Серверы: усложнение конфигураций и кластеризации при переходе на несколько географически разнесённых площадок.
Сервисы: главная задача — обеспечить работу при выходе из строя любого сегмента так, чтобы конечный пользователь в худшем случае воспринимал это как перезапуск программы или необходимость обновить страницу (F5).
Итоговые затраты и сроки на реализацию состояли из:
Организации новой площадки прода - 60% бюджета.
Реорганизация текущей продовой площадки под резерв площадку. - 10% бюджета.
Реорганизация старой резервной площадки под СРК - 30% Бюджета.
Длительность проекта под ключ с разнесением и настройкой всех бизнес критичных систем - 11 мес.