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

Каким может стать ЦОД будущего?
Станислав Синицын | 25.07.2015

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

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

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

img

img

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

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

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

img

Рисунок 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”).

img

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

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

img

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

Теги: Модернизация ИТ-инфраструктуры, инфраструктура, ЦОД, SaaS, виртуализация, data center

Компания: IBM, Microsoft, NetApp, VMware, Cisco

Об авторе


Станислав Синицын

Руководитель направления сетевых решений и телефонии компании ТЕГРУС.


ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru


Другие материалы рубрики

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

Мероприятия


08.09.2016
Санкт-Петербургский клуб ИТ-директоров «SPb CIO Club» и компания Event House приглашает Вас принять участие во втором Форуме по промышленной автоматизации «Industrial IT-Forum»! Промышленная автоматизация на предприятии – важная область, которой уделяется повышенное внимание. Использование информационных технологий - один из немногих технологически и экономически выгодных способов повышения эффективности подготовки производства. На современных предприятиях автоматизируются по максимуму все возможные участки работ. Новый взгляд на проблемы и тенденции информационных технологий в области промышленной автоматизации будут рассмотрены на II Форуме по промышленной автоматизации «Industrial IT Forum»

22.09.2016
24 июня 2016 года Госдумой шестого созыва был принят законопроект «Антитеррористический пакет» Яровой, который назван одним из самых резонансных. Существенная часть законопроекта призвана регулировать деятельность телекоммуникационных и интернет компаний. Согласно документу, операторы связи и «организаторы распространения информации» должны в течение полугода хранить вообще всю переданную информацию, то есть и записи телефонных звонков, и содержание смс-сообщений. В течение трех лет они также обязаны хранить сведения о переданных данных. Наконец, компании должны помочь ФСБ расшифровать весь трафик. Как законопроект повлияет на рынок? Смогут ли крупнейшие интернет-компании отстоять свою позицию? Готово ли государство прислушиваться к мнению бизнеса? На конференции Право.ru участники обсудят скрытые и явные угрозы «пакета Яровой», а также о другие законодательные изменения.