Думаю, никто не будет спорить, что наличие надежного бекапа и резервной инфраструктуры — это всегда хорошо. Количество природных и техногенных катастроф в мире растет с каждым годом, а ущерб от них измеряется сотнями миллиардов долларов. Пусть шанс пострадать от крупного происшествия не так велик, зато с локальными неприятностями в духе отключения электричества, затопления или пожара в серверной мы сталкиваемся достаточно часто.

Всякое бывает — иногда бизнесу мстят обиженные сотрудники, иногда оборудование изымают правоохранительные органы, иногда зарубежные IP-адреса случайно попадают под блокировку Роскомнадзора, а однажды в локальную серверную нашего заказчика вообще въехал грузовик — прямо через стену с улицы.



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

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

Сложность в том, что если вы с задачей резервирования придете к системному интегратору, то в соответствии с накопленным опытом вам скорее всего предложат проверенный временем подход с анализом бизнес-рисков, разработкой DRP и решением на базе оборудования с функционалом аппаратной синхронизации. Помимо высокой стоимости, такие решения обладают еще одним минусом — их сложно внедрить без существенной модернизации основной площадки, которую как правило лишний раз трогать никому не хочется.

Тем не менее для действительно критичных бизнес-систем это обоснованные риски и затраты, потому что иначе нельзя, однако как быть, если системы недостаточно критичны для «взрослого» и красивого проекта?

Можно, разумеется, смириться и не делать ничего, а если что-то все-таки случится, развести руками и получить по шапке от бизнеса. Можно подрядить интегратора на расчет резервного ЦОДа, сделать пилот, оценить бюджет, презентовать решение бизнесу, получить в ответ «денег пока нет» и отложить проект до лучших времен. Это, конечно, не спасет компанию от простоя, но и претензии в случае форс-мажора ИТ-отделу предъявить сложно, потому как «ну мы же вам предлагали», да и новые знания о рынке DR-решений не будут лишними. Такие варианты тоже имеют право на жизнь, однако бизнес может и не пережить потерю данных, и тогда придется искать новую работу.



Можно не вкладываться в полноценный резервный ЦОД, однако облегчить себе жизнь на будущее, настроив вторичный (или даже первичный) бекап данных в облако. Сегодня услуги BaaS (backup as a service) предлагают многие сервис-провайдеры, причем на базе самого разного ПО. Если у себя внутри вы пользуетесь каким-то популярным решением для резервного копирования, то наверняка сможете найти подобный сервис с удобной нативной интеграцией с вашим текущим ПО. Либо, как вариант, можно арендовать у провайдера недорогое S3-совместимое хранилище и складывать бекапы туда — работу по протоколу S3 сегодня поддерживают решения многих вендоров. Плюсы такого подхода очевидны — за приемлемые деньги вы получаете страховку от риска остаться без физического доступа к данным и возможность восстановиться в том же самом облаке при необходимости.

Насколько быстро вы сможете поднять свои системы из бекапа, зависит от затраченных ранее усилий на тестирование, наличия предоплаченного пула ресурсов для восстановления и написанной совместно с сервис-провайдером DR-процедуры. Однако даже если у вас есть только голый бекап, вы свои бизнес-системы в облаке все равно запустите, пусть и не очень оперативно, а поддержка поставщика BaaS вам в этом поможет.



А что если ущерб от простоя ИТ-систем для всех очевиден, но не настолько велик, чтобы тратиться на полноценный DR-проект с анализом бизнес-рисков и оснащением и второй площадки?

Здесь на помощь снова приходят сервис-провайдеры, предлагающие облачную инфраструктуру, уже распределенную по нескольким географическим площадкам. Нужно лишь перенести ваши серверы в облако, а обо всем остальном позаботится поставщик услуги.

Если переходить в облако целиком по каким-то причинам не хочется (например, если не так давно потратились на свое собственное железо и серверную), то подойдет вариант с софтверной синхронизацией в cloud нескольких особо ценных серверов. У облачного провайдера можно взять в аренду вычислительные ресурсы и сторадж, доступное ПО синхронизации и отдать развернутое DR-решение на поддержку. Это достаточно удобный вариант, и вам необязательно оплачивать обследование своих ИТ-систем, подготовку технического проекта и прочие этапы полноценного проекта — можно ограничиться недорогой типовой настройкой.

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



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

Подобные истории на самом деле знакомы многим ИТ-руководителям. Пару лет назад мы выполняли cloud ready обследование в инжиниринговой компании, и одной из предпосылок перехода в облако стала медленная работа бизнес-систем. Все данные приложений лежали на хранилище начального уровня, и его производительности банально не хватало. Однако во время аудита мы обнаружили у клиента отличный mid-range сторадж от именитого вендора, выполняющий роль файлового обменника. В ответ на наш немой вопрос «почему?» заказчик поведал историю о потере данных из-за редкого бага и нежелании рисковать еще раз, хотя вендор баг давно поправил.

Собственно, и в практике ActiveCloud было немало ситуаций, когда купленное железо не получилось использовать под изначальные цели, либо оно было введено в бой с задержкой в несколько месяцев. Стоит ли брать эти риски на себя, когда можно переложить их на провайдера, вопрос интересный.

---

ActiveCloud предлагает своим клиентам как сервис бекапирования в облачное хранилище на базе ПО Veeam, так и сервис горячего резервирования в cloud на базе ПО Carbonite (ex-Double-Take). Cервисы позволяют периодически бекапировать либо в реальном времени синхронизировать с облаком железные и виртуальные серверы на всех популярных гипервизорах. Услуги предлагаются по арендной модели и включают все необходимое: ресурсы облака, необходимый софт, поддержку 24х7 и быструю стартовую настройку.



Если у вас есть подобная задача и желание ее обсудить – напишите на dmitriy.yashin@activecloud.ru.