Come creare il datacenter meno efficiente

Cosa stai costruendo

Ogni guida su questo sito insegna a fare qualcosa correttamente: i comandi nell'ordine giusto, l'aspetto di un risultato corretto e la descrizione dei possibili errori. Questa guida è diversa. Oggi, in modo puramente ipotetico, progetteremo il datacenter meno efficiente che il denaro, l'elettricità e l'arroganza possano produrre.

Abbiamo bisogno di una metrica, quindi utilizzeremo quella del settore: PUE, Power Usage Effectiveness — la potenza totale dell'impianto divisa per la potenza che raggiunge effettivamente l'hardware di calcolo. Un datacenter hyperscale opera intorno a 1.1: quasi ogni watt svolge un lavoro utile. Una decente sala server aziendale gestisce un valore di 1.5. Il nostro obiettivo è 4.0 o superiore, il che significa che per ogni watt di calcolo, altri tre watt vengono sprecati. Faremo riferimento a questo numero spesso, come fanno le guide serie quando parlano di backup.

Selezione del sito: il calore è l'obiettivo

Il raffreddamento è la singola voce di spesa più alta in un datacenter reale, motivo per cui il nostro sfiderà la termodinamica sul suo terreno di gioco. La posizione ideale è una soffitta. Orientata a sud. Idealmente con un lucernario posizionato per far cadere la luce direttamente sul server, in modo che la macchina riceva sia il proprio calore residuo che quello del sole, una collaborazione tra la tua bolletta elettrica e una stella.

In inverno, il raffreddamento è gestito aprendo la finestra. I veri datacenter utilizzano l'aria esterna — la tecnica è chiamata free cooling, ed è progettata, filtrata e controllata per l'umidità. Noi la useremo accidentalmente, attraverso una finestra che ammette anche pioggia, polline e almeno un uccello confuso per trimestre.

Per un vero livello artistico, installa un condizionatore, poi posiziona una stufetta elettrica a 60 cm dal suo termostato, impostata due gradi più calda rispetto al target del condizionatore. Entrambe le macchine ora funzioneranno continuamente, per sempre, in perfetto disaccordo. La compagnia elettrica ti invierà un biglietto di auguri a Natale.

Un server, grande, amato

La ridondanza diluisce l'impegno. Il nostro datacenter contiene esattamente un server, ed è enorme, perché una singola macchina con 512 GB di RAM sembra un'infrastruttura, mentre quattro macchine piccole sembrano una lista di cose da fare.

Il server ha un nome. Non un hostname — un nome. Gandalf, di solito, o Odin. Non puoi decommissionare Odin. Odin è acceso 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, motivo per cui ne fai uno screenshot e lo pubblichi, e motivo per cui ogni attaccante che vede lo screenshot lo trova impressionante: 1,847 giorni di uptime significano 1,847 giorni di vulnerabilità del kernel, non patchate da nessuno. Riavviare è comunque fuori discussione — un reboot è il modo in cui scopri quali servizi sono stati avviati manualmente nel 2021 e mai scritti in un'unità systemd. Nessuno ricorda quali. Il server è ora un pilastro fondamentale dell'organigramma aziendale.

Storage: velocità e altri modi per perdere dati

I dischi sono configurati in RAID 0, per le prestazioni. Lo zero si riferisce al numero di dischi che possono guastarsi. Per il massimo effetto, crea lo stripe dell'array utilizzando storage di provenienza mista: due SSD propri, un vecchio hard disk meccanico e una chiavetta USB recuperata da una conferenza. L'array è affidabile esattamente quanto la chiavetta della conferenza, ed è questo il design previsto.

I backup sono gestiti da una directory sullo stesso array chiamata backup_final_v2_REAL, che contiene un tarball del precedente schema di denominazione. I backup off-site sono rappresentati da un post-it con scritto "configura backup off-site", che è, tecnicamente, memorizzato off-site quando lo porti a casa sul coperchio del tuo laptop.

Un risultato corretto consiste in: df che riporta un utilizzo del 97% e un piano per gestirlo nel prossimo sprint.

Networking: un singolo filo per tutto

Il server DNS gira sulla macchina stessa, in modo che quando il server si guasta, trascini con sé il record DNS che useresti per scoprire il motivo del guasto. Questo si chiama consolidamento.

Il firewall è stato disabilitato nel 2021 — temporaneamente, per debuggare qualcosa. Il debugging si è concluso; il firewall non è tornato. Ogni porta sul router è inoltrata al server "per risparmiare tempo in seguito", e il pannello admin del router è raggiungibile dal lato WAN con la password di fabbrica, per una comoda gestione remota. La tua, e quella di altri.

Il server è stato insolitamente caldo ultimamente, anche per gli standard di una soffitta, e top mostra che il processo più impegnativo è qualcosa chiamato xmrig. Assumiamo che questo sia lo strumento di monitoraggio che stiamo usando. Non lo abbiamo installato — è apparso da solo poco dopo che le porte sono state inoltrate, il che interpretiamo come un segno che l'ecosistema sta prosperando. Monitora ventiquattr'ore su ventiquattro.

L'energia arriva attraverso una catena di ciabatte elettriche la cui lunghezza combinata supera la distanza da percorrere fino al quadro elettrico — il che è efficiente, in un certo senso, perché visiterai spesso il quadro elettrico.

Ridondanza attraverso la complessità

Avendo rifiutato la ridondanza dove conta, ora la aggiungiamo dove non serve. La homepage aziendale — un singolo file HTML statico — è servita da un cluster Kubernetes a dodici nodi. Questo ottiene ciò che gli ingegneri chiamano architettura guidata dal curriculum: la pagina si carica nello stesso tempo di 40 millisecondi che nginx avrebbe garantito, ma ora può guastarsi in modi che richiedono un consulente.

Per l'isolamento, il cluster stesso gira all'interno di una macchina virtuale dentro una macchina virtuale dentro una macchina virtuale, dove ogni livello aggiunge sicurezza proprio come ogni strato di un turducken aggiunge un uccello. Il modulo di contatto è composto da nove microservizi. Due di essi non sono mai stati invocati. Uno di essi è fondamentale e nessuno sa quale.

Heating as a service

Un server moderno converte l'elettricità in calcolo e calore, e noi intendiamo massimizzare la seconda produzione. Un media server senza GPU è la scelta classica: il transcoding via CPU di un singolo stream 4K saturerà sedici core e scalderà una piccola camera da letto, una stufetta che riproduce anche film. L'operatore ambizioso passa a eseguire un large language model su CPU — una stufetta da 70 miliardi di parametri con un'API, che produce token a un ritmo che può essere misurato solo stagionalmente.

Il monitor osserva se stesso

L'osservabilità è importante, quindi implementiamo un monitor di uptime self-hosted — sullo stesso server che monitora. Quando Odin muore, il monitor muore con lui, ed ecco la parte elegante: non scatta alcun avviso. Nessun avviso significa nessun incidente. Nessun incidente significa uptime perfetto, secondo la misurazione. Il report mensile non è mai stato così bello.

Le email di avviso, per completezza, sono inoltrate tramite un server mail che gira anch'esso su Odin. La pipeline di alerting è quindi completamente autonoma, nello stesso modo in cui un serpente che si mangia la coda è completamente sazio.

La parte scomoda

Ecco la sezione che ho rimandato a lungo. Nulla di tutto questo è finzione. Il server amato e insostituibile, il RAID 0 con i backup sullo stesso volume, il firewall disabilitato "temporaneamente", il cluster Kubernetes che serve una singola pagina, il monitor che osserva se stesso — ho visto ognuna di queste cose in produzione. Alcune le ho viste quest'anno. Una o due di esse, ai miei inizi, le ho costruite io.

Ciò che rappresenta l'efficienza reale è noioso, motivo per cui perde l'argomentazione nell'immediato ma vince su un decennio: un PUE di cui non pensi mai perché qualcun altro lo ha progettato. Macchine dimensionate per il loro carico di lavoro invece che per l'immagine di sé del proprietario. Un raggio d'azione (blast radius), considerato prima dell'esplosione. Backup testati tramite ripristino, secondo una pianificazione, con un promemoria a calendario e senza eroismo. Ridondanza noiosa — due oggetti economici battono uno magnifico, ogni volta, in ogni guasto per cui mi hanno chiamato.

E il datacenter più efficiente che puoi gestire è quello che non gestisci. Un VPS delega l'energia, il raffreddamento, la ridondanza e i guasti hardware alle 3 del mattino a persone che li gestiscono su larga scala, in modo noioso, che è il più alto complimento che un'infrastruttura possa ricevere — e ti lascia la parte davvero divertente, ovvero eseguire i tuoi servizi sopra di esso, su una macchina che puoi permetterti di perdere, che è l'unico tipo su cui dovresti mai sperimentare.

FAQ

Dovrei davvero fare una di queste cose?

No. Ogni sezione di questa guida è un anti-pattern documentato con un numero di vittime misurato in weekend persi. Se la tua configurazione attuale assomiglia a più di due sezioni, salta all'ultima domanda di questa FAQ — nell'ordine fornito, perché l'ordine è il triage.

Qual è un buon PUE, in realtà?

I datacenter hyperscale operano intorno a 1.1, una stanza aziendale ben gestita gestisce da 1.4 a 1.6, e un armadio non raffreddato con una disputa tra stufette elettriche può superare davvero 3. Non puoi competere significativamente con 1.1 a casa, che è il motivo economico per affittare potenza di calcolo da chi può farlo.

Riscaldare un edificio con i server è una cosa reale?

Sì — se fatto correttamente. I progetti di teleriscaldamento in diversi paesi catturano il calore residuo dei datacenter attraverso scambiatori di calore e lo convogliano nelle case, per design, con ingegneria e contratti. La satira sopra non è che il calore dei server possa scaldare una stanza; è che lo fa per caso e chiama l'incidente una strategia.

Il mio server ha già questo aspetto. Cosa faccio per primo?

Backup, stasera, in un luogo che non sia il server, e poi un test di ripristino — un backup non testato è solo una voce. Secondo, patch e il reboot che stai evitando, in una finestra pianificata, così imparerai cosa si rompe mentre stai guardando. Terzo, separa il punto di guasto singolo: sposta il DNS e il monitoraggio fuori dalla macchina. Tutto il resto può aspettare una settimana più calma; questi tre no.