28 Апреля 2021 12:36 28 Апр 2021 12:36 |

Поделиться

Экспертиза: зачем российским компаниям нужны технологии аварийного восстановления

Disaster Recovery: каким компаниям и зачем это нужно

Как правило, Disaster Recovery востребован крупным и средним бизнесом, чья деятельность связана с обработкой больших объемов данных и напрямую зависит от непрерывности работы информационных систем. К примеру, это ритейл, интернет-компании, банки и страховые организации, а также производственный сектор

Если говорить с точки зрения облачных технологий, то Disaster Recovery — это облачный сервис для резервирования и восстановления ИТ-инфраструктуры компаний. «Заказчику предоставляется резервная площадка в облаке, где он может резервировать свои информационные системы. И, в случае сбоя или аварии на собственной ИТ-инфраструктуре, — быстро восстанавливаться с минимальными временными потерями», — поясняет Елена Синегубкина, руководитель IaaS-направления #CloudMTS.

К одному из ключевых показателей, которые характеризуют процессы Disaster Recovery, относится RPO (Recovery Point Objective). Этот показатель отражает максимальный период времени, за который могут быть потеряны данные в результате инцидента. Например, если RPO составляет тридцать минут, то не может быть восстановлено только то, что было наработано в течение этих последних тридцати минут. Все, что было сделано раньше, можно будет восстановить. «В нашем облаке показатель RPO составляет не более 5-15 минут», — говорит Елена Синегубкина.

Компании могут воспользоваться несколькими сценариями Disaster Recovery. Во-первых, зарезервировать в облаке собственную виртуальную ИТ-инфраструктуру. Во-вторых, организовать и основную, и резервную площадки в облаке провайдера на базе территориально распределенных дата-центров. По словам эксперта, основная облачная услуга провайдера — IaaS, базируется на стеке продуктов VMware. Поэтому для сервиса Disaster Recovery выбрано решение этого же вендора vCloud Availability.

Время, необходимое для восстановления

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

Здесь стоит упомянуть про еще один важный показатель, обязательный к определению в процессе планирования Disaster Recovery. Речь идет о RTO (Recovery Time Objective). Это промежуток времени, в течение которого система может оставаться недоступной в случае аварии. Его можно рассчитать самостоятельно или с помощью провайдера. После этого составляется план аварийного восстановления, способный обеспечить требуемое значение.

«Если у компаний по каким-то причинам нет такого плана или они хотят его актуализировать, то наши специалисты по Professional & Managed Services готовы помочь и разработать план аварийного восстановления. К примеру, провести аудит и понять, какие системы надо резервировать в первую очередь», — уточняет Елена Синегубкина.

Отличия облачного Disaster Recovery от резервного копирования

Аварийное восстановление как сервис (DRaaS) и создание резервных копий предназначены для разных целей. По словам Елены Синегубкиной, оба инструмента востребованы бизнесом. Основная цель бэкапа — не потерять данные в случае аварии. DRaaS же предназначен для того, чтобы свести к минимуму время простоев ИТ-систем.

Бэкап делается с определенной периодичностью, обычно раз в сутки в ночное время. Компании, которая делает только резервное копирование, в случае нештатной ситуации нужна будет ИТ-инфраструктура, куда можно будет восстановиться. Иными словами, бэкап не дает компании площадку, на которую можно будет перенести ИТ-системы и продолжить работать с ними, пока налаживается работоспособность основной площадки. Также нужно будет время для восстановления, которое, в зависимости от объема данных, может измеряться часами или даже днями. Кроме того, может случиться так, что последняя резервная копия не будет консистентной. Значит, придется восстанавливаться из предыдущей, — а это потеря данных и увеличение времени на восстановление.

Disaster Recovery as a Service предполагает, что в облаке провайдера уже есть резервная ИТ-инфраструктура, на которую можно восстановить системы. Она идентична основной площадке, на которой работают ИТ-системы клиента. Как правило, в рамках резервной площадки ИТ-специалисты компаний сами создают виртуальные машины, настраивают внутренние локальные сети. В случае необходимости с этим может помочь и облачный провайдер.

«В зависимости от заданной периодичности, допустим, каждые 15-30 минут в течение дня, происходит репликация виртуальных машин на резервную площадку в облаке», — добавляет Елена Синегубкина. Благодаря этому можно в любой момент восстановиться на резервной площадке и продолжить работу. При этом не обязательно восстанавливать все системы: если нештатная ситуация затронула только одну, то можно восстановить только ее. Немаловажно и то, что после восстановления основной площадки можно переключиться на нее и продолжить работать.

Исчезает ли необходимость бэкапов, если используется Disaster Recovery?

Многое зависит от специфики резервируемых систем и индивидуальных политик компании. К примеру, можно делать Disaster Recovery для критичных бизнес-систем, а бэкап — для менее критичных. Для того чтобы обеспечить надежность и непрерывность бизнеса, многие заказчики делают и то, и другое одновременно.

К примеру, одна из крупных логистических компаний резервирует в рамках Disaster Recovery системы «1С» на облачную площадку. «При этом основная площадка клиента также находится в облаке МТС в Московском регионе. Объем реплицируемых данных составляет около 8 Тб. Параллельно компания использует и услуги облачного резервного копирования», — рассказывает Елена Синегубкина. Таким образом, компания выполняет все внутренние политики по резервированию данных, имеет четкий план аварийного восстановления с определенными RPO и RTO.

Критерии выбора: на какие характеристики DRaaS надо обращать внимание

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

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

«Наша базовая услуга — аварийное восстановление из облака клиента на основе VMware на нашу облачную площадку, — приводит пример Елена Синегубкина. — Мы планируем реализовать возможность резервирования инфраструктуры с других платформ виртуализации. Например, Hyper-V или OpenStack, которые также востребованы. Существуют продукты, например, на базе технологий CommVault, которые путем конвертации позволяют делать репликацию с разных платформ виртуализации в облако провайдера, но стоимость таких решений будет значительно выше».

Еще один важный критерий при выборе площадки для Disaster Recovery — это характеристики платформы облачного провайдера. Например, для работы систем «1С» требуется процессор с частотой 3,1-3,5 Ггц. Если у провайдера в облаке нет таких процессоров, то после восстановления система будет работать очень плохо или вообще не заработает. Проблема может возникнуть и тогда, когда клиент использует, например, для баз данных виртуальные машины с объемом оперативной памяти более 512 Гб. Не каждое публичное облако поддерживает такие показатели. Кроме того, и компании, и провайдеру важно понимать, какие операционные системы используются. Это имеет значение для корректного восстановления приложений внутри виртуальных машин на резервной площадке провайдера.

И, конечно, не надо забывать про каналы связи. У многих провайдеров репликация происходит через интернет, а значит, надо обеспечить достаточную пропускную способность канала — не менее 1 Гбит/сек.

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

Также важна география расположения площадок провайдера. Если вы делаете Disaster Recovery со своей on-premise площадки, то лучше выбирать резервную площадку в вашем же регионе. Делать репликацию большого объема данных, к примеру, из Владивостока на площадку в Санкт-Петербурге не всегда эффективно.

Как выбрать оптимальные условия сервиса DRaaS?

На выбор оптимальных условий влияет все перечисленное выше. Если провайдер предоставляет возможность бесплатного тестирования сервиса, надо обязательно ей воспользоваться. «У нас был случай, когда клиент хотел перенести в облако виртуальную машину с очень большим объемом диска — более 5 Тб. По каким-то причинам настроить репликацию не удавалось, — рассказывает Елена Синегубкина. — Наши специалисты выяснили в чем причина и устранили ее. Далее провели тестовые аварийные восстановления. Таким образом, в процессе тестирования клиент убедился, что все работает корректно, и в случае необходимости ему поможет служба технической поддержки».

Безопасность при резервировании и восстановлении ИТ-инфраструктуры

Как правило, в облаке провайдера безопасность обеспечивается на нескольких уровнях. Во-первых, это сетевой уровень. Например, у #CloudMTS при передаче данных через интернет используется встроенное TLS-шифрование, также происходит сжатие трафика репликации. К тому же, имеется возможность использования VPN-каналов.

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

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

Последнее особенно важно, если компания использует DRaaS для своего внешнего сайта. Например, дистрибьютор лакокрасочных материалов размещает собственное ИТ-оборудование с информационными системами в стороннем дата-центре. Компания столкнулась с частыми сбоями и простоями на арендуемой площадке. Перемещение оборудования в другой дата-центр повлекло бы за собой долгий простой в работе систем. Поэтому компания приняла решение использовать сервисы Disaster Recovery. «ИТ-специалисты дистрибьютора делают репликации со своей on-premise инфраструктуры, размещенной в стороннем дата-центре, на площадку #CloudMTS. Объем реплицируемых данных составляет около 3 Тб», — добавляет Елена Синегубкина.

Развитие DRaaS: что нас ждет в будущем

Главный тренд сегодня — это мультиоблачность. Компании зачастую используют решения разных поставщиков с разной виртуализацией. Это значит, что Disaster Recovery должен осуществляться между разными виртуальными платформами. «Мы тоже движемся в этом направлении. Например, для резервного копирования мы используем продукты Commvault, Acronis, Veeam. Они постоянно развиваются и позволяют делать репликацию виртуальных машин с площадки клиента в облако провайдера в рамках Disaster Recovery, — рассказывает Елена Синегубкина. — При этом в некоторых решениях доступна конвертация с одной системы виртуализации на другую. Эти же продукты используются для миграции виртуальных машин, например, если клиент переезжает к нам в облако».

Поделиться

Короткая ссылка