GPU-кластерге арналған RoCEv2: желіні баптау және ML алдында тексеру

RoCEv2 GPU-кластерінде неше түрлі мәселелер болуы мүмкін

GPU-кластерде RoCEv2 әдетте жылдам коллективтік операциялар (all-reduce, all-gather) және түйіндер арасында градиенттердің тұрақты тасымалы үшін таңдалады. Егер желі тәртібі бұзылса, оқыту жай ғана баяуламай — ол болжаусыз болады: бір модель бір уақытта жақсы жүріп кетсе, кенеттен жылдамдығы түсіп қалуы мүмкін.

Мәселелер жиі есептеу қателері ретінде көрінеді, бірақ себеп желіде. Типтік симптомдар:

• RDMA ағындарында throughput-тың төмендеуі және all-reduce деградациясы;
• ретрайлдардың/таймауттардың өсуі және латенттіліктің секірулері;
• белгілі GPU-жұмысшылардың кезеңді түрде іліп қалуы;
• линктердің тұрақсыз жүктемесі (кейде бос, кейде толып кетеді);
• итерация уақытын бұзатын «микропаузалар».

Маңызды түсіну: RoCE үшін «пакетсіз желі» дегеніміз барлық счетчиктерде нөлдік dropped packets дегенді білдірмейді. Фабрикада best-effort трафик болуы мүмкін, онда кейбір дроптар рұқсат етіледі. RDMA үшін бастысы: RDMA-трафик жүретін класста потерь болмауы және PFC әсерінен бүкіл фабрикада паузалар тарамауы керек.

Типтік сценарий: сізде 8 GPU-узел бар, оқыту қалыпты жүріп жатады, сосын деректер жүктемесі немесе бэкап параллель түрде басталады. Егер RDMA мен «қадый-трафик» QoS арқылы айқын бөлінбесе, кезектер пайда болып, ECN жұмыс істемей, PFC көрші порттарды паузалауды бастайды. Нәтижесінде бір узел уақыт бойынша «қалады», және бүкіл топ ең баяу түйінді күтеді.

Көп нәрсе PFC/ECN/MTU-ды ұқыпты баптамас бұрын шешіледі. Алдын ала жылдамдықты және архитектураны (мысалы, 25/100/200G, leaf-spine) таңдап, L2/L3 шекараларын анықтап, storage үшін бөлек фабрика немесе RDMA үшін бөлек трафик класстары болатынын шешкен жөн. Бұл шешімдер соңғы «тюнингтен» әлдеқайда маңыздырақ болады.

Алдын ала: үйлесімділік, топология және L2/L3 шекаралары

RoCEv2 UDP/IP үстінде жұмыс істейтіні үшін формальды түрде L3 арқылы өтуі мүмкін. Бірақ RDMA жоғарғы талаптарына байланысты жоғалту мен латенттілік әдеттегі трафиктен қатты ерекшеленеді. Сондықтан алдымен залалсыздандыру механизмдері жабдық және желі схемасы арқылы шынымен қолдау табатынына көз жеткізіңіз.

Үйлесімділікті екі деңгейде тексеруден бастаңыз: сервердегі NIC пен коммутаторларда. NIC үшін RoCEv2 және ECN дұрыс жұмыс істеуі маңызды (және егер жоспарласаңыз — PFC). Коммутаторларда кезектер мен приоритеттер, қажетті кезектерде ECN marking қолдауы және таңдалған класста PFC-дің болжамды жұмысы маңызды.

Содан кейін L2 және L3 шекараларын анықтаңыз. PFC — L2 механизм (pause кадрлары), оны маршрутизаторлар арқылы өту мүмкін емес. Егер RoCEv2 L3 арқылы салынса, end-to-end басқаруға ECN-ге сеніңіз, ал PFC-ді тек қай жерде L2-сегментте баптауға сенімді болсаңыз ғана қолданыңыз. Leaf-spine архитектурасында бұл жиі: L2 рұқсаттары стойка ішінде немесе стойкалардың жұбы арасында, әрі қарай — L3.

RDMA трафигін бөлек ұстау көбіне пайдалы: бөлек VLAN, ал ірі желілерде — бөлек VRF. Осылай оқшаулау, QoS басқару және жалпы сегменттен келген эфирлік және қызметтік протоколдардың тосын сыйларынан сақтану оңайырақ.

PFC/ECN-ды қозғамас бұрын базалық QoS модельді бекітіңіз:

• қанша класс қажет (ең азында: RDMA және әдеттегі трафик);
• RDMA үшін қандай PCP/DSCP қолданылатынын және оны кім қоятынын (хост немесе коммутатор);
• коммутатордағы қандай кезектер осы класстарға сәйкес келетіні;
• PFC қай жерде рұқсат етілген (тек RDMA-класста);
• ECN marking қайда қосылғаны (әдетте RDMA-очередьта).

Және соңғысы: бүкіл тізбекте бірдей адресация жоспары мен бірдей MTU болуы тиіс. RoCEv2-те бір ғана «тар» сегмент фрагментацияға, күтпеген потеряларға және өнімділіктің алғашқы құлдырауына әкелуі мүмкін.

MTU және jumbo frames: қалай орнату және жолды бұзбау

GPU-кластердегі RoCEv2 үшін MTU әдетте бірдей және үлкен етіп орнатылады, бұл шығындарды азайтады және жоғары жүктеме кезінде микропотерьдің тәуекелін төмендетеді. Типтік таңдау — MTU 9000 (кейде коммутаторларда L2 деңгейінде 9216 көрінеді), мақсат бір — кадр GPU-серверден GPU-серверге фрагментациясыз өтуі.

MTU бүкіл жол бойынша сәйкес келуі тиіс. Бір ғана 1500 байтқа қалдырылған сегмент (VLAN, bond, uplink, SVI немесе аралық свитч) оғаш симптомдар тудырады: периодтық RDMA таймауттары, пропусктық қабілеттіктің төмендеуі және лавиелі джиттер.

MTU-ды конфигурация стандарт ретінде бекітіңіз:

• хосттар: физикалық интерфейстер, bond/team, VLAN-интерфейстер, bridge (бар болса), сонымен бірге overlay (егер VXLAN/Geneve т.с.с. қолдансаңыз);
• коммутаторлар: порттардағы және аплинктердегі MTU, port-channel-дар, және SVI (егер L3 свитчте жасалса);
• транзит: кез келген цехарара/стойкаара линктер мен құрылғылар, олар әлі де әдепкі MTU қалдырған болуы мүмкін.

Жолдың барлық бөлігінде MTU-дың өтуін қалай тексеру

Екі түйін арасында «DF-пен» (фрагментациясыз) сквозной тест жасаңыз және кадр қай жерде қиылатынын табыңыз. Linux-та ping-пен бастау ыңғайлы және қажет болса өлшемді азайтып көріңіз:

ping -M do -s 8972 <IP_соседа>

Егер пакет өтпесе, өлшемді қадамдап төмендетіңіз (мысалы, әрқайсысында 200 байт кемітіп, содан соң бинарлы іздеу) және порттардағы счетчиктерге (errors/drops/giants) қараңыз. Jumbo frames пайда әкеледі, бірақ тәртіпті талап етеді: кез келген сәйкессіздік MTU-ды бүкіл жолды бұзады. Сондықтан конфигурация шаблондарына және кластерді іске қоспас бұрын тексерулерге стандартты енгізу дұрыс.

PFC: тек қажет жерде қосыңыз

PFC (Priority Flow Control, 802.1Qbb) — бұл порттың барлығын емес, таңдалған трафик классын тоқтататын «пауза». Қарапайым Ethernet Pause (802.3x) барлық портты ұстап тастайды, соның салдарынан сол желіде барлық трафик кенеттен төмендеуі мүмкін. PFC RoCEv2 үшін пайдалы, өйткені RDMA потеряларға нашар шыдайды, бірақ PFC-дің өз бағасы бар: дұрыс бапталмаса, ол фабриканы «қысқартып», кешігулерді таратып және head-of-line blocking тудыруы мүмкін.

Негізгі ереже: PFC-ді тек RDMA жүретін бір приоритет үшін ғана қосыңыз, «барлығына бірдей» емес. Әдетте RoCE үшін бір 802.1p приоритет (мысалы, 3 немесе 4) бөледі және тек онда PFC қосады. Қалған трафик (басқару, storage, стандартты east-west) PFC-сіз өмір сүруі тиіс, әйтпесе кез келген перегрузка кезде сізде шындықта паузалар тізбегі пайда болады.

PFC болжамды жұмыс істеуі үшін меткалар хосттан коммутаторға және кері қайтып шығуы тиіс. Хостта RDMA пакеттер жиі DSCP арқылы маркаланса, L2-де бұл PCP (802.1p)-ке айналады. NIC/драйвер және коммутаторларда DSCP→PCP mapping-ті тексеріңіз және trunk-тарда меткалардың саясаттармен «нөлденбейтініне» немесе trust boundary әсерінен өзгертпейтініне көз жеткізіңіз.

PFC-ні порттарда қосар алдында қысқа тізбекпен жүріңіз:

• RDMA үшін бір приоритет таңдаңыз және сол приоритетте барлық жолдағы порттарда (сервер порттары мен коммутаторлар арасындағы линктер) PFC-ді қосыңыз;
• меткаларға сенімділікті (trust DSCP немесе trust PCP) бірдей етіп баптаңыз, сонда классификация барлық құрылғыларда бірдей болады;
• буферлер мен PFC порогтарын линк жылдамдығы мен фабриканың кешігулерін ескере отырып баптаңыз: 100G/200G-да пауза тез кезектерді толтыра алады, егер порогтар тым жоғары болса;
• сол приоритет үшін дұрыс egress queue қосылғанына және кездейсоқ шейпинг жоқтығына көз жеткізіңіз.

Содан кейін PFC-ді «счетчиктер арқылы оқыңыз». Коммутаторлар мен NIC-те кемінде мына көрсеткіштерді қараңыз:

• қажетті приоритет бойынша PFC Rx/Tx frames: шыған оқиғалар шың кезінде қабылданады, бірақ тұрақты өсу — перегрузка белгісі;
• PFC pause duration (қолжетімді болса): ұзақ паузалар кезектердің тарқамауын білдіреді;
• RDMA-классындағы drop-тар: егер PFC белсенді болса да drop-тар болса, онда порогтар/буферлер немесе классификация дұрыс емес;
• ECN/маркировкалар (егер қосылған): ECN жоқ болса, ал PFC өсіп жатса, сіз тек «тежегіштермен» мәселені емдеп жүрсіз.

Жай мысал: GPU-узелдерде PFC-ді «барлық сегіз приоритетте» қосып қойған. Бір кезде бэкап немесе үлкен east-west трафик басталғанда паузалар тек RDMA үшін ғана емес, бүкіл кластерде белсенді болып, латенттілік күрт өскен. PFC-ді тек RDMA-приоритетпен шектеп, DSCP/PCP теңестіру арқылы мәселе әдетте жоғалады, ал PFC счетчиктері сирек және түсінікті болады.

ECN және перегрузка бақылауы: микропотеряларды болдырмау үшін

RoCEv2-де пакеттердің жоғалуы көбіне «толық үзілуден» емес, кезекті қысым кезінде пайда болатын микропотерялардан басталады. Бұл модель оқытуда сирек, бірақ қатты әсер ететін пропусктық құлдыраулар мен итерация уақыттарының өсуі ретінде көрінеді. ECN жіберушілерді буфер толмай тұрып баяулата отырып көмектеседі.

PFC мен ECN әртүрлі тапсырмаларды шешеді. PFC L2-де потериясыздыққа ұмтылады, бірақ head-of-line blocking және тізбекті паузаларға әкелуі мүмкін. ECN жұмсақ жұмыс істейді: коммутатор кезек өсіп бара жатқанда пакеттерді белгілейді, ал хосттар өздері жіберуді азайтатын болады. Идеалда PFC RDMA-класс үшін сақтандыру ретінде қалады, ал ECN негізгі перегрузка бақылауын атқарады.

Коммутаторларда ECN marking-ті дәл RDMA кезегі үшін қосады (әдетте бөлек QoS-класс/priority). Порогтарды дұрыс орнату маңызды: ерте порог (маркировканы бастау) және жоғарғы порог (маркировка агрессивті бола бастайды). Порогтар тым төмен болса, маркировка желі бос кезде де болады және жылдамдықты төмендетеді. Тым жоғары болса — сіз әлі де потерялар мен PFC-паузаға тап боласыз.

Хосттарда ECN өңдеудің қосылғанына және RoCEv2 үшін басқару алгоритмі (әдетте DCQCN немесе NIC өндірушісінің аналогы) белсенді екеніне көз жеткізіңіз. Коммутатор дұрыс маркировка жасаса да, жіберуші дұрыс баяулатпаса нәтиже болмайды.

Практикалық тексеру:

• фондық жүктеме және қысқа «всплесктер» (all-reduce-пен ұқсас) жасап, ECN-marked пакеттердің үлесін және RDMA жылдамдығының динамикасын қараңыз;
• PFC pause кадрлары сирек, тұрақты емес болуы тиіс (айналыстағы паузалар арқылы мәселені емдемеу үшін);
• бос желіде ECN өнімділікті айтарлықтай қысқартпауы тиіс;
• фабрика порттарындағы кезектер/дроптар және NIC-те ECN/CNP счетчиктерін алыңыз.

Егер желіңіз әртүрлі модельдегі коммутаторлардан тұрса, ECN профильдерін алдын ала келісіңіз. Бірдей «сандық порогтар» әртүрлі нақты буфер көлемдері мен әртүрлі мінез-құлықты білдіруі мүмкін. Практикада маңыздысы — метрикалар бойынша бірдей нәтиже: аз паузалар, потерялардың болмауы, маркировка тек всплеск кезінде.

QoS және кезектер: RDMA мен «қалыпты» трафикті қалай бөлу

Желі көбіне MTU немесе PFC себебінен емес, RDMA трафигі бэкаптар, логтар және сервистік «шум» бар бір кезекке түскен кезде бұзылады. Фондық ағымдар буферді толтырғанда, микропотерялар мен латенттіліктің секірулері пайда болады, олар кейін оқыту жылдамдығының «танымайтын» құлдырауы ретінде көрінеді.

Әдетте жеткілікті QoS саясаты

Трафикті алдын ала класстарға бөліп, оларды кезектерге байлау (802.1p/PCP немесе DSCP арқылы) ең оңайы. Көбіне келесі бөлісу жеткілікті:

• RDMA (RoCEv2) — бөлек кезек;
• storage (мысалы, бөлінген сақтау) — бөлек кезек, PFC жоқ;
• басқару және қызметтік протоколдар (SSH, мониторинг, кластер агенттері) — кепілдендірілген минимум бар класс;
• қалғаны — best-effort.

Тек RDMA-ға преференция беру жеткіліксіз, фоновый трафикті де шектеу маңызды. Access порттарда шейпинг/полисинг шу көздерін байқағанда пайдалы, магистральда мәселені емдеуге тырысуға қарағанда тиімдірек. Мақсат — бэкаптар немесе ірі көшірмелер буферлерді алып, паузалар лавинасын тудырмауы керек.

Қайда rate-limit көмектеседі, қайда зиян келтіруі мүмкін

Rate-limit серверлерден келетін белгісіз best-effort трафикке және қозғалғыш қызмет порттарына лайықты. Ал uplink немесе RDMA жүретін порттарда қатты полисинг кешіктіруді нашарлатып, джиттер қосып, пакеттерді топтап жіберіп, тіпті потерясыз жағдайда да латенттілікке әсер етуі мүмкін.

RDMA үшін приоритет бергенде басқару трафигі аштыққа ұшырамауы үшін оған шағын кепілдендірілген минимум қалдырыңыз және кезек счетчиктерінен бұл шын мәнінде тасымал алып жатқанын тексеріңіз. Және міндетті түрде маркіровка ережелерін құжаттаңыз: хосттар қандай PCP/DSCP қояды, коммутаторлар қандай класттарды күтеді және trust қай жерде жүзеге асады (хост, ToR, агрегация).

Оқыту алдында қандай метрикалар жинау керек: хосттар мен коммутаторлар

Оқыту басталмас бұрын базалық сызықты бекітіп алыңыз: желі «таза» күйде (шамалы жүктемемен) қалай жұмыс істейтінін және типтік RDMA-трафик кезінде қалай өзгеретінін түсінген дұрыс. Бұл желелік проблеманы қосымша мәселенен ажыратуға көмектеседі.

Хосттарда (GPU-узелдер) жинау керек метрикалар

Хосттарда мақсат — потерялар, ретрайлдар және паузалардың бар-жоғын және олардың қай жерде екенін (NIC, кезектер, драйвер) анықтау.

• RDMA счетчиктер: retries/retransmits, timeouts, CQ/QP қателері, ECN-ге реакциялар (егер стек көрсетсе). Нормал жүктемеде ретрайлдардың өсуі әдетте микропотерялар немесе перегрузка дегенді білдіреді;
• интерфейс статистикасы: drops, errors, FCS/CRC, overruns, missed, сондай-ақ кезектер бойынша қателер (TX/RX queues). Тіпті аздаған FCS-қателер кабель/оптика немесе порт мәселесін көрсетеді;
• хосттағы PFC: қанша pause-кадр жіберілген және алынған, қандай приоритеттерде;
• жүктеме: линк utilization, екі бағыттағы throughput, кезектер бойынша бөлініс. Маңызды — RDMA шынымен дұрыс QoS класқа жататынын көру;
• латенттілік және джиттер: p50/p95/p99 қолданбалы тестте және желілік тестте. Оқытуда көбінесе p99 сияқты құйрықтар маңызды.

Коммутаторларда жинау керек метрикалар

Коммутаторлар пакеттерді кезектерде жоғалтпайтынын және ұзақ паузаларға түспейтінін растауы керек.

• кезектер және приоритеттер бойынша drops (әсіресе RDMA классында). Жүктеме кезінде нөлдік drop — жақсы белгі;
• PFC pause: паузалар саны және ұзақтығы бойынша статистика. Пауза өсе бастаса, кезектерді тарқату қиынға соғып жатыр деген сөз;
• ECN marks: қанша пакет белгіленген. Қалыпта ECN жүктеме кезінде өседі, бірақ хосттарда ретрайлдар күрт көбеюі тиіс емес;
• buffer occupancy (бар болса): порттар мен кезектердегі буфер қаншалықты толатынын көру ең жақсы индикатор;
• порт utilization және микроберстер: жүктеменің шыңдары мен асимметриясы. Көбіне орташа трафикте емес, қысқа всплесктерде проблема болады.

Метрикаларды екі рет алыңыз: алдымен 5–10 минут тыныштықта, сосын оқытуға ұқсас типтік RDMA жүктемесімен. Осылайша қай жерде бірінші рет ретрайлдар пайда болатынын, қай портта ECN-marked көбейтетінін және p99 латенттіктің қай жерде өсетінін салыстыруға болады.

Потеряларды, латенттілік пен джиттерді қалай тексеру: қадам-қадам

Тексеруді оқытуды бастамастан жасаған дұрыс. RoCEv2 мәселелері көбіне айқын үзілулер емес, сирек болатын микропотерялар мен ұзақ құйрықтар ретінде көрінеді.

Тез тексеру жоспары (ML-ды іске қоспастан бұрын)

1. Физикадан бастаңыз: екі ұштың жылдамдығы мен режимі сәйкес келетінін, flaps жоқтығын, өсіп жатқан қателер счетчиктері жоқтығын, FEC проблемалары жоқтығын тексеріңіз. Джиттердің жиі себебі — оптика немесе DAC-кабельдердің нашарлығы, «жұмыс істейді» көрінгенімен коррекция шегінде қалу.

2. MTU-ды end-to-end тексеріңіз (сервер, ToR, агрегация). Jumbo frames ғана орнату жеткіліксіз — еш жерде жасырып тұрған фрагментация жоқтығына сену керек.

3. Түйіндер жұптары арасында және all-to-all схемасында RDMA-тесттер жүргізіңіз. Түйін жұптары нүктелік проблемаларды көрсетсе, all-to-all аплинктердің «ысыған» бағыттарын жылдам табады.

4. Контролденетін перегрузка жасаңыз және PFC мен ECN қалай әрекет ететінін қараңыз. Мақсат — трафикті «суландырып» түсіру емес, паузалар мен маркировкалардың өсуін нөлдік потеря және көрші класттарда пауза лавинасы жоқ жағдайда көру.

5. Орташа ғана емес, p99 және p999 задержкаларды өлшеңіз және джиттерді тіркеңіз. Оқыту үшін құйрықтар маңызды: сирек пайда болатын задержка всплесктері итерацияларды орташа жылдамдықтан әлдеқайда тежейді.

Қандай құралдармен және не жазып алу керек

Минималды командалар жиыны жиі осындай:

# MTU фрагментациясыз (өз MTU-ға сай өлшем таңдаңыз)
ping -M do -s 8972 <ip>

# RDMA latency/bandwidth (perftest мысалы)
ib_write_lat -a <peer_ip>
ib_write_bw  -a <peer_ip>

Егер «A-B жұбы» тесті тұрақты жақсы латенттікті берсе, ал all-to-all-да p999 бір ToR арқылы күрт өсетін болса, бұл әдетте сол аплинктың немесе сол учаскедегі QoS/кезектердің дұрыс бапталмағанын көрсетеді.

Соңында нәтижелерді «golden baseline» ретінде сақтаңыз: драйверлер/прошивкалар версиясы, MTU, QoS параметрлері және негізгі метрикалар (drops, PFC pause, ECN marks, p50/p99/p999). Бұл кластеры кеңейгенде немесе жаңартқанда себептерді табуды жылдамдатады.

RoCEv2 баптамасындағы типтік қателіктер және оларды тез табу

Көптеген проблемалар «оқыту баяулады» немесе «коллективтік операциялар кейде іліп қалады» түрінде көрінеді. Төменде жиі кездесетін қателіктер, олар жасырын потерялар, паузалар және тұрақсыз задержка әкеледі, және жылдам диагноза тәсілдері.

PFC: глобалды паузалар және дұрыс емес класс

Ең ауыр қате — PFC-ды бірден және барлық приоритеттерде қосу. Нәтижесінде паузалар фабриканы таратады, бір перегруженный порт бірқатар ағынды тежейді.

Екінші жиі себебі — PFC қосулы, бірақ RDMA трафигі дұрыс приоритетке түспейді (DSCP/PCP маркіровкасының қателігі немесе хост пен коммутатордағы QoS-политикалардың айырмашылығы). Жылдам белгі: PFC счетчиктері өсіп жатыр, бірақ кезектерде drops бар.

MTU және ECN: «шамамен жұмыс істейді», бірақ баяу

Жолдың бір учаскісінде басқа MTU болуы көбіне байланысты толығымен үзілмей, бірақ фрагментация, CPU жүктемесінің артуы, RTT секірістері және пропусктың төмендеуі сияқты әсер көрсетеді. Егер бір түйін үнемі қалғандарының нашары болса, MTU бірінші күдік болуы тиіс.

ECN-да екі шектік жағдай бар: порогтар тым төмен болса — үнемі «тоқтатып тастаулар» болады (линк утилизациясы төмен), тым жоғары болса — кезектерде микропотерялар және кейін PFC пайда болады. ECN-marked/CE өсуі мен кезектер көлемін және нақты drops-ты салыстырыңыз.

Жылдам диагностика әдетте мына жерлерді көрсетеді:

• коммутаторларда: кезектер бойынша drops/overruns, PFC pause frames және олардың ұзақтығы, ECN-marked, буфер толуы;
• хосттарда: NIC қателері, RDMA retrans/timeout, порттарды нақтылы жылдамдық, QoS счетчиктері бойынша статистика;
• жүктеме: бір ағын емес, шынайы профильге жақын бірнеше GPU/нүктенің қозғалысын тестілеңіз;
• изоляция: «шулы» трафикті уақытша RDMA-дан бөліп алыңыз;
• салыстыру: «жақсы» және «жаман» түйінді тауып, MTU мен маркіровканы жол бойынша салыстырыңыз.

Практикада типтік узел (мысалы, стойка + ToR) үшін эталон конфигурация жасап, кластерге қосардан бұрын ауытқушылықтарды тексеру ыңғайлы.

Модельдерді оқытуға берерден бұрын қысқа чек-лист

Кластерді оқытуға беру алдында желіні тез тексеріңіз. Мұндағы басты мақсат — максималды цифр емес, болжамдылық: жасырын потерялар, паузалар және задержка секірістері болмауы керек.

Барлық жол бойынша (NIC - ToR - spine - ToR - NIC) базалық гигиенаны тексеріңіз:

• барлық линктерде бірдей MTU, жылдамдық және FEC баптаулары бар; CRC/FCS errors, symbol errors, flaps және басқа физикалық проблемалардың жоқтығы;
• RDMA трафигі дұрыс маркіленген (DSCP/802.1p) және бөлек кезекке тұрақты түрде түседі, «қалыпты» трафикпен араласпайды;
• PFC тек қажетті класқа қосылған (RDMA), PFC счетчиктері тұрақты өспейді және pause-storm белгілері жоқ;
• ECN RDMA-класста қосылған және ол нақты перегрузканы көрсетеді: қалыпты жүктемеде тұрақты маркировка болмауы тиіс;
• коммутаторларда және NIC-те RDMA кезегінде drop-тар жоқ (және онда WRED/tail drop сияқты механизмдер жұмыс жасамауы керек).

Сосын жүктеме астындағы сапаны тексеріңіз. Бір жұп хосттан гөрі all-to-all және параллель ағындарды тестілеу маңызды, өйткені оқыту дәл солай жұмыс істейді.

• all-to-all тесттерде латенттілік пен джиттер мақсатты жүктеме кезінде тұрақты болуы тиіс: PFC/ECN өсуімен сәйкес келмейтін периодтық шыңдар болмауы керек;
• фондық (қызметтік трафик, сақтау, мониторинг) бар кезде RDMA-кезек болжамды күйде қалуы тиіс: метрикалар кенет нашарламауы керек.

Егер бір тармақ сәйкес болмаса, оқытуды «барайды» деп бастамаңыз. Алдымен жөндеңіз: көбіне мәселе бір ғана MTU/маркировка сәйкессіздігінде немесе PFC-дің тым кең қосылуында болады.

Кластерді іске қосу мысалы және әрі қарайғы қадамдар

Мысал: 16 GPU-сервер, 2 leaf-коммутатор және 1 spine, аплинктер мен сервер порттары 100G. RDMA үшін бөлек VLAN (және бөлек QoS приоритеты) қарастырылған, ал басқару мен сақтау бөлек өмір сүреді. Бастапқы мақсаты — фабриканың болжамды жұмыс істейтініне көз жеткізу: потерялар жоқ, PFC «жабыспайды», задержка всплесктері жоқ.

Тексеруді кезең-кезеңімен жасап, әр этапта базалық сызықты жазып отыру ыңғайлы:

• 2 түйін: RDMA bandwidth/latency тесттері, MTU жол бойынша тексеру, порт есептері;
• 4 түйін: параллель ағындар (бірнеше жұп), жүктеме кезінде әділеттілік пен микропотерялардың жоқтығын тексеру;
• 8–16 түйін: коллективтік паттерндер (all-reduce/traffic matrix), нақты оқыту профилінің имитациясы және фондық «қалыпты» трафик;
• түнгі/ұзақ прогон: 2–6 сағат, сирек оқиғаларды (bursts, периодтық просадкалар) ұстап алу үшін.

Әр қадамнан кейін «қызыл қаманаларға» назар аударыңыз. Маңызды — мәселенің болуы ғана емес, оның динамикасы: көрсеткіш жүктемемен бірге өседі ме немесе қысқа интервалдарда ұшталып шыға ма.

• порттардағы drops/discards (әсіресе PFC қосылғанда) және кезек қателерінің өсуі;
• шамадан тыс PFC: көптеген паузалар, ұзақ паузалар немесе PFC-дің non-RDMA класстарға әсері;
• RDMA-да retries/RNR NAK өсуі, тұрақты жүктемеде пропусктың төмендеуі;
• ECN: порогтар қате болғанда маркировка көбейіп, latency секірістері көрінеді;
• джиттер: PFC немесе egress кезектерінің всплесктерімен сәйкес келетін кейбір задержка шыңдары.

Есепті қысқа 1–2 беттік құжат ретінде жасаңыз: (1) базалық сызық (2 түйін), (2) жүктеме тесті (бүкіл кластер), (3) табылған ауытқулар мен себептері, (4) жөндеу жоспары мен қайталап өлшеу.

Егер сіздің кластеріңіз RoCEv2-те алғаш рет болса немесе NIC/коммутатор профильдеріне сенімді болмасаңыз, пилот алдында фабрика және желілік профильдердің тәуелсіз валидациясы пайдалы болады. Мұндай тапсырмаларда GSE.kz көмектесе алады: архитектураны, QoS-модельді және «стоп-сигналдар» критерийлерін алдын ала бекітіңіз.