Связь распределённых ЦОД с использованием otv и lisp

Связь распределённых ЦОД с использованием OTV и LISP Скороходов Александр Системный инженер – консультант [email protected] +7(495)789-8615

«Растягивание» LAN: внутри и между ЦОД

§  Ряд приложений требуют смежности на 2 уровне § Кластеры (Veritas, MSFT) § vMotion § «Доморощенные» приложения

§  Миграция серверов

§  Высокая доступность

§  Распределенные служебные и прикладные сервисы

Data Center

A

Data Center

B

Связь ЦОД Требования к расширению подсетей

§  Изоляция STP: предотвращение распространения проблем

§  Предотвращение «зацикливания» между ЦОДами

§  Отказоустойчивость и масштабирование производительности

§  Поддержка многих сайтов

Intra-DC Domain with STP Isolation

Intra-DC Domain with STP Isolation

Core

Aggr/ Distr

Access

L3

L2

WAN

Data-center

WAN

Core

Aggr/ Distr

Access

L3

L2

WAN

Data-center

SAN SAN

No Inter-DC Loop

Same Extended VLAN

q  Защита от «петель» q  Изоляция STP q  Отказоустойчивость. q  Балансировка нагрузки

на WAN q  Прозрачность для

ядра q  Прозрачность для

сетей ЦОД q  Оптимизация трафика q  Масштабирование q  Связь многих ЦОД

Необходимо

Overlay Transport Virtualization (OTV)

Распределенные ЦОД Проблемы существующих решений

•  Сложно строить и эксплуатировать •  Зависимость от транпорта (MPLS, Dark fiber, etc.). •  Неэффективное использование полосы •  Сбои могут распространяться между ЦОД

Информация об адресах: flooding

x2

Site A

Site B

Site C

MAC 1 propagation MAC 1

§  Традиционные технологии выучивают MAC адреса с помощью flooding

§  Опора на flooding – потенциал для распространения сбоев

Кабели или Pseudo-Wires

§  Опора на full-mesh сеть кабелей, лямбд, или “pseudo-wire” сервисов

§  Для N объектов - N*(N-1)/2 соединений §  Для multicast и broadcast трафика – репликация на источнике

Резервирование подключения сайта

L2 Site L2 Site L2 VPN

Active Active

§  Необходимы дополнительные протоколы для выбора активного устроства/подключения

§  Опора на STP для управления альтернативными путями – опасно и ненадёжно!

Overlay Transport Virtualization (OTV) Простое и надежное решение для связи ЦОД

•  Расширение L2 доменов по произвольной IP сети – Тёмная оптика, MPLS, IP VPN... – Поддержка нескольких ЦОД

•  Упрощение построения и эксплуатации – Простота интеграции в существующие сети – Настройка за несколько команд

•  Высокая надёжность – Изоляция доменов сбоев – Резервирование подключения сайтов без дополнительных усилий

Any Workload, Anytime, Anywhere

OTV

Overlay Transport Virtualization Принципы работы протокола

•  Ethernet трафик инкапсулируется в IP: “MAC in IP” •  Динамическая инкапсуляция с использованием таблицы маршрутизации MAC

•  Не строится Pseudo-Wire или туннель

Communication between MAC1 (site 1) and MAC2 (site 2)

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

Элементы решения OTV •  Пограничное устройство (Edge Device)

– Реализует OTV, подключает сайт к траспортной сети – На сайте может быть несколько OTV Edge Devices

•  Внутренние интерфейсы – Интерфейсы Edge Devices внутрь ЦОД – Ведут себя как обычные интерфейсы L2 – Spanning tree BPDU обрабатываются как на обычных портах коммутатора

•  Внешние интерфейсы – Маршрутизируемые интерфейсы Edge Device в ядро.

– Используются для ргестрации в multicast группы OTV. – IP адреса используются для инкапсуляции

•  Интерфейс Overlay – Виртуальный интерфейс для –  связи сайтов – Не участвует в STP

OTV

Internal Interfaces

Core L2 L3

Join Interface

Overlay Interface

Транспортная сеть

OTV Data Plane: коммутация между ЦОД

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

IP A è 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

5 IP A è IP B MAC 1 è MAC 3 MAC 1 è MAC 3 Layer 2

Lookup

1 Encap 2

Decap 4

MAC 1 è MAC 3 West Site

MAC 1 MAC 3 East Site

1.  Поиск MAC адресата в таблице коммутации 2 уровня. MAC 3 достижим через IP B.

2.  Пограничное устройство инкапсулирует фрейм в IP пакет

3.  Транпорт доставляет пакет на второй сайт

4.  Пограничное устройство на втором сайте принимает и декапсулирует пакет

5.  Коммутация фрейма на 2 уровне. MAC 3 – локальный адрес

6.  Фрейм доставляется адресату

3

6

IP A IP B

Пополнение MAC таблиц OTV Control Plane

•  OTV проактивно анонсирует достижимость MAC (control-plane learning)

•  MAC адреса автоматически анонсируются в процессе рабты коммутатора, как только настроен OTV

•  Не требуется отдельная настройка

Core

IP A IP B

IP C

West East

South

MAC Addresses Reachability

OTV Control Plane Поиск других устройств и взаимодействие с ними

•  Взаимодействие c другими устройствами через multicast (предпочтительно) или unicast

West East

South

OTV

OTV Control Plane

OTV Control Plane

OTV Control Plane

OTV OTV

Транспорт не поддерживает multicast? В OTV есть решение: режим Adjacency Server

•  Использование multicast в ядре обеспечивает множество преимуществ:

– Сокращает число hello и update пакетов, которые должен формировать OTV – Упрощает обнаружение партнеров, доваление и удаление сайтов – Оптимизирует обработку broadcast и multicast трафика

•  Тем не менее, он доступен не всегда •  Adjacency Server Mode обеспечивает поддержку для траспортных сетей, поддерживающих только unicast

L2 L3

OTV OTV

Spanning Tree и OTV Независимость сайтов

•  OTV не влияет на STP топологию сайта •  У кажого сайта – свой домен STP, полностью независимый от других

•  Встроенная функциональность – настройка не требуется •  Edge Device посылает/принимает STP BPDUs только на внутренних интерфейсах

The BPDUs stop here

The BPDUs stop here

L2 L3

OTV OTV

Unknown Unicast и OTV Предотвращение flooding между ЦОД

•  OTV не опирается на flooding для того, чтобы узнавать MAC адесах на других сайтах

•  Любые unknown unicasts попадающие на OTV edge device не передаются в ядро. Это не требует дополнительной настройки.

•  Мы исходим из того, что оконечные устройства не являются «молчаливыми»

MAC TABLE

VLAN MAC IF 100 MAC 1 Eth1

100 MAC 2 IP B

- - -

MAC 1 è MAC 3

No MAC 3 in the MAC Table

Контроль ARP трафика ARP Neighbor-Discovery (ND) кеш

•  Каждое OTV edge device поддерживает ARP кеш, заполняемый в результате прослушивания ARP ответов

•  Первоначальные ARP запросы распространяются между сайтами, для последующих ответ формируется OTV Edge Device локально

•  Существенное сокращение ARP широковещания на магистрали

Transport Infrastructure

OTV

OTV

ARP Cache MAC 1 IP A

MAC 2 IP B

ARP reply

2

First ARP

request (IP A)

1

Snoop & cache ARP reply

3

Subsequent ARP requests

(IP A)

4 ARP reply on behalf of

remote server (IP A)

5

Резервирование подключения Authoritative Edge Device

•  OTV обеспечивает резервирование без «петель» за счёт выбора активного Edge устройства в каждой VLAN: Authoritative Edge Device (AED).

•  Edge устройства на сайте взаимодействуют по “site-vlan”, чтобы выбрать AED

OTV

OTV

AED

Internal peering for AED election

Настройка OTV Транспорт с поддержкой multicast

feature otv interface Overlay0 otv join-interface Ethernet1/1 otv control-group 239.1.1.1 otv data-group 232.192.1.0/24 otv extend-vlan 100-150 otv site-vlan 99 otv site-identifier 10

Интерфейс для подключения к транспортной сети. Его IP адрес используется как адрес источника при инкапсуляции OTV

ASM/Bidir группа для управляющего трафика OTV

SSM диапазон адресов для передачи multicast-трафика сайтов

VLAN, растягиваемые с помощью OTV

VLAN используемые внтури сайта для связи между пограничными устройствами Идентификатор сайта

Настройка OTV Unicast транспорт

feature otv interface Overlay0 otv join-interface Ethernet1/1 otv adjacency-server или otv use-adjacency-server 10.10.10.10 10.10.11.11 otv extend-vlan 100-150 otv site-vlan 99 otv site-identifier 10

Интерфейс для подключения к транспортной сети. Его IP адрес используется как адрес источника при инкапсуляции OTV

Конфигурирует устройство как Adjacency Server

Удалённые устройства, работающие как Adjacency Server (настройка, взаимно исключающаая с предыдущей)

VLAN, растягиваемые с помощью OTV

VLAN используемые внтури сайта для связи между пограничными устройствами Идентификатор сайта

•  Работа поверх любого транспорта (IP, MPLS)

•  Изоляция доменов сбоев •  Независимость сайтов •  Оптимальное использование полосы •  Встроенная отказоустойчивость •  Встроенная защита от «петель» •  Связь многих сайтов •  Масштабируемость

§  VLANs, сайты, MACs §  ARP, broadcasts/floods

•  Простота настройки •  Легкость добавления сайтов

Проблемы «растягивания» LAN Решаемые OTV

South Data

Center

North Data

Center

Fault Domain

Fault Domain

Only 6 CLI commands

LAN Extension

Fault Domain

Fault Domain

Оптимизация потоков трафика

Проблема оптимальной доставки

Pod A

WAN

Pod N

Ingress Routing Localization: Clients-Server

Server-Server

Egress Routing Localization: Server-Client Egress Routing Localization:

Server-Client

•  Расширение на 2 уровне – проблема для оптимальной маршрутизации

•  Проблема выбора расположения шлюза по умолчанию и анонсирования подсети в магистраль

Оптимальный путь В чём именно проблема?

Layer 3 Core

Access

Agg

Access

Agg

10.1.1.0/24 advertised into L3 Backup should main site go down

10.1.1.0/25 & 10.1.1.128/25 advertised into L3 DC A is the primary entry point

Node A

ESX ESX

Virtual Machine Virtual Machine

VMware vCenter

Data Center 1 Data Center 2

Оптимальный путь Хотелось бы так...

Access

Agg

Access

Agg

Node A

ESX ESX Virtual Machine

VMware vCenter

Data Center 1 Data Center 2

Оптимизация пути «на выход» Локализация FHRP с помощью OTV

•  Одна и та же HSRP группа на всех сайтах с теме виртуальным MAC адресом

•  Каждый сайт обеспечивает исходящую маршрутизацию •  OTV локализует исходящий трафик за счёт фильтрации HSRP hello сообщений между сайтами

•  ARP запросы перехватываются на OTV edge устройстве чтобть обеспечить ответы именно от локального шлюза

L2 L3

Active GWY Site 2

Active GWY Site 1

FHRP Hellos

FHRP Hellos ARP traffic is

kept local ARP traffic is kept local

West East

Оптимизация пути «на вход» Locator-ID Separation Protocol (LISP)

•  Отделяет идентификатор сервиса (IP адрес) от его местоположения

•  Маршрутизация исходя из местоположения, а не адреса хоста •  Соотношение адреса и его местоположение хранятся в директории

•  Поиск метоположения IP адреса по информации из директории •  Инкапсуляция трафика (IP in IP) и передача по месту нахождения хоста

•  Директория – распределенная база данных

ALT directory

Resolution & Registration Data Path

§  Информация о хостах не хранится в таблице маршрутизации

§  “Summarizable host routing”

Internet

IPv4 или IPv6 адрес служит и для

идентификации, и поиска месоположения

Стандартное поведение Loc/ID “совмещены”

x.y.z.1 При перемещении, устройство получает новый адрес

w.z.y.9

IPv4 или IPv6 адрес служит только для идентификации

При перемещении, устройство сохраняет адрес

Логика LISP Loc/ID “отделены”

Internet

a.b.c.1 e.f.g.7

Меняется только местоположение

x.y.z.1

x.y.z.1

Location Identity Separation Protocol Что подразумевается под “Location” и “Identity”?

Местоположение здесь!

LISP: инкапсуляция IPv4 RLOC используя IPv4 EID или IPv6 EID

•  Внешний заголовок тоже может быть IPv6 •  Инкапсуляция в UDP чтобы повысить эффективность балансировки нагрузки на магистральных линках (ECMP/Port Channel)

IPv4 Inner Header:

Host supplies EIDs

IPv4 Outer Header: Router supplies

RLOCs

LISP header

UDP

IPv6 Inner Header:

Host supplies EIDs

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

Non-‐LISP

EID Space

RLOC Space

Mapping System

xTR

EID Space

xTR xTR

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



MS/MR

PxTR

LISP: составные части решения Два пространства имен – EID и RLOC •  LISP – Элементы решения

§  EID (Endpoint IdenBfier) IP адрес хоста – «имя человека»

§  RLOC (RouBng Locator) IP адрес LISP роутера – «адрес человека»

§  Mapping Database System связывает EID и RLOC – «адресная книга» §  MS -‐ Map Server §  MR -‐ Map Resolver §  ALT – Alternate Topology

§  xTR – Ingress / Egress Tunnel Router

§  PxTR – Proxy Ingress / Egress Tunnel Router

•  LISP – уровень коммутации §  Запрос по требованию, кеширование ответа §  Динамическая инкасуляция §  Оверлей над транспортной сетью (только на

пограничных роутерах)

•  LISP – уровень управления §  Распределённая адресная база §  Map-Servers и Map-Resolvers §  LISP+ALT

Locator-ID Separation Protocol (LISP) Принцип работы

Prefix Route Locator (RLOC)

10.10.10.1 A, B

10.10.10.2 A, B … …

10.10.10.5 X, Y

10.10.10.6 X, Y …… …

Core

Pod A …

Ingress Tunnel Router (ITR)

Pod N

10.10.10.1 .2 .3 .4 .5 .6 .7 .8

A B X Y Egress TR (ETR)

Access

RLOCs:

Extended Subnet (10.10.10.0 /24)

EIDs:

Host IP = End-point ID

Router IP = Route Locator

1.  ITR консультируется с директорией, чтобы получить Route Locator (RLOC) для данного End-point ID (EID)

2.  ITR инкапуслирует трафик IPinIP и отправляет по адресу RLOC

3. ETR принимает и декапсулирует трафик

Dest = A Dest = 10.10.10.1

Dest = 10.10.10.1

Dest = 10.10.10.1

RLOC routes

only

§  Детальная информация о достижимости хостов

§  При миграции хоста информация отражается в директории

§  Информация об оконечных устройствах не хранится в таблицам маршрутизации

1 Encap

2

Decap

3

LISP: путь пакета

Non-‐LISP site

East-‐DC

LISP Site

IP Network

ETR

EID-‐to-‐RLOC mapping

172.16.1.1 172.16.2.1

1.1.1.1

3.3.3.3

172.16.10.1

2.2.2.2

10.2.0.0/24

172.16.3.1 172.16.4.1

10.1.0.0/24

West-‐DC

PiTR 4.4.4.4

10.3.0.0/24

Non-‐LISP site

ITR S

D

DNS Entry: D.abc.com A 10.1.0.1

1

10.3.0.1 -‐> 10.1.0.1 2

EID-‐prefix: 10.1.0.0/24

Locator-‐set:

172.16.1.1, priority: 1, weight: 50 (D1)

172.16.2.1, priority: 1, weight: 50 (D2)

Mapping Entry

3

Определяется сайтом-получателем

10.3.0.1 -‐> 10.1.0.1 172.16.10.1 -‐> 172.16.1.1

4

10.3.0.1 -‐> 10.1.0.1 5

LISP: база отображения адресов Регистрация и поиск

West-‐DC East-‐DC

X Z

Y

Y

10.1.0.2

10.1.0.0 /16 10.2.0.0/16

Map Server / Resolver: 1.1.1.1

A B C D

LISP Site

iTR

10.1.0.0/16 -> (A, B) Database Mapping Entry (ETR):

10.2.0.0/16 -> (C, D) Database Mapping Entry (ETR): eTR eTR eTR eTR

Map-Reply 10.1.0.0/16 -> (A, B)

10.1.0.0/16-> (A, B) Mapping Cache Entry (ITR):

•  Новый xTR обнаруживает новый источник трафика •  Настройка динамических EID определяет, для каких адресов разрешёно роуминг

•  Регистрация в базе LISP


LISP-‐VM (xTR)

X Z

Y

Y

Mapping DB

10.1.0.2

10.1.0.0 /16 10.2.0.0/16

1.1.1.1 2.2.2.2

lisp dynamic-eid roamer

database-mapping 10.1.0.0/24 <RLOC-C> … database-mapping 10.1.0.0/24 <RLOC-D> map-server 1.1.1.1 key abcd

interface vlan 100 lisp mobility roamer

A B C D

Получен пакет...

… от «нового» хоста … входит в разрешённый

диапазон динамических EID...

…это «переезд»! Регистрация /32 в LISP

LISP: поддержка мобильности VM Обнаружение перемещения

•  При обнаружении переезда, происходит обновление: –  Обновляется соотношение в базе соотношений EID->RLOC –  iTR уведомляются о необходимости обновить кеш

•  Удалённые LISP роутеры (iTRs или PiTRs) теперь отправляют трафик на другой сайт

•  «Прозрачность» для хостов и транспортной сети


LISP-‐VM (xTR)

X Z

Y

Y

Mapping DB

10.1.0.2

10.1.0.0 /16 10.2.0.0 /16

A B C D

LISP Site

xTR

10.1.0.0/16 – RLOC A, B

10.1.0.2/32 – RLOC C, D

LISP: поддержка мобильности VM Перенаправление трафика

West-‐DC

Data Center IP Backbone

DC-Aggregation

DC-Access

East-‐DC

Internet / WAN Backbone

PxTR

LISP Site

EID RLOC LISP Encap/Decap

xTR

Mapping DB

Non-‐LISP Sites

Где внедрять LISP and OTV Роли и положение в сети

LISP-‐VM (xTR)

xTR: роутеры филиалов на LISP сайтах

• Customer-managed/owned • SP-Managed CE service

PxTR: Пограничые роутеры в транзитных точках

• Customer backbone routers • Customer router @ co-location • SP provided router/service

Mapping Servers/ resolvers:распределены

• Customer-managed/owned • SP provided service

LISP-VM xTR: коммутаторы агрегирования в ЦОД

• Customer-managed/owned

OTV: Коммутаторы агрегирования в ЦОД

• Customer-managed/owned

OTV

Оптимальный транспорт с помощью LISP и OTV

ESX Server A

Layer3 Core

ESX Server B

VLAN A – 10.1.1.0

FHRP: 10.1.1.1 FHRP: 10.1.1.1

- Virtual-Machine-A - IP Address = 10.1.1.100 - Mask: 255.255.255.0 - Default GW = 10.1.1.1

VLAN A – 10.1.1.0

A A’ B B’

MS MR PxTR

D

Client in LISP Site Client in non-LISP Site

C1 C2

E

- Virtual-Machine-A - IP Address = 10.1.1.100 - Mask: 255.255.255.0 - Default GW = 10.1.1.1

OTV Server-to-Server L2 traffic

LISP: L3 Client-to-Server •  Оптимизация маршрутизации с детальной информацией

о местоположении •  Оптимицация мобильности внутри или между подсетями •  Масштабирование прикладных сервисов

OTV: L2 Server-to-Server •  Оптимизация расширения LAN •  Распределение прикладных систем •  Надежная связь на втором уровне для мобильности

виртуальных сервисов и кластерных систем

LISP: Аппаратные требования к Nexus 7000

Interfaces Encap/Decap

N7K-M132XP-12 N7K-M132XP-12L

Другие карты M-серии

Карты F1 (Proxy Mode)

N7K-M132XP-12 N7K-M132XP-12L P O P

•  Только N7K-M132XP-12 или N7K-M132XP-12L способны выполнять LISP-инкапсуляцию •  F1 карты могут использовать карты N7K-M132XP в прокси-режиме •  Другие карты M-серии не поддерживают LISP и не должны присутствовать в том же VDC

Nexus 7000: сосуществование OTV и LISP

•  OTV должен работать в отдельном VDC, чтобы поддерживать растягивание маршрутизируемых VLAN

•  LISP работает в VDC агрегирования, также как и любой другой IP сервис

Aggregation VDC IP Services, SVIs, LISP

OTV VDC OTV Services

Дополнительная информация

•  http://www.cisco.com/go/dci •  http://www.lisp4.net •  http://lisp.cisco.com

Вопросы и Ответы

Спасибо! Просим Вас заполнить анкеты. Ваше мнение очень важно для нас!

Связь распределённых ЦОД с использованием otv и lisp

Technology