Последние несколько лет Cisco активно продвигает новую архитектуру построения сети передачи данных в ЦОД — Application Centric Infrastructure (или ACI). Некоторые с ней уже знакомы. А кто-то даже успел внедрить её на своих предприятиях, в том числе и в России. Однако для большинства ИТ-специалистов и ИТ-руководителей ACI пока является либо непонятной аббревиатурой, либо всего лишь рассуждением о будущем.
В этой статье мы постараемся это будущее приблизить. Для этого мы расскажем об основных архитектурных компонентах ACI, а также проиллюстрируем способ её применения на практике. Кроме того, в ближайшее время мы организуем наглядную демонстрацию работы ACI, на которую может записаться каждый заинтересованный ИТ-специалист.
Узнать больше про новую архитектуру построения сети можно будет в Санкт-Петербурге в мае 2019 года. Все подробности – по ссылке . Записывайтесь!
Предыстория
Традиционной и самой популярной моделью построения сети является трёхуровневая иерархическая модель: ядро -> распределение (агрегация) -> доступ. На протяжении многих лет эта модель была эталоном, под нее производители выпускали различные сетевые устройства соответствующего функционала.
Раньше, когда информационные технологии были своего рода необходимым (и, честно скажем, не всегда желанным) придатком к бизнесу, данная модель была удобна, весьма статична и надёжна. Однако сейчас, когда ИТ являются одним из драйверов развития бизнеса, а во многих случаях и самим бизнесом, статичность данной модели стала вызывать большие проблемы.
Современный бизнес генерирует большое количество различных сложных требований к сетевой инфраструктуре. От сроков реализации этих требований напрямую зависит успешность бизнеса. Промедление в таких условиях недопустимо, а классическая модель построения сети зачастую не позволяет своевременно удовлетворять все бизнес-потребности.
К примеру, появление нового сложного бизнес-приложения предполагает совершение сетевыми администраторами большого количества однотипных рутинных операций на большом количестве разных сетевых устройств на разных уровнях. Кроме того, что это занимает много времени, это ещё и повышает риск допустить ошибку, которая может привеcти к серьезному простою ИТ-услуг и, как результат, к финансовому ущербу.
Корнем проблемы являются даже не сами сроки или сложность требований. Дело в том, что эти требования необходимо «переводить» с языка бизнес-приложений на язык сетевой инфраструктуры. Как известно, любой перевод — это всегда частичная потеря смысла. Когда владелец приложения говорит о логике работы своего приложения, сетевой администратор понимает набор VLAN-ов, Access list—ов на десятках устройств, которые нужно поддерживать, актуализировать и документировать.
Накопленный опыт и постоянное общение с заказчиками позволило Cisco спроектировать и внедрить новые принципы построения сети передачи данных центра обработки данных, которые отвечают современным тенденциям и основываются, в первую очередь, на логике бизнес-приложений. Отсюда и название — Application Centric Infrastructure.
Архитектура ACI.
Архитектуру ACI наиболее правильно рассматривать не с физической стороны, а с логической. Она основана на модели автоматизированных политик, объекты которых на верхнем уровне можно разделить на следующие компоненты:
Рассмотрим каждый уровень более подробно – при этом мы будем переходить от простого к сложному.
Сеть на базе коммутаторов Nexus
Сеть в ACI-фабрике похожа на традиционную иерархическую модель, но строится значительно проще. Для организации сети используется модель Leaf-Spine, которая стала общепринятым подходом для реализации сетей нового поколения. Данная модель состоит из двух уровней: Spine и Leaf, соответственно.
Уровень Spine отвечает только за производительность. Суммарная производительность Spine-коммутаторов равна производительности всей фабрики, поэтому на этом уровне следует использовать коммутаторы с портами 40G или выше.
Spine-коммутаторы соединяются со всеми коммутаторами следующего уровня: Leaf-коммутаторами, к которым подключаются конечные хосты. Основная роль Leaf-коммутаторов – портовая емкость.
Таким образом, легко решаются вопросы масштабирования: если нам требуется увеличить пропускную способность фабрики, мы добавляем Spine-коммутаторы, а если нам требуется увеличить портовую ёмкость – Leaf.
Для обоих уровней используются коммутаторы серии Cisco Nexus 9000, которые для Cisco являются основным инструментом для построения сетей ЦОД независимо от их архитектуры. Для уровня Spine используются коммутаторы Nexus 9300 или Nexus 9500, а для Leaf только Nexus 9300.
Модельный ряд коммутаторов Nexus, которые используются в ACI фабрике, приведён на рисунке ниже.
Кластер контроллеров APIC (Application Policy Infrastructure Controller)
APIC-контроллеры представляют из себя специализированные физические серверы, при этом для небольших внедрений допускается использовать кластер из одного физического APIC контроллера и двух виртуальных.
Контроллеры APIC осуществляют функции управления и мониторинга. Важно то, что контроллеры никогда не участвуют в передаче данных, то есть, если даже все контроллеры кластера выйдут из строя, то на стабильность работы сети это абсолютно не повлияет. Также необходимо отметить, что с помощью APIC-ов администратор управляет абсолютно всеми физическими и логическими ресурсами фабрики, и для того, чтобы внести какие-либо изменения, не требуется больше подключаться к тому или иному устройству, поскольку в ACI используется единая точка управления.
Теперь перейдем к одному из главных компонентов ACI – профилям приложений.
Профиль приложения (Application Network Profile) – это логическая основа ACI. Именно профили приложений определяют политики взаимодействия между всеми сетевыми сегментами и описывают непосредственно сами сетевые сегменты. ANP позволяет абстрагироваться от физического уровня и, по сути, представить, как нужно организовать взаимодействие между различными сегментами сети с точки зрения приложения.
Профиль приложения состоит из групп подключений (End-point groups – EPG). Группа подключений – это логическая группа хостов (виртуальных машин, физических серверов, контейнеров и т.п.), которые находятся в одном сегменте безопасности (не сети, а именно безопасности). Конечные хосты, которые относятся к той или иной EPG, могут определяться большим количеством критериев. Обычно используются следующие:
Для взаимодействия различных EPG предусмотрена сущность, которая называется контрактами. Контракт определяет отношения между разными EPG. Другими словами, контракт определяет какую услугу одна EPG предоставляет другой EPG. К примеру, мы создаём контракт, который позволяет ходить трафику по протоколу HTTPS. Далее мы соединяем этим контрактом, например, EPG Web (группа веб-серверов) и EPG App (группа серверов приложений), после этого эти две терминальные группы могут обмениваться трафиком по протоколу HTTPS.
На рисунке ниже описан пример настройки связи различных EPG через контракты в рамках одного ANP.
Профилей приложений в рамках ACI-фабрики может быть любое количество. Кроме того, контракты не привязаны к конкретному профилю приложения, их можно (и нужно) использовать для соединения EPG в разных ANP.
По сути, каждое приложение, для которого в том или ином виде нужна сеть, описывается собственным профилем. К примеру, на схеме выше приведена стандартная архитектура трёхзвенного приложения, состоящего из N-ного количества серверов внешнего доступа (Web), серверов приложений (App) и серверов СУБД (DB), а также описаны правила взаимодействия между ними. В традиционной сетевой инфраструктуре это был бы набор правил, прописанных на различных устройствах в инфраструктуре. В архитектуре ACI мы описываем эти правила в рамках одного профиля приложения. ACI с помощью профиля приложения позволяет значительно упростить создание большого количества настроек на различных устройствах, сгруппировав их все в единый профиль.
На рисунке ниже показан более жизненный пример. Профиль приложения Microsoft Exchange, выполненный из нескольких EPG и контрактов.
Центральное управление, автоматизация и мониторинг – одна из ключевых преимуществ ACI. ACI фабрика избавляет администраторов от рутинной работы по созданию большого количества правил на различных коммутаторах, маршрутизаторах и межсетевых экранах (при этом классический ручной метод настройки разрешен и может быть использован). Настройки профилей приложений и других объектов ACI автоматически применяются по всей ACI фабрике. Даже при физическом переключении серверов в другие порты коммутаторов фабрики не потребуется дублировать настройки со старых коммутаторов на новые и зачищать ненужные правила. Исходя из критериев принадлежности хоста к EPG, фабрика выполнит эти настройки автоматически и автоматически очистит неиспользуемые правила.
Интегрированные политики безопасности ACI реализованы по принципу белых списков, то есть то, что явно не разрешено, по умолчанию запрещено. В совокупности с автоматической актуализацией конфигураций сетевого оборудования (удаление «забытых» неиспользуемых правил и разрешений) этот подход значительно повышает общий уровень безопасности сети и сужает поверхность потенциальной атаки.
ACI позволяет организовывать сетевое взаимодействие не только виртуальных машин и контейнеров, но и физических серверов, аппаратных МСЭ и сетевого оборудования сторонних производителей, что делает ACI уникальным на текущий момент решением.
Новый подход компании Cisco к построению сети передачи данных на базе логики приложений — это не только автоматизация, безопасность и централизованное управление. Это ещё и современная горизонтально масштабируемая сеть, отвечающая всем требованиям современного бизнеса.
Реализация сетевой инфраструктуры на базе ACI позволяет всем подразделениям предприятия разговаривать на одном языке. Администратор руководствуется только логикой работы приложения, в котором описаны требуемые правила и связи. Также, как и логикой работы приложения руководствуются владельцы и разработчики приложения, служба информационной безопасности, экономисты и владельцы бизнеса.
Таким образом, компания Cisco на практике реализует концепцию сети центра обработки данных нового поколения. Хотите убедиться в этом сами? Приходите на демонстрацию Application Centric Infrastructure в Санкт-Петербурге и поработайте с сетью ЦОД-а будущего уже сейчас.
Записаться на мероприятие можно по ссылке .
В этой статье мы постараемся это будущее приблизить. Для этого мы расскажем об основных архитектурных компонентах ACI, а также проиллюстрируем способ её применения на практике. Кроме того, в ближайшее время мы организуем наглядную демонстрацию работы ACI, на которую может записаться каждый заинтересованный ИТ-специалист.
Узнать больше про новую архитектуру построения сети можно будет в Санкт-Петербурге в мае 2019 года. Все подробности – по ссылке . Записывайтесь!
Предыстория
Традиционной и самой популярной моделью построения сети является трёхуровневая иерархическая модель: ядро -> распределение (агрегация) -> доступ. На протяжении многих лет эта модель была эталоном, под нее производители выпускали различные сетевые устройства соответствующего функционала.
Раньше, когда информационные технологии были своего рода необходимым (и, честно скажем, не всегда желанным) придатком к бизнесу, данная модель была удобна, весьма статична и надёжна. Однако сейчас, когда ИТ являются одним из драйверов развития бизнеса, а во многих случаях и самим бизнесом, статичность данной модели стала вызывать большие проблемы.
Современный бизнес генерирует большое количество различных сложных требований к сетевой инфраструктуре. От сроков реализации этих требований напрямую зависит успешность бизнеса. Промедление в таких условиях недопустимо, а классическая модель построения сети зачастую не позволяет своевременно удовлетворять все бизнес-потребности.
К примеру, появление нового сложного бизнес-приложения предполагает совершение сетевыми администраторами большого количества однотипных рутинных операций на большом количестве разных сетевых устройств на разных уровнях. Кроме того, что это занимает много времени, это ещё и повышает риск допустить ошибку, которая может привеcти к серьезному простою ИТ-услуг и, как результат, к финансовому ущербу.
Корнем проблемы являются даже не сами сроки или сложность требований. Дело в том, что эти требования необходимо «переводить» с языка бизнес-приложений на язык сетевой инфраструктуры. Как известно, любой перевод — это всегда частичная потеря смысла. Когда владелец приложения говорит о логике работы своего приложения, сетевой администратор понимает набор VLAN-ов, Access list—ов на десятках устройств, которые нужно поддерживать, актуализировать и документировать.
Накопленный опыт и постоянное общение с заказчиками позволило Cisco спроектировать и внедрить новые принципы построения сети передачи данных центра обработки данных, которые отвечают современным тенденциям и основываются, в первую очередь, на логике бизнес-приложений. Отсюда и название — Application Centric Infrastructure.
Архитектура ACI.
Архитектуру ACI наиболее правильно рассматривать не с физической стороны, а с логической. Она основана на модели автоматизированных политик, объекты которых на верхнем уровне можно разделить на следующие компоненты:
- Сеть на базе коммутаторов Nexus.
- Кластер контроллеров APIC;
- Профили приложений;
Рассмотрим каждый уровень более подробно – при этом мы будем переходить от простого к сложному.
Сеть на базе коммутаторов Nexus
Сеть в ACI-фабрике похожа на традиционную иерархическую модель, но строится значительно проще. Для организации сети используется модель Leaf-Spine, которая стала общепринятым подходом для реализации сетей нового поколения. Данная модель состоит из двух уровней: Spine и Leaf, соответственно.
Уровень Spine отвечает только за производительность. Суммарная производительность Spine-коммутаторов равна производительности всей фабрики, поэтому на этом уровне следует использовать коммутаторы с портами 40G или выше.
Spine-коммутаторы соединяются со всеми коммутаторами следующего уровня: Leaf-коммутаторами, к которым подключаются конечные хосты. Основная роль Leaf-коммутаторов – портовая емкость.
Таким образом, легко решаются вопросы масштабирования: если нам требуется увеличить пропускную способность фабрики, мы добавляем Spine-коммутаторы, а если нам требуется увеличить портовую ёмкость – Leaf.
Для обоих уровней используются коммутаторы серии Cisco Nexus 9000, которые для Cisco являются основным инструментом для построения сетей ЦОД независимо от их архитектуры. Для уровня Spine используются коммутаторы Nexus 9300 или Nexus 9500, а для Leaf только Nexus 9300.
Модельный ряд коммутаторов Nexus, которые используются в ACI фабрике, приведён на рисунке ниже.
Кластер контроллеров APIC (Application Policy Infrastructure Controller)
APIC-контроллеры представляют из себя специализированные физические серверы, при этом для небольших внедрений допускается использовать кластер из одного физического APIC контроллера и двух виртуальных.
Контроллеры APIC осуществляют функции управления и мониторинга. Важно то, что контроллеры никогда не участвуют в передаче данных, то есть, если даже все контроллеры кластера выйдут из строя, то на стабильность работы сети это абсолютно не повлияет. Также необходимо отметить, что с помощью APIC-ов администратор управляет абсолютно всеми физическими и логическими ресурсами фабрики, и для того, чтобы внести какие-либо изменения, не требуется больше подключаться к тому или иному устройству, поскольку в ACI используется единая точка управления.
Теперь перейдем к одному из главных компонентов ACI – профилям приложений.
Профиль приложения (Application Network Profile) – это логическая основа ACI. Именно профили приложений определяют политики взаимодействия между всеми сетевыми сегментами и описывают непосредственно сами сетевые сегменты. ANP позволяет абстрагироваться от физического уровня и, по сути, представить, как нужно организовать взаимодействие между различными сегментами сети с точки зрения приложения.
Профиль приложения состоит из групп подключений (End-point groups – EPG). Группа подключений – это логическая группа хостов (виртуальных машин, физических серверов, контейнеров и т.п.), которые находятся в одном сегменте безопасности (не сети, а именно безопасности). Конечные хосты, которые относятся к той или иной EPG, могут определяться большим количеством критериев. Обычно используются следующие:
- Физический порт
- Логический порт (порт-группа на виртуальном коммутаторе)
- VLAN ID или VXLAN
- IP-адрес или IP-подсеть
- Атрибуты сервера (имя, расположение, версия ОС и т.п.)
Для взаимодействия различных EPG предусмотрена сущность, которая называется контрактами. Контракт определяет отношения между разными EPG. Другими словами, контракт определяет какую услугу одна EPG предоставляет другой EPG. К примеру, мы создаём контракт, который позволяет ходить трафику по протоколу HTTPS. Далее мы соединяем этим контрактом, например, EPG Web (группа веб-серверов) и EPG App (группа серверов приложений), после этого эти две терминальные группы могут обмениваться трафиком по протоколу HTTPS.
На рисунке ниже описан пример настройки связи различных EPG через контракты в рамках одного ANP.
Профилей приложений в рамках ACI-фабрики может быть любое количество. Кроме того, контракты не привязаны к конкретному профилю приложения, их можно (и нужно) использовать для соединения EPG в разных ANP.
По сути, каждое приложение, для которого в том или ином виде нужна сеть, описывается собственным профилем. К примеру, на схеме выше приведена стандартная архитектура трёхзвенного приложения, состоящего из N-ного количества серверов внешнего доступа (Web), серверов приложений (App) и серверов СУБД (DB), а также описаны правила взаимодействия между ними. В традиционной сетевой инфраструктуре это был бы набор правил, прописанных на различных устройствах в инфраструктуре. В архитектуре ACI мы описываем эти правила в рамках одного профиля приложения. ACI с помощью профиля приложения позволяет значительно упростить создание большого количества настроек на различных устройствах, сгруппировав их все в единый профиль.
На рисунке ниже показан более жизненный пример. Профиль приложения Microsoft Exchange, выполненный из нескольких EPG и контрактов.
Центральное управление, автоматизация и мониторинг – одна из ключевых преимуществ ACI. ACI фабрика избавляет администраторов от рутинной работы по созданию большого количества правил на различных коммутаторах, маршрутизаторах и межсетевых экранах (при этом классический ручной метод настройки разрешен и может быть использован). Настройки профилей приложений и других объектов ACI автоматически применяются по всей ACI фабрике. Даже при физическом переключении серверов в другие порты коммутаторов фабрики не потребуется дублировать настройки со старых коммутаторов на новые и зачищать ненужные правила. Исходя из критериев принадлежности хоста к EPG, фабрика выполнит эти настройки автоматически и автоматически очистит неиспользуемые правила.
Интегрированные политики безопасности ACI реализованы по принципу белых списков, то есть то, что явно не разрешено, по умолчанию запрещено. В совокупности с автоматической актуализацией конфигураций сетевого оборудования (удаление «забытых» неиспользуемых правил и разрешений) этот подход значительно повышает общий уровень безопасности сети и сужает поверхность потенциальной атаки.
ACI позволяет организовывать сетевое взаимодействие не только виртуальных машин и контейнеров, но и физических серверов, аппаратных МСЭ и сетевого оборудования сторонних производителей, что делает ACI уникальным на текущий момент решением.
Новый подход компании Cisco к построению сети передачи данных на базе логики приложений — это не только автоматизация, безопасность и централизованное управление. Это ещё и современная горизонтально масштабируемая сеть, отвечающая всем требованиям современного бизнеса.
Реализация сетевой инфраструктуры на базе ACI позволяет всем подразделениям предприятия разговаривать на одном языке. Администратор руководствуется только логикой работы приложения, в котором описаны требуемые правила и связи. Также, как и логикой работы приложения руководствуются владельцы и разработчики приложения, служба информационной безопасности, экономисты и владельцы бизнеса.
Таким образом, компания Cisco на практике реализует концепцию сети центра обработки данных нового поколения. Хотите убедиться в этом сами? Приходите на демонстрацию Application Centric Infrastructure в Санкт-Петербурге и поработайте с сетью ЦОД-а будущего уже сейчас.
Записаться на мероприятие можно по ссылке .
