Comments 26
Мы продолжаем знакомить вас с внутренним устройством Яндекс.Облака
А можно статьи помечать каким-то тегом, чтобы было легко найти?
Вендоры используются разные, это не так принципиально в разрезе обсуждаемых в статье вопросов. У одних вендоров лучше одно, у других — другое. От комбинации факторов и отталкиваемся, выбирая под конкретные задачи. Если у вас чуть более конкретный вопрос, то вы задавайте, а я попробую на него ответить.
www.youtube.com/watch?v=Kr6WIYPts8I
В качестве overlay используется Tungsten Fabric, переработанный и по частям.
Красите 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, несколько красок по типу трафика, но еще смотрим что тут можно сделать в нашей ситуации лучше.
А также рассматривали ли более «традиционную» схему с EVPN/VXLAN и EVPN/MPLS на DCs interconnect'е? и если, да, то почему не выбрали в двух словах?
Как писал выше, у нас используется по частям Tungsten Fabric с нашими изменениями.
Конечно, мы держали в голове разные схемы, но нам в том числе нужна была end-to-end mpls связность, поэтому иметь несколько схем (усложнение) и делать между ними какой-либо stitching (тоже усложнение) не хотелось, и в итоге остановились на том, на чем остановились.
Вы выделили сервис Облака в отдельную AS200350 относительно основной AS Яндекса AS13238 и для этого развиваете отдельную связность Облака. Это сделано для удобства размещения на одной структуре и возможности разделения сигнализаций этих структур? Не накладно ли держать дублирующие линки с магистральными операторами, или это делается в одних и тех же каналах для обеих AS параллельно?
MPLS повсюду. Как устроена сетевая инфраструктура Яндекс.Облака