Развитие технологий построения распределенных ЦОД

Развитие технологий построения
распределенных ЦОД
Хаванкин Максим
cистемный архитектор, CCIE
mkhavank@cisco.com
23.11.15 © 2015 Cisco and/or its affiliates. All rights reserved.

В этой презентации отсутствуют
•  Основы
•  Подробный рассказ о технологиях или архитектурах
•  Аспекты объединения сетей хранения данных
•  Сценарии использования сервисных устройств
•  Примеры конфигурации
23.11.15 © 2015 Cisco and/or its affiliates. All rights reserved.2

Содержание
•  Развитие технологии OTV
•  Развитие технологии LISP
•  Аппаратные платформы для DCI – что нового
•  MP-BGP EVPN на основе VXLAN-туннелей для DCI
•  Использование ACI в распределенных ЦОД
•  Заключение

Развитие технологии OTV

Overlay Transport Virtualization (OTV)
§  Расширение L2 доменов по произвольной IP сети
§  Тёмная оптика, MPLS, IP VPN...
§  Поддержка нескольких ЦОД
§  Упрощение построения и эксплуатации
§  Простота интеграции в существующие сети
§  Настройка за несколько команд
§  Высокая надёжность
§  Изоляция доменов сбоев
§  Резервирование подключения
сайтов без дополнительных усилий
Простое и надежное решение для связи ЦОД

Overlay Transport Virtualization
•  Ethernet трафик инкапсулируется в IP: “MAC in IP”
•  Динамическая инкапсуляция с использованием таблицы маршрутизации MAC
•  Не строится Pseudo-Wire или туннель
Принципы работы протокола
Server 1
MAC 1
Server 2
MAC 2
OTV OTV
MAC IF
MAC1 Eth1
MAC2 IP B
MAC3 IP B
IP A IP B
Encap Decap
MAC1 à MAC2 IP A à IP B MAC1 à MAC2 MAC1 à MAC2
Взаимодействие между
MAC1 (site 1) и MAC2 (site 2)

Терминология
Edge Device
§  Реализует OTV функции
§  Уровень агрегации или ядра
§  Несколько OTV Edge Device на один ЦОД
(multi-homing)
Internal Interface
§  Интерфейс на Edge Device, который
«смотрит вниз» внутрь сети ЦОД
§  Принимает VLAN-ы, которые будут
распространяться OTV
§  Обычный интерфейс 2-го уровня
§  Специальная настройка «для OTV» не требуется
§  Поддерживается IPv4 и IPv6
7
OTV устройства и интерфейсы
Core Device
OTV Edge
Device
OTV Internal Interface
OTV Join Interface
Aggregation Device
OTV Overlay Interface
OTV Edge
Device
OTV Internal
Interfaces

Терминология
Join Interface
§  Интерфейс, которым Edge Device
подключается «наверх»
§  Маршрутизируемый интерфейс point-to-point
(поддерживаются - physical, sub-interface
или port-channel)
§  Используется для физического «присоединения»
к оверлейной сети
§  Специальная настройка «для OTV» не требуется
§  Только IPv4
Overlay Interface
§  Виртуальный интерфейс с основной OTV конфигурацией
§  Логический интерфейс типа multi-access с поддержкой multicast
§  Инкапсулирует L2 фреймы в IP unicast или multicast
8
OTV устройства и интерфейсы
Core Device
OTV Edge
Device
OTV Internal Interface
OTV Join Interface
Aggregation Device
OTV Overlay Interface
OTV Join
Interface
Overlay Interface

Транспортная
инфраструктура
OTV OTV OTV OTV
MAC TABLE
VLAN MAC IF
100 MAC 1 Eth 2
100 MAC 2 Eth 1
100 MAC 3 IP B
100 MAC 4 IP B
MAC 1 è MAC 3
MAC TABLE
VLAN MAC IF
100 MAC 1 IP A
100 MAC 2 IP A
100 MAC 3 Eth 3
100 MAC 4 Eth 4
Layer 2
Lookup
6
IP A è IP B
MAC 1 è MAC
3
MAC 1 è MAC 3Layer 2
Lookup
2
Encap
3
Decap
5
MAC 1 è MAC 3
West
SiteServer 1 Server 3
East
Site
4
7
IP A IP B
1
IP A èIP BMAC 1 è MAC 3
Передача данных в OTV
9
Передача пакетов между ЦОД

Развитие технологии OTV
VXLAN Encapsulation
10
Использование VXLAN инкапсуляции
Underlay
Outer IP Header
Outer MAC Header
UDP Header
VXLAN Header
Original Layer-2 Frame
Overlay
50BytesofOverhead
•  Изначальный IETF драфт для OTV
•  Поддерживается только на F3-картах
•  Используется совместно с деполяризацией
туннелей
8 Bytes
Checksum 0x0000
UDP Length
VXLAN Port
Source
Port
16
16
16
16
8 Bytes
Reserved
VNI
Reserved
VXLAN Flags
RRRRIRRR
8
24
24
8
UDP 4789
Release 7.2

Доступ (вирт.)
Доступ (физический)
Распределение
Ядро (граница L2/L3)
Встраивание OTV в классическую
3-х уровневую топологию
•  Дизайн OTV On-a-Stick
•  OTV в отдельном VDC
•  vPC подключение OTV VDC
•  Один overlay интерфейс для лучшей
сходимости
•  Один internal интерфейс
•  Резервированное подключение
OTV
L2
L3
OTV
L2
L3

Spine (ядро)
Leaf (доступ)
Встраивание OTV в 2-х уровневую фабрику (на основе
MP-BGP VXLAN EVPN или ACI
RR RR
Edge Router
BorderLeaf
MP-BGP
Control Plane
L3
L2
OTV
L2
OTV
•  Подключение к border-leaf, а не к ядру/
агрегации
•  Граница L2/L3
•  Дизайн OTV On-a-Stick с теми же свойствами
•  отдельный VDC
•  vPC подключение
•  резервированное подключение
•  и т.д.
В ACI фабрике
peer-link межу
leaf-
коммутаторами
не нужен

Почему OTV чаще всего используют для организации L2-
связанности между ЦОД?
Простота
развертывания
и настройки
It Just WorksВсе компоненты
и аспекты под
контролем

Развитие технологии LISP

Оптимизация передачи трафика
§  Перемещение нагрузки между ЦОД создает проблемы с оптимальной
маршрутизацией
15
Проблема оптимальной маршрутизации
WAN
HSRP
Active
HSRP
Standby
HSRP Filter
HSRP
Active
HSRP
Standby
East-West /
Server-Server
Egress:
South-North /
Server-Client
Egress:
South-North /
Server-Client
Ingress:
North-South /
Client-Server
Ingress:
North-South /
Client-Server

Оптимизация передачи трафика
§  Логический или физический ЦОД?
§  Высокая доступность или защита от сбоев?
16
Какой способ выбрать?
WAN
East-West /
Server-Server
Egress:
South-North /
Server-Client
Egress:
South-North /
Server-Client
Ingress:
North-South /
Client-Server
Ingress:
North-South /
Client-Server
Это ОДИН логический ЦОД ?
(Высокая доступность - High Availability)
Или ДВА физически
и логически …
… разделенных
ЦОД?

IP core
IPv4 или IPv6 адрес
устройства or IPv6
определяет и его
идентификатор (identity) и
местоположение (location)
Традиционная IP сеть
10.1.0.1 Когда устройство перемещается,
оно получает новый IPv4 или IPv6
адрес, который определяет и его
идентификатор (identity) и
местоположение (location)
20.2.0.9
IPv4 или IPv6
адреса устройств
определяют только
их идентификацию.
Когда устройство
перемещается, его IPv4 или
IPv6 адрес, определяющий
его идентификатор не
изменяется.
Сеть с поддержкой LISP
Loc/ID “Разделение”
IP core
1.1.1.1
2.2.2.2
Только местоположение
изменяется при переезде
10.1.0.1
10.1.0.1
Это его местоположение
Location Identity Separation Protocol
17
Что понимается под “Location” и “Identity”

Сайт без
LISP
East-DC
LISP сайт
IP сеть
ETR
EID-to-RLOC
mapping
5.1.1.1
5.3.3.3
1.1.1.1
5.2.2.2
10.3.0.0/24 10.2.0.0/24
West-DC
PITR
5.4.4.4
10.1.0.0/24
Сайт без
LISP
ITR S
D
DNS Entry:
D.abc.com A 10.2.0.1
1
10.1.0.1 -> 10.2.0.1
2
EID-preﬁx: 10.2.0.0/24
Locator-set:
2.1.1.1, priority: 1, weight: 50 (D1)
Mapping
Entry
3 Эта политика
контролируется
владельцем ЦОД,
который
устанавливает веса
10.1.0.1 -> 10.2.0.1
1.1.1.1 -> 2.1.1.1
4
10.1.0.1 -> 10.2.0.1
5
2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1
Передача пакетов в LISP
18
Как работает LISP?

Сайт без
LISP
East-DC
IP сеть
ETR
EID-to-RLOC
mapping
5.1.1.1
5.3.3.3
5.2.2.2
10.3.0.0/24 10.2.0.0/24
West-DC
PITR
4.4.4.4
Сайт без
LISP
S
D
DNS Entry:
D.abc.com A 10.2.0.1
1
192.3.0.1 -> 10.2.0.1
2
EID-Preﬁx: 10.2.0.0/24
Locator-Set:
Mapping
Entry
3
192.3.0.1 -> 10.2.0.1
4.4.4.4- > 2.1.2.1
4
192.3.0.1 -> 10.2.0.1
5
2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1
Передача пакетов в LISP
19
Что делать с не-LISP сайтами?

Роли LISP
•  Tunnel Routers – xTRs
•  Пограничные устройства
encap/decap
•  Ingress/Egress Tunnel
Router (ITR/ETR)
•  Proxy Tunnel Routers - PxTR
•  Граница между LISP и не-
LISP сайтами
•  Ingress/Egress: PITR, PETR
•  EID - RLOC Mapping DB
•  Отображение RLOC в EID
•  Распредленная база по
Map Server (MS)
Адресные пространства
•  EID = End-point Identifier
•  идентификатор конечного хоста
•  RLOC = Routing Locator
•  IP адрес маршрутизатора сети агрегации или ядра
Prefix Next-hop
w.x.y.1 e.f.g.h
x.y.w.2 e.f.g.h
z.q.r.5 e.f.g.h
z.q.r.5 e.f.g.h
Mapping
DB
ITR
ETR
Non-LISP
EID Space
EID Space
RLOC Space
EID RLOC
a.a.a.0/24 w.x.y.1
b.b.b.0/24 x.y.w.2
c.c.c.0/24 z.q.r.5
d.d.0.0/16 z.q.r.5
EID RLOC
a.a.a.0/24 w.x.y.1
b.b.b.0/24 x.y.w.2
c.c.c.0/24 z.q.r.5
d.d.0.0/16 z.q.r.5
EID RLOC
a.a.a.0/24 w.x.y.1
b.b.b.0/24 x.y.w.2
c.c.c.0/24 z.q.r.5
d.d.0.0/16 z.q.r.5
ALT
PxTR
Роли и адресные пространства в LISP
20
Какие компоненты вовлечены в передачу данных?

LISP Mapping Database
21
Основы – регистрация и ответы на запросы
West-DC East-DC
X Z
Y
Y
10.2.0.2
10.2.0.0 /16 10.3.0.0/16
Map Server / Resolver: 5.1.1.1
2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1
LISP сайт
ITR
10.2.0.0/16 -> (2.1.1.1, 2.1.2.1)
Database Mapping Entry (на ETR):
10.3.0.0/16 -> (3.1.1.1, 3.1.2.1)
ETR ETR ETR ETR
Map-Request10.2.0.1
Map-Reply
10.2.0.0/16 -> (2.1.1.1, 2.1.2.1)
10.2.0.0/16-> (2.1.1.1, 2.1.2.1)
Mapping Cache Entry (на ITR):

LISP Mapping Database
22
Отказоустойчивость БД
West-DC East-DC
X Z
Y
Y
10.2.0.2
10.2.0.0 /16 10.3.0.0/16
Map Server: 5.1.1.1 Map Server: 5.2.2.2
LISP Site
ITR
Mapping DB
Node Cluster
Map Resolver:9.9.9.9 (Anycast)
10.2.0.0/16 -> (2.1.1.1, 2.1.2.1)
10.3.0.0/16 -> (3.1.1.1, 3.1.2.1)
ETR ETR ETR ETR
Map-Request10.2.0.1
Map-Reply
10.2.0.0/16 -> (2.1.1.1, 2.1.2.1)
Нет специального протокола для
синхронизации состояния Map-серверов;
ETR должны зарегистрироваться на всех
Map серверах самостоятельно;
ITR посылает запрос на Anycast адрес
Map Resolver-а
10.2.0.0/16-> (2.1.1.1, 2.1.2.1)
Mapping Cache Entry (на ITR):
2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1

Обновление кэш записей - «map cach»
1.  Устройства ITR и PITR продолжают
передавать трафик в «старый» ЦОД
2.  «Старый» xTR пересылает сообщения
Solicit Map Request (SMR) любому узлу
(encapsulator) который шлет
инкапсулированный трафик, который
предназначен переехавшему хосту
3.  ITR посылает новый map request
4.  ITR получает map-reply нового ЦОД
5.  ITR обновляет свой Map Cache
Трафик перенаправляется в правильный
ЦОД
SMR сообщение является важным
элементом поддерживающим целостность
решения
23
West-DC East-DC
LISP-VM (xTR)
X Z
Y
Y
Mapping DB
10.2.0.2
10.2.0.0 /16 10.3.0.0 /16
A B C D
LISP сайт
ITR
10.2.0.2/32 – RLOC C,D
Map Cache @ ITR
10.2.0.0/16 – RLOC A,B
2.SMR
1.Трафикданных
4.MapReply

West-DC East-DC
не-LISP сайты
PITR
LISP сайт
IP сеть
EID
RLOC
LISP Encap/Decap
ITR Mapping DB
5.1.1.1
5.3.3.3
1.1.1.1
10.2.0.0/24
5.2.2.2
ETR
2.1.1.1 2.1.2.1
Маршрутизатор в филиале
ip lisp itr-etr
ip lisp ITR map-resolver 5.3.3.3
Устройства агрегации в ЦОД
ip lisp itr-etr
ip lisp database-mapping 10.2.0.0/24 2.1.1.1 p1 w50
ip lisp database-mapping 10.2.0.0/24 2.1.2.1 p1 w50
ip lisp ETR map-server 5.1.1.1 key s3cr3t
ip lisp ETR map-server 5.2.2.2 key s3cr3t
Пограничный маршрутизатор
ip lisp proxy-itr
ip lisp ITR map-resolver 5.3.3.3Серверы БД
ip lisp map-resolver
ip lisp map-server
lisp site west-DC
authentication-key 0 s3cr3t
eid-prefix 10.2.0.0/24
Как правило устройство выполняет обе роли
ITR/ETR чтобы обсуживать трафик в обоих
направлениях
Базовая настройка LISP
24

IP мобильность
Disaster Recovery
Cloud Bursting
Сценарии применения LISP
25
Перемещение с растягиванием
L2 сегментов между ЦОД
West-DC East-DC
не-LISP
сайт
IP сеть
Mapping DB
LISP-VM (XTR)
LAN Extension
LISP сайт
XTR
Компоненты приложения растянуты между
ЦОД
Перемещение без растягивания
L2 сегментов между ЦОД
West-DC East-DC
LISP сайт
Internet или
WAN
XTR
Mapping DB
DR Location
или Cloud
Provider DC
LISP-VM (XTR)
Все компоненты приложения в одном ЦОД
одновременно

Аппаратная поддержка LISP для N7x00
26
Новые аппаратные модули, поддерживающие LISP
•  F3 модули, поддерживают LISP начиная с NX-OS 7.2(0)D1(1)
•  M1-32 модули поддерживают LISP начиная с NX-OS 6.2(8)
Cisco
Nexus 7000/7700
N7K-M108X2-12L
N7K-M148GS-11
N7K-M148GS-11L
N7K-M132XP-12
N7K-M132XP-12L
Nexus 7700 F3 40G
N77-F324FQ-25
Nexus 7700 F3 100G
N77-F312CK-26
Nexus 7000 F3 40G
N7K-F312FQ-25
Nexus 7700 F3 10G
N77-F348XP-23
Nexus 7000 F3 100G
Nexus 7000 F3 10G
N7K-F348XP-25
+ 6 новых линейных карт с
поддержкой LISP начиная с
июня 2015 г.

LISP в Центре Обработки Данных
27
4 сценария использования
IP
Single-Hop (SH) Multi-Hop (MH) IGP Assist (SH или
MH)
Интеграция c фабрикой на
основе MP-BGP EVPN
SG: Encap/decap ✓ ✓ ✗ ✓
SG: LISP Signaling ✓ ✓ ✓ ✓
FHR: Move Detection ✓ ✓ ✓ ✗
FHR: Local Routing Fix-up ✓ ✓ ✓ ✗
SG
+FHR
SG
FHR
SG
Redistribute
LISP to IGP
Advertise
Host Routes

Доступ (вирт.) – L2
L2
Распределение – L2
Встраивание LISP в классическую 3-х уровневую топологию
•  Использование F3 карт на уровне ядра/агрегации (только F3 в VDC)
•  Совмещение роли L2/L3 границы и xTR/PxTR
•  Роль MR/MS на этих же устройствах
•  Распределение/доступ – любой Nexus в L2-режиме
Сценарий № 1 – Single Hope + FHR
OTV
L2
L3
OTV
L2
L3F3 F3
LISP-инкапсулированный
трафик

Технология LISP Multi-Hop
§  xTR не стоит на первой линии перед
нагрузкой
§  На МСЭ и SLB попадает трафик без
инкапсуляции
§  Существующие MCЭ и SLB не
поддерживают инспекцию трафика
инкапсулированного в LISP*
§  Разнесение LISP функций:
§  SG XTR à LISP регистрация/encap/decap
§  1st Hop router à детекция перемещений,
нотификация устройства XTR, proxy
default GWY
§  Устройство SG XTR LISP
регистрирует перемещения и
сообщает центральной БД MS/MR
29
Функции обнаружения и инкапсуляции разносятся между разными устройствами
L3 ядро
R1: First Hop (FH)
R3: Site GWY
XTR (SG)
“roamer”
(мобильная
нагрузка)
R2: FW (не-LISP)
СообщениеLISPEID-notify
LISP encap/decap
LISP сигнализация
Move Detection
Host route injection
Default GWY proxy
* Roadmap

(граница L2/L3)
Ядро – L3
•  Ядро
•  Nexus 7000/7700 - использование F3 карт - роль xTR/PxTR
•  Распределение
•  N9K, N7K, N5K (+l3)
•  Доступ
•  L2/L3 граница
•  роль обнаружения
•  F2, F2E, F3 карты в N7000, N7700
Сценарий № 2 – Multi-Hop
OTV
L2
L3
OTV
L2
L3
LISP-инкапсуляция
Сервисное
устройствоFHRОбнаружение FHR
SG SG

Использование /32 маршрутов
§  Сквозное решение только на
базе /32
§  LISP обеспечивает только
детектирование мобильной
нагрузки
§  LISP помогает протоколам
маршрутизации IGP сойтись
быстрее
§  IGP распространяет маршруты
изученные с помощью LISP
§  LISP инкапсуляция не
применяется в процессе
передачи данных
Функция LISP IGP Assist
L3 сеть
R1: FHR
“roamer”
(мобильная нагрузка)
Динамический
маршрут /32
устанавливается при
помощи LISP и затем
редистрибутируется
в IGP

Доступ (вирт.) – L2
L2
•  Ядро
•  Nexus 7000/7700 - использование F3 карт для детектирования
•  совмещение роли L2/L3 границы и LISP-детектора
•  роль MR/MS на этих же устройствах
•  Распределение/доступ
•  N9K, N7K, N56xx, N2K в L2-режиме
Сценарий № 3 – IGP Assist
OTV
L2
L3
OTV
L2
L3F3 F3
Трафик без LISP-
инкапсуляции
Редистрибуция
из LISP в IGP

Интеграция LISP с фабрикой на основе MP-BGP EVPN
•  Преимущества:
§  Оптимизация входящих потоков
трафика
§  Масштабирование пограничных
устройств
§  WAN/Multi-homing
•  Обнаружение хостов выполняется
фабрикой
•  Переезд хоста регистрируется в LISP
при помощи получения eBGP апдейтов
о хостовых /32 маршрутах с
измененными значениями
•  next-hop и sequence
•  Использование данных MP-BGP в LISP
§  VXLAN EVPN (Standalone)
§  VPNv4
33
WAN
SG
Протокол
фабрики
(например
BGP)
LISP
Мобильность средствами фабрики:
Детектирование перемещения
Local Routing Fix-up
BGP host advertisement
Site Gateway (SG):
LISP encap/decap
LISP signaling
Филиал

1.  Хост подключается к фабрике
2.  VTEP сообщает MAC адрес и IP адрес хоста другим VTEP-ам посредством
BGP RR
NLRI:
•  Host MAC1, IP1
•  NVE IP 1
•  VNI 5000
Атрибут Ext. Community:
•  Encapsulation: VXLAN, NVGRE
•  Cost/Sequence VNI 5000
MAC IP VNI Next-
Hop
Encap Seq
1 1 5000 IP1 VXLAN 0
Host 1
VLAN 10
Распространение информации о хостах
34
MP-BGP EVPN – подключение хоста к фабрике
Leaf
SpineRR RR
VTEPVTEPVTEPVTEP

1.  Хост перемещается за VTEP-3
2.  VTEP-3 обнаруживает Host1 и шлет BGP-апдейт с увеличенным на единицу значением поля seq
3.  VTEP-1 обнаруживает более новый маршрут и удаляет свой предыдущий анонс /32 маршрута
MAC IP VNI Next-Hop Encap Seq
1 1 5000 IP1 VXLAN 0
1 1 5000 IP3 VXLAN 1
1 1 5000 IP3 VXLAN 1
Leaf
SpineRR RR
NLRI:
•  Host MAC1, IP1
•  NVE IP 1
•  VNI 5000
Атрибут Ext. Community:
•  Encapsulation: VXLAN, NVGRE
•  Cost/Sequence Host 1
MAC1
IP 1
VLAN 10
VXLAN 5000
Хост перемещается
35
MP-BGP EVPN - детектирование переезда
VTEP-4VTEP-3VTEP-2VTEP-1

E F G H
L5 L6 L7 L8
36
Распространение информации между сайтами
L3 Core
LISP
encap/decap
LISP
Registration/
Notifications L3 Core
LISP
encap/decap
“roamer”
(lands in a foreign
network)
Map-Register
iBGP Host Routes
Map-Notify
iBGP Host Routes
1
2
3
4
2
eBGP хостовые маршруты
с атрибутами
Sequence
передающимися
при помощи
Community
2
BGP AS 65001
BGP AS 65002
Map-System
Routing Table:
10.2.0.2/32 – L3, 65001
10.2.0.2/32 – Local
Routing Table:
10.2.0.2/32 – L3, 65001
10.2.0.2/32 – L6, 65002
Routing Table:
10.2.0.2/32 – Local
10.2.0.2/32 – L6, 65002
Routing Table:
10.2.0.2/32 – L3, 65001
10.2.0.2/32 – L6, 65002
10.2.0.2/32 – Null0-LISP
Map-Register
10.2.0.2/32 <E-H>
10.2.0.2/32 – RLOC A,B,C,D
10.2.0.2/32 – RLOC E,F,G,H
Map-Notify
10.2.0.2/32 <E-H>
BGP
withdraw
BGP
withdraw
L1 L2 L3 L4
A B C D

Встраивание LISP в MP-BGP EVPN фабрику
Leaf (граница L2/L3)
Spine (xTR, MS/MR)
LISP /32
мониторинг
F3 F3
LISP-инкапсулированный
трафик
•  Уровень Spine
•  Nexus 7000/7700 - использование F3 карт для детектирования
•  Уровень Leaf
•  N9K (MP-BGP EVPN)
•  Уровень филиала
•  Устройство с поддержкой
LISP-инкапсуляции

Аппаратные платформы для DCI – что нового

Семейство коммутаторов Cisco Nexus 7700
26RU
14RU
9RU
Cisco Nexus® 7700
10-слотов
Cisco Nexus® 7700
18-слотов
Cisco Nexus® 7700
6-слотов
100G плотность
40G плотность
1G / 10G плотность
192
384
768
96
192
384
48
96
192
12
24
48
3RU
Cisco Nexus® 7700
2-слота
Рекомендуется для DCI
сценариев

Cisco Nexus 7702
Самый компактный коммутатор с полным арсеналом DCI-функциональности

Безопасность
MACSec для DCI
Cisco TrustSec – SGT, SXP,
и SGACLs
Control Plane Policing
Модульный коммутатор Cisco Nexus 7702
Знакомое
управление
Один и тот же NX-OS
на всех
Nexus 7000 и 7700
Оптимизирован для
небольших сетей
ядра и агрегации
Богатый набор Layer 2 и
Layer 3 функций
(VDC, FEX, VPC, FabricPath)
Спроектирован для DCI
Исключительный набор DCI
функционала
(OTV, LISP, MPLS L2/L3 и
VXLAN)
Модульность
Поддержка Nexus
7700 Sup2E, F3, и
блоков питания.
Сервисные
устройства
Идеален для ITD
и RISE сервисов
Cisco Nexus 7702
DCI функциональность

Nexus 7702
Поддерживаемые линейные карты
3KW AC & DC модули блоков
питания
F3 I/O модули
Модули супервизора 2E
Вентиляторный модуль –Variable Speed Fans
I/O модуль Плотность портов
F3-10G 48p 1G/10G
F3-40G
24p 40G или
76p 10G (breakout) + 5p 40G
F3-100G 12p 100G
Поддержка Nexus 7700 Sup2E, F3-Series модулей (10 / 40 / 100G) и AC/DC блоков питания

Поддержка DCI функций на картах F3
MPLS (F3 паритет по
функциям с M2/M1)
•  MPLS-OAM
•  MPLS QoS
•  MPLS L2 VPN & VPLS
•  Inter-AS Option A and Option B lite
MPLS (Новый
функционал F3/M2/M1)
•  Inter-AS option B Full
•  BGP-3107 (Label Allocation for IPv4 family)
LISP (F3 паритет по
•  ITR
•  ETR
•  VM Mobility
•  Selective VRF
OTV (Новый
функционал F3/M2/M1)
•  OTV over IP/UDP
MPLS (F3 паритет по
•  MPLS forwarding
•  LDP signaling
•  Layer-3 VPNs
•  Export Import of routes between VRFs
•  PE-CE routing support
•  MPLS TE with Fast Re-Route
•  Multicast VPN for IPv4
•  6PE/6VPE
•  Новый код 7.2 для коммутаторов Nexus 7000/7700

MP-BGP EVPN на основе VXLAN-туннелей
для DCI

Использование VXLAN в распределенных ЦОД
Режим flood-and-learn – не рекомендуется для DCI применений
Доступ – L2
Ядро/агрегация – L2/L3 граница
V1
V2 V3
V4
•  Классическая схема организации сети ЦОД
•  Подключение к устройствам L2/L3 границы
по L2 (back-to-back vPC)
•  Требуется поддержка multicast на L3 каналах
между ЦОД
•  Сходимость
•  Отсутствие механизмов балансировки
•  Опора только на data-plane
•  Отсутствует control-plane управляющий
распространением информации о L2-
подключениях
•  Отсутствие встроенной защиты от L2-
петель

Режим MP-BGP EVPN – одна фабрика на два ЦОД
Leaf L2/L3 граница
Spine
V3
V4 V5
V6
•  VXLAN MP-BGP фабрика растянутая на две
площадки
•  Для связи между ЦОД выделяются транзитные
коммутаторы
•  Опора на MP-BGP EVPN control-plane, который
распространяет информацию о L2
•  Один домен сбоя, распространяющийся на два
ЦОД
•  Большое количество физических каналов
(лямбд) для организации отказоустойчивого
подключения
•  Валидированный дизайн не доступен
•  Технология изначально не
предназначалась для использования в DCI
сценариях
RR RR
V1
V1 V8
V7
Transit leaf Transit leaf

Режим MP-BGP EVPN – две независимые фабрики
Доступ – L2
Ядро/агрегация – L2/L3 граница
V1
V2 V3
V4
•  Классическая схема организации сети ЦОД
•  Подключение к устройствам L2/L3 границы
по L2 (back-to-back vPC)
•  Опора на MP-BGP EVPN control-plane,
который распространяет информацию о L2
•  Более сложная по сравнению с OTV
настройка
•  Отсутствие встроенной защиты от L2-
петель и механизмов балансировки
•  Валидированный дизайн не доступен
•  Технология изначально не
предназначалась для использования в DCI
сценариях
RR RR

Использование ACI в распределенных ЦОД

Один кластер APIC Cluster и домен Несколько кластеров APIC и доменов
Site 1 Site 2
ACI Фабрика
Растянутая (stretched) фабрика
POD ‘A’ POD ‘B’
Web/AppDB Web/App
APIC кластер
Multi-POD (План)
IP сетьSite ‘A’ Site ‘B’
MP-BGP - EVPN
Web
DB App
Multi-Site (План)
MP-BGP - EVPN
ACI фабрика 2ACI фабрика 1
Dual-Fabric Connected (L2 and L3 Extension)
DB Web
App
L2/L3

•  Фабрика растягивается на два ЦОД à
выглядит как одна фабрика
•  Один кластер APIC à одна точка управления
и настройки
•  Anycast GW на всех коммутаторах доступа
Растянутая (stretched) ACI фабрика
Основные характеристики
DC Site 1 DC Site 2
APIC APIC APIC
Растянутая фабрика
•  Требуется один или более transit leaf на ЦОД
à любой коммутатор leaf может взять на
себя роль «transit leaf»
•  Число транзитных коммутаторов и
количество каналов определяется
требованиями отказоустойчивости и
производительности
vCenter
Server

Transceivers Cable Distance
QSFP-40G-LR4 10 km
QSFP-40GE-LR4 10 km
QSFP-40GLR4L 2 km
QSFP-40G-ER4 30 km in 1.0(4h) or earlier
40 km in 1.1 and later (planned)
Все трансиверы требуют использования одномодового
оптического кабеля SMF
DC Site 1 DC Site 2
APIC APIC APIC
Вариант № 1 – использование темной оптики
vCenter
Server

10ms RTT
•  DWDM обеспечивает физическую связанность между ЦОД
•  SR трансивер и MTP-LC breakout cable для подключения ACI к DWDM системе
•  ПО 1.0(3f) или более позднее, максимально 10ms RTT между площадками
DC Site 1 DC Site 2
APIC APIC
Node ID 1 Node ID 2
Node ID 3
APIC
4x10 DWDM
QSFP-40G-SR4
MTP-LC
breakout cable
40G
40G
40G
40G
Вариант № 2 – использование DWDM

§  Внешние устройства с поддержкой EoMPLS
используются для растягивания фабрики ACI на
большие расстояния
Минимальная скорость физических каналов между
ЦОД – 10G
К Leaf/Spine коммутатору должен обязательно
подключаться 40G интерфейс
10 ms RTT
800 KM
DC Site 1 DC Site 2
APIC APIC
Node ID 1 Node ID 2
Node ID 3
APIC
QSFP-40G-SR4
40G
40G 40G
10G (и больше)
10G (и больше)
40G
EoMPLS Pseudowire
WAN
Вариант № 3 – Ethernet over MPLS (EoMPLS)
§  1.0(3f) и более поздний, 10ms max RTT между
ЦОД
10 ms позволяет разносить ЦОД на расстояние до
800 Km друг от друга
Другие порты на маршрутизаторах могут
использоваться для L3Out соединений

•  Одинаковые IS-IS метрики для соединений между ЦОД и внутри
•  Когда WAN маршрутизатор подключается к транзитному коммутатору (transit
leaf) оба пути из фабрики наружу эквивалентны (2-way ECMP)
•  Один L3Out на два пограничных коммутатора
DC Site 1
DC Site 2
APIC
ACI фабрика
APIC APIC
WAN
vCenter
Server
Транзитный и пограничный коммутаторы – проблема при совмещении ролей

•  Рекомендация: Не подключать WAN маршрутизатор к транзитному
коммутатору
•  Локальный WAN маршрутизатор на расстоянии 2 хопа
•  WAN маршрутизатор на удаленном сайте на расстоянии 4 хопа
DC Site 1
DC Site 2
APIC
ACI Fabric
APIC APIC
WAN
vCenter
Server
Транзитный и пограничный коммутаторы не рекомендуется совмещать
Следствие: минимум по 4 коммутатора
Leaf в каждой части растянутой фабрики

DC Site 1 DC Site 2
APIC
ACI фабрика
APIC APIC
WAN
•  MP-BGP используется для распространения внешних маршрутов по
ACI фабрике
•  Текущая версия ПО поддерживает два BGP RR
•  Рекомендация: размещать RR по одному в каждом ЦОД
MP-BGP
RR
MP-BGP
RR
vCenter
Server
Размещение MP-BGP Route Reflector

DVS
Интеграция с VMM – поддерживается сейчас
DC Site 1 DC Site 2
APIC APIC APIC
•  Один DVS растянутый между двумя сайтами
•  Один vCenter для управления vSphere-
хостами на двух сайтах
•  Живая миграция поддерживается
vCenter
Server
•  Планируется поддержка миграции между DVS (при
интеграции с vSphere 6.0)
•  Возможность разделить ESXi хосты на два
логических ЦОД (внутри vCenter)

DVS1
Интеграция с VMM – планируемый сценарий № 1 (конец 2015 г.)
DC Site 1 DC Site 2
APIC APIC APIC
vCenter
Server
DVS2

DVS1
Интеграция с VMM – планируемый сценарий № 2 (конец 2015 г.)
DC Site 1 DC Site 2
APIC APIC APIC
vCenter
Server 1
DVS2
vCenter
Server 12

Один кластер APIC Cluster и домен Несколько кластеров APIC и доменов
Site 1 Site 2
ACI Фабрика
Растянутая (stretched) фабрика
POD ‘A’ POD ‘B’
Web/AppDB Web/App
APIC кластер
Multi-POD (План)
IP сетьSite ‘A’ Site ‘B’
MP-BGP - EVPN
Web
DB App
Multi-Site (План)
MP-BGP - EVPN
ACI фабрика 2ACI фабрика 1
Dual-Fabric Connected (L2 и L3 Extension)
DB Web
App
L2/L3

Объединение двух фабрик (dual fabric)
Шлюз по умолчанию - вариант № 1 уникальные адреса (MAC IP)
vCenter
Server
ESX ESX
vCenter
Server
ESX ESX
ACI Fabric 1 ACI Fabric 2
1.1.1.10 2.2.2.10
1.1.1.20 2.2.2.20
APIC APIC
GW IP: 1.1.1.1
MAC: MAC-A
BD1
GW IP: 2.2.2.1
MAC: MAC-A
BD2
GW IP: 1.1.1.2
MAC: MAC-B
BD1
vCenter
Server
GW IP: 2.2.2.2
MAC: MAC-B
BD2
•  Поддерживается сегодня: разные Anycast GW IP и MAC на двух ACI фабриках
•  Active/Active маршрутизация
•  Живая миграция между сайтами не поддерживается
•  L2 связанность для работы приложений поддерживается

Шлюз по умолчанию - вариант № 2 - виртуальный адрес (MAC/IP) (конец 2015 г.)
•  Общий secondary IP and virtual MAC для общего шлюза по умолчанию
•  Поддерживаются любые способы объединения на уровне L2
•  dark fiber или L2 DCI
vCenter
Server
ESX ESX
vCenter
Server
ESX ESX
1.1.1.10 2.2.2.10
1.1.1.20 2.2.2.20
APIC APIC
vCenter
Server
BD2
Primary IP: 1.1.1.2
Secondary IP 1.1.1.1
MAC: MAC-A
VMAC: MAC-common
BD1
Primary IP: 1.1.1.3
Secondary IP 1.1.1.1
MAC: MAC-B
VMAC: MAC-common
BD1

APIC
•  Внутренний EPG растягивается (‘extended’) на удаленный ЦОД при помощи
отображения 1:1 на VLAN который передается через double-sided vPC
Более простой механизм по сравнению с L2Out
•  Отображение VLAN в EPG настраивается вручную и независимо на каждом APIC
контроллере
ACI Фабрика 1 ACI Фабрика 2
DCI
Статическое отображение 1:1 VLAN/EPG Статическое отображение 1:1 VLAN/EPG
L2-связанность

•  Раздельные L3Out-ы для подключения ко внешней WAN-сети (через МСЭ) для
маршрутизации между фабриками
•  OSPF peering между ACI Fabric/FW и FW/WAN Edge
•  EBGP peering между ЦОД и WAN
ACI Фабрика 1 ACI Фабрика 2
WAN
L3Out-DCI L3Out-DCI
L3Out-WAN
OSPF Area 0
L3Out-WAN
OSPF Area 0
EBGP
EBGPEBGP
DCI
L3-связанность

VMM Интеграция - Вариант № 1 – живая миграция не используется
VLAN
100
VLAN
100
VMM Domain: DC1
EPG WEB 100.1.1.0/24
VLAN
200
VLAN
200
VMM Domain: DC2
EPG WEB 100.1.1.0/24
Один L2 домен
Одна L3 подсеть
VLAN
300
•  Один vCenter (точнее один DVS)
управляются с одного APIC кластера à
VMM интеграция
•  По одному DVS на каждую ACI фабрику
•  L2 растянут между двумя фабриками
•  Живая миграция виртуальных машин не
используется
APIC APIC
ESX ESX
DVS1 DVS2
ESX ESX
vCenter
Server
vCenter
Server

VMM Интеграция - Вариант № 2 – поддержка миграции (конец 2015 г)
VLAN
100
VLAN
100
VMM Domain: DC1
EPG WEB 100.1.1.0/24
VLAN
200
VLAN
200
VMM Domain: DC2
EPG WEB 100.1.1.0/24
VLAN
300
•  По одному vCenter/DVS на каждую фабрику
•  VMM интеграция: vSphere 6 уже поддерживается ACI
•  Программное обновление в конце 2015 г. позволит обеспечить живую миграцию между двумя
Active/Active ЦОД
APIC APIC
ESX ESX
DVS1
DVS2
ESX ESX
живая миграция vSphere 6
vCenter
Server
vCenter
Server

Заключение

Выводы
•  Задача L2-связанности между ЦОД
•  OTV – самая лучшая технология на сегодняшний день
•  Задача оптимизации входящего пути трафика в ЦОД
•  LISP архитектура
•  Сквозная поддержка LISP в устройствах Cisco для WAN и ЦОД
•  Аппаратная платформа для DCI
•  Nexus 7000/7700 – весь арсенал DCI технологий в одном устройстве
•  Технологии объединения фабрик
•  Интенсивное развитие и разработка
•  Выбор из протестированных сценариев

CiscoRu Cisco CiscoRussia
Ждем ваших сообщений с хештегом
#CiscoConnectRu
CiscoRu
Спасибо
Хаванкин Максим
cистемный архитектор, CCIE
mkhavank@cisco.com
© 2015 Cisco and/or its affiliates. All rights reserved.

Развитие технологий построения распределенных ЦОД

Развитие технологий построения распределенных ЦОД

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (13)

Semelhante a Развитие технологий построения распределенных ЦОД

Semelhante a Развитие технологий построения распределенных ЦОД (20)

Mais de Cisco Russia

Mais de Cisco Russia (20)

Último

Último (9)

Развитие технологий построения распределенных ЦОД