close

Вход

Забыли?

вход по аккаунту

- Cisco Connect

код для вставкиСкачать
Программируемые и программноопределяемые инфраструктуры ЦОД.
Развитие подходов
Виктор Пустошилов
Системный Инженер
[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
Что означает Software-defined Networking (SDN)?
“…В архитектуре SDN разделены уровни управления и
передачи данных, обеспечена логическая централизация
интеллектуальных сетевых механизмов и информации о
состоянии сети, а нижележащая сетевая инфраструктура
абстрагирована от приложений…”
Источник: www.opennetworking.org
Академический взгляд на SDN
Бизнес Приложения
Маршрутизация, контроль доступа, и т.д.
Управляющая программа
Абстракция всей сети
Контроллер / Сетевая ОС
OpenFlow
Коммутация данных
SDN – Software Defined Networking
Развитие архитектуры уровня управления
Традиционный
Уровень Управления
Распределенный
Control Plane
Развитие Архитектуры Уровня Управления
Централизованный SDN
Гибридный SDN
API-и
Disconnected Net and Apps
Протоколы
…
Overlay (tunnels)
Original SDN idea:
Clean Slate Project
Underlay (physical)
(Stanford University)
Компоненты Control/Network/Services-plane
Компоненты ASIC’s, Data-plane
Коммутация, управляемая
приложениями
Приложения
План презентации
• Что означает Software-defined Networking (SDN)?
• Кому и зачем нужен SDN
• Контроллеры SDN и Оркестраторы
• Программные Интерфейсы Управления
-
OpenFlow
NETCONF/YANG, RESTCONF
OpFlex
• Контроллеры SDN и приложения Cisco
-
XNC
APIC
Кому и зачем нужен SDN

Корпоративные заказчики

Сервис провайдеры

Централизованное управление
комплексным функционалом
(Policy/ACL/QoS)

Масштабирование при развертывании
новых/существующих приложений
Control Plane (Segment Routing, TIF)

Оптимизация инфраструктуры


Изменение контекста операций
управления (от синтаксиса к
семантике)
Стандартные протоколы Control Plane
(I2RS/BGP-LS/PCEP)

Разделение Management/Control/Data

Снижение "точек управления”
(один контроллер или несколько
отдельных устройств)
Быстрое развертывание новых услуг
(снижение времени вывода на рынок)

Быстрое внедрение новых технологий
(предоставление уникальных
возможностей пользователям)


Потребление из облака
SDN - Централизованное управление Policy/ACL/QoS
Автоматизация управления на основе политик
REST/Custom API
Netconf/YANG
SDN Controller
SDN Controller
Meraki
ACLs/QoS
OpenDaylight
L2/L3
Connecti
vity
Data
Plane
Device
Policy
Централизованное управление
комплексным функционалом
(Policy/ACL/QoS)
SDN Controller

Оптимизация инфраструктуры
ACI

Изменение контекста операций
управления (от синтаксиса к
семантике)

Снижение "точек управления”
(один контроллер или несколько
отдельных устройств)

Потребление из облака
ACI Policy API
L2/L3
Connecti
vity
APIC
Policy
Open Protocol
Custom Protocol
Control
Plane
Control
Plane
Management
Plane
Management
Plane
Cloud
Data
Plane
Device
Корпоративные заказчики

Management
Plane
Meraki Cloud
API

Data
Plane
Spine/Leaf
L2/L3
Connecti
vity
Policy
SDN - Оптимизация инфраструктуры
Автоматизация управления на основе политик
REST/Custom API
Netconf/YANG
SDN Controller
ACLs/QoS
OpenDaylight
L2/L3
Connecti
vity
Management
Plane
Data
Plane
Device
Корпоративные заказчики

Централизованное управление
комплексным функционалом
(Policy/ACL/QoS)

Оптимизация инфраструктуры

Изменение контекста операций
управления (от синтаксиса к
семантике)

Снижение "точек управления”
(один контроллер или несколько
отдельных устройств)

Потребление из облака
Policy
Open Protocol
Control
Plane

Выбор
Стандартизованной
архитектуры
SDN - Объектное управление
Описание желаемого состояния на основе
объектной модели
REST/Custom API
Netconf/YANG
SDN Controller
SDN Controller
Meraki
ACLs/QoS
OpenDaylight
L2/L3
Connecti
vity
Data
Plane
Device
Policy
Централизованное управление
комплексным функционалом
(Policy/ACL/QoS)
SDN Controller

Оптимизация инфраструктуры
ACI

Изменение контекста операций
управления (от синтаксиса к
абстрактным объектам)

Снижение "точек управления”
(один контроллер или несколько
отдельных устройств)

Потребление из облака
ACI Policy API
L2/L3
Connecti
vity
APIC
Policy
Open Protocol
Custom Protocol
Control
Plane
Control
Plane
Management
Plane
Management
Plane
Cloud
Data
Plane
Device
Корпоративные заказчики

Management
Plane
Meraki Cloud
API

Data
Plane
Spine/Leaf
L2/L3
Connecti
vity
Policy
SDN - Снижение "точек управления”
Автоматизация управления на основе политик

Корпоративные заказчики

Централизованное управление
комплексным функционалом
(Policy/ACL/QoS)
SDN Controller

Оптимизация инфраструктуры
ACI

Изменение контекста операций
управления (от синтаксиса к
семантике)

Снижение "точек управления”
(один контроллер или несколько
отдельных устройств)

Потребление из облака
ACI Policy API
APIC
Data
Plane
Spine/Leaf
L2/L3
Connecti
vity
Policy
Control
Plane
Data
Plane
Spine/Leaf
L2/L3
Connecti
vity
Policy
Management
Plane
Control
Plane
Management
Plane
Management
Plane
OpFlex
Control
Plane
Data
Plane
Spine/Leaf
L2/L3
Connecti
vity
Policy
SDN - Потребление из облака
SDN Controller
Meraki
L2/L3
Connecti
vity
Data
Plane
Device
Control
Plane
Data
Plane
L2/L3
Connecti
vity
Policy

Корпоративные заказчики

Централизованное управление
комплексным функционалом
(Policy/ACL/QoS)

Оптимизация инфраструктуры

Изменение контекста операций
управления (от синтаксиса к
семантике)

Снижение "точек управления”
(один контроллер или несколько
отдельных устройств)

Потребление из облака
Infrastructure
Policy
Management
Plane
Management
Plane
Cloud
Устаревшие
платформы
Management
Plane
Meraki Cloud
API
Control
Plane
Data
Plane
Infrastructure
L2/L3
Connecti
vity
Policy
План презентации
• Что означает Software-defined Networking (SDN)?
• Кому и зачем нужен SDN
• Контроллеры SDN и Оркестраторы
• Программные Интерфейсы Управления
-
OpenFlow
NETCONF/YANG, RESTCONF
OpFlex
• Контроллеры SDN и приложения Cisco
-
XNC
APIC
Контроллеры SDN и Оркестраторы
- Контроллеры SDN, системы централизованного управления,
системы оркестрации….
- Одно и тоже или взаимодополняющие компоненты?
- Давайте разберемся.
Различие между оркестраторами и контроллерами
Платформа
Оркестрации
Например UCS Director
Контроллеры – платформы для
приложений, которые программируют
Control plane устройств или получают
информацию о состоянии от Control
Plane устройств

Приложение
(например
IaaS)
Например XNC (платформа) – Data
Broker (приложение)
Management
Plane

Например
UCS Director
Control
Plane
Data
Plane
Device
Определение услуги
Политика услуги
Взаимосвязи услуги
Жизненный цикл
услуги
• Поддержка услуги
•
•
•
•
• Управление через
API
• Развертывание
услуги
• Логика оркестрации
• Приложение
управления
• Взаимодействие с
инфраструктурой
L2/L3
Connecti
vity
Policy
Приложение
контроллера
Например
Data Broker
Платформа
контроллера
Например
Cisco XNC
Management
Plane
Оркестраторы – платформы
автоматизации, используются
приложениями для конфигурирования
инфраструктуры (через Management
Plane опосредованно
определяют/контролируют Control Plane
и Data Plane), и выполняют конкретные
Сервисные Запросы
Control
Plane
Data
Plane
Device
L2/L3
Connecti
vity
Policy
Различие между оркестраторами и контроллерами
Платформа
Оркестрации
Например UCS Director
Контроллеры – платформы (для
приложений), которые программируют
Control plane устройств или получают
информацию о состоянии от Control
Plane устройств

Приложение
(например
IaaS)
Например XNC (платформа) – Data
Broker (приложение)
Management
Plane

Например
UCS Director
Control
Plane
Data
Plane
Device
• Интерфейс
приложения
• Логика управления
Control Plane
• Взаимосвязи
приложения
• Интерфейсы
интеграции
приложений
• Сервисные функции
(DB)
• Message bus
• Протоколы Control
Plane
• Протоколы South
Bound к инфраст-ре
L2/L3
Connecti
vity
Policy
Приложение
контроллера
Например
Data Broker
Платформа
контроллера
Например
Cisco XNC
Management
Plane
Оркестраторы – платформы
автоматизации, которые используются
приложениями для конфигурирования
инфраструктуры (через Management
Plane опосредованно
определяют/контролируют Control Plane
и Data Plane), и выполняют конкретные
Сервисные Запросы
Control
Plane
Data
Plane
Device
L2/L3
Connecti
vity
Policy
Различие между приложением и платформой контроллера
• Приложение может быть
реализовано
как интегрированное (например APIC)
или
на основе открытой платформы
контроллера (например Data Broker).
• Множество сетевых приложений
управления связано с
необходимостью решать различные
задачи управления сетевой
инфраструктурой.
• Выбор платформы контроллера для
приложения определяется
возможностями платформы.
Интегрированное
приложение управления
– например APIC
Приложение для
платформы контроллера,
например Data Broker
Сетевое
приложение
контроллера
Сетевое
приложение
контроллера
Платформа
Контроллер
а
Сетевое
устройство
Сетевое
устройство
Вертикально
интегрированная
платформа
Контроллер и
инфраструктура
разделены
Например
Cisco XNC
Способы взаимодействия контроллеров и оркестраторов
Оркестратор
Оркестратор
Приложение,
использующее
оркестратор
Приложение,
использующее
оркестратор
Приложение,
использующее
оркестратор
Платформа
оркестрации
Платформа
оркестрации
Платформа
оркестрации
-
Forwarding tables
-
Policy tables
Через протоколы SDN
(OpenFlow)/протоколы Control
Plane (I2RS, BGP-LS, PCEP)
Оркестратор может опрашивать
контроллеры в процессе
принятия решения оркестрации
Control
Plane
Data
Plane
Device
L2/L3
Connecti
vity
Policy
SDN Controller
SDN Controller
Приложение
контроллера
Приложение
контроллера
Платформа
контроллера
Платформа
контроллера
Control
Plane
Data
Plane
Device
L2/L3
Connecti
vity
Policy
Management
Plane
Контроллеры программируют
Control plane устройств:
-

Оркестратор
Management
Plane
•
Оркестраторы настраивают
устройства через Management
Plane:
- CLI
- RPC (Netconf)
- Models (Netconf/YANG)
Management
Plane
•
Control
Plane
Data
Plane
Device
L2/L3
Connecti
vity
Policy
Модели взаимодействия контроллеров/ оркестраторов/ сети
Система
Оркестрации/Пр
иложение
L2/L3
Connectivity
Policy
XNC
controller
Data
Plane
Коммутатор
Push – например XNC/Data Broker
• Сетевое состояние проактивно
спускается на сетевые устройства
при создании новых правил в
приложении
Management
Plane
OpFlex
Mapping
server
L2/L3
Connectivity
Policy
Control
Plane
Data
Plane
Коммутатор
Pull – например ACI, LISP
• Сетевое состояние
передается на устройства
доступа по запросу
(реактивно)
Control
Plane
L2/L3
Connectivity
BGP RR
Policy
iBGP
Control
Plane
Data
Plane
Edge
iBGP
L2/L3
Connectivity
Policy
Management
Plane
APIC
Контроллер
Management
Plane
Control
Plane
NetConf/Y
ANG
Management
Plane
Management
Plane
OpenFlow
Control
Plane
Management
Plane
RESTCONF
Control
Plane
Data
Plane
Core
iBGP
L2/L3
Connectivity
Policy
Management
Plane
Система
Оркестрации/П
риложение
Система
Оркестрации/П
риложение
Control
Plane
Data
Plane
Core
L2/L3
Connectivity
Policy
Распределенная модель - например BGP, IGP
• Система оркестрации определяет
конфигурацию устройств доступа, которые в
свою очередь анонсируют доступность через
протоколы маршрутизации
План презентации
• Что означает Software-defined Networking (SDN)?
• Кому и зачем нужен SDN
• Контроллеры SDN и Оркестраторы
• Программные Интерфейсы Управления
- NETCONF/YANG, RESTCONF
- OpenFlow
- OpFlex
• Контроллеры SDN и приложения Cisco
-
XNC
APIC
Программные Интерфейсы по категориям
Настройка
Управление
Программные
расширения
DevOps
Интеграция
NETCONF
YANG
BGP-LS
PCEP
BGP
Flowspec
Cisco
Python API
OpFlex
Программные Интерфейсы Управления
Приложения, Системы Управления, Контроллеры, ...
OnePK
C/Java
Python
NETCONF
REST
OpenFlow ACI Fabric OpenStack
Puppet
Protocols
…
RESTful
Management
Puppet
Orchestration
Neutron
“Protocols”
Network Services
BGP, PCEP,...
Control
OpFlex
Forwarding
OpenFlow
onePK Plug-Ins
API (OnePK) and Data Models (YANG)
Operating Systems – IOS / NX-OS / IOS-XR
YANG
Device
…
JSONXML
NETCONF и RESTCONF
RPC (Remote Procedure Call) операции с конфигурационными и оперативными данными в формате XML
•
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) – программная архитектура веб приложений
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
…
YANG
YANG (RFC6020) язык описания модели данных (data modelling language)
•
“Yet Another Net Generation“ – разработан после фиаско NG-SNMP
•
Разрабатывался как язык описания модели данных для протокола NETCONF
•
NETCONF/YANG‘s должны обеспечить мультивендорное R/W управление элементами и услугами,
став таким образом открытым стандартом программного управления устройствами
YANG vs. SNMP
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 (пример)
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-andtime
+--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 example
container 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";
get reply
– XML-encoded
YANG data example
}
leaf
link-up-down-trap-enable
{
<?xml
version="1.0"
encoding="UTF-8"?>
if-feature
if-mib;
<rpc-reply message-id=“9“
type enumeration {
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0“>
<data> enum enabled { value 1; }
enum disabled { value 2; }
<interfaces
} xmlns="urn:ietf:params:xml:ns:yang:ietf}
interfaces“>
} <interface>
}
<name>eth0</name>
container
interfaces-state {
<type>ianaift:ethernetCsmacd</type>
config
false;
<enabled>false</enabled>
description
</interface>
"Data
nodes for the operational state of interfaces.";
</interfaces>
list
interface { key "name";
<interfaces-state
... xmlns="urn:ietf:params:xml:ns:yang:ietfinterfaces“>
<interface>
Программные Интерфейсы Управления
Приложения, Системы Управления, Контроллеры, ...
OnePK
C/Java
Python
NETCONF
REST
OpenFlow ACI Fabric OpenStack
Puppet
Protocols
…
RESTful
Management
Puppet
Orchestration
Neutron
“Protocols”
Network Services
BGP, PCEP,...
Control
OpFlex
Forwarding
OpenFlow
onePK Plug-Ins
API (OnePK) and Data Models (YANG)
Operating Systems – IOS / NX-OS / IOS-XR
YANG
Device
…
JSON/XML
Что такое OpenFlow?
“…открытый стандарт, определяющий
взаимодействие между разделёнными уровнями
управления (контроллер) и передачи данных
(агент)…”
Источник: www.openflow.org
Openflow
Openflow
Приложения
API’s
Контроллер OPENFLOW
(например OpenDaylight / Cisco XNC)
- Symmetric Sync Messages (Hello, Echo, Vendor…)
- Async Messages (Port-Status, Flow-Removed, Error…)
- Forwarding Control & Stats Collection
Коммутатор
OF 1.1+:
Требуется специальный ASIС
GROUP
TABLE (1.1)
FLOW
TABLE 1
Data
Data
OF
или
STD
FLOW METER
TABLE (1.3)
FLOW
TABLE 2
pipeline
(1.1)
FLOW
TABLE n
SWITCH FORWARDING ENGINE
STD Ethernet Processing Pipeline
OPENFLOW
HYBRID SWITCH
(1.1)
CPU
O
U
T
P
U
T
Openflow
Действия (1.0)
OF 1.1+:
Требуется специальный ASIC
FLOW TABLE
HEADER FIELDS
COUNTERS
ACTIONS
…
…
…
…
…
…
Счетчики:
• per Table, Flow, Queue, Port
• Bytes, Packets, Errors, Flow duration…
• Counter Disable (1.3)
Маскируемые поля (14-tuple):
L1/L2 (1.0)
Ingress
Port
Source
MAC
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
MPLS (1.1,BoS 1.3) IPv4 (1.0), IPv6 (1.2)
Dest
MAC
Ether
Type
VLAN
ID
VLAN
Priority
MPLS
Label
MPLS
Traffic
Class
IP
SRC
IP
DEST
IP
Protocol
L4 ports (1.0)
IP
TOS
TCP/UDP
SRC
ICMP Type
TCP/UDP
DEST
ICMP Code
Программные Интерфейсы Управления
Приложения, Системы Управления, Контроллеры, ...
OnePK
C/Java
Python
NETCONF
REST
OpenFlow ACI Fabric OpenStack
Puppet
Protocols
…
RESTful
Management
Puppet
Orchestration
Neutron
“Protocols”
Network Services
BGP, PCEP,...
Control
OpFlex
Forwarding
OpenFlow
onePK Plug-Ins
API (OnePK) and Data Models (YANG)
Operating Systems – IOS / NX-OS / IOS-XR
YANG
Device
…
JSON/XML
Решаемая проблема: микроуправление инфраструктурой
• На сегодня сети – это среды, требующие
детального конфигурирования
• Требования пользователей,
инфраструктуры и политик сопровождения
зачастую противоречат друг другу
• Это порождает большие проблемы с
масштабируемостью, повышает отказы
и снижает совместимость
• Доступные на сегодня протоколы SDN не
решают проблему микроуправления
“Trunk vlan”
“Настроить
ACL”
“ Добавить
маршрут…”
Control System
Запрос пользователя
разделяется на множество
конечных команд, связанный с
настройкой конкретной
инфраструктуры
“Развернуть
приложение
X”
Элементы
Императивный контроль
Система
управления/пользовате
ль передает
конфигурацию на
устройства.
Админ
Пример: Сконфигурировать сеть на сервере
Императивный контроль – в чем недостатки
Недостатки систем с императивным контролем (OpenFlow + OVSDB):
-
Централизованное управление SDN плохо масштабируется – все сетевые устройства должны
зарегистрироваться на контроллере.
-
Большой домен отказа.
-
Система управления должна знать возможности всех устройств – точное описание управляемых
объектов с использованием низкоуровневых сетевых функций.
-
Задействуется небольшой набор функционала для достижения приемлемой масштабируемости в
решениях SDN первого поколения.
В случае императивного подхода
все эти устройства должны
выглядеть одинаково
Ограничение функционала
сдерживает развитие
Modular 1
Hypervisor vSwitches
Modular 2
Vendor 1
Vendor 2
Решение: Декларативный контроль
Админ
“Разрешить Хосту A
взаимодействовать с
Хостом B”
Отказы
- Инфраструктура самостоятельно
интерпретирует политики в
соответствии со своими
возможностями и производит
изменение конфигурации
Control System
- Создаваемые абстрактные политики
напрямую передаются на
инфраструктуру
Элементы
- Администратор создает политики на
основе абстрактных элементов
“Мои Веб серверы
должны
взаимодействовать с
моими серверами
приложений”
“Исполняю”
Сделаны
соответствующие
изменения
SDN или нет?
Policy Manager + Control Plane
SDN Controller
Элементы
OpenFlow + OVSDB
Control System Админ
Императивный контроль
OpFlex - новый расширяемый протокол описания
политик, разработанный для декларативного
управления любой инфраструктурой ЦОД.
Data Plane
Декларативный контроль
Policy Manager
APIC
OpFlex
Control Plane + Data Plane
OpFlex - как это работает
APIC управляет
логической моделью
желаемого состояния
APIC
POLICY
Запрос
политики
1
Конечное устройство
интерпретирует политику
и сопоставляет со своими
аппаратными
возможностями
HARDWARE
PORTS,
VLANS,
INTERFACES
2
3
Обновление
политики
4
Интерпретация
политики
SUBSET OF
POLICY
Интерпретация может в том числе
использовать программные интерфейсы
включая 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 Контроллер: базовые функции
Приложения
Приложения
OpenDaylight Контроллер
OSGI
H/A
GUI
Northbound APIs
RESTful
Локальная
Аутентификация
Dijkstra SPF
Forwarding Rules
Manager
Host Tracker
Physical and Logical
Topology Manager
ARP Handler
Device
Manager
Service Abstraction Layer (SAL)
Southbound APIs
Сетевые устройства
OF 1.x
Java Bundle
Базовая инфраструктура
Cisco XNC Контроллер
Основан на OpenDaylight + расширенные функции и приложения
Приложения
Собственные
Cisco
Cisco XNC
Cisco GUI
Northbound APIs
OSGI
Функционал
продуктивных
сетей
Forwarding Rules
Manager
L3 Interface
Host Tracker
Physical and Logical
Topology Manager
ARP Handler
Device
Manager
Java Bundle
Расширенная
аналитика и
сервисы через
Cisco API
Topology Independent Forwarding (TIF)
Расширенная инфраструктура
Dijkstra SPF
Cisco GUI с
расширенными
функциями
RESTful
Приложения Контроллера
Monitor Manager
Slice Manager
Расширенные компоненты
Аутентификация
H/A
Поиск неисправностей
Развитие
сервисов из
OD
3те сторонние
Встроенные
приложения:
Network
Slicing,
Custom
Forwarding и
Data Broker
Service Abstraction Layer (SAL)
OnePK*
Southbound APIs
Сетевые устройства
OF 1.x
Динамические
сетевые
плагины
Openflow - Приложения с Контроллером Cisco XNC 1.5
Nexus Data Broker
(Сеть Matrix)
Использование стандартных
коммутаторов для передачи на
основе политик
зеркалированного трафика к
Инструментам анализа
Topology Independent
Forwarding
(Управление трафиком)
Статическое и динамическое
создание правил для каждого
потока на основе различных
параметров
Network Slicing
(Сегментация сети)
Разделение сети с высокой
степенью детализации
политик
Приложение Cisco Nexus Data Broker
Традиционная сеть перехвата трафика
Инструменты
Продуктивная сеть
IDS
Wireshark
Видео
L1 Matrix коммутатор
Монитор Статические фильтры и
форвардинг
Сеть Matrix построена на специализированных коммутаторах
Приложение Cisco Nexus Data Broker
Подход Cisco – решение на основе SDN
Инструменты
Новое
Прил.
Собствен
ные
приложен
ия
Wireshark
Видео
Монитор
Продуктивная сеть
Cisco XNC
Контроллер
Динамическая фильтрация и передача
Обратная связь с приложением/
D
В режиме реального времени
С SDN решениемNexus Data Broker
Центральная точка
перехвата
Оптические
TAP-ы
Nexus 3000
с OpenFlow
SPAN/
ERSPAN
Сеть Matrix заменяется на коммутаторы Nexus 3000, XNC
Контроллер и приложение Nexus Data Broker
Пример топологии Cisco Nexus Data Broker
Я хочу передать
веб трафик на
систему сетевого
анализа …
SPAN/
ERSPAN
Nexus 3000
с OpenFlow
Nexus 3000
с OpenFlow
Инструменты
анализа
Инфраструктура Nexus Data Broker
Копия трафика из
продуктивной сети
Cisco Application Policy Infrastructure Controller
(APIC)
APIC - управление фабрикой на основе политик/сетевых профилей
• Расширение принципов сервисного
профиля Cisco UCS® Manager на всю
фабрику
• Сетевой профиль: определение
требований приложения без привязки к
оборудованию (stateless принцип)
̶ Уровни приложений (tiers)
̶ Политики регламентирующие взаимодействие
Приложение
Web Tier
Storage
Storage
App Tier
DB Tier
Сетевой профиль полностью описывает
сетевые и сервисные потребности приложения
̶ Сервисы 4 – 7 уровня
## Network Profile: Defines Application Level Metadata (Pseudo Code Example)
̶ XML/JSON схема
<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>
...
• Полная абстракция от физической
инфраструктуры
̶ устранение зависимости от инфраструктуры
̶ переносимость между фабриками различных
ЦОД
Профиль приложения и его применение к сети
Клиент
приложения
Профиль приложения: определяет
сетевые требования приложения
(сетевой профиль приложения)
Storage
Storage
App Tier
Web Tier
DB Tier
Применение профиля: каждое
сетевое устройство динамически
производит изменения настроек,
требуемые профилем
APIC
VM
VM
VM
10.2.4.7 10.9.3.37
VM
VM
VM
VM
10.32.3.7
Вся передача данных в фабрике управляется при помощи профилей приложений
• IP адреса полностью переносимы и могут использоваться где угодно внутри фабрики
• Безопасность и передача данных не зависят от любых физических и логических сетевых
атрибутов
• Коммутаторы автономно обновляют свои настройки на основе правил, определенных
профилем приложения, в случае переезда/миграции приложения или его компонент
Итого
Приложения, Системы Управления, Контроллеры, ...
OnePK
C/Java
Python
NETCONF
REST
OpenFlow ACI Fabric OpenStack
Puppet
Protocols
…
RESTful
Management
Puppet
Orchestration
Neutron
“Protocols”
Network Services
BGP, PCEP,...
Control
OpFlex
Forwarding
OpenFlow
onePK Plug-Ins
API (OnePK) and Data Models (YANG)
Operating Systems – IOS / NX-OS / IOS-XR
YANG
Device
…
JSON/XML
Ждем ваших сообщений с хештегом
#CiscoConnectRu
Спасибо за внимание!
Пожалуйста, используйте код для
оценки доклада
7205
Ваше мнение очень важно для нас
CiscoRu
25.11.2014
Cisco
© 2014 Cisco and/or its affiliates. All rights reserved.
CiscoRussia
1/--страниц
Пожаловаться на содержимое документа