Upload
cisco-russia
View
188
Download
1
Embed Size (px)
DESCRIPTION
Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов
Citation preview
Программируемые и программно-определяемые инфраструктуры ЦОД. Развитие подходов
Виктор ПустошиловСистемный Инженер[email protected]
20.10.14 © 2014 Cisco and/or its affiliates. All rights reserved.
План презентации
• Что означает Software-defined Networking (SDN)?• Кому и зачем нужен SDN• Контроллеры SDN и Оркестраторы• Программные Интерфейсы Управления
- OpenFlow- NETCONF/YANG, RESTCONF- OpFlex
• Контроллеры SDN и приложения Cisco- XNC- APIC
“…В архитектуре SDN разделены уровни управления и передачи данных, обеспечена логическая централизация интеллектуальных сетевых механизмов и информации о состоянии сети, а нижележащая сетевая инфраструктура абстрагирована от приложений…”
Источник: www.opennetworking.org
Что означает Software-defined Networking (SDN)?
Контроллер / Сетевая ОС
Управляющая программаМаршрутизация, контроль доступа, и т.д.
Абстракция всей сети
Коммутация данных
OpenFlow
Академический взгляд на SDN
Бизнес Приложения
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
План презентации
• Что означает Software-defined Networking (SDN)?
• Кому и зачем нужен SDN• Контроллеры SDN и Оркестраторы• Программные Интерфейсы Управления
- OpenFlow- NETCONF/YANG, RESTCONF- OpFlex
• Контроллеры SDN и приложения Cisco- XNC- APIC
Кому и зачем нужен SDN Сервис провайдеры Масштабирование при развертывании
новых/существующих приложенийControl Plane (Segment Routing, TIF)
Стандартные протоколы Control Plane (I2RS/BGP-LS/PCEP)
Разделение Management/Control/Data Быстрое развертывание новых услуг
(снижение времени вывода на рынок) Быстрое внедрение новых технологий
(предоставление уникальных возможностей пользователям)
Корпоративные заказчики Централизованное управление
комплексным функционалом (Policy/ACL/QoS)
Оптимизация инфраструктуры Изменение контекста операций
управления (от синтаксиса к семантике)
Снижение "точек управления”(один контроллер или несколько отдельных устройств)
Потребление из облака
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
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
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
Корпоративные заказчики Централизованное управление
комплексным функционалом (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
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 - Потребление из облака
План презентации
• Что означает Software-defined Networking (SDN)?• Кому и зачем нужен SDN
• Контроллеры SDN и Оркестраторы• Программные Интерфейсы Управления
- OpenFlow- NETCONF/YANG, RESTCONF- OpFlex
• Контроллеры SDN и приложения Cisco- XNC- APIC
Контроллеры SDN и Оркестраторы
- Контроллеры SDN, системы централизованного управления, системы оркестрации….
- Одно и тоже или взаимодополняющие компоненты?- Давайте разберемся.
Различие между оркестраторами и контроллерами
Приложение(например
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
Различие между оркестраторами и контроллерамиОркестраторы – платформы автоматизации, которые используются приложениями для конфигурирования инфраструктуры (через 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
• Взаимосвязиприложения
Различие между приложением и платформой контроллера
Контроллер и инфраструктура
разделены
Вертикально интегрированная
платформа
• Приложение может быть реализовано как интегрированное (например APIC)или на основе открытой платформы контроллера (например Data Broker).
• Множество сетевых приложений управления связано с необходимостью решать различные задачи управления сетевой инфраструктурой.
• Выбор платформы контроллера для приложения определяется возможностями платформы.
Сетевое приложение контроллера
Сетевое приложение контроллера
Платформа Контроллер
а
Интегрированное приложение управления
– например APIC
Приложение для платформы контроллера,
например Data Broker
Например Cisco XNC
Сетевое устройство
Сетевое устройство
Способы взаимодействия контроллеров и оркестраторов
• Оркестраторы настраивают устройства через 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
Модели взаимодействия контроллеров/ оркестраторов/ сети
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
План презентации
• Что означает Software-defined Networking (SDN)?• Кому и зачем нужен SDN• Контроллеры SDN и Оркестраторы
• Программные Интерфейсы Управления- NETCONF/YANG, RESTCONF- OpenFlow- OpFlex
• Контроллеры SDN и приложения Cisco- XNC- APIC
Программные Интерфейсы по категориям
НастройкаУправление
Программные расширения
DevOpsИнтеграция
NETCONFYANG
BGP-LSPCEP
OpFlexCiscoPython API
BGP Flowspec
Программные Интерфейсы Управления
Приложения, Системы Управления, Контроллеры, ...
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
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) – программная архитектура веб приложений
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
Интерфейс 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>
Приложения, Системы Управления, Контроллеры, ...
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
Программные Интерфейсы Управления
“…открытый стандарт, определяющий взаимодействие между разделёнными уровнями управления (контроллер) и передачи данных (агент)…”
Источник: www.openflow.org
Openflow
Что такое OpenFlow?
Ком
мут
атор
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
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
Программные Интерфейсы Управления
Приложения, Системы Управления, Контроллеры, ...
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
Решаемая проблема: микроуправление инфраструктурой
• На сегодня сети – это среды, требующие детального конфигурирования
• Требования пользователей, инфраструктуры и политик сопровождения зачастую противоречат друг другу
• Это порождает большие проблемы с масштабируемостью, повышает отказы и снижает совместимость
• Доступные на сегодня протоколы SDN не решают проблему микроуправления
Пример: Сконфигурировать сеть на сервере
Элем
енты
Con
trol
Sys
tem
Адм
ин
“Развернуть приложение
X”
“Trunk vlan”
“Настроить ACL”
“ Добавить маршрут…”
Система управления/пользовате
ль передает конфигурацию на
устройства. Императивный контрольЗапрос пользователя разделяется на множество конечных команд, связанный с настройкой конкретной инфраструктуры
Императивный контроль – в чем недостатки
Недостатки систем с императивным контролем (OpenFlow + OVSDB):- Централизованное управление SDN плохо масштабируется – все сетевые устройства должны
зарегистрироваться на контроллере.
- Большой домен отказа.
- Система управления должна знать возможности всех устройств – точное описание управляемых объектов с использованием низкоуровневых сетевых функций.
- Задействуется небольшой набор функционала для достижения приемлемой масштабируемости в решениях SDN первого поколения.
Modular 1
Modular 2Vendor 1
Vendor 2
Hypervisor vSwitchesВ случае императивного подхода все эти устройства должны выглядеть одинаково
Ограничение функционала сдерживает развитие
Решение: Декларативный контроль
Элем
енты
Cont
rol S
yste
mАд
мин
Отк
азы
“Мои Веб серверы должны
взаимодействовать с моими серверами
приложений”
“Разрешить Хосту A взаимодействовать с
Хостом B”
“Исполняю”
Сделаны соответствующие
изменения
- Администратор создает политики на основе абстрактных элементов
- Создаваемые абстрактные политикинапрямую передаются на инфраструктуру
- Инфраструктура самостоятельно интерпретирует политики в соответствии со своими возможностями и производит изменение конфигурации
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 - новый расширяемый протокол описания политик, разработанный для декларативного управления любой инфраструктурой ЦОД.
OpFlex - как это работает
Конечное устройство интерпретирует политику и сопоставляет со своими аппаратными возможностями
POLICYAPICAPIC управляет логической моделью желаемого состояния
HARDWARE
PORTS, VLANS,
INTERFACES
SUBSET OFPOLICY
4
Интерпретацияполитики
Обновление политики
Запрос политики
32
1
Интерпретация может в том числе использовать программные интерфейсы включая OVSDB, OpenFlow или собственный API устройства
План презентации
• Что означает Software-defined Networking (SDN)?• Кому и зачем нужен SDN• Контроллеры SDN и Оркестраторы• Программные Интерфейсы Управления
- NETCONF/YANG, RESTCONF- OpenFlow- OpFlex
• Контроллеры SDN и приложения Cisco- XNC- APIC
Cisco eXtensible Network Controller (XNC)
Что такое OpenDaylight ?OpenDaylight – это проект с открытым исходным кодом, сформированный лидирующими компаниями под эгидой Linux Foundation. Целью проекта является расширение использования и развитие технологий SDN (Software Defined Networking) через создание общей, поддерживаемой всеми производителями, архитектуры.
Platinum Gold Silver
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
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
Openflow - Приложения с Контроллером Cisco XNC 1.5
Network Slicing(Сегментация сети)
Разделение сети с высокой степенью детализации
политик
Topology Independent Forwarding
(Управление трафиком)Статическое и динамическое создание правил для каждого потока на основе различных
параметров
Использование стандартных коммутаторов для передачи на
основе политик зеркалированного трафика к
Инструментам анализа
Nexus Data Broker(Сеть Matrix)
Продуктивная сеть
Приложение Cisco Nexus Data BrokerТрадиционная сеть перехвата трафика
L1 Matrix коммутаторСтатические фильтры и
форвардинг
IDS
Wireshark
ВидеоМонитор
Сеть Matrix построена на специализированных коммутаторах
Инструменты
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
Динамическая фильтрация и передачаОбратная связь с приложением/
В режиме реального времени
Пример топологии Cisco Nexus Data Broker
SPAN/ERSPAN
Инфраструктура Nexus Data Broker
Nexus 3000с OpenFlow
Nexus 3000с OpenFlow
Копия трафика из продуктивной сети
Я хочу передать веб трафик на
систему сетевого анализа …
Инструментыанализа
Cisco Application Policy Infrastructure Controller (APIC)
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
Приложение
Сетевой профиль полностью описывает сетевые и сервисные потребности приложения
Профиль приложения и его применение к сети
Вся передача данных в фабрике управляется при помощи профилей приложений• 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
Итого
Приложения, Системы Управления, Контроллеры, ...
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
CiscoRu Cisco CiscoRussia
Ждем ваших сообщений с хештегом#CiscoConnectRu
Пожалуйста, используйте код для оценки доклада
7205
Ваше мнение очень важно для нас
Спасибо за внимание!
25.11.2014 © 2014 Cisco and/or its affiliates. All rights reserved.