clos_article.html
1 Знаете ли вы, что количество серверов у братьев наших старших давно перевалило за <a href="https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fmp.weixin.qq.com%2Fs%2FNKxDZsqeEzuj7NYV_3xaFA" target="_blank">миллион</a>. 2 Они не работают каждый сам по себе, и они не подключены по <a href="https://en.wikipedia.org/wiki/Wireless_data_center" target="_blank">Wi-Fi</a>, а это значит, что их нужно объединять в кабельную сеть. И для этого строят гигантскую сложную дорогую инфраструктуру. Сетевой архитектор Яндекса Дмитрий Афанасьев <a href="https://www.youtube.com/watch?v=U86Xjx1rcHY&t=1051s" target="_blank">рассказывал</a> на прошедшей в 2019 конференции NextHop о подходах и возникающих в самых неожиданных местах нюансах. 3 4 Если сегодня вы решите построить что-то очень большое, вроде Яндекса или Гугла, то выбор топологии сети предопределён - это будет сеть Клоза. 5 В этой статье я вместе с вами разберусь в эволюции подходов к строительству датацентров и причинах появления тех или иных решений. 6 7 Сеть в большой степени следует за требованиями сервисов, лишь иногда диктуя, как было бы правильно сделать. 8 Так, приложения затребовали широкую полосу и низкие задержки - и сети пришлось стать очень регулярной и плотной. 9 Но при таком дизайне плоской сетью с Ethernet-коммутацией уже не обойдёшься, и в современном мире приложениям приходится учится жить в мире IP-маршрутизации. 10 11 <a href="https://fs.linkmeup.ru/images/adsm/2/kdpv.jpg" target="_blank"><img src="https://fs.linkmeup.ru/images/adsm/2/kdpv_small.jpg" width="600"></a> 12 13 Спойлер: • Clos ••• L3 ••• ECMP ••• BGP ••• Overlay ••• Single-chip • 14 15 <h1>Содержание</h1> 16 <ul> 17 <li><b><a href="#3_TIER">Трёхуровневая иерархическая сеть</a></b></li> 18 <li><b><a href="#NSVSEW">Север-Юг против Запада-Востока</a></b></li> 19 <li><b><a href="#CLOS">Сети Клоза</a></b> 20 <ul> 21 <li><b><a href="#BLOCKING">Блокируемые и неблокируемые сети и переподписка</a></b></li> 22 <li><b><a href="#MULTISTAGE">Многоуровневая сеть Клоза</a></b></li> 23 <li><b><a href="#GLOSSARY">3-Tier, Fat Tree, Clos, Folded Clos, Leaf-Spine?! Аааа!</a></b></li> 24 <li><b><a href="#ROUTING">Маршрутизация</a></b></li> 25 <li><b><a href="#TUNNELS">Вам IP или туннелировать?</a></b></li> 26 <li><b><a href="#DRAWBACKS">Минусы сети Клоза</a></b></li> 27 </ul> 28 </li> 29 <li><b><a href="#OTHERTOPOS">Альтернативные топологии</a></b></li> 30 <li><b><a href="#DEVICES">Выбор оборудования</a></b></li> 31 <li><b><a href="#THEEND">Заключение</a></b></li> 32 <li><b><a href="#LINKS">Полезные ссылки</a></b></li> 33 </ul> 34 <hr> 35 36 <cut> 37 Если заглянуть в далёкое прошлое датацентры жили примерно в таких условиях: 38 <ul> 39 <li>Преобладающий North-South трафик от клиента к серверу и обратно.</li> 40 <li>Плоская Ethernet-сеть (L2) в силу требования мобильности виртуальных машин без смены IP-адреса и высокой цены на L3-оборудование.</li> 41 <li>Любое сетевое оборудование, обладающее широкой функциональностью, стоило действительно немалых денег.</li> 42 </ul> 43 44 Поэтому традиционная сеть ДЦ была такой: 45 46 <a name="3_TIER"></a> 47 <h1>Трёхуровневая иерархическая сеть - 3-Tier</h1> 48 <img src="https://fs.linkmeup.ru/images/adsm/2/fat_tree.png" width="600"> 49 50 Это классическая трёхуровневая архитектура сети, известная нам с <a href="https://linkmeup.ru/blog/11.html" target="_blank">СДСМ0</a>: Access, Aggreggation/Distribution/Core. 51 Так были построены сети операторов связи и предприятий, а впоследствие её же перенесли в датацентры, потому что только так и умели, да и оборудования другого не было. 52 53 Чем дальше в ядро, тем толще линки. 54 - 100 Мб/с к машинам, 1 Гб/с от коммутаторов доступа к коммутаторам агрегации. 55 - 10 Гб/с (а в то время, возможно, LAG из нескольких гигабитных линков) к ядру сети. 56 - Итд. 57 Потому что весь трафик от серверов сливался в аплинки. 58 59 Наверху иерархии стояла пара <a href="https://comeroutewithme.com/2015/02/28/why-is-clos-spineleaf-the-thing-to-do-in-the-data-center/">God Boxes</a>, концентрирующих на себе все сервисы и всю маршрутизацию. На них инженеры молились и старались не дышать. 60 Это были модульные шкафы, занимающие полстойки, а то и стойку, а то и кластера из нескольких стоек. 61 62 С этой топологией была <i>пара</i> проблем. 63 Если взять ситуацию, как на рисунке выше, то отказ любого линка сразу же приводит к выходу из строя части сети. 64 Фактически же строили сети всё-таки с резервированием, и на каждом уровне обычно стояло по паре устройств: 65 <img src="https://fs.linkmeup.ru/images/adsm/2/fat_tree_redundancy.png" width="600"> 66 Да, это требовало богомерзкого STP, но это позволяло обеспечить хоть какую-то стабильность. 67 68 Здесь <b>выпадение</b> линка или устройства приводило к двукратной деградации пропускной способности и, очевидно, работе без резерва. 69 70 Кроме того, все сервисы при таком подходе сосредотачивались как раз на этих верхних устройствах 71 <b>Вывести их из эксплуатации</b>, например, для обновления, означало также потерю половины пропускной способности сети, а то и вовсе полную недоступность сервисов из-за того что второе устройство настроено неправильно. 72 <blockquote> 73 О, сколько раз на моей памяти инженер со спокойной душой выводил устройство из эксплуатации со словами "второе же есть" и ронял сеть, потому что на втором кто-то в своё время превентивно погасил интерфейс или положил BGP-сессию. 74 </blockquote> 75 76 <b>Расширение пропускной способности</b> - это отдельная болезненная история: 77 <ul> 78 <li>Расширение LAG'ов,</li> 79 <li>Закупка линейных карт.</li> 80 <li>А если карты ставить больше некуда, то апгрейд железа, на ещё более мощные и большие ящики.</li> 81 </ul> 82 83 <b>Итого:</b> 84 <ol> 85 <li>Классическая трёхуровневая сеть не может обеспечить лёгкое расширение пропускной способности.</li> 86 <li>Она довольно плохо масштабируется: добавление нового модуля в ДЦ потребует снова расширения линков.</li> 87 <li>Она не может обеспечить высокую степень резервирования - в L2-топологии использование избыточных линков затруднительно из-за "особенностей" MSTP. Соответственно часть линков просто простаивает. А при выпадении узла есть риск потерять не только пропускную способность, но и всю сеть на некоторое время.</li> 88 <li>В общем, эксплуатировать и поддерживать классическую сеть проблематично.</li> 89 </ol> 90 91 <blockquote> 92 Любопытно, что L2-топология, обычно используемая в датацентрах прежде, настолько избаловала разработчиков приложений и системных администраторов, что они долгое время не представляли своей жизни без L2. 93 Здесь и кроются истоки TRILL, SPB, FabricPath и прочих технологий, так желающих облегчить жить Ops'ам. 94 И только в последние годы прослеживается устойчивая тенденция к L3 до стойки в датацентрах. 95 96 Однако было бы лукавством сказать, что L2 отживает своё. Зачастую он просто переместился на уровень абстракции выше - а именно в <a href="https://linkmeup.ru/blog/449.html#OVERLAY" target="_blank">оверлей</a>. 97 Тот же VXLAN благополучно растягивает L2 домен до треска. EVPN тоже умеет его сигнализировать. 98 Однако общая тенденция такова, что на физической сети, в <a href="https://linkmeup.ru/blog/449.html#UNDERLAY" target="_">андерлее</a>, остаётся исключительно L3. 99 </blockquote> 100 <hr> 101 102 <a name="NSVSEW"></a> 103 <h1>Север-Юг против Запада-Востока</h1> 104 Однако всё вышеперечисленное в некотором смысле мелочи, которые можно было бы решить. Один переход на L3 снял бы бо́льшую часть сложностей. 105 Проблема в том, что изменился мир. 106 Внезапно появились Big Data, Map Reduce, ML, гигантские базы данных, аналитика, контекстная реклама. А теперь и AI из пауэр-поинтов на нас поглядывает. 107 108 Исторически запрос пользователя полностью обрабатывался в рамках одного хоста. Был запрос от клиента, который пришёл сверху, и ответ, уходящий обратно наверх. 109 В такой сети преобладает вертикальное (North-South) направление. И иерархическая сеть такой спрос вполне удовлетворяла. 110 <img src="https://fs.linkmeup.ru/images/adsm/2/north_south.png" width="600"> 111 112 Теперь в ДЦ преобладает <b>горизонтальный (East-West)</b> трафик между серверами. 113 И вот как это получается: 114 <ol> 115 <li>Клиент запросил веб-страничку,</li> 116 <li>Его запрос пришёл на балансировщик трафика,</li> 117 <li>Балансировщик перенаправил его на один из фронтендов, </li> 118 <li>Тот послал запрос на один бэкенд сервер, чтобы получить текстовый контент,</li> 119 <li>На другой сервер, чтобы получить данные о пользователе: пол, возраст, предпочтения, последний поиск,</li> 120 <li>На третий - проанализировать данные по локации,</li> 121 <li>Второй и третий послали новые данные на четвёртый, чтобы пополнить информацию о пользователе в БД, чтобы ещё лучше знать какие отмычки для лифтовых дверей предпочитает среднестатистический житель Ленинского района города Новосибирска, пользующийся Android 9.1,</li> 122 <li>На пятый - сформировать контекстную рекламу,</li> 123 <li>Потом все разом начали отвечать фронтенду,</li> 124 <li>Фронтенд отдал всю страницу обратно</li> 125 </ol> 126 127 <img src="https://fs.linkmeup.ru/images/adsm/2/west_east.png" width="600"> 128 129 То есть бо́льшая часть событий произошла внутри сети сервис-провайдера. 130 При этом запрос-ответ внутри ДЦ может многократно превышать по размеру запрос-ответ пользователю. Добавим к этому репликации БД, внутренние хранилища, логи и всё становится понятно (кивните, если согласны). 131 132 Вот такой график <a href="https://www.youtube.com/watch?v=mLEawo6OzFM" target="_blank">Facebook показывает</a> на конференциях, иллюстрируя тенденцию к стремительному росту intra-dc трафика: 133 <img src="https://fs.linkmeup.ru/images/adsm/2/facebook_traffic.png" width="400"> 134 135 Традиционные сети органически не приспособлены к этому из-за своего акцента на North-South. 136 L2-топологиям из-за низкой утилизации полосы и склонности к штормам тоже отказано (TRILL бы, возможно, спас ситуацию, но где он?). 137 Ну, и умное железо если и не стало резко дешевле, то только из-за всё возрастающей производительности, доходящей сегодня уже до 12,8 Тб/с на одночиповую коробку размером 4 юнита. 138 А так уже любая вафельница умеет в L3+BGP. 139 <hr> 140 141 <a name="CLOS"></a> 142 <h1>Сети Клоза</h1> 143 Современный подход к строительству ДЦ, которые используют гипер-скейлеры и <a href="https://www.instagram.com/p/ByJoMiRB4bW/" target="_blank">клауд-титаны</a>, вроде Яндекса, Фейсбука и Гугла - развитие идей крутого парня из Bell Laboratories Чарльза Клоза (который на самом-то деле Шарль Кло, ибо француз). 144 145 <img src="https://fs.linkmeup.ru/images/adsm/2/charles_clos.jpg" width="600"> 146 147 Он в 1953 году, решая проблему проключения звонков через телефонную станцию, предложил неблокируемую сеть, в которой любые входы могут установить соединение с любыми выходами в любой момент времени. 148 149 Прежде для решения этой задачи использовался так называемый <b>Crossbar</b>, соединявший каждый вход с каждым выходом. 150 <img src="https://fs.linkmeup.ru/images/adsm/2/cross_bar.png" width="400"> 151 <i>Изображение с сайта <a href="https://packetpushers.net/demystifying-dcn-topologies-clos-fat-trees-part1/" target="_blank">packetpushers.net</a></i> 152 153 Учитывая, что большая их часть простаивала, решение, и без того сложное в реализации (n^2 соединений), было ещё и неоптимальным. 154 155 Он предложил разделить входы и выходы дополнительным уровнем коммутации, который позволит простраивать соединения между входами и выходами по запросу. Это и назвали <b>сетью Клоза</b>. 156 <img src="https://fs.linkmeup.ru/images/adsm/2/clos_network_1.png" width="600"> 157 <i>Изображение с сайта <a href="https://packetpushers.net/demystifying-dcn-topologies-clos-fat-trees-part1/" target="_blank">packetpushers.net</a></i> 158 159 Сложность такой сети значительно ниже, чем у Crossbar, поскольку имеет гораздо меньшее количество точек коммутации: 6n^(3/2)-3n. 160 161 Вот таблица необходимого числа коммутаций: 162 <img src="https://fs.linkmeup.ru//images/adsm/2/crosspoint_complexity.png" width="600"> 163 164 Уже начиная с 36 конечных точек, сложность топологии Клоза меньше, чем связей "каждый с каждым". 165 166 При этом оригинальная сеть Клоза подразумевает отсутствие блокировки, то есть любые два входа всегда могут быть скоммутированы друг с другом. Выделяют строго неблокируемые или неблокируемые при перекоммутациях - для нас это сейчас неважно. Фактически же более рационально использовать сети с низкой вероятностью блокировки. 167 168 169 В чистом виде топология Клоза описывала сети с коммутацией каналов. 170 Но в 90-е годы с развитием пакетной коммутации эта идея обрела альтер эго. 171 В модульном сетевом оборудовании стало уже сложно соединять все <a href="https://linkmeup.ru/blog/312.html#SERDES" target="_blank">SerDes'ы</a> одного чипа со всеми SerDes'ами другого, поэтому появился дополнительный уровень, в общем скрытый от пользователей, <b><a href="https://linkmeup.ru/blog/312.html#FABRIC">фабрики коммутации</a></b>, единственной задачей которых было доставить пакеты от входного порта в выходной, убрав при этом необходимость в полносвязной топологии. 172 Это не что иное, как сеть Клоза. 173 174 Ну и последняя на сегодняшний день инкарнация - это <b>датацентровые сети</b>, которые суть - те же фабрики коммутации. 175 176 Типичный вид трёхуровневой сети Клоза: 177 <img src="https://fs.linkmeup.ru/images/adsm/2/clos_network_2.png" width="600"> 178 179 Более привычный вид Leaf-Spine - ещё он называется Folded Clos - потому что словно действительно сложен пополам. 180 <img src="https://fs.linkmeup.ru/images/adsm/2/clos_network_3.png" width="600"> 181 182 Другое название такой сети - <b>Fat Tree</b>. 183 184 Вместо весьма интеллектуального, а соответственно и склонного к ошибкам и багам уровня агрегации появляется примитивный уровень коммутации - Spine, задача которого - очень быстро переложить пакет с одного Leaf на другой. 185 186 К Leaf'ам подключаются машины. Сами Leaf'ы подключаются к каждому Spine'у. А Spine'ы соответственно ко всем Leaf'ам. 187 Таким образом между любой парой машин будет существовать большое количество равноценных путей (по количеству спайнов) с всегда одинаковым числом хопов - 3 для сети, изображённой выше. 188 189 Выход же во внешний мир или в другие ДЦ обычно реализуется через отдельные коробки, которые с точки зрения фабрики выглядят как Leaf-коммутаторы, однако гораздо более функциональные. Называются они Edge-Leaf. 190 191 <img src="https://fs.linkmeup.ru/images/adsm/2/clos_network_4.png" width="600"> 192 193 <blockquote> 194 Впрочем привычная операторам реализация границы датацентра всё же имеет право на жизнь. В этом случае функции Edge выполняют спайны. 195 </blockquote> 196 197 В такой топологии интеллект отчасти перемещается на Leaf'ы, отчасти на Edge-Leaf'ы 198 199 В чём плюсы такой сети? 200 <ol> 201 <li>Во-первых, в отсутствии неиспользуемых линков (при учёте, что мы отказываемся от L2). <a href="https://linkmeup.ru/blog/482.html" target="_blank">ECMP</a> - это воздух для сетей Клоза.</li> 202 <li>Во-вторых, конечно, в широких горизонтальных каналах для East-West-трафика.</li> 203 <li>В-третьих, выпадение одного устройства или линка не влечёт фатальных последствий: 204 Если это был ToR - то пострадает только одна стойка. 205 Если Spine - просядет пропускная способность, но не на 50%, как это было бы прежде, а лишь на 1/n, где n - число спайнов. </li> 206 <li>В-четвёртых, простота вывода спайнов из эксплуатации. Благодаря небольшой деградации и отсутствию интеллекта на этом узле, проводить работы на них не так страшно, как на God-Box'ах</li> 207 <li>В-пятых, масштабируемость. 208 Новые лифы можно безболезненно добавлять пока не кончатся порты на спайнах. 209 Добавлением спайна можно расширить аплинки лифов. 210 Добавлением эджей - полосу пропускания наружу. 211 212 Не нужно расширять LAG'и и вставлять новые платы. А если вдруг портов потенциально не хватает или хочется объединять модули одного ДЦ в суперфабрику, то можно надстроить ещё один уровень спайнов (или не один) - хотя тут есть <a href="#DRAWBACKS">нюансы</a>. 213 <blockquote> 214 Такой метод масштабирования называется <b>горизонтальным</b> или <b>Scale out</b>. Добавляется просто ещё одно типовое устройство, практически линейно увеличивая пропускную способность. Нынче это очень модно. Теперь всё масштабируют горизонтально. 215 Классический подход - <b>вертикальное</b> масштабирование <b>Scale up</b> - тут добавляют мощностей в текущие устройства, чтобы расширить их возможности. В маршрутизаторы добавляют платы, в сервера - оперативную память и процы. 216 </blockquote> 217 </li> 218 </ol> 219 220 Здесь может сложиться впечатление, что мы просто перенесли всю сложность с God-Box'ов на граничные маршрутизаторы. Что же, впечатление не обманывает: так оно и есть. Но L3 здесь позволяет, используя <a href="https://linkmeup.ru/blog/482.html" target="_blank">ECMP</a>, масштабировать внешнюю связность, просто увеличивая количество граничных коробок (см. выше Scale out). И также легко и безопасно выводить их из работы, как спайны (почти). 221 <hr> 222 223 <a name="BLOCKING"></a> 224 <h2>Блокируемые и неблокируемые сети и переподписка</h2> 225 Как уже говорилось выше, топологии Клоза были придуманы для сетей с коммутацией каналов. 226 Поэтому свойство "строго неблокируемые" означало, что независимо от количества уже активных каналов, всегда будет возможность соединить свободный вход со свободным выходом. 227 Неблокируемые при перекоммутации - это топологии, в которых тоже всегда возможно найти свободный канал, но, возможно, придётся перекоммутировать существующий активный. Они требуют меньшее количество свитчей. 228 Так же существуют топологии с низкой вероятностью блокировки. 229 230 Если переложить эти термины на сеть с коммутацией пакетов, то неблокируемая сеть Клоза описывает в некотором смысле фабрику без переподписки, когда сумма аплинков не меньше суммы даунлинков. Например, схема с 30ю даунлинками по 10Гб/с и 3мя аплинками по 100Гб/с на Leaf - это фабрика без переподписки - и даже при одновременной передаче данных всеми подключенными хостами - всегда хватит аплинков. 231 Фактически это не всегда необходимо. Глядя на пиковую утилизацию аплинков, например, мы видим, что она достигает 80Гб/с, мы не ожидаем рост, и тогда можно делать два аплинка по 100Гб/с. Получим переподиску 2:3, аналогичную сети Клоза с низкой вероятностью блокировки. 232 Строить фабрику с переподпиской или без - вопрос на усмотрение сетевых архитекторов, но возьму на себя смелость сказать, что чаще строят с переподпиской, чтобы сэкономить порты на спайнах. 233 Касательно пропускной способности стоит ещё отметить ситуацию с кратковременными всплесками трафика (микробёрстами), рождёнными, например, <a href="http://bradhedlund.com/2011/05/01/tcp-incast-and-cloud-application-performance/" target="_blank">инкастом</a>. С ними не справится и фабрика без переподписки, поскольку мы упираемся обычно не в общую полосу аплинков, а в скорость порта, который не успевает пропустить трафик, начинает его буферизировать, очереди переполнятся и пакеты дропаются. Но это уже совсем другая история. 234 235 236 <a name="MULTISTAGE"></a> 237 <h2>Многоуровневая сеть Клоза</h2> 238 Рассмотренная выше сеть Клоза - трёхуровневая или 3-stage: Input Switch - Middle Switch - Output Switch. Если в ней одни и те же лифы выполняют роль одновременно и передатчиков и приёмников, её можно сложить пополам по линии Middle Switch и получается более привычная нам двухуровневая сеть Leaf-Spine. 239 240 Пятиуровневая сеть Клоза будет выглядеть так: Input Switch - Middle Switch 1 - Middle Switch 2 - Middle Switch 3 - Output Switch. Вот она повёрнутая на 90 градусов: 241 <img src="https://fs.linkmeup.ru/images/adsm/2/5_stage_clos.png" width="700"> 242 243 Если её сложить по линии центральных Middle Switch, получается такая трёхуровневая сеть (folded clos): 244 <img src="https://fs.linkmeup.ru/images/adsm/2/folded_5_stage_clos.png" width="800"> 245 246 Стоит дать пояснения: 247 <img src="https://fs.linkmeup.ru/images/adsm/2/2_planes_fabric.png" width="800"> 248 249 После сворачивания сети Клоза мы получили 4 обособленные группы - их называют <b>POD</b>'ами - <b>Point Of Delivery</b>. В каждой из них свой набор спайнов - это <b>спайны первого уровня</b>. 250 POD - это универсальная единица при строительстве датацентров - как кубик лего. Можно сказать, при заказе дополнительных мощностей, просто закупают новый POD и подключают его к новой фабрике. 251 Спайны в одном POD'е далее соединены со спайнами в другом POD'е через <b>спайны второго уровня</b>. Но здесь уже не полная связность: не все спайны первого уровня включены во все спайны второго уровня - напротив, есть разделение по так называемым плоскостям - <b>Plane</b>. 252 По одному спайну из каждого POD'а выводится в отдельную плоскость, в которой есть свой отдельный набор спайнов второго уровня. 253 Сделано это не из вредности, а потому что количество портов на спайнах ограничено и сделать топологию полносвязной просто не получится. На иллюстрации выше - ограничение в 4 порта. 254 255 И так по числу уровней можно расти дальше. 256 <hr> 257 258 259 Сеть Клоза по задумке строится из одинаковых элементов, с одинаковым радиксом (количеством портов). 260 И тут мы имеем ту же самую проблему, что и с <a href="https://linkmeup.ru/blog/312.html#ARCHITECTURE" target="_blank">чипами</a>: 261 <a href="https://linkmeup.ru/blog/312.html#ARCHITECTURE" target="_blank"><img src="https://habrastorage.org/webt/kc/cd/ze/kccdzeml2g5gfo15qx4ueanhto4.png" width="700"></a> 262 263 Чтобы обеспечить неблокируемую (без переподписки) фабрику, аплинки по пропускной способности должны быть такими же, как даунлинки. 264 И тут появляется нюанс при масштабировании. 265 266 Давайте разбираться. 267 <blockquote> 268 Далее предполагаем, что на всех уровнях мы используем одни и те же устройства, на которых только один тип портов и для даунлинков и для аплинков. 269 </blockquote> 270 271 Так, если на коммутаторе всего 2 порта, можно включить всего 1 лиф и 2 машины (или сколько угодно лифов и всё равно 2 машины). 272 273 <img src="https://fs.linkmeup.ru/images/adsm/2/2_ports_1_stage.png" width="300"> 274 275 или 276 277 <img src="https://fs.linkmeup.ru/images/adsm/2/2_ports_3_stages.png" width="300"> 278 279 Если 4 порта, то 4 лифа по 2 даунлинка - 8 машин. 280 <img src="https://fs.linkmeup.ru/images/adsm/2/4_ports_3_stages.png" width="300"> 281 282 8 - 8 лифов по 4 даунлинка - и 32 машины. 283 <img src="https://fs.linkmeup.ru/images/adsm/2/8_ports_3_stages.png" width="400"> 284 285 Более близкий к реальности сценарий - 32 порта - 32 лифа по 16 даунлинков - 512 машин. 286 <img src="https://fs.linkmeup.ru/images/adsm/2/32_ports_3_stages.png" width="300"> 287 288 То есть от числа портов напрямую зависит число машин, которое возможно подключить. 289 При дальнейшем масштабировании всё больше растёт число спайнов. 290 Это при трёхуровневой сети Клоза (лиф-спайн-лиф). 291 292 293 Однако если добавить ещё один уровень, то станет дышаться легче: 294 <img src="https://fs.linkmeup.ru/images/adsm/2/4_ports_5_stages.png" width="300"> 295 296 Тогда при 4 портах можно подключить 8 лифов и 16 машин, а при 8 - 128. 297 <img src="https://fs.linkmeup.ru/images/adsm/2/8_ports_5_stages.png" width="300"> 298 299 32-хпортовые свитчи тогда позволят подключить 8192 хоста - в 16 раз больше, чем в трёхуровневой сети Клоза. 300 <img src="https://fs.linkmeup.ru/images/adsm/2/32_ports_5_stages.png"> 301 302 303 <blockquote> 304 Посоветую вот этот простой, но <a href="https://github.com/h8liu/ftree-vis" target="_blank"> изящный инструмент</a>, который рассчитает количество и возможных хостов, и необходимых свитчей, и кабелей. 305 Я склонировал репу себе, и вы можете <a href="https://fs.linkmeup.ru/ftree-vis/index.html" target="_blank">поиграться</a> прямо сейчас. 306 307 А ещё детальные вычисления для сети Клоза даны <a href="https://packetpushers.net/demystifying-dcn-topologies-clos-fat-trees-part2/" target="_blank">тут</a>. 308 </blockquote> 309 310 Реальный мир как обычно посложнее. Всё же на самом деле мы не используем одни и те же коммутаторы на всех уровнях. 311 Типичный тор/лиф сегодня в крупных ДЦ - это 48x10/25G даунлинков и 6-8x100G аплинков. 312 Типичный спайн - от 32 до 128х100G 313 314 Тут арифметика уже другая. Посчитайте сами. Но очевидно, что подключить в этом случае можно гораздо больше машин. 315 <hr> 316 317 <img src="https://fs.linkmeup.ru/images/adsm/2/squirrels.jpg" width="500"> 318 <a name="GLOSSARY"></a> 319 <h1>3-Tier, Fat Tree, Clos, Folded Clos, Leaf-Spine?! Аааа!</h1> 320 Если у вас такая же реакция, то вам в эту главу! 321 Всё достаточно просто с последними тремя. 322 <b>Clos - Топология Клоза</b> - это теоретические выкладки о том, как малыми усилиями построить сеть без блокировок. 323 <b>Folded Clos - свёрнутая топология Клоза</b> - репрезентация топология Клоза, сложенной пополам, в которой входы - они же выходы, а выходы там же, где входы. 324 <b>Leaf-Spine</b> - это тот же Folded Clos, реализованный в виде сети датацентра. 325 326 А дальше посложнее. 327 Складывается ощущение что единой терминологии тут не выработано. 328 Пока я писал эту статью, пришлось 3 раза полностью переписывать некоторые её части, потому что менялось отношение к терминам. 329 В одних источниках <b>Fat Tree</b> синонимируется с топологией Клоза, в других - с 3-Tier. 330 Я неоднократно встречал статьи, где современному "Leaf-Spine противопоставляется <i>классический</i> Fat-Tree". 331 Хотя в той же <a href="https://ru.wikipedia.org/wiki/Fat_Tree" target="_blank">википедии</a> Fat Tree изображён в виде Клоза, или в <a href="https://tools.ietf.org/html/rfc7938">RFC 7938</a> говорится об их синонимичности. 332 333 В общем, предлагаю не поддаваться соблазну оставить вопрос без решения. Отныне и навсегда: есть классический <b>3-Tier</b>: Access, Aggregation, Core - а есть <b>Fat-Tree</b> - он же Leaf-Spine. 334 Но есть и <a href="#OTHERTOPOS" target="_blank">другие</a>. 335 336 Принимаю аргументированные претензии в комментариях. 337 338 <hr> 339 340 <a name="ROUTING"></a> 341 <h1>Маршрутизация</h1> 342 Для маршрутизации в Клозе стандартом де-факто стал BGP. 343 Почему? 344 На эту тему есть <a href="https://tools.ietf.org/html/rfc7938" target="_blank">целый RFC</a> имени Facebook'a и Arista, где рассказывается, как строить <b>очень крупные</b> сети датацентров, используя BGP. Читается почти как художественный, очень рекомендую для томного вечера. 345 В нём и про топологии Клоза, и про L3-дизайны, и про BGP в качестве единственного протокола маршрутизации, и даже про OPEX с CAPEX'ом. В общем мне Пётр Лапухов (он один из авторов) идею продал. 346 347 Что такое крупный? Это тысячи стоек в одном датацентре, то есть это тысячи сетевых устройств - не всем IGP по зубам. Даже при разбиении на OSPF-зоны или ISIS (запрещённый в Российской Федерации протокол маршрутизации)-level'ы вопросы уместности здесь Link-State протоколов остаются: 348 <ul> 349 <li>Почти отсутствующие политики маршрутизации,</li> 350 <li>Очень ограниченные возможности агрегации маршрутов</li> 351 <li>Для каждого VRF нужно заводить отдельные процессы</li> 352 <li>А если хочется распространять не только IPv4-unicast маршруты?</li> 353 <li>LS IGP рассылает обновления на всю зону при любых изменениях топологии, в то время как EBGP на месте выбирает лучший маршрут, и если ничего не меняется, то и помалкивает.</li> 354 <li>Ещё одна особенность IGP-протоколов - периодический фладинг LS-информацией. OSPF раз в 30 минут будет рассылать многие тысячи сообщений, напрягая CPU.</li> 355 <li>Учитывая плотность линков на фабрике, одни и те же LSA много раз проходят по сети. LS IGP получается слишком говорливым.</li> 356 </ul> 357 358 359 При этом от BGP как протокола сигнализации между датацентрами, скорее всего, никуда не денешься. 360 А BGP супер-масштабируемый, расширяемый протокол, который уже показал свою эффективность на самой крупной сети нашей Солнечной системы. 361 Десятки и сотни тысяч (<a href="https://nag.ru/news/newsline/105287/zabityiy-do-otkaza-reestr-vozmojno-polojil-revizor-.html" target="_blank">даже миллионы</a>) маршрутов он ест на завтрак. 362 Как раз то, что нужно. 363 Тем более мы сокращаем стек используемых технологий - везде BGP. 364 365 Если у вас есть вопросы к сходимости BGP, то тут в наши дни всё тоже неплохо: таймеры можно выкрутить, BFD или BGP Next-hop tracking включить, <a href="https://tools.ietf.org/html/draft-ietf-rtgwg-bgp-pic-05" target="_blank">PIC</a> <a href="https://blog.ipspace.net/2012/01/prefix-independent-convergence-pic.html" target="_blank">опять же</a>. Время распространения информации при изменении топологии - примерно такое же, что и у LS IGP. Количество информации тоже как минимум не больше - нет периодической рассылки LSDB - только реальные события инициируют сообщения BGP Update. Кроме того, домен распространения обновлений можно сократить агрегацией маршрутов. 366 367 368 <blockquote> 369 <i>Стоит вспомнить, как в середине СДСМ мы наивно смеялись над идеей BGP в качестве IGP, а теперь пришлось к ней обратиться</i>. 370 Хотя, безусловно, у BGP есть свои недостатки. По сравнению с LS IGP это, безусловно, отсутствие автообнаружения соседей. При настройке администратору нужно указать их в конфигурации, соотвественно держать где-то об этом информацию. Хотя в качестве контраргумента можно привести в пример <a href="https://tools.ietf.org/html/draft-acee-idr-lldp-peer-discovery-05" target="_blank">BGP Logical Link Discovery Protocol</a> и <a href="https://cumulusnetworks.com/lp/bgp-ebook/">попытки Mellanox</a> облегчить эту задачу. 371 Во-вторых, это вычисление наилучшего маршрута. В BGP оно несколько грубовато - на основе длины AS Path, Local Preference и MED. Учёта стоимости линков нет (AIGP не работает, потому что IGP нет). 372 В случае датацентровых сетей это не звучит большой проблемой - обычно всё-таки все линки одной полосы и одной стоимости. Хотя для проведения работ, например, чтобы вывести узел из эксплуатации не получится просто задрать кост на интерфейсах - нужно через политики пессимизировать маршруты или навешивать <a href="https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/irg-grace-shut.pdf" target="_blank">Gshut community</a>. 373 </blockquote> 374 375 Итак, IGP не рассматривается как протокол для больших датацентров в принципе. BGP - на сегодня стандарт, но со своими ограничениями - главное из них - это возможность блэкхола трафика при агрегации маршрутов. Я об этом напишу чуть <a href="#DRAWBACKS">позже</a>. 376 <hr> 377 378 А есть ли альтернативы? 379 И да, и нет. 380 381 Последние несколько лет активно развивается <a href="https://tools.ietf.org/html/draft-ietf-rift-rift-01" target="_blank">RIFT - Routing In Fat Trees</a>. 382 Все протоколы маршрутизации были разработаны специально для сетей с произвольной топологией и не очень высокой степенью связности между сетевыми узлами. Топология Клоза же напротив является регулярной и плотной. 383 Умные дядьки вдруг решили разрушить полярный мир LS vs DV и смешали их: LS в сторону спайнов, DV в сторону лифов. Детальная информация распространяется только вверх - не вбок и не вниз. 384 Таким образом каждый уровень сети знает все детали об уровнях ниже, но не про уровни выше. На лифах получается только дефолт. 385 386 Кроме того, есть механизм автоматической дезагрегации, который борется с блэкхолом при отказах линков. В ситуации, которую я привёл в <a href="#DRAWBACKS">секции недостатокв</a>, он начинает анонсировать специфики вниз фабрики, чтобы выбрался путь только через те устройства, которые действительно знают как добраться до адресата. 387 388 Это объяснение того, почему альтернативы есть. 389 А нет их, потому что RIFT на сегодняшний день реализован на полутора моделях устройств. Более того, несмотря на его плюсы, не все эксперты так уж оптимистично настроены по поводу его будущего. 390 Ну а мы посмотрим. 391 <hr> 392 393 <a name="TUNNELS"></a> 394 <h1>Вам IP или туннелировать?</h1> 395 Есть крупные компании, которые используют плоскую сеть и держать все абсолютно ресурсы в анедрлее. 396 Но они, скорее, исключение - большинству других нужна изоляция сервисов. Достигается она обычно заведением виртуальной сети. 397 В цикле АДСМ уже <a href="https://linkmeup.ru/blog/449.html" target="_blank">была большая статья</a> об оверлеях - глубоко забираться не будем. 398 Оверлейная сеть состоит из двух участков - изолированный неймспейс на машине и изолированная передача трафика по андерлейной сети. 399 Второе достигается засчёт инкапсуляции. И их мы знаем много видов: 400 <ul> 401 <li>GRE-туннель</li> 402 <li>VXLAN</li> 403 <li>MPLS</li> 404 <li>L3VPN</li> 405 <li>GENEVE</li> 406 </ul> 407 Сеть андерлей при этом предоставляет базовую маршуртизацию между хостами. 408 Практически любой из видов инкапсуляции может начинаться на хосте или на ToR-коммутаторе - это не так уж важно. 409 А вот что важно, так это то, что они отличаются друг от друга заголовками, по которым происходит маршрутизация - IP или MPLS. Например, VXLAN упаковывает данные в заголовки UDP и IP, Tungsten Fabric - в GRE и IP, а MPLS BGP L3VPN - в MPLS. 410 От этого зависит, какие протоколы должны поддерживаться фабрикой - достаточно ли только IP или нужно и MPLS. 411 И насколько бы ни был MPLS гибок, удобен и во всех отношениях прекрасен, с ним на датацентровой фабрике появляются нюансы. 412 413 <ul> 414 <li>Необходимо поддерживать ещё какие-то протоколы (скорее всего, это BGP Labeled Unicast) и дополнительные сущности (LFIB, состояния LSP).</li> 415 <li>В условиях ECMP <a href="https://linkmeup.ru/blog/482.html#MPLS_ECMP_GROUPS" target="_blank">MPLS ведёт себя из рук вон плохо</a>. Он натурально опасен - нужно тщательно следить за ресурсами ECMP-групп.</li> 416 <li>Как ни крути, а LFIB забирает на себя ресурсы чипов (TCAM и RAM), хотя тут надо постараться, чтобы до их ограничений ещё добраться.</li> 417 <li>Когда стандартом де факто в сетях ДЦ стал VXLAN Broadcom выпилил из некоторых своих чипов поддержку MPLS вовсе. Учитывая, что он до сих пор является монополистом, выбор оборудования с поддержкой MPLS становится крайне невелик.</li> 418 </ul> 419 420 Таким образом оверлею в датацентровых сетях быть, а вот MPLS'у скорее нет. 421 422 Из набирающих шум баззвордов стоит вспомнить SRv6, который позволяет махом решить многие вопросы, но оставим это пока для лабораторных исследований. 423 <hr> 424 425 426 <a name="DRAWBACKS"></a> 427 <h1>Минусы сети Клоза</h1> 428 Да, да, они есть, несмотря на всю простоту и красоту подхода. 429 <b>Во-первых</b>, это количество необходимых <a href="https://fs.linkmeup.ru/images/adsm/2/32_ports_5_stages.png" target="_blank">кабелей, портов и свитчей</a>. Каждый новый лиф должен быть подключен во все спайны. А каждый новый спайн - во все лифы. Хотя это является естественным свойством этой топологии, и архитектор к нему заведомо готов. 430 <b>Во-вторых</b>, максимальное количество хостов определено уже на моменте проектирования. Если их понадобится больше, то нужно строить новый кластер/датацентр и соединять его с первым. Очевидно, что это будет две разных инсталляции со сравнительно узкими линками между друг другом, а это автоматически означает, что приложения, активно нагружающие сеть, тоже должны запускаться отдельно в этих кластерах. 431 Если всё-таки для приложений важно, чтобы это был один кластер, то нужно заранее продумывать какое число уровней фабрики будет нужно. А это всегда дополнительные расходы, причём весьма значительные. И отсюда вытекает следующий недостаток: 432 <b>В-третьих</b>, фабрика, основанная на топологии Клоза, должна быть построена почти в полном объёме ещё до того, как туда запустят первые сервисы. 433 434 <img src="https://fs.linkmeup.ru/images/adsm/2/not_fully_constructed_fabric.png" width="800"> 435 436 Например, тут, вы не можете не построить одну плоскость, как не можете не поставить один из спайнов в плейне. С одной стороны - это деградация пропускной способности, с другой - отсутствие резервирования, если речь идёт о двух устройствах. 437 Я немного лукавлю, конечно: не всегда нужна сразу вся запланированная пропускная способность, поэтому можно запланировать 32 плейна, а начать с 4 и плавно добавлять их по мере необходимости. 438 Но! При таких масштабах совсем иначе стоит вопрос коммутаций - это на самом деле непростая задача <a href="https://youtu.be/U86Xjx1rcHY?t=2717" target="_blank">проектирования и экономики</a>. Многие сотни километров оптики должны быть проложены ещё в момент строительства. И на этом фоне стоимость самих коробок может быть гомеопатически малой. 439 То есть к моменту запуска нагрузки, сеть должна быть уже практически полностью построена. 440 441 <b>В-четвёртых</b>, впрочем это сложно назвать недостатком, скорее особенностью топологии Клоза - это маршрутизация. 442 При движении на север есть много путей, а на юг - всегда только один. 443 444 Мы тут используем горячо любимый BGP. И он хорош. Но сценарии отказа и распространения маршрутной информации нужно продумывать очень тщательно. 445 На большой сети мы не можем позволить везде бегать спецификам с торов. Во-первых, их может быть слишком много, что может вызывать исчерпание ресурсов FIB (например, <a href="https://linkmeup.ru/blog/482.html#ECMP_GROUPS" target="_blank">ECMP-групп</a>). Во-вторых, малейшие флапы линков будут вызывать наводнение всей сети обновлениями. 446 Агрегирование маршрутов позволяет решить обе сложности, однако создаёт новую: блэкхолинг трафика. 447 Вот ситуация, которая к нему приведёт: 448 <img src="https://fs.linkmeup.ru/images/adsm/2/blackholes_and_reveleations.png" width="800"> 449 450 За Leaf 00 живёт хост 10.0.0.1. 451 Leaf 00 анонсирует маршрут 10.0.0.0/24 на Level 1 Spine 00 (и на Spine 01, конечно). 452 Рвётся линк между Leaf 00 и Spine 00. Маршрут 10.0.0.0/24 исчезает. 453 Leaf 01 продолжает анонсировать маршрут 10.0.1.0/24 на Spine 00, зажигая агрегат 10.0.0.0/20. 454 Level1 Spine 00 анонсирует этот агрегат на Level2 Spine 00. А тот его переанонсирует в другой POD. 455 POD1 имеет 4 маршрута 10.0.0.0/20 - через спайны второго уровня: Spine 00, 01, 02, 03. 456 Хосты отправляют трафик на DIP: 10.0.0.1. Этот трафик балансируется по 4 путям. 457 Тот трафик, который приходит на Level 2 Spine 00 далее попадает только на Level 1 Spine 00. 458 Однако на нём нет маршрута к специфику 10.0.0.0/24, а агрегат указывает в Null, поскольку на этом устройстве и зарождён. 459 То есть при наличии нескольких рабочих путей в этом случае четверть трафика будет теряться. 460 461 С агрегацией нужно быть предельно аккуратным. 462 <hr> 463 <a name="OTHERTOPOS"></a> 464 <h1>Альтернативные топологии</h1> 465 И я тут не про звезду и full mesh. 466 Существуют топологии, в которых можно построить сеть с той же полосой и на то же количество серверов, что и Клоз, но обойтись меньшим количеством свитчей и кабелей. 467 468 Мы точно не будем здесь развивать эту тему, я просто дам вам отправные точки: 469 <ul> 470 <li><a href="https://www.researchgate.net/publication/220771890_Flattened_butterfly_a_cost-efficient_topology_for_high-radix_networks" target="_blank">Flattened butterfly</a></li> 471 <li><a href="https://people.inf.ethz.ch/asingla/papers/jellyfish-nsdi12.pdf" target="_blank">Jellyfish</a></li> 472 <li><a href="https://www.researchgate.net/publication/313341364_Dragonfly_Low_Cost_Topology_for_Scaling_Datacenters">Dragonfly</a></li> 473 <li>Любопытный сравнительный <a href="https://nnov.hse.ru/data/2017/07/13/1170958979/The%20comparative%20analysis%20of%20big%20networks.pdf" target="_blank">обзор разных топологий</a>.</li> 474 </ul> 475 Стоит лишь помнить, что это топологии, для которых ещё не разработаны протоколы Control Plane'а. 476 Однако говорят, что их уже используют в HPC - если у вас есть тому свидетельства, буду рад добавить в статью. 477 <hr> 478 479 <a name="DEVICES"></a> 480 <h1>Выбор оборудования</h1> 481 Тут, наверняка, нет универсального совета. 482 Но мы попробуем порассуждать. 483 И стоит вспомнить о промежуточном дизайне сети ДЦ, который был между 3-Tier и полноценным многоуровневым Клозом, построенным из однотипных элементов. 484 Как только начали переходить на L3, сразу появился соблазн использовать ECMP и ставить много (больше, чем два) агрегирующих устройств. 485 Так, например, в Facebook появились кластера - набор стоек с ToR'ами, подключенными в четыре кластерных свитча. 486 Кластера подразумевали сотни стоек, то есть сотни портов на кластерных свитчах. 487 В те годы это могли быть только большие модульные шкафы с линейными картами, фабриками коммутации, отдельными платами управления, выжирающие электропитание и греющие горячий коридор. 488 С такими модульными коммутаторами есть несколько проблем: 489 <b>Во-первых</b>, такие устройства имеют сложную внутреннюю архитектуру. Так каждая линейная карта имеет как минимум один чип коммутации (а то и два), свой чип Traffic Management, подключение к общей шине. 490 Фабрики коммутации сами по себе сложны по количеству взаимосвязанных компонентов, хотя и не выполняют интеллектуальные функции. 491 Над всем этим есть VoQ, какие-то общие на коробку диспетчеры. 492 Control Plane работает на управляющей плате и должен синхронно и гарантировано доставить данные в Data Plane всех линейных карт. 493 Эта архитектура, как и управляющий софт, закрыты и крайне сложны для отладки. 494 <b>Во-вторых</b>, именно из-за наличия такого количества чипов, вероятность того, что где-то начнутся потери - она не только есть, но такие ситуации, увы, часто случаются. 495 Самое в них неприятное, что они тяжело отлавливаются, потому что никак не дают о себе знать - в ошибках на интерфейсах всё чисто, дропы в очередях QoS тоже по нулям, в логах пусто. Да и связность не полностью пропадает - она или с потерями или всё в целом нормально, но отсутствует связность между конкретными префиксами. Учитывая количество путей, по которым раскладывается трафик, отследить где именно и почему что-то теряется становится задачей нетривиальной и зачастую сводящейся к тому, чтобы поочерёдно перезагружать подозрительные устройства (поднимите руки, кому не приходилось этого делать). 496 497 <blockquote> 498 Вызваны они бывают как внешними факторами, так и внутренними. 499 На моей памяти было два случая, когда происходило замятие контактов на задней части платы, которая вставляется в общую шину. Один раз достаточно сильный инженер засадил линейку в шасси, не заметив, что к контактам прилипла гайка - не только замял контакты но и сжёг шину замыканием. 500 Бывают наоборот слабые инженеры, которые недовставят плату, и часть SerDes'ов не работают - отсюда и частая рекомендация TAC - вытащить и вставить. 501 502 Гораздо более частая причина - неверно запрограммированный FIB - это уже косяк ПО. Когда запись прогружается из RIB в FIB, что-то может пойти не так, и запись не доедет до чипа. 503 Спрашивайте своего вендора, как проверять актуальность FIB, причём именно аппаратного - есть ли интересующая вас запись в чипе, а не просто в оперативной памяти линейной карты. 504 505 В наше время девятинанометровых техпроцессов случаются ситуации, когда бит в ячейке памяти меняет своё значение почти спонтанно. Условно, альфа-частица во время солнечной активности или от куска урана, распадающегося на соседнем юните в стойке, может пролететь через чип и привести к этому. 506 Это повреждает записанную в ячейке информацию или инструкцию и ломает передачу данных. 507 </blockquote> 508 509 А <b>в-третьих</b>, такие гигантские коробки производит всего несколько вендоров. Само по себе это, возможно, и не является проблемой, но привязанность к производителю может выйти боком. 510 511 Так или иначе, через подобный дизайн проходили все. 512 513 Модная тенденция этой осени - строить фабрику на пицца-боксах - одночиповых коммутаторах небольшого размера - от одного до четырёх рэк-юнитов. 514 Это в определённом смысле очень выигрышный подход. С одной стороны он позволяет убрать всю эту скрытую архитектурную сложность модульных шасси - если одночиповая коробка ломается, то ломается целиком, а не частично (впрочем, есть у меня для вас пара историй). С другой - они маленькие, дешёвые и производительные - то, что надо в парадигме горизонтального масштабирования. Очень легко докупается ещё одна коробочка на 64х100G порта в качестве спайна для расширения пропускной способности. 515 <hr> 516 517 И тут как раз происходит смещение с подхода с кластерными свитчами на полноценную 5- (и больше) уровневую топологию Клоза. 518 519 Сегодня можно найти фантастические по меркам пятилетней давности штуковины. 520 Например, на ToR 48х25G+6х100G, как вам? 521 А 128х100G, умещённые в 4 юнита? 12,8 Тб/с на одном чипе - шутка ли? 522 523 До едва ли не прошлого года был здесь нюанс с тем, что производитель чипов для датацнетровых коммутаторов был ровно один - Broadcom, заваливший рынок своими Tomahawk/Tomohawk+/2, Trident1/2/3 и Jericho. 524 525 Сегодня стали появляться мощные конкуренты - Mellanox со своими Spectrum'ами, Barefoot с Tophino, Innovium - и стало уже можно выбирать, и даже немного манипулировать. 526 Некоторые вендоры делают ставку на чипы собственного производства. 527 Но выбор чипа - это уже тема отдельной статьи. 528 <hr> 529 <a name="THEEND"></a> 530 <h1>Заключение</h1> 531 Картинка, как по мне, получается красивая. Но всегда следует помнить, что и инженеры, и админы, и девопсы, и архитекторы решают задачи бизнеса, а не диктуют как бизнесу подстраиваться под классную сеть, которую они придумали. Поэтому место найдётся и для топологий Клоза и для 3-Tier и для MSTP в ядре (увы). 532 Кстати, сеть Клоза на самом деле изобретена не Клозом, а Эдсоном Эрвином на 15 лет раньше, но кого это теперь волнует? :) 533 534 <a name="LINKS"></a> 535 <h1>Полезные ссылки</h1> 536 537 <b>Сети Клоза:</b> 538 <ul> 539 <li><a href="https://www.gdt.id.au/~gdt/presentations/2016-07-05-questnet-sdn/papers/bell195303--clos--a-study-of-non-blocking-switching-networks.pdf" target="_blank">Оригинальная публикация <i>A study of non-blocking switching networks by Charles Clos</i></a>. 540 Натурально научный угар. Если не верите, вот вам скринпруф: 541 <img src="https://fs.linkmeup.ru/images/adsm/2/formulas.png" width="500"> 542 </li> 543 <li>Короткая вводная в сеть Клоза: <a href="https://www.networkworld.com/article/2226122/clos-networks-what-s-old-is-new-again.html" target="_blank">Clos Networks: What's Old Is New Again</a>.</li> 544 <li>Про сеть Клоза до мельчайших винтиков: 545 Demystifying DCN Topologies: Clos/Fat Trees – <a href="https://packetpushers.net/demystifying-dcn-topologies-clos-fat-trees-part1/" target="_blank">Part1</a> и <a href="https://packetpushers.net/demystifying-dcn-topologies-clos-fat-trees-part2/" target="_blank">Part2</a>.</li> 546 <li>Поверхностный, но очень понятный разбор устройства сети Facebook: <a href="https://www.youtube.com/watch?time_continue=240&v=mLEawo6OzFM" target="_blank">Introduction to Facebook's data center fabric</a>.</li> 547 </ul> 548 549 <b>О вреде God Boxes в ДЦ:</b> 550 <ul> 551 <li><a href="https://comeroutewithme.com/2015/02/28/why-is-clos-spineleaf-the-thing-to-do-in-the-data-center/" target="_blank">Why is Clos (Spine/Leaf) the thing to do in the Data Center?</a></li> 552 </ul> 553 554 <b>Подходы к маршрутизации в L3 ДЦ:</b> 555 <ul> 556 <li>Первый доклад Дмитрия Афанасьева о сетях в ДЦ: <a href="https://www.youtube.com/watch?v=U86Xjx1rcHY&t=1051s" target="_blank">Next Hop 2019: конференция по сетям</a></li> 557 <li><a href="https://tools.ietf.org/html/rfc7938" target="_blank">RFC 7938. Use of BGP for Routing in Large-Scale Data Centers</a></li> 558 <li><a href="https://cumulusnetworks.com/lp/bgp-ebook/" target="_blank">Cumulus. BGP in the data center</a></li> 559 <li>Про оптимизацию BGP: <a href="https://www.ipspace.net/BGP_Convergence_Optimization" target="_blank">BGP Convergence Optimization</a></li> 560 </ul> 561 562 <b>Альтернативные топологии:</b> 563 <ul> 564 <li><a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3926393/" target="_blank">Application of Butterfly Clos-Network in Network-on-Chip</a></li> 565 <li><a href="https://www.researchgate.net/publication/220771890_Flattened_butterfly_a_cost-efficient_topology_for_high-radix_networks" target="_blank">Flattened butterfly: a cost-efficient topology for high-radix networks.</a></li> 566 <li><a href="https://people.inf.ethz.ch/asingla/papers/jellyfish-nsdi12.pdf" target="_blank">Jellyfish: Networking Data Centers Randomly</a></li> 567 <li><a href="https://www.researchgate.net/publication/313341364_Dragonfly_Low_Cost_Topology_for_Scaling_Datacenters" target="_blank">Dragonfly+: Low Cost Topology for Scaling Datacenters</a></li> 568 </ul> 569 <hr> 570 571 <h1>Спасибы</h1> 572 <ul> 573 <li>Андрею Глазкову aka @glazgoo за вычитку и правки</li> 574 <li>Александру Клименко aka @v00lk за то, что перевернул взгляд на топологии</li> 575 <li>Артёму Чернобаю за КДПВ</li> 576 </ul> 577 <hr>