Каким может стать ЦОД будущего?

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

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

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

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

Владельцы ЦОД оказались в непростой ситуации ? несмотря на необходимость модернизации, 70% их ИТ-бюджетов расходуется на эксплуатацию и поддержку, что оставляет инновациям всего лишь 30% средств (и это оптимистичная оценка).

Требования рынка

Бизнесу и госзаказчикам требуется все больше объемов для хранения данных (увеличение в 10 раз за 5 лет!), все более высокая скорость обработки, компактное размещение и минимальное потребление энергии ? при ограниченном финансировании и человеческом ресурсе. Именно это, в конечном счете, отражается на выборе архитектурных подходов, технологий и оборудования.

Развитии индустрии ИТ идет в сторону консолидации вычислений и все большей автономности функционирования инфраструктуры. Привычной стала вездесущая виртуализация вплоть до рабочих мест (VDI), широкое использование публичных, частных и гибридных облачных сред. Сервисно-ориентированные технологии IaaS, SaaS популярны настолько, что в ряде стран к 2017 году в их отношении прогнозируется CAGR (ежегодный показатель роста) в 30%-40%.

Отчасти это объясняется тем, что создание ЦОД ? дело затратное. Аналитики оценивают порог входа минимум в $500.000. Поэтому наряду с наиболее распространенным ранее вариантом ? созданием собственного корпоративного ЦОД ? на рынке появились и бурно развиваются услуги коммерческих ЦОД, предназначенных для аренды инфраструктуры внешними заказчиками.

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

Ключевые концепции современного ЦОД

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

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

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

3. Конвергентность. Необходимость строить для каждой подсистемы (и, в перспективе, модернизировать!) независимую кабельную систему, комплекс активного оборудования, сеть управления существенно удорожает решение и усложняет условия эксплуатации. И напротив ? сокращение количества компонентов приводит к повышению общей надежности. Пример конвергентной сети передачи данных: Data Center Bridging (DCB) и передача Fibre Channel трафика по технологии FCoE.

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

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

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

Don't panic! (© Douglas Adams. The Hitchhiker's Guide to the Galaxy)

Принципы создания ЦОД меняются. Отметим важные векторы их развития:

· Полная виртуализация инфраструктуры и единое управление сетью, серверами, хранилищами, сервисными платформами, виртуальными ресурсами, также известное как «оркестрирование»;

· Виртуализация «наружу»: например, технологии создания единых виртуальных коммутаторов для централизованного управления всей сетью передачи данных на тысячи портов как одной большой платформой;

· Программно-определяемое доминирование: сегодняшний венец развития идеи разделения шины данных и шины управления, один из примеров ? концепция Software Defined Networking (SDN);

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

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

Проблема двух подходов

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

Проиллюстрировать разницу двух подходов можно на примере стандартного многоуровневого web-приложения (Рисунок 1).

Рисунок 1. Два подхода к описанию логики работы приложения

Проблема находится на стыке ? эти два подхода плохо приспособлены для взаимодействия друг с другом.

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

Рисунок 2. Сетевая архитектура для работы корпоративного приложения (источник: cisco.com)

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

При этом возникают следующие вопросы:

· Достаточно ли отражена здесь логика работы бизнес-приложения в пределах его жизненного цикла?

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

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

· И ? главное ? сколько на это потребуется времени, включая время простоя площадок, и, в конечном счете, каковы будут затраты?

А что если строить ЦОД на базе второго («инженерного») подхода, но эксплуатировать в терминах первого ? взаимодействия приложений?

Технология Cisco ACI

Именно такое решение под именем Application Centric Infrastructure (ACI) в конце 2013 г. предложила компания Cisco. ACI обеспечивает поддержку сквозной виртуализации, управления и автоматизации, реализуя логику взаимодействия приложений посредством настраиваемых политик. Аппаратная составляющая ACI ? коммутаторы Nexus 9000, объединенные в топологию Spine-Leaf. Матрица коммутаторов формирует «ACI-фабрику». Прочие элементы ACI ЦОД подключаются к коммутаторам “Leaf” и называются End Point (EP). Для уменьшения количества объектов в среде ACI End Point объединяют в группы End Point Group (EPG). В принципе, знать о физической топологии нужно только то, что коммутаторы соединены между собой избыточными каналами и трафик между End Point равномерно балансируется по фабрике. Все управление компонентами ACI и самой фабрикой выполняется посредством программных контроллеров APIC (Application Policy Infrastructure Controller), также подключенных к “Leaf”-коммутаторам. Посредством APIC группа администрирования ЦОД формирует цепочки приложений и сервисных компонент в терминах End Point и политик их взаимодействия. Подобные взаимоотношения в терминах ACI называются «контрактами»: одна сторона контракт предоставляет (“provider”), другая потребляет (“consumer”).

Рисунок 3. Архитектура Cisco ACI

Контроллеры APIC в модели ACI являются распределенным хранилищем-репозиторием для всех объектов и политик среды ACI. При этом сама фабрика, что называется, stateless, без контроллера с базой данных она пуста и готова реализовывать любой логический дизайн.

Рисунок 4. Формирование цепочки End Point для описания многоуровневого приложения

Упоминавшийся выше принцип “multitenant” является неотъемлемой частью архитектуры ACI. В среде ACI существуют «арендаторы», в рамках выделенного ему сегмента арендатор создает изолированные «контексты», в которые погружает цепочки приложений, состоящие из EPG, связанных контрактами (Рисунок 4).

Помимо использования графического интерфейса (GUI), управление ACI можно осуществлять программно, посредством Python или Perl, а также любого другого языка с поддержкой REST API. Кроме этого поддерживается загрузка готовых объектов непосредственно на контроллер APIC в виде XML.

Инициативу Cisco ACI поддерживают BMC, Computer Associates, Citrix, EMC, Emulex, F5, IBM, Microsoft, NetApp, VMware и многие другие компании. Их продукты и технологии являются органичной частью модели ACI и поддерживают управление своим функционалом через контроллеры APIC.

Заключение

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

Концепция Cisco ACI уже используется в ЦОД более чем 500 крупнейших мировых ИТ-компаний. Для ознакомления с технологией Cisco предоставляет возможность воспользоваться своей площадкой интерактивных демонстраций dCloud, построенной на основе ACI.

Статья подготовлена в рамках многолетнего сотрудничества компании Cisco и TEGRUS, российского системного интегратора полного цикла, входящего в ТОП-50 крупнейших ИТ-компаний России. TERGUS, помимо широкого спектра решений Cisco, предлагает заказчикам полную проектную поддержку, в том числе инженерную, на всех этапах – от проектирования и строительства инженерной инфраструктуры до пуско-наладки, аудита и послепродажного обслуживания готового решения.