Comments 23
А почему накатывание продуктивной конфигурации сделано до обновления, а не после? Ведь есть шанс, что в продуктивной конфигурации могут оказаться команды, которые отсутствуют в стартовой версии софта коммутатора.
Наконец —то статья достойная Хабра!
Респект
Респект
весьма противоречивая идея, которая реализована мало у кого из облачных провайдеров.
Неужели крупные облака тоже ставят один ToR на хост? Никакие MLAG ничего не используют? Может подкинете источники, а то так сходу не найдешь. Я конечно понимаю, что в облаке полно ресурсов, чтобы быстренько перезапустить виртуалку в соседней стойке, но все равно как-то странно. При плановом обслуживании вполне реально на горячую мигрировать машины (хз делают ли так), а если отказ — даунтайм гарантированный на всю стойку? Это ж может быть большое число клиентов.
высокоскоростные интерфейсы хост-тор — 50 ГБ/с или 100 ГБ/с.
Хосты действительно способны такой канал забить?
Знаю даже не особо крупные облака, в которых в каждой стойке по 2 тора, собранных в фабрику и LAG от каждого сервера в фабрику, один линк в один свитч, другой — в другой. Отказ свитча не приводит к недоступности клиентских инстансов, только понижает пропускную способность.
Насчёт горячей миграции при плановых работах — многие стараются это делать, но не всегда это реально.
Да, именно не особо крупные облака обычно это делают. А тем более, если это коммерческие ДЦ.
Но у больших играет уже фактор масштаба: два свитча — это ведь не просто +1 свитч в стойку — это возрастающая вдвое СКС, требующая уже иных подходов, это увеличивающееся количество спайнов.
Ну и кроме того только MC-LAG позволит forwarding-агенту на хосте не знать о двуторье.
А MC-LAG — это проприетарная технология, привязывающая вас к вендору, чего вы точно не хотите, когда покупаете свитчи тысячами.
Если использовать BGP до хоста, то соответственно на нём нужна контролька, понимающая его и умеющая программировать forwarfing-агент.
Я не говорю, что это всё невозможно — мы сделали прототип. Но на данный момент архитектура и компенсационные меры эффективнее, чем удвоенная СКС.
Но у больших играет уже фактор масштаба: два свитча — это ведь не просто +1 свитч в стойку — это возрастающая вдвое СКС, требующая уже иных подходов, это увеличивающееся количество спайнов.
Ну и кроме того только MC-LAG позволит forwarding-агенту на хосте не знать о двуторье.
А MC-LAG — это проприетарная технология, привязывающая вас к вендору, чего вы точно не хотите, когда покупаете свитчи тысячами.
Если использовать BGP до хоста, то соответственно на нём нужна контролька, понимающая его и умеющая программировать forwarfing-агент.
Я не говорю, что это всё невозможно — мы сделали прототип. Но на данный момент архитектура и компенсационные меры эффективнее, чем удвоенная СКС.
А MC-LAG — это проприетарная технология, привязывающая вас к вендору, чего вы точно не хотите, когда покупаете свитчи тысячами.
Это если мы говорим о проприетарных свитч платформах. Если брать bare-metal и ставить sonic или cumulus, то MC-LAG вполне себе получается свободный. А с учетом, что у крупных игроков порой вообще софт и железо свои в этом месте, то тем более не проблема как по мне.
По масштабам понятно. Просто любопытно, неужели люди выбирают риск потерять целую стойку и даунтайм для кучи клиентов. С ростом масштабов у нас соответственно и клиентов больше, и риск потерять свитч выше.
потерять целую стойку и даунтайм для кучи клиентов
Всё-таки парадигма публичного Облака предполагает, что клиент запускает N>1 экземпляров в разных AZ, ставит под балансер, и ещё накручивает автоскейлер. Выпадение одной стойки будет болезненным, но не фатальным. Внутренние сервисы такое переживают, не вздрагивая.
Ну а вопросы открытых ОС для whitebox'ов стоит обсуждать совсем отдельно)
И ещё где-то выше писал, что MC-LAG — это только одна из технических сложностей при реализации дуал-хоминга.
Ну а вопросы открытых ОС для whitebox'ов стоит обсуждать совсем отдельно)
Какие у вас кстати мысли насчет этого? Мы вот с самого начала пошли по этому пути. Хоть и не облако, но небольшой кластер вычислительный. Whitebox свитчи, клос фабрика. Живет себе и никого не трогает, а денег сэкономили вагон. Кажись гиперскейлеры по этому пути идут сейчас. Sonic, собственно, из азура вышел и вроде как набирает популярность.
Мы используем Whitebox. Думаю, что на одном из следующих NextHop кто-нибудь об этом сделает доклад)
А можете рассказать, каким образом Whitebox-свитчи позволили сэкономить вагон? Они ведь не настолько драматически дешевле, а количество возникающих с ними проблем требует или поддержки или своего штата экспертов.
Ну и что было мотивацией использовать их вместо зрелых и оттестированных вендорских железок?
А можете рассказать, каким образом Whitebox-свитчи позволили сэкономить вагон? Они ведь не настолько драматически дешевле, а количество возникающих с ними проблем требует или поддержки или своего штата экспертов.
Ну и что было мотивацией использовать их вместо зрелых и оттестированных вендорских железок?
Whitebox у нас получились существенно дешевле. Конкурент в лице аристы, которого мы тоже смотрели, стоил на тысячи долларов дороже за штуку. Оно ведь понятно. В стоимость вложена ОС, а с whitebox мы платим только за железо. И даже с учетом платы за cumulus выходило существенно дешевле, а с sonic разница так вообще неприличная получается. При этом железо все равно везде одинаковое практически — кругом стоит один и тот же броадком. В том числе у аристы и многих других.
А мотивацией было как раз нежелание отваливать столько денег, на которые лучше было серваков докупить, а также связываться собственно с этими самыми вендорами. Ну и поэкспериментировать — тренд в эту сторону давно просматривался. Пока у нас проблем никаких не возникало с таким решением. Как настроили так и работает.
А мотивацией было как раз нежелание отваливать столько денег, на которые лучше было серваков докупить, а также связываться собственно с этими самыми вендорами. Ну и поэкспериментировать — тренд в эту сторону давно просматривался. Пока у нас проблем никаких не возникало с таким решением. Как настроили так и работает.
Про MLAG ответил ниже.
Ссылок, боюсь нет. Именно про dual-homing серверов большие ребята особо не рассказывают. Знаю из личных разговоров и по косвенным признакам в публичных публикациях.
Карточки такие уже есть на рынке некоторое время. Вопрос за приложениями.
Несколько клиентов, интенсивно (очень) пишущих на диски (распределённые по ДЦ), вполне могут нагенерить большой объём трафика.
Или GPU-кластера, считающие ML-задачки.
На нагрузочных тестах мы приближались к таким цифрам.
Ссылок, боюсь нет. Именно про dual-homing серверов большие ребята особо не рассказывают. Знаю из личных разговоров и по косвенным признакам в публичных публикациях.
Хосты действительно способны такой канал забить?
Карточки такие уже есть на рынке некоторое время. Вопрос за приложениями.
Несколько клиентов, интенсивно (очень) пишущих на диски (распределённые по ДЦ), вполне могут нагенерить большой объём трафика.
Или GPU-кластера, считающие ML-задачки.
На нагрузочных тестах мы приближались к таким цифрам.
А в чем принципиальный смысл растить AZ до размеров, когда требуется второй уровень спайнов? Почему даже в рамках одного ДЦ не разбить сеть на несколько AZ, связав их только BGP?
Клиенты хотят бесплатного трафика внутри AZ. И иногда пользуются им на всю катушку.
Уровень spine2 позволяет предоставить дешёвую полосу внутри AZ и не делать сеть узким местом. Расширить стык между двумя кусками такой сети гораздо сложнее, чем нарастить число спайнов второго уровня.
Грубо говоря, если у вас на границе двух таких сегментов будет стоять свитч/рутер на 32х100Gb/s порта вы сразу ограничены в 3,2Tb/s. Много это или мало?
А если сегментов 3? А 5? А 20? Я не теоретизирую — это реальная необходимость)
Кроме того это задача оптимизации — до какой степени гранулярным делать плейсмент потребителей в AZ?
Здесь не просто нужно размещать мощности клиентов (и свои инфраструктурные тоже) близко друг к другу, но и контролировать, что его новые экземпляры уместятся в этот сегмент. А если не уместятся — и у него network-intensive операции окажутся между сегментами?
А если клиента два, но они очень активно ходят друг к другу?
А если клиент оказался в одном сегменте, а сервис Облака (например, его S3-бакет) в другом?
В общем, Клоз, позволяет надстраивать уровни и не превращать плейсмент в гору «если», сеть в узкое место, а отладку дропов — в ад. При этом, насколько я знаю, у больших число уровней Клоза доходит до 4 или даже 5 (без пруфов))
Грубо говоря, если у вас на границе двух таких сегментов будет стоять свитч/рутер на 32х100Gb/s порта вы сразу ограничены в 3,2Tb/s. Много это или мало?
А если сегментов 3? А 5? А 20? Я не теоретизирую — это реальная необходимость)
Кроме того это задача оптимизации — до какой степени гранулярным делать плейсмент потребителей в AZ?
Здесь не просто нужно размещать мощности клиентов (и свои инфраструктурные тоже) близко друг к другу, но и контролировать, что его новые экземпляры уместятся в этот сегмент. А если не уместятся — и у него network-intensive операции окажутся между сегментами?
А если клиента два, но они очень активно ходят друг к другу?
А если клиент оказался в одном сегменте, а сервис Облака (например, его S3-бакет) в другом?
В общем, Клоз, позволяет надстраивать уровни и не превращать плейсмент в гору «если», сеть в узкое место, а отладку дропов — в ад. При этом, насколько я знаю, у больших число уровней Клоза доходит до 4 или даже 5 (без пруфов))
Ну и больше того — граница AZ — это тоже сегмент сети Клоза, чтобы даже выход в DCI можно было масштабировать горизонтально.
-А в чем прикол Spine вврех ногами прикрутить? (QSFP приятнее включать или mgmt слева-направно не тянуть?)
-SDN прям совсем не смотрите — «сами с усами»? Все говорят (вендоры) о эффекти технологии, но даже такие продвинутые ребята ее не используют(( Вопрос в небеса: чем же так страшен вендор лок?
-Получается машинки подключены одним хвостом 10/25Gb, им хватает?
П.С. Статья клевая!
-SDN прям совсем не смотрите — «сами с усами»? Все говорят (вендоры) о эффекти технологии, но даже такие продвинутые ребята ее не используют(( Вопрос в небеса: чем же так страшен вендор лок?
-Получается машинки подключены одним хвостом 10/25Gb, им хватает?
П.С. Статья клевая!
— Не понял про спайн вверх ногами.
— SDN в Облаке и в хвост и в гриву — для построения оверлейной сети. Там сильно кастомизированный Tungsten Fabric. Для андерлея фабрики — нет — он там и не нужен. Для магистрали есть мысли-идеи, а-ля Egress Peer Engineering.
— Вендор лок страшен тем, что кончатся чипы у вендора — и ты перед сложным решением, что нужно редизайнить сеть. Или тем, что ты не можешь манипулировать ценой, рассматривая альтернативных поставщиков. Ну и в конце концов — просто перестанет поддерживать фичу, как, например, MPLS на новых коробках)
Сейчас — да.
— SDN в Облаке и в хвост и в гриву — для построения оверлейной сети. Там сильно кастомизированный Tungsten Fabric. Для андерлея фабрики — нет — он там и не нужен. Для магистрали есть мысли-идеи, а-ля Egress Peer Engineering.
— Вендор лок страшен тем, что кончатся чипы у вендора — и ты перед сложным решением, что нужно редизайнить сеть. Или тем, что ты не можешь манипулировать ценой, рассматривая альтернативных поставщиков. Ну и в конце концов — просто перестанет поддерживать фичу, как, например, MPLS на новых коробках)
Получается машинки подключены одним хвостом 10/25Gb, им хватает?
Сейчас — да.
Чтобы рассчитывать на резервирование в Dual-ToR — нужно загружать каналы < чем на 50% (иначе отказ линка приведет к каскадным отказам по производительности), а это уже расход денег.
Плюс — policy-based routing чтобы отделить трафик хранилки от сетевого трафика (если я правильно понял) — это тоже дополнительные проблемы дизайна.
Решит ли добавление второго линка к хосту проблему отказоустойчивости? Кажется, только усложнит жизнь.
Плюс — policy-based routing чтобы отделить трафик хранилки от сетевого трафика (если я правильно понял) — это тоже дополнительные проблемы дизайна.
Решит ли добавление второго линка к хосту проблему отказоустойчивости? Кажется, только усложнит жизнь.
Sign up to leave a comment.
Как превратить две серверные стойки в сеть для десятков тысяч машин и не остаться в неоплатном техническом долгу