Ямы на пути к облакам

Тема облаков вызывает сегодня немалый интерес — появляется все больше статей, в которых рассказывается о том, как будет хорошо и какие выгоды принесет конечному потребителю подход XaaS, где вместо X нужно подставить: Software, Infrastructure, Platform, Desktop... Иногда обсуждаются и более «приземленные» вопросы: обеспечение безопасности, гарантия соблюдения SLA и вопросы лицензирования. Однако, к сожалению, редко затрагивается тема перехода от существующей у заказчика инфраструктуры к облачной, а точнее к гибридной, так как, несмотря на заклинания многих аналитиков, 100-процентного перехода всех систем в облако в обозримом будущем не произойдет. Вариант, когда некая компания обращается к провайдеру и с нуля создает всю инфраструктуру сразу в облаке, вряд ли стоит рассматривать как серьезный, а следует считать «вырожденным» случаем построения облака для предприятий малого бизнеса. Все остальные компании, рассматривающие облачные решения как способ дальнейшего развития своих информационных систем, уже имеют развернутую инфраструктуру, и чем более развита с точки зрения ИТ существующая инфраструктура, тем проще и легче сделать переход на модель XaaS.

Какие проблемы могут появиться при переводе работающей ИТ-инфраструктуры на площадку провайдера облаков? Представим себе, что у нас есть ресурсоемкое приложение, работающее с корпоративным каталогом LDAP (например Active Directory), хранящее и обрабатывающее информацию из некоторой базы данных (рис. 1).

Рис. 1. Начальный этап перехода к гибридному облаку

Конечно, переход не состоится в одно мгновение, а будет осуществляться поэтапно. На первом этапе мы перенесем к провайдеру приложение, а сервис каталогов LDAP и сервер базы данных пока останутся в корпоративном ЦОД (рис. 2).

Рис. 2. Перенос к провайдеру облачных услуг ресурсоемкого приложения без организации обратного подключения к корпоративному ЦОД

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

Для получения работающей среды понадобится ПО или оборудование, обеспечивающее «прозрачность» на сетевом уровне между инфраструктурами корпоративного ЦОД и провайдера облака — за счет применения различных технологий в ЦОД провайдера можно будет за его «входной точкой» использовать то же адресное пространство, что и в корпоративном ЦОД. Естественно, такое соединение должно быть безопасным и оптимальным с точки зрения передачи сетевого трафика по WAN. При выполнении всех этих требований мы должны получить схему, представленную на рис. 3. В таком режиме обеспечивается бесшовное взаимодействие всех компонентов, и в дальнейшем процесс переноса других модулей/приложений не будет вызывать проблем с межкомпонентными коммуникациями. Как показывает практика, корпоративные заказчики хотят использовать «дешевые» вычислительные ресурсы в облаке, но в то же самое время сохранять свои данные и сервис каталогов в корпоративном ЦОД.

Рис. 3. Гибридное облако с организацией «прозрачного» соединения между корпоративным ЦОД и ЦОД провайдера

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

Несмотря на то что компания Citrix больше известна как производитель решений по виртуализации приложений (XenApp), десктопов (XenDesktop) и серверов (XenServer), у нее имеются продукты для работы с облачными инфраструктурами. Например, для упомянутых случаев перехода к облакам можно использовать продукты NetScaler CloudBridge и NetScaler CloudGateway, поставляемые в виде аппаратных комплексов и как виртуальные устройства для различных гипервизоров.

NetScaler CloudBridge обеспечивает формирование туннеля IPsec между различными площадками, а входящий в состав решения компонент Branch Repeater осуществляет оптимизацию трафика TCP, проходящего по глобальной сети. В результате заказчик получает работающее приложение, перенесенное в ЦОД провайдера облака, но с сохранением всей схемы сетевой адресации и доступности программных блоков, необходимых для функционирования корпоративной системы. Такой перенос между ЦОД заказчика и ЦОД одного или нескольких провайдеров облачных услуг не приводит к перестроению всей инфраструктуры и простою бизнеса.

CloudBridge входит в состав семейства продуктов NetScaler и выпускается в нескольких вариантах: виртуальные устройства NetScaler VPX, рассчитанные на небольшие нагрузки от 10 Мбит/с и до 3 Гбит/с, аппаратные устройства под маркой NetScaler MPX, предназначенные для обработки трафика в диапазоне от 500 Мбит/с и до 50 Гбит/с. Наиболее интересен третий вариант — NetScaler SDX, фактически представляющий собой комбинацию первых двух. На аппаратной платформе NetScaler на заводе устанавливается гипервизор Citrix XenServer, и на нем можно развернуть до 40 изолированных экземпляров NetScaler VPX.

Продукты NetScaler позволяют организовать балансировку запросов между различными площадками как для распределения нагрузки, так и для создания инфраструктур непрерывной доступности — в случае отказа одной из площадок из схемы балансировки будет исключен неисправный сайт и пользователь будет перенаправлен на работающие серверы. Если приложение часто обращается с запросами чтения к базе данных (Microsoft SQL Server или MySQL), то технология распараллеливания запросов DataStream поможет распределить нагрузку между серверами баз данных, используемых для работы приложения. Анализ происходит на уровне SQL запросов.

Продукт NetScaler CloudGateway доступен в виде программного и аппаратного устройства, но, в отличие от CloudBridge, это решение асимметрично и устанавливается на одной площадке с рабочими местами. Система позволяет: настроить создание (provisioning) и удаление (de-provisioning) учетных записей пользователей во внешних системах по заданным администратором условиям (например, появление или удаление учетной записи пользователя в группе Active Directory); обеспечить однократный вход в систему за счет использования различных технологий (Security Assertion Markup Language, заполнение Web-форм); вести учет использованных облачных ресурсов.

Для организации, которая решила перейти от одного провайдера облаков к другому, становится актуальной, казалось бы, несложная задача переноса данных. Действительно, в простом случае происходит обычный перенос базы данных с одной площадки на другую методом копирования, миграции или репликации. Но если изначально такой сценарий не обсуждался и не тестировался, то провайдер может передать не искомую базу данных, а набор информации в формате, требующем повторного импортирования данных в систему, либо в другом виде, не исключающем потерь или нарушения структуры. Поэтому очень важной является стадия выработки требований (стадия проектирования) к сервисам, предоставляемым провайдером. Если предусматривается простой перенос данных, то для этих целей Citrix предлагает сервис ShareFile, который может быть связан с сервисом каталогов. Интересная возможность ShareFile — обеспечение взаимодействия пользователя с его персональным облаком, доступ к которому возможен с разнообразных устройств, не требующих синхронизации. В 2012 году Citrix планирует выпустить версию ShareFile, которую можно будет использовать в рамках частного облака компании без привлечения внешних ресурсов.

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

1. Анализ существующей инфраструктуры и особенностей приложений.
2. Оценка предложений провайдеров облаков (предлагаемые сервисы, уровень обслуживания, возможность переноса инфраструктуры обратно в корпоративный ЦОД, возможность установки аппаратных/виртуальных устройств, помогающих в построении гибридных облаков).
3. Выделение приоритетных направлений (сервисы, приложения) для переноса к провайдеру.
4. Разработка дизайна и архитектуры гибридного облака с учетом описанных проблем.
5. Подготовка оповещения для пользователей с информацией о новых возможностях, особенностях и контактах для решения возникающих проблем.

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

***

Продукты семейства Citrix NetScaler позволяют осуществить переход к гибридным облакам с сохранением, при необходимости, безопасного удаленного доступа к ресурсам ЦОД с использованием технологии SSL VPN. Для этого служит компонент NetScaler Access Gateway. Для более требовательных заказчиков с помощью Access Gateway можно развернуть сервис проверки состояния клиентского рабочего места, когда в зависимости от имеющихся на нем ресурсов пользователь может получить доступ к тем или иным дополнительным сервисам в полном или ограниченном объеме. Применяя NetScaler Branch Repeater, можно обеспечить оптимизацию трафика TCP в глобальной сети между различными площадками ЦОД <-> ЦОД, ЦОД <-> Удаленный офис, Удаленный офис <-> Удаленный офис, рационально используя загрузку канала и сокращая время ожидания. Для организации защиты конфиденциальных данных может использоваться сертифицированный по стандарту PCI-DSS продукт NetScaler Web Application Firewall, осуществляющий проверку данных, отправляемых от приложения к пользователю и приходящих от пользователя к приложению.

Сергей Халяпин (sergeykh@citrix.com) — руководитель системных инженеров представительства компании Citrix Systems (Москва).