Macierze kompatybilności, release notes i zmiany firmware

„Supported” to stwierdzenie dotyczące trójki: ten moduł, na tej platformie, na tym wydaniu oprogramowania. Producenci publikują tę trójkę w macierzach kompatybilności i informacjach o wydaniu i zmieniają ją — pojawia się nowa optyka, stara znika z listy, sprawdzenia stają się bardziej rygorystyczne. Czytanie macierzy przed zakupem i ponowne czytanie przed aktualizacją to najtańsza praca nad kompatybilnością, jaka istnieje. Ta strona pokazuje, gdzie żyją te informacje, jak je czytać i jak prowadzić flotę, żeby aktualizacja oprogramowania nie zamieniła się w awarię optyki.

Gdzie producenci publikują wsparcie

Czytaj też informacje o wydaniu wersji NOS, której używasz: zmiany dotyczące optyki kryją się pod „resolved issues”, „behaviour changes” i „new hardware support”.

Czytanie wpisu w macierzy

Co zmienia się wraz z oprogramowaniem

Praktyka floty, która unika niespodzianek

1. Inwentaryzacja — zapisz w CMDB producenta, PN, numer seryjny, rewizję i firmware każdego modułu na porcie (z przełącznika albo ze stanowiska).
2. Przypnij wydania — traktuj wersję NOS jako część trójki kompatybilności; nie aktualizuj dostępu i rdzenia tego samego dnia.
3. Czytaj informacje o wydaniu pod kątem pozycji dotyczących optyki przed każdą aktualizacją.
4. Testuj na przełączniku laboratoryjnym albo kanarkowym po jednym egzemplarzu każdego typu używanej optyki — najpierw moduły innych producentów i zakodowane.
5. Zachowaj poprzedni obraz oprogramowania i plan rollbacku; wiedz, które porty są podatne na errdisable.
6. Ustal wartość bazową DDM przed i po, żeby zmiany zachowania było widać w monitoringu (Monitorowanie).
7. Śledź EOL numerów PN optyki i ich następców, żeby zamienniki pasowały do macierzy.

Optyka innych producentów i zakodowana w tym kontekście

Moduł zakodowany pod PN OEM jest oceniany według tego samego wpisu w macierzy co oryginał — platforma nie widzi różnicy, jeśli kodowanie jest kompletne — ale oświadczenie producenta o wsparciu na niego nie rozciąga się, a bardziej rygorystyczne sprawdzenie w nowym wydaniu może go zdemaskować. Utrzymuj moduły zakodowane jako rozpoznawalne w inwentaryzacji (ich prawdziwego producenta i numer seryjny), testuj je jako pierwsze przy aktualizacjach i planuj na wypadek, gdyby wydanie zamknęło furtkę (Optyka innych producentów, Blokada producenta).

Strona NIC i serwera

Adaptery serwerowe mają własne macierze (adapter ↔ moduł ↔ sterownik/firmware) i własne polityki — niektóre rodziny Intel odrzucają SFP spoza listy, chyba że pozwala na to parametr sterownika; adaptery Mellanox/Nvidia weryfikują kable dla InfiniBand. Aktualizacje sterownika i firmware zmieniają te zasady tak samo jak aktualizacje NOS (Przepisy konfiguracji portów).

W CodingBox

Strona stanowiskowa praktyki floty: podczas kontroli wejściowej wczytaj dane identyfikacyjne i wersję firmware każdego modułu do code database, porównaj bajty podejrzanego modułu z wpisem w macierzy na Check transceiver i zachowaj w notatkach bazy rozróżnienie zakodowany/oryginalny, żeby odrzucenie w dniu aktualizacji dało się w sekundy powiązać z modułem.

Polityki sterowników i firmware NIC szczegółowo, według producenta i systemu operacyjnego: Kompatybilność transceiverów w kartach NIC.

Praktyka floty jako lista kontrolna uruchomienia — aktualizacja przed konfiguracją, testy kanarkowe, wartość bazowa DDM, test odbiorczy: Wybór i uruchomienie.