Il vostro inventario è un'ipotesi finché la rete non lo conferma

Ogni inventario di datacenter parte accurato e comincia a divergere dal primo giorno. Un server viene spostato, un cavo viene sostituito di fretta, un indirizzo viene riutilizzato, e il registro smette in silenzio di descrivere la realtà. La soluzione non è un foglio di calcolo più grande. È un'abitudine: trattate ogni voce come un'affermazione, e verificatela sulla rete viva ogni volta che la scrivete o che vi fate affidamento.

Il dispositivo vivo vince

La prima regola è quella che chiude ogni discussione. Quando il registro e il dispositivo non concordano, ha ragione il dispositivo e il registro viene corretto. Un DCIM riconciliato di continuo con la rete in esercizio diventa lo strumento più utile che avete alle tre di notte.

Gestiamo un DCIM self-hosted basato su RackTables ed esteso con moduli che prelevano dati vivi dai dispositivi: tabelle ARP, stato delle porte, zoning Fibre Channel, export dello storage e configurazioni degli switch. I prelievi esistono perché il registro possa essere verificato sul cavo, non creduto sulla parola.

Dimostrate che un indirizzo è libero in tre modi

Un registro che dice «libero» è il primo controllo, non l'ultimo. Prima di assegnare qualsiasi indirizzo lo verifichiamo in tre modi:

1. Il registro. È allocato a qualcosa nel DCIM?
2. Le tabelle ARP. Qualche router o switch su quel segmento lo ha visto di recente? Sui dispositivi Cisco, show ip arp <address> risponde in un secondo.
3. Il cavo stesso. Da un host sullo stesso segmento, la duplicate address detection chiede all'intero segmento se qualcuno possiede l'indirizzo:

arping -D -I <interface> -c 3 <address>
echo $?    # 0 means nobody answered, 1 means the address is in use

Il ping è il più debole dei controlli, perché un host dietro firewall non risponderà, ed è per questo che l'ARP conta di più sul segmento locale. Se un qualsiasi controllo non concorda con il registro, vince la risposta viva, e indagate prima di assegnare qualsiasi cosa. Ogni assegnazione è poi seguita dai suoi record DNS, diretto e inverso, così ogni indirizzo della rete risolve a un nome che dice cos'è.

Confermate l'hardware e i suoi link

Leggete gli indirizzi MAC dalla macchina

Gli indirizzi MAC copiati a mano da un adesivo o da un preventivo sono sbagliati abbastanza spesso da contare. Prima che un server venga messo in rack, il suo controller di gestione può già dirvi il MAC reale di ogni porta di rete, e sui sistemi blade l'enclosure può dirvi ogni MAC e ogni WWPN Fibre Channel per ogni bay. Leggeteli da lì e scriveteli nel registro. Quando il server viene collegato, la tabella MAC dello switch deve mostrare esattamente gli indirizzi che avete registrato, esattamente sulle porte che avete pianificato.

Confermate il cablaggio con LLDP

Un piano di cablaggio è una dichiarazione di intenti. LLDP vi dice cosa è stato collegato davvero. Sullo switch:

show lldp neighbors detail

Su un host Linux con lldpd in esecuzione:

lldpctl

Ogni lato riporta il vicino che vede: nome di sistema e porta. Confrontatelo con i link nel registro. Un server che riporta lo switch giusto sulla porta sbagliata è una svista di cablaggio colta prima che trasporti traffico, invece che un pomeriggio di confusione più avanti.

Rileggete ogni campo

Quando una costruzione o un lavoro di cablaggio è finito, rileggete dal database ogni campo che avete scritto e confrontatelo con il piano: unità rack, porte, indirizzi MAC, link su entrambi i capi, cable ID, allocazioni di indirizzi con l'interfaccia su cui vivono, controller di gestione, e per i blade la loro posizione nell'enclosure. Un oggetto compilato a metà è lavoro non finito, non una bozza da completare dopo. «Dopo» è il modo in cui i registri divergono.

Un'ulteriore salvaguardia costa poco e coglie una quantità sorprendente di problemi: eseguite regolarmente un report dei duplicati, perché due voci per una macchina sono fuorvianti quanto nessuna.

Riconciliate anche il fabric di storage

Su un fabric Fibre Channel, il registro deve contenere il WWPN di ogni porta host, la porta dello switch su cui arriva, e le zone a cui appartiene. Il fabric stesso può confermare tutte e tre le cose. Sugli switch Brocade, switchshow elenca cosa è in login su ogni porta, nsshow elenca i WWPN registrati nel name server del fabric, e zoneshow stampa lo zoning attivo. Confrontateli con il registro su entrambi i fabric. Un host che risulta in login su un solo fabric è un host a un guasto di switch dal perdere i suoi dischi, e il confronto lo trova prima che accada. Preleviamo lo zoning dagli switch nel nostro DCIM esattamente per questo, così il registro di una zona è la zona come la impone il fabric.

Non riutilizzate mai un cable ID

Ogni cavo che installiamo porta un'etichetta plastificata a entrambi i capi con un cable ID numerico univoco e il rack, il dispositivo, la porta e la lunghezza dell'altro capo, e lo stesso numero è registrato sul link nel DCIM. La regola che fa funzionare tutto questo è quella che le persone sono più tentate di infrangere: un cable ID non si riutilizza mai, nemmeno il numero di un cavo rimosso da tempo. I nostri provengono da un allocator dedicato, vengono riservati prima che le etichette siano stampate, e sono sorvegliati contro i duplicati. Perché il familiare metodo «il numero più alto più uno» fallisce, e come si gestisce correttamente l'allocazione, è l'argomento di Numerare i cavi: perché «il più alto più uno» è la regola sbagliata.

Costruite prima sulla carta

Tutto questo converge in un'abitudine: il nuovo hardware è completamente nel registro prima di arrivare. Unità rack, controller di gestione, ogni porta con il suo indirizzo MAC, i port-channel, le porte switch all'altro capo, e un cable ID riservato per ogni link. Il set di etichette viene stampato in anticipo, e l'hardware viene messo in rack e cablato secondo un piano che è già il registro. La verifica alla fine è allora un confronto, non una ricostruzione.

Controllate i vostri registri

• Scegliete un indirizzo segnato come libero ed eseguite tutti e tre i controlli. Concordano?
• Scegliete un server e confrontate i suoi MAC registrati con la tabella MAC dello switch.
• Eseguite LLDP su un rack e confrontate ogni link con il registro.
• Confrontate i WWPN di ogni host nel registro con nsshow su entrambi i fabric.
• Cercate qualsiasi numero di cavo che compaia su due link.

Se state pianificando una migrazione e volete che sia costruita a partire da un registro di cui potete fidarvi, possiamo aiutarvi. Parla con un ingegnere

Related (rows[1])

Correlati: DCIM: ogni oggetto, porta, cavo e indirizzo tracciato · Installazione in rack, onboarding dei blade, controller di gestione · Monitoraggio di potenza e capacità