Сетевая архитектура для ЦОД и облаков

Прошло больше пяти лет, с тех пор как Cisco выпустила на рынок сетевую архитектуру для ЦОД Application Centric Infrastructure (ACI). На современном ИТ-рынке это довольно большой срок, позволяющий нам говорить о подведении промежуточных итогов и задумываться о планах на будущее. В этой статье мы расскажем о том, что сейчас представляет собой Cisco ACI, в чем ее достоинства и каковы ключевые направления развития.

Что такое Cisco ACI? Если попытаться ответить на этот вопрос одним предложением, то Cisco ACI – это эффективная сетевая инфраструктура с центральной точкой декларативного управления, мониторинга и автоматизации, обеспечивающая связность, применение политик безопасности и микросегментацию для невиртуализированных серверов, виртуальных машин и контейнерных сред. А теперь постараемся разобраться в том, что означает столь громкое заявление и на какие реальные возможности ACI оно опирается.

Строительные блоки системы

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

Главным достоинством такой архитектуры является возможность легко наращивать производительность и отказоустойчивость путем добавления коммутаторов Spine-уровня и независимо от этого наращивать портовую емкость путем добавления коммутаторов Leaf. Кроме того, меньшее число уровней означает меньшее число промежуточных портов и коммутаторов и тем самым меньшую стоимость решения при заданных требованиях. При необходимости несколько таких двухуровневых сетей может быть объединено в общую модульную ACI-фабрику как в рамках одного крупного ЦОД, так и для связи нескольких ЦОД. Применяемое в составе ACI-фабрики оборудование дает возможность использовать скорости от 1 до 400 Гбит/с, закрывая весь диапазон потребностей по производительности.

Поскольку в сетях Spine-Leaf передача данных происходит по многим альтернативным путям, использование протокола Spanning Tree, многие годы являвшегося одним из основных источников отказов в локальных сетях, просто неприемлемо. Вместо этого в ACI в качестве опорного транспорта используется маршрутизация протокола IP, а весь продуктивный трафик, как на втором, так и на третьем уровне модели OSI (модель Open Systems Interconnection), передается через опорную IP-сеть с использованием туннельных заголовков на основе технологии Virtual Extensible LAN (VXLAN), которые обеспечивают транспорт и сегментацию для L2 и L3, а также передачу дополнительной информации, необходимой для применения политик безопасности, о чем мы поговорим ниже.

Управление сетью

В отличие от большинства традиционных сетей все управление в сети ACI осуществляется не на уровне конкретных сетевых коммутаторов, которых в крупном ЦОД могут быть многие сотни, а с использованием центральной точки в виде контроллера APIC (Application Policy Infrastructure Controller), точнее кластера контроллеров, что позволяет обеспечить и отказоустойчивость, и масштабируемость. Важно отметить, что возможность центрального управления появляется не после первоначальной настройки сети, как это часто бывает в традиционных архитектурах, а с самого начала – сам процесс запуска ACI-фабрики происходит с использованием контроллера, так что единственное, для чего нужно физически прикоснуться к коммутаторам, – это их физическое размещение в стойках и подключение к ним сетевых соединений.

Возможности управления в ACI включают в себя не только конфигурирование, но и обратный поток информации – сбор и накопление статистики, данных об отказах и т. д. Наконец, сам принцип управления в ACI сильно отличается как от принятого в традиционных сетях, так и от используемого многими современными решениями из категории программно-определяемых сетей (Software Defined Network – SDN).

В ACI используется декларативный подход, при котором на уровне контроллера определяется высокоуровневая конечная цель (часто используется понятие Intent – намерение), которая должна быть реализована сетью, а уже сама сетевая инфраструктура берет на себя ее достижение. Такой целью может являться как чисто сетевая функция (например, определенная настройка портов или коммутаторов, подпадающих под определенное условие), так и политика, формулируемая на уровне приложения (например, разрешение взаимодействия между конкретными приложениями).

Применительно к сетям такой подход получил название Intent-based networking (сети, управляемые на основе намерений), и Cisco выступила пионером его воплощения. Достоинством такого подхода является то, что описание желаемого поведения сети может быть, насколько это возможно, приближено к бизнес-целям заказчика (например, к обеспечению взаимодействия определенных прикладных систем), а его реализация делегируется элементам инфраструктуры, которые должны обеспечивать его выполнение, в том числе и с учетом меняющихся условий (скажем, миграции виртуальных машин).

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

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

Информационная безопасность

Одной из основных тем в современных информационных технологиях, безусловно, является информационная безопасность. В традиционных сетях применение политик безопасности обычно возлагается на специализированные устройства: межсетевые экраны, IDS/IPS системы и т. д. А сама сеть в лучшем случае выполняет фильтрацию трафика между подсетями на основе IP-адресов, в остальном взаимодействие остается полностью «открытым».

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

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

Означает ли это, что при использовании ACI специализированные средства ИБ вообще не нужны? Разумеется, нет. Современные межсетевые экраны (МСЭ) и IDS/IPS могут выполнять анализ трафика на предмет угроз на гораздо более глубоком уровне, чем сеть, пусть и очень «умная». Преимуществом ACI при их использовании является гибкая модель встраивания средств безопасности (физических или виртуальных) в путь трафика, что дает возможность сочетать гранулярность задействования их ресурсов с полной свободой выбора узлов, между которыми контролируется взаимодействие. Так, например, можно направить на обработку на МСЭ вообще весь трафик определенного протокола между нагрузками определенного типа, даже входящими в одну и ту же подсеть, – задача, просто немыслимая в традиционных сетях.

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

Поскольку архитектура ACI разрабатывалась уже с учетом этих реальностей, она «из коробки» поддерживает без дополнительных продуктов все перечисленные типы нагрузок, включая виртуальные машины на платформах VMware vSphere, Microsoft Hyper-V, OpenStack и RedHat Virtualization, а также контейнерные среды на базе Kubernetes, OpenShift и Cloud Foundry. Такая поддержка не ограничивается только доведением до них необходимой связности, но также включает в себя применение политик безопасности и функции мониторинга.

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

Направление развития Cisco ACI

В заключение немного расскажем о том, как развивается ACI в настоящее время. Первоначально Cisco ACI была решением для сети одного ЦОД, затем появились архитектуры ACI Multi-Pod и ACI Multi-Site, обеспечивающие связь отказоустойчивых и катастрофоустойчивых ЦОД, возможность продолжать ACI-фабрику в небольшие «сателлитные ЦОД» с использованием технологии Remote Leaf. Такое направление развития получило название стратегии ACI Anywhere, предполагающей доведение возможностей ACI по управлению, безопасности и мониторингу в любую точку, где они необходимы.

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

Для поддержки расширения возможностей ACI в части управления, применения политик безопасности и мониторинга в гибридные облака было выпущено решение Cloud ACI, являющееся частью стратегии ACI Anywhere. Ряд существующих на рынке сетевых решений, обеспечивающих продолжение сети в облака, используют облачную инфраструктуру только как источник вычислительных ресурсов, строя между ними свои наложенные (оверлейные) сети. Такой подход, по сути, игнорирует механизмы управления сетевой связностью и политиками безопасности, созданные облачным оператором.

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

В настоящий момент решение Cloud ACI поддерживается для Amazon Web Services и Microsoft Azure, в дальнейшем этот список будет пополняться новыми облачными операторами.








 

ИД «Connect» © 2015-2019

Использование и копирование информации сайта www.connect-wit.ru возможно только с письменного разрешения редакции.

Техподдержка и обслуживание Роман Заргаров


Яндекс.Метрика
Яндекс.Метрика