Журнал ТЗ №3 2017 |
  бюро находок  
  Где искать        
наши издания
наши анонсы






2017
№3
статьи



Журнал ТЗ №3 2017



Раздел: ВЗГЛЯД
Тема:
Автор: Диана КОЧИЕВА, Лев КАВЕЛИН, компания «Окей-Телеком»

Состояние ИТ-инфраструктуры — лакмусовая бумажка производительности и работоспособности бизнеса

Доктор! У меня DRaaS на базе OpenStack! Это не опасно?

Этот материал адресован бизнесам, использующим для размещения своих приложений платформу виртуализации VMware vSphere. Мы расскажем об услуге, которая нужна большинству современных компаний, в практике которых используются автоматизированные процессы. По-английски эта услуга называется Disaster Recovery as a service, а по-русски – резервная площадка как услуга.

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

Предположим, у нас есть строительная компания с нагрузкой в 300 виртуальных машин, которая пользуется продуктом VMware vSphere. Руководитель IT-отдела однажды приходит к выводу, что пора бы задуматься о регламенте работы в случае ЧП, ведь большая часть нагрузки критична, если инфраструктура выйдет из строя, работа компании попросту встанет. Компания решает обратиться к сервис-провайдеру.

Как это работает
Сервис-провайдер создает план Disaster Recovery. После этого совместно с клиентом план корректируется с учетом индивидуальных потребностей компании. Подготовка такого плана для среднего бизнеса с 300 виртуальными машинами на основной площадке займет около двух-трех недель. Важно учесть: виртуальные машины должны быть запущены в правильном порядке, так же как было на основной площадке. Условно сначала базы данных, потом уже клиентские части. Если нарушить последовательность, то в самый ответственный момент DR просто не сработает.

Сервис-провайдер ставит на инфраструктуру клиента программу, которая инициализирует виртуальные машины и топологию сети, после чего начинает процесс односторонней синхронизации данных между основной площадкой и облачной платформой сервис-провайдера. Данные копируются непрерывно с момента запуска этого процесса, с заранее определенной периодичностью, которую может задать сам клиент (раз в три часа, раз в 10 минут, как угодно). Передаются данные по защищенному каналу, хранятся в облаке в трех копиях, в надежных и физически защищенных дата-центрах уровня Tier 3 по сертификации Uptime Institute. В рамках функционала Disaster Recovery есть возможность хранить данные за несколько месяцев.

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

«Виртуалки» запускаются одна за другой в заданной последовательности: первыми идут машины с критическими сервисами.

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

Более того, теперь сотрудники знают, что именно может произойти и как в таком случае должна вести себя система, – возможные сценарии ЧП прорабатываются на тестовых запусках резервной площадки. Такие «репетиции» специалисты компании могут самостоятельно запустить в любой момент. Это дает возможность при желании время от времени проверять исправность инфраструктуры и актуальность DR-плана, оценивать время запуска критических приложений или всей инфраструктуры в целом.

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

Это уже было: опыт VMware – как вендора жадность сгубила

Раньше у руководителя IT -отдела компании, которая использует VMware, был только один вариант действий: создать резервную площадку все на той же коммерческой платформе.

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

После того как совокупная стоимость всего этого будет посчитана, станет понятно, что тратить такое количество денег за площадку, которая будет большую часть времени простаивать, компания не станет. Так бизнес остается уязвимым.

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

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

OpenStack, в свою очередь, оправдывает доверие – это быстро растущий стабильный продукт, который исключает любую привязку к одному вендору. Ведь казалось бы, использование решений VMware и на продакшене, и при построении DR должно облегчить клиенту жизнь: ты имеешь один сет экспертизы, поддержку тебе могут оказать на двух площадках сразу. Но на деле выходит, что клиент надевает на себя кандалы лицензионных выплат и уже не может уйти к другому вендору.

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

Вторые посмотрели на первых и решили, что лучше на обеспечении надежности не экономить, глупо полагаться на «авось пронесет», если речь идет о бизнесе. Ведь если вы не готовы сегодня, уже завтра вы можете потерять все. Именно поэтому мы убеждены, что услуга Disaster Recovery нужна каждому, у кого есть IT -инфраструктура.

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

Мало того что вы (равно как и арендодатель), вероятно, потребуете от сервиса возместить вам ущерб, так они еще и потеряют вас как клиента. А если бы владельцы площадки озаботились планом аварийного восстановления, устранение проблемы заняло бы гораздо меньше времени.

Что все это значит?
Разбор услуги Disaster Recovery с технической стороны показывает, что устроен сервис аналогично решениям от VMware, таким как BCDR или vCloud Air Disaster Recovery. Отсюда можно сделать вывод, что DRaaS, организованный на технологии OpenStack, выгодно отличается от продуктов вендора ценой и возможностью свободно выбирать поставщика услуг. К тому же в рамках этого сервиса данные передаются по защищенному шифрованному каналу, хранятся в нескольких копиях, а доступ к ним имеют только технические специалисты клиента и авторизованный сотрудник сервис-провайдера.

Внимание! Копирование материалов, размещенных на данном сайте допускается только со ссылкой на ресурс http://www.tzmagazine.ru

Рады сообщить нашим читателям, что теперь нашем сайте работает модуль обратной связи. Нам важна ваша оценка наших публикаций! Также вы можете задавать свои вопросы.Наши авторы обязательно ответят на них.
Ждем ваших оценок, вопросов и комментариев!
Добавить комментарий или задать вопрос

Правила комментирования статей

Версия для печати

Средняя оценка этой статьи: 0  (голосов: 0)
Ваша оценка:

назад
|

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



IBM меняет представление о передаче и хранении видео. Впервые на All-over-IP 2017!
Сравните ваш взгляд на интеллектуальное видеонаблюдение с мнением руководителей корпорации IBM на 10-м форуме All-over-IP 2017.



Бесшовная запись - возможности технологии Smart Failover
Что делать в ситуации, когда возникает разрыв связи между IP-камерой и IP-видеорегистратором (NVR)?



Реклама
Подписка на новости
Имя
E-mail
Анти-спам код
Copyright © 2008 —2017 «Технологии защиты».