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

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

По замыслу инвестора жизненный цикл ЦОД должен составлять порядка 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).

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

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

Приведенная архитектура отражает многие перечисленные ранее принципы: здесь находят применение виртуализованные коммутаторы, конвергентные сети, гарантируется непрерывность функционирования приложений за счет обеспечения катастрофоустойчивости. Решение работоспособно и отражает 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»).

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

Упоминавшийся выше принцип «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, предлагает заказчикам полную проектную поддержку, в том числе инженерную, на всех этапах — от проектирования и строительства инженерной инфраструктуры до пуско-наладки, аудита и послепродажного обслуживания готового решения.

*Источник — рейтинг CNews100: Крупнейшие ИТ-компании России.

НА ПРАВАХ РЕКЛАМЫ