Динамические и облачные инфраструктуры: от теории к практике

На форуме «Мир ЦОД – 2014» были широко представлены решения для развертывания гибких, динамических ИТ-инфраструктур в центрах обработки данных предприятий разного масштаба, а системные интеграторы и облачные провайдеры поделились опытом их внедрения.

Почти все ведущие вендоры предIлагают комплексные интегрированные платформы — заранее протестированные программно-аппаратные решения общего назначения либо оптимизированные для выполнения тех или иных задач. В ряде случаев они позиционируются как системы, с помощью которых заказчик может быстро развернуть облачную инфраструктуру. Между тем системные интеграторы накапливают собственный опыт проектирования и развертывания динамических и облачных инфраструктур. Некоторые из них были представлены в качестве примеров на семинарах и мастер-классах, проходивших в рамках пятого двухдневного форума «МИР ЦОД», проведенного в мае 2014 года издательством «Открытые системы».

КАК ПОСТРОИТЬ ОБЛАКО — БЫСТРО И НЕДОРОГО

Сколько требуется времени, чтобы с нуля построить частное облако IaaS? Евгений Лагунцов, системный инженер-консультант компании Cisco, продемонстрировал, как сделать это на основе политик использования ресурсов всего за один час. С помощью Cisco UCS Director он сконфигурировал конвергентный стек, где использовались серверное оборудование Cisco UCS (пять серверов трех разных моделей), дисковый массив NetApp и сетевое оборудование Cisco Nexus с конвергентными подключениями к UCS и NetApp. В результате были созданы работающая виртуальная среда, кластер серверов, хранилище данных FC с общим доступом и портал самообслуживания. Последний позволяет заказать виртуальную среду с предопределенными параметрами или подстраивать параметры уже имеющейся, а при необходимости отправить заявку на расширение физической среды (добавление хоста в кластер). Подробности можно найти на видеоканале Cisco (https://www.youtube.com/CiscoRussiaMedia) и по адресу http://www.ciscoclub.ru (семинар «Автоматизированное развертывание виртуализированной инфраструктуры с интегрированными сетевыми сервисами на базе Cisco Nexus 1000v»).

В UCS Director можно конфигурировать и более сложные сетевые топологии, организационные структуры и сервисы (например, контейнеры с разными типами ВМ, внутренними сетями и сетевыми сервисами), рассчитывать стоимость потребленных услуг и т. д. Евгений Лагунцов выделяет несколько ключевых преимуществ интегрированной платформы Cisco UCS: снижение рисков, исключение ошибок и гарантированная идентичность аппаратных настроек при внедрении ферм серверов и их расширении, отсутствие необходимости согласованно настраивать большое число коммутаторов разного типа благодаря единой «самонастраивающейся» фабрике, сокращение времени развертывания сервисов и масштабирования, снижение совокупной стоимости владения и трудозатрат на внедрение, обслуживание и поддержку за счет встроенного управления на основе политик и шаблонов.

Однако нередко системные интеграторы и провайдеры, заинтересованные в сокращении затрат, предпочитают создавать облачную инфраструктуру из самостоятельно выбираемых ими компонентов, а не использовать готовое интегрированное решение (см. статью автора «ИТ-инфраструктура ЦОД: новые подходы» в этом номере «Журнала сетевых решений/LAN»).

«Облачные сервисы хорошо подходят для тестовых сред и сред разработки, характеризующихся высокой динамикой изменения пула ресурсов, — считает Григорий Атрепьев, директор проектов DataLine. — В то же время попытки снижения себестоимости сервиса зачастую приводят к снижению показателей производительности и доступности». Он рассказал о том, как и из чего можно собрать недорогое, но реализующее все необходимые функции облачное решение.

Компания Dataline, специализирующаяся на предоставлении услуг аутсорсинга ИТ, построила в Москве собственную сеть ЦОД с заявленным уровнем надежности Tier III. При развертывании «облегченной» облачной среды DataLite экспертам пришлось делать выбор между тремя наиболее популярными продуктами виртуализации — VMware, KVM и Microsoft Hyper-V. «Список мог бы быть более широким, но все платформы требовалось протестировать за ограниченное время, — рассказывает Григорий Атрепьев. — Аргументами в пользу VMware стало, в частности, наличие у DataLine опыта эксплуатации данных решений. Еще один важный фактор — стоимость лицензий. Составление финансовых моделей показало, что применение KVM и Hyper-V позволит сэкономить лишь 4–5% от общей стоимости проекта и при этом потребует привлечения новых специалистов. К тому же при внедрении любого нового решения высока вероятность появления проблем». Кроме того, в DataLine отмечают негативные особенности ценообразования при покупке лицензий на Hyper-V провайдерами, что может существенно увеличивать стоимость услуги.

По данным исследования DataLine, значительная часть возникающих у клиентов проблем приходится на сеть. Отсутствие сетевого доступа — не менее серьезный отказ, чем глобальный сбой самой платформы виртуализации. Поэтому, чтобы обеспечить соответствие условиям SLA по доступности ИТ-ресурсов, рекомендуется не экономить на сетевом оборудовании. В качестве основных коммутаторов сети хранения данных DataLine использует Cisco Nexus 5000, применяемые ею и в других решениях. Каждая хост-система имеет шесть портов 10GbE. Файлы VMDK виртуальных машин дублируются на другом хосте, где при отказе какой-либо ВМ запускается ее копия. Через интерфейс vCloud Director заказчики могут работать с любыми продуктами или платформами разработки DataLine, распределяя между ними свои ВМ. Для увеличения скорости доступа используется кэш-память SSD, поддерживаемая программной платформой vSAN. Емкость SSD составляет 12% от общей емкости кластера СХД (см. Рисунок 1).

Рисунок 1. Архитектура облачной среды DataLite компании DataLine.

На системы хранения данных и SAN приходится обычно около 40% стоимости решения, поэтому переход на vSAN и локальные диски дает возможность сэкономить. А вот на отказоустойчивости специалисты DataLinе советуют не экономить. В DataLite она обеспечивается резервированием ресурсов в рамках кластера и резервированием сетевого сегмента. В результате уровень доступности составляет 99,9%.

ОБЛАКА ПОД ЗАЩИТОЙ

Сегодня российские предприятия используют облака не только для тестирования и разработки ПО, но и для выполнения важнейших бизнес-приложений, и таких примеров немало. DataLine предлагает для этих целей катастрофоустойчивое облако CloudLine Metrocluster с доступностью 99,95%. Данное решение на базе СХД NetApp и ПО VMware vSphere обеспечивает защиту критичных приложений и данных, даже если ЦОД полностью выйдет из строя. Для этого применяется дублирование элементов СХД в двух ЦОД — OST (ул. Боровая) и NORD (Коровинское ш.), — удаленных друг от друга на 33 км. При недоступности одного из них осуществляется миграция виртуальных машин на резервную площадку. В последнем случае запуск ВМ (Recovery Time Objective, RTO) может осуществляться в течение 2 мин., а в режиме зеркалирования данных на уровне СХД между двумя площадками — практически мгновенно. В нормальном режиме работы обеспечивается балансировка нагрузки на уровне двух ЦОД.

Практическим опытом внедрения высоконадежного облачного решения LinxCloud для корпоративных клиентов поделился также Игорь Дроздов, менеджер технической поддержки продаж Linxdatacenter. Компания владеет четырьмя ЦОД Tier II и III (два из них находятся в Европе) общей площадью более 13 тыс. м². На их базе клиентам предоставляются услуги аренды площадей, управляемого хостинга и различные облачные сервисы, в том числе резервное копирование и аварийное восстановление. Все четыре ЦОД объединены в отказоустойчивое кольцо, а общая протяженность сети Linxdatacenter — почти 8800 км.

ЦОД Tier III в Санкт-Петербурге, где базируется российский сегмент облачного решения Linxdatacenter, рассчитан на 1000 стоек. Его европейский двойник (на 240 стоек) — ЦОД Tier III в Варшаве. Облачное решение LinxCloud построено на базе интегрированной системы FlexPod, объединяющей продукты NetApp, Cisco и VMware (см. Рисунок 2). «FlexPod — проверенное корпоративное решение, позволяющее предлагать сервисы тем организациям, которым необходим высокий уровень информационной безопасности в многопользовательской архитектуре. Соответствие FlexPod стандартам PCI DSS дает возможность предлагать услуги клиентам из банковской сферы. Его характеризуют также эластичность, надежность и отказоустойчивость. Уровень SLA составляет ‘‘пять девяток’’», — подчеркивает Игорь Дроздов. Внутренние каналы и подключение к Интернету резервируются.

Рисунок 2. Облачное решение Linxdatacenter на базе FlexPod.

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

ГИБРИДНЫЕ ОБЛАКА

Облачные сервисы решают определенный набор задач. Поскольку требования различны, все более популярной становится гибридная модель. Как показывают исследования, за последний год интерес российских заказчиков к гибридной облачной модели значительно вырос. Но готовы ли провайдеры ее предлагать? «Мы предоставляем партнерам и заказчикам выбор: они могут строить частные, гибридные или публичные облака, — подчеркивает Игорь Виноградов, системный инженер EMC. — Гибридное облако на базе EMC VPLEX и Cisco OTV позволяет практически мгновенно переключаться со своей корпоративной инфраструктуры на инфраструктуру провайдера. А благодаря технологии VPLEX серверы могут работать с локальным или «облачным» томом, имеющими один LUN».

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

Тем временем технологии совершенствуются. Сейчас облачные платформы разных вендоров изолированы, имеют разные характеристики и обеспечивают разный уровень SLA по разной цене. Задача — навести мосты между этими островками, чтобы можно было реализовать гибридную облачную инфраструктуру. Именно этим и занимается Cisco. «Мы создаем инфраструктуру виртуальных сетевых сервисов, позволяющую заказчикам менять провайдера, для чего разрабатываем систему сертификации облачных провайдеров и развиваем инициативу InterCloud», — рассказывает Дмитрий Хороших.

При развертывании гибридного облака и построении сложной облачной инфраструктуры необходимо также обеспечить эффективное управление и сетевое взаимодействие между площадками. С последней задачей помогают справиться виртуальные маршрутизаторы (в виде ВМ), уже предлагаемые Cisco, которые позволяют настраивать маршрутизацию между облаками с помощью привычных инструментов, интерфейсов и протоколов. Кроме того, посредством недавно выпущенного продукта Cisco Nexus InterCloud можно связывать облака не только на третьем, но и на втором сетевом уровне, а Cisco USC Director обеспечивает управление как своим, так и внешним облаком (например, облаком Amazon).

Более десятка клиентов Linxdatacenter уже развернули в соответствии с гибридной моделью свои рабочие системы, например SAP. Одно из решений, используемых в ЦОД Linxdatacenter, — гибридное облако Play (ранее — YotaPlay), построенное на базе FlexPod для компании Yota («Скартел») с целью предоставления ее заказчикам разнообразного видеоконтента. Гибкая среда для разработчиков позволяет оперативно развертывать и высвобождать виртуальные серверы, причем оплата производится «за использование», а предоставляемая среда тестирования обеспечивает заданные требования к производительности. Аппаратную часть обслуживает провайдер.

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

«Частное облако не подошло клиенту из-за ограниченной масштабируемости. Кроме того, для его реализации требуется наличие у компании собственной экспертизы и опытного персонала, а для развертывания необходимо время. Провайдер все это делает значительно быстрее, одновременно обеспечивая снижение затрат на ИТ. Однако использование публичного облака заставляет заказчика вносить серьезные изменения в свою архитектуру сервиса и осложняет реализацию защиты прав правообладателей. Предоставление видео по требованию (Video on Demand, VoD) создает серьезную нагрузку как на вычислительные ресурсы, так и на каналы связи, трудности возникают и с обеспечением связности между публичным облаком и физической инфраструктурой заказчика», — поясняет Игорь Дроздов.

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

В решении, развернутом на двух стойках в ЦОД, расположенном в Москве, и пяти — в санкт-петербургском центре обработки данных, используются сервисы IaaS. Дополнительно заказчик арендует сетевые ресурсы Linxdatacenter, включая каналы L3 VPN между ЦОД (1 Гбит/с). Доступ в Интернет осуществляется через разных провайдеров — на каждой площадке задействовано три канала от трех разных провайдеров с суммарной пропускной способностью до 10 Гбит/с. Самые ресурсоемкие сервисы VoD развернуты на физических серверах, часть сервисов балансировки нагрузки и обработки запросов, а также Web-сервисы — на виртуальных машинах. Для построения сети Play компания Linxdatacenter добавила к платформе FlexPod дополнительные коммутаторы Nexus.

В результате существенная часть инфраструктуры Play передана на аутсорсинг (см. врезку «ЦОД: владение или аренда?») и реализована поддержка трех сред (Development, Preproduction, Production), причем последняя работает по отказоустойчивой схеме на разнесенных площадках. «Мы убедились в возможности развертывания публичных облаков на базе FlexPod с отличным качеством и большой скоростью, в том числе для клиентов с высокими требованиями к нагрузке и отказоустойчивости. Сейчас Play — это свыше 800 Тбайт данных (трафик составляет 450 Тбайт в месяц) и более 200 серверов в двух ЦОД. Всю эту инфраструктуру обслуживают три инженера», — рассказывает Игорь Дроздов.

Еще одно решение Linxdatacenter развернула для компании «Первый БИТ», которая решила предоставлять сервисы «1C» по модели SaaS. Заказчик протестировал десяток ЦОД и в итоге остановился на предложении Linxdatacenter. С момента реализации проекта в 2011 году к сервису уже подключилось более 1000 пользователей сервиса. Поскольку ресурсы ИТ можно гибко наращивать или освобождать, компания планирует увеличить число пользователей втрое и запустить новые сервисы IaaS. Гибкости и динамичности инфраструктуры — собственной или предоставляемой облачным провайдером — некоторые заказчики уделяют особое внимание.

ДИНАМИЧЕСКИЕ ИНФРАСТРУКТУРЫ

Компания «Инфосистемы Джет» с 2011 года реализует проект для одного из российских банков, постоянно расширяющего свой бизнес. В рамках этого проекта поэтапно строится динамическая инфраструктура ИТ, что предусматривает использование сервисного подхода и возможность гибкого выделения и освобождения ресурсов ИТ по необходимости. Кроме того, необходимо обеспечить высокую эффективность использования ресурсов, гибко реагировать на изменения, проблемы и сбои, гарантировать надежность и безопасность. Стимулом перехода на динамическую инфраструктуру являются также повышенные требования к отказоустойчивости сервисов ИТ.

Сначала на примере одной информационной системы были проверены выбранная платформа виртуализации и стратегия, стандартизировано оборудование, определены требования ПО для всех систем банка. В 2012 году консолидированы системы хранения и проверены на практике технологии виртуализации при динамическом перераспределении ресурсов между двумя системами банка. По результатам было принято решение о переводе на динамическую инфраструктуру всех 10 критичных систем банка. К концу 2013 года они работали в основном и резервном ЦОД, связанных магистралью 10 Гбит/с. Перемещение информационных систем между ЦОД может осуществляться без остановки ИТ-сервисов. Для этого используются технологии VMware vMotion. Системы хранения виртуализированы с помощью IBM SVC. В случае возникновения чрезвычайных ситуаций время переключения всех систем банка между площадками не превышает 2,5 ч.

«В данной архитектурной модели классификация систем на более и менее критичные для бизнеса потеряла смысл. Кроме того, виртуализация стала надежным фундаментом для ИТ-инфраструктуры организации. А революция в системах х86 привела к тому, что вместо сервера старшего класса с решением тех же задач теперь справляется обычный двухпроцессорный сервер. Новые процессоры максимально ориентированы на технологию виртуализации, что позволяет эффективнее использовать физические ресурсы в виртуальной среде. Все это дало синергетический эффект и позволило за счет виртуализации реализовать маршрутизаторы, межсетевые экраны и криптошлюзы, не покупая соответствующего физического оборудования, что добавило гибкости в инфраструктуру, — рассказывает Ильдар Абульханов, менеджер по развитию бизнеса центра проектирования вычислительных комплексов компании «Инфосистемы Джет». — В результате удалось добиться таких эксплуатационных эффектов, о которых раньше можно было только мечтать. Виртуальные машины можно перемещать из одной системы в другую, оперативно добавлять вычислительные ресурсы в моменты пиковых нагрузок и т. д. После построения распределенного ЦОД значительно (на 30%) сократились затраты при развертывании критичных для бизнеса систем, а технология виртуализации сделала возможной покупку готового к работе сервера с защитой от сбоев без приобретения дополнительного кластерного ПО, что экономит затраты и сокращает время внедрения. Намного упростились задачи миграции приложений из одного ЦОД в другой».

Рисунок 3. Распределенный ЦОД, реализованный для одного из банков компанией «Инфосистемы Джет». В нем используются модульные серверы IBM и Hitachi, дисковые хранилища Hitachi, IBM, EMC, виртуализатор IBM SVC. Площадки, разнесенные на 40 км, связаны каналами 10 Гбит/с (LAN) и 16 Гбит/с (SAN). При такой архитектурной модели выход из строя любого дискового массива, сервера, виртуализатора или канала связи не нарушит работу информационных систем банка.

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

КОММУНИКАЦИИ МЕЖДУ ЦОД

Вместе с инфраструктурой вычислительных комплексов меняется сетевая составляющая. Ранее пропускная способность канала передачи данных между ЦОД обычно ограничивалась 100 Мбит/с и процедура восстановления занимала до 24 ч. Критичным для бизнеса приложениям требовались локальная защита в рамках основной площадки (например, кластерное решение) и дополнительное резервирование на удаленной. С появлением технологии 10GbE и FC на 16 Гбит/с время восстановления системы в такой архитектуре сократилось до 1–2 часов, а главное — снизились затраты на владение инфраструктурой ИТ.

Все чаще заказчики требуют поддержки миграции ВМ между ЦОД без прерывания сервисов. На сетевую инфраструктуру это накладывает новые требования. Таким образом, виртуализация и облачные вычисления не только оказывают глубокое влияние на построение ИТ-архитектуры ЦОД, но и заставляют вендоров искать новые подходы к организации сетевой инфраструктуры центров обработки данных (см. статью Александра Скороходова «Сетевая инфраструктура ЦОД с акцентом на приложениях» в пятом номере «Журнала сетевых решений/LAN» за этот год и статью автора «Сетевая инфраструктура и управление: подход Cisco» в центре компетенции «Мир ЦОД» — http://www.osp.ru/dcworld).

Для соединения двух ЦОД используется волоконно-оптический канал и DWDM (Dense Wave Division Multiplexing) — это современная технология передачи и уплотнения в одном оптическом волокне нескольких оптических сигналов с различными длинами волн. «С различных точек зрения данный вариант безальтернативен, — считает Дмитрий Иванов, начальник отдела инженерной поддержки продаж центра сетевых решений компании «Инфосистемы Джет». — Расстояние может достигать 120 км, а переключение с основного на резервный канал происходит за микросекунды. В DWDM есть встроенные механизмы мониторинга качества линии и автоматического переключения. Эти технологии пришли из операторского бизнеса, что означает высокий уровень надежности и отказоустойчивости – пресловутые ‘‘пять девяток’’. Стоимость типовой конфигурации (два канала 10GbE и шесть FC 8) составляет 200–300 тыс. долларов». Альтернативная пассивная система DWDM обладает низким уровнем отказоустойчивости и для построения таких систем обычно не применяется.

Однако случаются и проблемы, как было в случае описанного выше проекта для банка. «На этапе опытной эксплуатации выяснилось, что при переключении каналов все ИТ-системы останавливаются на несколько часов, даже если время переключения не превышало 50 мс. Детальный анализ проблемы выявил, что даже за столь малый интервал времени буферы коммутаторов FC переполнялись. Такую проблему трудно предугадать на этапе проектирования, — поясняет Дмитрий Иванов. — Для ее решения пришлось отказаться от использования механизмов отказоустойчивости на транспортном уровне и задействовать собственные встроенные механизмы SAN. Выбор решения в данном случае зависит от возможностей настройки буфера коммутатора FC и расстояния между ЦОД».

Использование vMotion накладывает специфические требования и на топологию сети. Иерархическая топология уже не подходит: для миграции ВМ со всеми настройками нужен единый домен L2, поэтому применяют наложенные сети. Данное направление активно развивается как поставщиками сетевого оборудования, так и разработчиками программного обеспечения. «Мы решили выбрать технологии хорошо зарекомендовавшего себя вендора — Cisco и использовать для связи между площадками протокол OTV, а для взаимодействия с «внешним миром» — протокол LISP», — рассказывает Дмитрий Иванов.

Рисунок 4. Локальный выход во внешние сети — конфигурация «активный-активный».

В другом примере у заказчика было две площадки, каждая из которых имела свой выход в Интернет. Как известно, после миграции ВМ в другой ЦОД появляется петля в маршрутизации при выходе в Интернет, в то же время есть возможность общаться с «внешним миром» напрямую. Проблема решается при помощи протокола LISP, который для идентификации ресурсов и устройств сети предлагает использовать два IP-адреса: внешний и внутренний. Однако фактически LISP требует построения еще одной наложенной сети, что несколько усложняет инфраструктуру (см. Рисунок 4). Кроме того, клиентские устройства и маршрутизаторы должны поддерживать LISP. В данном случае модернизация маршрутизаторов обошлась бы заказчику слишком дорого. Поэтому домен LISP ограничен уровнем граничных маршрутизаторов. При переезде ВМ во внешнюю сеть просто анонсируется ее маршрут с маской /32. В итоге такой вариант не устроил заказчика, поэтому пришлось вернуться к «неэффективной» модели и конфигурации с единым выходом в Интернет.

Чрезмерное число технологий и подходов неизбежно приводит к определенным сложностям на этапе реализации. Важно, чтобы системный интегратор уже имел опыт их преодоления, заключают специалисты компании «Инфосистемы Джет».

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

Сергей Орлов — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: sorlov@lanmag.ru.