Стратегия резервного копирования в облаке: горячее, прохладное, холодное

Основной запрос со стороны любого бизнеса — обеспечение сохранности данных, а также высокой доступности, отказоустойчивости и катастрофоустойчивости главных ИТ-сервисов (электронная почта, 1С, CRM, CLM, системы управления складом и т.д.).

Сегодня всё чаще эти задачи решаются с помощью резервирования ресурсов в облаке. Здесь возможны два варианта. В первом случае облако IaaS-провайдера — это целостное решение; во втором случае облако — только часть решения, обеспечивающая холодный, тёплый или горячий резерв ресурсов.

Вариант 1. Качество решения всех вопросов, связанных с отказо- и катастрофоустойчивостью ключевых ИТ-сервисов компании, полностью зависит от того, как в конкретном ЦОД построена инженерная инфраструктура и система виртуализации. Как размещены данные (одна площадка или несколько; в пределах одного ЦОД или целой сети). Соответственно, главная задача заказчика, получающего услугу от ЦОД, — правильно выбрать саму услугу и её провайдера. А затем правильно ее настроить (например, не забыть о репликации виртуальных машин в разные ЦОД, если это IaaS). Все остальное — задача и ответственность ЦОД.

В варианте 2 заказчику нужно решать более сложные задачи. В первую очередь, определиться с характером резервирования (холодный, тёплый, горячий), что существенно влияет на эксплуатационные и технические параметры решения, а также на работу всей ИС при возникновении нештатных ситуаций.

Холодный резерв

Компания (чаще всего средняя) сама обеспечивает высокую доступность, отказо- и катастрофоустойчивость сервисов. Не создавая избыточную ИТ-инфраструктуру, а используя облачные средства. В случае холодного резерва ресурсов это может быть, например, минимальный контракт с ЦОД и установленный VPN-тоннель. Если в компании произошел форс-мажор и «все сломалось», идет переключение на ресурсы в холодном резерве. Время переключения может составлять от одного часа до суток.

Более современный вариант холодного резерва — Backup as a Service (BaaS). В этом случае клиент платит уже не за ресурсы, а за хранение резервных копий данных в облаке поставщика услуги. То есть, при форс-мажоре все ИТ-сервисы компании-заказчика запустятся в облаке BaaS-провайдера.

Теплый резерв

В этом случае в облаке хранятся не сами данные, а их вторые копии (реплики). При этом обеспечивается постоянная синхронизация данных. Время простоя того или иного сервиса при форс-мажоре очень небольшое, если сравнивать теплый резерв с холодным. Всего 5-15 минут. Точное определение времени переключения на резервные копии определяется при разработке решения для конкретного заказчика и зависит от того, данные за какое время бизнес готов потерять. На стоимость самого теплого резерва это не влияет.

Плюс теплого резерва в том, что уже создана минимальная инфраструктура. В случае форс-мажора необходимо лишь добавить определенное количество ресурсов к тем сервисам, что уже есть и работают. И перевести их в продуктивный режим. Это быстрее, чем при холодном резерве, но несколько дороже. Потому что надо платить уже за минимальную ИТ-инфраструктуру. И, конечно, нужны некоторые изменения, в отличие от холодного резерва: где-то стоит провести миграцию сервиса, где-то изменить редакцию ПО на поддерживающую отказоустойчивый режим работы.

Горячий резерв

В этом случае у компании есть все копии данных. Они абсолютно такие же, как в продуктивной системе, если есть механизм синхронной репликации. Или же очень незначительно отстают от «продуктива» (на 3-5 минут). Соответственно, у компании есть все сервисы, причем они настроены. Есть все актуальные на момент форс-мажора данные. Отмечу, что сервисы должны быть построены так, чтобы обеспечивать автоматическое переключение на резервную копию инфраструктуры. При холодном или теплом резерве участие человека в переключении подразумевается по умолчанию (администратор, оператор, инженер). При горячем резерве всё наоборот: по умолчанию подразумевается, что человек в переключении не участвует. Время простоя при переключении ИТ-инфраструктуры компании на горячий резерв —0-5 минут. Однако, отмечу, что далеко не каждой компании он так уж необходим. ИТ-сервисов, для которых нужно немедленное резервирование, в современной организации не так уж и много — не более 20% от общего количества (IP-телефония для call-центра, платежные системы для финансовых компаний, сервисы, отвечающие за работу складов и логистику для транспортных и производственных компаний и др.).

Кому и что интересно в первую очередь?

Здесь определяющую роль играет масштаб организации.

Enterprise — теплый или горячий «дубль»

Если у крупной компании уже есть высокодоступные отказоустойчивые системы (у нее резервируется все оборудование), но они пока не обладают катастрофоустойчивостью (все сервисы в одной локации), то ей можно рекомендовать облачные ресурсы в теплом или горячем резерве. В свете того, что ИТ-бюджеты продолжают урезать даже в сегменте Enterprise, это более чем актуально для производственных, транспортных и торговых предприятий с территориально распределенной структурой. Тогда отказы многочисленных серверов, коммутаторов, падения интернет-каналов — то есть 95% проблем, связанных с катастрофоустойчивостью — не страшны ни их головным офисам, ни многочисленным региональным отделениям. Исключая моменты, когда вся площадка может уйти в офлайн (длительное отключение электричества, обрыв кабеля, серьезная ошибка инженера — например, удаление данных из СХД). Однако, здесь нужно очень точно считать, сколько ресурсов и в каком резерве действительно выгодно. Кроме того, у компании должна быть современная ИТ-инфраструктура и все нужные ИТ-компетенции в штате или на аутсорсинге.

Средняя компания — и тепло, и горячо, и холодно

Средним предприятиям стоит внимательно рассматривать и просчитывать все три варианта резерва, --- в зависимости от потребности компании в ресурсах. Если сервисов много (10+), то держать их горячие резервы может оказаться слишком накладно. А если сервисов, скажем, до 5 и все они --- ключевые (электронная почта, файловый сервис, 1С, CRM, CLM, специализированные сервисы, управляющие складом и логистикой), то горячий резерв и траты на него вполне оправданы. Но всё же, именно теплый резерв как правило оказывается оптимальным. Он дороже холодного в несколько раз, так как требует и больших расходов на размещение и актуализацию ресурсов в облаке. А также проработанной проектной части (подключения ИТ-специалистов, которые все настроят и реализуют, подготовят детальный план по переключению на резервную копию ИТ-инфраструктуры — не только для себя, но и для сотрудников заказчика). Но, одновременно, он выгоднее горячего резерва. И при этом совершенно приемлем для большинства организаций и их ИТ-сервисов — выгоды теплого резерва (например, экономия ИТ-бюджетов в 3-5 раз по сравнению с оплатой горячего резерва) не перевешивают ущерб от того, что организация выбрала чуть большие задержки при переключении на зарезервированные ресурсы.

Малый бизнес — холодный, максимум, теплый резерв

Для небольших компаний актуальнее всего холодный, максимум — теплый резерв ресурсов. Потому что компании в 10-50 человек крайне невыгодно дублировать всю инфраструктуру (представьте: два интернет-провайдера, два комплекта сетевого оборудования, два комплекта серверов). Намного проще и выгоднее заключить договор на аренду ресурсов или настроить резервное копирование в облако к провайдеру, который позволяет там же восстановить инфраструктуру. Ежемесячные (а то и ежегодные!) платежи в 10-20 тысяч рублей (в зависимости от стоимости услуг у конкретного провайдера и объема данных компании) вполне посильны для любого небольшого предприятия. То есть, холодный резерв стоит совсем недорого, а вот проблем решает сразу массу: данные компании не теряются из-за сбоев электропитания и других форс-мажоров, из-за участившихся атак вирусов-шифровальшиков и вымогателей. Это тем более важно, если небольшая компания не может позволить себе даже малейших простоев (занимается, например, продуктами питания или ведет финансовые операции).

Как избежать самых частых ловушек и рисков при резервном копировании данных в облако

Допустим, организация выбрала вариант, когда облако IaaS-провайдера — целостное решение и отдала «на откуп» ЦОД все вопросы, связанные с отказо- и катастрофоустойчивостью ключевых сервисов. По каким критериям ей стоит выбирать ЦОД?

Соблюдение стандартов (Tier/Uptime Institute) Нужно выяснить, прошел ли ЦОД проверку на соблюдение стандартов Tier 1, Tier 2, Tier 3 или же просто заявляет, что соответствует нужному уровню. Реальное соответствие стандартам при проектировании и тем более при построении ЦОД — отличная заявка на надежность: эти проверки, действительно, дороги и сложны. И если ЦОД их прошел, риски клиентов сильно снижаются. Сертификация по Uptime Institute — еще одна гарантия правильного выбора ЦОД. Эта проверка тоже не слишком простая. Если ЦОД ее действительно прошел, он гарантированно обеспечит заказчика услугами высокого уровня.

Правильное распределение ИТ-сервисов между площадками ЦОД Наличие ЦОД с несколькими локациями — бесспорное преимущество. Однако просто взять две площадки и разделить ИТ-сервисы между ними — это решение, которое ничего не дает корпоративному клиенту. А вот если объем вычислительных ресурсов правильно распределен между площадками, и компания может без труда резервировать критичные сервисы, то тут преимущество для бизнеса очевидно. В момент ухода одной площадки в офлайн тут же включится вторая --- и пользователи продолжат работу, не заметив перерыва.

Отсутствие «риска плохого соседа» Совместное использование ЦОД-ом ресурсов сети, аппаратного и программного обеспечения может привести к ситуации, когда какой-либо корпоративный заказчик «узурпирует» те или иные ресурсы, что создаст «бутылочные горлышки», снижающие производительность ИС у других клиентов ЦОД. Простейший случай — когда нехватка ресурсов вообще лишает других заказчиков возможности нормально работать. А так как сервисы могут перемещать между серверами, СХД, узлами, разными ЦОД, в любой момент может оказаться, что компания делит ресурсы с таким «узурпатором». Конечно, существует специализированное программное обеспечение, которое может регулировать потребление ресурсов, но и тогда мало какой ЦОД может гарантировать, что ресурсы не перетянет «сосед». Однако если ключевые ИТ-сервисы находятся и на своей площадке, и в облаке, то шансов на «плохого соседа» намного меньше. Распространенная ошибка при выборе ЦОД связана как раз с тем, что современные организации или не подозревают об этой проблеме или не могут ее четко сформулировать. Или же не сознают ее масштабов и степени влияния на ситуацию.

Риск попадания под DDoS-атаку Компания может пострадать, если делит интернет-канал с популярным сайтом, на который идет атака. Даже если у такой компании есть теплый или холодный резерв ресурсов, может остановиться репликация данных. А это ведет к проблемам — все изменения, которые нужно передать, не передаются, а накапливаются на собственных сервисах. Если на дисках заканчивается свободное место, сервисы просто останавливаются. А когда каналы заработают, нужно будет разом передать большой объем данных. Это может сильно перегрузить каналы, потому что они не могут за 30 минут передать то, что должно было передаваться все прошлые сутки. Здесь заказчикам можно посоветовать не выбирать IaaS-провайдера, ориентируясь только на стоимость услуг. Скорее всего, их качество тоже окажется очень и очень низким.

Рекомендации для системных администраторов, отвечающих за данные

Заранее проработать все процедуры по переключению на резервную копию. Обязательно протестировать это переключение. Часто бывает, что ИТ-специалист резервирует виртуальную машину (ВМ) в холодном резерве и пытается ее восстановить. А с такими характеристиками нельзя создать ВМ у этого провайдера — ей нужно слишком много памяти или процессоров. Поэтому резервная копия создается, а вот восстановить из нее информацию не получается. Или восстановление занимает слишком много времени («есть все копии — сейчас я нажму и все восстановится»). Если реакция системы на это «нажму» — долгие часы или даже дни, а специалист не выявил этого заранее, на резервном копировании можно смело ставить крест. Бизнес не готов столько ждать. Здесь нужно сразу понимать: переключиться на резерв не получится, стоит искать другой вариант. А не ждать форс-мажора, который выявит эту проблему в самой острой форме.

Не забывать о пользователях. Резервное копирование — это не просто работающие площадки, благополучно запущенные ключевые ИТ-сервисы и актуальные данные. Это, прежде всего, люди. Поэтому успех стратегии резервного копирования измеряется тем, а могут ли пользователи компании работать с привычными ИТ-сервисами. Можно раздать новые параметры ИТ-сервисов централизованно. Или подготовить аварийные ярлычки доступа вместе с инструкциями (теперь сервис находится вот по этому адресу). Плюс предоставить доступ к терминальному серверу, чтобы люди могли работать удаленно. При этом нельзя забывать о пользователях, работающих, скажем, с каким-то особым локальным принтером. Или, например, о терминальном сервере, на котором нужно использовать специфическое оборудование (веб-камеру, голос). А у вас ЦОД так далеко, что задержки слишком большие. И пользоваться сервисами ВКС будет мучительно или вовсе невозможно.

Помнить о честной проверке. Бывает и так, что при возникновении нештатной ситуации нужно открыть аварийный план или инструкцию, где сказано, как переключить все на резервную копию. Но оказывается, что эти документы находятся на сервере, который уже не работает. А их копия — на внутреннем портале, который тоже не работает. Пароли провайдера DNS также могут остаться во внутренней базе знаний системных администраторов. Поэтому важно провести максимально честную проверку — не тогда, когда все работает. А тогда, когда имитируется реальный сбой, никуда нет доступа и т.п. Такая проверка исключительно важна, потому что компания может потратить миллионы на резервное копирование, а окажется, что подключиться к ЦОД практически невозможно. Кроме предельно честной проверки (например, подключить рабочее место к локальной сети, не имея под рукой привычных инструментов и основных инструкций) важно, чтобы у пользователей был распечатан план действий на случай сбоя, а у администраторов были бумажные инструкции. Или инструкции в стороннем облаке и на бумаге.

Итого

При выработке стратегии резервного копирования важно не идеализировать облако, не думать, что «там никогда ничего не ломается». Если данные компании-заказчика пропадут, IaaS-провайдер будет готов вернуть деньги за последний месяц. И это по максимуму! Но потерянных данных это не вернет, а ключевые ИТ-сервисы (почта, CRM, CLM и др.) не заработают. Облако — это тоже инструмент, который точно так же может ломаться. И лучше резервировать свои данные, находящиеся и там. Мы сами при размещении в нашем облаке (ALP Cloud) рекомендуем нашим клиентам хранить резервные копии еще и на другой площадке. Это ответственный подход к важным данным, и он себя полностью оправдывает.