Обзор методов обеспечения катастрофоустойчивости
19 февраль, 2014 - 16:44Евгений ВойтовичБизнес-требования к непрерывности ИТ-сервисов постоянно растут, что связано с увеличением количества сервисов, без которых компании будут либо недополучать прибыль, либо вообще нести убытки. В связи с этим все больший круг компаний нуждается в решениях, которые смогли бы обеспечить такую непрерывность при любых событиях, происходящих в ЦОД, в здании и в компании в целом.
Если еще несколько лет назад защиту от таких угроз как пожар, потоп, длительное отключение электричества в ЦОД, захват/проверка внедряли только самые крупные финансовые учреждения, страховые компании, сервис-провайдеры, телекомы, то сегодня круг заинтересованных значительно вырос. Конечно же рост спроса обусловлен расширением количества технологий и снижением цен на решения, которые могут обеспечить катастрофоустойчиовость.
В этой статье коротко описаны основные методы обеспечения катастрофоустойчивости, которые позволят восстановить работоспособность ИТ-сервисов с заданным показателем актуальности данных (RPO, Recovery Point Objective, точка восстановления — максимальный допустимый период времени, за который данные могут быть потеряны) и в заданные сроки (RTO, Recovery Time Objective, время востановления — максимальное допустимое время, в течении которого данные должны быть восстановлены) при полном или частичном прекращении работы этих сервисов на основной площадке. В качестве резервной площадки может выступать продуктивный резервный ЦОД, выделенные мощности на площадке сервис-провайдера или мощности, предоставляемые по определенному SLA, в «облаке» или в публичном ЦОД. Естественно, чем выше целевые показатели RPO и RTO, тем выше требования к резервным площадкам, каналам связи между ними и к методам обеспечения катастрофоустойчивости, а как следствие — и стоимость решения. Поэтому при планировании таких решений нужно правильно классифицировать сервисы, учесть связи между ними, определить для них реальные показатели RPO и RTO и затем подобрать метод обеспечения катастрофоустойчивости, способный их обеспечить. Итак, рассмотрим доступные методы в порядке возрастания стоимости их реализации.
Резервное копирование
Самый недорогой метод обеспечения катастрофоустойчивости, не требующий развитой инфраструктуры ни на основной, ни на удаленной площадках, обеспечивающий целостность данных на определенный момент времени, с низкими показателями RPO и RTO. Рассмотрим основные его разновидности.
На ленты
Самым доступным способом обеспечения катастрофоустойчивости является резервное копирование на ленты. С определенной периодичностью ленты с актуальными резервными копиями выносятся на другую площадку, в банк, в сейф и т.д. В случае катастрофы данные с последней копии последовательно восстанавливаются на существующие в резерве или вновь купленные/арендованные вычислительные мощности. Важно заметить, что вместе с лентами желательно хранить и стример, который смог бы прочесть ленты соответствующего стандарта.
Такой подход, как правило, обеспечивает не лучшие показатели RPO и RTO, а также требует дополнительных расходов на логистику и хранение, отличается невысоким показателем надежности. Время восстановления данных может составлять до двух суток для первого сервиса, к примеру, если авария произошла в субботу, а ленты находятся в банке.
Восстановление резервных копий происходит последовательно и, к примеру, на воссоздание инфраструктуры из 30 серверов (виртуальных и физических) может понадобиться несколько суток, и это в случае наличия необходимых вычислительных ресурсов. RPO зависит от частоты вывоза лент и в среднем составляет одну неделю (если ленты вывозить за пределы ЦОД, к примеру, по субботам после полного резервного копирования инфраструктуры).
Если речь идет о нескольких продуктивных ЦОД или серверных, то затраты на доставку лент в место их хранения могут приближать это решение по стоимости к следующему методу резервного копирования — на диски.
Плюсы и минусы:
+ низкая стоимость. Резервное копирование является неотъемлемой составляющей ИТ в организации и на сегодняшний день чаще всего выполняется на ленты. В таком случае расходы для обеспечения катастрофоустойчивости заключается только в логистике и хранении лент;
+ большинство приводов для чтения/записи лент в базе предоставляет функцию шифрования, что может сыграть ключевую роль при выборе недорогого решения;
– худшие показатели времени и точки восстановления: процесс восстановления выполняется последовательно, для поиска нужной резервной копии необходимо перемотать одну или несколько лент в нужное место, а уж потом восстанавливать данные; как правило вывоз лент за пределы ЦОД выполняется не чаще раза в сутки, а в среднем — раз в неделю;
– низкая надежность хранения на лентах. Есть вероятность повреждения данных на ленте при перевозке и хранении;
– человеческий фактор. Большое количество ручной работы как в случае аварии, так и при обслуживании повышает вероятность ошибок и нарушения SLA.
На диски
Резервное копирование на диски (D2D, Disk-to-Disk) для обеспечения катастрофоустойчивости, имеет смысл для компаний с несколькими серверными или ЦОД. Копии, сделанные локально, передаются на одну или несколько удаленных площадок по каналам связи. В случае потери данных или краха одной из площадок, резервные копии передаются на исходную площадку либо восстанавливаются на другой, после чего сервис предоставляется удаленно.
Современные решения резервного копирования на диски, как правило, в базе предоставляют функции дедупликации, репликации, передачи данных по тонким каналам связи, что упрощает действия администратора, снижает требования к коммуникациям и уменьшает объем хранимых данных на дорогих, сравнительно с лентами, носителях.
В первую очередь D2D сокращает время, необходимое для резервного копирования и восстановления данных, т.к. отпадает необходимость в перемотке лент, а функции дедупликации и репликации позволяют оптимизировать RPO. Для самых критичных приложений этот показатель может достигать 15 мин при использовании инкрементальных копий, и до суток для самых объемных и/или менее критичных сервисов.
Схема резервного копирования D2D на примере двух площадок с применением дедупликации
Показатели RTO в таком сценарии гораздо лучше, чем в случае с лентами, т.к. резервные копии находятся непосредственно в ЦОД, их поиск и восстановление занимают меньше времени, можно восстанавливать несколько приложений одновременно. Таким образом, при наличии заранее подготовленных вычислительных мощностей, первый сервис можно восстановить менее чем за час, а инфраструктуру из 30 серверов — скажем, за сутки.
Плюсы и минусы:
+ достаточно бюджетное решение, комбинирующее необходимое для каждой компании резервное копирование с обеспечением катастрофоустойчивости. Не требует обязательного наличия всех вычислительных ресурсов на удаленной площадке;
+ высокая гибкость при выполнении резервных копий, что позволяет регулировать точку восстановления данных;
+ возможность хранения нескольких копий данных в разных территориально-распределенных местах;
– зависимость восстановления данных на удаленную площадку от каналов связи, что в украинских реалиях может иметь существенное значение;
– человеческий фактор, вследствие большого количества ручной работы, что повышает вероятность ошибок и нарушения SLA.
Средствами приложения/сервиса
Некоторые приложения, сервисы, СУБД имеют собственные механизмы обеспечения катастрофоустойчиовости, которые позволяют достичь наилучших показателей RPO и RTO, но, чаще всего, требуют на резервной площадке таких же мощных серверов и СХД как и на основной, а также выдвигают высокие требования к каналам связи и организации сети. К таковым относятся SQL Server, Oracle Database, Exchange, сервисы AD, DNS и пр. В качестве примера более подробно рассмотрим Microsoft SQL Server.
Актуальная версия SQL Server 2012 предлагает следующие возможности по обеспечению высокой доступности, отказоустойчивости и катастрофоустойчивости:
Катастрофоустойчивое решение средствами SQL Server 2012 возможно только с использованием опции AlwaysOn Availability Group. В синхронном режиме достигаются лучшие показатели RPO и RTO, но с падением производительности. Аргументом в пользу асинхронного режима (а также опции AlwaysOn Failover Cluster Instance) может послужить скорость работы СУБД. Дело в том, что при использовании механизмов синхронной репликации логов AlwaysOn Availability Group возрастает время на отработку транзакции за счет латентности сети — транзакция не будет завершена до тех пор, пока данные не будут записаны на удаленную площадку.
Для обеспечения комплексной защиты данных возможно совместное использование нескольких указанных опций. На рисунке ниже AlwaysOn Failover Cluster Instance обеспечивает отказоустойчивость в пределах одной площадки, а AlwaysOn Availability Group в асинхронном режиме — катастрофоустойчивость на двух площадках.
Тем не менее, нередки случаи, когда для сервисов со встроенными средствами репликации все же выбираются другие методы обеспечения катастрофоустойчивсти. Основными причинами являются сложность и/или дороговизна реализации, которые могут быть связаны со стоимостью оборудования, каналов связи, необходимых лицензий.
Плюсы и минусы:
+ наилучшие показатели RTO и RPO;
+ гарантия целостности данных;
+ автоматический или полуавтоматический процесс восстановления работоспособности сервиса, что снижает влияние человеческого фактора;
– стоимость решения, обусловленная необходимостью дублировать оборудование;
– поддерживается в сравнительно небольшом количестве приложений.
Средствами СХД
Этот способ подразумевает репликацию данных системами хранения на блочном уровне между несколькими площадками. При этом СХД безразлично, какие серверы к ней подключены, какие приложения на них исполняются и пр., они лишь гарантируют, что каждый блок данных, записанный на одной, будет в определенный срок продублирован на другой.
При этом выделяют следующие стандартные типы репликации: синхронная, асинхронная, асинхронная Remote Snap. Также у каждого производителя СХД имеются проприетарные технологии, которые несколько отличаются от стандартных, но в большинстве своем на них базируются. К примеру, архитектура СХД HP StoreVirtual 4000 (ранее LeftHand), которые ориентированы на виртуализованные среды и территориально разнесенные инфраструктуры, позволяет записывать и читать данные на обеих площадках одновременно (что не применимо в описанных ниже случаях). Таким образом, реплицируемые данные не блокируются на резервной площадке, а остаются доступными и на чтение, и на запись, что позволяет строить распределенные кластеры.
Синхронная репликация
Гарантирует, что блоки данных, записанные на основную СХД, будут реплицированы на удаленную без всяких задержек. По сути, основная дожидается от удаленной подтверждения записи блока, а лишь затем сама выдает подтверждение приложению. Таким образом RPO в данном случае стремится к нулю. К примеру, если СУБД завершила транзакцию и после этого произошел сбой, то восстановленная база данных на другой площадке будет в актуальном состоянии с точностью до последней завершенной транзакции.
Этот тип репликации характеризуется высокими требованиями и ограничениями, которые могут несколько меняться в зависимости от производителя СХД. Обычно расстояние между реплицируемыми СХД должно быть в пределах 40 км, а латентность канала связи не должна превышать 2 мс (темная оптика) — при этом приложение должно допускать вдвое большие задержки.
Асинхронная репликация
Отличается от синхронной тем, что СХД вначале локально записывает данные и отправляет подтверждение приложению, а параллельно передает данные на вторую СХД. Таким образом, по сравнению с синхронной репликацией, снимаются ограничения по расстоянию и латентности канала связи, но при этом увеличивается значение RPO.
Асинхронная репликация Remote Snap
Подразумевает использование снимков. Основная СХД обменивается снимками томов с резервной СХД непрерывно через заданные интервалы времени. Это позволяет восстановить данные с резервной площадки на момент, когда был сделан (и успешно передан) последний снимок основной СХД.
Обычно производители рекомендуют интервал репликации не менее 15 мин, таким образом лучшее значение RPO составляет 15 мин плюс время, необходимое для передачи этого снимка на вторую площадку.
Организация
Как правило, выделяют продуктивную площадку, на которой сервисы работают в активном режиме, и резервную, на которой располагается СХД и серверная инфраструктура, полностью дублирующая основную или достаточная для восстановления самых критичных сервисов. В таком случае используется односторонняя репликации с активной площадки на резервную. С целью экономии средств, иногда площадки используются в режиме Active-Active, когда обе являются продуктивными и имеют некий запас серверной мощности для восстановления сервисов друг друга. В таком случае имеет место двухсторонняя репликация. Все вышеперечисленные методы репликации подразумевают, что основной логический диск доступен на чтение и запись, а реплицируемый только на чтение или не доступен вообще до завершения репликации.
В случае катастрофы на основной площадке, необходимо запустить к выполнению заранее прописанный Disaster Recovery Plan, который подразумевает последовательность действий для реанимации сервисов на резервной площадке. При этом существует ряд программных продуктов, способных свести необходимые действия администратора к нажатию нескольких кнопок, что, в свою очередь, в разы снижает значение RTO.
Плюсы и минусы:
+ наилучшие RPO и RTO для всех сервисов;
+ ПО автоматизации процесса восстановления минимизирует возможные ошибки;
+ интеграция с самыми популярными гипервизорами;
– высокая стоимость, обусловленная дублированием оборудования на двух площадках, а также приобретением ПО автоматизации процедур переключения активной площадки на резервную;
– высокие требования к каналам связи, особенно при синхронной репликации.
Выводы
Рассмотренные методы обеспечения катастрофоустойчивости чаще всего используются совместно в пределах одной компании для обеспечения необходимых показателей RPO и RTO для разных групп сервисов. Реализация таких решений — непростой процесс, требующий скрупулезного подхода на всех этапах, начиная с определения требований по каждому сервису и заканчивая процедурой внедрения и тестирования. Надо понимать, что чем жестче выдвигаемые к решению требования, тем дороже оно обойдется. Зачастую случается так, что при первой попытке оценить необходимые инвестиции, руководство компании приходит в ужас от полученных цифр. Это является следствием именно чрезмерных требований, вроде обеспечения доступности абсолютно всех сервисов в режиме 24×7.
В таких случаях необходимо вернутся к стадии постановки задачи и исходить из реальных оценок финансовых потерь бизнеса в случае, если сервис X будет недоступен в течении Y часов. Отталкиваясь от этой информации, нужно разбить сервисы на несколько групп и для каждой определить адекватные методы обеспечения отказоустойчивости и катастрофоустойчиовсти.
Итоговое сравнение методов обеспечения катастрофоустойчиовости
