— Не понял про спайн вверх ногами.
— SDN в Облаке и в хвост и в гриву — для построения оверлейной сети. Там сильно кастомизированный Tungsten Fabric. Для андерлея фабрики — нет — он там и не нужен. Для магистрали есть мысли-идеи, а-ля Egress Peer Engineering.
— Вендор лок страшен тем, что кончатся чипы у вендора — и ты перед сложным решением, что нужно редизайнить сеть. Или тем, что ты не можешь манипулировать ценой, рассматривая альтернативных поставщиков. Ну и в конце концов — просто перестанет поддерживать фичу, как, например, MPLS на новых коробках)
Получается машинки подключены одним хвостом 10/25Gb, им хватает?
Уровень spine2 позволяет предоставить дешёвую полосу внутри AZ и не делать сеть узким местом. Расширить стык между двумя кусками такой сети гораздо сложнее, чем нарастить число спайнов второго уровня.
Грубо говоря, если у вас на границе двух таких сегментов будет стоять свитч/рутер на 32х100Gb/s порта вы сразу ограничены в 3,2Tb/s. Много это или мало?
А если сегментов 3? А 5? А 20? Я не теоретизирую — это реальная необходимость)
Кроме того это задача оптимизации — до какой степени гранулярным делать плейсмент потребителей в AZ?
Здесь не просто нужно размещать мощности клиентов (и свои инфраструктурные тоже) близко друг к другу, но и контролировать, что его новые экземпляры уместятся в этот сегмент. А если не уместятся — и у него network-intensive операции окажутся между сегментами?
А если клиента два, но они очень активно ходят друг к другу?
А если клиент оказался в одном сегменте, а сервис Облака (например, его S3-бакет) в другом?
В общем, Клоз, позволяет надстраивать уровни и не превращать плейсмент в гору «если», сеть в узкое место, а отладку дропов — в ад. При этом, насколько я знаю, у больших число уровней Клоза доходит до 4 или даже 5 (без пруфов))
Про MLAG ответил ниже.
Ссылок, боюсь нет. Именно про dual-homing серверов большие ребята особо не рассказывают. Знаю из личных разговоров и по косвенным признакам в публичных публикациях.
Хосты действительно способны такой канал забить?
Карточки такие уже есть на рынке некоторое время. Вопрос за приложениями.
Несколько клиентов, интенсивно (очень) пишущих на диски (распределённые по ДЦ), вполне могут нагенерить большой объём трафика.
Или GPU-кластера, считающие ML-задачки.
На нагрузочных тестах мы приближались к таким цифрам.
Да, именно не особо крупные облака обычно это делают. А тем более, если это коммерческие ДЦ.
Но у больших играет уже фактор масштаба: два свитча — это ведь не просто +1 свитч в стойку — это возрастающая вдвое СКС, требующая уже иных подходов, это увеличивающееся количество спайнов.
Ну и кроме того только MC-LAG позволит forwarding-агенту на хосте не знать о двуторье.
А MC-LAG — это проприетарная технология, привязывающая вас к вендору, чего вы точно не хотите, когда покупаете свитчи тысячами.
Если использовать BGP до хоста, то соответственно на нём нужна контролька, понимающая его и умеющая программировать forwarfing-агент.
Я не говорю, что это всё невозможно — мы сделали прототип. Но на данный момент архитектура и компенсационные меры эффективнее, чем удвоенная СКС.
Я тут разделил их на два шага, но фактически на данный момент это один — устройство перезагружается в новой версии ПО с целевым конфигом.
Вероятно, в следующих версиях автоматизации это поменяется. Отдельно в будущем напишу про это.
А вот это любопытно. Никогда не проверял, убеждённый, что Майнхоф — это мужчина :) Исправил. Но, учитывая, что я тут обыгрываю двойное авторство в виде двойной фамилии, думаю, это допустимо)
Любопытная вещь. На первый взгляд выглядит почти братом netbox, стек почти такой же, только база другая.
Но нет, руками не трогал, потому что впервые от вас услышал.
Ну, я привёл здесь только 3 из 6 принципов, потому что статья — интро-туториал, с какой стороны в первый раз подойти к RESTful API.
К uniform я тоже привёл очень краткое описание. Более полному не соответствовать совсем нетрудно:
As the constraint name itself applies, you MUST decide APIs interface for resources inside the system which are exposed to API consumers and follow religiously. A resource in the system should have only one logical URI, and that should provide a way to fetch related or additional data. It’s always better to synonymize a resource with a web page.
Any single resource should not be too large and contain each and everything in its representation. Whenever relevant, a resource should contain links (HATEOAS) pointing to relative URIs to fetch related information.
Also, the resource representations across the system should follow specific guidelines such as naming conventions, link formats, or data format (XML or/and JSON).
All resources should be accessible through a common approac
Вы про gRPC?
Возможно, со временем я напишу обзорную или сравнительную статью о разных API, но пока это подготовительная статья к следующей, поэтому задача была по камешкам разобрать именно RESTful API.
Без шифрования можно собрать дамп трафика и посмотреть внутрь HTTP. Именно поэтому я и дал все ссылки с http.
Впрочем, это не отменяет того факта, что неплохо было бы сделать оба варианта :)
Ну, Django — это один день хорошего туториала с практикой (грубо говоря).
И плюс я иду из мира сетевиков в это дело, а PHP тут нужен примерно нигде и никому.
— SDN в Облаке и в хвост и в гриву — для построения оверлейной сети. Там сильно кастомизированный Tungsten Fabric. Для андерлея фабрики — нет — он там и не нужен. Для магистрали есть мысли-идеи, а-ля Egress Peer Engineering.
— Вендор лок страшен тем, что кончатся чипы у вендора — и ты перед сложным решением, что нужно редизайнить сеть. Или тем, что ты не можешь манипулировать ценой, рассматривая альтернативных поставщиков. Ну и в конце концов — просто перестанет поддерживать фичу, как, например, MPLS на новых коробках)
Сейчас — да.
Грубо говоря, если у вас на границе двух таких сегментов будет стоять свитч/рутер на 32х100Gb/s порта вы сразу ограничены в 3,2Tb/s. Много это или мало?
А если сегментов 3? А 5? А 20? Я не теоретизирую — это реальная необходимость)
Кроме того это задача оптимизации — до какой степени гранулярным делать плейсмент потребителей в AZ?
Здесь не просто нужно размещать мощности клиентов (и свои инфраструктурные тоже) близко друг к другу, но и контролировать, что его новые экземпляры уместятся в этот сегмент. А если не уместятся — и у него network-intensive операции окажутся между сегментами?
А если клиента два, но они очень активно ходят друг к другу?
А если клиент оказался в одном сегменте, а сервис Облака (например, его S3-бакет) в другом?
В общем, Клоз, позволяет надстраивать уровни и не превращать плейсмент в гору «если», сеть в узкое место, а отладку дропов — в ад. При этом, насколько я знаю, у больших число уровней Клоза доходит до 4 или даже 5 (без пруфов))
Ссылок, боюсь нет. Именно про dual-homing серверов большие ребята особо не рассказывают. Знаю из личных разговоров и по косвенным признакам в публичных публикациях.
Карточки такие уже есть на рынке некоторое время. Вопрос за приложениями.
Несколько клиентов, интенсивно (очень) пишущих на диски (распределённые по ДЦ), вполне могут нагенерить большой объём трафика.
Или GPU-кластера, считающие ML-задачки.
На нагрузочных тестах мы приближались к таким цифрам.
Но у больших играет уже фактор масштаба: два свитча — это ведь не просто +1 свитч в стойку — это возрастающая вдвое СКС, требующая уже иных подходов, это увеличивающееся количество спайнов.
Ну и кроме того только MC-LAG позволит forwarding-агенту на хосте не знать о двуторье.
А MC-LAG — это проприетарная технология, привязывающая вас к вендору, чего вы точно не хотите, когда покупаете свитчи тысячами.
Если использовать BGP до хоста, то соответственно на нём нужна контролька, понимающая его и умеющая программировать forwarfing-агент.
Я не говорю, что это всё невозможно — мы сделали прототип. Но на данный момент архитектура и компенсационные меры эффективнее, чем удвоенная СКС.
Вероятно, в следующих версиях автоматизации это поменяется. Отдельно в будущем напишу про это.
Исправил.Но, учитывая, что я тут обыгрываю двойное авторство в виде двойной фамилии, думаю, это допустимо)Но нет, руками не трогал, потому что впервые от вас услышал.
К uniform я тоже привёл очень краткое описание. Более полному не соответствовать совсем нетрудно:
Так или так.
Возможно, со временем я напишу обзорную или сравнительную статью о разных API, но пока это подготовительная статья к следующей, поэтому задача была по камешкам разобрать именно RESTful API.
Впрочем, это не отменяет того факта, что неплохо было бы сделать оба варианта :)
И плюс я иду из мира сетевиков в это дело, а PHP тут нужен примерно нигде и никому.