Сейчас трудно представить себе сферу деятельности, в которой доступность IT-инфраструктуры стояла бы на последнем месте. С ростом критических для бизнеса сервисов данный вопрос встает все острее, и сегодня мы хотим рассмотреть варианты резервирования инфраструктуры на удаленной DR-площадке IaaS-провайдера и кейсы, в контексте которых они подходят в качестве стратегии business continuity.
Давайте для начала определимся с базовыми понятиями, которыми оперируют IT-специалисты при разработке плана повышения доступности и без которых невозможно принять взвешенное и объективное решение по его реализации. Подготовка подобного плана всегда включает в себя обязательный диалог между IT и бизнесом, от чьих интересов и особенностей мы всегда должны отталкиваться. И первый вопрос в данном диалоге должен звучать так: Какое время простоя сервисов компании в случае отказа информационных систем не окажет ощутимого воздействие на бизнес? Можно сразу ответить: никакое, ведь любая нештатная ситуация, приводящая к прекращению предоставления услуг, неприятна. Но следует понимать, что организация нулевого даунтайма может обойтись бизнесу дороже, чем потенциальные потери, которые может понести компания, выстроив план так, что время восстановления после сбоя займет, к примеру, 4 часа.
Данное понятие называется RTO (recovery time objective) и его суть сводится к определению времени, за которое работоспособность того или иного сервиса должна быть восстановлена. Мы говорим про сервисы, а не про инфраструктуру в целом, потому что у каждого сервиса есть свой cost и RTO должен рассчитываться применительно именно к сервисам, а не к инфраструктуре в целом. Ведь, к примеру, без сервера печати можно прожить чуть дольше, чем без CRM или сайта компании, если он располагается на вашей площадке.
Следующим в данном диалоге будет вопрос о критичности потери наработанной информации. К примеру, в компании резервное копирование данных происходит ежедневно в 6:00 утра. Люди приходят на работу, вносят изменения в базы, получают новую почту, модернизируют приложение… А вечером происходит критический сбой всех наших систем, и все, что у нас есть, – это резервные копии на момент начала рабочего дня. Если изменений немного и они не критичны, то ничего страшного – восстанавливаемся и работаем дальше. Но если это не так и откат до существующей точки восстановления по тем или иным причинам невозможен без существенных потерь для бизнеса?
Подобный вопрос описывается параметром RPO (recovery point objective) – то есть точка состояния критичных данных, к которой допустимо вернуться в случае сбоя. К примеру, для сервера баз данных мы определяем этот параметр равный 1 часу. Это значит, что актуальная резервная копия данных должна собираться каждый час либо каждый час происходить репликация системы на резервный узел.
Разумеется, это не все вопросы, которые стоит обсудить с держателями сервисов перед составлением плана Business Continue и Disaster Recovery Plan в частности. Но от них в бОльшей степени зависит выбор стратегии по организации доступности бизнеса и стоимость инфраструктуры. После определения данных параметров можно переходить к выбору Disaster Recovery Site – места, где будут находиться резервные мощности, способные принять на себя рабочую нагрузку в случае возникновения отказа основных систем.
Есть несколько подходов к решению данного вопроса. Один из них – размещение резервных узлов непосредственно рядом с продуктовой инфраструктурой и организация либо кластеризации ресурсов, либо иного способа резервирования.
Тут вопрос сводится к тому, готовы ли вы положить все яйца в одну корзину, ведь в этом случае нельзя полностью исключить риск потери доступности всей инфраструктуры из-за техногенных катастроф, человеческого фактора или иных причин. Также нельзя исключать шанс потерять информацию, если и основные сервисы, и резервные копии размещены на одной площадке. Будь то отказ всех резервных каналов связи по причине консолидации точек присутствия провайдеров в одном помещении с последующей непредвиденной ситуацией или проблема с перебоем электроснабжения – вы никогда не будете застрахованы от перебоя в жизнедеятельности вашей компании, организовав план доступности таким образом.
Более надежно выглядит вариант с размещением резервной площадки на территории дата-центра. Вы сразу избегаете вероятности потерять всю инфраструктуру, а при определенных затратах на резервную площадку можно добиться околонулевых прерываний и высокой катастрофоустойчивости. Минусом этого решения можно считать только накладные расходы на закупку резервного оборудования (по сути, вы удваиваете расходы на содержание ИТ-инфраструктуры), затраты на внедрение и издержки на поддержку данного решения.
Еще одной вариацией такого решения является размещение на удаленной площадке IaaS-провайдера, что избавляет вас от накладных расходов на поддержку оборудования на удаленной стороне, но также не избавляет от трат на внедрение и поддержку самой системы резервирования.
Третий вариант – DRS (Disaster Recovery Service), буквально – «аварийное восстановление как сервис», когда ваша инфраструктура (или только критически важные для бизнеса сервисы) реплицируется на площадку IaaS-провайдера и, в зависимости от настроенных планов RTO и RPO, дает вам возможность практически моментально запустить все системы одним нажатием на «красную кнопку», а при дополнительной настройке силами представителей резервной площадки – автоматически.
Как это работает? В случае VMware все очень просто: действия сводятся к поднятию доверия SRM с двух сторон. SRM – Site Recovery Manager, роль которого – обеспечивать готовность и саму отработку отказа. На практике это выглядит примерно так:
На vCenter или на отдельном сервере устанавливается SRM, обеспечивающий оркестровку репликации и восстановления.
Запускается первоначальная полная синхронизация выбранных ВМ согласно плану DR.
Настраиваются политики RPO, и начинается блочная асинхронная репликация.
Дальше мы получаем возможность в любое время тестировать ложную отработку отказа без воздействия на продуктовую инфраструктуру либо «жмем красную кнопку» – и отработка происходит в боевых условиях. Данный механизм хорошо зарекомендовал себя и прошел проверку временем.
Оптимальный план резервирования зависит от стоимости потенциальных потерь, которые повлечет за собой остановка работы инфраструктуры. Подходите к этому вопросу с умом, оценивайте риски заранее. Понимание необходимости оценивать такие риски может появиться после unsuccess story, но для вас это будет не самый комфортный сценарий. Защищайте свои инвестиции, настраивайте сценарии аварийного восстановления в облако (DRS).
RSS
