Ми розробили дизайн мережі дата-центрів, який дозволяє розгортати обчислювальні кластери розміром більше 100 тисяч серверів із піковою смугою бісекції (bisection bandwidth) понад один петабайт на секунду.
З доповіді Дмитра Афанасьєва ви дізнаєтеся про основні принципи нового дизайну, масштабування топологій, що виникають при цьому проблемах, варіанти їх вирішення, про особливості маршрутизації та масштабування функцій forwarding plane сучасних мережевих пристроїв у «щільних» (densely connected) топологіях з великою кількістю ECMP-маршрутів . Крім того, Діма коротко розповів про організацію зовнішньої зв'язності, фізичний рівень, кабельну систему та способи подальшого збільшення ємності.
- Всім добрий день! Мене звуть Дмитро Афанасьєв, я мережевий архітектор Яндекса і займаюсь переважно дизайном мереж дата-центрів.
Моя розповідь буде про оновлену мережу дата-центрів Яндекса. Це значною мірою еволюція дизайну, який у нас був, але водночас є деякі нові елементи. Це оглядова презентація, оскільки потрібно було вмістити досить багато інформації у короткий час. Ми розпочнемо з вибору логічної топології. Потім буде огляд control plane і проблем із масштабованістю data plane, вибір того, що відбуватиметься фізично, подивимося на деякі особливості пристроїв. Трохи торкнемося і того, що відбувається в дата-центрі з MPLS, про який ми говорили деякий час тому.
Отже, що таке Яндекс з погляду навантажень і сервісів? Яндекс – типовий гіперскейлер. Якщо дивитися в бік користувачів, у нас відбувається в першу чергу обробка запитів користувача. Також різні стрімінг-сервіси та віддача даних, тому що storage-сервіси у нас також є. Якщо ближче до бекенду, то там з'являються інфраструктурні навантаження та сервіси, такі як розподілені об'єктні сховища, реплікація даних та, звичайно, persistent queues. Один з основних типів навантажень — MapReduce тощо, потокова обробка, machine learning і т.д.
Як улаштована інфраструктура, поверх якої це все відбувається? Знову ж таки, ми цілком типовий гіперскейлер, хоча, можливо, знаходимося трохи ближче до того боку спектру, де знаходяться менші гіперскейлери. Але ми маємо всі атрибути. Ми використовуємо commodity hardware та горизонтальне масштабування скрізь, де можна. У нас на повне зростання присутній пулінг ресурсів: ми не працюємо з окремими машинами, окремими стійками, а об'єднуємо їх у великий пул взаємозамінних ресурсів з якимись додатковими сервісами, які займаються плануванням та алокацією, та працюємо з усім цим пулом.
Так ми маємо наступний рівень — операційної системи рівня обчислювального кластера. Дуже важливо, що ми повністю контролюємо стек технологій, що у нас використовується. Ми контролюємо енд-поінти (хости), мережу та програмний стек.
У нас є кілька великих дата-центрів у Росії та за кордоном. Їх поєднує backbone, що використовує технологію MPLS. Наша внутрішня інфраструктура практично повністю побудована на IPv6, але оскільки нам потрібно обслуговувати зовнішній трафік, що все ще надходить в основному IPv4, ми повинні якось доставляти запити, що приходять по IPv4, до фронтенд-серверів, і трошки ще ходити до зовнішнього IPv4- Інтернет - наприклад, для індексування.
Останні кілька ітерацій дизайну мереж дата-центрів використовують багаторівневі Clos-топології, і в них застосовується лише L3. Ми пішли з L2 деякий час тому назад та зітхнули з полегшенням. Нарешті наша інфраструктура включає сотні тисяч обчислювальних (серверних) інстансів. Максимальний розмір кластера якийсь час тому був близько 10 тис. серверів. Це обумовлено значною мірою тим, як можуть працювати ті самі операційні системи рівня кластера, планувальники, алокація ресурсів тощо. Оскільки на стороні інфраструктурного софту стався прогрес, то цільовим є розмір близько 100 тис. серверів в одному обчислювальному кластері, і у нас постало завдання — вміти будувати мережеві фабрики, які дозволяють ефективно здійснювати пулінг ресурсів у такому кластері.
Що ми хочемо від мережі дата-центру? Насамперед — багато дешевої та досить однорідно розподіленої смуги пропускання. Тому що мережа — це та підкладка, за рахунок якої ми можемо робити ресурс ресурсів. Новий цільовий розмір – близько 100 тис. серверів в одному кластері.
Також нам, звичайно, хочеться масштабований і стабільний control plane, тому що на такій великій інфраструктурі досить багато головного болю виникає навіть від випадкових подій, і ми не хочемо, щоб нам приносив головний біль ще й control plane. При цьому ми хочемо мінімізувати стан у ньому. Чим менший стан, тим краще та стабільніше все працює, простіше діагностувати.
Звичайно, нам потрібна автоматизація, тому що вручну керувати такою інфраструктурою неможливо, і неможливо було вже якийсь час тому. Нам потрібна якомога підтримка операційної діяльності та підтримка CI/CD, наскільки це можна забезпечити.
За таких розмірів дата-центрів та кластерів вже досить гостро постало завдання підтримки інкрементального розгортання та розширення без перерви сервісу. Якщо на кластерах розміром тисячу машин, можливо, близько десятка тисяч машин, їх ще можна було викочувати як одну операцію — тобто ми плануємо розширення інфраструктури, і кілька тисяч машин додаються як одна операція, то кластер розміром під сто тисяч машин не виникає Одночасно таким, він будується протягом деякого часу. І бажано, щоб весь цей час те, що вже викачали, та розгорнута інфраструктура була доступна.
І одна вимога, яка у нас була і пішла: це підтримка multitenancy, тобто віртуалізації чи сегментування мережі. Тепер нам не потрібно це робити на рівні мережевої фабрики, тому що сегментування пішло на хости, і це дуже полегшило масштабування. Завдяки IPv6 і великому адресному простору нам не потрібно було у внутрішній інфраструктурі використовувати адреси, що дублюються, вся адресація була і так унікальна. А завдяки тому, що ми фільтрацію та сегментування мережі забрали на хости, нам не потрібно створювати якісь віртуальні мережеві сутності в датацентрових мережах.
Дуже важлива річ — те, що нам не потрібно. Якщо якісь функції можна прибрати з мережі, це полегшує життя, і, як правило, розширює вибір доступного обладнання та програмного забезпечення, дуже спрощує діагностику.
Отже, що нам не потрібно, від чого ми змогли відмовитися, не завжди з радістю в момент, коли це відбувалося, але з великим полегшенням, коли процес завершувався?
Насамперед відмова від L2. Нам не потрібний L2 ні реальний, ні емульований. Не використовується значною мірою завдяки тому, що ми контролюємо стек додатків. Наші програми горизонтально масштабуються, вони працюють з L3 адресацією, вони не дуже турбуються, що якийсь окремий інстанс погас, просто викочують новий, йому не потрібно викочуватися на старій адресі, тому що є окремий рівень service discovery та моніторингу машин, що знаходяться в кластері . Ми не перекладаємо це завдання на мережу. Завдання мережі – доставляти пакети з точки А до точки Б.
Також ми не маємо ситуацій, коли адреси пересуваються всередині мережі, і це потрібно відстежувати. У багатьох дизайнах це, як правило, потрібно підтримувати VM mobility. Ми не використовуємо мобільність віртуальних машин у внутрішній інфраструктурі саме великого Яндекса, і, крім того, вважаємо, що навіть якщо це робиться, це не повинно відбуватися за допомогою мережі. Якщо потрібно зробити, це потрібно робити на рівні хостів, і заганяти адреси, які можуть мігрувати, в оверлеї, щоб не чіпати і не вносити занадто багато динамічних змін в систему маршрутизації власне underlay (транспортної мережі).
Ще одна технологія, яку ми не використовуємо – це мультикаст. Бажаючим можу докладно розповісти чому. Це сильно полегшує життя, тому що, якщо хтось мав з ним справу і дивився, як виглядає саме control plane мультикаста — у всіх інсталяціях, окрім найпростіших, це головний біль. І більше того, важко знайти відкриту реалізацію, що добре працює, наприклад.
І, нарешті, ми проектуємо наші мережі так, щоб у них не відбувалося надто багато змін. Ми можемо розраховувати, що потік зовнішніх подій у системі маршрутизації невеликий.
Які проблеми і які обмеження треба враховувати, коли ми розробляємо мережу дата-центру? Вартість, звісно. Масштабованість, те, до якого рівня ми хочемо зростати. Необхідність розширення без припинення сервісу. Смуга пропускання, доступність. Видимість те, що відбувається у мережі, для систем моніторингу, для операційних команд. Підтримка автоматизації — знову ж таки настільки, наскільки це можливо, оскільки різні завдання можуть вирішуватися на різних рівнях, у тому числі запровадженням додаткових прошарків. Ну і не-залежно від вендорів. Хоча в різні історичні періоди, залежно від того, на який зріз дивитися, ця незалежність була легша або складніша. Якщо візьмемо зріз чіпів мережевих пристроїв, то досі говорити про незалежність від вендорів, якщо ми хотіли ще й чіпи з великою пропускною здатністю, можна було дуже умовно.
За якою ж логічною топологією ми будуватимемо нашу мережу? Це буде багаторівневий Clos. Насправді реальних альтернатив на даний момент немає. І Clos-топологія досить хороша, навіть якщо її порівнювати з різними топологіями, які більше зараз перебувають у сфері академічного інтересу, якщо у нас є комутатори з великим радиксом.
Як приблизно влаштована багаторівнева Clos-мережа і як у ній називаються різні елементи? Насамперед, троянда вітрів, щоб зорієнтуватися, де північ, де південь, де схід, де захід. Мережі такого типу зазвичай будують ті, хто має великий трафік захід — схід. Що стосується решти елементів, вгорі зображено віртуальний комутатор, зібраний з менших комутаторів. Це основна ідея рекурсивної побудови Clos-мереж. Ми беремо елементи з якимось радиксом і з'єднуємо їх так, щоб те, що вийшло, можна було розглядати як комутатор з більшим радиксом. Якщо потрібно ще більше процедуру можна повторити.
У випадках, наприклад, з дворівневими Clos, коли можна чітко виділити компоненти, які на моїй схемі вертикальні, їх називають площинами. Якби ми будували Clos-з трьома рівнями спайн-світчів (усі, які не граничні та не ToR-світчі і які використовуються тільки для транзиту), то площини виглядали б складніше, дворівневі виглядають саме так. Блок ToR- або leaf-світчів та асоційовані з ними спайн-світчі першого рівня ми називаємо Pod. Спайн-світи рівня спайн-1 вгорі Pod - це top of Pod, вершина Pod. Світчі, які розташовуються вгорі всієї фабрики, - це верхній шар фабрики, Top of fabric.
Звичайно, постає питання: Clos-мережі будуються вже деякий час, сама ідея взагалі походить з часів класичної телефонії, TDM-мереж. Може, з'явилося щось краще, може, можна якось краще зробити? І так і ні. Теоретично так, на практиці найближчим часом точно немає. Тому що є кілька цікавих топологій, частина з них навіть використовується в продакшені, наприклад, Dragonfly використовується в HPC-додатках; є також цікаві топології типу Xpander, FatClique, Jellyfish. Якщо подивитися доповіді на конференціях типу SIGCOMM або NSDI за останній час, можна виявити досить велику кількість робіт з альтернативних топологій, які мають кращі властивості (тими чи іншими), ніж Clos.
Але у всіх цих топологій є одна цікава властивість. Воно перешкоджає їхньому впровадженню в мережах дата-центрів, які ми намагаємося будувати на commodity hardware і які коштують досить розумних грошей. У всіх цих альтернативних топологіях більша частина смуги, на жаль, доступна не найкоротшими шляхами. Тому ми відразу позбавляємось можливості використовувати традиційний control plane.
Теоретично вирішення завдання відоме. Це, наприклад, модифікації link state з використанням k-shortest path, але, знову ж таки, немає таких протоколів, які були б реалізовані в продакшені та доступні масово на устаткуванні.
Більше того, оскільки більша частина ємності доступна не найкоротшими шляхами, нам потрібно модифікувати не тільки control plane, щоб він вибирав усі ці шляхи (і, до речі, це значно більший стан у control plane). Нам ще потрібно модифікувати forwarding plane, і, як правило, потрібно як мінімум дві додаткові фічі. Це можливість приймати всі рішення про форвардинг пакетів разово, наприклад, на хості. Фактично це source routing, іноді в літературі з взаємнихзв'язок мереж це називається all-at-once forwarding decisions. І ще adaptive routing - це вже функція, потрібна нам на мережевих елементах, що зводиться, наприклад, до того, що ми вибираємо наступний хоп, виходячи з інформації про найменше завантаження черги. Як приклад, можливі інші варіанти.
Таким чином, напрямок цікавий, але, на жаль, прямо зараз застосувати не можемо.
Окей зупинилися на логічній топології Clos. Як ми її масштабуватимемо? Погляньмо, як вона влаштована і що можна зробити.
У Clos-мережі є два основні параметри, які ми можемо якось варіювати та отримувати ті чи інші результати: radix елементів та кількість рівнів у мережі. У мене схематично зображено, як те та інше впливає на розмір. В ідеалі комбінуємо і те, й інше.
Видно, що підсумкова ширина Clos-мережі - це твір по всіх рівнях спайн-свитчів південного радиксу, те, скільки лінків у нас є вниз, як вона розгалужується. Ось як масштабуємо розмір мережі.
Що стосується ємності, особливо на ToR-світах, тут два варіанти масштабування. Або можемо, зберігаючи загальну топологію, використовувати більш швидкісні лінки, або можемо додавати більше площин.
Якщо подивитися на розгорнутий варіант Clos-мережі (у правому нижньому кутку) і повернутися до цієї картинки з Clos-мережею внизу…
… то це однаково та ж топологія, але у цьому слайді вона схлопнута компактніше і площині фабрики накладені друг на друга. Це одне і теж.
Як виглядає масштабування Clos-мережі у числах? Тут у мене наводяться дані, якої максимальної ширини можна отримати мережу, яка максимальна кількість стійок, ToR-свитків або leaf-свитків, якщо вони не знаходяться в стійках, ми можемо отримати в залежності від того, який у нас радикс свитчів, які використовуються для спайн -Рівень, і скільки рівнів ми використовуємо.
Тут наведено, скільки у нас може бути стійок, скільки серверів і приблизно скільки все це може споживати з розрахунку 20 кВт на стійку. Дещо раніше я згадував, що ми цілимося в розмір кластера близько 100 тис. серверів.
Видно, що у всій цій конструкції інтерес становлять два з половиною варіанти. Є варіант із двома шарами спайнів та 64-портовими свитчами, який трохи недотягує. Потім добре вписуються варіанти для 128-портових (з радиксом 128) спайн-свитчів з двома рівнями, або свитчі з радиксом 32 з трьома рівнями. І у всіх випадках, де більше радикс і більше рівнів, можна зробити дуже велику мережу, але якщо ви подивіться на очікуване споживання, як правило, там гігавати. Кабель можна прокласти, а стільки електрики на одному майданчику ми навряд чи отримаємо. Якщо подивитися статистику, публічні дані щодо дата-центрів - дуже мало можна знайти дата-центрів на розрахункову потужність більше 150 МВт. Те, що більше - як правило, дата-центрові кампуси, кілька великих дата-центрів, розташованих досить близько один до одного.
Існує ще важливий параметр. Якщо подивіться на ліву колонку, там вказано usable bandwidth. Неважко помітити, що в Clos-мережі помітна частина портів йде на те, щоб з'єднувати комутатори один з одним. Usable bandwidth, корисна смуга, це те, що можна віддати назовні, у бік серверів. Звичайно, я говорю про умовні порти і саме про смугу. Як правило, лінки всередині мережі швидше, ніж лінки у бік серверів, але на одиницю смуги, наскільки ми її можемо видати назовні до нашого серверного обладнання, доводиться ще смуги всередині самої мережі. І чим більше рівнів ми робимо, тим більше питомих витрат на те, щоб надати цю смугу назовні.
Понад те, навіть ця додаткова смуга не зовсім однакова. Поки короткі прольоти, ми можемо використовувати щось типу DAC (direct attach copper, тобто twinax-кабелі), або multimode оптики, які ще більш-менш розумних грошей коштують. Як тільки ми переходимо на прольоти довше - як правило, це single mode оптика, і вартість цієї додаткової смуги помітно зростає.
І знову ж таки, повертаючись на попередній слайд, якщо ми робимо Clos-мережа без перепідписки, то неважко подивитися на схему, подивитися, як будується мережа — додаючи кожен рівень спайн-світчів, ми повторюємо всю смугу, яка була внизу. Плюс рівень — плюс вся та сама смуга, ще стільки ж, скільки було на попередньому рівні, портів на комутаторах, ще стільки ж трансіверів. Тому кількість рівнів спайн-свитчів дуже бажано мінімізувати.
Виходячи з цієї картинки, видно, що нам дуже хочеться будуватися на чомусь типу світчів з радіксом 128.
Тут у принципі все те саме, що я зараз розповів, це слайд швидше для розгляду згодом.
Які є варіанти, що ми можемо вибрати як такі комутатори? Дуже приємна для нас звістка, що зараз такі мережі стало можна будувати на одночіпових комутаторах. І це дуже здорово, у них багато приємних особливостей. Наприклад, майже немає внутрішня структура. Це означає, що вони легше ламаються. Вони ламаються, куди без цього, але ламаються, на щастя, цілком. У модульних пристроях є велика кількість несправностей (дуже неприємних), коли з погляду сусідів і control plane воно ніби працює, але, наприклад, у нього пішла частина фабрики, і воно працює не на повну ємність. А трафік на нього балансується виходячи з того, що воно є повністю функціональним, і ми можемо отримати перевантаження.
Або, наприклад, виникають проблеми з бекплейном, тому що всередині модульного пристрою теж є високошвидкісні SerDes - воно по-справжньому складно влаштоване всередині. Або в нього синхронізуються або синхронізуються таблички між forwarding елементами. Загалом, будь-який продуктивний модульний пристрій, що складається з великої кількості елементів, всередині себе, як правило, містить ту саму Clos-мережу, тільки яку дуже важко діагностувати. Найчастіше навіть самому вендору важко діагностувати.
І воно має велику кількість сценаріїв збоїв, за яких пристрій деградує, але не випадає з топології повністю. Оскільки у нас мережа велика, активно використовується балансування між ідентичними елементами, мережа дуже регулярна, тобто один шлях, на якому все гаразд, нічим не відрізняється від іншого шляху, нам вигідніше просто втратити частину пристроїв з топології, ніж потрапляти на ситуацію, коли деякі з них начебто працюють, а начебто ні.
Наступна приємна особливість одночіпових пристроїв - вони краще еволюціонують швидше. Також вони, як правило, мають найкращу ємність. Якщо брати великі зібрані конструкції, які ми маємо, на коло, то ємність на рек-юніт по портах тієї ж швидкості виходить майже вдвічі краще, ніж у модульних пристроїв. Пристрої, побудовані навколо одного чіпа, виходять значно дешевше, ніж модульні, і споживають менше енергії.
Але, звичайно, це все не просто так, є й недоліки. По-перше, практично завжди менший радикс, ніж у модульних пристроїв. Якщо ми можемо пристрій навколо одного чіпа побудований, отримати на 128 портів, то модульний ми можемо отримати на кілька сотень портів зараз вже без особливих проблем.
Це помітно менший розмір форвардинг таблиць і, як правило, всього, що стосується масштабування data plane. Неглибокий буфер. І, зазвичай, досить обмежена функціональність. Але з'ясовується, що якщо знати ці обмеження та вчасно подбати про те, щоб їх обійти чи просто врахувати, це не так страшно. Те, що радикс менше, на пристрої, що з'явилися недавно, нарешті, з радіксом 128 проблемою вже не є, ми можемо побудуватися в два шари спайнів. А менше двох нічого цікавого для нас розміру збудувати все одно не можна. З одним рівнем дуже маленькі кластери виходять. Навіть попередні наші дизайни та вимоги все одно їх перевищували.
Насправді якщо раптом рішення десь на межі, є ще спосіб змасштабуватися. Оскільки останній (або перший), найнижчий рівень, куди підключаються сервери - ToR-світчі або leaf-світчі, ми не зобов'язані підключати до них одну стійку. Тому якщо рішення недотягує десь у два рази, можна подумати про те, щоб просто використовувати комутатор з великим радиксом на нижньому рівні та підключати, наприклад, дві-три стійки в один комутатор. Це теж варіант, у нього є свої витрати, але він цілком працює і може виявитися непоганим рішенням, коли потрібно дотягнути десь удвічі розмір.
Резюмуючи, ми будуємося з топології з двома рівнями спайнів, з вісьмома шарами фабрики.
Що буде з фізикою? Дуже прості розрахунки. Якщо у нас є два рівні спайнів, значить у нас всього три рівні свитків, і ми очікуємо, що в мережі буде три кабельні сегменти: від серверів до leaf-свитків, до спайна 1, до спайна 2. Варіанти, які ми можемо використовувати це twinax, multimode, single mode. І тут потрібно враховувати, яка смуга доступна, скільки це буде коштувати, які фізичні розміри, які прольоти можемо пройти, і як ми будемо апгрейдитися.
За вартістю все можна побудувати в лінійку. Твінакси коштують відчутно дешевше, ніж активна оптика, дешевше ніж multimode трансівери, якщо брати за проліт з кінця, дещо дешевше, ніж 100-гігабітний порт світчу. І він, увага, коштує дешевше, ніж single mode оптика, тому що на прольотах, де потрібно single mode, в дата-центрах з ряду причин осмислено використовувати CWDM, з паралельним single mode (PSM) працювати не дуже зручно, виходять дуже великі пачки волокна, і якщо зупинитись на цих технологіях, виходить приблизно така ієрархія за цінами.
Ще одне зауваження: на жаль, не дуже вдається використати розібрані 100 до 4х25 мультимодні порти. Через особливості конструкції трансіверів SFP28 коштує не набагато дешевше, ніж QSFP28 на 100 Гбіт. І це розбирання для multimode не дуже працює.
Ще деяке обмеження це те, що через розмір обчислювальних кластерів, через кількість серверів наші дата-центри виходять фізично великими. Це означає, що хоча б один проліт доведеться робити із синглмодом. Знову ж таки, через фізичний розмір Pods не вдасться пройти два прольоти twinax-ми (мідними кабелями).
У результаті, якщо оптимізувати за ціною та враховувати геометрію цієї конструкції, ми отримуємо один проліт твінаксом, один проліт мультимодом та один проліт синглмодом з використанням CWDM. Це враховує можливі шляхи апгрейду.
Приблизно так виглядає, що було нещодавно, куди ми рухаємось і що можливо. Зрозуміло, принаймні, як рухатися убік до 50-гігабітних SerDes і для мультимоду, і для синглмоду. Більше того, якщо подивитися те, що є в синглмод трансіверах зараз і на перспективу для 400G, там найчастіше навіть коли приходять 50G SerDes з електричного боку, то в оптику можуть йти вже 100 Gbps per lane. Тому цілком можливо, що замість переходу на 50 відбудеться перехід на 100-гігабітні SerDes і 100 Gbps per lane, тому що за обіцянками багатьох вендорів їхня доступність очікується досить скоро. Період, коли 50G SerDes були найшвидшими, здається, буде не дуже тривалим, тому що 100G SerDes викочуються чи не наступного року перші екземпляри. І через якийсь час після цього вони, можливо, коштуватимуть розумні гроші.
Ще один нюанс щодо вибору фізики. В принципі, вже зараз ми можемо застосовувати 400 або 200-гігабітні порти з використанням 50G SerDes. Але з'ясовується, що в цьому немає особливого сенсу, тому що, як я розповідав раніше, нам хочеться досить великого радіксу на комутаторах, у межах розумного, звісно. Нам хочеться 128. А якщо у нас ємність чіпа обмежена і ми збільшуємо швидкість лінка, то радикс, звичайно, знижується, чудес немає.
А загальну ємність ми можемо збільшити за рахунок площин, і при цьому особливих витрат немає, можна додати кількість площин. А якщо ми втратимо радикс, нам доведеться вводити додатковий рівень, тому при поточних розкладах, при максимально доступній ємності на один чіп, з'ясовується, що ефективніше використовувати 100-гігабітні порти, тому що вони дозволяють отримати більший радикс.
Наступне питання — як організовано фізику, але вже з погляду кабельної інфраструктури. З'ясовується, що вона організована досить кумедно. Кейблінг між leaf-світчами та спайнами першого рівня — там не так багато лінків, там усе будується відносно просто. А ось якщо ми візьмемо одну площину, те, що відбувається всередині, — там потрібно з'єднати всі спайни першого рівня з усіма спайнами другого рівня.
Плюс, як правило, є деякі побажання до того, як це має виглядати усередині дата-центру. Наприклад, нам дуже хотілося об'єднувати кабелі в бандл і тягнути їх так, щоб одна патч-панель високої щільності йшла цілком в одну патч-панель, щоб не було зоопарку по довжинах. Нам вдалося вирішити це завдання. Якщо подивитися на логічну топологію, то видно, що площини незалежні, кожна площина може будуватися сама по собі. Але коли ми додаємо такий бандлінг і хочемо тягнути повністю патч-панель у патч-панель, то доводиться всередині одного бандла змішувати різні площини та вводити проміжну конструкцію у вигляді оптичних крос-коннектів, щоб перепаковувати їх від того, як вони були зібрані на одному сегменті У тому, як вони будуть зібрані на іншому сегменті. Завдяки цьому ми отримуємо приємну особливість: вся складна комутація не виходить за межі стояків. Коли потрібно щось дуже переплести, «розгорнути площини», як це іноді називають у Clos-мережах, це все зосереджено всередині однієї стійки. У нас немає сильно розібраних, аж до індивідуальних лінків, комутацій між стійками.
Так виглядає з погляду логічної організації кабельної інфраструктури. На малюнку ліворуч різнокольорові блоки зображують блоки спайн-свитків першого рівня, по вісім штук, і чотири бандли кабелів, що йдуть від них, ідуть і перетинаються з бандлами, що йдуть від блоків спайн-2-свитчів.
Маленькі квадратики позначають перетину. Вгорі зліва дана розгортка кожного такого перетину, це насправді модуль крос-коннекта 512 на 512 портів, які перепаковують кабелі так, щоб приходити повністю в одну стійку, де тільки одна площина спайн-2. І справа розгортка цієї картинки трохи більш детальна стосовно кількох Pods на рівні спайн-1, і як це упаковується в крос-коннекті, як це приходить на рівень спайн-2.
Ось як це виглядає. Не повністю ще зібрана стійка спайн-2 (ліворуч) та стійка крос-коннекту. На жаль, там не дуже багато що видно. Вся ця конструкція розгортається прямо зараз в одному з наших великих дата-центрів, що розширюється. Це робота в процесі, виглядатиме красивіше, буде заповнено краще.
Важливе питання: обрали логічну топологію, збудували фізику. Що буде з control plane-ом? Досить добре відомо з досвіду експлуатації, є певна кількість виступів, що link state протоколи хороші, з ними приємно працювати, але, на жаль, на щільно пров'язаній топології вони погано масштабуються. І є один основний фактор, який цьому перешкоджає, — це те, як працює флудинг у link state протоколах. Якщо просто взяти алгоритм фледингу, подивитися на те, як влаштована наша мережа, видно, що буде на кожному кроці дуже великий fanout, і просто заливатиме control plane апдейтами. Саме такі топології безпосередньо з традиційним алгоритмом флудингу в link state протоколах поєднується дуже погано.
Вибір – використовувати BGP. Як його правильно готувати, описано в RFC 7938 використання BGP у великих дата-центрах. Базові ідеї прості: мінімальна кількість префіксів на хост і взагалі мінімальна кількість префіксів у мережі, використовувати агрегацію, якщо це можливо, і пригнічувати path hunting. Ми хочемо дуже акуратного, дуже контрольованого поширення апдейтів, те, що називається valley free. Ми хочемо, щоб апдейти, проходячи по мережі, розгорталися рівно один раз. Якщо вони оригінуються внизу, вони йдуть нагору, розвертаються не більше одного разу. Не повинно бути зигзагів. Зигзаги дуже погані.
Щоб це зробити, ми використовуємо досить просту схему для використання базових механізмів BGP. Тобто у нас використовується eBGP, що працює на link local, і автономні системи надаються наступним чином: автономна система на ToR, автономна система на весь блок спайн-1-світчого одного Pod, і загальна автономна система на весь Top of Fabric. Неважко подивитися і переконатися в тому, що при цьому навіть нормальна поведінка BGP дає нам поширення апдейтів, якого нам хочеться.
Звичайно, доводиться дизайнувати адресацію та агрегацію адрес так, щоб це було сумісно з тим, як побудована маршрутизація, щоб це забезпечувало стабільність control plane. L3 адресація в транспорті прив'язана до топології, тому що без цього не можна досягти агрегації, без цього індивідуальні адреси пролазитимуть у систему маршрутизації. І ще одна річ — це те, що агрегація, на жаль, не дуже добре поєднується з multi-path, тому що коли у нас є multi-path і є агрегація, все добре, коли вся мережа працездатна, у ній немає збоїв. На жаль, як тільки в мережі з'являються збої і симетрія топології губиться, ми можемо прийти в точку, з якої анонсувався агрегат, з якої не можна пройти туди, куди нам потрібно. Тому агрегувати найкраще там, де далі немає multi-path, у нашому випадку це ToR-світи.
Насправді агрегувати можна, але обережно. Якщо ми можемо зробити контрольовану дезагрегацію з появою збоїв у мережі. Але це досить складне завдання, ми навіть прикидали, чи вийде це зробити, чи можна навісити додаткову автоматику, і кінцеві автомати, які правильно штовхатимуть BGP, щоб отримати потрібну поведінку. На жаль, обробка corner cases є дуже неочевидною і складною, і шляхом приєднання до BGP зовнішнього навісного обладнання це завдання добре не вирішується.
Дуже цікава робота у цьому плані зроблена в рамках протоколу RIFT, про який буде розказано на наступній доповіді.
Ще одна важлива річ — це те, як масштабуються data plane у щільних топологіях, де ми маємо велику кількість альтернативних шляхів. У цьому використовується кілька додаткових структур даних: ECMP групи, які у свою чергу описують групи Next Hop.
У нормально працюючій мережі, без збоїв, коли ми йдемо по Clos-топології вгору, достатньо використовувати лише одну групу, тому що все, що не локально, описується дефолтом, можна йти вгору. Коли ми йдемо зверху вниз на південь, всі дороги не ECMP, це single path-шляху. Все добре. Біда в тому, і особливість Clos-топології класичної в тому, що якщо ми дивимося на Top of fabric, будь-який елемент, до будь-якого елемента внизу в нього один шлях. Якщо вздовж цього шляху відбуваються збої, то саме цей елемент нагорі фабрики стає невалідним для тих префіксів, які лежать за поламаним шляхом. А для решти він валідний, і нам доводиться розбирати ECMP групи та вводити новий state.
Як виглядає мастштабованість data plane на сучасних пристроях? Якщо ми робимо LPM (longest prefix match), все добре, понад 100к префіксів. Якщо говоримо про Next Hop групи, то все гірше, 2-4 тисячі. Якщо говоримо про таблицю, яка містить опис Next Hops (або adjacencies), це десь від 16к до 64к. І це може стати проблемою. І тут ми підходимо до цікавого відступу: що сталося з MPLS у дата-центрах? В принципі нам його хотілося зробити.
Сталося дві речі. Ми зробили мікросегментацію на хостах, нам стало не потрібно робити це на мережі. Не дуже добре було за допомогою різних вендорів і тим більше з відкритими реалізаціями на white boxes з MPLS. А ще MPLS, принаймні його традиційні реалізації, на жаль, дуже погано поєднується з ECMP. І ось чому.
Такий вигляд має структура ECMP-форвардингу для IP. Велика кількість префіксів може використовувати одну і ту ж групу і той самий блок Next Hops (або adjacencies, в різній документації на різні пристрої це може називатися по-різному). Сенс у тому, що це описується як вихідний порт і що переписати МАС-адресу, щоб потрапити на правильний Next Hop. Для IP все виглядає просто, можна використовувати на дуже велику кількість префіксів на ту саму групу, один і той же блок Next Hops.
Класична архітектура MPLS має на увазі - залежно від вихідного інтерфейсу мітка може переписуватись на різні значення. Тому нам потрібно тримати по групі та по блоку Next Hops на кожну вхідну мітку. І це, на жаль, не масштабується.
Неважко подивитися, що нам у нашій конструкції потрібно було близько 4000 ToR-свитків, максимальна ширина - 64 шляхи ECMP, якщо йти від спайна-1 у бік спайна-2. Ми важко пролазимо, на межі, в одну таблицю ECMP-груп, якщо тільки один префікс з ToR йде, і взагалі не пролазимо в таблицю Next Hops.
Все не безнадійно, тому що архітектури типу Segment Routing мають на увазі глобальні позначки. Формально можна було б знову зіштовхнути всі ці блоки Next Hops. Для цього потрібна операція типу wild card: взяти мітку і переписати на ту саму без конкретного значення. Але, на жаль, у доступних реалізаціях це не дуже присутнє.
І, нарешті, нам потрібно в дата-центр приносити зовнішній трафік. Як це робити? Раніше трафік заводився у Clos-мережі зверху. Тобто, були граничні маршрутизатори, які приєднувалися до всіх пристроїв на Top of fabric. Це рішення працює цілком нормально на невеликих та середніх розмірах. На жаль, щоб заводити трафік у такий спосіб симетрично на всю мережу, потрібно приходити одночасно на всі елементи Top of fabric, і коли їх стає більше сотні, з'ясовується, що нам потрібен великий радикс ще й на граничних маршрутизаторах. Взагалі, це коштує грошей, тому що граничні маршрутизатори функціональніші, порти на них дорожчі будуть, і виходить не дуже гарна конструкція.
Інший варіант – заводити такий трафік знизу. Неважко переконатися, що Clos-топологія побудована так, що трафік, що заходить знизу, тобто з боку ToR, рівномірно розподіляється на рівні Top of fabric за дві ітерації, завантажуючи всю мережу. Тому ми вводимо спеціальний тип Pod, Edge Pod, який забезпечує зовнішню зв'язність.
Є ще одна опція. Приміром, робить Facebook. Це вони називають Fabric Aggregator чи HGRID. Вводиться додатковий рівень спаю, щоб з'єднати кілька дата-центрів. Така конструкція можлива, якщо ми не маємо на стиках додаткових функцій або зміни інкапсуляції. Якщо вони є, це додаткові touch points, це складно. Як правило, виникає більше функцій та свого роду мембрана, що розділяє різні частини дата-центру. Робити таку мембрану великої не варто, а якщо вона дуже потрібна, тобто сенс розглянути можливість віднести її, зробити максимально широкою і перенести на хости. Так робиться, наприклад, у багатьох операторів хмар. У них є overlays, вони починаються з хостів.
Які бачимо можливості розвитку? Насамперед — покращення підтримки CI/CD-пайплайну. Ми хочемо літати так, як ми тестуємо, та тестувати так, як літаємо. Це не дуже добре виходить, тому що інфраструктура більша, продублювати її для тестів неможливо. Потрібно зрозуміти, як вводити елементи тестування до робочої інфраструктури, при цьому не втрачаючи її.
Найкраще інструментування, найкращий моніторинг зайвим не буває практично ніколи. Усе питання у балансі зусиль та віддачі. Якщо можна додати розумними силами — дуже добре.
Відкриті операційні системи для мережевих пристроїв. Найкращі протоколи та найкращі системи маршрутизації, наприклад RIFT. Також потрібні дослідження щодо застосування кращих схем congestion control і, можливо, введення принаймні в деяких точках підтримки RDMA в межах кластера.
Якщо дивитися з прицілом на подальше майбутнє, потрібні просунуті топології і, можливо, мережі, що використовують менший overhead. Зі свіжих речей — нещодавно були публікації про технологію фабрик для HPC Cray Slingshot, в основі якої лежить commodity Ethernet, але з опцією використання набагато коротших заголовків. В результаті overhead зменшується.
Все слід робити настільки простим, наскільки це можливо, але не простіше. Складність - ворог масштабованості. Простота та регулярні структури – наші друзі. Якщо можна десь робити scale out – робіть. І взагалі зараз здорово займатися мережевими технологіями. Відбувається багато цікавого. Дякую.
Джерело: habr.com