2. Развитие подходов к построению сети ЦОД
Традиционная модель сети
Альтернативная
SDNмодель
Новая
модель сети
Проверенное решение
Существующая модель эксплуатации сети и приложений
Широкое распространение
Много точек управления
Негибкость
Остаётся сложность
Отдельные оверлей и транспортная сеть
Зависимость от гипервизора
Несколько точек управления
Программная виртуализация сети
Application CentricInfrastructure
Сумма устройств
Устраняет сложность
Управление по политикам
Аппаратные оверлеи
Автоматизация
Программируемая инфраструктура
Защита инвестиций
3. Cisco ACIновое поколение инфраструктуры ЦОД
ACI фабрика
Программируемость, масштабируемость, открытость
App
DB
Web
Внешняя сетьпередачи данных
QoS
ACL
QoS
LB
QoS
МСЭ, LB
Application Policy Infrastructure Controller
APIC
4. Сетевой профиль приложенияApplication Network Profile (ANP)
Входящие/ Исходящие политики
Сетевой профиль приложения
Сетевой профиль -логическое объединение групп EPG и политик, определяющих правила взаимодействия между EPG
=
Входящие/ Исходящие политики
5. Модель политик ACIконцепция End-Point Group (EPG)
HTTPS Service
HTTPS Service
HTTPS Service
HTTPS Service
HTTP Service
HTTP Service
HTTP Service
HTTP Service
EPG -Web
EPG–логическаягруппа конечных хостовпредставляющих приложение целиком или компоненты приложения,которая (в общем случае) не зависит от сетевых атрибутов
6. Вся передача данных в фабрике управляется при помощи профилей приложений
•IP адреса полностью переносимы и могут использоваться где угодно внутри фабрики
•Безопасность и передача данных не зависятот физических и логических сетевых атрибутов
•Коммутаторы автономно обновляют свои настройки на основе правил, определенных профилем приложения, в случае миграции приложения или его компонент
DB Tier
Storage
Storage
Клиент приложения
Web Tier
App Tier
Профиль приложения: определяет сетевые требования приложения(сетевой профиль приложения)
Применение профиля: каждое сетевое устройство динамически производит изменения настройки, требуемые профилем
VM
VM
VM
10.2.4.7
VM
10.9.3.37
VM
10.32.3.7
VM
VM
APIC
Сетевой профиль приложенияACIПрофиль приложения и его применение к сети
7. 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
Открытый RESTfulAPI
Управление при помощи политик
APIC
9. Обзор 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
10. ACI фабрикаИнтегрированные оверлеи
•
ACI фабрика базируется на IP сети, обеспечивающей маршрутизацию между элементами фабрики и интегрированных оверлеях для маршрутизации/коммутации между хостами фабрики
‒
весь трафик между конечными хостами внутри фабрики передается при помощи оверлеев
•
Почему интегрированные оверлеи?
‒
Мобильность, масштабируемость,поддержкаmulti-tenancyи интеграция с гипервизорами
‒
Вместе с трафиком данных можно передавать мета-данные для реализации распределенных политик
APIC
VTEP
VTEP
VTEP
VTEP
VTEP
VTEP
Payload
IP
VXLAN
VTEP
11. Таблица отображения фабрикиInline Hardware Mapping DB -1,000,000+ хостов
Local Station Table –адреса “всех”конечных хостов, которые подключены напрямую к Leafкоммутатору
10.1.3.11
fe80::462a:60ff:fef7:8e5e
10.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 3
10.1.3.11
Leaf 1
Leaf 4
Leaf 6
fe80::8e5e
fe80::5b1a
Proxy Station Table –адреса «всех» хостов, подключенных к фабрике
•
Таблица отображения на коммутаторе Leaf делится между локальнымии глобальными записями
•
Глобальная таблица на коммутаторе Leaf кеширует часть полной глобальной таблицы, которая содержится на каждом коммутаторе Spine
•
Если адрес конечного хоста не найден в локальном кэше, то (по умолчанию) пакет передается на коммутатор Spine (до 1,000,000+ записейв таблице отображения коммутатора Spine)
Proxy
Proxy
Proxy
12. Режимы передачи пакетов в фабрике
Неизвестный Layer 2 Unicast адрес
•
Если адрес назначения не известен, то он пересылается на коммутатор уровня Spine proxy. Если Spine не знает адрес, то пакет отбрасывается(Режим по умолчанию)
•
Опциональныйрежим -Flood Mode: если MAC адрес назначения не известен, то он пересылается всем хостам Bridge Domain-а
Неизвестный Layer 2 Unicast адрес
Неизвестный Layer 3 Unicast адрес
•
Если адрес не известен, то пакет пересылается коммутатору Spineproxy. Если Spine не знает адрес, то пакет отбрасывается
Передача на VTEP адрес AnycastLayer 2 MAC Proxy
Неизвестный Layer 3 Unicast адрес
Передача на VTEP адрес AnycastIPv4 Proxy
Если прокси не знает адрес, то пакет отбрасывается
APIC
13. ACI фабрикаНормализация инкапсуляции
VXLAN
VNID = 5789
VXLAN
VNID = 11348
NVGRE
VSID = 7456
Any to Any
802.1Q
VLAN 50
Нормализация инкапсуляции
Локализация
инкапсуляции
IP фабрика используетeVXLANтег
Данные
IP
eVXLAN
VTEP
•
Весь трафик инкапсулируется при помощи заголовкаextended VXLAN (eVXLAN)
•
Внешний тег VLAN, VXLAN, NVGREна входящем порту отображается во внутреннийeVXLANтег
•
Внешние идентификаторы локальны на уровне Leaf устройства или Leaf порта
•
Возможность переиспользования, если требуется
Данные
Данные
Данные
Данные
Данные
Eth
IP
VXLAN
Outer
IP
IP
NVGRE
Outer
IP
IP
802.1Q
Eth
IP
Eth
MAC
Нормализация входящей инкапсуляции
APIC
14. vSwitch (VMWare)
vSwitch (MSFT)
Payload
IP
VM, подключенная к Ingress Port Group или физический сервер формируют пакет
1
Payload
IP
VXLAN
VTEP
vSwitchинкапсулирует пакет и передает его в сторону Leaf VTEP
2
Если входящий Leaf коммутатор уже выучил соответствие IPадреса хоста назначения и адресаVTEP,то в качестве адреса назначения для eVXLANтуннеля выбирается известный VTEP адрес и пакет передается напрямую на исходящий Leaf коммутатор
4a
Payload
IP
eVXLAN
VTEP
Коммутатор Leaf заменяет заголовок VXLAN на eVXLANи применяет политику
3
Payload
IP
eVXLAN
VTEP
Исходящий Leafкоммутатор производит замену eVXLANзаголовка на требуемую инкапсуляцию и применяет политику
5
Payload
IP
NVGRE
GRE IP
Коммутатор Leaf передает пакетvSwitch-уили физическому серверу
6
Payload
IP
Пакет передается на порт vSwitch
7
Payload
IP
eVXLAN
VTEP
Если входящий Leaf коммутатор не имеет записи в кешео соответствии IP назначения адресу VTEP, то пакет пересылается на spine-коммутатор на адрес anycastVTEP, где на уровне ASIC происходит HW lookup и переписывается адрес VTEP назначения. Дополнительной задержки или снижения производительности при этом не происходит.
4b
VTEP
VTEP
VTEP
Передача пакетов в ACIфабрике
APIC
15. vSwitch (VMWare)
vSwitch (MSFT)
vSwitchинкапсулирует пакеты, ассоциированные с EPG при помощи назначенного VLAN/VXLAN/NVGRE идентификатора
1
Если коммутаторуLeaf известен исходящийEPG который ассоциирован с узлом назначения, то он реализует политику устанавливая в соответствующее значение бит в заголовке eVXLAN, показывающий, что входящая политика была применена к пакету
4
На основе классификации коммутаторLeafформирует значение поля Source Group в eVXLANзаголовке
3
Payload
IP
NVGRE
GRE IP
Коммутатор Leaf пересылает пакетvSwitch-уили подключенному напрямую физическому серверу.
7
Пакет идентифицируется как принадлежащий определенной end point group (EPG) на основе входящей классификации (port group, физический порт, IP адрес, VLAN)
2
Payload
VNID
Flags
VTEP
SRC Group
Если политика приложения требует передачу пакета через сервисное устройство или цепочку таких устройств, то фабрика в качестве VTEP узла назначенияуказывает адрес коммутатора, в которому подключено сервисное устройство
5
Исходящий Leaf коммутатор проверяет был ли установлен policy флаг в заголовке eVXLANи если требуется применяет политику
6
Реализация политик в ACI фабрике
Payload
VNID
Flags
VTEP
SRC Group
16. ACI фабрика: управление трафиком
Фокус на времени отклика приложения
•
ACI фабрика отслеживает перегрузки на всем пути передачи входящим и исходящим leaf(измерения в реальном времени)
‒
Перегрузка на внешних портах коммутаторов (external wires)
‒
Перегрузка на соединениях ASIC-to-ASIC (internal wires)
•
Фабрика балансирует потоки трафика по принципу ‘flowletswitching’
‒
Динамическоеперенаправление активных потоков с загруженного пути на менее загруженный путь передачи трафика
•
Фабрика приоритезируетнебольшие потоки
‒
Обеспечениеповедения как DC-TCP без модификации на конечном хосте
‒
Увеличениескорости передачи большихTCP потоков
APIC
17. Балансировка внутри ACI фабрикиFlowletSwitching
H1
H2
TCP поток
•Flowletswitching* обеспечивает независимую передачу “порций” пакетов принадлежащих одному потоку по разным аплинкам
•Без изменения порядка передаваемых пакетов
Gap ≥ |d1–d2|
d1
d2
*FlowletSwitching (Kandulaet al ’04)
18. Балансировка внутри ACI фабрикиDynamic Flow Prioritization
Реальный трафик представляет собой миксбольших (elephant) и малых(mice) потоков.
F1
F2
F3
Стандартный режим (один приоритет):
Потоки больших размеров влияют на производительность небольших потоков (задержкаи потери).
High
Priority
Dynamic Flow Prioritization:
фабрика автоматически приоритезируетпотоки малого размера
Standard
Priority
Ключевая идея:
Фабрика обнаруживает первые несколько “порций”(flowlets) каждого потока данных и помещает их в приоритетную очередь
19. ACI фабрика: возможности по телеметрии
•
Изменения в топологии и схеме распределения трафика заставляют пересмотреть традиционные подходы к поиску и устранения неисправностей, а так же планирования емкостей в ЦОД
•
Высокая степень разделяемостиинфраструктуры объединенная с распределенной сущность приложений требуют сбора статистки в контексте приложения
•
Возможности ACI фабрики
•
Atomic Counters–точный учёт переданных и потерянных пакетов по каждому пути
•
Измерение задержки–контроль матрицы задержек между всеми узлами
Необходимость мониторинга SLA в разделяемых ландшафтах
Фабрика больших размеров усложняет корреляцию собираемых статистических данных со специфическим приложением/tenant- ом
Увеличение распределенной нагрузки
VM
VM
VM
VM
VM
VM
APIC
21. Фабрика с поддержкой нескольких гипервизоров
•
Интегрированный шлюз для VLAN, VxLAN, NVGRE сетей
•
Заказчик не ограничен в выборе гипервизора
•
Фабрика готова к поддержке нескольких гипервизоров «из коробки»
•
Возможность использования нескольких VMM в одной группе EPG
Интеграция с
виртуальным миром
Сетевой администратор
Администратор приложения
ФИЗИЧЕСКИЙ СЕРВЕР
VLAN
VXLAN
VLAN
NVGRE
VLAN
VXLAN
VLAN
ESX
Hyper-V
KVM
Управление
гипервизором
ACI фабрика
APIC
APIC
22. Координация политик с администраторами гипервизоров
•
Координация сетевых политик с администраторами систем виртуализации
•
Автоматическое детектирование виртуальных машин и применение политик
•
Политики применяют к физическим и виртуализированнымресурсам
•
Политика следует за VM
Интеграция с
виртуальным миром
Управление гипервизорами
Web
App
DB
Профиль приложения
Координация сетевых политик
Web
App
DB
Нотификация о добавлении/ удалении VM
PortGroup
нотификация о перемещении VM
PortGroups
VM Networks
APIC
APIC
23. Cisco APIC and VMWarevCenterHandshake
ACI Fabric
Apply Policy
APP
DB
WEB
Application Network Profile
Firewal
ADC
Интеграция Cisco ACI и VMWare vSphere
APIC
Web
Web
Web
Web
App
App
HYPERVISOR
HYPERVISOR
HYPERVISOR
VIRTUAL DISTRIBUTED SWITCH
WEB PORT GROUP
APP PORT GROUP
DBPORT GROUP
DB
DB
VI/Server Admin
vCenter
Instantiate VMs
24. Instantiate VMs
Cisco APIC and Microsoft SCVMM Handshake
ACI Fabric
Apply Policy
VI/Server Admin
System Center Virtual Machine Manager
APP
DB
WEB
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
25. APIC Admin
(Performs Steps 3)
OpenStack Tenant
(Performs Steps 1,4)
Instantiate VMs
Create Application Policy
Web
Web
Web
Web
App
App
4
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
NOVA
NEUTRON
OPEN VIRTUAL SWITCH
OPEN VIRTUAL SWITCH
OPEN VIRTUAL SWITCH
Интеграция Cisco ACI и OpenStackФаза 1
APIC
37
26. Интеграция Cisco ACI и OpenStackФаза 2
2
ACI Admin
(manages physical network, monitors tenant state)
L/B
EPG APP
EPG
DB
F/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
Web
Web
Web
App
App
4
Create Application Network Profile
1
DB
DB
HYPERVISOR
HYPERVISOR
HYPERVISOR
NOVA
NEUTRON
Automatically Push Network Profiles to APIC
L/B
EPG APP
EPG
DB
F/W
L/B
EPG WEB
Application Network Profile
APIC
27. ACI:интеграция с сервисами 4 -7 уровня
Централизация, автоматизация и поддержка существующей модели
•
Эластичность вставки сервиса физического или виртуального
•
Помощь в административном разделении между уровнями приложения и сервиса
•
APIC –центральная точка контроля сети и согласовании политик
•
Автоматизация процесса развертывания/свертывания сервиса посредством программируемого интерфейса
•
Поддержка текущей операционной модели эксплуатации
•
Применение сервиса вне зависимости от места нахождения приложения
•
Описание сервисаввидеdevice package– может быть создан сторонним разработчиком
Web Server
App Tier
A
Web сервер
Web Server
App Tier
B
App
сервер
Сервисная
цепочка
“Security 5”
Политика перенаправления
Администратор приложения
Администратор сервиса
Серв. граф
begin
end
Stage 1
…..
Stage N
Providers
inst
inst
…
МСЭ
inst
inst
…
Балансировка
……..
Сервисный
профиль
Определение “Security 5”
28. ACI: автоматизации вставки сервиса
•
Для автоматизации управления сервисов требуется device package. Это zip файл:
•
Спецификация устройства (XML файл)
•
Скрипт устройства(Python)
•
APIC взаимодействует с устройством при помощи Python скрипта
•
APIC использует модель устройства, описанную в XML файле для настройки устройства при помощи скрипта
•
Для коммуникации с устройством скрипт использует REST илиCLI
Device Package
Device Specification
<devtype= “f5”>
<service type= “slb”>
<paramname= “vip”>
<devident=“210.1.1.1”
<validator=“ip”
<hidden=“no”>
<locked=“yes”>
APIC –Policy Element
Модель устройства
Специфичный для устройства Python скрипт
Скриптовый интерфейс APIC
Script Engine
Узел APIC
Интерфейс устройства: REST/CLI
Устройство
предоставляющее сервис (FW, SLB)
APIC
29. •
Сервисный граф настраивается в APIC
•
Определяет модель взаимодействия между EPG
•
В сервисной цепочке доступны следующие операции -split, join, tapи т.д.*
•
Типичные сервисы:
-
Firewall
-
IPS
-
TAP/Packet mirror
-
ADC/SLB
Cервисная архитектура Определение сервисного графа
IPS
EPG
Outside
EPG Web
TAP
EPG App
EPG DB
ADC
EPG Web
EPG
Desktop
EPG
Mobile
ADC
EPG Web2
EPG AppA
EPG Web1
FW
EPG App
ADC
EPG DB
*Не всё доступно первоначально
30. Tenant X
Автоматизация сервисных цепочекРоли и обязанности
Администратор приложения
•
Создание сервисного графа
•
Применение сервисного графа
•
Загружает device package
•
Подключает оборудование
•
Регистрирует сервисные устройства и назначает их группам пользователей (tenants)
•
Публикует сервисный граф
Device Package A
Device Package B
Device Package C
Объекты управления:
•Сервисный граф
•Конфигурация устройства и сервиса
Device A
Device B
Device C
Device C
Device A
Device A
Сетевой администратор
APIC
31. L4-L7 устройство может говорить на языке ACI! OpFlex: открытый декларативный протокол
•
Файл с integration packageбольше не нужен
•
OpFlexразрабатывается как открытый стандарт, который может быть реализован любым инфраструктурным элементом (коммутатор, L4-L7 устройство, маршрутизатор)
•
OpFlexIETF: http://tools.ietf.org/html/draft-smith-opflex-00
•
OpFlexтак же интегрируется вOpenDaylight: https://wiki.opendaylight.org/view/OpFlex:Main
•
OpFlexагент с открытым исходным кодом разрабатывается
•
Вендорыподдержавшие OpFlex:(список расширяется)
33. Открытая экосистемаACIВсе возможности доступны благодаря открытому API и модели данных
Объектно-ориентированная
Автоматизация
RESTfulXML / JSON
Открытая экосистема
Программируемость
Полный доступ к системе посредством API
Northbound API
•
Быстрая интеграция с существующими средствами управления
•
Поддержка приложений и орг. cтруктуры(tenant)
•
Поддержка OpenStack
Southbound API
•
Опубликованная модель данных
•
Протокол OpFlexдля открытой интеграции элементов вACI
•
Open sourceреализация DME
•
Встраивание L4-L7сервисов
*На момент FCSесть ограничения, обращайтесь за уточнениями
Системное
управление
Управлениегипервизорами
Средства автоматизации
Средства оркестрации
34. APIC
Представляем Opflex–открытое управление элементами фабрики ACI
ПРОТОКОЛ OPFLEX+ ЭКОСИСТЕМА
OPEN SOURCE
Открытыйкод, доступный всем
ЭКОСИСТЕМА
Широкая и постоянно расширяющаяся поддержка производителей включая гипервизоры, сетевые устройства L4-7
СТАНДАРТ
Стандартизация OpflexвIETF
OPFLEX
ЗАЩИТА ИНВЕСТИЦИИ ЗА СЧЕТ ВОЗМОЖНОСТИ СТОРОННЕМУ УСТРОЙСТВУ ИНТЕГРИРОВАТЬСЯ В ФАБРИКУ CISCO ACI
L4-7 DEVICE
КОММУТАТОР
ГИПЕРВИЗОРА
35. APIC
Opflex: открытый расширяемый протокол для описания политик
OPFLEXСОЗДАН,
ЧТОБЫ ОБЕСПЕЧИТЬ:
Policies:
•Who can talk to whom
•What about
•Ops requirements
Абстрактное описание политик а не настройки конкретного устройства
1.
Гибкое, расширяемое описание с использованием XML / JSON
2.
Поддержка любых устройств, включая виртуальные коммутаторы, физические коммутаторыи и сетевые сервисы с обеспечением интероперабельности между вендорами
3.
Открытый, стандартизованный API с эталонной open sourceреализацией
4.
OPFLEXPROXY
OPFLEXAGENT
OPFLEXAGENT
OPFLEXAGENT
HYPERVISOR SWITCH
ADC
FIREWALL
49
37. Сценарий 1: Подключение нового ACI Pod
Новый POD
Существующаяинфраструктура
BGP
OSPF
VLAN
VxLAN
38. Сценарий 2: Расширение уровня доступа
VLAN 10
Банд ACI начального уровня, подключенный к коммутаторам агрегации
Существующаяинфраструктура
VLAN 20
New Server Group
Layer 2 соединения
40.
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
41. Backbone
Внедрение ACI в существующих ЦОДВынесенные по IP leaf устройства: 9300 & AVS (1HCY15)
APIC Policy Controller
Directory/Proxy Service Nodes
Border Leaves
Nexus 9300: вынесенный leaf реализующий политики ACI
AVS
OVS
Hyper-V
AVS
vSwitch
ACI Policy based forwarding, automation, service insertion and counters extended to the edge of existing networks