Каким может стать ЦОД будущего?
Центр обработки данных, ЦОД, ? понятие, которое каждый представляет себе несколько по-своему. В целом это сложный аппаратно-программный комплекс, состоящий из десятков инженерных подсистем, относительно безлюдная среда обитания ИТ-оборудования и корпоративных приложений, некое пространство, в котором можно даже с другого континента арендовать для своих нужд необходимого размера сегмент с нужными характеристиками.
Несмотря на свою дороговизну, ЦОД быстро перестает удовлетворять потребностям своих создателей и их клиентов. В результате владельцы вынуждены постоянно достраивать новые площадки и серьезно модернизировать существующие.
По замыслу инвестора жизненный цикл ЦОД должен составлять порядка 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, предлагает заказчикам полную проектную поддержку, в том числе инженерную, на всех этапах – от проектирования и строительства инженерной инфраструктуры до пуско-наладки, аудита и послепродажного обслуживания готового решения.
Опубликовано 25.07.2015