Эволюция технологий для организации сервисных...

Хаванкин Максим cистемный архитектор [email protected]

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

11/20/14 © 2014 Cisco and/or its affiliates. All rights reserved.

Legal Disclaimer

Некоторые сведения, приведенные в данной Презентации, могут представлять ссылки на технологии, которые будут разработаны в будущем, функциональные возможности, которые будут реализованы в будущем, ценовую политику для технологических решений и другую подробную информацию ("Подробные сведения"). Все Подробные сведения приводятся исключительно в информационных целях и могут быть изменены без уведомления, включая возможность прекращения разработки (если это применимо), но не ограничиваясь ей. Cisco Systems не берет на себя никаких обязательств по окончательной реализации Подробных Сведений и не будет нести никакую ответственность за их реализацию. Отсутствие такой реализации не является основанием для возврата ранее приобретенного оборудования или услуг Cisco Systems. 11/20/14 © 2014 Cisco and/or its affiliates. All rights reserved.

Содержание

§  Введение

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

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

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

§  Архитектура Network Service Header

§  Заключение


Сложности при интеграции сервисов в существующие ЦОД

4

Вставка сервиса в традиционных сетях

SNAT

Настройка сетевых параметров МСЭ

Настройка сети для подключения МСЭ

Настройка правил на МСЭ

Перенаправление трафика на балансировщик

Настройка сетевых параметров балансировщика

Настройка балансировщика Серверы

Вставка сервиса занимает дни Настройка сети занимает время и является возможным источником ошибок Сложности в отслеживании изменений

VLAN 10 10.0.10.0/28

VLAN 11 10.0.11.0/28

PBR

VLAN 13 10.0.13.0/24

VLAN 12 10.0.12.0/24

Решает ли проблему сложности тотальная виртуализация?

5

Вставка сервиса в традиционных виртуализированных сетях

SNAT

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

VXLAN 12 10.0.12.0/24

Virtual router

Virtual FW

Virtual ADC Virtual router

Virtual switch

Что делать с распределенными сервисами?

DC-1

Subnet A

DC-2

Subnet A

VIP VLAN

Front-‐end VLAN

Inside VLAN

Outside VLAN

Back-‐end VLAN

L3 ядро

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

…

Гипервизор Гипервизор Гипервизор

Устройство Nexus 1100

VSM-A1 VSM-A6

VSM-B1 VSM-B6

Виртуальная машина

Управление

VSM-1 VSM-2

VEM-1 VEM-2 VEM-N

L2 MO D E

L3 M O D E

VSM-1 VSM-2 VEM-1 VEM-2

VEM-N

Модульный коммутатор

Supervisor-1 Supervisor-2 Linecard-1 Linecard-2

Linecard-N … B

ack

plan

e

VSM: Virtual Supervisor Module VEM: Virtual Ethernet Module

vPath – перенаправление 1-го пакета каждой новой сессии на сервисную цепочку

Nexus 1000V Distributed Virtual Switch

VM VM VM

VM VM

VM

VM VM VM

VM

VM

VM VM VM

VM VM VM VM

VM

vPath

Первый пакет в сессии

Сервисное устройство

1 Проверка пакета согласно политике

2

3

4

Результат политики в кеше

vPath – обработка последующих пакетов этого же потока

Nexus 1000V Distributed Virtual Switch

VM VM VM

VM VM

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

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,

vservice node VSG-1 type vsg ip address 10.0.21.254 adjacency l2 vlan 21 fail-mode close

Шаг 3: создаем сервисную цепочку


vservice path WEB-CHAIN node VSG-1 profile WEB_SP order 1 node ASA-1 profile TEST-EDGE-SP order 3

switch# show vservice brief <часть вывода опущена> -------------------------------------------------------------------------------- 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

switch# show vservice brief -------------------------------------------------------------------------------- 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

«Разгрузка» обработки с сервисного элемента Да

Автоматизация настроек

Фабрика UCS-D

Гипервизор VACS

Сервисное устройство UCS-D, PNSC, VACS

Автоподключение сервисного устройства Нет

Производители сервисных устройств Cisco, Citrix, Imperva

Фабрика управляет сервисным устройством Нет Полностью автоматическая конфигурация

сервисного устройства Нет

Вид цепочки Последовательно

Динамический выбор сервисного пути Нет

Сервисная инкапсуляция vPath

Поддержка HA сервисных устройств Да

Scale-out модель для сервисных устройств Нет

vPath – основные характеристики


«Разгрузка» обработки с сервисного элемента

vPath

















Автоматизация при помощи Virtual Application Container Services (VACS)

Развертывание контейнера на базе Nexus 1000V и vPath в 1-клик

vPath

















Собственная сервисная инкапсуляция

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

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


Управление фабрикой

Оптимизация передачи данных

Виртуальные фабрики Автоматизация Управление фабрикой

Автоматизация Виртуальные фабрики Оптимизация передачи данных

24

Архитектура Dynamic Fabric Automation Основные компоненты

Простой модульный набор функций упрощающий развертывание

N1KV/OVS WAN/Core Services

Spine - агрегация Leaf - доступ Border Leaf – граница Services Leaf - сервис Virtual Leaf - виртуальный

N1KV/OVS

Виртуальные машины Физические сервера FEX-ы, UCS FI, СХД, блейды Коммутаторы 3-х производителей Сервисные вирт. машины

МСЭ Балансировщики Устройства 3х производителей

Маршрутизаторы Коммутаторы Устройства 3х производителей

Замечание: роли на уровне доступа (leaf) - логические. Один и тот же коммутатор доступа (leaf) может быть одновременно обычным коммутатором доступа и сервисным и пограничным.

25

Архитектура Dynamic Fabric Automation Подключение сервисных устройств

N1KV/OVS

Точки подключения сервисных устройств и виртуальных машин

Шаг 1: подготовка сетевой фабрики

§  Развертывание DFA фабрики при помощи POAP-шаблонов §  Подключение продуктивной нагрузки

26

Leaf

Spine

Leaf Leaf

Spine

Core/WAN

BL

Клиенты

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

Leaf

Spine

Leaf Leaf

Spine

www1 - 10.10.10.11

Leaf

Spine

Leaf Leaf

Spine

Core/WAN BL

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 §  Сервисный узел = маршрутизация между VRF

Дополнительный 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

Spine

Leaf Leaf

Spine

www1 - 10.10.10.11

Leaf

Spine

Leaf Leaf

Spine

Core/WAN BL

VRF: INSIDE

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! address-family ipv6 unicast! route-target import 65002:9999! route-target both auto! ! router bgp 65002! vrf Red! address-family ipv4 unicast! 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! address-family ipv6 unicast! redistribute hmm route-map FABRIC-RMAP-REDIST-HOST! redistribute direct route-map FABRIC-RMAP-REDIST-SUBNET! maximum-paths ibgp 2!

configure profile vrf-common-ES!! vrf context Blue! vni 50002! rd auto! ip route 0.0.0.0/0 192.168.40.2! address-family ipv4 unicast! route-target import 65002:9999! route-target both auto! address-family ipv6 unicast! route-target import 65002:9999! route-target both auto!! router bgp 65002! vrf Blue! address-family ipv4 unicast! redistribute hmm route-map FABRIC-RMAP-REDIST-HOST! redistribute direct route-map FABRIC-RMAP-REDIST-SUBNET! maximum-paths ibgp 2! address-family ipv6 unicast! redistribute hmm route-map FABRIC-RMAP-REDIST-HOST! redistribute direct route-map FABRIC-RMAP-REDIST-SUBNET! maximum-paths ibgp 2!

Шаг 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 - логическая конфигурация сети, не привязанная оборудованию


ACI фабрика

Неблокируемая фабрика на базе оверлеев

App DB Web

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

(Tenant VRF)

QoS

Filter

QoS

Service

QoS

Filter

Application Policy Infrastructure

Controller

APIC

Вставка сервисной цепочки

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

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

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

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

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

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

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

Web Server

App Tier A

Web сервер

Web Server

App Tier B

App сервер

Сервисная послед-ть “Security 5”

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

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

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

Серв.

граф

begin end Stage 1 …..

Stage N

Pro

vide

rs inst

inst

…

МСЭ

inst

inst

…

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

……..

Сервисный

профиль

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

§  Установка “device packages” §  Device packages выпускается вендором сетевого сервиса (F5, Citrix,

etc): кто знает их собственные продукты лучше?

§  Нет ограничений на презентацию уникальных для производителя сервисного устройства функций

§  Включает в себя: §  Конфигурацию сервисного устройства §  Проверку конфигурации на корректность §  Мониторинг состояния сервисного устройства

Шаг 1: Научить ACI говорить на языке сетевых сервисов

§  Производитель может презентовать все функции сервисного устройства в сторону ACI

§  ACI настроит все функции устройства при помощи скриптов, которые являются частью integration package

Пример: функции, которые презентуются Citrix NetScaler

§  Определение порядка в котором сервисы должны быть добавлены при помощи графического интерфейса

§  Объект “service graph” может быть использован повторно и ассоциирован с несколькими приложениями

Шаг 2: Определить «сервисный граф» который можно использовать повторно

§  Эти параметры определяют как будет настроено сервисное устройство

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

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

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

§  Сервисный граф является частью контракта, который «заключается» между EPG (End-Point Group)

§  Cервисное устройство настраивается при помощи указанных атрибутов при помощи скриптов, которые являются часть «device package»

Шаг 4: Ассоциировать “сервисный граф” с приложением

Шаг 5: Подключить серверы к сети

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

Триггер автоконфигурации политики на сервисном устройстве = подключение нагрузки, а не сервисного устройства Никаких дополнительных действий со стороны администратора сети и администратора сервисного устройства не требуется

Рендеринг сервисного графа

§  Для каждой функции в графе: 1.  APIC выбирает логическое устройство из ранее определенных 2.  APIC разрешает параметры конфигурации и готовит конфигурационный словарь 3.  APIC выделяет VLAN для каждого соединения, ассоциированного с функцией 4.  APIC настраивает сеть - VLAN, EPG и соответствующие фильтры 5.  APIC запускает скрипт и настраивает сервисное устройство

EPG: Web EPG: External Func9on Firewall

Func9on SSL offload

Func9on Load Balancer

Сервисный граф: “web-‐applicaIon”

Firewall Func9on SSL offload

Func9on Load Balancer

Выделение VLAN

1 2

3

Настройка VLAN 4

5

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


1

2

3

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-пакет

Пакет c инкапусляцией фабрики

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 Да

CiscoRu Cisco CiscoRussia

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

Пожалуйста, заполните анкеты. Ваше мнение очень важно для нас.

Спасибо Contacts: Name Хаванкин Максим Phone +74999295710 E-mail [email protected]


Эволюция технологий для организации сервисных...

Technology

Transcript of Эволюция технологий для организации сервисных...