return

Автоматизация Для Самых Маленьких. Часть Вторая. Дизайн сети

20 июля 2019, 21:50

В первых двух статьях я поднял вопрос автоматизации и набросал её фреймворк, во второй сделал отступление в виртуализацию сети, как первый подход к автоматизации настройки сервисов.
А теперь пришло время нарисовать схему физической сети.
Описанные в этой серии практики должны быть применимы к сети любого типа, любого масштаба с любым многообразием вендоров (нет).
Однако нельзя описать универсальный пример применения этих подходов. Поэтому я остановлюсь на современной архитектуре сети ДЦ: Фабрике Клоза. DCI сделаем на MPLS L3VPN.
В этом случае получится сравнительно простой сценарий для автоматизации, потому что имеем много оборудования, настраивающегося одинаковым образом.
Мы выберем сферический ДЦ в вакууме:
— Одна версия дизайна везде.
— Два вендора, образующих две плоскости сети.
— Один ДЦ похож на другой как две капли воды.
Содержание:

Пусть наш Сервис-Провайдер будет, например, хостить обучающие видео о выживании в застрявших лифтах.
В мегаполисах это пользуется бешенной популярностью, поэтому физических машин надо много.
Сначала я опишу сеть приблизительно такой, какой бы её хотелось видеть. А потом упрощу для лабы.


Физическая топология

Локации
У LAN_DC будет 6 ДЦ:

  • Россия (RU):
    • Москва (msk)
    • Казань (kzn)
  • Испания (SP):
    • Барселона (bcn)
    • Малага (mlg)
  • Китай (CN):
    • Шанхай (sha)
    • Сиань (sia)

В каждом ДЦ по 10 стоек с машинами, они будут нумероваться как A, B, C итд.
В каждой стойке по 30 машин. Они нас интересовать не будут.
Также в каждой стойке стоит коммутатор, к которому подключены все машины — это Top of the Rack switch — ToR или иначе в терминах фабрики Клоза будем называть его Leaf.
Именовать их будем XXX-leafY, где XXX — трёхбуквенное сокращение ДЦ, а Y — порядковый номер. Например, kzn-leaf11.

Я в статьях позволю себе достаточно фривольно обращаться терминами Leaf и ToR, как синонимами. Однако нужно помнить, что это не так.
ToR — это конкретная роль устройства в физической топологии.
Leaf — это конечное устройство в терминах Фабрики Клоза.
Так Leaf’ом может быть EndofRaw-коммутатор, например.

Каждый ToR-коммутатор в свою очередь соединён с четырьмя вышестоящими агрегирующими коммутаторами — Spine. Под Spine’ы выделено по одной стойке в ДЦ. Именовать будем аналогично: XXX-spineY.
В этой же стойке будет стоять сетевое оборудование для связности между ДЦ — 2 маршрутизатора с MPLS на борту. Но по большому счёту — это те же самые ToR’ы. То есть с точки зрения Spine-коммутаторов не имеет никакого значения обычный там ToR с подключенными машинами или маршрутизатор для DCI — один чёрт форвардить.
Такие специальные ToR’ы называются Edge-leaf. Мы их будем именовать XXX-edgeY.
Для простоты предположим, что ДЦ связаны между собой прямыми линками.
Исключим из рассмотрения внешнюю связность.

Я отдаю себе отчёт в том, что каждый раз, как я убираю какой-либо компонент, я значительно упрощаю сеть. И при автоматизации нашей абстрактной сети всё будет хорошо, а на реальной возникнут костыли.
Это так. И всё же задача этой серии — подумать и порабоnать над подходами, а не героически решать выдуманные проблемы.

На Edge-Leaf’ах underlay помещается в VPN и передаётся через MPLS-магистраль (тот самый прямой линк).
Вот такая верхнеуровневая схема получается. Задача сетевой фабрики, как мы уже определились, очень и очень простая — обеспечить IP-связность между машинами как в пределах одного ДЦ, так и между.
Оттого-то сеть и называется фабрикой, так же, например, как фабрика коммутации внутри модульных сетевых коробок, о чём подробнее можно почитать в СДСМ14.
Фабрика полностью L3. Никаких VLAN, никаких Broadcast — вот такие у нас в LAN_DC замечательные программисты, умеют писать приложения, живущие в парадигме L3, а виртуальные машины не требует Live Migration c сохранением IP-адреса.
Почему фабрика?!!!


Маршрутизация

Для маршрутизации внутри ДЦ будем использовать BGP.
На MPLS-магистрали OSPF+LDP.
Для DCI, то есть организации связности в андерлее — BGP L3VPN over MPLS.
На фабрике никаких OSPF и ISIS (запрещённый в Российской Федерации протокол маршрутизации).
А это значит, что не будет Auto-discovery и вычисления кратчайших путей.
Ручная (нет — автоматическая) настройка протокола, соседства и политик.
Почему BGP?
На эту тему есть целый RFC имени Facebook’a и Arista, где рассказывается, как строить очень крупные сети датацентров, используя BGP. Читается почти как художественный, очень рекомендую для томного вечера.
В нём и про Clos-топологии, и про L3-дизайны, и про BGP в качестве единственного протокола маршрутизации, и даже OPEX с CAPEX’ом. В общем мне Лапухов (он один из авторов) идею продал.
Что такое крупный — это тысячи стоек в одном датацентре, то есть это тысячи сетевых устройств. Даже при разбиении на OSPF-зоны или ISIS (запрещённый в Российской Федерации протокол маршрутизации)-level’ы проблема работы Link-State протоколов вопросы остаются: политики маршрутизации, агрегация маршрутов, а если у нас VRF, а если хочется распространять не только unicast маршруты?
При этом от BGP как протокола сигнализации между датацентрами, скорее всего, никуда не денешься.
А BGP супер-масштабируемый, расширяемый протокол, который уже показал свою эффективность на самой крупной сети нашей Солнечной системы.
Десятки и сотни тысяч (даже миллионы) маршрутов он ест на завтрак.
Как раз то, что нужно.
Тем более мы сокращаем стек используемых технологий — везде BGP.
С точки зрения маршрутизации один датацентр можно считать единым доменом маршрутизации.
Стоит вспомнить, как в середине СДСМ мы наивно смеялись над идеей BGP в качестве IGP, а теперь пришлось к ней обратиться.

Положа руку на сердце, на нашей фабрике, которая с большой долей вероятности не будет стремительно расти, за глаза хватило бы и OSPF. Это на самом деле проблемы мегаскейлеров и клауд-титанов. Но пофантазируем всего лишь на несколько выпусков, что нам это нужно, и будем использовать BGP, как завещал Пётр Лапухов.

Сессии и политики

На Leaf-коммутаторах мы импортируем в BGP префиксы с Underlay’ных интерфейсов с сетями. Допустим это будет Vlan127.
У нас будет BGP-сессия между каждой парой Leaf-Spine, в которой эти Underlay’ные префиксы будут анонсироваться по сети тудыть-сюдыть.
Внутри одного датацентра мы будем распространять специфики, которые импортировали на ТоРе. На Edge-Leaf’ах будем их агрегировать и анонсировать в удалённые ДЦ и спускать до ТоРов. То есть каждый ТоР будет знать точно, как добраться до другого ТоРа в этом же ДЦ и где точка выхода, чтобы добраться до ТоРа в другом ДЦ.
В DCI маршруты будут передаваться, как VPNv4. Для этого на Edge-Leaf интерфейс в сторону фабрики будет помещаться в VRF, назовём его UNDERLAY, и соседство с Edge-Leaf на Spine будет подниматься внутри VRF, а между Edge-Leaf’ами в VPNv4-family.
А ещё мы запретим реанонсировать маршруты полученные от вышестоящего уровня, обратно на него.
На Leaf и Spine мы не будем импортировать Loopback’и. Они нам понадобятся только для того, чтобы определить Router ID.
А вот на Edge-Leaf’ах импортируем его в Global BGP. Между Loopback-адресами Edge-Leaf’ы будут устанавливать BGP-сессию в IPv4 VPN-family друг с другом.
Между EDGE-устройствами у нас будет растянута магистраль на OSPF+LDP. Всё в одной зоне. Предельно простая конфигурация.
Вот такая картина с маршрутизацией.

BGP ASN

Edge-Leaf

На Edge-Leaf’ах будет один ASN во всех ДЦ. Это важно, чтобы между Edge-Leaf’ами был iBGP, и мы не накололись на нюансы eBGP. Пусть это будет 65535. В реальности это мог бы быть номер публичной AS.

Spine

На Spine у нас будет один ASN на ДЦ. Начнём здесь с самого первого номера из диапазона приватных AS — 64512, 64513 итд.
Почему ASN на ДЦ?
Декомпозируем этот вопрос на два:
Почему одинаковые ASN на всех Спайнах одного ДЦ,
Почему разные в разных ДЦ
Почему одинаковые ASN на всех Спайнах одного ДЦ
Вот как будет выглядеть AS-Path Андерлейного маршрута на Edge-Leaf:
[leaf1_ASN, spine_ASN, edge-leaf_ASN]
При попытке заанонсировать его обратно на Спайн, тот его отбросит потому что его AS (Spine_AS) уже есть в списке.
Однако в пределах ДЦ нас совершенно устраивает, что маршруты Underlay, поднявшиеся до Edge не смогут спуститься вниз. Вся коммуникация между хостами внутри ДЦ должна происходить в пределах Спайнов. При этом агрегированные маршруты других ДЦ в любом случае беспрепятственно будут доходить до ТоРов — в их AS-Path будет только ASN 65535 — номер AS Edge-Leaf’ов, потому что именно на них они были созданы.
Почему разные в разных ДЦ
Теоретически нам может потребоваться протащить Loopback’и каких-нибудь сервисных виртуальных машин между ДЦ.
Например, на хосте у нас запустится Route Reflector или тот самый VNGW (Virtual Network Gateway), который по BGP запирится с ТоРом и проанонсирует свой Лупбэк, который должен быть доступен из всех ДЦ.
Так вот как будет выглядеть его AS-Path:
[VNF_ASN, leaf_DC1_ASN, spine_DC1_ASN, edge-leaf_ASN, spine_DC2_ASN, leaf_DC2_ASN].
И здесь нигде не должно быть повторяющихся ASN.
То есть Spine_DC1 и Spine_DC2 должны быть разными, ровно как и ToR_DC1 и ToR_DC2, к чему мы как раз и подходим.

Как вы, наверно, знаете, существуют хаки, позволяющие принимать маршруты с повторяющимися ASN вопреки механизму предотвращения петель (allowas-in на Cisco). И у этого есть даже вполне законные применения. Но это потенциальная брешь в устойчивости сети.
И если у нас есть возможность не использовать опасные вещи, мы ей воспользуемся.

Leaf

У нас будет индивидуальный ASN на каждый Leaf-коммутаторах в пределах всей сети.
Делаем мы так из соображений, приведённых выше: AS-Path без петель, конфигурация BGP без закладок.
Чтобы маршруты между Leaf’ами беспрепятственно проходили, AS-Path должен выглядеть так:
[leaf1_ASN, spine_ASN, leaf2_ASN]
где leaf1_ASN и leaf2_ASN хорошо бы, чтобы отличались.
Требуется это и для ситуации с анонсом Лупбэка VNF между ДЦ:
[VNF_ASN, leaf_DC1_ASN, spine_DC1_ASN, edge-leaf_ASN, spine_DC2_ASN, leaf_DC2_ASN]
Будем использовать 4-байтовую ASN и генерировать его на основе ASN Spine’а и номера Leaf-коммутатора, а именно, вот так: Spine_ASN.0000X.
Вот такая картина с ASN.


IP-план

Принципиально, нам нужно выделить адреса для следующих подключений:

  1. Адреса сети Underlay между ToR и машиной. Они должны быть уникальны в пределах всей сети, чтобы любая машина могла связаться с любой другой. Отлично подходит 10/8. На каждую стойку по /26 с запасом.
  2. Линковые адреса между Leaf/Tor и Spine. Пусть это будет… 169.254.0.0/16. А именно 169.254.00X.Y/31, где X — номер Spine, Y — P2P-сеть /31. Это позволит запускать до 128 стоек, и до 10 Spine в ДЦ. Линковые адреса могут (и будут) повторять из ДЦ в ДЦ.
  3. Cтык Spine — Edge-Leaf организуем на подсетях 169.254.10X.Z/31, где точно так же X — номер Spine, Y — P2P-сеть /31.
  4. Линковые адреса из Edge-Leaf в MPLS-магистраль. Здесь ситуация несколько иная — место соединения всех кусков в один пирог, поэтому переиспользовать адресное пространство те же самые не получится — нужно выбирать следующую свободную подсеть. Поэтому за основу возьмём 192.168.0.0/16 и будем из неё выгребать свободные.
    • Адреса Loopback. Отдадим под них весь диапазон 172.16.0.0/12.
    • Leaf — по /25 на ДЦ — те же 128 стоек. Выделим по /23 на регион.
    • Spine — по /28 на ДЦ — до 16 Spine. Выделим по /26 на регион.
    • Edge-Leaf- по /29 на ДЦ — до 8 коробок. Выделим по /27 на регион.

Вот такая картина с IP-адресацией.

Префикс Роль устройства Регион ДЦ
172.16.0.0/23 edge    
172.16.0.0/27 ru  
172.16.0.0/29 msk
172.16.0.8/29 kzn
172.16.0.32/27 sp  
172.16.0.32/29 bcn
172.16.0.40/29 mlg
172.16.0.64/27 cn  
172.16.0.64/29 sha
172.16.0.72/29 sia
172.16.2.0/23 spine    
172.16.2.0/26 ru  
172.16.2.0/28 msk
172.16.2.16/28 kzn
172.16.2.64/26 sp  
172.16.2.64/28 bcn
172.16.2.80/28 mlg
172.16.2.128/26 cn  
172.16.2.128/28 sha
172.16.2.144/28 sia
172.16.8.0/21 leaf    
172.16.8.0/23 ru  
172.16.8.0/25 msk
172.16.8.128/25 kzn
172.16.10.0/23 sp  
172.16.10.0/25 bcn
172.16.10.128/25 mlg
172.16.12.0/23 cn  
172.16.12.0/25 sha
172.16.12.128/25 sia

Лаба

Два вендора. Одна сеть. АДСМ.
Juniper + Arista. Ubuntu. Старая добрая Ева.
Количество ресурсов на нашей виртуалочке в Миране всё же ограничено, поэтому для практики мы будем использовать вот такую упрощённую до предела сеть. Два датацентра: Казань и Барселона.

  • По два спайна в каждом: Juniper и Arista.
  • По одному ТоРу (Leaf’у) в каждом, с одним подключенным хостом (возьмём легковесный Cisco IOL для этого).
  • По одной ноде Edge-Leaf (пока только Juniper).
  • One Cisco switch to rile them all.
  • Помимо сетевых коробок запущена виртуальная машина-управляка. Она имеет доступ ко всем устройствам, на ней будут крутиться IPAM/DCIM-системы, букет питоновских скриптов, анзибль и что угодно ещё, что нам может понадобиться.

Полная конфигурация всех сетевых устройств, которую мы будем пробовать воспроизвести с помощью автоматики.




Полезные ссылки.
Подход к маршрутизации в L3 ДЦ описан в следующих документах:
Лапухов

Меланокс.!!!

like 460 views 637 message 0

0 коментариев

Ещё статьи

Превратности балансировки
Статья опубликована nag.ru. ================== Тема балансировки одна из самых душещипательных и одновременно зубодробильных после QoS. Как это обычно бывает в сфере связи, всё выглядит очень просто с точки зрения настройки: ...
like 0 14232 10
27 августа 2014
linkmeup и Клиппер. Собес. #3. Integration Engineer
Пока у нас определяется кандидат на Собес#2 и дата интервью (ориентировочно 04.03), мы начинаем принимать резюме на следующую позицию в linkmeup Ltd. Если вы чувствуете в себе смелость и силу ...
like 0 2821 0
20 февраля 2018
Массовая публикация исторических эпизодов на ютуб-канале linkmeup
В последний день месяца вплоть до сентября на нашем ютуб-канале будет выкидываться сразу пачка подкастов. Так, сегодня вы услышите (и даже что-то увидите) наши исторические эпизоды за 2014 год. Не ...
like 620 988 0
31 марта 2021