У сучасних дата-центрах встановлено сотні активних пристроїв, покритих різними видами моніторингу. Але навіть ідеальний інженер з ідеальним моніторингом у руках зможе правильно відреагувати на мережний збій лише за кілька хвилин. У доповіді на конференції Next Hop 2020 я представив методологію дизайну мережі ДЦ, яка має унікальну особливість — дата-центр лікує себе сам за мілісекунди. Точніше, інженер спокійно лагодить проблему, тоді як сервіси її просто не помічають.
Для багатьох мережевих інженерів мережа дата-центру починається, звичайно, з ToR, зі світчу в стійці. ToR зазвичай має два типи лінків. Маленькі йдуть до серверів, інші - їх у N разів більше - йдуть у бік спайнів першого рівня, тобто до аплинок. Аплинки зазвичай вважаються рівнозначними, і трафік між аплінками балансується на основі хешу від 5-tuple, до якого входять proto, src_ip, dst_ip, src_port, dst_port. Тут жодних сюрпризів.
Далі, як виглядає архітектура плейнів? Спайни першого рівня між собою не з'єднані, а з'єднуються за допомогою суперспайнів. За суперспайни у нас відповідатиме літера X, вона практично як кросконнект.
І зрозуміло, що з іншого боку до всіх спайнів першого рівня підключені тори. Що важливо на цій картинці? Якщо у нас йде взаємодія всередині стійки, то взаємодія, ясна річ, йде через ToR. Якщо взаємодія йде всередині модуля, взаємодія йде через спайни першого рівня. Якщо міжмодульна взаємодія — як тут, ToR 1 і ToR 2, — то взаємодія піде через спайни як першого, так і другого рівня.
Теоретично така архітектура легко масштабується. Якщо у нас є портова ємність, запас місця в дата-центрі та заздалегідь прокладене волокно, то завжди кількість плейнів можна збільшити, тим самим підвищуючи загальну ємність системи. На папері зробити таке дуже просто. Було б так у житті. Але сьогоднішня розповідь не про це.
Я хочу, щоб було зроблено правильні висновки. У нас усередині дата-центру багато шляхів. Вони умовно незалежні. Один шлях усередині дата-центру можливий лише усередині ToR. Усередині модуля у нас кількість шляхів дорівнює кількості плейнів. Кількість шляхів між модулями дорівнює добутку числа плейнів на число суперспайнів у кожному плейні. Щоб було зрозуміліше, щоб відчути масштаб, я дам цифри, які є справедливими для одного з дата-центрів Яндекса.
Плейнів вісім, у кожному плейні 32 суперспайни. У результаті виходить, що всередині модуля вісім шляхів, а за міжмодульної взаємодії їх уже 256.
Тобто, якщо ми розробляємо Cookbook, намагаємося навчитися тому, як будувати відмовостійкі дата-центри, які лікують себе самостійно, то плейнова архітектура — правильний вибір. Вона дозволяє вирішити задачу масштабування, і теоретично легко. Є багато незалежних шляхів. Залишається питання: як така архітектура переживає збої? Бувають різні збої. І ми зараз це обговоримо.
Нехай у нас один із суперспайнів «захворів». Я тут повернувся до архітектури двох плейнів. Як приклад ми зупинимося на них, тому що тут просто буде легше бачити, що відбувається, з меншою кількістю частин, що рухаються. Нехай X11 захворів. Як це вплине на послуги, які живуть усередині дата-центрів? Дуже багато залежить від того, як збій виглядає насправді.
Якщо збій хороший, ловиться на рівні автоматики того ж BFD, автоматика радісно кладе проблемні стики та ізолює проблему, то все гаразд. У нас безліч шляхів, трафік моментально перемаршрутизується на альтернативні маршрути, і сервіси нічого не помітять. Це добрий сценарій.
Поганий сценарій — якщо у нас виникають постійні втрати, то й автоматика проблеми не помічає. Щоб зрозуміти, як це впливає на програму, нам доведеться витратити трохи часу на обговорення того, як працює протокол TCP.
Я сподіваюся, що нікого не шокую цією інформацією: TCP – протокол із підтвердженням передачі. Тобто у найпростішому випадку у нас відправник відправляє два пакети і отримує на них кумулятивний ack: «Я отримав два пакети».
Після цього він відправить ще два пакети, і ситуація повториться. Я заздалегідь перепрошую за деяке спрощення. Такий сценарій вірний, якщо вікно (кількість пакетів у польоті) дорівнює двом. Звісно, у випадку це необов'язково так. Але на контекст перенаправлення пакетів розмір вікна не впливає.
Що буде, якщо ми втратимо пакет 3? У цьому випадку одержувач отримає пакети 1, 2 і 4. І він у явному вигляді за допомогою опції SACK повідомить відправнику: "Ти знаєш, три дійшло, а середка загубилася". Він каже: "Ack 2, SACK 4".
Відправник зараз без проблем повторює саме той пакет, який загубився.
Але якщо загубиться останній пакет у вікні, ситуація виглядатиме зовсім інакше.
Одержувач отримує перші три пакети і перш за все починає чекати. Завдяки деяким оптимізаціям в TCP-стеку ядра Linux він чекатиме парного пакета, якщо немає явної вказівки у прапорах, що це останній пакет або щось подібне. Він зачекає, поки закінчиться Delayed ACK тайм-аут, і після цього відправить підтвердження на перші три пакети. Але тепер уже відправник чекатиме. Він же не знає, загубився четвертий пакет чи ось-ось дійде. А щоб не перевантажувати мережу, він намагатиметься дочекатися моменту явної вказівки, що пакет втрачений, або закінчення RTO timeout.
Що таке Timeout RTO? Це максимум від вирахованого TCP-стеком RTT та деякої константи. Що це за константа, ми зараз обговоримо.
Але важливо, якщо нам знову не щастить і четвертий пакет знову втрачається, то RTO подвоюється. Тобто, кожна невдала спроба — це подвоєння таймууту.
Тепер подивимося, чому дорівнює ця база. За дефолтом мінімальний RTO дорівнює 200 мс. Це мінімальний RTO для дата пакетів. Для SYN-пакетів він інший, 1 секунда. Як можна бачити, навіть перша спроба перенаправляти пакети буде за часом займати в 100 разів більше, ніж RTT всередині дата-центру.
Тепер повернемось до нашого сценарію. Що відбувається у сервісу? Сервіс починає втрачати пакети. Нехай сервісу спочатку умовно щастить і втрачається щось у середині вікна, тоді він отримує SACK, пересилає пакети, що загубилися.
Але якщо невдача повторюється, то у нас трапляється RTO. Що тут важливе? Так, у нас у мережі дуже багато шляхів. Але TCP-трафік одного конкретного TCP-з'єднання продовжуватиме йти через один і той же битий стек. Втрати пакетів за умови, що цей наш чарівний X11 не гасне самостійно, не призводять до того, що трафік перетікає на ділянки, які не є проблемними. Ми намагаємося доставити пакет через той самий битий стек. Це призводить до каскадної відмови: дата-центр - це безліч взаємодіючих додатків, і частина TCP-з'єднань всіх цих додатків починають деградувати - тому що суперспайн зачіпає взагалі всі додатки, які є всередині ДЦ. Як у приказці: не підкували коня — кінь зашкутильгав; кінь закульгав — повідомлення не доставили; повідомлення не доставили - програли війну. Тільки тут рахунок йде на секунди з моменту виникнення проблеми до стадії деградації, яку відчувають сервіси. А значить, десь можуть недоотримати користувачі.
Є два класичні рішення, які один одного доповнюють. Перше — це сервіси, які намагаються підкласти соломки та вирішити проблему так: «А давайте ми підкрутимо щось у TCP-стеку. А давайте ми зробимо таймаути на рівні програми або довго живуть TCP-сесії з внутрішніми health checks». Проблема в тому, що такі рішення: а) взагалі не масштабуються; б) дуже погано перевіряються. Тобто навіть якщо сервіс випадково налаштує TCP-стек так, щоб йому стало краще, по-перше, це навряд чи буде застосовано для всіх додатків та всіх дата-центрів, а по-друге, швидше за все, він не зрозуміє, що зроблено правильно , а що немає. Тобто він працює, але працює погано і не масштабується. І якщо виникає мережева проблема, хто винен? Звісно, NOC. Що робить NOC?
Багато сервісів вважають, що у NOC робота відбувається приблизно так. Але, якщо говорити чесно, не тільки.
NOC у класичній схемі займається розробкою безлічі моніторингів. Це як black box моніторинги, так і white box. Про приклад black box-моніторингу спайнів Олександр Клименко минулого Next Hop. До речі, цей моніторинг працює. Але навіть ідеальний моніторинг матиме лаг у часі. Зазвичай, це кілька хвилин. Після того, як він спрацьовує, черговим інженерам потрібен час, щоб перевірити ще раз його роботу, локалізувати проблему і після цього погасити проблемну ділянку. Тобто в кращому випадку лікування проблеми займає 5 хвилин, у гіршому 20 хвилин, якщо відразу виявляється не очевидно, де виникають втрати. Зрозуміло, що весь цей час — 5 або 20 хвилин — у нас продовжуватимуть боліти сервіси, що, мабуть, недобре.
Що дуже хотілося б отримати? У нас стільки шляхів. А проблеми виникають саме тому, що TCP-потоки, яким не щастить, продовжують використовувати той самий маршрут. Потрібно щось, що дозволить нам використовувати велику кількість маршрутів в рамках одного TCP-з'єднання. Здавалося б, ми маємо рішення. Є TCP, який і називається — multipath TCP, тобто TCP для безлічі шляхів. Щоправда, він розроблявся для зовсім іншого завдання — для смартфонів, які мають кілька мережевих пристроїв. Щоб максимізувати передачу або зробити режим primary/backup, було розроблено механізм, який прозоро додатку створює кілька потоків (сеансів) і дозволяє у разі виникнення збою перемикатися між ними. Або, як я сказав, максимізувати смугу.
Але тут є нюанс. Щоб зрозуміти, у чому він, нам доведеться подивитись, як встановлюються потоки.
Потоки встановлюються послідовно. Спочатку встановлюється перший потік. Потім з використанням куки, яка вже узгоджена в рамках цього потоку, встановлюються такі потоки. І тут проблема.
Проблема в тому, що якщо перший потік не встановиться, другі та треті потоки ніколи не виникнуть. Тобто multipath TCP не вирішує втрату SYN пакета у першого потоку. І якщо SYN губиться, multipath TCP перетворюється на звичайний TCP. Отже, в середовищі дата-центру не допоможе нам вирішити проблему втрат у фабриці та навчитися використовувати безліч шляхів у разі збою.
Що нам може допомогти? Дехто з вас уже здогадався з назви, що важливим полем у нашій подальшій розповіді стане поле заголовка IPv6 flow label. І справді, це поле, яке з'являється в v6, його немає в v4, воно займає 20 біт, і з приводу його використання тривалий час точилися суперечки. Це дуже цікаво - суперечки йшли, щось фіксувалося в рамках RFC, а в Linux-ядрі водночас з'явилася реалізація, яка так ніде й не задокументована.
Я пропоную вам разом зі мною вирушити на невелике розслідування. Погляньмо, що відбувалося в ядрі Linux за останні кілька років.
2014. Інженер з однієї великої та поважної компанії додає у функціональність ядра Linux залежність значення flow label від хешу сокету. Що тут намагалися полагодити? Це з RFC 6438, у якому обговорювалася наступна проблема. Усередині дата-центру найчастіше інкапсулюється IPv4 в пакети IPv6, тому що сама фабрика — IPv6, але назовні треба віддати IPv4. Довгий час були проблеми зі свічками, які не могли заглянути під два IP-заголовки, щоб дістатися TCP або UDP і знайти там src_ports, dst_ports. Виходило, що хеш, якщо дивитися на два перші IP-заголовки, виявлявся чи не фіксованим. Щоб цього уникнути, щоб балансування цього інкапсульованого трафіку працювало коректно, запропонували значення поля flow label додати хеш від 5-tuple інкапсульованого пакета. Приблизно те саме було зроблено і для інших схем інкапсуляції, для UDP, для GRE, в останньому використовувалося поле GRE Key. Так чи інакше, тут цілі зрозумілі. І принаймні на той час вони були корисні.
У 2015 році від цього ж шановного інженера надходить новий патч. Він дуже цікавий. У ньому йдеться таке — ми рандомізуватимемо хеш у разі негативної події маршрутизації. Що таке негативна подія маршрутизації? Це RTO, яке ми з вами раніше обговорювали, тобто втрата хвоста вікна — подія, яка справді негативна. Щоправда, складно здогадатися, що це саме воно.
2016 рік, інша шановна компанія, також велика. Вона розбирає останні милиці і робить так, що хеш, який ми зробили раніше рандомізованим, тепер змінюється на кожен ретрансміт SYN і після кожного RTO таймауту. І в цьому листі вперше і востаннє звучить кінцева мета — зробити так, щоб трафік у разі виникнення втрат або перевантаження каналів мав можливість м'якої перемаршрутизації, використання безлічі шляхів. Звичайно, після цього було багато публікацій, ви легко їх зможете знайти.
Хоча ні, не зможете, бо жодної публікації на цю тему не було. Але ж ми знаємо!
І якщо ви не до кінця зрозуміли, що було зроблено, я вам зараз розповім.
Що ж було зроблено, яку функціональність додали до ядра Linux? txhash змінюється рандомное значення після кожної події RTO. Цей цей негативний результат маршрутизації. Хеш залежить від цього txhash, а flow label залежить від skb hash. Тут є деякі викладки щодо функцій, на один слайд всі деталі не помістити. Якщо комусь цікаво, можна пройти за кодом ядра та перевірити.
Що тут важливе? Значення поля flow label змінюється випадкове число після кожного RTO. Як це впливає наш нещасливий TCP-потік?
У випадку SACK нічого не змінилося, тому що ми намагаємося переслати відомий втрачений пакет. Поки що все відносно добре.
Але у випадку RTO, за умови, що ми додали flow label у хеш-функцію на ToR, трафік може піти іншим маршрутом. І чим більше плейнів, тим більше шансів, що він знайде шлях, який не зачепить збоєм на конкретному пристрої.
Залишається одна проблема – RTO. Інший маршрут, звичайно, знаходиться, але дуже багато на це витрачається часу. 200 мс – це багато. Секунда – це взагалі дикість. Раніше я розповідав про таймаути, які налаштовують послуги. Так ось, секунда - це тайм-аут, який зазвичай налаштовує сервіс на рівні програми, і в цьому сервіс буде навіть щодо прав. Притому, що, повторюся, справжній RTT усередині сучасного дата-центру — близько 1 мілісекунди.
Що можна зробити із RTO-таймаутами? Таймаут, який відповідає за RTO у разі втрати пакетів з даними, відносно легко можна налаштувати з user space: є утиліта IP, і в одному з її параметрів є той самий rto_min. Зважаючи на те, що крутити RTO, безумовно, потрібно не глобально, а для заданих префіксів такий механізм виглядає цілком робочим.
Щоправда, з SYN_RTO дещо гірше. Він натурально прибитий цвяхами. У ядрі зафіксовано значення – 1 секунда, і все. З user space дотягнутися туди не можна. Є лише один спосіб.
На допомогу приходить eBPF. Якщо говорити спрощено, це невеликі програми на C. Їх можна вставити в хуки в різних місцях виконання стеку ядра і TCP-стека, за допомогою якого можна змінювати дуже багато налаштувань. Взагалі, eBPF – це довгостроковий тренд. Замість того, щоб пиляти десятки нових параметрів sysctl і розширювати утиліту IP, рух йде саме у бік eBPF і розширення його функціональності. За допомогою eBPF можна динамічно змінювати congestion controls та інші різноманітні налаштування TCP.
Але нам важливо, що його можна крутити значення SYN_RTO. Причому є публічно викладений приклад: . Що тут зроблено? Приклад робітник, але сам собою дуже грубий. Тут передбачається, що всередині дата-центру ми порівнюємо перші 44 біти, якщо вони збігаються, отже, ми опиняємось усередині ДЦ. І тут ми змінюємо значення SYN_RTO timeout на 4ms. Те саме завдання можна зробити куди витонченішим. Але цей простий приклад показує, що таке: а) можливо; б) щодо просто.
Що ми знаємо? Що плейнова архітектура дозволяє масштабуватись, вона виявляється нам надзвичайно корисною, коли ми включаємо flow label на ToR і отримуємо можливість обтікати проблемні ділянки. Найкращий спосіб знизити значення RTO та SYN-RTO – використовувати eBPF-програми. Залишається питання: а чи безпечно використовувати flow label для балансування? І тут є нюанс.
Нехай у вас в мережі є сервіс, який мешкає в будь-якому часі. На жаль, у мене немає часу докладно розповідати, що таке anycast, але це розподілений сервіс, різні фізичні сервери якого доступні за однією і тією ж IP-адресою. І тут можлива проблема: подія RTO може виникнути не лише під час проходження трафіку через фабрику. Воно може виникнути і на рівні буфера ToR: коли відбувається incast-подія, вона може виникнути навіть на хості, коли хост щось проливає. Коли відбувається подія RTO, вона змінює flow label. У цьому випадку трафік може потрапити на інший будь-який часвхід. Припустимо, це stateful anycast, він містить у собі connection state — це може бути L3 Balancer або ще якийсь сервіс. Тоді виникає проблема, тому що після RTO TCP-з'єднання прилітає на сервер, який про це з'єднання TCP нічого не знає. І якщо ми не маємо шерингу стейтів між anycast-серверами, то такий трафік буде скинутий і TCP-з'єднання порветься.
Що тут можна зробити? Всередині вашого контрольованого середовища, де ви включаєте балансування flow label, необхідно фіксувати значення flow label при зверненні до будь-яких cast-серверів. Найпростіший спосіб зробити це через ту ж eBPF-програму. Але тут дуже важливий момент — що робити, якщо ви оперуєте не мережею дата-центру, а оператором зв'язку? Це і ваша проблема теж: починаючи з певних версій Juniper і Arista включають flow label в хеш-функції по дефолту — щиро кажучи, з незрозумілої причини. Це може призвести до того, що ви будете рвати TCP-з'єднання користувачів, що йдуть через мережу. Тому я настійно рекомендую перевірити налаштування ваших маршрутизаторів у цьому місці.
Так чи інакше мені здається, що ми готові перейти до експериментів.
Коли ми включили flow label на ToR, підготували агента eBPF, який тепер живе на хостах, ми вирішили не чекати наступного великого збою, а провести контрольовані вибухи. Ми взяли ToR, у якого чотири аплінки, і на одному з них влаштували дропи. Намалювали правило, сказали – тепер ти втрачаєш усі пакети. Як можна бачити зліва, у нас per-packet monitoring, який просів до значення 75%, тобто 25% пакетів губляться. Праворуч графіки сервісів, які мешкають за цим ToR. По суті, це графіки трафіку стиків з серверами всередині стійки. Як можна бачити, вони просіли навіть нижче. Чому вони просіли нижче — не на 25%, а в деяких випадках у 3–4 рази? Якщо TCP-з'єднання не щастить, воно продовжує намагатися достукатися через битий стик. Це посилюється типовою поведінкою сервісу всередині ДЦ — на один запит користувача генерується N запитів до внутрішніх сервісів, і відповідь піде до користувача, або коли дадуть відповідь на всі джерела даних, або коли спрацює тайм на рівні програми, який ще повинен бути налаштований. Тобто все дуже і дуже погано.
Тепер той самий експеримент, але з включеним значенням flow label. Як можна бачити, ліворуч наш пакетний моніторинг просів на ті самі 25%. Це абсолютно коректно, тому що він нічого не знає про ретрансміти, він відправляє пакети і просто вважає відношення кількості доставлених та втрачених пакетів.
А праворуч перебуває графік сервісів. Ви тут не знайдете ефекту від проблемного стику. Трафік за ті самі мілісекунди перетік із проблемної ділянки в три аплінки, що залишилися, не порушених проблемою. Ми отримали мережу, яка лікує себе сама.
Це мій останній слайд, час підбити підсумки. Тепер, сподіваюся, ви знаєте, як будувати мережу дата-центру, здатну до самолікування. Вам не потрібно буде ходити архівом ядра Linux і вишукувати там спеціальні патчі, ви знаєте, що Flow label в даному випадку вирішує проблему, але підходити до цього механізму потрібно обережно. І я ще раз наголошую, що якщо ви оператор зв'язку, ви не повинні використовувати flow label як хеш-функцію, інакше ви рватимете сесії ваших користувачів.
У мережевих інженерів має відбутися концептуальне зрушення: мережа починається не з ToR, не з мережевого пристрою, а з хоста. Досить яскравий приклад — те, як ми використовуємо eBPF для зміни RTO, і для фіксації flow label у бік anycast-сервісів.
Механіка flow label, безперечно, підходить і для інших застосувань усередині контрольованого адміністративного сегменту. Це може бути трафік між дата-центрами, а можна особливим способом використовувати таку механіку і для керування вихідним трафіком. Але про це я розповім, сподіваюся, наступного разу. Щиро дякую за увагу.
Джерело: habr.com