Realtà hardware, limiti delle risorse e monitoraggio approfondito delle prestazioni

Quando un NAS QNAP sembra lento, l'indagine inizia da ciò che il suo hardware è in grado di fare. Poi analizza su cosa il NAS spende le proprie risorse, e solo successivamente passa alle code più profonde: processi bloccati in I/O e macchine virtuali in conflitto per il processore.

1. Aspettativea cosa serve questo hardware
2. Baselineferma gli extra, osserva RAM e SWAP
3. Stati Dprocessi bloccati in I/O
4. vCPUthread, oversubscription, steal
5. GraficiBlackBox e Pulse, leggerli bene

01Aspettative e realtà dell'hardware

I server QNAP sono costruiti con componenti in linea con il loro prezzo. QNAP rilascia ancora aggiornamenti firmware per unità con più di dieci anni, ma ciò non significa che un NAS vecchio o entry-level possa eseguire l'intera gamma delle app odierne senza compromessi. Il software diventa più pesante man mano che si sviluppa; l'hardware rimane quello di una volta.

Un NAS economico è progettato per servire file in modo fluido. Aspettarsi che esegua macchine virtuali o database pesanti senza problemi significa travisare la sua natura. Verifica cosa possono realmente fare il tuo processore e la tua memoria, e assumiti la responsabilità della scelta dell'hardware. Il lavoro principale del NAS è gestire file; tutto il resto è un'aggiunta che funziona sfruttando le risorse rimanenti.

02Ramo 1: la baseline, isolando i servizi

Quando il NAS rallenta, soprattutto quando la memoria si esaurisce e inizia a usare lo SWAP (il che rallenta bruscamente ogni operazione), il primo passo diagnostico è isolare i servizi.

1. Accedi a QTS o QuTS hero.
2. Apri l'App Center e interrompi le app e i servizi non essenziali uno per uno. Workbench non interrompe le app al posto tuo.
3. Osserva il sistema nel Resource Monitor di QTS o in Pulse di Workbench (scrivania Utilities, menu Start → Monitoring → Pulse; solo amministratori). Il suo cockpit si aggiorna ogni due secondi: utilizzo CPU con una barra per ogni CPU logica, RAM usata rispetto al totale con la page cache in una fascia dedicata, una barra SWAP quando il NAS ha memoria swap, il carico a 1 minuto (1-minute load) e la coda di esecuzione (run queue). Osserva scendere il carico della CPU e lo SWAP in uso.
4. Trova la baseline: continua a interrompere i servizi finché la funzione principale del NAS, servire file in modo fluido, non torna del tutto.

Quella è la baseline del tuo hardware. A partire da essa, avvia le altre app una alla volta, restando rigorosamente nelle risorse che l'hardware ha ancora libere.

03Ramo 2: Stati D e colli di bottiglia nascosti

A volte il problema non è una CPU sovraccarica o la mancanza di RAM. Il sistema può bloccarsi con il processore tutt'altro che pieno quando i processi rimangono in uninterruptible sleep, lo stato D. Nelle parole stesse di Workbench, un processo in stato D è bloccato in attesa di I/O dal kernel (un disco, un file system di rete, un driver bloccato) e non può nemmeno essere terminato finché tale I/O non viene completato. Molti processi in D significano che si stanno accumulando in coda, solitamente dietro a operazioni I/O lente del disco, e il dispositivo si blocca.

Questa attesa in coda è particolarmente deleteria quando il NAS ospita macchine virtuali (Virtualization Station, KVM). Un'allocazione errata delle risorse in questo ambito si manifesta con pacchetti di rete persi e lunghi ritardi di I/O.

• Pulse segnala Processes in D-state (I/O) non appena un processo entra in stato D, e lo segna come critico quando sono più di due. Nella sua scheda Processes, D + Z mostra solo i processi bloccati (D) e gli zombie (Z) insieme ai relativi processi padre.
• BlackBox registra i dati del NAS ogni 20 secondi dal momento in cui il pacchetto è in esecuzione; non c'è nulla da attivare. Memorizza l'utilizzo della CPU, iowait e clock per core, il carico (load), la coda di esecuzione (run queue) e Blocked (D); memoria utilizzata e disponibile, page cache, swap e OOM kills; per ogni interfaccia il traffico, i drop e le ritrasmissioni TCP; per ogni disco l'await, la profondità della coda e l'utilizzo; le temperature e le ventole; e per ogni VM la relativa CPU, vCPU, memoria e I/O del disco. Conserva ogni campione da 20 secondi per un giorno, poi produce riepiloghi al minuto per una settimana, ogni cinque minuti per un mese e ogni ora per un anno.
• Due conteggi D differenti. Blocked (D) di BlackBox è il conteggio del kernel dei task bloccati; Pulse conta i processi che vede in stato D. Non è detto che debbano coincidere.
• iowait, non PSI. I kernel di QNAP sono compilati senza pressure stall information, pertanto Workbench misura il ritardo I/O come iowait.

04Allocazione CPU: pCPU, lCPU e vCPU

Prima di assegnare le risorse a una VM, comprendine la topologia:

• pCPU (physical CPU): i core fisici del processore del NAS.
• lCPU (logical CPU): i core visti dal sistema operativo, incluso l'Hyper-Threading. L'Hyper-Threading non raddoppia le prestazioni; come regola pratica aggiunge circa il 30% di throughput.
• vCPU (virtual CPU): i core virtuali assegnati alle VM.

Pulse conta le CPU logiche: quando indica 12 cores su uno Xeon W-1250 a sei core e dodici thread, si tratta di thread.

La trappola dell'oversubscription. Assegnare 128 vCPU a VM su un processore a 32 core presuppone che non siano mai tutte occupate nello stesso momento. Quando succede, l'hypervisor non riesce a pianificare i vCPU abbastanza velocemente, e le VM si bloccano in attesa di tempo CPU, il che, all'interno di un sistema guest, si presenta come steal time (tempo rubato). Pulse lo segnala dal lato host:

• vCPU over-subscription (informazione) quando le VM in esecuzione hanno più vCPU di quante CPU logiche possieda il NAS;
• VMs contending for CPU (avviso) quando, inoltre, l'host è occupato per oltre il 75% o la sua coda di esecuzione è più lunga del numero di thread. La relativa nota su questo NAS: Over-subscribed (17 vCPUs / 12 cores) AND the host is busy (84%, queue 11) — your VMs are likely contending for physical cores NOW. This is CPU theft, host-side.
• Steal time viene misurato all'interno del guest. Sul NAS, per sua natura, restituisce zero; una nota di Workbench stessa spiega che non è possibile vedere lo steal di un guest dall'host. Valuta la contention sul NAS in base alle vCPU rispetto ai thread, alla percentuale di occupazione e alla coda di esecuzione, e leggi lo steal dall'interno della VM (la colonna st di top o vmstat in un guest Linux).

05Osservazione delle macchine virtuali

Workbench non richiede l'installazione di alcun agente in una VM. Misura il NAS su cui viene eseguito, e questo include le macchine virtuali ospitate dal NAS:

1. Apri Pulse, scheda VM: ogni VM in esecuzione con i suoi vCPU, CPU%, memoria, RSS, stato e ID del processo, e la riga di intestazione Hosting 4 VM(s), 17 vCPUs.
2. Apri BlackBox (Menu Start → Monitoring), passa a Heat map e attiva la riga Virtual machines: la CPU di ogni VM durante il giorno, accanto alle temperature e all'await dei dischi. I suoi grafici registrano inoltre i vCPU, la memoria e l'I/O su disco di ogni VM, nonché l'avvio e l'arresto di ciascuna VM.
3. Per verificare la raggiungibilità di rete di una VM, aggiungi il suo indirizzo in BlackBox sotto Settings → Monitored hosts: BlackBox ne registrerà quindi il round trip e la perdita di pacchetti.
4. All'interno della VM, controlla il suo steal time con gli strumenti nativi del guest.

La finestra Virtual Machines · LOCAL (Local NAS → Virtual Machines) mostra la configurazione di ciascuna VM tratta da Virtualization Station: i suoi vCPU, la topologia, il CPU set, il modello di CPU, i dischi e le schede di rete. Quando la apri, la finestra esegue i dump diagnostici di QNAP e li salva nella cache di Workbench; non cambia alcuna impostazione.

06Lettura dei grafici: gli stati critici

• Molti processi in stato D e ritardo I/O elevato. I processi sono in attesa sui dischi. Il report settimanale di BlackBox lo definisce Processes waiting on storage (un iowait al 95° percentile del 20% o più costituisce un avviso, dal 40% in su è critico) e indica il disco più impegnato; Slow array member segnala un disco il cui await è il doppio di quello degli altri dischi dell'array e pari ad almeno 50 ms (critico a 200 ms), e Disk with no headroom uno che risulta occupato al 90% o più per due ore. Il rimedio è quello che consiglia l'autore: sposta la VM su un volume SSD, verifica lo stato di salute dei dischi (la guida alle prestazioni), e accertati che nessun altro processo stia saturando il RAID.
• Elevata coda CPU (CPU queueing). Il processore del NAS è oversubscribed: Pulse segnala VMs contending for CPU, e Virtual machine hogging the host nel report settimanale segnala una VM che utilizza il 150% di un core o più (300% critico). Assegna meno vCPU alle VM: inizia con uno o due per VM e aggiungine altri solo quando il guest ne ha bisogno.
• Throttling termico (Thermal throttling). Un'elevata temperatura della CPU, seguita da un clock inferiore e ritardi più lunghi, significa che il processore si sta surriscaldando. Il report settimanale lo definisce CPU thermal throttling: un core che gira al 60% o meno del suo normale clock mentre la CPU è impegnata per almeno il 60%. Sulla mappa di calore, 65 °C è color ambra e 80 °C rosso. Il consiglio di Workbench stesso: rimuovi la polvere dal dissipatore, dalle ventole e dalle prese d'aria, verifica che le ventole girino e migliora il flusso d'aria o abbassa la temperatura della stanza; anche una maggiore velocità delle ventole in QTS è d'aiuto.

07Buone pratiche KVM: il modello CPU

• Host / passthrough (consigliato): passa il processore del NAS stesso alla VM, con ogni set di istruzioni di cui dispone (AVX, per esempio). Fornisce le migliori prestazioni e il minor overhead su un singolo NAS.
• Un modello emulato (una CPU Intel o AMD generica): nasconde il processore dell'host. È utile in un cluster, per spostare le VM in esecuzione tra host fisicamente differenti; su un singolo NAS fa solo perdere prestazioni.

La finestra Virtual Machines · LOCAL mostra il modello di CPU assegnato a ogni VM (ad esempio Westmere) e la sua topologia; Workbench non giudica la scelta effettuata.

08Conoscenze di base: overcommit delle risorse

Come non far crollare le prestazioni delle VM quando il NAS lavora al limite. Il rapporto tra vCPU e core fisici (pCPU) è la prima cosa che vale la pena contare:

Regola generale. L'overcommit è sicuro con un carico leggero e discontinuo accompagnato da monitoraggio attivo, ma è pericoloso durante i picchi se non si ha margine. Mantieni una riserva.