Concetti relativi a disponibilità, affidabilità e scalabilità

Ultima modifica dell'argomento: 2005-05-20

Sebbene in questa guida venga principalmente descritto come ottenere un determinato livello di disponibilità, è importante comprendere anche perché l'affidabilità e la scalabilità siano fattori chiave nella pianificazione e nell'implementazione di un sistema di messaggistica di Exchange 2003 altamente disponibile.

Definizione di disponibilità

Nella comunità IT la metrica utilizzata per misurare la disponibilità è rappresentata dalla percentuale di tempo durante la quale un sistema è in grado di eseguire la funzione designata. Poiché si riferisce ai sistemi di messaggistica, la disponibilità rappresenta la percentuale di tempo durante la quale il servizio di messaggistica è attivo e in esecuzione. I livelli di disponibilità vengono calcolati con la formula seguente:

Percentage of availability = (total elapsed time - sum of downtime)/total elapsed time

La disponibilità viene di norma misurata in "nove". Ad esempio, una soluzione con un livello di disponibilità di "tre nove" è in grado di supportare la propria funzione per il 99,9% del tempo, ovvero l'equivalente di un tempo di inattività annuale di 8,76 ore all'anno su una base di 24x7x365 (24 ore al giorno/sette giorni a settimana/365 giorni l'anno). Nella tabella seguente sono elencati i livelli di disponibilità comuni che molte organizzazioni tentano di raggiungere.

Percentuali di disponibilità e tempi di inattività annuali

Purtroppo, la misurazione della disponibilità non è semplice come la selezione di una delle percentuali di disponibilità mostrate nella tabella precedente. È, innanzitutto, necessario scegliere la metrica da utilizzare per precisare i tempi di inattività. Un'organizzazione, ad esempio, potrebbe considerare come tempo di inattività il periodo durante il quale un database non è installato. Un'altra organizzazione, invece, potrebbe considerare come tempo di inattività soltanto il caso in cui un'interruzione riguarda un numero superiore alla metà dei propri utenti.

Inoltre, i requisiti di disponibilità devono essere determinati nel contesto del servizio e dell'organizzazione da cui il servizio è stato utilizzato. Ad esempio, i requisiti di disponibilità per i server che ospitano dati di cartelle pubbliche non critiche possono essere impostati su un valore più basso rispetto ai server che contengono database delle cassette postali di fondamentale importanza.

Per informazioni sulla metrica da utilizzare per la misurazione della disponibilità e per informazioni sulla determinazione di requisiti di disponibilità basati sul contesto del servizio e dei requisiti dell'organizzazione, vedere Definizione degli obiettivi di disponibilità.

Definizione di affidabilità

L'affidabilità viene generalmente utilizzata per calcolare la probabilità di errore per un singolo componente della soluzione. Una misura utilizzata per definire l'affidabilità di un componente o di un sistema è rappresentata dal tempo che intercorre tra un errore e l'altro (MTBF). L'MTBF rappresenta l'intervallo di tempo medio, di norma espresso in migliaia o decine di migliaia di ore (a volte denominate ore di alimentazione attiva o POH), trascorso fino al verificarsi di un errore e alla richiesta di assistenza. L'MTBF viene calcolato utilizzando l'equazione seguente:

MTBF = (total elapsed time - sum of downtime)/number of failures

Una misurazione correlata è data dal tempo medio necessario per la riparazione (MTTR). L'MTTR è l'intervallo di tempo medio (di norma espresso in ore) necessario alla riparazione di un componente guasto. L'affidabilità di tutti i componenti della soluzione, ad esempio, dell'hardware del server, del sistema operativo, del software dell'applicazione e della rete, può influire sulla disponibilità della soluzione.

Un sistema è più affidabile se è a tolleranza di errore. Per tolleranza di errore si intende la capacità di un sistema di continuare a funzionare nel caso in cui si verifichi un errore. La tolleranza di errore si ottiene progettando il sistema con un alto grado di ridondanza hardware. Se si verifica un errore in un singolo componente, questo viene sostituito dal componente ridondante senza che si verifichino tempi di inattività notevoli. Per ulteriori informazioni sui componenti a tolleranza di errore, vedere Implementazione della tolleranza di errore nell'organizzazione di Exchange 2003.

Definizione di scalabilità

Nelle distribuzioni di Exchange la scalabilità rappresenta la misura relativa alla capacità di un servizio o di un'applicazione di adattarsi alle crescenti richieste a livello di prestazioni. Se riferita al cluster di Exchange, la scalabilità rappresenta la possibilità di aggiungere computer in modo incrementale a un cluster esistente quando il carico complessivo del cluster supera la capacità del cluster stesso di offrire prestazioni adeguate. Per soddisfare le crescenti richieste a livello di prestazioni relative all'infrastruttura di messaggistica, è possibile implementare due strategie di scalabilità: scalabilità in verticale o in orizzontale.

Scalabilità in verticale

La scalabilità in verticale include maggiori risorse di sistema (come processori, memoria, dischi e adattatori di rete) per l'hardware esistente o per la sostituzione di tale hardware con risorse di sistema superiori. La scalabilità in verticale è appropriata quando si desidera migliorare il tempo di risposta del client, come per la configurazione del bilanciamento del carico di rete (NLB, Network Load Balancing) di un server front-end di Exchange. Se, ad esempio, l'hardware corrente non offre prestazioni adeguate, è possibile aggiungere RAM o CPU ai server nel cluster NLB.

Windows Server 2003 supporta CPU singole o multiple conformi allo standard SMP. Utilizzando lo standard SMP, il sistema operativo può eseguire thread su qualsiasi processore disponibile, consentendo alle applicazioni di utilizzare più processori quando si richiede una maggiore potenza di elaborazione per migliorare le funzionalità del sistema.

Scalabilità in orizzontale

La scalabilità in orizzontale implica invece l'aggiunta di server per soddisfare ogni esigenza. Pertanto, nel cluster del server back-end, ciò implica l'aggiunta di nodi al cluster. Mentre nello scenario NBL front-end, implica l'aggiunta di computer al gruppo di server dei protocolli front-end di Exchange 2003. La scalabilità orizzontale è, inoltre, appropriata quando si desidera migliorare il tempo di risposta del client con i server.

Per informazioni sulla scalabilità in merito a soluzioni cluster del server, vedere "Considerazioni sulle prestazioni e la scalabilità" in Considerazioni sulla pianificazione del clustering.

Per informazioni dettagliate su come scegliere l'hardware e regolare le prestazioni e la scalabilità di Exchange 2003, vedere Exchange Server 2003 Performance and Scalability Guide.