51
Программируемые и программно- определяемые инфраструктуры ЦОД. Развитие подходов Виктор Пустошилов Системный Инженер [email protected] 20.10.14 © 2014 Cisco and/or its affiliates. All rights reserved.

Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Embed Size (px)

DESCRIPTION

Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Citation preview

Page 1: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Виктор ПустошиловСистемный Инженер[email protected]

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

Page 2: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

План презентации

• Что означает Software-defined Networking (SDN)?• Кому и зачем нужен SDN• Контроллеры SDN и Оркестраторы• Программные Интерфейсы Управления

- OpenFlow- NETCONF/YANG, RESTCONF- OpFlex

• Контроллеры SDN и приложения Cisco- XNC- APIC

Page 3: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов
Page 4: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

“…В архитектуре SDN разделены уровни управления и передачи данных, обеспечена логическая централизация интеллектуальных сетевых механизмов и информации о состоянии сети, а нижележащая сетевая инфраструктура абстрагирована от приложений…”

Источник: www.opennetworking.org

Что означает Software-defined Networking (SDN)?

Page 5: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Контроллер / Сетевая ОС

Управляющая программаМаршрутизация, контроль доступа, и т.д.

Абстракция всей сети

Коммутация данных

OpenFlow

Академический взгляд на SDN

Бизнес Приложения

Page 6: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Original SDN idea:Clean Slate Project(Stanford University)

SDN – Software Defined NetworkingРазвитие архитектуры уровня управления

Распределенный Control Plane

Развитие Архитектуры Уровня Управления

Компоненты Control/Network/Services-plane Компоненты ASIC’s, Data-plane Приложения

Централизованный SDN Гибридный SDN

Традиционный Уровень Управления

Overlay (tunnels)

API-и

Протоколы

Коммутация, управляемаяприложениями

Underlay (physical)

Disconnected Net and Apps

Page 7: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

План презентации

• Что означает Software-defined Networking (SDN)?

• Кому и зачем нужен SDN• Контроллеры SDN и Оркестраторы• Программные Интерфейсы Управления

- OpenFlow- NETCONF/YANG, RESTCONF- OpFlex

• Контроллеры SDN и приложения Cisco- XNC- APIC

Page 8: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Кому и зачем нужен SDN Сервис провайдеры Масштабирование при развертывании

новых/существующих приложенийControl Plane (Segment Routing, TIF)

Стандартные протоколы Control Plane (I2RS/BGP-LS/PCEP)

Разделение Management/Control/Data Быстрое развертывание новых услуг

(снижение времени вывода на рынок) Быстрое внедрение новых технологий

(предоставление уникальных возможностей пользователям)

Корпоративные заказчики Централизованное управление

комплексным функционалом (Policy/ACL/QoS)

Оптимизация инфраструктуры Изменение контекста операций

управления (от синтаксиса к семантике)

Снижение "точек управления”(один контроллер или несколько отдельных устройств)

Потребление из облака

Page 9: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Device

SDN - Централизованное управление Policy/ACL/QoS

Device

DataPlaneM

ana

gem

ent

Pla

ne

Корпоративные заказчики Централизованное управление

комплексным функционалом (Policy/ACL/QoS)

Оптимизация инфраструктуры Изменение контекста операций

управления (от синтаксиса к семантике)

Снижение "точек управления”(один контроллер или несколько отдельных устройств)

Потребление из облака

Meraki

SDN Controller

ACI Policy APIREST/Custom APINetconf/YANG

Meraki Cloud API

Cloud

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

ACLs/QoS

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

SDN Controller

Spine/Leaf

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

ACI

SDN Controller

Custom Protocol

APIC

Open Protocol

OpenDaylight

ControlPlane

Policy

L2/L3 Connecti

vity

ControlPlane

Page 10: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

SDN - Оптимизация инфраструктуры

Корпоративные заказчики Централизованное управление

комплексным функционалом (Policy/ACL/QoS)

Оптимизация инфраструктуры Изменение контекста операций

управления (от синтаксиса к семантике)

Снижение "точек управления”(один контроллер или несколько отдельных устройств)

Потребление из облака

REST/Custom APINetconf/YANG

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

Device

DataPlaneM

ana

gem

ent

Pla

ne

ACLs/QoS

SDN Controller

Open Protocol

OpenDaylightPolicy

L2/L3 Connecti

vity

Выбор Стандартизованной

архитектуры

ControlPlane

Page 11: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Device

SDN - Объектное управление

Корпоративные заказчики Централизованное управление

комплексным функционалом (Policy/ACL/QoS)

Оптимизация инфраструктуры Изменение контекста операций

управления (от синтаксиса к абстрактным объектам)

Снижение "точек управления”(один контроллер или несколько отдельных устройств)

Потребление из облака

Meraki

SDN Controller

ACI Policy APIREST/Custom APINetconf/YANG

Meraki Cloud API

Cloud

Описание желаемого состояния на основе объектной модели

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

Spine/Leaf

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

ACI

SDN Controller

Custom Protocol

APIC

Device

DataPlaneM

ana

gem

ent

Pla

ne

ACLs/QoS

SDN Controller

Open Protocol

OpenDaylightPolicy

L2/L3 Connecti

vity

ControlPlane

ControlPlane

Page 12: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Корпоративные заказчики Централизованное управление

комплексным функционалом (Policy/ACL/QoS)

Оптимизация инфраструктуры Изменение контекста операций

управления (от синтаксиса к семантике)

Снижение "точек управления”(один контроллер или несколько отдельных устройств)

Потребление из облака

ACI Policy API

Spine/Leaf

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

ACI

SDN Controller

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

Spine/Leaf

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

Spine/Leaf

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

APIC

OpFlex

SDN - Снижение "точек управления”

ControlPlane

ControlPlane

ControlPlane

Page 13: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Device

Корпоративные заказчики Централизованное управление

комплексным функционалом (Policy/ACL/QoS)

Оптимизация инфраструктуры Изменение контекста операций

управления (от синтаксиса к семантике)

Снижение "точек управления”(один контроллер или несколько отдельных устройств)

Потребление из облака

Meraki

SDN Controller

Устаревшие платформы

Meraki Cloud API

Cloud

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

Infrastructure

PolicyDataPlane

L2/L3 Connecti

vityM

ana

gem

ent

Pla

ne

ControlPlane

Infrastructure

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

ControlPlane

SDN - Потребление из облака

Page 14: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

План презентации

• Что означает Software-defined Networking (SDN)?• Кому и зачем нужен SDN

• Контроллеры SDN и Оркестраторы• Программные Интерфейсы Управления

- OpenFlow- NETCONF/YANG, RESTCONF- OpFlex

• Контроллеры SDN и приложения Cisco- XNC- APIC

Page 15: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Контроллеры SDN и Оркестраторы

- Контроллеры SDN, системы централизованного управления, системы оркестрации….

- Одно и тоже или взаимодополняющие компоненты?- Давайте разберемся.

Page 16: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Различие между оркестраторами и контроллерами

Приложение(например

IaaS)

Платформа Оркестрации

Приложение контроллера

Платформа контроллера

Например Data Broker

Например Cisco XNC

Например UCS Director

Device

PolicyDataPlane

L2/L3 Connecti

vity

ControlPlane

Device

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

ControlPlane

• Управление через API

• Развертываниеуслуги

• Логика оркестрации• Приложение

управления• Взаимодействие с

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

• Определение услуги• Политика услуги• Взаимосвязи услуги• Жизненный цикл

услуги• Поддержка услуги

Оркестраторы – платформы автоматизации, используются приложениями для конфигурирования инфраструктуры (через Management Plane опосредованно определяют/контролируют Control Plane и Data Plane), и выполняют конкретные Сервисные Запросы Например UCS Director

Контроллеры – платформы для приложений, которые программируют Control plane устройств или получают информацию о состоянии от Control Plane устройств Например XNC (платформа) – Data

Broker (приложение)

Ma

nage

men

tPl

ane

Page 17: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Различие между оркестраторами и контроллерамиОркестраторы – платформы автоматизации, которые используются приложениями для конфигурирования инфраструктуры (через Management Plane опосредованно определяют/контролируют Control Plane и Data Plane), и выполняют конкретные Сервисные Запросы Например UCS Director

Контроллеры – платформы (для приложений), которые программируют Control plane устройств или получают информацию о состоянии от Control Plane устройств Например XNC (платформа) – Data

Broker (приложение)

Приложение(например

IaaS)

Платформа Оркестрации

Приложение контроллера

Платформа контроллера

Например Data Broker

Например Cisco XNC

Например UCS Director

Device

PolicyDataPlane

L2/L3 Connecti

vityM

ana

gem

ent

Pla

ne

ControlPlane

Device

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

ControlPlane

• Интерфейсы интеграции приложений

• Сервисные функции (DB)

• Message bus• Протоколы Control

Plane• Протоколы South

Bound к инфраст-ре

• Интерфейс приложения

• Логика управления Control Plane

• Взаимосвязиприложения

Page 18: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Различие между приложением и платформой контроллера

Контроллер и инфраструктура

разделены

Вертикально интегрированная

платформа

• Приложение может быть реализовано как интегрированное (например APIC)или на основе открытой платформы контроллера (например Data Broker).

• Множество сетевых приложений управления связано с необходимостью решать различные задачи управления сетевой инфраструктурой.

• Выбор платформы контроллера для приложения определяется возможностями платформы.

Сетевое приложение контроллера

Сетевое приложение контроллера

Платформа Контроллер

а

Интегрированное приложение управления

– например APIC

Приложение для платформы контроллера,

например Data Broker

Например Cisco XNC

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

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

Page 19: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Способы взаимодействия контроллеров и оркестраторов

• Оркестраторы настраивают устройства через Management Plane:- CLI- RPC (Netconf)- Models (Netconf/YANG)

• Контроллеры программируют Control plane устройств:- Forwarding tables- Policy tables- Через протоколы SDN

(OpenFlow)/протоколы Control Plane (I2RS, BGP-LS, PCEP)

Оркестратор может опрашивать контроллеры в процессе принятия решения оркестрации

Приложение контроллераПлатформаконтроллера

SDN Controller

Device

PolicyDataPlane

L2/L3 Connecti

vity

ControlPlane

ОркестраторПриложение,

использующее оркестратор

Платформаоркестрации

ОркестраторПриложение,

использующее оркестратор

Платформаоркестрации

Device

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

ControlPlane

Device

PolicyDataPlane

L2/L3 Connecti

vity

Ma

nage

men

tPl

ane

ControlPlane

ОркестраторПриложение,

использующее оркестратор

Платформаоркестрации

Приложение контроллераПлатформаконтроллера

SDN Controller

Ma

nage

men

tPl

ane

Page 20: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Модели взаимодействия контроллеров/ оркестраторов/ сети

EdgePolicy

Распределенная модель - например BGP, IGP• Система оркестрации определяет

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

Система Оркестрации/Пр

иложение

Control Plane

DataPlane

L2/L3 Connectivity

Ma

nage

men

t Pl

ane

NetConf/YANG

CorePolicy

Control Plane

DataPlane

L2/L3 Connectivity

Ma

nage

men

t Pl

ane

CorePolicy

Control Plane

DataPlane

L2/L3 Connectivity

Ma

nage

men

t Pl

ane

i-BGP

i-BGP

Policy

Control Plane

L2/L3 Connectivity

Ma

nage

men

t Pl

ane

BGP RR

i-BGP

Коммутатор

Push – например XNC/Data Broker• Сетевое состояние проактивно

спускается на сетевые устройства при создании новых правил в приложении

Система Оркестрации/П

риложение

Policy

Control Plane

L2/L3 Connectivity

Ma

nage

men

t Pl

ane

RESTCONF

DataPlaneM

ana

gem

ent

Pla

ne

OpenFlow

XNCcontroller

Control Plane

Pull – например ACI, LISP• Сетевое состояние

передается на устройства доступа по запросу (реактивно)

Mapping server

APICКонтроллер

Policy

L2/L3 Connectivity

Система Оркестрации/П

риложение

Коммутатор

DataPlaneM

ana

gem

ent

Pla

ne

Control Plane

OpFlex

Page 21: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

План презентации

• Что означает Software-defined Networking (SDN)?• Кому и зачем нужен SDN• Контроллеры SDN и Оркестраторы

• Программные Интерфейсы Управления- NETCONF/YANG, RESTCONF- OpenFlow- OpFlex

• Контроллеры SDN и приложения Cisco- XNC- APIC

Page 22: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Программные Интерфейсы по категориям

НастройкаУправление

Программные расширения

DevOpsИнтеграция

NETCONFYANG

BGP-LSPCEP

OpFlexCiscoPython API

BGP Flowspec

Page 23: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Программные Интерфейсы Управления

Приложения, Системы Управления, Контроллеры, ...

Device

Forwarding

Control

Network Services

Orchestration

Management

OpenFlow

OpenFlow

Operating Systems – IOS / NX-OS / IOS-XRAPI (OnePK) and Data Models (YANG)

OpenStack PuppetOnePKC/Java

Puppet

Neutron

Protocols

“Protocols”BGP, PCEP,...

Python NETCONF REST ACI Fabric

OpFlex

onePK Plug-Ins

RESTful

YANG JSONXML

Page 24: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

NETCONF и RESTCONF RPC (RemoteProcedureCall) операции с конфигурационными и оперативными данными в формате XML

NETCONF RESTCONF Процедура<get> HTTP GET Get operational data (like “show” commands)

<get-config> HTTP GET Get configuration (like “show run”)

<edit-config> HTTP PATCH Edit configuration (like “conf t” and then “commit”)

<edit-config> operation=“delete” HTTP DELETE Delete configuration (eg. like “no int loo1”)

<edit-config> operation=“create” HTTP POST Create configuration (eg. like “int tunnel-te1 …”)

<edit-config> operation=“replace” HTTP PUT Replace configuration

• NETCONF (RFC6241) – для сетевого сообщества- работает поверх SSH или TLS – пример сессии NETCONF: ssh –s [email protected] -p 830 netconf- операторы типа <get>, <get-config>, <edit-config>, <commit>, <copy-config>, <lock> ...

• RESTCONF (draft-bierman-netconf-restconf) – для сообщества разработчиков- использует стандартные операции HTTP – GET, PUT, POST, DELETE…- основан на REST (Representational State Transfer) – программная архитектура веб приложений

Page 25: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

YANG

YANG SNMP

Framework(definition language)

YANG SMI

Content (information model)

YANG module MIB

Payload(encoded data)

XML (ASCII) ASN.1 BER (binary)

Protocol(remote access)

NETCONF,RESTCONF

SNMP

YANG (RFC6020) язык описания модели данных (data modelling language)• “Yet Another Net Generation“ – разработан после фиаско NG-SNMP • Разрабатывался как язык описания модели данных для протокола NETCONF • NETCONF/YANG‘s должны обеспечить мультивендорное R/W управление элементами и услугами,

став таким образом открытым стандартом программного управления устройствами

YANG vs. SNMP

Page 26: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Интерфейс YANG (пример)ietf-interfaces – the structure (RFC7223)+--rw interfaces

| +--rw interface* [name]| +--rw name string| +--rw description? string| +--rw type identityref| +--rw enabled? boolean| +--rw link-up-down-trap-enable? enumeration+--ro interfaces-state

+--ro interface* [name]+--ro name string+--ro type identityref+--ro admin-status enumeration+--ro oper-status enumeration+--ro last-change? yang:date-and-time+--ro if-index int32+--ro phys-address? yang:phys-address+--ro higher-layer-if* interface-state-ref+--ro lower-layer-if* interface-state-ref+--ro speed? yang:gauge64+--ro statistics

+--ro discontinuity-time yang:date-and-time

+--ro in-octets? yang:counter64+--ro in-unicast-pkts? yang:counter64+--ro in-broadcast-pkts? yang:counter64+--ro in-multicast-pkts? yang:counter64+--ro in-discards? yang:counter32

...

ietf-interfaces.yang – YANG module examplecontainer interfaces {

description "Interface configuration parameters.";

list interface { key "name“; leaf name { type string; }leaf description { type string; }leaf type {

type identityref {base interface-type;

}mandatory true;

}leaf enabled {

type boolean;default "true";

}leaf link-up-down-trap-enable {

if-feature if-mib;type enumeration {

enum enabled { value 1; }enum disabled { value 2; }

}}

}}container interfaces-state {

config false;description "Data nodes for the operational state of interfaces.";

list interface { key "name";...

get reply – XML-encoded YANG data example<?xml version="1.0" encoding="UTF-8"?><rpc-reply message-id=“9“

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0“><data>

<interfacesxmlns="urn:ietf:params:xml:ns:yang:ietf-

interfaces“><interface>

<name>eth0</name><type>ianaift:ethernetCsmacd</type><enabled>false</enabled>

</interface></interfaces>

<interfaces-statexmlns="urn:ietf:params:xml:ns:yang:ietf-

interfaces“><interface>

Page 27: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Приложения, Системы Управления, Контроллеры, ...

Device

Forwarding

Control

Network Services

Orchestration

Management

OpenFlow

OpenFlow

Operating Systems – IOS / NX-OS / IOS-XRAPI (OnePK) and Data Models (YANG)

OpenStack PuppetOnePKC/Java

Puppet

Neutron

Protocols

“Protocols”BGP, PCEP,...

Python NETCONF REST ACI Fabric

OpFlex

onePK Plug-Ins

RESTful

YANG JSON/XML

Программные Интерфейсы Управления

Page 28: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

“…открытый стандарт, определяющий взаимодействие между разделёнными уровнями управления (контроллер) и передачи данных (агент)…”

Источник: www.openflow.org

Openflow

Что такое OpenFlow?

Page 29: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Ком

мут

атор

FLOWTABLE 1

SWITCH FORWARDING ENGINE

Контроллер OPENFLOW (например OpenDaylight / Cisco XNC)

CPUGROUP

TABLE (1.1)

FLOWTABLE 2

FLOWTABLE n

FLOW METERTABLE (1.3)

OPENFLOW HYBRID SWITCH

(1.1)

Data Data

STD Ethernet Processing Pipeline

OFилиSTD

OUTPUT

pipeline (1.1)

- Symmetric Sync Messages (Hello, Echo, Vendor…)- Async Messages (Port-Status, Flow-Removed, Error…)- Forwarding Control & Stats Collection

API’s

Приложения

OF 1.1+: Требуется специальный ASIС

Openflow

Page 30: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

FLOW TABLE

HEADER FIELDS COUNTERS ACTIONS

… …

… …

Счетчики: • per Table, Flow, Queue, Port• Bytes, Packets, Errors, Flow duration…• Counter Disable (1.3)

IngressPort

SourceMAC

DestMAC

EtherType

VLANID

VLANPriority

IPSRC

IPDEST

IPProtocol

IPTOS

TCP/UDPSRC

ICMP Type

TCP/UDPDEST

ICMP Code

MPLSLabel

MPLSTrafficClass

MPLS (1.1,BoS 1.3) IPv4 (1.0), IPv6 (1.2)L1/L2 (1.0) L4 ports (1.0)

Маскируемые поля (14-tuple):

Действия (1.0)

1 Forward out all ports except input port

2 Redirect to Openflow Controller

3 Forward to local Forwarding Stack (CPU)

4 Perform action in flow table

5 Forward to input port

6 Forward to destination port

7 Drop Packet

Optional Actions – Modify-Field, Enqueue, Forward Normally

Openflow OF 1.1+: Требуется специальный ASIC

Page 31: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Программные Интерфейсы Управления

Приложения, Системы Управления, Контроллеры, ...

Device

Forwarding

Control

Network Services

Orchestration

Management

OpenFlow

OpenFlow

Operating Systems – IOS / NX-OS / IOS-XRAPI (OnePK) and Data Models (YANG)

OpenStack PuppetOnePKC/Java

Puppet

Neutron

Protocols

“Protocols”BGP, PCEP,...

Python NETCONF REST ACI Fabric

OpFlex

onePK Plug-Ins

RESTful

YANG JSON/XML

Page 32: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Решаемая проблема: микроуправление инфраструктурой

• На сегодня сети – это среды, требующие детального конфигурирования

• Требования пользователей, инфраструктуры и политик сопровождения зачастую противоречат друг другу

• Это порождает большие проблемы с масштабируемостью, повышает отказы и снижает совместимость

• Доступные на сегодня протоколы SDN не решают проблему микроуправления

Page 33: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Пример: Сконфигурировать сеть на сервере

Элем

енты

Con

trol

Sys

tem

Адм

ин

“Развернуть приложение

X”

“Trunk vlan”

“Настроить ACL”

“ Добавить маршрут…”

Система управления/пользовате

ль передает конфигурацию на

устройства. Императивный контрольЗапрос пользователя разделяется на множество конечных команд, связанный с настройкой конкретной инфраструктуры

Page 34: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Императивный контроль – в чем недостатки

Недостатки систем с императивным контролем (OpenFlow + OVSDB):- Централизованное управление SDN плохо масштабируется – все сетевые устройства должны

зарегистрироваться на контроллере.

- Большой домен отказа.

- Система управления должна знать возможности всех устройств – точное описание управляемых объектов с использованием низкоуровневых сетевых функций.

- Задействуется небольшой набор функционала для достижения приемлемой масштабируемости в решениях SDN первого поколения.

Modular 1

Modular 2Vendor 1

Vendor 2

Hypervisor vSwitchesВ случае императивного подхода все эти устройства должны выглядеть одинаково

Ограничение функционала сдерживает развитие

Page 35: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Решение: Декларативный контроль

Элем

енты

Cont

rol S

yste

mАд

мин

Отк

азы

“Мои Веб серверы должны

взаимодействовать с моими серверами

приложений”

“Разрешить Хосту A взаимодействовать с

Хостом B”

“Исполняю”

Сделаны соответствующие

изменения

- Администратор создает политики на основе абстрактных элементов

- Создаваемые абстрактные политикинапрямую передаются на инфраструктуру

- Инфраструктура самостоятельно интерпретирует политики в соответствии со своими возможностями и производит изменение конфигурации

Page 36: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

SDN или нет?

Императивный контроль

Элем

енты

Cont

rol S

yste

mАд

мин

Декларативный контроль

Policy Manager

Control Plane + Data Plane

APIC SDN Controller

Policy Manager + Control Plane

Data Plane

OpenFlow + OVSDB OpFlex

OpFlex - новый расширяемый протокол описания политик, разработанный для декларативного управления любой инфраструктурой ЦОД.

Page 37: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

OpFlex - как это работает

Конечное устройство интерпретирует политику и сопоставляет со своими аппаратными возможностями

POLICYAPICAPIC управляет логической моделью желаемого состояния

HARDWARE

PORTS, VLANS,

INTERFACES

SUBSET OFPOLICY

4

Интерпретацияполитики

Обновление политики

Запрос политики

32

1

Интерпретация может в том числе использовать программные интерфейсы включая OVSDB, OpenFlow или собственный API устройства

Page 38: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

План презентации

• Что означает Software-defined Networking (SDN)?• Кому и зачем нужен SDN• Контроллеры SDN и Оркестраторы• Программные Интерфейсы Управления

- NETCONF/YANG, RESTCONF- OpenFlow- OpFlex

• Контроллеры SDN и приложения Cisco- XNC- APIC

Page 39: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Cisco eXtensible Network Controller (XNC)

Page 40: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Что такое OpenDaylight ?OpenDaylight – это проект с открытым исходным кодом, сформированный лидирующими компаниями под эгидой Linux Foundation. Целью проекта является расширение использования и развитие технологий SDN (Software Defined Networking) через создание общей, поддерживаемой всеми производителями, архитектуры.

Platinum Gold Silver

Page 41: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

OpenDaylight Контроллер: базовые функции

Базовая инфраструктура

GUIOpenDaylight Контроллер

Приложения

ЛокальнаяАутентификация

Приложения

Southbound APIs OF 1.x

Сетевые устройства

Northbound APIsOSGI RESTful

Forwarding Rules Manager

Dijkstra SPF

Service Abstraction Layer (SAL)

Physical and Logical Topology Manager

Device Manager

Host Tracker ARP Handler

H/A

Java Bundle

Page 42: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Cisco XNC КонтроллерОснован на OpenDaylight + расширенные функции и приложения

Southbound APIs

Physical and Logical Topology Manager

Device Manager

Host Tracker ARP Handler

Forwarding Rules Manager

Dijkstra SPF L3 InterfaceРасширенная инфраструктура

Java Bundle

H/A

Сетевые устройства

OF 1.xOnePK*

Поиск неисправностей

Функционал продуктивных

сетейВстроенные приложения:

Network Slicing, Custom

Forwarding и Data Broker

Cisco GUI с расширенными

функциями

Service Abstraction Layer (SAL)

Динамические сетевые плагины

Расширенная аналитика и

сервисы через Cisco API

Аутентификация Monitor Manager

Topology Independent Forwarding (TIF)

Приложения КонтроллераSlice Manager

Расширенные компоненты

Cisco GUICisco XNCNorthbound APIsOSGI RESTful

Cisco Собственные 3те сторонниеПриложения

Развитие сервисов из

OD

Page 43: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Openflow - Приложения с Контроллером Cisco XNC 1.5

Network Slicing(Сегментация сети)

Разделение сети с высокой степенью детализации

политик

Topology Independent Forwarding

(Управление трафиком)Статическое и динамическое создание правил для каждого потока на основе различных

параметров

Использование стандартных коммутаторов для передачи на

основе политик зеркалированного трафика к

Инструментам анализа

Nexus Data Broker(Сеть Matrix)

Page 44: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Продуктивная сеть

Приложение Cisco Nexus Data BrokerТрадиционная сеть перехвата трафика

L1 Matrix коммутаторСтатические фильтры и

форвардинг

IDS

Wireshark

ВидеоМонитор

Сеть Matrix построена на специализированных коммутаторах

Инструменты

Page 45: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

D

Продуктивная сеть

Приложение Cisco Nexus Data BrokerПодход Cisco – решение на основе SDN

Сеть Matrix заменяется на коммутаторы Nexus 3000, XNC Контроллер и приложение Nexus Data Broker

ИнструментыС SDN решениемNexus Data Broker

НовоеПрил. Собствен

ные приложения

Nexus 3000с OpenFlow

Wireshark

ВидеоМонитор

ОптическиеTAP-ы

Cisco XNC Контроллер

Центральная точкаперехвата

SPAN/ERSPAN

Динамическая фильтрация и передачаОбратная связь с приложением/

В режиме реального времени

Page 46: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Пример топологии Cisco Nexus Data Broker

SPAN/ERSPAN

Инфраструктура Nexus Data Broker

Nexus 3000с OpenFlow

Nexus 3000с OpenFlow

Копия трафика из продуктивной сети

Я хочу передать веб трафик на

систему сетевого анализа …

Инструментыанализа

Page 47: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Cisco Application Policy Infrastructure Controller (APIC)

Page 48: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

APIC - управление фабрикой на основе политик/сетевых профилей• Расширение принципов сервисного

профиля Cisco UCS® Manager на всю фабрику

• Сетевой профиль: определение требований приложения без привязки к оборудованию (stateless принцип) Уровни приложений (tiers)

Политики регламентирующие взаимодействие

Сервисы 4 – 7 уровня

XML/JSON схема

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

переносимость между фабриками различных ЦОД

## Network Profile: Defines Application Level Metadata (Pseudo Code Example)

<Network-Profile = Production_Web><App-Tier = Web>

<Connected-To = Application_Client><Connection-Policy = Secure_Firewall_External>

<Connected-To = Application_Tier><Connection-Policy = Secure_Firewall_Internal & High_Priority>

. . .<App-Tier = DataBase>

<Connected-To = Storage><Connection-Policy = NFS_TCP & High_BW_Low_Latency>

. . .

App Tier DB Tier

Storage Storage

Web Tier

Приложение

Сетевой профиль полностью описывает сетевые и сервисные потребности приложения

Page 49: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

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

Вся передача данных в фабрике управляется при помощи профилей приложений• 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

Page 50: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

Итого

Приложения, Системы Управления, Контроллеры, ...

Device

Forwarding

Control

Network Services

Orchestration

Management

OpenFlow

OpenFlow

Operating Systems – IOS / NX-OS / IOS-XRAPI (OnePK) and Data Models (YANG)

OpenStack PuppetOnePKC/Java

Puppet

Neutron

Protocols

“Protocols”BGP, PCEP,...

Python NETCONF REST ACI Fabric

OpFlex

onePK Plug-Ins

RESTful

YANG JSON/XML

Page 51: Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов

CiscoRu Cisco CiscoRussia

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

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

7205

Ваше мнение очень важно для нас

Спасибо за внимание!

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