Павел Рыцев, ИТ-директор, руководитель Центра компетенции по импортозамещению и Open Source в ALP Group

Основной запрос со стороны любого бизнеса – обеспечение сохранности данных, а также высокой доступности, отказоустойчивости и катастрофоустойчивости главных ИТ-сервисов (электронной почты, 1С, CRM, CLM, систем управления складом и т. д.). Сегодня эти задачи все чаще решаются с помощью резервирования ресурсов в облаке. Здесь возможны два варианта: в первом облако IaaS-провайдера – это целостное решение; во втором – только часть решения, обеспечивающая холодный, теплый или горячий резерв ресурсов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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