Comments 33
Максимальный размер кластера некоторое время назад был порядка 10 тыс. серверов. Это обусловлено в значительной степени тем, как могут работать те самые операционные системы уровня кластера, планировщики, аллокация ресурсов и т. п. Поскольку на стороне инфраструктурного софта случился прогресс, то сейчас целевым является размер порядка 100 тыс. серверов в одном вычислительном кластере, и у нас возникла задача — уметь строить сетевые фабрики, которые позволяют эффективно осуществлять пулинг ресурсов в таком кластере.
Выглядит как «вертикальное масштабирование» кластера, т.е. примерно как одному серверу добавлять память, диски и процессоры.
А почему не работает горизонтальное масштабирование — т.е. вместо одного большого кластера делать федерацию кластеров?
Доклад с кучей специфических терминов, с малым кол-вом пояснений, почему они выбрали ту и ли иную технологию.
Вызывает вопросы по использованию BGP вместо более быстрой OSPF с агрегацией маршрутов.
Также непонятно по серверам, какое там чудо-железо, способное генерить 2x50G данных, особенно CPU и сетевые карты.
В чем отличия от типичного дизайна Cisco для датацентров?
или
Вызывает вопросы по использованию BGP вместо более быстрой OSPF с агрегацией маршрутов.
Также непонятно по серверам, какое там чудо-железо, способное генерить 2x50G данных, особенно CPU и сетевые карты.
В чем отличия от типичного дизайна Cisco для датацентров?
- Cisco Three-Tier Network Design
или
- Collapsed Core/Aggregation Network Design
Если вы все-таки пытаетесь реализовать Spine-Leaf Network Topology, то не забудьте упоминуть, что для этого очень желательно иметь железо Cisco Nexus.
- Spine-Leaf Network Topology
очень желательно иметь железо Cisco Nexus
Это почему? Сейчас эти сети можно строить на чем угодно (собственно, как и модно сейчас. bare-metal все дела), был бы чип нужный и поддержка софта. Почти все на broadcom основаны, в том числе циска. Бери какой хочешь.
Опять же, это утверждение «Spine-Leaf Network Topology, то не забудьте упоминуть, что для этого очень желательно иметь железо Cisco Nexus» — тоже чушь.
Там масштабы не для OSPF. Как ответ на вопрос можно почитать rfc7938
В этом RFC только два предположения.
И ни слова, почему нельзя использовать OSPF с сегментированием сетей и автосуммированием маршрутов.
- over one hundred thousand servers
- using BGP as the only routing protocol
И ни слова, почему нельзя использовать OSPF с сегментированием сетей и автосуммированием маршрутов.
Можно использовать OSPF. Но в OSPF нет автосуммаризации и в rfc написано почему предлагается использовать BGP. Можно поискать по ключевому слову — ospf.
Подозреваю, что OSPF не любят за фладинг при любом изменении в сети. Из-за чего оно не скейлится и это никак не побороть. Поэтому крупные игроки на BGP. Его, по крайней мере, можно настроить нормально и RFC этот самый об этом и пишет.
Как раз таки в этом самом RFC хорошо расписано, как настроить BGP, но при этом почти ничего не написано про то, почему не стоит использовать OSPF/ISIS с разделением на зоны/уровни, как справедливо предложил желтый колобок выше. Флудинг LSA при изменениях топологии будет ограничен 1 зоной. Допустим, 1 зона = 1 POD, если сопоставлять с дизайном с картинок выше. Если в поде меньше 100 устройств, то CPU вашей кофеварки скорей всего выживет.
По поводу RFC, вот все 4 упоминания слова OSPF в его тексте:
1. Обычно, OSPF используется в L3-дизайнах.
2. Устройство протокола OSPF сложнее, чем у BGP.
3. BGP поддерживает third-party next-hop, OSPF их тоже поддерживает, но у BGP лучше.
4. Ссылка на OSPF RFC.
Ну да, п.2 и п.3 похожи на какие-то аргументы в пользу BGP. Но если честно, мне они напоминают ухищрения в выборе вида «нам надо купить именно циску, давайте добавим eigrp в требования».
Нет, я в целом верю, что раз яндекс, фейсбук и прочие используют BGP вместо IGP, то у них есть достаточные основания, другое дело, что аргументы озвучиваются с моей точки зрения сомнительные.
По поводу RFC, вот все 4 упоминания слова OSPF в его тексте:
1. Обычно, OSPF используется в L3-дизайнах.
2. Устройство протокола OSPF сложнее, чем у BGP.
3. BGP поддерживает third-party next-hop, OSPF их тоже поддерживает, но у BGP лучше.
4. Ссылка на OSPF RFC.
Ну да, п.2 и п.3 похожи на какие-то аргументы в пользу BGP. Но если честно, мне они напоминают ухищрения в выборе вида «нам надо купить именно циску, давайте добавим eigrp в требования».
Нет, я в целом верю, что раз яндекс, фейсбук и прочие используют BGP вместо IGP, то у них есть достаточные основания, другое дело, что аргументы озвучиваются с моей точки зрения сомнительные.
Наличие большого количество резервных маршрутов + LSA Flooding внутри домена + сложность эксплуатации + масштабируемость. Если мои комментарии, доклад Дмитрия Афанасьева и RFC 7938 для Вас не авторитет, то рекомендую прочитать книгу автора Russ White — The Art of Network Architecture: Business-Driven Design, издательство Cisco Press (глава Clos and the Control Plane).
RFC — рекомендация, книга — мнение конкретного автора, но никак не научная статья, где выводы можно независимо повторить в другой лаборатории/стенде.
Пока что выбор BGP основан на рекомендациях вендора (Cisco) с учетом его проприетарных опций для BGP. И потому в докладе не был указаны важный факторы времени сходимости и реакции протокола на изменения в топологии сети.
В простом случае, если «шаловливые» ручки подергали или поменяли патч-корды.
Пока что выбор BGP основан на рекомендациях вендора (Cisco) с учетом его проприетарных опций для BGP. И потому в докладе не был указаны важный факторы времени сходимости и реакции протокола на изменения в топологии сети.
В простом случае, если «шаловливые» ручки подергали или поменяли патч-корды.
Опять чушь.
Cisco всегда продвигала ISIS, а не BGP. На BGP в DC она скорее была вынуждена согласиться. BGP скорее двигал активно Juniper, а теперь уже RIFT.
Про сходимость так вообще чушь несусветная написана. Отвечу так:
- ECMP
- BGP fast external failover
- BGP ATF
- BGP dampening или interface dampening
Вы бы поменьше «шаловливыми» руками клавиши трогали и побольше книжки.
Вас упорно тянет на специфические дискусии. Прочтите тред четырехлетней давности.
Кстати да, а почему BGP а не RIFT, Яндекс же вроде участвовал в формировании требований к нему?
Какие еще рекомендации вендора (да еще циски) могут быть в датацентре фейсбука, где все свитчи на собственной аппаратной и программной платформе?
Мы не знаем, что «под капотом» у крупных ДЦ, что в Гугле, что в FB, что в Амазоне.
Знаем. Фейсбук во всех подробностях рассказывал про архитектуру сети своих ДЦ и железках, на которых это все работает. При этом все это предоставили на благо всем в рамках OCP www.opencompute.org/contributions?refinementList%5Bcontributor%5D%5B0%5D=Facebook&refinementList%5Bfamily%5D%5B0%5D=Network%20Switch&page=1&configure%5BfacetFilters%5D%5B0%5D=archived%3Afalse
Поправка, Владислав, это вы не знаете )))
Вызывает вопросы по использованию BGP вместо более быстрой OSPF с агрегацией маршрутов.
Потому что в условиях большого количества сетевых железок и линков между ними (которые подразумеваются в spine-leaf топологии) OSPF будет ощутимо нагружать CPU расчетом SPF, а линки — рассылкой LSA-сообщений. Так же есть еще пачка недостатков у протоколов IGP, на фоне которых BGP кажется лучшим средством для маршрутизации в ДЦ.
Чушь. OSPF плохо себя ведет в топологиях типо CLOS и очень плохо масштабируется.
Могли бы объяснить термин radix в контексте сетей?
Насколько я знаю, radix это основание системы счисления.
В данном случае речь идет в контексте «переподписка». Количество доступных портов без переподписки. Пять лет тому назад, со схожей тематикой, в Интернетах проскакивала хорошая статья (там, тема с radix достаточно хорошо раскрывалась), которая называлась — Facebook Fabric Networking Deconstructed — www.firstclassfunc.com/2014/11/facebook-fabric-networking-deconstructed
Sign up to leave a comment.
Как масштабировать дата-центры. Доклад Яндекса