Отказоустойчивость vs. катастрофоустойчивость
Множество событий могут привести к неработоспособности систем — будь то ураган, пожар, землетрясение или человеческий фактор. Этот список можно продолжать бесконечно. Поскольку угрожающих факторов так много, надежная ИТ-система должна быть спроектирована так, чтобы пережить эти опасности.
В разрезе устойчивости инфраструктуры чаще всего звучат два термина: отказоустойчивость (High Availability) и катастрофоустойчивость (Disaster Tolerance). Сегодня мы хотим прояснить разницу между этими концепциями.
Если кратко, концепция отказоустойчивости направлена на устранение точек отказа, катастрофоустойчивость — на поддержание работоспособности после массового отказа компонентов инфраструктуры, серьезной аварии или стихийного бедствия.
Отказоустойчивость (HA)
Как уже упоминалось, концепция HA нацелена на устранение отдельных точек отказа, соответственно, подразумевает избыточность и резервирование компонентов. Как правило, резервирование происходит в трех плоскостях: оборудование, ПО и окружение. Концепция высокой доступности позволяет не прерывать выполнение задач, если какой-то из компонентов инфраструктуры выходит из строя.
Аппаратное резервирование было одним из первых способов обеспечения высокой доступности в вычислениях. До того, как приложения ушли в онлайн, они выполняли корпоративные задачи внутри локальной сети. Тогда не было необходимости в обслуживании тысяч пользователей 24/7. Однако эти системы хранили и обрабатывали критически важные для бизнеса данные, поэтому им требовалось аппаратное обеспечение, которое было бы отказоустойчивым. Тогда стали использоваться следующие меры:
резервирование хранилищ с помощью RAID или аналогичной технологии, которая обеспечивала запись данных для чтения с нескольких физических дисков — это предотвратило потерю данных и простои;
резервирование питания путем подключения нескольких источников позволило избегать отключения оборудования в случае сбоя на одном из источников;
исправление ошибок, например, с помощью внедрения ECC RAM (error-correcting code) для "лечения" поврежденных данных;
резервирование сети путем подключения нескольких контроллеров к независимым сетям, что позволяло гарантировать, что сервер остается подключенным к сети в случае сбоев.
Избыточность программного обеспечения вскоре последовала этому примеру. Разработчики приложений работали над тем, чтобы сами приложения могли выдерживать сбои в системе, будь то аппаратный сбой, ошибки конфигурации или любые другие события, которые могли привести к повреждению ПО. Это было достигнуто несколькими способами:
внедрение технологий кластеризации, например, кластеров БД, которые распределяют рабочие нагрузки по нескольким серверам;
внедрение концепции statelessness для быстрого масштабирования и простоты настройки высокой доступности;
балансировка нагрузки с помощью мониторинга приложений;
разработка систем, способных к самостоятельному восстановлению, которые перемещают рабочие нагрузки или выделяют дополнительную емкость при обнаружении сбоев.
С ростом использования облаков провайдеры подняли высокую доступность на совершенно новый уровень, дополнив концепцию высокой доступности избыточностью окружения:
аппаратная избыточность в стойке, позволяющая распределять рабочие нагрузки для уменьшения отдельных точек отказа;
избыточность ЦОД в географическом регионе, обычно называемом «зоной доступности», позволяет пользователям запускать приложения в разных дата-центрах, которые расположены географически близко друг к другу.
Все эти меры направлены на решение одной проблемы — устранение точек отказа — и позволяют провайдерам гарантировать доступность сервисов, зафиксированную в SLA. Уровень отказоустойчивости измеряется "девятками".
Соотношение уровня доступности и допустимой длительности простоя в год:
99.9% — 8.77 часов
99.99% — 52,6 минут
99.999% — 5, 26 минут
Катастрофоустойчивость (DT)
Если отказоустойчивость позволяет ИТ-инфраструктуре сохранять работоспособность даже тогда, когда выходит из строя какой-либо ее компонент, то катастрофоустойчивость — спасти критически важные данные и сохранить работоспособность в случае серьезной аварии, массового выхода из строя компонентов инфраструктуры и даже всего ЦОД, например, при пожаре или стихийном бедствии. Катастрофоустойчивость дата-центров реализуется путем геораспределенной кластерной конфигурации серверов с общей сетью хранения данных. Узлы на основной и резервной площадках образуют единую систему, что позволяет сохранить доступность сервисов даже при аварии в одном из ЦОД.
К понятию катастрофоустойчивости достаточно близок термин «Disaster Recovery» (DR). Реализация аварийного восстановления позволяет сохранить работоспособность корпоративных ИТ-систем после масштабного сбоя. Сложность процесса зависит от двух факторов: целевого времени (RTO) и целевой точки восстановления (RPO).
RTO — это максимальное количество времени, за которое система должна восстановить работоспособное состояние. Для некоторых систем оно может составлять часы или даже дни, однако для критически важных систем, как правило, фиксируется в секундах.
Точка восстановления отражает допустимый объем потерь данных после аварии, измеряемый во времени. Эта метрика работает похожим образом — некоторые системы могут потерять данные за целый день, а другие — максимум за несколько секунд. Продолжительность RTO и RPO оказывает глубокое влияние на реализацию DR-плана.
Сохранить непрерывность бизнеса, даже если в вашем ЦОД произошла авария, можно с помощью резервной площадки. Такой резерв может быть трех типов:
Холодный: некая серверная с запасным аппаратным обеспечением. Однако ввод в эксплуатацию такой площадки может занять не одну неделю.
Теплый: уже функционирующая доп. площадка, на которой подключено основное оборудование, настроены WAN-каналы, телеком- и вычислительная инфраструктура. Учитывайте, что на "теплой" площадке должны быть резервные копии ваших приложений и других данных, а оборудование должно быть готово к приему нагрузки. Как правило, такая резервная площадка запускается за один, максимум два дня.
Горячий: готовая инфраструктура на площадке, производительность которой сопоставима с вашей основной. Обычно перезапуститься на такой площадке можно в течение установленного RTO благодаря регулярной репликации данных.
Как "ИТ-ГРАД" помогает сохранить непрерывность бизнеса
Облачная площадка "ИТ-ГРАД" не имеет единой точки отказа, поддерживает катастрофоустойчивые и гибридные инфраструктуры, а для реализации аварийного восстановления клиенты могут подключить услугу DRaaS на базе VMware vCloud® Availability для быстрого восстановления виртуальных машин в облако в случае отказа основной площадки. Решение позволяет:
настраивать RPO на уровне клиента — от 15 минут.
определять количество точек восстановления — до 24.
самостоятельно управлять аварийным восстановлением и репликацией из веб-консоли.
отслеживать доступность инфраструктуры, включая состояние выполненных и текущих задач.
Для резервной площадки под DR также подходит публичное облако "ИТ-ГРАД".