**Аннотация: **Как должна развиваться сеть Underlay, чтобы соответствовать пяти девяткам?
В последние годы бизнес общедоступных облачных сервисов быстро развивался, и концепция сети как услуги становилась все более и более популярной. Поставщики облачных услуг предоставляют арендаторам все больше и больше облачных сервисов, а сервисные функции, такие как VPC и LB, становятся все более и более совершенными. Это требует, чтобы сеть предоставляла гибкие возможности программирования, которые могут быстро изменять политики в зависимости от бизнес-требований арендаторов. Эта концепция фактически противоречит традиционной сети. В традиционной сетевой концепции мы верим в процедуру «преодоления стабильности».Чтобы обеспечить стабильность сети, необходимо свести к минимуму изменения конфигурации сети. Тогда как в облачной среде сеть может соответствовать требованиям стабильности и гибкости?
Чтобы удовлетворить потребности облачных сервисов, сети постепенно дифференцируются на базовые и оверлейные. Нижняя сеть — это маршрутизирующее и коммутационное оборудование традиционного центра обработки данных, она по-прежнему верит в концепцию стабильности во всем и обеспечивает возможности надежной сетевой передачи данных, а оверлей — это инкапсулированная на ней бизнес-сеть, которая ближе к сервису и инкапсулируется такими протоколами, как VXLAN или GRE., чтобы предоставить арендаторам простой в использовании сетевой сервис. Нижняя сеть и оверлейная сеть связаны и разъединены, и они связаны друг с другом и развиваются независимо.
Сегодня я в основном говорю о стратегии развития базовой сети. Нижняя сеть является основой всего общедоступного облака, несущая сеть нестабильна, а SLA для сервисов отсутствует. По мере того, как услуги, предоставляемые в облаке, становятся все больше и больше, а количество клиентов увеличивается, требования к стабильности базовой сети становятся все выше и выше. Как должна развиваться сеть Underlay, чтобы соответствовать пяти девяткам?
Традиционная сеть «толстое дерево» имеет простую структуру и проста в обслуживании, но с расширением масштаба сети возникает множество проблем.
1. Проблема стабильности уровня 2
Традиционно устройства POD используются в качестве единиц расширения. В устройствах POD используются крупномасштабные коммутаторы для агрегации, и большинство устройств POD представляют собой сетевые устройства уровня 2. Существует два распространенных решения для взлома петель уровня 2: STP+VRRP, стекирование
VRRP+STP — наиболее часто используемое сетевое решение в традиционных центрах обработки данных.Шлюз резервируется через VRRP, а петля разрывается через STP.Это действительно «золотой партнер» традиционных сетей. Однако по мере увеличения масштаба сети, когда количество TOR достигает более 100, протокол stp столкнется с более серьезными проблемами, такими как случайные ошибки в вычислениях и медленное время сходимости. 100 TOR, каждый с 40 нисходящими портами, двойным доступом к серверам, могут поддерживать масштабирование до 2K. Масштаб тоже немалый, но как только возникнет проблема с STP, пострадают все 2К серверы, что недопустимо.
Укладка, укладка может напрямую избежать проблемы петель, и ее намного проще поддерживать. Но стек все равно остается большим вторым этажом, а большой второй этаж рискует быть парализованным штормом. Кроме того, система стека не может быть гладко обновлена, что всегда было болью в сердцах инженеров по эксплуатации и техническому обслуживанию.После того, как стек собран, риск обновления слишком велик.
2. Проблема сходимости пропускной способности
Структура толстого дерева увеличивает пропускную способность за счет увеличения пропускной способности линии и количества линий устройства верхнего уровня. Однако по мере увеличения масштаба подключается все больше и больше серверов и подключается все больше и больше TOR, а соединений, которые сходятся к ядру, часто недостаточно для достижения неконвергентной сети. И сколько бы ни было подключений, все они идут с определенного устройства, это устройство неисправно и потеря пропускной способности слишком серьезна.
3. Проблемы с расширением
Согласно данным, предоставленным AWS, масштаб облачного центра обработки данных является самым большим — 6 Вт. Для решения на основе толстого дерева в принципе невозможно поддерживать доступ к серверу 6 Вт. Даже если он действительно подключен, сетевые проблемы, вызванные отказом любого магистрального устройства, непредсказуемы. Так же, как формирование обжор в фильме «Великая стена», все обжоры вращались вокруг короля зверей, и вся армия была уничтожена, когда король зверей умер.
Таким образом, исходя из бизнес-требований общедоступного облака, как базовая сеть может развиваться в соответствии с «человеческим дизайном», которая является одновременно надежной и поддерживает крупномасштабную неконвергентность? Это конечно модный геймплей типа clos, scale out, anycast (не такой уж и модный, они сделали это 10 лет назад)
Позвольте мне поделиться с вами практиками Google и Facebook, сети этих двух компаний можно рассматривать как эталон производительности.
Google:
Google по-прежнему сохраняет концепцию, аналогичную POD, но их POD имеет 4 схождения, а количество ядер, подключаемых к аплинку, сколько угодно, совершенно выходит за рамки традиционных. Между N ядрами и каждым агрегированием POD существует взаимосвязь. Между любыми двумя POD есть 4 * N линий, которые взаимодействуют друг с другом.
Четыре POD сходятся, где шлюз? Столько линий, как сделать управление и маршрутизацию?
Чтобы сделать такую сеть, это определенно не то, что можно сделать, изменив метод подключения. Шлюз подложки должен быть подключен к TOR. Агрегация восходящего потока TOR напрямую запускает протокол динамической маршрутизации, а протокол динамической маршрутизации также работает между агрегацией и ядром, чтобы сформировать несколько путей с одинаковой стоимостью. Сообщения можно пересылать по желанию, и все дороги ведут в Рим.
Традиционные протоколы динамической маршрутизации, такие как OSPF и BGP, в конце концов могут поддерживать ограниченные пути ECMP. Google преобразовал традиционный протокол динамической маршрутизации, чтобы он мог поддерживать больше путей с равной стоимостью и быстрее обнаруживать проблемы с линиями.
Фейсбук:
На картинке выше изображена типичная сеть LEGO Facebook, которая разделена на несколько уровней и плоскостей. Каждая плоскость на нижнем уровне соответствует POD, а совокупность POD состоит из нескольких плоскостей и ядра для формирования POD верхнего уровня.
Глядя на это, может немного кружиться голова, давайте упростим это следующим образом:
- Каждый POD имеет 48 TOR, и у каждого сервера есть только 1 линия для подключения к 1 TOR.
- Каждый восходящий поток TOR подключается к 4 агрегациям, а каждый восходящий поток агрегации подключается к 48 ядрам.
- Между любыми двумя серверами существует 4 * 48 = 192 пути.
- Если какой-либо из TOR выходит из строя, программное обеспечение выполняет собственное резервирование, и бизнес не затрагивается.
- Любой сбой агрегации или ядра, служба в основном не знает
Такая сеть, в которой работает бизнес, вызывает ли она сильное ощущение?
Обобщите характеристики сетей двух компаний:
1. Децентрализация, больше не одна агрегация или ядро, а множественные расширения
2. Шлюз сливается в TOR, а маршрут выше TOR — это route forwarding, что препятствует распространению широковещательного домена второго уровня.
3. Существует несколько путей с одинаковой стоимостью, и избыточность линий между агрегацией ядра высока, и отказ любого одного устройства или одной линии практически не влияет.
Выше — это то, что мы можем видеть непосредственно с физической карты, а в «невидимых» местах сделано больше оптимизаций:
1. Аппаратный контроллер устройства, унифицированное управление всеми устройствами, стандартизированная конфигурация
2. Канал передачи информации о мониторинге оборудования, любой канал имеет полный мониторинг
3. Возможность планирования трафика, если линия перегружена, трафик направляется на другие ссылки.
Конечно, есть много других оптимизаций, о которых автор не может знать, но у этих оптимизаций определенно есть общая цель: сеть становится более стабильной.
** Философия дизайна Интернета никогда не верит в надежность одной точки. ** Благодаря избыточной конструкции отказ любого узла не повлияет на бизнес в целом. То же самое относится и к базовой сети: по мере того, как все больше и больше сервисов переносится в облако, если базовая сеть нестабильна, все больше и больше сервисов будут повреждены, и причиненные убытки не могут быть перенесены. Концепция проектирования всех базовых сетей должна быть сосредоточена на том, что «ни один бизнес не может рухнуть, несмотря ни на что». Сеть Google и Facebook является нашим пионером, и различные отечественные поставщики облачных услуг фактически используют аналогичные сетевые решения.
**Структура физической архитектуры обеспечивает инженерную надежность. ** И многие режимы отказа, которые физическая архитектура может не покрыть. Также необходимо разработать соответствующее программное обеспечение, чтобы лучше обеспечить стабильную работу сети. Дополнение программных возможностей, таких как мониторинг и планирование, более важно, чем физическая архитектура.
В настоящее время все больше и больше компаний внедряют коммутаторы «белой марки». Фактически, они открывают традиционную систему коммутаторов и добавляют интерфейсы API к традиционной закрытой системе коммутаторов, которые можно напрямую планировать через систему программирования для получения дополнительной внутренней информации для облегчить Настройка для каждой ситуации. Например, анализ потери пакетов при переключении, удаленный захват пакетов, мониторинг заданного потока, планирование заданного потока и другие возможности.
Хотя традиционные коммутаторы имеют полные функции, по сравнению с общедоступными облаками, полные функции не обязательно являются бременем. Как раз полный набор функций вкупе с открытой и программируемой системой — это то, что нужно облаку. Видите ли, AWS приходится выпускать собственные коммутаторы.
Нажмите «Подписаться», чтобы впервые узнать о новых технологиях HUAWEI CLOUD~