Sfruttare al meglio la propria Inverted Pyramid of Doom

L'architettura 3-2-1 o Inverted Pyramid of Doom è diventata un paria del settore IT per molte ragioni. Purtroppo per molte aziende, scoprono i pericoli associati a questo design solo dopo che i componenti sono arrivati e il denaro ha lasciato i conti.

Alcune aziende sono fortunate e individuano questo errore abbastanza presto da poter restituire gli acquisti e ricominciare con una fase di progettazione e decisione adeguata prima dell'acquisizione di nuovo hardware e software. Questa, tuttavia, è una situazione ideale e molto rara. Nel migliore dei casi possiamo normalmente aspettarci costi di restituzione e, molto più comunemente, le apparecchiature non possono essere restituite affatto oppure i costi sono così elevati da rendere l'operazione inutile.

Ciò che la maggior parte delle aziende si trova ad affrontare è la necessità di «sfruttare al meglio» la situazione andando avanti. Una delle preoccupazioni maggiori è che le parti coinvolte, che si tratti degli stakeholder finanziari che hanno appena speso molto denaro per il nuovo hardware o degli stakeholder tecnici che ora fanno una brutta figura per aver permesso l'acquisto di queste apparecchiature, cedano a una reazione emotiva che porta ad assecondare la fallacia dei costi sommersi. È fondamentale che a questa reazione emotiva e illogica non venga permesso di prendere piede, poiché minerebbe i processi decisionali critici.

Bisogna comprendere che il denaro speso per l'inverted pyramid of doom è già stato speso ed è perduto. Che il denaro sia stato sprecato o quanto ne sia stato sprecato è irrilevante per il processo decisionale a questo punto. Se il sistema è stato un regalo o se è costato un miliardo di dollari non importa, quel denaro è perduto e ora dobbiamo arrangiarci con ciò che abbiamo. Un potenziale «trucco» in questo caso sarebbe coinvolgere un decisore finanziario come un CFO, spiegare che sta per verificarsi una reazione emotiva legata a denaro già speso e discutere della fallacia dei costi sommersi prima di parlare del problema concreto, in modo che le persone siano consapevoli e razionali e che la persona formata (si spera) per gestire al meglio questo tipo di situazione sia presente e pronta a prevenire le emozioni legate ai costi sommersi. È importante gestire con attenzione una reazione potenzialmente alimentata dalle emozioni. Questo non è il momento di tentare di nascondere i passi falsi finanziari o tecnici, che è proprio ciò che la reazione emotiva sta generando. È necessario che tutte le parti comunichino e rimangano distaccate e razionali per affrontare le esigenze. Alcune aziende gestiscono bene questa fase, molte non ci riescono e finiscono intrappolate nel tentativo di andare avanti con decisioni sbagliate già prese, probabilmente nella speranza che non accada nulla di male e che nessuno se ne ricordi o se ne accorga. Combattete questa reazione. Tutti la provano, è la naturale risposta emotiva «attacco o fuga» dell'amigdala.

Ora che siamo pronti a combattere le reazioni emotive al problema possiamo iniziare ad affrontare la questione «da dove proseguiamo». La buona notizia è che la posizione in cui ci troviamo è generalmente quella di avere «troppo» piuttosto che «troppo poco». Quindi abbiamo l'opportunità di essere un po' creativi. Fortunatamente esistono generalmente buone opzioni che possono permetterci di muoverci in diverse direzioni.

Una cosa molto importante da notare è che stiamo considerando esclusivamente soluzioni più affidabili, non meno affidabili, dell'architettura inverted pyramid of doom prevista che stiamo sostituendo. Una IPOD è un design molto fragile e pericoloso e potremmo dilungarci a lungo dimostrando concetti come l'analisi del rischio, i single point of failure, le fallacie della falsa ridondanza, l'attenzione alla ridondanza anziché all'affidabilità, le catene di dipendenze, ecc., ma ciò che è assolutamente fondamentale che tutte le parti comprendano è che un singolo server, in esecuzione con storage locale, è più affidabile di quanto sarebbe l'intera infrastruttura IPOD. Questo è così importante che va ribadito: se un singolo server ha «disponibilità standard», la IPOD è al di sotto di tale livello. Più rischiosa. Se a questo punto qualcuno teme una «mancanza di ridondanza» o una «mancanza di complessità» nelle soluzioni risultanti, dobbiamo tornare a questo punto: nulla di ciò di cui parleremo è rischioso quanto ciò che era già stato progettato e acquistato. Se vi è qualche timore di rischio andando avanti, tale timore avrebbe dovuto essere maggiore prima di migliorare l'affidabilità del design. Questo non si può sottolineare abbastanza. Le IPOD si vendono perché confondono facilmente chi non è formato nell'analisi del rischio e sembrano affidabili quando, in realtà, sono tutt'altro.

Comprendendo quanto sopra e utilizzando una tecnica chiamata «rilettura» dell'architettura IPOD accettata, ci rendiamo conto che l'azienda in questione accettava di non avere alta disponibilità (e nemmeno disponibilità standard) al momento dell'acquisto della IPOD. Forse credeva di ottenerla, ma l'architettura non era in grado di fornirla e quindi, andando avanti, abbiamo l'opzione di «arrangiarci» con nient'altro che un singolo server, in esecuzione sul proprio storage locale. Questo è semplice e facile e migliora quasi ogni aspetto del design IPOD previsto. Costa meno gestirlo e mantenerlo, è spesso più veloce ed è molto meno complesso pur essendo leggermente più affidabile.

Ma probabilmente limitarsi semplicemente a ridurre tutto a un singolo server e sperare di trovare usi per il resto delle apparecchiature acquistate «altrove» non sarà la nostra opzione migliore. Nelle situazioni in cui la IPOD era destinata a essere utilizzata solo per un singolo carico di lavoro o insieme di carichi di lavoro e anche altre aree dell'azienda hanno bisogno di apparecchiature, può essere molto vantaggioso adottare l'approccio del «singolo server» per il carico di lavoro IPOD previsto e utilizzare le apparecchiature rimanenti altrove nell'azienda.

L'approccio più comune da adottare per il riutilizzo di uno stack IPOD consiste nel riconfigurare i due (o più) nodi di calcolo affinché diventino nodi full stack contenenti il proprio storage. Questo passaggio potrebbe non richiedere alcun acquisto, a seconda dello storage già acquistato, uno spostamento di dischi tra i sistemi oppure spesso l'acquisto relativamente modesto di dischi rigidi aggiuntivi a questo scopo.

Questi nodi possono poi essere configurati secondo uno di due modelli di alta disponibilità. In passato una scelta progettuale comune, per ragioni di costo, era utilizzare un modello di replica asincrona (spesso noto come l'approccio Veeam) che replica le macchine virtuali tra i nodi e consente di avviare le VM molto rapidamente, permettendo un tempo di inattività, dal momento del guasto del nodo di calcolo fino al ripristino, di appena pochi minuti.

Oggi la fault tolerance completamente sincrona è disponibile così comunemente e gratuitamente da aver di fatto sostituito il modello asincrono in quasi tutti i casi. In questo modello lo storage viene replicato in tempo completamente reale tra i nodi di calcolo, consentendo al failover di avvenire istantaneamente, anziché con un ritardo di pochi minuti, e con zero perdita di dati anziché con una piccola finestra di perdita di dati (ad esempio un RPO pari a zero).

A questo punto sembra essere comune che le persone reagiscano alla replica con il timore di una perdita di capacità di storage causata dalla replica stessa. Naturalmente questo è vero. È necessario comprendere che è proprio questa replica, assente dal design IPOD originale, a fornire la solida base per un'elevata affidabilità. Se questa replica viene saltata, l'alta disponibilità è un sogno irraggiungibile e i singoli nodi di calcolo che utilizzano storage locale in modalità «stand alone» rappresentano l'opzione potenziale più affidabile. Le soluzioni ad alta disponibilità si basano sulla replica e sulla ridondanza per costruire l'affidabilità necessaria a qualificarsi per l'alta disponibilità.

Questo risolve la questione di cosa fare con i nostri nodi di calcolo ma ci lascia con il problema di cosa possiamo fare con il nostro dispositivo di storage condiviso esterno, il single point of failure ovvero il «vertice» del design a piramide invertita. Per rispondere a questa domanda dovremmo iniziare a esaminare cosa potrebbe essere questo storage.

Esistono tre tipi comuni di dispositivi di storage che verrebbero utilizzati in un design a piramide invertita: DAS, SAN e NAS. Possiamo accorpare DAS e SAN poiché sono entrambi due aspetti diversi dello storage a blocchi e possono essere utilizzati essenzialmente in modo intercambiabile nella nostra discussione: si distinguono solo per la presenza dello switching, che può essere aggiunto o rimosso secondo necessità nei nostri design. Il NAS si differenzia in quanto è storage a file anziché storage a blocchi.

In entrambi i casi, storage a blocchi (DAS o SAN) o a file (NAS), uno degli usi più comuni per questo dispositivo ormai superfluo è come destinazione di backup per la nostra nuova infrastruttura di virtualizzazione. In molti casi il dispositivo può essere sovradimensionato per questo compito, generalmente con più prestazioni e molte più funzionalità di quante ne servano per una semplice destinazione di backup, ma un buon storage di backup è importante per qualsiasi infrastruttura aziendale critica ed eccedere nel sovradimensionamento non è necessariamente una cosa negativa. Le aziende spesso cercano di lesinare sulle proprie infrastrutture di backup e questa è un'opportunità per investirvi pesantemente senza spendere denaro aggiuntivo.

Sulla stessa linea dello storage di backup, il dispositivo di storage esterno potrebbe essere riutilizzato come storage di archiviazione o come altro «livello inferiore» di storage in cui l'alta disponibilità non è giustificata. Questo è un approccio meno comune, generalmente perché ogni azienda ha bisogno di un buon sistema di backup ma solo alcune dispongono di un modo per sfruttare un livello di storage di archiviazione.

Oltre a questi due modelli di storage comuni e universali, un caso d'uso comune per i dispositivi di storage esterni, soprattutto se il dispositivo è un NAS, è sfruttarlo nel suo ruolo nativo come file server separato dall'infrastruttura di virtualizzazione. Per molte aziende il file serving non è critico in termini di uptime quanto l'infrastruttura di virtualizzazione centrale e i backup sono molto più facili da mantenere e gestire. Trasferendo il file serving su un dispositivo NAS già acquistato è possibile ridurre i requisiti di file serving dell'infrastruttura di virtualizzazione, sia diminuendo il numero di VM che devono essere eseguite su di essa, sia spostando quello che è tipicamente uno dei maggiori utilizzatori di storage su un dispositivo separato, il che può abbassare i requisiti di prestazioni dell'infrastruttura di virtualizzazione oltre ai suoi requisiti di capacità. Così facendo riduciamo potenzialmente il costo necessario per l'acquisto di dischi rigidi aggiuntivi per lo storage locale sui nodi di calcolo, come abbiamo affermato in precedenza, e quindi questo può essere un metodo molto apprezzato da molte aziende per soddisfare le esigenze di riutilizzo.

Ogni azienda è unica e vi sono potenzialmente molti ambiti in cui le apparecchiature di storage in eccesso potrebbero essere utilizzate efficacemente, dai laboratori agli archivi allo storage a livelli. Usando un po' di creatività e pensando fuori dagli schemi è possibile sfruttare il proprio insieme unico di apparecchiature disponibili e l'insieme unico di esigenze e richieste della propria azienda per trovare il posto migliore in cui utilizzare queste apparecchiature, là dove sono disaccoppiate dall'infrastruttura di virtualizzazione centrale e critica ma possono comunque apportare valore all'organizzazione. Evitando l'inverted pyramid of doom possiamo ottenere il massimo valore dalle apparecchiature in cui abbiamo già investito, anziché implementare nuovo debito tecnico che dovremo poi faticare a superare inutilmente.