Matrici di compatibilità, release notes e modifiche firmware

«Supportato» è un’affermazione su una tripla: questo modulo, su questa piattaforma, con questa release software. I produttori pubblicano quella tripla in matrici di compatibilità e release notes, e la cambiano — compaiono nuovi ottici, quelli vecchi escono, i controlli diventano più rigidi. Leggere le matrici prima di acquistare e rileggerle prima di aggiornare è il lavoro di compatibilità più economico che esista. Questa pagina mostra dove si trova l’informazione, come leggerla, e come gestire una flotta in modo che un aggiornamento software non si trasformi in un’interruzione degli ottici.

Dove i produttori pubblicano il supporto

Leggi anche le release notes della versione di NOS che usi: le modifiche relative agli ottici si nascondono sotto «resolved issues», «behaviour changes» e «new hardware support».

Leggere una voce della matrice

Cosa cambia con il software

Una prassi di flotta che evita sorprese

1. Inventario — registra produttore, PN, seriale, revisione e firmware di ogni modulo per porta (dallo switch o dal banco) nel CMDB.
2. Fissa le release — tratta la versione del NOS come parte della tripla di compatibilità; non aggiornare access e core lo stesso giorno.
3. Leggi le release notes per le voci relative agli ottici prima di ogni aggiornamento.
4. Testa su uno switch di laboratorio o canary con un esemplare di ogni tipo di ottico in uso — prima i moduli di terze parti e quelli codificati.
5. Conserva l’immagine precedente e un piano di rollback; sappi quali porte sono soggette a errdisable.
6. Fai una baseline del DDM prima e dopo, in modo che i cambiamenti di comportamento siano visibili nel monitoraggio (Monitoraggio).
7. Tieni traccia dell’EOL dei PN degli ottici e dei loro successori, in modo che le sostituzioni corrispondano alla matrice.

Ottici di terze parti e codificati in questo quadro

Un modulo codificato su un PN OEM viene giudicato dalla stessa voce di matrice dell’originale — la piattaforma non può notare la differenza se la codifica è completa — ma la dichiarazione di supporto del produttore non si estende a esso, e un controllo più rigido in una nuova release può smascherarlo. Mantieni i moduli codificati identificabili nell’inventario (il loro vero produttore e seriale), testali per primi negli aggiornamenti, e pianifica il caso in cui una release chiuda la porta (Ottici di terze parti, Blocco del produttore).

Lato NIC e server

Gli adattatori server hanno proprie matrici (adattatore ↔ modulo ↔ driver/firmware) e proprie politiche — alcune famiglie Intel rifiutano gli SFP non elencati a meno che un parametro del driver non li consenta; gli adattatori Mellanox/Nvidia convalidano i cavi per InfiniBand. Gli aggiornamenti di driver e firmware cambiano queste regole proprio come fanno gli aggiornamenti del NOS (Ricette di configurazione delle porte).

In CodingBox

Il lato banco della prassi di flotta: leggi l’identità e la versione firmware di ogni modulo nel code database all’ispezione in ingresso, confronta i byte di un modulo sospetto con la voce di matrice su Check transceiver, e mantieni la distinzione codificato/originale nelle note del database in modo che un rifiuto nel giorno dell’aggiornamento possa essere ricondotto al modulo in pochi secondi.

Le politiche di driver e firmware delle NIC in dettaglio, per produttore e sistema operativo: Compatibilità dei ricetrasmettitori sulle NIC.

La prassi di flotta come lista di controllo per la messa in servizio — aggiornare prima di configurare, test canary, baseline del DDM, test di accettazione: Scegliere e mettere in servizio.