«Запрограммировать» ЦОД

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

Сделать ЦОД программно определяемым (Software-Defined Data Center, SDDC) можно с помощью ряда ИТ-технологий и инструментов. В первую очередь при построении SDDC стоит задуматься о технологии макровиртуализации. Она подразумевает применение тандема из двух систем управления — виртуальными машинами (ВМ) и инфраструктурой ЦОД (Data Center Infrastructure Management, DCIM) — с целью снижения эксплуатационных расходов.

DCIM собирает и агрегирует информацию о состоянии инженерной инфраструктуры центра обработки данных, наличии свободных площадей, а также места в стойках. Система помогает получать максимально полную картину того, что происходит в ЦОД компании-провайдера «здесь и сейчас». В совокупности с информацией из системы управления ВМ это позволяет выявить проблемные точки в ЦОД (локальное превышение пороговых значений температуры, нехватка электропитания и др.), на основании чего может быть принято решение о перемещении вычислительной нагрузки в ту или иную физическую зону центра обработки данных (или в другой ЦОД). Благодаря переносу высоконагруженных виртуальных машин ближе к тем элементам инженерной инфраструктуры, которые способны обеспечить их надлежащую поддержку, «накал серверных страстей» снижается.

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

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

СЕТЬ ПОД УПРАВЛЕНИЕМ ПРИЛОЖЕНИЙ

Одним из важных кирпичиков программно определяемой сетевой среды является технология Software Defined Networking (SDN). Обеспечивая централизованное управление высокопроизводительными сетевыми коммутаторами, SDN находит себе все новых сторонников.

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

Управление трафиком — взаимодействие управляющего контроллера и коммутаторов — осуществляется с помощью специальных протоколов (наиболее перспективный из них и активно развивающийся — OpenFlow), которые оперируют понятием «поток» (flow). Через них выполняются разнообразные действия с трафиком: запрещение, разрешение, перенаправление и т. д. SDN обеспечивает гибкость управления сетью и существенно упрощает ее администрирование.

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

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

Архитектура программно определяемой сети

ВИРТУАЛЬНЫЕ СЕТЕВЫЕ УСТРОЙСТВА

Далеко не все задачи могут быть решены средствами, которые предоставляет SDN. В частности, это касается сложных задач обработки трафика и организации межсетевого взаимодействия, когда SDN органично дополняется виртуализацией сетевых функций (Network Function Virtualization, NFV). Уже существуют как Open Source, так и коммерческие реализации в виртуальной среде сетевых устройств — коммутаторов, маршрутизаторов, балансировщиков нагрузки, межсетевых экранов и т. д.

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

Почему эта тенденция устойчива и каковы преимущества NFV? Ответ на этот вопрос дают результаты опроса руководителей 220 компаний из различных отраслей экономики, проведенного порталом SDNCentral. Среди отмеченных ими преимуществ NFV почти с трехкратным отрывом лидирует показатель гибкости: виртуальный сервер значительно проще приобрести, масштабировать и т. д., чем физическое устройство. А показатели капитальных и операционных затрат, хотя и отмечаются респондентами в качестве существенных, не находятся на лидирующих позициях.

Если конкретизировать результаты опроса, можно отметить следующие преимущества:

• возможность создать персональное сетевое окружение для каждого приложения или абонента в облачной инфраструктуре;
• сокращение номенклатуры используемых устройств;
• снижение затрат на обслуживание и обеспечение функционирования ИТ-инфраструктуры: виртуальные сетевые устройства размещаются в виртуализированной среде на стандартных, однотипных серверах, поэтому для их установки не требуется отдельного места в стойке, а для обслуживания — широкой номенклатуры ЗИП;
• уменьшение сроков поставки: NFV — это ПО и лицензии, их поставлять значительно проще, чем оборудование;
• простота тиражирования и масштабирования наряду с упрощением автоматизации;
• несложное восстановление за короткое время: резервные копии конфигураций виртуальных сетевых устройств или просто образы их виртуальных машин можно восстановить за считанные минуты на других серверах.

Благодаря применению NFV, провайдер очень быстро может предоставить абоненту требуемое количество и нужную номенклатуру сетевых устройств, которые тот самостоятельно настроит в соответствии со своими уникальными задачами. Кстати, возможность полностью управлять всеми настройками арендованных сетевых устройств качественно отличает услугу от варианта, когда сети настраивает сам провайдер (в последнем случае заказчик не получает контроля над настройками, эксплуатация сети для оператора многократно усложняется и в итоге решение оказывается значительно дороже для обеих сторон).

Преимущества NVF

СЕТЬ ВНУТРИ СЕТИ

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

Действительно, вместо того чтобы каждый раз заниматься переконфигурированием физической сети, почему бы не «оставить ее в покое», единожды настроив и обеспечив только базовые функции — надежность, производительность, общую связность? В результате появился новый вид сетей — создаваемые поверх физических наложенные (Overlay), или логические, сети. Подобное делалось и раньше: под приведенное определение попадает хорошо известный стандарт IEEE 802.1q (VLAN). Разница в том, что протоколы для наложенных сетей ориентированы на маршрутизируемые сети и предусматривают существенно больше меток для их идентификации (как правило, 16 млн). В общем случае наложенная сеть создается с помощью программных или аппаратных коммутаторов (gateway) и протоколов туннелирования (VXLAN, NVGRE, STT, GENEVE).

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

• обеспечение связности виртуальных машин в различных сегментах сети и даже в разных ЦОД;
• повышение стабильности работы сети за счет использования маршрутизируемой сети в качестве транспорта;
• возможность совместной работы в виртуальной вычислительной инфраструктуре и взаимодействия с устройствами NFV;
• полная совместимость с существующей сетевой инфраструктурой благодаря тому, что все протоколы наложенных сетей работают по принципу инкапсуляции и используют стандартный формат кадра Ethernet.

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

НЕ СЕТЬЮ ЕДИНОЙ

Обсуждая программно определяемый ЦОД, мы затронули актуальные технологии в области инженерной и сетевой инфраструктур. Не менее важной составляющей SDDS является виртуализация систем хранения (Software-Defined Storage, SDS).

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

В качестве SDS рассматривается такой тип сервиса хранения данных, когда физическая составляющая СХД (массивы, диски, контроллеры, порты и т. д.) отделена от логической и организационной (логические тома, сервисы, политики доступа и т. п.). Скорее, здесь следует говорить об очередном уровне аппаратной абстракции (Hardware Abstraction Layer, HAL), который потребовался для эффективной поддержки виртуализации и сервиса хранения в рамках концепции SDDC.

ОГРАНИЧИТЕЛИ ДВИЖЕНИЯ

Технологии SDN, NFV, DCIM, SDS и другие вызывают интерес у многих российских компаний — провайдеров ИТ-услуг, но полноценных реализаций SDDC в нашей стране все еще нет. Это можно объяснить несколькими принципиальными причинами.

Так, на рынке отсутствуют готовые решения для интеграции системы DCIM и ПО управления виртуальными машинами. Компании придется самостоятельно решать этот вопрос с помощью своих ИТ-специалистов или команды системного интегратора. Да и сам выбор DCIM вызывает определенные сложности.

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

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

Выбор того или иного решения зависит от конкретных условий. Компания должна определиться с тем, какая система необходима именно ей (с учетом состояния инфраструктуры и планов развития), провести RFI, разработать KPI, сформировать шорт-лист и выполнить тестовые испытания. Все это сопряжено со значительными временными и трудовыми затратами. Логично, что многие провайдеры откладывают внедрение DCIM в долгий ящик, отодвигая и переход к программно определяемой среде.

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

ПО Open Source для SDN представляет собой по большей части «заготовку», которую нужно дорабатывать, что по карману не каждой компании. Ожидания рынка по поводу дешевых SDN-коммутаторов тоже не оправдываются: поскольку необходимая для поддержки требуемого количества потоков память (Ternary Content Addressable Memory, TCAM) является дорогим компонентом, стоимость всего устройства возрастает. К тому же вендоры по очевидным причинам не делают свои решения полностью открытыми: никто из ведущих производителей не упустит возможности «привязать» компанию-заказчика проприетарными доработками.

Проблемой SDS на данный момент является отсутствие единых стандартов для программных интерфейсов и протоколов, обеспечивающих взаимодействие между физическим, логическим и организационным уровнями решения. По сути, программно определяемая СХД дня сегодняшнего и ближайшего будущего на 90% состоит из виртуализированной СХД и на 10% — из программного инструментария (который сейчас только разрабатывается), позволяющего эффективно управлять СХД и взаимодействовать с другими компонентами SDDC.

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

Сергей Андронов — директор центра сетевых решений компании «Инфосистемы Джет», Александр Гуляев — начальник отдела сетевых проектов компании «Инфосистемы Джет».