Download - Интеграция сервисных устройств в сеть ЦОД: интеграция сервисов 4-7 уровня

Интеграция сервисов 4-7 уровня Хаванкин Максим cистемный архитектор, CCIE [email protected]

18 июня 2015

Cisco Confidential 2 © 2013-2014 Cisco and/or its affiliates. All rights reserved.

§  Интеграция сервисных устройств в сеть ЦОД §  Шаги по встраиванию сервисного устройства в ACI фабрику

§  Примеры дизайнов с сервисными графами

§  Встраивание Cisco ASA и Cisco NGIPS

§  Использование ACI для замены “сервисного шасси” §  Партнерская экосистема

Содержание


Сетевые сервисы L4-L7 “выделенные виртуальные и физические устройств, которые обеспечивают дополнительную функциональность поверх традиционной сети коммутации и маршрутизации”


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

5

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

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


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

6

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

SNAT

Configure Network to insert Firewall

Configure firewall rules

Virtual servers

Упростится ли решаемая задача, если для вставки виртуализированного сервиса применяются те же сетевые концепции, что и для физической сети?

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


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”


App DB Web

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

(Tenant VRF)

QoS

Filter

QoS

Service

QoS

Filter Filter

Service Service

ACI фабрика

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

Infrastructure Controller

APIC

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

Основной принцип ACI - логическая конфигурация сети, не привязанная оборудованию

Управление внешним устройством


Автоматизация вставки сервиса при помощи «device package» Open Device

Package

Policy Engine

APIC реализует расширяемую модель политик при помощи Device Package

Configuration Model

Device Interface: REST/CLI

APIC Script Interface

Call Back Scripts

Event Engine

APIC– Policy Manager

Configuration Model (XML File)

Call Back Script

Администратор загружает файл, содержащий Device Package в APIC

Device Package содержит XML модель устройства, которое находится под управлением

Device scripts транслирует вызовы APIC API в специфичные для устройства CLI команды или API вызовы

APIC


§  Файл с 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: (список расширяется)

L4-L7 устройство может говорить на языке ACI! OpFlex: an open declarative protocol


Tenant: контейнер Tenant_001, в который добавляется сервисное устройство

Шаг 2: Service Graph Template: конструкция, определяющая путь по котором трафик проходит через сервисное устройство, входящий и исходящий интерфейсы

Шаг 3: Device cluster: логическая конструкция c идентификатором Firewall, представляющая кластер сервисных устройств или отказоустойчивую пару устройств

Шаги 1-4 на одном слайде Tenant_001

Политики безопасности и/или сетевые настройки устройства

Service Function Profile

Device cluster Firewall

Concrete device ASA

GigabitEhternet 0/1

Physical interface

GigabitEthernet 0/0

Physical interface

external

Logical interface

internal

Logical interface

Service Graph Template

Шаг 3: Logical interface: конструкция представляющая классы логических интерфейсов на кластере сервисных устройств

Шаг 3: Concrete device: логическая конструкция, с идентификатором ASA, определяющая настройку одного из устройств кластера или отказоустойчивой пары устройств

Шаг 3: Physical interface: конструкция, определяющая характеристики физического порта на одном из устройств кластера или отказоустойчивой пары устройств

Шаг 2: Service Function Profile: определяет детальную конфигурацию политик безопасности, балансировки нагрузки и т.д. на сервисном устройстве.

Контракт EPG Web

EPG App

EPG: группы конечных устройств между которыми трафик передается через сервисную цепочку

Шаг 4: Контракт: содержит ссылку на сервисный граф

zip-файл импортируемый в APIC

Шаг 1: Device package


Шаг 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 запускает скрипт и настраивает сервисное устройство

Func%on Firewall

Func%on SSL offload

Func%on Load Balancer

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

Firewall Func%on SSL offload

Func%on Load Balancer

Выделение VLAN

1

2

3

Настройка VLAN 4

5

EPG Web EPG

App


Коммутаторы Spine

Коммутаторы Leaf

Исходная топология

Port-channel? vPC? Конфигурация L3? Кокой режим встраивания: routed или transparent?


Терминология ACI для настройки сервисного графа

Consumer Side Provider Side Concrete Device

Logical Device consumer EPG Provider EPG

L4-L7 параметры

17




Пример № 1: встраивание в режиме “transparent”

Template 1 (Cdev1) vPC и Transparent mode


Bridge Domain Outside Bridge Domain Inside

Client EPG Server EPG

Service Graph

Contract

Provider Consumer

Provider Side Consumer Side

Внешний маршрутизатор

IP

Шлюз по умолчанию для серверов

Пример № 1: встраивание в режиме “transparent”

ARP Flooding Unknown Unicast Flooding No IP Routing

ARP flooding Uknown unicast flooding No IP Routing

19




Пример № 2: встраивание в режиме “routed”

Template 2 (Cdev2) 2 отдельных Port Channel и Routed mode



Client EPG Server EPG

Service Graph

Contract

Provider Consumer

ARP Flooding Unknown Unicast Flooding No IP Routing

ARP flooding Uknown unicast flooding No IP Routing


Выступает шлюзом по умолчанию для серверов в Server EPG

Пример № 2: встраивание в режиме “routed” Внешнее подключение L2

21



L3Out L3InstP

Server EPG

Service Graph

Contract Provider Consumer

VRF

ARP Flooding Uknown Unicast Flooding No IP Routing Subnet: шлюз по умолчанию для L4-L7

устройства Hardware Proxy


Шлюз по умолчанию для серверов

Пример № 2: встраивание в режиме “routed” Внешнее подключение при помощи L3

22


Интеграция с ACI устройств безопасности Cisco

Подключение к фабрике ACI

Подключение к фабрике ACI

Настройка политик

Мониторинг и уведомления в реальном времени

Настройка политик

Managing Service Producer Security Configurations and Visibility

События и syslog CSM

ASA Device Package

FirePOWER Device Package

Интеграция ASA Интеграция FirePOWER


ASA5585 c SFR в сервисном графе – Etherchannel

Po1.300 Po1.301

Vlan 100 Vlan 200

vPC4 VLAN 300 vPC4

Vlan 301

App1 DB

provider consumer class firepower_class_map sfr fail-close

SFR NGIPS policy ASA

Когда сервисный граф с сервисным устройством ASA активируется в определенном контракте (начинается рендеринг), APIC автоматически настроивает ASA интерфейсы и политики, включая redirection на модуль FirePOWER. Поддерживаются L3 (GoTo) и L2 (GoThrough) режимы. FireSIGHT независимо управляет политиками FirePOWER.

ASA 1.2 Device Package

ASA5585+SFR

APIC

Vlan 100 App2 VM


Cервисный граф для FirePOWER - LAG

s1p1.300 s1p2.301

Vlan 100 Vlan 200

vPC4 Vlan 300 vPC4

Vlan 301

Идентификаторы VLAN ID назначаются автоматически из пула и для EPG и для портов сервисных устройств.

Настройка всех портов согласно логике (L2,L3) производится автоматически.

App DB

consumer provider

FirePOWER использует LAG (port-channel) для подключения к фабрике

для обеспечения отказоустойчивости к

одному коммутатору или паре коммутаторов с функцией vPC.

Physical

APIC использует FirePOWER Device package для

взаимодействия с FireSIGHT Management Center который

управляет NGIPS

APIC


ASAv и FirePOWERv в сервисном графе

vNIC2 vNIC3

Vlan 100 Vlan 200 App DB

provider consumer Устройства ASAv и NGIPSv разворачиваются вручную или при помощи оркестратора. vNIC

интерфейсы, помеченные как consumer и provider задействуются при

активации (рендеринге) сервисного графа.

vNIC2 vNIC3 provider consumer

Vlan 302 Vlan 303 Vlan 300 Vlan 301

APIC полностью управляет конфигурацией ASAv, при этом настройка виртуального FirePOWER устройства выполняется при помощи FireSIGHT.

APIC


СПД

Использование ACI в существующих ЦОД Стандартная сервисная архитектура

vSwitch

Сервисное шасси

vSwitch vSwitch

Сервисное шасси


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

МСЭ 1

L3 OSPF BGP

L2 VLAN 802.1Q

L2

L3

40G ACI

ADC


Backbone

Развертывание ACI в существующем ЦОД Апгрейд «сервисного шасси» на ACI

vSwitch vSwitch vSwitch

APIC Policy Controller

Directory/Proxy Service Nodes

Border Leaves

ACI Enabled L4-7 Virtual and Physical Services (Поддержка существующих и новых/дополнительных сервисов)

Реализация сервисов на базе ACI в любом существующем ЦОД, который использует IP протокол

1.  Установка сервисного блока ACI

2.  Использование существующих L4-7 сервисных узлов ‘или’ использование новых сервисов, которые будут полностью автоматизированы при помощи APIC device package

3.  Протянуть VLAN == EPG из существующей сети в сервисный модуль ACI

4.  Миграция шлюза по умолчанию на сервисный модуль ACI

5.  Управление сервисами через APIC с сохранением текущей схемы коммутации


Партнерская экосистема ACI

СЛЕДИТЕ ЗА АНОНСАМИ!

Спасибо!

Download - Интеграция сервисных устройств в сеть ЦОД: интеграция сервисов 4-7 уровня

Top Related