Эволюция технологий для организации сервисных цепочек в ЦОД

Эволюция технологий для организации
сервисных цепочек в ЦОД
Хаванкин Максим
cистемный архитектор
mkhavank@cisco.com
11/20/14 © 2014 Cisco and/or its affiliates. All rights reserved.

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

Содержание
§ Введение
§ Организация сервисных цепочек в виртуализированной среде - vPath
§ Подключение сервисных устройств к DFA
§ Интеграция сервисных устройств с ACI
§ Архитектура Network Service Header
§ Заключение

Сложности при интеграции сервисов
в существующие ЦОД
Настройка сети для подключения МСЭ
Настройка сетевых параметров балансировщика
4
VLAN 12
10.0.12.0/24
Вставка сервиса в традиционных
сетях
SNAT
Настройка сетевых параметров МСЭ
Настройка правил на МСЭ
Перенаправление трафика на балансировщик
Серверы Настройка балансировщика
Вставка сервиса
занимает дни
Настройка сети
занимает время и
является возможным
источником ошибок
Сложности в
отслеживании
изменений
VLAN 10
10.0.10.0/28
VLAN 11
10.0.11.0/28
PBR
VLAN 13
10.0.13.0/24

Решает ли проблему сложности тотальная
виртуализация?
5
Virtual router
SNAT
VXLAN 12
10.0.12.0/24
Вставка сервиса в традиционных
виртуализированных сетях
Configure Network to insert Firewall
Configure firewall rules
Виртуальные серверы
Упростится ли решаемая
задача, если для вставки
виртуализированного
сервиса применяются те
же сетевые концепции,
что и для физической
сети?
VXLAN 10
10.0.10.0/28
VXLAN 11
10.0.11.0/28
PBR
VXLAN 13
10.0.13.0/24
Virtual FW
Virtual router Virtual ADC
Virtual switch

Что делать с распределенными сервисами?
DC-1
Subnet A
DC-2
Subnet A
L3 ядро
Outside
VLAN
Inside
VLAN
VIP
VLAN
Front-‐end
VLAN
Back-‐end
VLAN
VIP
Src-NAT
• Эффект пинг-понга
для сервисных
элементов в
распределенных
ЦОД

Сервисные цепочки (SFC) и узлы (SN)
§ Сервисная цепочка – Service Function Chain (SFC)
§ упорядоченный набор сервисных функций (SF)
§ направленный граф в вершинах которого находятся сервисные функции
§ абстракция
§ Сервисный узел – Service Node (SN)
§ устройство, реализующее одну или несколько сервисных функций
11/20/14 © 2014 Cisco and/or its affiliates. All rights reserved. 7

Сервисный путь ( SFP)
§ Сервисный путь – Service Function Path (SFP)
§ конкретная реализация абстрактной сервисной цепочки
§ одной цепочке может соответствовать несколько путей
SF-6.1 и SF-6.2 – два
экземпляра одной
сервисной функции на
разных узлах кластера
сервисных устройств

Динамический выбор сервисного пути
§ Изменение сервисного пути в зависимости от результатов работы
сервисного устройства
DPI устройство принимает
решение изменить
сервисный путь

Организация сервисных цепочек в
виртуализированной среде - vPath

Компоненты коммутатора Nexus 1000V
VSM-1 VSM-2
Гипервизор Гипервизор Гипервизор
…
Устройство Nexus 1100
VSM-A1 VSM-A6
VSM-B1 VSM-B6
Виртуальная машина
Управление
VEM-N VEM-2 VEM-1
Модульный коммутатор
L2
M
O
D
E
Supervisor-1
Supervisor-2
Linecard-1
Linecard-2
Linecard-N
VSM-1
VSM-2
VEM-1
VEM-2
VEM-N
L3
M
O
D
E
…
Back plane
VSM: Virtual Supervisor Module
VEM: Virtual Ethernet Module

vPath – перенаправление 1-го пакета каждой новой
сессии на сервисную цепочку
VM VM
VM VM VM
Nexus 1000V
Distributed Virtual Switch
VM
VM VM
VM VM VM
VM VM VM
VM
VM VM VM
VM
vPath
Первый
пакет в
сессии
Сервисное
устройство
1 Проверка пакета
согласно политике
2
3
4
Результат
политики в
кеше

vPath – обработка последующих пакетов этого же потока
VM VM
VM VM VM
Nexus 1000V
Distributed Virtual Switch
VM
VM VM
VM VM VM
VM VM VM
VM
VM VM VM
VM
vPath
Результат политики в кеше
определяет дальнейшие
действия Nexus 1000v
Последующие
пакеты к сессии
Сервисное

Шаг 1: Подготовка N1K и сетевой фабрики к подключению
сервисных виртуальных машин
§ Установить Nexus 1000V
§ Cisco Virtual Switch Update Manager
§ Установить сервисные ВМ с поддержкой vPath
§ PNSC -> VSG, Netscaler, ASAv*
§ Подготовка сетевой фабрики
§ L3 связанность
§ Никаких специальных требований
*roadmap

Шаг 2: регистрируем сервисные узлы в N1K
vservice node ASA-1 type asa
ip address 10.0.21.1
adjacency l2 vlan 21
fail-mode close
vservice node VSG-1 type vsg
ip address 10.0.21.254
adjacency l2 vlan 21
fail-mode close
switch# show vservice brief
--------------------------------------------------------------------------------
License Information
--------------------------------------------------------------------------------
Type In-Use-Lic-Count UnLicensed-Mod
asa 2
--------------------------------------------------------------------------------
Node Information
--------------------------------------------------------------------------------
ID Name Type IP-Address Mode State Module
1 VSG-1 vsg 10.0.21.254 v-21 Alive 4,
2 ASA-1 asa 10.0.21.1 v-21 Alive 4,

Шаг 3: создаем сервисную цепочку
vservice path WEB-CHAIN
node VSG-1 profile WEB_SP order 1
node ASA-1 profile TEST-EDGE-SP order 3
<часть вывода опущена>
--------------------------------------------------------------------------------
Path Information
--------------------------------------------------------------------------------
Name:WEB-CHAIN NumOfSvc:2 Mod:4,
Node Order Profile
VSG-1 1 WEB_SP
ASA-1 3 TEST-EDGE-SP
--------------------------------------------------------------------------------

Шаг 4: цепочка подключается к профилю
port-profile type vethernet V-CONT.WEB
org root/tenant-01
vservice path WEB-CHAIN
--------------------------------------------------------------------------------
Port Information
--------------------------------------------------------------------------------
PortProfile:V-CONT.WEB
Org:root/tenant-01
Path:WEB-CHAIN
Node Profile(Id)
VSG-1(10.0.21.254) WEB_SP(9)
ASA-1(10.0.21.1) TEST-EDGE-SP(8)
Veth Mod VM-Name vNIC IP-Address
15 4 r1-web-v2 1 10.0.21.10
<часть вывода опущена>

Шаг 5: настройка политик на сервисных ВМ
§ Традиционный подход к управлению сервисными ВМ
§ Свой CLI/GUI для каждой сервисной функции или группы функций
§ Nexus 1000V или сетевая фабрика не берут на себя функции управления
политиками сервисных устройств
Prime Network
Services Controller

vPath – основные характеристики
«Разгрузка» обработки с сервисного элемента
vPath
«Разгрузка» обработки с сервисного элемента Да
Автоматизация
настроек
Фабрика UCS-D
Гипервизор VACS
Сервисное устройство UCS-D, PNSC, VACS
Автоподключение сервисного устройства Нет
Производители сервисных устройств Cisco, Citrix, Imperva
Фабрика управляет сервисным устройством Нет
Полностью автоматическая конфигурация
сервисного устройства Нет
Вид цепочки Последовательно
Динамический выбор сервисного пути Нет
Сервисная инкапсуляция vPath
Поддержка HA сервисных устройств Да
Scale-out модель для сервисных устройств Нет

Автоматизация при помощи Virtual Application Container Services (VACS)
vPath
настроек
Развертывание контейнера на базе
Nexus 1000V и vPath в 1-клик

Собственная сервисная инкапсуляция
vPath
настроек
vPath инкапсуляция - проверенный
способ создания сервисных цепочек

Подключение сервисных устройств к DFA

Управление
фабрикой
Оптимизация Автоматизация передачи данных
Оптимизация
передачи данных
Автоматизация Виртуальные фабрики
24
Архитектура Dynamic Fabric Automation
Основные компоненты
Простой модульный набор функций упрощающий развертывание

Архитектура Dynamic Fabric Automation
Подключение сервисных устройств
N1KV/OVS
Точки подключения сервисных
устройств и виртуальных машин
Services WAN/Core
Spine - агрегация
Leaf - доступ
Border Leaf – граница
Services Leaf - сервис
Virtual Leaf - виртуальный
N1KV/OVS
N1KV/OVS
Виртуальные машины
Физические сервера
FEX-ы, UCS FI, СХД, блейды
Коммутаторы 3-х производителей
Сервисные вирт. машины
МСЭ
Балансировщики
Устройства 3х производителей
Маршрутизаторы
Коммутаторы
Устройства 3х производителей
Замечание: роли на уровне доступа (leaf) - логические. Один и тот же
коммутатор доступа (leaf) может быть одновременно обычным
коммутатором доступа и сервисным и пограничным.

Шаг 1: подготовка сетевой фабрики
§ Развертывание DFA фабрики при помощи POAP-шаблонов
§ Подключение продуктивной нагрузки
26
Core/WAN
Leaf
BL
Spine
Spine
Leaf Leaf
Клиенты
www1 - 10.10.10.11
vlan 55
vn-segment 30051
mode fabricpath
interface vlan 55
vrf member INSIDE
ip address 10.10.10.1/24
fabric forwarding mode proxy-gateway
no ip redirects
no shutdown
VRF: INSIDE

Шаг 1: подготовка сетевой фабрики
§ При создании партиции для подключения нагрузки указываем IP адрес
§ INSIDE-интерфейс (условно)
IP адрес сервисного
устройства = INSIDE =
Service ES Network

Шаг 2: создаем виртуальную фабрику для подключения
28
§ Добавляем дополнительный VRF
§ Сервисный узел = маршрутизация между VRF
Leaf
Spine
Spine
Leaf Leaf
www1 - 10.10.10.11
Core/WAN
Leaf
BL
Spine
Spine
Leaf Leaf
VRF: INSIDE
Клиенты
VRF: OUTSIDE
vlan 55
vn-segment 30051
mode fabricpath
interface vlan 55
vrf member INSIDE
ip address 10.10.10.1/24
fabric forwarding mode proxy-gateway
no ip redirects
no shutdown
Дополнительный VRF
Сервисное

Шаг 2: создаем виртуальную фабрику для подключения
29
§ Cоздаем в DCNM партицию = VRF для подключения внешнего
интерфейса сервисного устройства
§ Указываем IP адрес сервисного устройства
§ OUTSIDE-интерфейс (условно)
IP адрес сервисного
устройства = OUTSIDE =
External network

Шаг 3: создаем профиль автоконфигурации INSIDE
Внутренний интерфейс сервисного устройства
Тип подключения = Service-
ES Network = внутреннее
Конфигурация, которая
появится на устройстве
после обнаружения
подключения к фабрике
INSIDE интерфейса

Шаг 4: создаем профиль автоконфигурации OUTSIDE
Внешний интерфейс сервисного устройства
Тип подключения = External
Network = внешнее
Конфигурация, которая
появится на устройстве
после обнаружения
подключения к фабрике
OUTSIDE интерфейса

Шаг 5: Настраиваем маршрутизацию на сервисном
устройстве, например ASA
interface TenGigabitEthernet0/6.20
vlan 20
nameif INSIDE
security-level 100
ip address 10.2.20.1 255.255.255.248
!
interface TenGigabitEthernet0/6.200
vlan 200
nameif OUTSIDE
security-level 0
ip address 10.2.200.1 255.255.255.248
!
router ospf 2
router-id 10.2.20.1
network 10.2.20.0 255.255.255.248 area 0
network 10.2.200.0 255.255.255.248 area 0
log-adj-changes

Шаг 6: Подключаем сервисное устройство
Автоконфигурация интерфейсов фабрики
Leaf
VRF: INSIDE
Spine
Spine
Leaf Leaf
www1 - 10.10.10.11
Core/WAN
Leaf
BL
Spine
Spine
Leaf Leaf
VRF: OUTSIDE
Клиенты
Сервисное
vlan 30
vn-segment $segmentId
mode fabricpath
interface vlan 30
vrf member INSIDE
ip address 192.168.30.1/30
ip router ospf 4 area 0.0.0.0
no shutdown
router ospf 4
vrf INSIDE
router-id 192.168.30.1
include profile vrf-common-External-Dynamic
vlan 41
vn-segment 30041
mode fabricpath
interface vlan 41
vrf member OUTSIDE
ip address 192.168.30.5/30
ip router ospf 2 area 0.0.0.0
no shutdown
router ospf 2
vrf OUTSIDE
router-id 192.168.30.5
redistribute direct route-map directMap
redistribute bgp 65002 route-map bgpMap
include profile vrf-common-ES

Шаг 6: Подключаем сервисное устройство
Конфигурация VRF (на устройстве)
configure profile vrf-common-External-Dynamic!
!
vrf context Red!
vni 50001!
rd auto!
address-family ipv4 unicast!
route-target import 65002:9999!
route-target both auto!
!
router bgp 65002!
vrf Red!
redistribute hmm route-map FABRIC-RMAP-REDIST-
HOST!
redistribute direct route-map FABRIC-RMAP-REDIST-
SUBNET!
maximum-paths ibgp 2!
redistribute ospf 4 route-map ospfMap!
HOST!
SUBNET!
configure profile vrf-common-ES!
!
vrf context Blue!
vni 50002!
rd auto!
ip route 0.0.0.0/0 192.168.40.2!
!
router bgp 65002!
vrf Blue!
HOST!
SUBNET!
HOST!
SUBNET!

Шаг 7: настройка политик на сервисном устройстве
§ Традиционный подход к управлению сервисными устройствами
§ Свой CLI/GUI для каждой сервисной функции или группы функций
§ Сетевая фабрика DFA не берет на себя функции управления политиками
сервисных устройств
Prime Network
Services Controller
Cisco Security
Manager
Cisco FireSIGHT
Management Center

DFA – основные характеристики
Автоподключение сервисного устройства
DFA
«Разгрузка» обработки с сервисного элемента Нет
настроек
Фабрика DCNM
Гипервизор UCS-D
Сервисное устройство UCS-D
Автоподключение сервисного устройства dot1q, ARP, DHCP, VDP
Производители сервисных устройств Любой (Routing)
Сервисная инкапсуляция Нет
Автодетекция и подключение любых
сервисных устройств (static, OPSF,
BGP)

Интеграция сервисных устройств с ACI

Основной принцип ACI - логическая конфигурация сети, не
привязанная оборудованию
Внешняя сеть
передачи данных
(Tenant VRF)
ACI фабрика
Вставка сервисной цепочки
Web App DB
Неблокируемая фабрика на базе оверлеев
QoS
Filter
QoS
Service
QoS
Filter
APIC
Application Policy
Infrastructure
Controller

ACI: интеграция с сервисами 4 - 7 уровня
Централизация, автоматизация и поддержка существующей модели
• Эластичность вставки сервиса
физического или виртуального
App Tier
• Помощь в административном
A
Web
Web
разделении между уровнями приложения
сервер
Server
и сервиса
• APIC – центральная точка контроля сети
и согласовании политик
• Автоматизация процесса развертывания/
свертывания сервиса посредством
программируемого интерфейса
• Поддержка текущей операционной
модели эксплуатации
• Применение сервиса вне зависимости от
места нахождения приложения
App Tier
B
App
Web
сервер
Server
Политика
перенаправления
Сервисная
послед-ть
“Security 5”
Администратор
приложения
Администратор
сервиса
Серв.
граф
…..
begin Stage 1 Stage N
end
Providers
inst
…
inst
МСЭ
inst
…
inst
Балансировка
……..
Сервисный
профиль
Определение “Security 5”

Шаг 1: Научить ACI говорить на языке сетевых сервисов
§ Установка “device packages”
§ Device packages выпускается вендором сетевого сервиса (F5, Citrix,
etc): кто знает их собственные продукты лучше?
§ Нет ограничений на презентацию уникальных для производителя
сервисного устройства функций
§ Включает в себя:
§ Конфигурацию сервисного устройства
§ Проверку конфигурации на корректность
§ Мониторинг состояния сервисного устройства

Пример: функции, которые презентуются Citrix NetScaler
§ Производитель может презентовать
все функции сервисного устройства
в сторону ACI
§ ACI настроит все функции
устройства при помощи скриптов,
которые являются частью integration
package

Шаг 2: Определить «сервисный граф» который можно
использовать повторно
§ Определение порядка в котором сервисы должны быть добавлены
при помощи графического интерфейса
§ Объект “service graph” может быть использован повторно и
ассоциирован с несколькими приложениями

Параметры, которые могут быть настроены в сервисном
графе
§ Эти параметры определяют как будет настроено сервисное
§ Например: алгоритм балансировки нагрузки, виртуальный IP адрес,
и т.д.

Шаг 3: Сообщить ACI как подключиться
к сервисному устройству

Шаг 4: Ассоциировать “сервисный граф” с приложением
§ Сервисный граф является частью
контракта, который «заключается»
между EPG (End-Point Group)
§ Cервисное устройство
настраивается при помощи
указанных атрибутов при помощи
скриптов, которые являются часть
«device package»

Шаг 5: Подключить серверы к сети
Серверы ассоциируются с End-Point-Group (EPGs) при помощи VLAN,
портовой группы VMware ил AVS на момент FCS. Другие атрибуты – имя
виртуальной машины, DNS или IP адрес/подсеть (roadmap)
Как только сервер попадает в нужный EPG, все необходимое (сетевой QoS,
cетевые ACL, L4-L7 сервисы) настраиваются автоматически
Триггер автоконфигурации политики на сервисном
устройстве = подключение нагрузки, а не сервисного
устройства
Никаких дополнительных действий со стороны администратора
сети и администратора сервисного устройства не требуется

Рендеринг сервисного графа
EPG:
External
1
Func9on
Firewall
Firewall
Выделение
VLAN
3
Настройка
VLAN
4
§ Для каждой функции в графе:
EPG:
Web
Сервисный
граф:
Func9on
SSL
offload
“web-‐applicaIon”
Func9on
Load
Balancer
Func9on
SSL
offload
Func9on
Load
Balancer
2
5
1. APIC выбирает логическое устройство из ранее определенных
2. APIC разрешает параметры конфигурации и готовит конфигурационный словарь
3. APIC выделяет VLAN для каждого соединения, ассоциированного с функцией
4. APIC настраивает сеть - VLAN, EPG и соответствующие фильтры
5. APIC запускает скрипт и настраивает сервисное устройство

ACI – основные характеристики
OpFlex
ACI
настроек
Фабрика APIC
Гипервизор APIC
Сервисное устройство APIC
Автоподключение сервисного устройства APIC
Производители сервисных устройств Любой (Device pkg.)
Фабрика управляет сервисным устройством APIC
сервисного устройства Opflex (roadmap)
Вид цепочки Ветвящийся граф
Динамический выбор сервисного пути Roadmap
Сервисная инкапсуляция Roadmap
Scale-out модель для сервисных устройств Roadmap
OpFlex – открытый стандарт,
регламентирующий подключение к
фабрике любых устройств, в т.ч.
сервисных

ACI – основные характеристики
Вид сервисной цепочки
ACI
настроек
Фабрика APIC
Гипервизор APIC
Сервисное устройство APIC
Автоподключение сервисного устройства APIC
Производители сервисных устройств Любой (Device pkg.)
Фабрика управляет сервисным устройством APIC
сервисного устройства Opflex (roadmap)
(roadmap)
Динамический выбор сервисного пути Roadmap
Сервисная инкапсуляция Roadmap
Scale-out модель для сервисных устройств Roadmap
Гибкость при выборе топологий =
большое количество сценариев
использования

Архитектура Network Service Header (NSH)
Перспективная архитектура для следующих поколений существующих
фабрик (см. Legal Disclamer)

Основные понятия NSH
§ NSH-домен
§ cовокупность сетевых и сервисных устройств, поддерживающих
архитектуру NSH
§ не определяет протоколы плоскости управления
§ NSH Classifier или Service Classifier
§ классификация пакетов на границе домена
§ добавление NSH-заголовка к транспортной инкапсуляции (GRE, VXLAN…)
§ Network Forwarder
§ устройство поддерживающее передачу фреймов с NSH-заголовками
— понимает, но не разбирает NSH-инкапсуляцию
§ например, Spine устройство фабрики

Основные понятия NSH
§ Service Function Forwarder (SFF)
§ подключение сервисных устройств,
поддерживающих NSH
§ например, Leaf устройство фабрики
§ SFC Proxy
§ подключение сервисных устройств,
НЕ поддерживающих NSH
§ функция на Leaf устройстве

Фабрика с поддержкой NSH
NSH-пакет
1
2
3
NSH-пакет
Пакет c
инкапусляцией
фабрики
Исходный пакет Исходный пакет
4
5
6
7
8
Исходный пакет
9
§ 1-2 native
§ 2-3 TRF+NSH
§ 3-5 native
§ 5-6 TRF+NSH
§ 6-8 TRO+NSH
§ 8-9 TRF
§ 9-10 native
10
TRF – транспортная инкапсуляция сетевой фабрики TRO – транспортная инкапсуляция за пределами фабрики

NSH – плоскость управления

NSH - инкапсуляция
Фиксированный
заголовок

NSH – основные характеристики
Сервисная инкапсуляция
NSH
настроек
Фабрика
Определяется
фабрикой
Гипервизор
Сервисное устройство
Производители сервисных устройств
Фабрика управляет сервисным устройством
Динамический выбор сервисного пути Да
Сервисная инкапсуляция Да
Scale-out модель для сервисных устройств Да
Поддержка сервисных путей в
инкапсуляции

Динамический выбор сервисного пути
NSH
настроек
Фабрика
фабрикой
Сервисное устройств переписывает
NSH-заголовок – изменяет SFP-A на
SFP-B

Scale-out модель для сервисных устройств
NSH
настроек
Фабрика
фабрикой
Облачный подход - эластичный
сервис по запросу

Заключение

Сравнение методов
vPath DFA ACI NSH
«Разгрузка» обработки с сервисного элемента Да Нет Нет Нет
настроек
Фабрика UCS-D DCNM APIC
фабрикой
Гипервизор VACS UCS-D APIC
Сервисное устройство UCS-D, PNSC, VACS UCS-D APIC
Автоподключение сервисного устройства Нет dot1q, ARP, DHCP, VDP APIC
Производители сервисных устройств Cisco, Citrix, Imperva Любой (Routing) Любой (Device pkg.)
Фабрика управляет сервисным устройством Нет Нет APIC
сервисного устройства Нет Нет Opflex (roadmap)
Вид цепочки Последовательно Последовательно Ветвящийся граф
(roadmap) Ветвящийся граф
Динамический выбор сервисного пути Нет Нет Roadmap Да
Сервисная инкапсуляция vPath Нет Roadmap Да
Поддержка HA сервисных устройств Да Да Да Да
Scale-out модель для сервисных устройств Нет Нет Roadmap Да

Ждем ваших сообщений с хештегом
#CiscoConnectRu
Спасибо
Пожалуйста, заполните анкеты.
Ваше мнение очень важно для нас.
Contacts:
Name Хаванкин Максим
Phone +74999295710
E-mail mkhavank@cisco.com
CiscoRu Cisco CiscoRussia

Эволюция технологий для организации сервисных цепочек в ЦОД

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Эволюция технологий для организации сервисных цепочек в ЦОД

Similar to Эволюция технологий для организации сервисных цепочек в ЦОД (20)

More from Cisco Russia

More from Cisco Russia (20)

Эволюция технологий для организации сервисных цепочек в ЦОД