W nowoczesnych infrastrukturach AI i HPC, struktury InfiniBand są często uważane za stabilną infrastrukturę niskiego poziomu – dopóki awaria Menedżera Podsieci (SM) nie spowoduje wyłączenia całego klastra. We wdrożeniach opartych na niezarządzanych przełącznikach InfiniBand MQM8790, płaszczyzna sterowania struktury jest całkowicie zależna od zewnętrznego Menedżera Podsieci, takiego jak OpenSM. Awaria głównej instancji OpenSM nie powoduje łagodnej degradacji, lecz potencjalną awarię płaszczyzny sterowania w całej strukturze, co wpływa na komunikację GPU, ruch w pamięci masowej i rozproszone obciążenia. W tym artykule wyjaśniono przyczynę tego trybu awarii oraz sposób projektowania architektury przełączania awaryjnego OpenSM o wysokiej dostępności dla środowisk produkcyjnych.
- Etapowe zamrożenie operacji od ciągłości płaszczyzny danych na poziomie sprzętowym do całkowitego przestoju klastra.
- Projektowanie topologii aktywnych i rezerwowych w celu zarządzania wyborami głównymi i kontrolą infrastruktury.
- Ustawianie profili priorytetowych, progów wyborczych i parametrów dostrajania dla węzłów aktywnych/rezerwowych.
- Szczegółowy opis techniczny – od wykrywania awarii i sondowania po ponowne odkrycie całej struktury.
- Różnica między natychmiastową replikacją stanu a kontrolowaną ponowną inicjalizacją płaszczyzny sterowania.
- Wytyczne operacyjne dotyczące dedykowanych węzłów głównych, konfiguracji usług systemowych i wyrównywania oprogramowania sprzętowego.
- Rozwiązywanie konfliktów w przypadku dwóch serwerów głównych, powolnego odzyskiwania i łagodzenie przerw w działaniu potoku LLM.
- Końcowe podsumowanie operacyjne dotyczące zarządzania zachowaniem odzyskiwania odporności w warunkach awarii.
Dlaczego struktury InfiniBand MQM8790 opierają się na OpenSM
MQM8790 To niezarządzany przełącznik InfiniBand, co oznacza, że nie zawiera żadnej wewnętrznej inteligencji płaszczyzny sterowania. Nie może on wykonywać następujących czynności: zarządzania podsieciami, przypisywania identyfikatorów LID, obliczania trasowania ani wykrywania topologii. Zamiast tego wszystkie funkcje płaszczyzny sterowania są obsługiwane zewnętrznie przez OpenSM.
Do obowiązków OpenSM należy:
- Odkrywanie struktury InfiniBand
- Przypisanie LID (identyfikatora lokalnego)
- Obliczenia LFT (Linear Forwarding Table)
- Usługi Path Record i SA
- Zarządzanie grupą multiemisji
Bez OpenSM struktura nie jest w stanie przeprowadzić rekonfiguracji, adaptacji ani odzyskać sprawności po zmianach.
Co się dzieje, gdy OpenSM zawodzi
Pojedynczy OpenSM Instancja reprezentuje pojedynczy punkt awarii (SPOF). W przypadku awarii skutki występują etapami.
Faza początkowa: ciągłość płaszczyzny danych
Istniejące połączenia InfiniBand QP mogą tymczasowo działać, ponieważ sprzętowo pozostają aktywne tablice przekierowań. Jednakże: nie można nawiązać nowych połączeń, nie występują żadne aktualizacje trasowania ani nie są przetwarzane żadne zmiany topologii.
Zamrożenie płaszczyzny sterowania
Po wystąpieniu jakiegokolwiek zdarzenia w strukturze (restart węzła, awaria łącza lub ponowne przesłanie zadania) system nie może odpowiedzieć z powodu braku kontroli nad Menedżerem Podsieci. Na tym etapie struktura zostaje zawieszona operacyjnie.
Wpływ na poziomie klastra
W środowiskach AI i HPC prowadzi to do:
- Zawieszenie prac nad szkoleniem rozproszonym (przekroczenie limitu czasu NCCL)
- Błędy synchronizacji GPU
- Degradacja sieci pamięci masowej (NVMe-oF, równoległe systemy plików)
- Przekroczenie limitu czasu węzła harmonogramu zadań
Nie jest to już tylko problem dotyczący sieci; staje się to scenariuszem awarii całego klastra.
Sprawdź stan magazynowy, porównaj opcje lub porozmawiaj z naszym zespołem.
Architektura wysokiej dostępności OpenSM
Aby wyeliminować to ryzyko, w środowiskach produkcyjnych stosuje się dwuwęzłowy model przełączania awaryjnego OpenSM, wykorzystując konstrukcję aktywny/rezerwowy.
Przegląd architektury
Jedna instancja OpenSM pełni rolę aktywnego serwera głównego, podczas gdy jedna lub więcej instancji rezerwowych stale monitoruje jej stan. Wybór odbywa się na podstawie priorytetu, gdzie serwer SM o najwyższym priorytecie staje się aktywnym menedżerem.
Konfigurowanie OpenSM do pracy w trybie failover
Stabilna konfiguracja trybu failover wymaga spójnych parametrów we wszystkich uczestniczących węzłach.
Konfiguracja głównego węzła OpenSM
Zachowanie: Wysoki priorytet zapewnia główną rolę w normalnych warunkach, a silne utrzymanie roli głównej zapobiega niepotrzebnej zmianie roli.
Konfiguracja dodatkowego węzła OpenSM
Zachowanie: Działa jako zapasowy menedżer podsieci, stale monitoruje stan podstawowego menedżera podsieci i przejmuje kontrolę w przypadku wykrycia awarii.
Parametry stabilności i sondowania
Cel: Określa interwał wykrywania awarii, kontroluje tolerancję na awarie przejściowe i zapobiega niespójnym stanom podczas przełączania awaryjnego.
Jak działa tryb failover OpenSM
Przełączanie awaryjne opiera się na sondowaniu SM, wyborze i odbudowie struktury, a nie na natychmiastowym przełączaniu.
- Krok 1: Wykrywanie awarii: Węzły rezerwowe używają sondowania sminfo MAD do monitorowania aktywnego węzła SM. Po kilku nieudanych odpowiedziach węzeł główny zostaje uznany za wyłączony.
- Krok 2: Proces wyborczy: Nowego mastera wybiera się na podstawie najwyższego priorytetu sm_priority, a jeśli to konieczne, rozstrzygającego GUID.
- Krok 3: Odbudowa tkaniny: Nowy serwer główny wykonuje ponowne wykrywanie topologii, ponowne obliczanie LFT, sprawdzanie poprawności lub ponowne przypisywanie identyfikatorów LID oraz inicjalizację bazy danych administracji podsiecią.
- Krok 4: Zachowanie naprawcze: Mimo że proces ten odbywa się automatycznie, wiąże się on z czasowymi zakłóceniami w ruchu, opóźnieniami w komunikacji GPU i dodatkowym obciążeniem związanym z ponownym łączeniem zadań.
Przełączanie awaryjne OpenSM poprawia dostępność, ale nie eliminuje zakłóceń.
Kluczowe zagadnienia inżynieryjne
Częstym błędem w projektowaniu jest założenie, że przełączanie awaryjne jest równoznaczne z bezproblemową ciągłością. W architekturach InfiniBand: przełączanie awaryjne oznacza kontrolowaną ponowną inicjalizację infrastruktury, a nie natychmiastową replikację stanu. To rozróżnienie jest kluczowe dla: projektowania stabilności szkolenia AI, strategii punktów kontrolnych oraz planowania odporności systemów rozproszonych.
Najlepsze praktyki dla środowisk produkcyjnych
- Dedykowane węzły menedżera podsieci: OpenSM powinien działać wyłącznie na stabilnych, dedykowanych węzłach infrastruktury. Nigdy nie należy go wdrażać na węzłach GPU o dużej mocy obliczeniowej.
- Ścisła kontrola priorytetów: Należy unikać konfiguracji o równym priorytecie, chyba że celowo projektuje się zaawansowane systemy z wieloma SM, gdyż może to prowadzić do trzepotania lub niestabilności SM.
- Zarządzanie usługami: Aby zapewnić automatyczne odzyskiwanie i kontrolę cyklu życia, należy używać menedżerów systemd lub klastrów, takich jak Pacemaker lub Keepalived.
- Wymagania dotyczące monitorowania: Środowiska produkcyjne muszą śledzić zmiany stanu SM, dzienniki ponownej inicjalizacji struktury oraz zmiany lub alerty topologii.
- Spójność oprogramowania sprzętowego i wersji: Zapewnij spójność między wersjami oprogramowania układowego przełącznika MQM8790, oprogramowania układowego HCA i OpenSM. Niespójne oprogramowanie układowe jest częstą przyczyną subtelnej niestabilności przełączania awaryjnego.
Typowe problemy z przełączaniem awaryjnym i znaczenie klastra AI
Typowe problemy z przełączaniem awaryjnym
- Konflikt Podwójnego Mistrza: Przyczyna: nieprawidłowa konfiguracja priorytetów SM. Skutek: niestabilność routingu i rotacja sieci. Rozwiązanie: wymuszenie ścisłej hierarchii priorytetów.
- Powolne odzyskiwanie po awarii: Przyczyna: opóźnienie w wykrywaniu topologii na dużą skalę. Rozwiązanie: dostosuj interwały sondowania i zoptymalizuj rozmiar struktury.
- Awarie na poziomie aplikacji po przejściu w tryb failover: Przyczyna: ponowne przypisanie LID lub zmiana topologii. Rozwiązanie: projektowanie aplikacji z myślą o tolerancji na ponowne połączenia.
Znaczenie w klastrach AI i HPC
W środowiskach szkoleniowych opartych na GPU: InfiniBand zapewnia warstwę transportu danych, OpenSM kontroluje stan całej struktury, a MQM8790 działa jako pasywny komponent przekierowujący. Awaria pojedynczego menedżera podsieci może zakłócić: potoki szkoleniowe LLM, rozproszone obciążenia wnioskowania i systemy synchronizacji punktów kontrolnych.
Rozważania nad infrastrukturą i rzeczywistość zamówień publicznych
Zaprojektowanie architektury OpenSM o wysokiej dostępności to tylko jeden z elementów gotowości produkcyjnej. Drugim kluczowym czynnikiem jest spójny i niezawodny dostęp do zweryfikowanego sprzętu InfiniBand. W rzeczywistych wdrożeniach HPC i AI inżynierowie często polegają na platformach takich jak router-switch, aby pozyskać: przełączniki InfiniBand NVIDIA/Mellanox, w tym sprzęt klasy MQM8790, adaptery Host Channel (HCA), okablowanie LinkX o wysokiej przepustowości dla struktur HDR/NDR oraz komponenty sieciowe klasy produkcyjnej dla klastrów AI. W środowiskach HA spójność sprzętowa, kompatybilność oprogramowania sprzętowego i niezawodność zasilania bezpośrednio wpływają na to, czy architektura failover może zostać pomyślnie wdrożona na dużą skalę.
Wniosek
Przełączanie awaryjne OpenSM w infrastrukturze InfiniBand opartej na architekturze MQM8790 jest podstawowym wymogiem dla każdego produkcyjnego klastra HPC lub AI. Prawidłowo zaprojektowana architektura Subnet Manager o wysokiej dostępności zapewnia: eliminację pojedynczych punktów awarii, automatyczny wybór i odzyskiwanie serwera głównego, kontrolowaną ponowną inicjalizację infrastruktury oraz zwiększoną odporność operacyjną.
Inżynierowie muszą jednak zrozumieć kluczowe ograniczenie: przełączenie awaryjne przywraca dostępność płaszczyzny sterowania, ale nie eliminuje przejściowych zakłóceń. Celem nie jest brak awarii, ale przewidywalne i kontrolowane zachowanie systemu w warunkach awarii.