Premessa: questa "white paper" cerca appositamente di essere semplice e comprensibile e di conseguenza il meno tecnica possibile. Lo scopo e' quello di interessare chi deve prendere decisioni e seguire lo sviluppo dell'azienda e per questo motivo non vuole dedicare la sua concentrazione agli aspetti informatici troppo tecnici.
Premessa I: diamo comunque per scontato che chi legge effettui back up dei dati diligentemente, quotidianamente ovvero regolarmente e costantemente. In pratica, in questa lettera non si mettera' minimamente in dubbio la sicurezza dei vostri dati che sicuramente e' ottima. Leggendo si capira' che parliamo di cose ben piu gravi del salvataggio dati.
Premessa II: il server in diverse aziende e' un deposito di files (file server) e o un gestore di stampanti (print server): applicazioni non critiche. In altre, il server e' il perno che fa funzionare tutte le attivita' degli impiegati e la produzione stessa: questa e' cio' che definiamo applicazione critica (di server nell'ambito di un attivita').
Con riferimento alla sola seconda premessa, il concetto che sottoponiamo e sul quale invitiamo a riflettere ha il suo fulcro su come rispondereste a queste tre domande:
"Se vi si rompe/rubano/brucia il server, senza server potete lavorare/produrre?"
"Se non potete lavorare/produrre, quanto tempo potete accettare di stare col server fermo ovvero il fermo del server ovvero la produzione ferma, passati quanti minuti o ore si trasforma in un danno?"
"Quantifichiamo il danno. Cosa mi costerebbe 1 ora, mezza giornata, una giornata di fermo produzione?"
1) se si rompe il server alle 5 del pomeriggio e il back up e' "vecchio" della notte prima: "quanto tempo dovreste perdere per reinserire tutti i dati non ancora salvati dal momento dell'ultimo backup al momento della rottura?"
2) il server si rompe alle 12:00, il tecnico IBM/DELL/HP/etc arriverà almeno dopo 6 ore lavorative o più. Arriverà l'indomani, in pratica. Non solo: se il danno al server e' grave e si rendesse poi necessario reinstallare sistema operativo e gestionali?: andra' persa un altra mezza giornata (ammesso e non concesso che riusciate a coordinare un intervento con la softwarehouse che dovrebbe reinstallare il gestionale). Un vero e proprio disastro (in fatti si parla di tempi di recupero dal momento del disastro ovvero Disaster Recovery)
3) oltre al tempo perso al punto 1), quanto tempo impieghero'/perdero' per ripristinare i back up?
4) a ripristino dei back up avvenuto, ovvero quando il server sara' finalmente operativo, oltre al tempo perso ai punti 1) e 3), quanto tempo dovro' perdere per recuperare quanto "non prodotto" durante tutto questo fermo del server?
Ci sono svariate combinazioni per realizzare un sistema ad HIGH AVAILABILITY. In FAsTec ne proponiamo due che comunque implicitamente prevedono di impostare un Disaster Recovery Plan (Piano Di Recupero/Riavvio in conseguenza di un Disastro [al server])
Soluzione 1 - Molto economica e altrettanto efficace, fault tolerant
un muletto-attivo sul quale si copia, replica e aggiorna istante per istante in maniera costante, permanente e in tempo reale un vero e proprio alterego del server principale.
Con questa formula, fault tolerant, se il server "muore", "il muletto si attiva" (o, se in manuale, "si attiva il muletto") e si sara' ISTANTANEAMENTE OPERATIVI, poiche' in poche decine di secondi "nel muletto risorgera' il server defunto".
ATTENZIONE: con alterego del server principale, intendiamo esattamente che TUTTO, sistema operativo, nome del dominio, nome del server, indirizzo / indirizzi IP, programmi, dati e database viene costantemente e in tempo reale replicato/duplicato ovvero salvato, sul muletto.
NOTA BENE: una variante di questa soluzione, replica in buona parte quanto "erogato" dalla soluzione 2, evitando pero' l'acquisto di hardware costo o molto costoso.
Soluzione 2 - Piu sofisticata: load balanced (high availability incrociato)
e' un sistema che introduce nel sistema aziendale un secondo server vero e proprio e facilmente anche altre apparecchiature.
PREMESSA: Cos'è il carico di lavoro? Si supponga che in un azienda, invece di un solo server windows, ce ne siano 2 e magari ve ne sono pure 1 Apple e 1 Linux. A parte il risparmio energetico che si realizza consolidandoli in soli 2 computer, è ovvio che, una volta in funzione, "peseranno" sui processori delle macchine che li ospitano.
In questo sistema, i due server (presumibilmente gemelli) lavorano in simbiosi e contengono 2 dei suddetti server ciscuno, memorizzando i dati su un sistema di dischi (condiviso tra i due computer fisici).
Si chiama load balanced, poiche' il carico di lavoro (load) viene bilanciato (balanced) e quindi ripartito tra le due macchine, raddoppiando il potenziale di erogazione, si, ma al contempo avendo una doppia disponibilita' di server. Questa formula implica soluzioni tecnologiche piu articolate ed evolute ovvio sinonimo di costi piu elevati. La versione non incrociata, semplice high availability è una evoluzione della soluzione 1 dove il passaggio dal server morto a quello di emergenza avviene 1. in automatico e in autonomia (anche se succedesse di notte quindi) e 2."live", cioè senza interruzione di servizi.
Con la formula load balanced, se uno dei due server muore, si viene semplicemente avvisati della triste dipartita dell'altro e nulla piu': the show must go on. Nulla si interrompe, il lavoro degli impiegati e la produzione continuano senza un sussulto e nulla va perso.
Tutto il carico di lavoro che si sobbarcava il defunto passera' istantaneamente al sopravvissuto senza interruzione alcuna dei servizi e senza nessuna perdita di dati (ovviamente).Oltre al salvataggio quotidiano su DAT o NAS, disporrete cosi' di una seconda e migliore copia poiche' "aggiornata all'ultimo secondo". In quanto evidenti, non discutiamo i vantaggi di una copia istantanea e reale del server su un suo gemello vero e proprio, suggeriamo invece di valutare i vantaggi derivanti dal fatto che il secondo computer/server puo' essere piazzato in una locazione anche diversa (in quanto e' con cavi rete che sta collegato al server principale).
Questo sistema NON sostituisce NTBackup per windows 2008 o 2003 che quindi dovrà comunque essere usato.
Anzi, una azienda che ha una gestione accorta dei backup del server, prevede di fare e di avere il backup a rotazione, ovvero una copia di backup diversa, su diverso supporto, per ogniuno dei 5 giorni lavorativi della settimana e poi, possibilmente ruotare anche una copia settimanale e una mensile.
Perche' un backup a rotazione? Ovvio: perche' se per sbaglio qualcuno cancella un file importante e se ne accorge solo dopo qualche giorno, solo un backup a rotazione ne rendera' disponibile una copia da cui reperirlo e anche poiche', se si e' afferrato il concetto di "copia speculare in tempo reale" di un server sull'altro... si capira' che se si cancella un file sul primo server, istantanemaente questo verra' cancellato anche sul secondo.
Sara' curioso sapere che la demo di una delle soluzioni, prevede di strappare brutalmente le spine della 220V del server pricipale. Detto questo, vediamo i tempi in cui si tornera' operativi.
- fault tolerant: in caso di morte del server, in poche decine di secondi si e' di nuovo operativi come se nulla fosse successo (in caso di sistema automatico), oppure in meno di 5 minuti (in caso di sistema manuale). Sara' l'analisi preliminare del sistema col quale lavora il cliente (tipologie di database, servizi, applicazioni etc etc) che promuovera' la scelta del manuale o dell'automatico.
- high availability e o load balancing: non vi e' alcuna interruzione di servizi e nessuna perdita di dati
Per realizzare questi meccanismi vi sono combinazioni che mescolano in varie salse e in varie maniere prodotti commerciali di varie case software con costi di licenze astronomici che prevedono implicitamente l'uso di hardware dedicato molto costoso per gestire storage esterni molto costosi... oppure c'e' FAsTec... che invece ha architettato e ingegnerizzato un sistema dove i costi delle licenze sono 0 (zero)!!! seppur usando prodotti blasonati ma nella formula GPL (appunto a costo zero)
FAsTec fornisce preferibilmente server IBM. Sono disponibili server IBM tower e server IBM rack 19"
Per un approfondimento su quanto esposto, si puo' visionare questa pagina del nostro sito