LanCloud запустил облачный сервис аварийного восстановления серверов

LanCloud вывел на рынок сервис Cloud DRaaS (Disaster Recovery as a Service) с целью предоставления заказчикам готового инструмента, позволяющего добиться оперативного аварийного восстановления ИТ-инфраструктуры с минимальной потерей данных. Cloud DRaaS – это облачный сервис быстрого аварийного восстановления работы виртуальных серверов в резервном центре обработки данных LanCloud в случае частичного или полного отказа основного ЦОД Заказчика. Сервис Cloud DRaaS обеспечивает постоянную асинхронную репликацию всех виртуальных серверов из основного ЦОД клиента в резервный ЦОД LanCloud. В случае сбоя основного ЦОД, активируется процедура Failover, и все виртуальные машины автоматически начинают работать в облаке LanCloud. Сервис Cloud DRaaS обеспечивает показатели RTO и RPO не более 15 минут. Cloud DRaaS построен на базе решений Veeam Backup & Replication и Veeam Cloud Connect. В ЦОД Заказчика устанавливается сервер Veeam BackUp & Replication, который реплицирует виртуальные машины в Veeam Cloud Connect в облаке LanCloud. В случае сбоя, Заказчик активирует процедуру аварийного переключения, и все виртуальные серверы запускаются в облаке LanCloud. При этом, автоматически устанавливается L2 VPN-туннель до инфраструктуры заказчика, что позволяет всем серверам оставаться доступными по внутренней сети по тем же самым IP-адресам. При восстановлении основного ЦОД, администратор может запустить процедуру обратного переключения – Failback, и все серверы будут обратно отреплицированы и запущены в ЦОД Заказчика с актуальными данными. Помимо процедуры аварийного переключения, заказчикам доступны функции тестового запуска виртуальных серверов в облаке без влияния на продуктивную инфраструктуру, а также функции восстановления отдельных файлов и приложений из облачных реплик, аналогично обычному резервному копированию. Таким образом, облачный сервис Cloud DRaaS позволяет значительно снизить риски, связанные с утерей данных и простоем бизнеса, без капитальных вложений в ИТ-инфраструктуру. Большинство заказчиков, даже обладая отказоустойчивыми кластерами виртуальных машин, и регулярно выполняя резервное копирование всех критичных для бизнеса данных, не уделяют достаточного внимания плану аварийного восстановления (DRP – Disaster Recovery Plan). И, столкнувшись с каким-либо серьезным сбоем, например, отказом кластера виртуальных серверов, выходом из строя продуктивной системы хранения данных или иной техногенной катастрофы ЦОД, в том числе изъятие оборудования правоохранительными органами, компания оказывается в экстренной ситуации, к которой не была заранее готова. Обычно в такой момент выясняется, что даже имея на руках все необходимые резервные копии, если они хранились на другом оборудовании в другом дата центре, у компании: отсутствует резервное оборудование, на котором можно бы было запустить всю серверную инфраструктуру; даже если резервное оборудование присутствует, время восстановления составит несколько дней или недель, в зависимости от объема данных; актуальность данных в резервных копиях составляет несколько дней или недель до момента сбоя, и даже после завершения процедуры восстановления, вся информация, накопившаяся с момента последнего резервного копирования, будет утеряна. Такие события зачастую приводят к многомиллионным убыткам для бизнеса и, как следствие, банкротству компании. Чтобы быть готовой к подобного рода инцидентам, каждая компания должна иметь заранее подготовленный DRP-план. DRP-план или план аварийного восстановления - это документ, описывающий последовательность действий, которые должны быть выполнены, чтобы восстановить работу ИТ-инфраструктуры в случае того или иного сбоя или катастрофы в основном ЦОД. Двумя важнейшими параметрами DRP-плана являются параметры: RTO и RPO. RTO (Recovery Time Objective) – это время необходимое на полное восстановление работы после сбоя. RPO (Recovery Point Objective) – это точка восстановления, или по-другому – на какой момент времени до сбоя будет восстановлена вся информация компании. В свою очередь, каждый бизнес должен определить, какие параметры RTO и RPO являются для него приемлемыми при наступлении неблагоприятных событий. Чем меньше эти показатели – тем лучше. Но если речь идет об обеспечении RTO и RPO не более нескольких минут, то очевидно, что простое резервное копирование здесь не поможет. Ссылка на источник