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

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

План презентации
•
Что означает Software-definedNetworking(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


Сервис провайдеры

Масштабирование при развертывании новых/существующих приложенийControl Plane(Segment Routing, TIF)

Стандартные протоколы Control Plane (I2RS/BGP-LS/PCEP)

Разделение Management/Control/Data

Быстрое развертывание новых услуг(снижение времени вывода на рынок)

Быстрое внедрение новых технологий (предоставление уникальных возможностей пользователям)

Корпоративныезаказчики

Централизованное управление комплекснымфункционалом (Policy/ACL/QoS)

Оптимизация инфраструктуры

Изменение контекста операций управления(от синтаксиса к семантике)

Снижение "точек управления” (один контроллер или несколько отдельных устройств)

Потребление из облака

Device
SDN-Централизованноеуправление Policy/ACL/QoS
Device
DataPlane
Management
Plane

Корпоративные заказчики





Meraki
SDN Controller
ACI Policy API
REST/Custom API
Netconf/YANG
MerakiCloud API
Cloud
Автоматизация управления на основе политик
ACLs/QoS
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
SDN Controller
Spine/Leaf
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
ACI
SDN Controller
Custom Protocol
APIC
Open Protocol
OpenDaylight
Control
Plane
Policy
L2/L3 Connectivity
Control
Plane

SDN-Оптимизация инфраструктуры






REST/Custom API
Netconf/YANG
Device
DataPlane
Management
Plane
ACLs/QoS
SDN Controller
Open Protocol
OpenDaylight
Policy
L2/L3 Connectivity
Выбор
Стандартизованной
архитектуры
Control
Plane

Device
SDN-Объектное управление




Изменение контекста операций управления(от синтаксиса к абстрактным объектам)


Meraki
SDN Controller
ACI Policy API
REST/Custom API
Netconf/YANG
MerakiCloud API
Cloud
Описание желаемого состояния на основе объектной модели
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
Spine/Leaf
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
ACI
SDN Controller
Custom Protocol
APIC
Device
DataPlane
Management
Plane
ACLs/QoS
SDN Controller
Open Protocol
OpenDaylight
Policy
L2/L3 Connectivity
Control
Plane
Control
Plane







ACI Policy API
Spine/Leaf
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
ACI
SDN Controller
Spine/Leaf
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
Spine/Leaf
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
APIC
OpFlex
SDN-Снижение "точек управления”
Control
Plane
Control
Plane
Control
Plane

Device






Meraki
SDN Controller
Устаревшие платформы
MerakiCloud API
Cloud
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
Infrastructure
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
Control
Plane
Infrastructure
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
Control
Plane
SDN-Потребление из облака

Контроллеры SDNиОркестраторы
-
Контроллеры SDN, системы централизованного управления, системы оркестрации….
-
Одно и тоже или взаимодополняющие компоненты?
-
Давайте разберемся.

Различие между оркестраторами и контроллерами
Приложение
(например IaaS)
Платформа Оркестрации
Приложение контроллера
Платформа контроллера
Например
Data Broker
Например Cisco XNC
Например UCS Director
Device
Policy
DataPlane
L2/L3 Connectivity
Control
Plane
Device
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
Control
Plane
•
Управление через API
•
Развертываниеуслуги
•
Логика оркестрации
•
Приложениеуправления
•
Взаимодействиес инфраструктурой
•
Определение услуги
•
Политика услуги
•
Взаимосвязиуслуги
•
Жизненный циклуслуги
•
Поддержка услуги
Оркестраторы–платформы автоматизации, используются приложениями для конфигурирования инфраструктуры (через Management Planeопосредованно определяют/контролируют Control Plane и Data Plane),и выполняют конкретные Сервисные Запросы

Контроллеры–платформы для приложений, которые программируют Control plane устройств или получают информацию о состоянии от Control Planeустройств

Например XNC (платформа)–Data Broker (приложение)
Management
Plane

Различие между оркестраторами и контроллерами
Оркестраторы–платформы автоматизации, которые используются приложениями для конфигурирования инфраструктуры (через Management Planeопосредованно определяют/контролируют Control Plane и Data Plane),и выполняют конкретные Сервисные Запросы

Контроллеры–платформы (для приложений), которые программируют Control planeустройств или получают информацию о состоянии от Control Planeустройств

Например XNC (платформа)–Data Broker (приложение)
(например IaaS)
Платформа Оркестрации
Платформа контроллера
Например
Data Broker
Device
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
Control
Plane
Device
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
Control
Plane
•
Интерфейсы интеграции приложений
•
Сервисные функции (DB)
•
Message bus
•
Протоколы Control Plane
•
Протоколы South Boundк инфраст-ре
•
Интерфейс приложения
•
Логика управления Control Plane
•
Взаимосвязиприложения

Различие между приложением и платформой контроллера
Контроллери инфраструктура разделены
Вертикально интегрированнаяплатформа
•
Приложениеможет быть реализовано
как интегрированное (например APIC)
или
на основе открытой платформы контроллера (например Data Broker).
•
Множество сетевых приложений управления связано с необходимостью решать различные задачи управления сетевой инфраструктурой.
•
Выбор платформы контроллера для приложения определяется возможностями платформы.
Сетевое приложение контроллера
Сетевое приложение контроллера
Платформа
Контроллера
Интегрированное приложение управления–например APIC
Приложение для платформы контроллера, например Data Broker
Сетевое устройство
Сетевое устройство

Способы взаимодействия контроллеров и оркестраторов
•
Оркестраторы настраивают устройства через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
Policy
DataPlane
L2/L3 Connectivity
Control
Plane
Оркестратор
Приложение, использующее оркестратор
Платформаоркестрации
Device
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
Control
Plane
Device
Policy
DataPlane
L2/L3 Connectivity
Management
Plane
Control
Plane
Платформаконтроллера
SDN Controller
Management
Plane

Модели взаимодействия контроллеров/оркестраторов/ сети
Edge
Policy
Распределенная модель -напримерBGP, IGP
•
Система оркестрацииопределяет конфигурацию устройств доступа, которые в свою очередь анонсируют доступность через протоколы маршрутизации
Система Оркестрации/Приложение
Control Plane
DataPlane
L2/L3 Connectivity
Management Plane
NetConf/YANG
Core
Policy
Control Plane
DataPlane
L2/L3 Connectivity
Management Plane
Core
Policy
Control Plane
DataPlane
L2/L3 Connectivity
Management Plane
i- BGP
i- BGP
Policy
Control Plane
L2/L3 Connectivity
Management Plane
BGP RR
i- BGP
Коммутатор
Push –например XNC/Data Broker
•
Сетевое состояние проактивноспускается на сетевые устройства при создании новых правил в приложении
Policy
Control Plane
L2/L3 Connectivity
Management Plane
RESTCONF
DataPlane
Management Plane
OpenFlow
XNC
controller
Control Plane
Pull –например ACI, LISP
•
Сетевое состояние передается на устройства доступа по запросу (реактивно)
Mapping server
APIC
Контроллер
Policy
L2/L3 Connectivity
DataPlane
Management Plane
Control Plane
OpFlex

План презентации
•
Что означает Software-definedNetworking(SDN)?
•
•
Контроллеры SDN и Оркестраторы
•
-
NETCONF/YANG, RESTCONF
-
OpenFlow
-
OpFlex
•
Контроллеры SDN и приложенияCisco
-
XNC
-
APIC

Программные Интерфейсы по категориям
Настройка
Управление
Программные расширения
DevOps
Интеграция
NETCONF
YANG
BGP-LS
PCEP
OpFlex
Cisco
Python API
BGP Flowspec

Приложения, Системы Управления, Контроллеры, ...
Device
Forwarding
Control
Network Services
Orchestration
Management
…
…
OpenFlow
OpenFlow
Operating Systems –IOS / NX-OS / IOS-XR
API (OnePK) and Data Models (YANG)
OpenStack
Puppet
OnePKC/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>
HTTPGET
Get configuration (like “show run”)
<edit-config>
HTTP PATCH
Edit configuration (like“conft” and then “commit”)
<edit-config>operation=“delete”
HTTPDELETE
Delete configuration (eg. like “no intloo1”)
<edit-config> operation=“create”
HTTP POST
Create configuration (eg. like “inttunnel-te1 …”)
<edit-config> operation=“replace”
HTTP PUT
Replace configuration
…
•
NETCONF (RFC6241) –для сетевого сообщества
-
работает поверх SSH илиTLS –пример сессииNETCONF: ssh–s admin@r1.net.com -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
(remoteaccess)
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)
+--rwinterfaces
| +--rwinterface* [name]
| +--rwname string
| +--rwdescription? string
| +--rwtype identityref
| +--rwenabled? boolean
| +--rwlink-up-down-trap-enable? enumeration
+--rointerfaces-state
+--rointerface* [name]
+--roname string
+--rotype identityref
+--roadmin-status enumeration
+--rooper-status enumeration
+--rolast-change? yang:date-and-time
+--roif-index int32
+--rophys-address? yang:phys-address
+--rohigher-layer-if* interface-state-ref
+--rolower-layer-if* interface-state-ref
+--rospeed? yang:gauge64
+--rostatistics
+--rodiscontinuity-time yang:date-and- time
+--roin-octets? yang:counter64
+--roin-unicast-pkts? yang:counter64
+--roin-broadcast-pkts? yang:counter64
+--roin-multicast-pkts? yang:counter64
+--roin-discards? yang:counter32
...
ietf-interfaces.yang–YANG module example
containerinterfaces{
description"Interface configurationparameters.";
list interface{ key"name“;
leafname{ type string; }
leafdescription{ type string; }
leaftype{
type identityref{
base interface-type;
}
mandatorytrue;
}
l eafenabled{
type boolean;
default "true";
}
leaf link-up-down-trap-enable {
if-feature if-mib;
type enumeration {
enumenabled { value 1; }
enumdisabled { value 2; }
}
}
}
}
c ontainer interfaces-state {
configfalse;
description
"Data nodes for the operational state of interfaces.";
list interface { key "name";
...
getreply–XML-encodedYANG data example
<?xmlversion="1.0" encoding="UTF-8"?>
<rpc-replymessage-id=“9“
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0“>
<data>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf- interfaces“>
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<enabled>false</enabled>
</interface>
</interfaces>
<interfaces-state
xmlns="urn:ietf:params:xml:ns:yang:ietf- interfaces“>
<interface>

Device
Forwarding
Control
Network Services
Orchestration
Management
…
…
OpenFlow
OpenFlow
OpenStack
Puppet
OnePKC/Java
Puppet
Neutron
Protocols
Python
NETCONF
REST
ACI Fabric
OpFlex
onePK Plug-Ins
RESTful
YANG
JSON/XML

“…открытый стандарт, определяющий взаимодействие междуразделёнными уровнями управления (контроллер) и передачи данных (агент)…”
Источник: www.openflow.org
Openflow
Чтотакое OpenFlow?

FLOW
TABLE 1
SWITCH FORWARDING ENGINE
Контроллер OPENFLOW
(например OpenDaylight/Cisco XNC)
CPU
GROUP
TABLE (1.1)
FLOW
TABLE 2
FLOW
TABLE n
FLOW METER
TABLE (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…)
-AsyncMessages (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)
Ingress
Port
Source
MAC
Dest
MAC
Ether
Type
VLAN
ID
VLAN
Priority
IPSRC
IPDEST
IPProtocol
IPTOS
TCP/UDP
SRC
ICMP Type
TCP/UDP
DEST
ICMP Code
MPLS
Label
MPLS
Traffic
Class
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
OpenStack
Puppet
OnePKC/Java
Puppet
Neutron
Protocols
Python
NETCONF
REST
ACI Fabric
OpFlex
onePK Plug-Ins
RESTful
YANG
JSON/XML

Решаемая проблема: микроуправлениеинфраструктурой
•
На сегодня сети –это среды, требующие детального конфигурирования
•
Требования пользователей, инфраструктуры и политик сопровождения зачастую противоречат друг другу
•
Это порождает большие проблемы с масштабируемостью, повышает отказы и снижает совместимость
•
Доступные на сегодня протоколы SDN не решают проблему микроуправления

Пример: Сконфигурировать сеть на сервере
Элементы
Control System
Админ
“Развернуть приложение X”
“Trunk vlan”
“Настроить ACL”
“Добавить маршрут…”
Система управления/пользователь передает конфигурацию на устройства.
Императивный контроль
Запрос пользователя разделяется на множество конечных команд, связанный с настройкой конкретной инфраструктуры

Императивный контроль –в чем недостатки
Недостатки систем с императивным контролем (OpenFlow+ OVSDB):
-
Централизованное управление SDN плохо масштабируется –все сетевые устройства должны зарегистрироваться на контроллере.
-
Большой домен отказа.
-
Система управления должна знать возможности всех устройств –точное описание управляемых объектов с использованием низкоуровневых сетевых функций.
-
Задействуется небольшой набор функционала для достижения приемлемой масштабируемости в решениях SDN первого поколения.
Modular 1
Modular 2
Vendor 1
Vendor 2
Hypervisor vSwitches
В случае императивного подхода все эти устройства должны выглядеть одинаково
Ограничение функционала сдерживает развитие

Решение: Декларативный контроль
Элементы
Control System
Админ
Отказы
“Мои Веб серверы должны взаимодействовать с моими серверами приложений”
“РазрешитьХостуA взаимодействовать с ХостомB”
“Исполняю”
Сделаны соответствующие изменения
-
Администратор создает политики на основе абстрактных элементов
-Создаваемые абстрактные политикинапрямую передаются на инфраструктуру
-Инфраструктура самостоятельно интерпретирует политики в соответствии со своими возможностями и производит изменение конфигурации

SDN или нет?
Императивный контроль
Элементы
Control System
Админ
Декларативный контроль
Policy Manager
Control Plane + Data Plane
APIC
SDN Controller
Policy Manager + Control Plane
Data Plane
OpenFlow+ OVSDB
OpFlex
OpFlex-новый расширяемый протокол описания политик, разработанный для декларативного управления любой инфраструктурой ЦОД.

OpFlex-как это работает
Конечное устройство интерпретирует политику и сопоставляет со своими аппаратными возможностями
POLICY
APIC
APIC управляет логической моделью желаемого состояния
HARDWARE
PORTS, VLANS, INTERFACES
SUBSETOFPOLICY
4
Интерпретация
политики
Обновление политики
Запрос политики
3
2
1
Интерпретация может в том числе использовать программные интерфейсы включая OVSDB, OpenFlowили собственный APIустройства

Cisco eXtensibleNetwork Controller (XNC)

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

OpenDaylightКонтроллер:базовые функции
Базовая инфраструктура
GUI
OpenDaylightКонтроллер
Локальная
Аутентификация
Southbound APIs
OF 1.x
Сетевые устройства
Northbound APIs
OSGI
RESTful
Forwarding Rules Manager
DijkstraSPF
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
DijkstraSPF
L3Interface
Расширенная инфраструктура
Java Bundle
H/A
Сетевые устройства
OF 1.x
OnePK*
Поиск неисправностей
Функционал продуктивных сетей
Встроенные приложения: Network Slicing,
Custom Forwarding и Data Broker
Cisco GUI с расширенными функциями
Service Abstraction Layer (SAL)
Динамические сетевые плагины
Расширенная аналитика и сервисы через Cisco API
Аутентификация
Monitor Manager
Topology Independent Forwarding (TIF)
Приложения Контроллера
Slice Manager
Расширенные компоненты
Cisco GUI
Cisco XNC
Northbound APIs
OSGI
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
Копия трафика из продуктивной сети
Я хочу передать веб трафикна систему сетевого анализа…
анализа

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
VM
VM
10.2.4.7
VM
10.9.3.37
VM
10.32.3.7
VM
VM
APIC

Итого
Device
Forwarding
Control
Network Services
Orchestration
Management
…
…
OpenFlow
OpenFlow
OpenStack
Puppet
OnePKC/Java
Puppet
Neutron
Protocols
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.

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

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

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

More from Cisco Russia

More from Cisco Russia (20)

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