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

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

Хаванкин Максим cистемный архитектор, CCIE [email protected]

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 3 Layer 2 Lookup

2 Encap 3

Decap 5

MAC 1 è MAC 3 West Site Server 1 Server 3

East Site

4

7

IP A IP B

1

IP A èIP B MAC 1 è MAC 3

Передача данных в OTV

9

Передача пакетов между ЦОД

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

VXLAN Encapsulation

10

Использование VXLAN инкапсуляции

Und

erla

y

Outer IP Header

Outer MAC Header

UDP Header

VXLAN Header

Original Layer-2 Frame Ove

rlay 50

Byt

es o

f Ove

rhea

d

•  Изначальный 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

UDP4789

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


Ingress: North-South / Client-Server


Оптимизация передачи трафика

§  Логический или физический ЦОД? §  Высокая доступность или защита от сбоев?

16

Какой способ выбрать?

WAN

East-West / Server-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-RLOCmapping

5.1.1.1

5.3.3.3

1.1.1.1

5.2.2.2

10.3.0.0/2410.2.0.0/24

West-DC

PITR5.4.4.4

10.1.0.0/24


ITRS

D

DNSEntry:D.abc.comA10.2.0.1

1

10.1.0.1->10.2.0.12

EID-prefix: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.11.1.1.1->2.1.1.1

4

10.1.0.1->10.2.0.15

2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1

Передача пакетов в LISP

18

Как работает LISP?


East-DC

IP сеть

ETR

EID-to-RLOCmapping

5.1.1.1

5.3.3.3

5.2.2.2

10.3.0.0/2410.2.0.0/24

West-DC

PITR4.4.4.4


S

D

DNSEntry:D.abc.comA10.2.0.1

1

192.3.0.1->10.2.0.12

EID-Prefix:10.2.0.0/24

Locator-Set:



Mapping Entry

3

192.3.0.1->10.2.0.14.4.4.4->2.1.2.1

4

192.3.0.1->10.2.0.15

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



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) Database Mapping Entry (на ETR): ETRETR ETRETR

Map-Request 10.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) Database Mapping Entry (на ETR):

10.3.0.0/16 -> (3.1.1.1, 3.1.2.1) Database Mapping Entry (на ETR): ETRETR ETRETR

Map-Request 10.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. S

MR

1. Трафик

данных

4. Map Reply

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

L3 F3 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)

Сообщение

LIS

P E

ID-n

otify

LISP encap/decap LISP сигнализация

Move Detection Host route injection Default GWY proxy

* Roadmap

Доступ (физический) (граница L2/L3)


Ядро – L3


•  Ядро •  Nexus 7000/7700 - использование F3 карт - роль xTR/PxTR •  Роль MR/MS на этих же устройствах

•  Распределение •  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

L3 F3 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

Spine RR RR

VTEP VTEP VTEP VTEP

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

Spine RR 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-4 VTEP-3 VTEP-2 VTEP-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 карт для детектирования •  Роль MR/MS на этих же устройствах

•  Уровень Leaf •  N9K (MP-BGP EVPN)

•  Уровень филиала •  Устройство с поддержкой

LISP-инкапсуляции

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


Семейство коммутаторов Cisco Nexus 7700

26 R

U

14 R

U

9 R

U

Cisco Nexus® 7700 10-слотов



100G плотность 40G плотность

1G / 10G плотность

192 384

768

96 192

384

48 96

192

12 24

48

3 R

U

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 сервисов

Ani

mat

ed S

lide

!

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 блоков питания

Ani

mat

ed S

lide

!

Поддержка 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 паритет по функциям с M2/M1) •  ITR •  ETR •  VM Mobility •  Selective VRF

OTV (Новый функционал F3/M2/M1) •  OTV over IP/UDP

MPLS (F3 паритет по функциям с M2/M1) •  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 в распределенных ЦОД


Использование ACI в распределенных ЦОД Один кластер APIC Cluster и домен Несколько кластеров APIC и доменов

Site 1 Site 2 ACI Фабрика

Растянутая (stretched) фабрика

POD ‘A’ POD ‘B’

Web/App DB Web/App APIC кластер

Multi-POD (План)

IP сеть Site ‘A’ Site ‘B’

MP-BGP - EVPN

Web DB App

Multi-Site (План)

MP-BGP - EVPN

ACI фабрика 2 ACI фабрика 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 Transit leaf •  Требуется один или более 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



Растянутая (stretched) ACI фабрика Вариант № 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

Растянутая (stretched) ACI фабрика Вариант № 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

Растянутая (stretched) ACI фабрика Вариант № 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

Растянутая (stretched) ACI фабрика Транзитный и пограничный коммутаторы – проблема при совмещении ролей

•  Рекомендация: Не подключать WAN маршрутизатор к транзитному коммутатору

•  Локальный WAN маршрутизатор на расстоянии 2 хопа •  WAN маршрутизатор на удаленном сайте на расстоянии 4 хопа


ACI Fabric


APIC APIC

WAN

vCenter Server

Растянутая (stretched) ACI фабрика Транзитный и пограничный коммутаторы не рекомендуется совмещать

Следствие: минимум по 4 коммутатора Leaf в каждой части растянутой фабрики


ACI фабрика


APIC APIC

WAN •  MP-BGP используется для распространения внешних маршрутов по

ACI фабрике •  Текущая версия ПО поддерживает два BGP RR •  Рекомендация: размещать RR по одному в каждом ЦОД

MP-BGP RR

MP-BGP RR

vCenter Server

Растянутая (stretched) ACI фабрика Размещение MP-BGP Route Reflector

DVS

Растянутая (stretched) ACI фабрика Интеграция с VMM – поддерживается сейчас


•  Один DVS растянутый между двумя сайтами •  Один vCenter для управления vSphere-

хостами на двух сайтах •  Живая миграция поддерживается


vCenter Server

•  Планируется поддержка миграции между DVS (при интеграции с vSphere 6.0)

•  Возможность разделить ESXi хосты на два логических ЦОД (внутри vCenter)

DVS1

Растянутая (stretched) ACI фабрика Интеграция с VMM – планируемый сценарий № 1 (конец 2015 г.)





vCenter Server



DVS2

DVS1

Растянутая (stretched) ACI фабрика Интеграция с VMM – планируемый сценарий № 2 (конец 2015 г.) DC Site 1 DC Site 2

APIC APIC APIC




vCenter Server 1

DVS2

vCenter Server 12



Использование ACI в распределенных ЦОД Один кластер APIC Cluster и домен Несколько кластеров APIC и доменов

Site 1 Site 2 ACI Фабрика

Растянутая (stretched) фабрика

POD ‘A’ POD ‘B’

Web/App DB Web/App APIC кластер

Multi-POD (План)

IP сеть Site ‘A’ Site ‘B’

MP-BGP - EVPN

Web DB App

Multi-Site (План)

MP-BGP - EVPN

ACI фабрика 2 ACI фабрика 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 связанность для работы приложений поддерживается

Объединение двух фабрик (dual fabric) Шлюз по умолчанию - вариант № 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

Объединение двух фабрик (dual fabric) 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

EBGP EBGP

DCI

Объединение двух фабрик (dual fabric) L3-связанность

Объединение двух фабрик (dual fabric) VMM Интеграция - Вариант № 1 – живая миграция не используется

VLAN 100

VLAN 100

VMM Domain: DC1 EPG WEB 100.1.1.0/24

VLAN 200

VLAN 200


Один L2 домен Одна L3 подсеть

VLAN 300


•  Один vCenter (точнее один DVS) управляются с одного APIC кластера à VMM интеграция

•  По одному DVS на каждую ACI фабрику

•  L2 растянут между двумя фабриками •  Живая миграция виртуальных машин не

используется

APIC APIC

ESX ESX

DVS1 DVS2

ESX ESX

vCenter Server

vCenter Server

Объединение двух фабрик (dual fabric) VMM Интеграция - Вариант № 2 – поддержка миграции (конец 2015 г)

VLAN 100

VLAN 100


VLAN 200

VLAN 200


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 [email protected]

© 2015 Cisco and/or its affiliates. All rights reserved.

Technology

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