Infinidat ha redatto un interessante documento, con il chiaro intento di consigliare le aziende nella gestione delle tematiche legate all’always on.
Un aiuto quanto mai utile, dato che la rivoluzione in atto sulle architetture IT viaggia a velocità davvero sostenuta. Chiaramente, non tutte le infrastrutture sono uguali: quelle utili a fidelizzare e mantenere i clienti attivi, garantendo uptime e prestazioni, devono avere priorità assoluta in azienda.
Ogni processo che richieda ore per il ripristino è inaccettabile. Per questo, il Disaster Recovery come l’abbiamo conosciuto fino a oggi è morto ed è necessario garantire un servizio Always On.
Ecco le cinque linee guida di Infinidat per adottare questo approccio:
– Eliminare la complessità IT Oggi, la maggior parte delle aziende ha la necessità di una soluzione puntuale, aggiuntiva e dedicata (HA Gateway), dotata di differenti funzionalità, strumenti di gestione e monitoraggio. Questo aggiunge complessità ai processi operativi e di automazione. È raccomandabile scegliere una soluzione integrata che combini storage e capacità Always On.
– Ridurre i costi I gateway HA non sono economici e spesso si basano sul modello “costo per capacità”. Questo obbliga le aziende a ridurre il numero di applicazioni che beneficiano dell’Always On. Un costo ulteriore emerge quando la soluzione HA necessita di connessione Fiber Channel tra i siti. Le aziende garantiscono maggiore protezione quando sono meno sovraccariche.
– Prestazioni costanti, ovunque Le operazioni sincrone tra due sistemi di storage su due siti aumentano la latenza. Questo rende più complessa l’adozione di applicazioni sensibili alla latenza, indipendentemente dal livello di criticità. Nelle implementazioni su lunga distanza, inviare una scrittura allo storage array locale ed un’altra a quello remoto raddoppierà la latenza, creando user experience non soddisfacenti. Questo spesso accade quando la configurazione è errata. Può essere facilmente corretta semplificandola e automatizzandola, per consentire agli host di differenziare i percorsi da effettuare sempre da quelli utilizzati solo in caso di errore. In questo modo si riduce l’impatto sulle performance, consentendo un’adozione più ampia.
– Funzionalità variabili Molte soluzioni che vantano capacità “Always On” hanno in realtà funzionalità molto diverse. Alcune offrono una copia di sola lettura su uno dei siti e failover automatizzato, mentre altre subiscono cali di prestazioni durante l’invio della scrittura alla copia secondaria. Trattare entrambe le copie allo stesso modo, senza penalizzazioni sulle performance, consente agli host di scrivere su entrambi i siti (copie attive reali) senza alcun processo di failover.
– Affidabilità Come ogni soluzione distribuita a livello geografico, i cluster Always On hanno bisogno di una “via d’uscita” in caso di errore di comunicazione tra i due sistemi. Perciò le aziende hanno bisogno di un arbitro (witness) posizionato in un terzo fault domain con networking ridondante per ogni sito, per supplire tramite il quorum alla mancata comunicazione tra i due siti. Il fornitore deve garantire che il witness si adatti al metodo di implementazione (cloud/on-premises) prescelto dal cliente.
