Cosa controllare su un nuovo server prima che porti produzione

Un nuovo server dedicato arriva di solito con un sistema operativo, un login e un presupposto: che tutto ciò che avete pagato sia presente, sano e configurato per essere usato. Il più delle volte è quasi vero. Il divario tra quasi e del tutto è il punto da cui nascono database lenti, link di rete inattivi e interruzioni a sorpresa. Ecco il controllo di accettazione che pensiamo meriti ogni server prima di portare produzione, con i comandi per eseguirlo da soli.

Perché il test di accettazione viene saltato

Un server che si avvia sembra finito. Il sistema operativo non si lamenta di un modulo di memoria che non vede, di una cache RAID che gira senza la sua batteria, o di un bond che manda ogni pacchetto su un solo link. Ognuna di queste cose è invisibile nell'uso normale e costosa più avanti, e ognuna richiede minuti per essere controllata il primo giorno. Dopo il go-live, gli stessi controlli richiedono una finestra di manutenzione.

Memoria: tutta, bilanciata, senza errori

Confermate che il sistema vede ogni modulo che avete ordinato, e che i moduli siedono in una disposizione bilanciata sui canali di memoria di ogni processore. Una disposizione sbilanciata funziona, ma più lentamente di quanto dovrebbe.

dmidecode -t memory | grep -E 'Size|Locator' | grep -v 'No Module'
free -h
ras-mc-ctl --errors

Errori di memoria corretti nei primi giorni di vita di un server sono un motivo per sostituire un modulo adesso, finché è facile, non una curiosità da osservare.

Dischi e controller RAID

Leggete la salute di ogni disco, compresi quelli nascosti dietro un controller RAID hardware, e lo stato della cache in scrittura del controller:

smartctl -a /dev/sda
smartctl -a -d megaraid,0 /dev/sda    # a drive behind a MegaRAID-family controller
storcli64 /c0 show all                # Dell PERC and LSI family
ssacli ctrl all show config detail    # HPE Smart Array

Cercate contatori diversi da zero di settori riallocati, in attesa o di errori del supporto su qualunque disco. Un disco nuovo con un errore corretto è un disco la cui correzione d'errore sta già lavorando sodo. Sul controller, confermate che il drive logico è del livello RAID che avete ordinato, che la cache è in modalità write-back e che il modulo di cache con batteria o flash riporta uno stato sano. Un controller passato a write-through a causa della batteria può far sembrare un array di SSD un disco rotativo.

Poi misurate il throughput sul volume vuoto prima che contenga dati, con uno strumento come fio, così avrete una baseline con cui confrontarvi più avanti.

Il flash viene trattato come flash?

I controller RAID hardware spesso non passano al kernel il flag di stato solido, quindi un volume costruito con SSD viene riportato come disco rotativo e riceve impostazioni tarate per i supporti rotanti:

lsblk -d -o NAME,ROTA,SCHED,MODEL
cat /sys/block/sda/queue/read_ahead_kb

Se ROTA dice 1 su un volume che sapete essere flash, confermate prima il tipo di supporto dal controller, poi correggetelo con una regola udev perché sopravviva ai riavvii:

# /etc/udev/rules.d/60-ssd-tunings.rules
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}="0"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/read_ahead_kb}="16"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/nr_requests}="1024"

udevadm control --reload && udevadm trigger --action=change /sys/block/sda

Non applicatelo a un volume su dischi rigidi. Un read ahead corto si addice al flash e penalizza le letture sequenziali dai supporti rotanti.

Rete: due link, entrambi funzionanti

Un server con due porte in bond spesso ne usa una sola. L'hash di trasmissione predefinito del driver di bonding di Linux guarda solo gli indirizzi MAC, e in un datacenter, dove un host parla con una manciata di MAC di gateway e peer, questo può mettere quasi ogni flusso sullo stesso link.

cat /proc/net/bonding/bond0
ethtool -S <first port> | grep -E 'tx_packets|rx_packets'
ethtool -S <second port> | grep -E 'tx_packets|rx_packets'

Controllate che entrambi i membri siano su, che LACP si sia accoppiato con lo switch, e che la policy di hash sia quella che intendevate. Sotto carico, i contatori di entrambi i membri dovrebbero crescere a ritmi simili. Per la maggior parte dei server, fare l'hash su indirizzi IP e porte distribuisce il traffico molto meglio:

nmcli con mod bond0 bond.options "mode=802.3ad,miimon=100,lacp_rate=slow,xmit_hash_policy=layer3+4"

Allineate il lato switch, così il traffico viene distribuito allo stesso modo in entrambe le direzioni. Poi staccate un cavo, confermate che il server resta raggiungibile, ricollegatelo, e ripetete con l'altro.

Alimentazione, tempo e accesso remoto

ipmitool sdr type "Power Supply"
chronyc tracking
getenforce

Entrambi gli alimentatori dovrebbero essere presenti e alimentati, e dovrebbero essere serviti da linee di alimentazione diverse. Un server con due alimentatori collegati alla stessa linea ha un singolo punto di guasto con qualche passaggio in più. Confermate che il controller out of band (iLO, iDRAC o IPMI) è raggiungibile sulla sua rete di gestione e licenziato per la console remota di cui avrete bisogno. Se SELinux fa parte del vostro standard, confermate che è in enforcing prima che venga installata la prima applicazione, non dopo.

Scrivetelo

L'ultimo controllo è la documentazione: numero di serie, posizione nel rack, ogni porta con il suo indirizzo MAC e a cosa si collega, ogni indirizzo IP, entrambe le linee di alimentazione e gli ID dei cavi.

Come lo facciamo noi

I nostri server dedicati sono piattaforme HPE ProLiant e Dell PowerEdge, con gestione out of band su una rete isolata. Ogni build RAID riceve un passaggio di salute dei dischi e un test di throughput prima della consegna. Il flash dietro un controller RAID riceve il tuning qui sopra, legato al tipo di supporto letto dai dischi. Ogni bond fa l'hash su indirizzi e porte, allineato sullo switch. Controlliamo i contatori per porta per dimostrare che entrambi i link portano traffico.

Se avete un server già in produzione che non ha mai avuto questo controllo, non è troppo tardi, e siamo lieti di percorrerlo con voi.

cta: Parla con un ingegnere

Related

• /what-we-do/storage-compute/bare-metal-servers/
• /what-we-do/storage-compute/performance-engineering/
• /what-we-do/storage-compute/enterprise-san-storage/