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






2017
№ 4
статьи



Журнал ТЗ № 4 2017



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

Надежность и безопасность ИТ-инфраструктуры: миграция на OpenStack


В эпоху тотальной автоматизации, когда дело касается корпоративной инфраструктуры, бизнес особенно обеспокоен вопросом ее безопасности. Опытные руководители ИТ-отделов понимают: если вся площадка или какая-то ее часть выйдет из строя, большинство бизнес-процессов остановится. Это сулит серьезные неприятности: по данным агентства Aberdeen, финансовые потери за час простоя инфраструктуры составляют в среднем 164 000 долларов. Спрашивать за убытки и недополученную прибыль в этом случае будут с ИТ-отдела. Осознавая всю степень ответственности, ИТ-менеджеры пытаются добиться от руководства выделения бюджета на приобретение сервиса Disaster Recovery (восстановление после сбоев). Однако часто получают отказ – слишком дорогое удовольствие. Но так ли это на самом деле?

И да и нет. Дело в том, что подавляющее большинство компаний использует в качестве платформы виртуализации продукты типа VMware vSphere, Microsoft Hyper-V и др. Разумеется, в случае использования коммерческого ПО клиент платит за лицензии. И платит, надо сказать, много – около 7500 долларов на один сервер с поддержкой на три года. Зато продуктив работает стабильно и все довольны. Как только разговор заходит о приобретении лицензий для резервной площадки, руководители компаний порой разводят руками. Потому что стоят они не меньше, чем на основную. А удваивать бюджет готовы не все. ИТ-отделу остается только ограничиваться резервными копиями. А где их развернуть, если инфраструктура выйдет из строя? Ответа на этот вопрос зачастую нет. План восстановления после аварий имеют только 55% компаний (согласно отчету Forrester Research и Disaster Recovery Journal). То есть потребность в DR испытывают многие, но спрос, особенно на российском рынке, сдерживается высокой стоимостью программного обеспечения. Конечно, вопрос в цене каждого часа простоя и в том, как руководство компании оценивает возможность аварии. Дополнительным фактором, тормозящим развитие рынка DR в России, можно назвать дефицит отечественных разработок в этой сфере.

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

При чем здесь Disaster Recovery, если речь в этой статье должна пойти о миграции с платформы VMware на OpenStack, спросите вы. Ответим: создание резервной площадки и плана восстановления данных – это самый очевидный, пусть и не единственный, сценарий миграции. Судите сами: вы проверили облако провайдера при работах по созданию резервной площадки, развернули копию своей инфраструктуры, провели «учебные пуски» DR-плана, возможно, использовали резервную площадку для нагрузочного тестирования новых приложений. Все это обошлось вам существенно дешевле лицензионных отчислений и платы за поддержку для основной площадки. В этом случае не только у технических специалистов, но и у бухгалтерии возникнет банальный вопрос: зачем платить больше? Тогда может быть принято решение о переносе основной площадки с VMware на OpenStack. Технически оба сервиса – DR и миграция – организованы идентично. Поговорим об этом подробнее.

Пошаговое руководство. Не все сразу

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

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

Как мигрировать данные: демо на пальцах

Попробуем описать, что именно происходит в момент миграции данных. По условию задачи мы имеем платформу виртуализации под управлением VMware vSphere, на которой расположено 22 виртуальные машины. Данные с них мы хотим перенести на резервную площадку в облако OpenStack. На основную инфраструктуру клиента, а конкретнее – на тот же хост, где располагаются виртуалки, которые мы собираемся защищать, – ставим так называемого агента. Это виртуальная машина, которая работает на Linux. Фактически заказчику дается ссылка на файл, который он загружает себе на vSphere, после чего агент начинает работать. Он запускается и исследует все виртуальные машины вокруг себя. Спустя пару минут в интерфейсе Hystax Acura (так называется описываемое решение) о них появляется информация, которую агент обновляет каждые 30 секунд.

Основное управление агентом происходит через административную панель, в которой администратор может просмотреть имена машин, их IP-адреса, дату последней репликации, размер и т. д. Здесь же можно при желании вручную отменить защиту какой-то конкретной машины. После сбора «агентурных данных» запускается full-репликация. Время, которое потребуется для того, чтобы перенести все данные в облако, зависит от ширины канала и размера реплицируемых машин. Но в среднем этот процесс занимает около получаса.

Обратите внимание: когда агент впервые ставится на инфраструктуру, все девайсы появляются в интерфейсе как незащищенные (unprotected). Нужно выбрать, какие машины (все или несколько) надо реплицировать, и запустить первую полную репликацию. Ее, к слову, проводят минимум раз в месяц из соображений безопасности. Но одной полной репликации данных недостаточно. Ведь данные на основной площадке постоянно изменяются. Поэтому время от времени по расписанию, которое выбирает заказчик, проводится инкрементная репликация: агенты отслеживают все изменения на инфраструктуре клиента и передают снапшоты в хранилище. Можно выбрать интервальную репликацию или непрерывную – здесь все зависит от поставленной задачи и предпочтений клиента.

Все реплицируемые данные лежат в хранилище. Чтобы сократить объем данных, подлежащих хранению, используется метод дедупликации. Если клиент отдал 200 терабайт, то по факту может храниться всего 100. Эффективнее применять этот метод, если реплицируемые машины работают на одной операционной системе или хранят повторяющиеся данные, тогда они будут отосланы и сохранены только один раз. Это, разумеется, скажется и на стоимости хранилища: платить клиент будет за реально занимаемое место. В случае аварии на основной инфраструктуре клиент просто нажимает на волшебную зеленую кнопку – и данные разворачиваются на резервной площадке.

Притча о волшебной кнопке

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

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

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

Заключение

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

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

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

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

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

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

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

назад
|

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



Новинка от компании IDIS: 5Мп IP-видеокамера DC-T3533HRX
Тенденции развития индустрии IP-видеонаблюдения демонстрируют погоню производителей за увеличением разрешающей способности видеокамер. При этом часто оказывается так, что озвучиваемые цифры в 4, 9, 12 и даже 20 мегапикселей оказываются несопоставимыми с физическими размерами сенсоров, используемых в этих камерах. Поэтому подобные разрешения реализуются лишь на уровне соответствующих цифр в настройках камеры и не приводят к какому-либо улучшению изображения.



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



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