24 Июля 2015 19:07 | 24 Июл 2015 19:07 | |

Поделиться

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

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

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

Современные центры обработки данных в довольно короткие сроки перестают в должном объеме удовлетворять потребностям и ожиданиям своих владельцев и создателей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: Сisco

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

Сетевая архитектура для работы корпоративного приложения

Источник: Сisco

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

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

При этом возникает целый ряд вопросов.

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

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

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

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

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

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

Именно такое решение под именем Application Centric Infrastructure (ACI) в конце 2013 года предложила компания Cisco Systems. Технология 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 и политик их взаимодействия. Например, «серверам из EPG «A» позволено обращаться к серверам в EPG «B» по порту TCP/80», или «пропускную способность канала из сетей «Outside» для доступа к серверам в EPG «Web» ограничить 1000 Мбит/с». Подобные взаимоотношения в терминах ACI называются «контрактами»: одна сторона контракт предоставляет, другая потребляет.

Архитектура Cisco ACI

Источник: Сisco

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

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

Источник: Сisco

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

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

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

При кажущейся идеологической схожести, подход Cisco ACI не является реализацией парадигмы SDN. APIC — не SDN-контроллер, а коммутаторы Nexus 9000, в отличие от максимально облегченных коммутаторов OpenStack, являются сложными сетевыми устройствами, оснащенными «тяжелыми» ASIC. Можно сказать, что модель ACI предназначена для управления средой ЦОД с позиций более высокого уровня абстракции, чем при традиционном подходе SDN, и изначально нацелена на развертывание приложений и облачных сред.

Заключение

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

Будущее, несомненно, за гибкими, широко масштабируемыми архитектурами ЦОДов, в которых сервисный слой тесно интегрирован с сетевым, и при этом инфраструктура рассчитана на программное управление.

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

И вот где может прийти на помощь упомянутый выше принцип модульности ЦОДа. Опыт взаимодействия с заказчиками, планировавшими развертывание новых ЦОДов в 2014–2015 годах, свидетельствует: несмотря на молодость модели, интерес к ACI огромный. Однако чтобы не рисковать, для тестирования возможности коммерческого использования ACI в ЦОД, как правило, планируется отдельная ACI-зона, в которой постепенно размещаются не только тестовые, но и реальные корпоративные и коммерческие приложения. При оценке рисков важно учитывать, что в дальнейшем ACI-фабрику на Nexus 9000 можно перевести в классический режим Core-Edge.

Технология ACI в настоящее время интенсивно развивается и демонстрирует весьма интересные результаты. Например, на конференции Gartner Datacenter Conference, проходившей в Лас Вегасе 13 января 2015 года, в одном из докладов прозвучало, что процедура развертывания приложения при переходе на архитектуру ACI сократилась со 149 до 7 шагов.

Сегодня уже можно с уверенностью утверждать, что концепция Cisco ACI надежно укрепилась на рынке ЦОДов и облачных вычислений. Это подтверждается активным тестированием и внедрением в крупнейших ЦОДах планеты, в таких компаниях как Symantec, NetApp, Avit Systems, Zitcom, NetCloud, P-Pros, Key Information Systems, Qbranch, HalkBank, Sungard, Du, Acxiom, E*Trade, Qatar University, UOL, County of Riverside, Millenial Media (всего более 500 заказчиков), а также в ЦОДах технологических партнеров, совместно с Cisco разрабатывающих интегрированные решения.

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

Поделиться

Короткая ссылка