Guida al datacenter meno efficiente del mondo

Cosa stai realizzando

Ogni guida di questo sito insegna a eseguire correttamente un'attività: i comandi nell'ordine previsto, l'aspetto di un risultato corretto e le modalità di errore previste. Questa guida è diversa. Oggi, in via del tutto ipotetica, progetteremo il datacenter meno efficiente che denaro, elettricità e arroganza possano produrre.

Ci serve una metrica, quindi useremo quella adottata dal settore: PUE, Power Usage Effectiveness, cioè la potenza totale della struttura divisa per la potenza che raggiunge effettivamente le apparecchiature di calcolo. Un datacenter hyperscale ha un valore intorno a 1.1: quasi ogni watt svolge un lavoro utile. Una sala server aziendale di buon livello arriva a 1.5. Il nostro obiettivo è 4.0 o superiore: per ogni watt destinato al calcolo, altri tre watt vengono consumati inutilmente. Useremo spesso questo numero, come fanno le guide serie con i backup.

Selezione del sito: il calore è il punto

Il raffreddamento è il principale costo operativo aggiuntivo in un datacenter reale. Per questo il nostro contrasterà la termodinamica direttamente sul suo terreno. La posizione ideale è una soffitta. Rivolta a sud. Preferibilmente con un lucernario posizionato in modo da illuminare direttamente il server, così il sistema riceverà sia il proprio calore di scarto sia quello del sole: una collaborazione tra la bolletta elettrica e una stella.

In inverno, il raffreddamento si gestisce aprendo la finestra. I datacenter reali usano l'aria esterna; la tecnica si chiama free cooling ed è progettata, filtrata e sottoposta al controllo dell'umidità. Noi la useremo accidentalmente, attraverso una finestra che lascia entrare anche pioggia, polline e almeno un uccello disorientato ogni trimestre.

Per ottenere un risultato davvero accurato, installa un condizionatore, quindi posiziona un termoventilatore a circa due piedi dal suo termostato e impostalo su una temperatura di due gradi superiore a quella configurata sul condizionatore. Entrambe le macchine funzioneranno ora ininterrottamente, per sempre, in perfetto disaccordo. Il fornitore di energia ti manderà un biglietto a Natale.

Un server, grande e indispensabile

La ridondanza diluisce l'impegno. Il nostro datacenter contiene esattamente un server, ed è enorme, perché una singola macchina con 512 GB di RAM dà l'impressione di essere infrastruttura, mentre quattro macchine piccole sembrano una lista di attività.

Il server ha un nome. Non un hostname, un nome. Di solito Gandalf oppure Odin. Non puoi dismettere Odin. Odin è operativo da cinque anni:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

Quel numero è motivo di orgoglio. Per questo ne fai uno screenshot e lo pubblichi. Ogni attaccante che vede lo screenshot lo considera altrettanto impressionante: 1,847 giorni di uptime equivalgono a 1,847 giorni di vulnerabilità del kernel, senza che nessuno abbia applicato le patch. Il riavvio è comunque fuori discussione. Un riavvio serve a scoprire quali servizi sono stati avviati manualmente nel 2021 e non sono mai stati definiti in una unità systemd. Nessuno ricorda quali siano. Ora il server è diventato un elemento critico dell'organizzazione.

Storage: velocità e altri modi per perdere dati

I dischi sono configurati in RAID 0 per ottenere prestazioni migliori. Lo zero indica il numero di dischi che possono guastarsi. Per ottenere il massimo effetto, distribuisci lo striping dell'array su dispositivi di archiviazione di provenienza diversa: due SSD affidabili, un disco meccanico datato e una chiavetta USB ricevuta a una conferenza. L'affidabilità dell'array è esattamente quella della chiavetta della conferenza: è questo il risultato previsto.

I backup sono gestiti da una directory sullo stesso array, denominata backup_final_v2_REAL, che contiene un archivio tar dello schema di denominazione precedente. I backup off-site sono rappresentati da un post-it con scritto "configurare i backup off-site"; tecnicamente, il post-it è archiviato off-site quando lo porti a casa sul coperchio del laptop.

Un risultato corretto è il seguente: df segnala un utilizzo del 97% e prevedi di occuparsene nel prossimo sprint.

Rete: un unico punto di dipendenza

Il server DNS è in esecuzione sulla macchina stessa. Quando il server si arresta, rende irraggiungibile anche il record DNS che useresti per capire perché si è arrestato. Questo si chiama consolidamento.

Il firewall è stato disabilitato nel 2021, temporaneamente, per eseguire il debug di un problema. Il debug è terminato, ma il firewall non è stato riattivato. Tutte le porte del router vengono inoltrate al server «per risparmiare tempo in futuro». Il pannello di amministrazione del router è inoltre raggiungibile dal lato WAN e usa ancora la password predefinita di fabbrica, per semplificare la gestione remota. La tua e quella di altri.

Il server funziona a una temperatura insolitamente elevata, anche considerando che si trova in soffitta, e top indica che il processo più impegnativo è qualcosa chiamato xmrig. Presumiamo che sia lo strumento di monitoraggio che stiamo utilizzando. Non lo abbiamo installato noi: è comparso autonomamente poco dopo l'inoltro delle porte. Interpretiamo questo come un segnale che l'ecosistema è in buona salute. Esegue il monitoraggio ininterrottamente.

L'alimentazione passa attraverso una catena di multiprese per uso domestico la cui lunghezza complessiva supera la distanza da percorrere a piedi fino al quadro elettrico. In un certo senso è efficiente, perché visiterai spesso il quadro elettrico.

Ridondanza attraverso la complessità

Dopo aver rifiutato la ridondanza dove sarebbe utile, la aggiungiamo dove non serve. La homepage aziendale, un singolo file HTML statico, viene servita da un cluster Kubernetes a dodici nodi. Questo realizza quella che gli ingegneri chiamano architettura orientata al curriculum: la pagina si carica negli stessi quaranta millisecondi necessari a nginx per servirla, ma ora può avere problemi che richiedono l'intervento di un consulente.

Per l'isolamento, il cluster stesso viene eseguito all'interno di una macchina virtuale dentro una macchina virtuale dentro una macchina virtuale, e ogni livello aggiunge sicurezza, come gli strati di un turducken aggiungono carne di volatile. Il modulo di contatto è composto da nove microservizi. Due non sono mai stati invocati. Uno è indispensabile al funzionamento e nessuno sa quale.

Il riscaldamento come servizio

Un server moderno trasforma l'elettricità in calcolo e calore; il nostro obiettivo è massimizzare il secondo risultato. Un media server senza GPU è l'approccio classico: la transcodifica CPU di un singolo flusso 4K può saturare sedici core e riscaldare una camera da letto di piccole dimensioni, come un termoventilatore che riproduce anche film. L'operatore più ambizioso passa a eseguire un modello linguistico di grandi dimensioni su CPU, un termoventilatore da 70 miliardi di parametri con un'API, che genera token a una velocità misurabile al meglio su scala stagionale.

Il monitor monitora se stesso

L’osservabilità è importante, quindi distribuiamo un monitor self-hosted dell’uptime sullo stesso server che deve monitorare. Quando Odin si arresta, anche il monitor si arresta. Ecco l’aspetto più elegante: non viene generato alcun avviso. Nessun avviso significa nessun incidente. Nessun incidente significa uptime perfetto, secondo le metriche raccolte. Il report mensile non è mai stato così positivo.

Per completezza, le email di avviso vengono inoltrate tramite un mail server che viene eseguito anch’esso su Odin. La pipeline di alerting è quindi completamente autonoma, come un sistema che non può rilevare il proprio guasto.

La parte scomoda

Ecco la sezione che continuavo a rimandare. Nulla di tutto questo è inventato. Il server insostituibile a cui tutti erano affezionati, il RAID 0 con i backup sullo stesso volume, il firewall disabilitato «temporaneamente», il cluster Kubernetes che pubblicava una sola pagina, il sistema di monitoraggio che controllava se stesso: li ho visti tutti in produzione. Alcuni li ho visti quest'anno. Uno o due, agli inizi, li ho configurati io.

L'efficienza reale è noiosa. Per questo, sul momento, perde la discussione, ma nell'arco di un decennio la vince: un PUE a cui non pensi mai perché è stato progettato da qualcun altro. Macchine dimensionate in base al carico di lavoro, non all'immagine che il proprietario ha di sé. Un blast radius valutato prima dell'esplosione. Backup verificati ripristinandoli secondo una pianificazione, con un promemoria sul calendario e senza eroismi. Ridondanza banale: due componenti economici sono meglio di uno straordinario, ogni volta e in ogni guasto per cui io abbia mai ricevuto una segnalazione.

E il datacenter più efficiente che puoi gestire è quello che non gestisci. Un VPS affida alimentazione, raffreddamento, ridondanza e guasti hardware alle 3 di notte a persone che gestiscono questi aspetti su larga scala, in modo metodico e senza complicazioni: è il complimento più alto che l'infrastruttura possa ricevere. A te lascia la parte davvero interessante, cioè gestire i tuoi servizi sopra di esso, su una macchina che puoi permetterti di perdere: è l'unico tipo di macchina su cui dovresti fare esperimenti.

FAQ

Devo davvero fare qualcosa di tutto questo?

No. Ogni sezione di questa guida descrive un anti-pattern documentato, con un costo misurabile in weekend persi. Se la configurazione attuale assomiglia a più di due sezioni, vai direttamente all'ultima domanda di questa FAQ, seguendo l'ordine indicato: è l'ordine del triage.

Qual è, in pratica, un buon PUE?

I datacenter hyperscale si attestano intorno a 1.1, una sala aziendale gestita correttamente mantiene valori compresi tra 1.4 e 1.6, mentre un ripostiglio senza raffreddamento, in conflitto con una stufa elettrica, può superare realmente 3. A casa non puoi competere in modo significativo con 1.1. Questo è l'argomento economico, poco evidente ma concreto, a favore del noleggio di risorse di calcolo da chi può offrirle.

Riscaldare un edificio con i server è una pratica reale?

Sì, se viene fatto correttamente. In diversi Paesi, i progetti di teleriscaldamento recuperano il calore residuo dei datacenter tramite scambiatori di calore e lo convogliano nelle abitazioni mediante tubazioni, secondo un progetto preciso, con adeguata ingegneria e contratti. La satira precedente non riguarda il fatto che il calore dei server possa riscaldare un ambiente. Riguarda il farlo accidentalmente e definire l'incidente una strategia.

Il mio server è già in queste condizioni. Da dove inizio?

Esegui subito un backup, questa sera, su una destinazione diversa dal server, quindi verifica il ripristino. Un backup non verificato è solo un'ipotesi. Secondo: installa le patch ed esegui il riavvio che stai rimandando, in una finestra di manutenzione pianificata, così puoi individuare i problemi mentre controlli il sistema. Terzo: elimina il single point of failure. Sposta DNS e monitoraggio fuori dal server. Tutto il resto può aspettare una settimana più tranquilla; questi tre interventi no.