Скороходов АлександрСистемный инженер-консультант

askorokh@cisco.com

Архитектура и принципы функционирования сетевой фабрики Cisco ACI

25.11.2014 © 2014 Cisco and/or its affiliates. All rights reserved.

Развитие подходов к построению сети ЦОДТрадиционная модель сети

АльтернативнаяSDN модель

Новая модель сети

Проверенное решениеСуществующая модель эксплуатации сети и приложенийШирокое распространениеМного точек управленияНегибкость

Остаётся сложностьОтдельные оверлей и транспортная сетьЗависимость от гипервизораНесколько точек управления

Программная виртуализация сети

Application CentricInfrastructure

Сумма устройств

Устраняет сложностьУправление по политикамАппаратные оверлеиАвтоматизацияПрограммируемая инфраструктураЗащита инвестиций

Cisco ACIновое поколение инфраструктуры ЦОД

ACI фабрика

Программируемость, масштабируемость, открытость

App DBWeb

Внешняя сетьпередачи данных

QoS

ACL

QoS

LB

QoS

МСЭ, LB

Application Policy Infrastructure

Controller

APIC

Сетевой профиль приложенияApplication Network Profile (ANP)

Входящие/Исходящие политики

Сетевой профиль приложения

Сетевой профиль - логическое объединение групп EPG и политик, определяющих правила взаимодействия между EPG

=

Входящие/Исходящие политики

Модель политик ACIконцепция End-Point Group (EPG)

HTTPS Service

HTTPS Service

HTTPS Service

HTTPS Service

HTTP Service

HTTP Service

HTTP Service

HTTP Service

EPG - Web

EPG – логическая группа конечных хостовпредставляющих приложение целиком или компоненты приложения, которая (в общем случае) не зависит от

сетевых атрибутов

Вся передача данных в фабрике управляется при помощи профилей приложений• IP адреса полностью переносимы и могут использоваться где угодно внутри фабрики• Безопасность и передача данных не зависят от физических и логических сетевых атрибутов• Коммутаторы автономно обновляют свои настройки на основе правил, определенных профилем приложения, в

случае миграции приложения или его компонент

DB Tier

Storage Storage

Клиент приложения

Web Tier App Tier

Профиль приложения: определяет сетевые требования приложения(сетевой профиль приложения)

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

VM VMVM

10.2.4.7

VM

10.9.3.37

VM

10.32.3.7

VMVM

APIC

Сетевой профиль приложения ACIПрофиль приложения и его применение к сети

Application Policy Infrastructure ControllerЦентрализованная автоматизация и управление фабрикой

• Единая точка управления политиками в сети ЦОД:

• Профили приложений• Интеграция с сервисами L4-L7• Открытая модель данных для управления при

помощи внешних средств оркестрации• Мониторинг приложений, поиск и устранение

неисправностей фабрики• Управление образами (Spine / Leaf)

• Кластер APIC может поддержать более миллиона конечных хостов, 200,000+ портов, 64,000+ логических организаций (tenant)

• Не принимает непосредственное участие в передаче данных

• Не занимается детальной настройкой

Сервисы 4..7 Управление системами

УправлениеСХД

Оркестрация

Storage SME Server SME Network SME

Security SME App. SME OS SME

Открытый RESTful API

Управление при помощи политик

APIC

Архитектура сетевой фабрики Cisco ACI

Обзор ACI фабрики• Наиболее эффективная фабрика в индустрии:

‒ 1/10 Gb на границе сети, высокая плотность 40GE на Spineи возможность перехода на 100GE

‒ 1 миллион+ IPv4 и IPv6 хостов‒ 64,000+ логических организаций (tenants)‒ 220K+ 1/10 Gb хостов на одном уровне с переподпиской

3:1 на уровне фабрики• Маршрутизируемая фабрика – оптимальная

передача IP трафика‒ Масштабируемая распределённая коммутация (L2) и

маршрутизация (L3) для VXLAN, NVGRE, VLAN‒ Не требуются программные шлюзы – физические или

виртуальные‒ Быстрота развертывания приложения – нет ограничений

при выборе точки размещения в фабрике• Полная прозрачность – физическая или

виртуальная нагрузка• Передача метаданных вместе с трафиком

‒ Детальное управление без необходимости программировать потоки

SpineАппаратная база отображения адресовДо 576 x 40 Gb портов на устройствоВысокая плотность за умеренную стоимость

Оптимизация фабрикиИспользование IEEE 1588 для измерения задержкиОптимальная балансировка ECMP

МасштабированиеИнтеллектуальное кешированиеПоддержка терминации оверлеевУлучшенная аналитика

APIC

ACI фабрикаИнтегрированные оверлеи

• ACI фабрика базируется на IP сети, обеспечивающей маршрутизацию между элементами фабрики и интегрированных оверлеях для маршрутизации/коммутации между хостами фабрики‒ весь трафик между конечными хостами внутри фабрики передается при помощи оверлеев

• Почему интегрированные оверлеи?‒ Мобильность, масштабируемость, поддержка multi-tenancy и интеграция с гипервизорами ‒ Вместе с трафиком данных можно передавать мета-данные для реализации распределенных политик

APIC

VTEP VTEP VTEP VTEP VTEP VTEP

PayloadIPVXLANVTEP

Таблица отображения фабрикиInline Hardware Mapping DB - 1,000,000+ хостов

Local Station Table – адреса “всех” конечных хостов,

которые подключены напрямую к Leaf коммутатору

10.1.3.11 fe80::462a:60ff:fef7:8e5e10.1.3.35 fe80::62c5:47ff:fe0a:5b1a

Proxy

10.1.3.11

10.1.3.35

Port 9

Leaf 3

Proxy *

Global Station Table –локальный кэш записей для

подключенных к фабрике хостов

10.1.3.35 Leaf 310.1.3.11 Leaf 1

Leaf 4Leaf 6

fe80::8e5efe80::5b1a

Proxy Station Table –адреса «всех» хостов, подключенных к фабрике

• Таблица отображения на коммутаторе Leaf делится между локальными и глобальными записями

• Глобальная таблица на коммутаторе Leaf кеширует часть полной глобальной таблицы, которая содержится на каждом коммутаторе Spine

• Если адрес конечного хоста не найден в локальном кэше, то (по умолчанию) пакет передается на коммутатор Spine (до 1,000,000+ записей в таблице отображения коммутатора Spine)

Proxy Proxy Proxy

Режимы передачи пакетов в фабрике

Неизвестный Layer 2 Unicast адрес• Если адрес назначения не известен, то он

пересылается на коммутатор уровня Spine proxy. Если Spine не знает адрес, то пакет отбрасывается (Режим по умолчанию)

• Опциональный режим - Flood Mode: если MAC адрес назначения не известен, то он пересылается всем хостам Bridge Domain-а

Неизвестный Layer 2 Unicast адрес

Неизвестный Layer 3 Unicast адрес• Если адрес не известен, то пакет

пересылается коммутатору Spine proxy. Если Spine не знает адрес, то пакет отбрасывается

Передача на VTEP адрес Anycast Layer 2 MAC Proxy

Неизвестный Layer 3 Unicast адрес

Передача на VTEP адрес Anycast IPv4 Proxy

Если прокси не знает адрес, то пакет отбрасывается

APIC

ACI фабрикаНормализация инкапсуляции

VXLANVNID = 5789

VXLANVNID = 11348

NVGREVSID = 7456

Any to Any

802.1QVLAN 50

Нормализация инкапсуляции

Локализацияинкапсуляции

IP фабрика используетeVXLAN тег

Данные IPeVXLANVTEP

• Весь трафик инкапсулируется при помощи заголовка extended VXLAN (eVXLAN)• Внешний тег VLAN, VXLAN, NVGRE на входящем порту отображается во

внутренний eVXLAN тег• Внешние идентификаторы локальны на уровне Leaf устройства или Leaf порта

• Возможность переиспользования, если требуетсяДанные

Данные

Данные

Данные

Данные

EthIPVXLANOuter

IP

IPNVGREOuterIP

IP802.1Q

EthIP

EthMAC

Нормализация входящей инкапсуляции

APIC

vSwitch (VMWare) vSwitch (MSFT)

PayloadIP

VM, подключенная к Ingress Port Group или физический сервер формируют пакет

1

PayloadIPVXLANVTEP

vSwitch инкапсулирует пакет и передает его в сторону Leaf VTEP

2

Если входящий Leaf коммутатор уже выучил соответствие IP адреса хоста назначения и адресаVTEP, то в качестве адреса назначения для eVXLANтуннеля выбирается известный VTEP адрес и пакет передается напрямую на исходящий Leaf коммутатор

4a

PayloadIPeVXLANVTEP

Коммутатор Leaf заменяет заголовок VXLAN на eVXLAN и применяет политику

3

PayloadIPeVXLANVTEP

Исходящий Leaf коммутатор производит замену eVXLAN заголовка на требуемую инкапсуляцию и применяет политику

5

PayloadIPNVGREGRE IP

Коммутатор Leaf передает пакетvSwitch-у или физическому серверу

6

PayloadIP

Пакет передается на порт vSwitch7

PayloadIPeVXLANVTEP

Если входящий Leaf коммутатор не имеет записи в кеше о соответствии IP назначения адресу VTEP, то пакет пересылается на spine-коммутатор на адрес anycast VTEP, где на уровне ASIC происходит HW lookup и переписывается адрес VTEP назначения. Дополнительной задержки или снижения производительности при этом не происходит.

4b

VTEP VTEP

VTEP

Передача пакетов в ACI фабрике

APIC

vSwitch (VMWare) vSwitch (MSFT)

vSwitch инкапсулирует пакеты, ассоциированные с EPG при помощи назначенного VLAN/VXLAN/NVGRE идентификатора

1

Если коммутатору Leaf известен исходящий EPG который ассоциирован с узлом назначения, то он реализует политику устанавливая в соответствующее значение бит в заголовке eVXLAN, показывающий, что входящая политика была применена к пакету

4

На основе классификации коммутатор Leaf формирует значение поля Source Group в eVXLAN заголовке

3

PayloadIPNVGREGRE IP

Коммутатор Leaf пересылает пакет vSwitch-у или подключенному напрямую физическому серверу.

7

Пакет идентифицируется как принадлежащий определенной end point group (EPG) на основе входящей классификации (port group, физический порт, IP адрес, VLAN)

2

PayloadVNIDFlagsVTEP SRC Group

Если политика приложения требует передачу пакета через сервисное устройство или цепочку таких устройств, то фабрика в качестве VTEP узла назначенияуказывает адрес коммутатора, в которому подключено сервисное устройство

5

Исходящий Leaf коммутатор проверяет был ли установлен policy флаг в заголовке eVXLAN и если требуется применяет политику

6

Реализация политик в ACI фабрике

PayloadVNIDFlagsVTEP SRC Group

ACI фабрика:управление трафиком

Фокус на времени отклика приложения

• ACI фабрика отслеживает перегрузки на всем пути передачи входящим и исходящим leaf (измерения в реальном времени)‒ Перегрузка на внешних портах коммутаторов

(external wires)‒ Перегрузка на соединениях ASIC-to-ASIC (internal

wires)• Фабрика балансирует потоки трафика по принципу

‘flowlet switching’‒ Динамическое перенаправление активных

потоков с загруженного пути на менее загруженный путь передачи трафика

• Фабрика приоритезирует небольшие потоки‒ Обеспечение поведения как DC-TCP без

модификации на конечном хосте‒ Увеличение скорости передачи больших TCP

потоков

APIC

Балансировка внутри ACI фабрикиFlowlet Switching

H1 H2TCP

поток

• Flowlet switching* обеспечивает независимую передачу “порций”пакетов принадлежащих одному потоку по разным аплинкам

• Без изменения порядка передаваемых пакетов

Gap ≥ |d1 – d2|

d1 d2

*Flowlet Switching (Kandula et al ’04)

Балансировка внутри ACI фабрикиDynamic Flow Prioritization

Реальный трафик представляет собой микс больших (elephant) и малых (mice) потоков.

F1

F2

F3Стандартный режим

(один приоритет):Потоки больших размеров

влияют на производительность небольших потоков

(задержка и потери).

HighPriority

Dynamic Flow Prioritization:фабрика автоматически приоритезирует потоки

малого размера

StandardPriority

Ключевая идея:Фабрика обнаруживает первые несколько “порций” (flowlets)каждого потока данных и помещает их в приоритетную очередь

ACI фабрика:возможности по телеметрии

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

приложений требуют сбора статистки в контексте приложения• Возможности ACI фабрики

• Atomic Counters – точный учёт переданных и потерянных пакетов по каждому пути• Измерение задержки– контроль матрицы задержек между всеми узлами

Необходимость мониторинга SLA в разделяемых ландшафтахФабрика больших размеров

усложняет корреляцию собираемых статистических данных со специфическим приложением/tenant-ом

Увеличение распределенной нагрузки VM VM VMVM VMVM

APIC

Интеграция сервисов и гипервизоров

Фабрика с поддержкой нескольких гипервизоров

• Интегрированный шлюз для VLAN, VxLAN, NVGRE сетей

• Заказчик не ограничен в выборе гипервизора

• Фабрика готова к поддержке нескольких гипервизоров «из коробки»

• Возможность использования нескольких VMM в одной группе EPG

Интеграция с виртуальным миром

Сетевой администратор

Администратор приложения

ФИЗИЧЕСКИЙ СЕРВЕР

VLANVXLAN

VLANNVGRE

VLANVXLAN

VLAN

ESX Hyper-V KVM

Управлениегипервизором

ACI фабрика

APIC

APIC

Координация политик с администраторами гипервизоров

• Координация сетевых политик с администраторами систем виртуализации

• Автоматическое детектирование виртуальных машин и применение политик

• Политики применяют к физическим и виртуализированным ресурсам

• Политика следует за VM

Интеграция с виртуальным миром

Управление гипервизорами

Web App DB

Профиль приложения

Координация сетевых политик

Web App DB

Нотификация о добавлении/ удалении VM PortGroup

нотификация о перемещении

VM

PortGroups VM Networks

APIC

APIC

Cisco APIC and VMWare vCenterHandshake

ACI Fabric

Apply Policy

APP DBWEB

Application Network ProfileFirewal ADC

Интеграция Cisco ACI и VMWare vSphere

APIC

Web

Web

Web

Web AppApp

HYPERVISOR HYPERVISOR HYPERVISOR

VIRTUAL DISTRIBUTED SWITCH

WEB PORT GROUP

APP PORT GROUP DB PORT GROUP

DB DB

VI/Server Admin

vCenter

Instantiate VMs

Instantiate VMs

Cisco APIC and Microsoft SCVMM Handshake

ACI Fabric

Apply Policy

VI/Server Admin

System Center Virtual Machine

Manager

APP DBWEB

Application Network Profile

LOGICAL SWITCH

VM NETWORK WEB

VM NETWORK APP

VM NETWORK DB

Web App

HYPERVISOR

App DB

HYPERVISOR

Web DB

HYPERVISOR

Firewal ADC

Интеграция Cisco ACI и Microsoft Hyper-V

APIC

APIC Admin(Performs Steps 3)

OpenStack Tenant(Performs Steps 1,4) Instantiate VMs

Create Application Policy

Web WebWebWeb AppApp4

3

5 ACI Fabric

Automatically Push Network Profiles to APIC

Push Policy

Create Network, Subnet, Security Groups, Policy NETWORK ROUTING SECURITY

1

2

DB DB

HYPERVISOR HYPERVISOR HYPERVISOR

NOVANEUTRON

OPEN VIRTUAL SWITCH OPEN VIRTUAL SWITCH OPEN VIRTUAL SWITCH

Интеграция Cisco ACI и OpenStackФаза 1

APIC

37

Интеграция Cisco ACI и OpenStackФаза 2

2

ACI Admin(manages physical

network, monitors tenant state)

L/BEPG APP

EPG DBF/W

L/B

EPG WEB

Application Network Profile

Create Application Policy

3

5 ACI Fabric

Push Policy

OpenStack Tenant(Performs step 1,4) Instantiate VMs

Web WebWebWeb AppApp4

Create Application Network Profile

1

DB DB

HYPERVISOR HYPERVISOR HYPERVISOR

NOVANEUTRON

Automatically Push Network Profiles to APIC

L/BEPG APP

EPGDBF/W

L/B

EPG WEB

Application Network Profile

APIC

ACI: интеграция с сервисами 4 - 7 уровняЦентрализация, автоматизация и поддержка существующей модели

• Эластичность вставки сервиса физического или виртуального

• Помощь в административном разделении между уровнями приложения и сервиса

• APIC – центральная точка контроля сети и согласовании политик

• Автоматизация процесса развертывания/свертывания сервиса посредством программируемого интерфейса

• Поддержка текущей операционной модели эксплуатации

• Применение сервиса вне зависимости от места нахождения приложения

• Описание сервиса в виде device package –может быть создан сторонним разработчиком

Web Server

App Tier A

Web сервер

Web Server

App Tier B

Appсервер

Сервисная цепочка

“Security 5”

Политика перенаправления

Администратор приложения

Администратор сервиса

Сер

в.гр

афbegin endStage 1…..

Stage N

Prov

ider

sinst

inst

…

МСЭ

inst

inst

…

Балансировка

……..

Сер

висн

ый

проф

иль

Определение “Security 5”

ACI: автоматизации вставки сервиса

• Для автоматизации управления сервисов требуется device package. Это zip файл:

• Спецификация устройства (XML файл)

• Скрипт устройства (Python)

• APIC взаимодействует с устройством при помощи Python скрипта

• APIC использует модель устройства, описанную в XML файле для настройки устройства при помощи скрипта

• Для коммуникации с устройством скрипт использует REST или CLI

Device PackageDevice Specification<dev type= “f5”>

<service type= “slb”><param name= “vip”><dev ident=“210.1.1.1”

<validator=“ip”<hidden=“no”><locked=“yes”>

APIC – Policy Element Модель устройства

Специфичный для устройства Python скрипт

Скриптовый интерфейс APIC

Script Engine

Узел APIC

Интерфейс устройства: REST/CLI

Устройство предоставляющее сервис

(FW, SLB)

APIC

• Сервисный граф настраивается в APIC

• Определяет модель взаимодействия между EPG

• В сервисной цепочке доступны следующие операции - split, join, tap и т.д.*

• Типичные сервисы:- Firewall- IPS- TAP/Packet mirror- ADC/SLB

Cервисная архитектура Определение сервисного графа

IPSEPGOutside EPG Web

TAPEPG App EPG DB

ADCEPG Web

EPGDesktop

EPGMobile

ADC

EPG Web2

EPG AppA

EPG Web1

FWEPG App ADC EPG DB

*Не всё доступно первоначально

Tenant X

Автоматизация сервисных цепочекРоли и обязанности

Администратор приложения

• Создание сервисного графа• Применение сервисного графа

• Загружает device package• Подключает оборудование• Регистрирует сервисные

устройства и назначает их группам пользователей (tenants)

• Публикует сервисный граф

Device Package A Device Package B Device Package C

Объекты управления:• Сервисный граф

• Конфигурация устройства и сервиса

Device A Device BDevice C Device CDevice ADevice A

Сетевой администратор

APIC

L4-L7 устройство может говорить на языке ACI!OpFlex: открытый декларативный протокол

• Файл с integration package больше не нужен• OpFlex разрабатывается как открытый стандарт, который

может быть реализован любым инфраструктурным элементом (коммутатор, L4-L7 устройство, маршрутизатор)

• OpFlex IETF: http://tools.ietf.org/html/draft-smith-opflex-00• OpFlex так же интегрируется в OpenDaylight:

https://wiki.opendaylight.org/view/OpFlex:Main• OpFlex агент с открытым исходным кодом разрабатывается• Вендоры поддержавшие

OpFlex: (список расширяется)

Открытость архитектуры ACI

Открытая экосистема ACIВсе возможности доступны благодаря открытому API и модели данных

Объектно-ориентированнаяАвтоматизация

RESTful XML / JSON

Открытая экосистема

Программируемость Полный доступ к системе

посредством API

Northbound API• Быстрая интеграция с

существующими средствами управления

• Поддержка приложений и орг. cтруктуры (tenant)

• Поддержка OpenStack

Southbound API• Опубликованная модель

данных• Протокол OpFlex для

открытой интеграции элементов в ACI

• Open source реализация DME• Встраивание L4-L7 сервисов *На момент FCS есть ограничения, обращайтесь за уточнениями

Системное управление

Управлениегипервизорами

Средства автоматизации

Средства оркестрации

APIC

Представляем Opflex – открытое управление элементами фабрики ACI

ПРОТОКОЛ OPFLEX + ЭКОСИСТЕМА

OPEN SOURCEОткрытый код, доступный всем

ЭКОСИСТЕМАШирокая и постоянно расширяющаяся поддержка производителей включая гипервизоры, сетевые устройства L4-7

СТАНДАРТСтандартизация Opflex в IETFOPFLEX

ЗАЩИТА ИНВЕСТИЦИИ ЗА СЧЕТ ВОЗМОЖНОСТИ СТОРОННЕМУ УСТРОЙСТВУ ИНТЕГРИРОВАТЬСЯ В ФАБРИКУ CISCO ACI

L4-7 DEVICE

КОММУТАТОРГИПЕРВИЗОРА

APIC

Opflex: открытый расширяемый протокол для описания политикOPFLEX СОЗДАН, ЧТОБЫ ОБЕСПЕЧИТЬ:

Policies:• Who can talk to

whom• What about• Ops requirements

Абстрактное описание политик а не настройки конкретного устройства 1.Гибкое, расширяемое описание с использованием XML / JSON2.Поддержка любых устройств, включая виртуальные коммутаторы, физические коммутаторыи и сетевые сервисы с обеспечением интероперабельности между вендорами

3.

Открытый, стандартизованный API с эталонной open source реализацией4.

OPFLEXPROXY

OPFLEXAGENT

OPFLEXAGENT

OPFLEXAGENT

HYPERVISOR SWITCH ADCFIREWALL

49

Миграция на ACI традиционных ЦОД

Сценарий 1:Подключение нового ACI Pod

Новый PODСуществующаяинфраструктура

BGPOSPFVLANVxLAN

Сценарий 2:Расширение уровня доступа

VLAN 10

Банд ACI начального уровня, подключенный к коммутаторам агрегацииСуществующая

инфраструктура

VLAN 20 New Server Group

Layer 2 соединения

Сценарий 3ACI как «сервисное устройство»

МСЭ 1

L3 OSPF BGP

L2 VLAN 802.1Q

L2L340G ACI

ADC

AVS поддерживает OpFlex для взаимодействия с APIC

Поддерживает произвольную сеть L2 (Nexus 7k/6k/5k/3k/2k/FI) между Nexus 9k и AVS: защита инвестиций

На данный момент для «запуска»OpFlex необходима L2 сеть

VMware DVS поддерживает только один L2 коммутатор между N9k и DVS Интеграция с помощью LLDP а не

OpFlex

Сценарий 4Интеграция средствами виртуальных коммутаторов

AVS

AVS

AVS

OpFlex

OpFlex

OpFlex

Phase 1: Layer 2 Existing Network/Local Switching

Backbone

Внедрение ACI в существующих ЦОДВынесенные по IP leaf устройства: 9300 & AVS (1HCY15)

APIC Policy Controller

Directory/Proxy Service Nodes

Border Leaves

Nexus 9300: вынесенный leaf реализующий политики ACI

AVS OVSHyper-VAVSvSwitch

ACI Policy based forwarding, automation, service insertion and counters extended to the edge of existing networks

CiscoRu Cisco CiscoRussia

Ждем ваших сообщений с хештегом#CiscoConnectRu

Пожалуйста, используйте код для оценки доклада:

2532

Спасибо

Скороходов АлександрPhone: +7(495)789-8615E-mail: askorokh@cisco.com

25.11.2014 © 2014 Cisco and/or its affiliates. All rights reserved.