Pull to refresh

Comments 26

Приятно, когда интересно и легко написано)

Мы продолжаем знакомить вас с внутренним устройством Яндекс.Облака


А можно статьи помечать каким-то тегом, чтобы было легко найти?

Замечательный дизайн. Кто вендор коммутаторов?
Вендор используется не один. Однако общее между ними то, что большинство сетевых устройств базируется на Broadcom Trident/Tomahawk series чипсетах.
Какие вендоры используются? У самого сеть на Trident первого поколения.

Вендоры используются разные, это не так принципиально в разрезе обсуждаемых в статье вопросов. У одних вендоров лучше одно, у других — другое. От комбинации факторов и отталкиваемся, выбирая под конкретные задачи. Если у вас чуть более конкретный вопрос, то вы задавайте, а я попробую на него ответить.

Хотелось бы еще почитать о логической составляющей — как и на чем работает виртуализация…
расскажите побольше про управление инфраструктурой. как или чем накатываются конфиги? если тестирование конфигов?
Я надеюсь, мы когда-нибудь про это напишем подробнее, а пока перечислю используемые у нас инструменты: netbox (ipam), git, ansible, естественно самописные python скрипты, jinja, netconf (как один из способов управления устройствами и получения информации с них), и еще различные сопутствующие внутренние вещи.
Вот это было бы очень интересно всем кто хочет автоматизировать сеть. Ждем. Спасибо.
Если у вас в качестве underlay используется mpls, то что в качестве overlay? vpls? evpn/mpls?

В качестве overlay используется Tungsten Fabric, переработанный и по частям.

Т.е. если я правильно понял, фабрика у вас используется только в качестве mpls транспорта, никаких сервисов на ней нет, а все сервисы сидят на виртуальных роутерах?
Действительно, часть сервисов сидит на виртуальных роутерах и, соответственно, в виртуальной сети. Однако, немалая часть сервисов сидит в underlay-сети, это например само управление серверами, сетевой сторадж и др.
Сопутствующий вопрос про storage трафик. По картинке label switch path начинается с Cloud GateWay. А он под Leaf. Не увеличиваются ли задержки в IP Storage трафике? Distributed Storage ноды вряд ли под одним Leaf, так как тогда бы стойка была точкой отказа…

Красите storage трафик? data и replication под одним QoS?
переиспользовать текущую инфраструктуру

Кабы я была царица, — говорит одна девица, — стала б я «использовать существующую инфраструктуру».
Теперь не только авторы, но и Хабр говорит по английски! Англоязычной аудитории будет интересно почитать про Яндекс.

Я считаю, что вы молодцы — использовать «нестандартное» решение это амбициозно. У меня несколько вопросов возникло:


1) по какой причине вы решили подключать сервера к двум коммутаторам вместо одного? Ведь это существенно дороже и сервер все равно остаётся единой точкой отказа.
2) Используете ли вы cut-through или store-n-forward режим коммутации? Если второе, то не беспокоит ли вас увеличивающаяся задержка в пути?
3) Ничего не сказано про максимальный размер пакета (MTU) доступный конечным пользователям
4) Насколько использование MPLS ограничивает вас в выборе оборудования? На горизонте есть несколько разных поставщиков сетевых ASIC, но сможете ли вы их использовать со своими специфичными требованиями?
5) Возникали ли у вас какие либо трудности с взаимодействием между MPLS и балансировкой нагрузки между интерфейсами? Например поляризация трафика.
6) Используете ли вы какую либо систему маркировки и приоритезации трафика?


Спасибо.

Отвечу по пунктам:

1) по какой причине вы решили подключать сервера к двум коммутаторам вместо одного? Ведь это существенно дороже и сервер все равно остаётся единой точкой отказа.

На самом деле, стоимость второго коммутатора в серверной стойке не является сильно принципиальной на фоне стоимости самой стойки серверов в полной их набивке.
Зато такая конструкция снижает домен отказа в *количество серверов в стойке* раз, а также позволяет сравнительно безболезненно проводить различные работы.

2) Используете ли вы cut-through или store-n-forward режим коммутации? Если второе, то не беспокоит ли вас увеличивающаяся задержка в пути?

Нет, текущие значения нас совсем не беспокоят.

3) Ничего не сказано про максимальный размер пакета (MTU) доступный конечным пользователям

Внутри виртуальных пользователских сетей доступны jumbo frames.

4) Насколько использование MPLS ограничивает вас в выборе оборудования? На горизонте есть несколько разных поставщиков сетевых ASIC, но сможете ли вы их использовать со своими специфичными требованиями?

Конечно есть некоторые ограничения, но в основном они сводятся к софту. Однако наши требования не сильно специфичные, по большей части нужно просто уметь делать label swap, а с этим как правило все хорошо.
Есть места где нужно уметь делать label imposing на сетевом оборудовании, но их не так много, а там где много — мы делаем на наших сетевых appliances.

5) Возникали ли у вас какие либо трудности с взаимодействием между MPLS и балансировкой нагрузки между интерфейсами? Например поляризация трафика.

Как таковых трудностей в этом месте, которые заставили бы нас думать серьезно об этом, у нас не возникало.

6) Используете ли вы какую либо систему маркировки и приоритезации трафика?

QoS, несколько красок по типу трафика, но еще смотрим что тут можно сделать в нашей ситуации лучше.
Есть возможность рассказать, что используется в качестве vRouter'ов?
А также рассматривали ли более «традиционную» схему с EVPN/VXLAN и EVPN/MPLS на DCs interconnect'е? и если, да, то почему не выбрали в двух словах?

Как писал выше, у нас используется по частям Tungsten Fabric с нашими изменениями.


Конечно, мы держали в голове разные схемы, но нам в том числе нужна была end-to-end mpls связность, поэтому иметь несколько схем (усложнение) и делать между ними какой-либо stitching (тоже усложнение) не хотелось, и в итоге остановились на том, на чем остановились.

Здравствуйте, Александр!
Вы выделили сервис Облака в отдельную AS200350 относительно основной AS Яндекса AS13238 и для этого развиваете отдельную связность Облака. Это сделано для удобства размещения на одной структуре и возможности разделения сигнализаций этих структур? Не накладно ли держать дублирующие линки с магистральными операторами, или это делается в одних и тех же каналах для обеих AS параллельно?

Это было сделано с целью разделить внешний трафик Яндекс.Облака и трафик самого Яндекса.

По-английски бы еще то же самое )
Sign up to leave a comment.