О преимуществах использования облачной модели компаниями, чей бизнес напрямую не связан с ИТ, сказано достаточно: облака позволяют эффективнее использовать имеющийся парк оборудования, оперативно увеличивать пул ресурсов и экономить на администрировании инфраструктуры. Опасения относительно безопасности облаков постепенно развеиваются. Практика показывает, что риски связаны преимущественно с некомпетентностью специалистов, которые администрируют облачные системы. Но корпоративные клиенты не всегда готовы тратить ресурсы на повышение квалификации собственных сотрудников ИТ-отделов, вместо этого они прибегают к услугам сервис-провайдеров.
Облачная инфраструктура: докупить или переехать?
Перед корпоративными заказчиками, которые уже используют в работе облачные вычисления наряду с традиционными решениями, и теми, кто только присматривается к новым технологиям, может встать вопрос: заменить полностью имеющуюся инфраструктуру на облако или сделать выбор в пользу гибридного решения? Давайте разбираться. Какие вообще бывают облака и кому они могут быть интересны?
Частные (приватные) облака – это собственная облачная инфраструктура компании. Организации, как правило, строят приватные облака в своих ЦОД силами сотрудников ИТ-отдела. В частном облаке можно расположить критически важные бизнес-приложения, ограничить политики доступа и таким образом сохранить полный контроль над инфраструктурой.
Ресурсы публичного облака можно приобрести у сервис-провайдера по модели IaaS («инфраструктура как услуга»). При этом сценарии физические данные хранятся на территории провайдера, заказчику предоставляется к ним удаленный доступ, а администрируют инфраструктуру специалисты ИТ-компании.
Гибридное облако предполагает сочетание частной и публичной облачных инфраструктур: данные с двух площадок синхронизируются и передаются по защищенному каналу.
Между тем нередко встречается модель, когда инфраструктура компании объединяет не два облака, а облако и физическое оборудование. В этом случае мы говорим о гибридном решении. Это актуально, например, если требуется обеспечить высокий уровень безопасности ряда корпоративных приложений, и использование аппаратных средств шифрования − вопрос принципиальный. Тогда заказчик может оставить некоторые системы работать на физических серверах.
Другой пример − приложения, управляющие оборудованием на производстве или, скажем, в медицинском учреждении. Также систему контроля доступом (СКУД) тоже лучше не переносить в облако − вы рискуете, как минимум, остаться запертым на заводе, если вдруг перестанет работать Интернет.
При наличии подобных обстоятельств организации, как правило, внедряют облачные решения в дополнение к физической инфраструктуре, т. е. строят приватные облака или по мере необходимости под новые сервисы приобретают ресурсы публичного облака у провайдера.
Когда актуальна полная миграция?
Важно понимать, что миграция данных в облачную среду и внедрение облаков в принципе − это два разных процесса. Первый подразумевает перенос данных с одной площадки на другую, т. е. замену основной инфраструктуры. Второй − внедрение, как уже было сказано, не всегда подразумевает миграцию данных: основная инфраструктура может остаться прежней, а облачные решения будут работать вкупе с ней.
Предположим, у условной ритейл-компании уже есть некая корпоративная инфраструктура (пусть это будет платформа виртуализации), которая исправно работает. Мала вероятность того, что руководство компании решит мигрировать в облако с функционирующей площадки без веских на то оснований. Так в какой ситуации есть смысл переносить данные с одной площадки на другую?
Миграцию целесообразно осуществлять, если корпоративный клиент хранит данные в частном облаке от вендора или использует в качестве платформы виртуализации коммерческий продукт. В этом случае можно говорить о миграции в облако сервис-провайдера, построенное на базе решений с открытым исходным кодом. Поскольку провайдер не делает лицензионных отчислений вендору, то и стоимость услуги для конечного пользователя будет ниже. При таком сценарии заказчик имеет возможность сэкономить: за меньшие деньги он получает функционирующую инфраструктуру без необходимости ее администрировать.
 |
Всеволод Вайнер, коммерческий директор ATLEX
Переезд в публичное облако сервис-провайдера позволяет корпоративным клиентам сэкономить на лицензионных отчислениях вендору. Заказчик платит только за реально используемые ресурсы по программе pay as you go. Кроме того, есть возможность оперативно масштабировать инфраструктуру и получать дополнительную функциональность в максимально короткие сроки.
|
Альтернативой проприетарным продуктам постепенно становятся решения с открытым исходным кодом. Их использование позволяет интегрировать имеющийся функционал платформы с собственными разработками компании. Таким образом, приобретая у сервис-провайдера ресурсы публичного облака на базе открытого кода, клиент получает решение, доработанное с учетом специфики его бизнеса. При этом исключается зависимость от одного вендора.
Так себя зарекомендовал OpenStack − комплекс продуктов свободного программного обеспечения для создания облачных сервисов и хранилищ. Над созданием технологий трудятся разработчики передовых компаний − Huawei, Intel, IBM, Cisco, Dell, Oracle, NetApp и др., а облачными решениями на базе OpenStack пользуются такие компании, как Volkswagen Group, China Mobile, государственная сетевая корпорация Китая (SGCC), AT&T, Walmart, Comcast, налоговая служба Великобритании и т. д.
Несмотря на преимущества публичных облаков, развернутых на свободном ПО, некоторых пользователей пугает неизвестность: как мигрировать данные на новую площадку? И кто будет нести ответственность за простой инфраструктуры, если что-то пойдет не так?
Миграция: план действий
Возьмем для примера ритейл-компанию с нагрузкой в 100 виртуальных машин и рассмотрим этапы переноса данных в публичное облако. Миграция осуществляется специалистами сервис-провайдера с платформы VMware на OpenStack с помощью технологии Hystax Acura.
Весь процесс переноса данных с коммерческой платформы на OpenStack можно условно разделить на несколько основных этапов: подготовка миграционного плана и инфраструктуры, репликация данных, тестирование инфраструктуры и запуск продуктива.
Сначала сотрудники ИТ-компании изучают архитектуру клиента − топологию сети, настройки, связи и зависимости между виртуальными машинами. На основе полученных данных сервисная компания совместно с внутренними ИТ-специалистами заказчика прописывает план миграции данных на новую площадку, которая структурно полностью дублирует VMware. При желании клиента в OpenStack можно заранее создать проект, где будут прописаны имеющиеся сетевые настройки. Тогда виртуальные машины будут развернуты уже на готовой площадке.
Затем осуществляется полная репликация инфраструктуры. Для этого на площадку VMware устанавливаются так называемые агенты − виртуальные машины, которые работают на Linux. Клиент скачивает по ссылке файл, и агент автоматически запускается. Он считывает с расположенных на хосте машин всю информацию и передает ее в облачное хранилище сервис-провайдера. Отсюда на этапе тестирования клиент сможет брать свежие копии данных – «снэпшоты» (инкрементная репликация будет производиться с заданной периодичностью все время вплоть до запуска новой инфраструктуры в продуктив). Спустя несколько минут данные появляются в интерфейсе управления. Кроме того, в административной панели есть информация об именах, IP-адресах, дате репликации и размере виртуальных машин.
Как долго будет длиться такая процедура? Это зависит от объема данных и ширины канала. Применяемые методы дедупликации уменьшают время передачи данных (эффективнее эта технология работает, если вся инфраструктура функционирует на одной версии ОС).
После этого копии виртуальных машин разворачиваются в облаке OpenStack. Начинается тестирование площадки. На данном этапе клиент имеет возможность проверить работоспособность инфраструктуры. При необходимости в план вносятся коррективы. Важно отметить, что продакшн при этом продолжает работать в штатном режиме.
По окончании тестирования необходимо произвести запланированную остановку работы основной инфраструктуры (окно обслуживания − от англ. maintenance window − необходимое время простоя оборудования для обслуживания), чтобы сделать финальную репликацию: перенести на OpenStack произошедшие за последние 5−10 минут изменения. Площадка запускается в продуктив.
Заключение
Вернемся к тому, с чего начали: сервис миграции данных актуален для компаний, у которых уже есть облачная инфраструктура от вендора или коммерческая платформа виртуализации. В этом случае корпоративный клиент может мигрировать данные в публичное облако сервис-провайдера, построенное на базе продуктов с открытым исходным кодом. Зачем? Это позволит ему значительно сократить расходы на ИТ-инфраструктуру за счет отсутствия лицензионных отчислений вендору со стороны провайдера.
Если специфика бизнеса обязывает вас хранить и обрабатывать конфиденциальные данные внутри компании, но необходимость оптимизировать расходы все-таки есть, возможно, вам стоит задуматься о гибридном облаке и в будущем приобретать ресурсы под некритические нагрузки у сервис-провайдера.
Переход на гибридное решение можно посоветовать компаниям с физической инфраструктурой: модель IaaS позволяет повысить эффективность использования существующей ИТ-инфраструктуры и оптимизировать план закупок нового оборудования.
