Руслан Заединов, заместитель генерального директора, руководитель направления ЦОД и облачных вычислений, компания КРОК
Прежде всего следует разграничить понятия отказоустойчивости и катастрофоустойчивости. Отказоустойчивость – это способность ИТ-системы переживать локальные сбои. Катастрофоустойчивость – более сложная задача по восстановлению работы систем в случае каких-то глобальных ситуаций, стихийных бедствий, пожаров, когда исключается возможность работы дата-центра в целом. Поскольку непрерывное функционирование основных бизнес-процессов становится все более критичным требованием бизнеса, необходимо предусмотреть варианты «страховки» и для таких случаев. Если говорить о непрерывности процессов с точки зрения бизнеса, то оптимальный способ застраховать себя от простоев – создать или арендовать резервный ЦОД.
«Непрерывность бизнеса − стратегическая и тактическая способность организации планировать свои действия и реагировать на инциденты и нарушения нормального хода бизнеса в целях продолжения деловых операций на определенном приемлемом уровне» (из стандарта «В525999-1:2006. Управление непрерывностью бизнеса»).
Градус растет
Резервные ИТ-мощности условно можно разделить на три группы: «холодные», «теплые», «горячие». «Холодный» резерв предполагает наличие площадки, где при необходимости можно развернуть новый дата-центр в случае утраты работавшего. Этот путь самый долгий и подойдет только тем компаниям, для которых довольно длительный простой, связанный с завозом оборудования и заключением новых контрактов с операторами связи и провайдерами, не будет критичным.
«Теплый» резерв позволит с меньшими потерями времени решить задачи по перезапуску критичных приложений, необходимых для работы организации. При выборе варианта, когда у компании уже есть действующий резервный ЦОД, пусть и с меньшей мощностью инфраструктуры, чем на основной площадке, на первый план выходит правильно организованная синхронизация данных между ЦОД.
Если же для бизнеса даже незначительный простой грозит большими финансовыми потерями, то оптимальный выбор для ИТ-службы – создание «горячего» резерва. На практике это означает, что необходимо создать резервную площадку с системами хранения данных, серверными мощностями и другими компонентами, дублирующими основную площадку по производительности и функционалу. Для сокращения финансовых издержек на поддержку двух ЦОД нагрузку между ними можно распределить таким образом, чтобы они оба были использованы в решении повседневных задач.
Резервные площадки
Архитектура катастрофоустойчивых ИТ-систем индивидуальна для каждой организации. Конечный выбор и стоимость таких решений зависят от множества аспектов бизнеса и приоритетности для компании различных внутренних и внешних процессов. Для каждого из таких процессов нужно принимать во внимание параметры RTO (Recovery Time Objective – время восстановления системы), RPO (процент потери данных при восстановлении), и RCO (часть нагрузки, которую обеспечивает резервная система).
Практически нулевого показателя RPO можно достичь с помощью синхронной репликации на уровне СХД, СУБД или серверов. Стоимость лицензий для репликации на уровне СХД начинается от нескольких тысяч долларов, и к этой сумме нужно добавить стоимость оборудования для организации резервного ЦОД, если его еще нет в организации.
Если же для заказчика крайне важно максимально сократить возможное время восстановления после сбоя, то основной упор в организации резервного ЦОД необходимо сделать на документальное описание и автоматизацию процесса. Одно из универсальных решений, которое может быть использовано в такой ситуации, – высоконадежные кластеры (HA-кластеры) с территориально распределенными узлами. Основой для такого решения может стать, например, Symantec Cluster Server, в составе которого есть модули по работе с СХД и бизнес-приложениями. Эти модули автоматически переключают направление репликации при запуске сервиса на резервном канале и корректно перезапускают программные службы.
Новые возможности резервных площадок
Для создания собственной резервной площадки заказчикам необходимо пройти непростой и затратный по времени и средствам путь: выбрать и закупить оборудование и программное обеспечение, настроить и протестировать созданную систему, внедрить ее в уже имеющиеся бизнес-процессы и ИТ-инфраструктуру. Дополнительных затрат требуют строительство и обслуживание резервной площадки.
Все это приводит к тому, что для компании может быть более выгодно арендовать несколько стоек в коммерческом дата-центре, нежели строить свой собственный с нуля.
Но, пожалуй, оптимальным решением с точки зрения финансовых затрат и времени на запуск системы будет организация резервной инфраструктуры в облаке. Такой подход может существенно сократить сроки введения в эксплуатацию ИТ-системы и снизить капитальные расходы на ИТ.
На ИТ-рынке набирает обороты тренд «резервный ЦОД как услуга» (Disaster Recovery-as-a-Service − DRaaS). Крупные системные интеграторы, имеющие в своем распоряжении собственные защищенные дата-центры, готовы установить и настроить оборудование и программное обеспечение таким образом, чтобы все важные для бизнеса их заказчиков сервисы в случае катастрофы в основном ЦОД были переведены на их коммерческие площадки с минимумом негативных последствий. Весь комплекс систем предоставляется заказчику как услуга, не требующая капитальных вложений, затрат на настройку и ИТ-поддержку. Резервный ЦОД может быть размещен в одном из аутсорсиноговых дата-центров провайдера, в том числе и на облачной платформе.
Для обеспечения катастрофоустойчивости, как правило, используется комплекс аппаратно-программных решений, включающих в себя отказоустойчивые кластерные платформы, программные продукты по резервному копированию данных, программно-аппаратные комплексы для репликации данных и защищенные каналы связи.
Преимущества подобного подхода:
- полная защита данных от сбоев оборудования и внешних угроз;
- минимизация нагрузки на администрирующий персонал;
- возможность перекрестной репликации;
- миграция отдельных виртуальных машин и дисков между несколькими ЦОД;
- возможность перекрестного между площадками резервного копирования данных;
- возможность подключения физического оборудования к облачной части системы (например, для удовлетворения сертификационных требований прикладного ПО).
Дополнительным преимуществом при использовании «резервного ЦОД как услуги» станет возможность получить детальный план аварийного восстановления ИТ-сервисов (DRP), разработанный специалистами от провайдера. Например, для кредитных организаций и банковских групп наличие DRP является одним из обязательных требований со стороны регулирующих органов для финансовых организаций (постановление ЦБ № 219 от 5 марта 2009 г.).
Резервный центр обработки данных в банке
Одна из ключевых задач, которая стоит перед ИТ-департаментом любого банка, – обеспечение непрерывности бизнес-процессов. Для выполнения этой задачи ИТ-службы и принимается решение о необходимости разработки и внедрения катастрофоустойчивой ИТ-инфраструктуры.
Для одного из своих заказчиков из банковской сферы КРОК предложил решение, которое строится на базе двух территориально распределенных центров обработки данных – основного и резервного. За время реализации этого проекта мы внедрили около десяти программных и аппаратных решений различных производителей: Hitachi Data Systems, Brocade, Oracle, Symantec, Cisco, MRV, VMware и др.
Команда, которая работала над проектом, проделала огромную работу. Были модернизированы сети и системы хранения, серверный комплекс, организованы независимые магистральные каналы связи между собственным и резервным центрами обработки данных, оптимизирована система управления базами данных, внедрены система резервного копирования, а также набор программных решений, автоматизирующих процесс обеспечения непрерывной доступности ключевых для банка бизнес-приложений.
На случай возникновения чрезвычайных ситуаций был разработан план аварийного восстановления, который стал для ИТ-персонала настоящей дорожной картой по выявлению и устранению угроз. В нем, например, учтены перемещения сотрудников и распределены их конкретные роли при восстановлении системы с точностью до конкретных команд, выполняемых администраторами.
В итоге в случае возникновения форс-мажорных обстоятельств работа ключевых сервисов будет восстановлена в течение одного часа.
