Previsione della larghezza di banda per i client di Exchange - Problema del fuso orario

Articolo originale pubblicato mercoledì 20 giugno 2012

Aggiornamento 22/06/12 - Questo articolo e il download a esso associato sono stati aggiornati.

Nell'ultima versione di Exchange Client Network Bandwidth Calculator sono inclusi diversi aggiornamenti, ma probabilmente il più significativo di tutti è il supporto del fuso orario. Ho cercato di risolvere il problema del fuso orario nel corso degli ultimi 12 mesi circa e c'è voluto del tempo per trovare una soluzione pratica. Ma sto correndo troppo. Cerchiamo perciò di capire innanzitutto cosa sia realmente il problema del fuso orario.

In cosa consiste il problema del fuso orario

Per questa spiegazione parto dal presupposto che tutti sappiano cosa sono i fusi orari e perché vengano utilizzati. Per chi desidera approfondire comunque l'argomento, consiglio di leggere l'articolo seguente di Wikipedia:

https://en.wikipedia.org/wiki/Time_zone

Il problema del fuso orario dal punto di vista della previsione della larghezza di banda di rete è rappresentato dal fatto che possiamo tentare di definire carichi di lavoro per utenti che condividono la stessa connessione di rete o lo stesso servizio finale, ma che si trovano in parti diverse del mondo. Questo ci crea un problema perché i periodi di maggior utilizzo per la maggior parte degli utenti sono collegati al fuso orario locale.

Se ad esempio consideriamo una normale giornata di lavoro per un'organizzazione con una media di 1000 utenti, i periodi di picco in genere sono due: uno al mattino che inizia intorno alle 10.00 e dura due ore e un picco successivo nel pomeriggio intorno alle 14.00 che dura quattro ore. Quando tracciamo un grafico di tale situazione, il risultato è simile al seguente:

Immaginiamo ora di dover impostare i requisiti per cinque diverse località del mondo, ognuna delle quali supporta 1000 utenti che accedono a una risorsa condivisa che si trova a New York. In questa fase supponiamo che la risorsa condivisa sia un dispositivo di bilanciamento del carico rivolto verso Exchange 2010 in locale (pensavo che avrei scelto un esempio relativo alla situazione locale tanto per cambiare).

• Londra (GMT) = 1000 utenti
• Varsavia (GMT+1) = 1000 utenti
• Giacarta (GMT+7) = 1000 utenti
• Redmond (GMT-8) = 1000 utenti
• New York (GMT-5) = 1000 utenti

Se impostiamo i requisiti utilizzando la nostra tecnica legacy basata sulla previsione del picco per ogni set di utenti e sulla relativa somma, otteniamo quanto segue:

Questo grafico mostra che per ogni sito di 1000 utenti sono stati necessari approssimativamente 1,56 Mbit/sec di larghezza di banda nel periodo di picco ogni giorno, pertanto se li sommiamo tutti per rappresentare tutti gli utenti che condividono il dispositivo di bilanciamento del carico a New York, otteniamo un requisito di picco pari a 7,81 Mbit/sec. Questo è il modo in cui finora abbiamo effettuato la pianificazione della larghezza di banda per gli utenti distribuiti, abbiamo previsto i relativi requisiti di picco, li abbiamo inseriti in una tabella e li abbiamo sommati.

Il problema in questo caso è dato dal fatto che gli utenti in Europa stanno rientrando a casa dal lavoro quando gli utenti di Redmond si stanno appena svegliando e quelli a Giacarta sono già a dormire!

Se consideriamo il fuso orario di questi siti, il grafico cambia in modo significativo:

Questo grafico mostra come i carichi di lavoro si combinano per delineare un profilo di utilizzo molto diverso da quello per cui avremmo in passato effettuato la pianificazione. L'aspetto veramente interessante è il fatto che il carico di lavoro di picco ora è molto più basso, ovvero pari a solo 3,78 Mbit/sec (a fronte di una previsione originaria di 7,81 Mbit/sec). Anche il profilo di utilizzo è molto diverso rispetto alla previsione iniziale.

Come è possibile risolvere questo problema?

Come avrete immaginato dai grafici, abbiamo esteso il calcolatore della larghezza di banda di rete in modo da includere i dettagli relativi al fuso orario!

A tale scopo, abbiamo abbandonato l'idea di prevedere solo il carico di lavoro di picco e ora prevediamo l'utilizzo della larghezza di banda per ora del giorno in base ai modelli di utilizzo forniti, ad esempio quando si verifica il periodo di picco del mattino, quello del pomeriggio e così via. Questo consente al calcolatore di sapere quando si avrà il picco di utilizzo, ma anche quale sarà l'entità dell'utilizzo per il resto della giornata. Dopo avere determinato tale curva, è possibile sommare i dati tenendo conto dei fusi orari.

C'è veramente qualcuno che esegue questo consolidamento?

Beh, la risposta più semplice è sì. Molte organizzazioni stanno consolidando il più possibile i carichi di lavoro. Questo richiede che i team di progettazione pianifichino i carichi di lavoro di servizio di utenti molto distribuiti, spesso con profili diversi e in fusi orari diversi. Tale situazione è comune soprattutto dove il carico di lavoro viene spostato nel cloud, in quanto Office 365 offre singole posizioni di tenant per area geografica, pertanto un'organizzazione di portata internazionale che utilizza Office 365 dovrà effettuare la pianificazione per una larga parte di utenti che accedono al servizio in un'area e un fuso orario completamente diversi, spesso tramite un'infrastruttura condivisa.

Molti clienti con cui lavoro stanno inoltre consolidando diversi data center di piccole dimensioni in un numero inferiore di data center di dimensioni maggiori. Tali siti consolidati devono essere in grado di gestire il carico di lavoro degli utenti precedentemente distribuiti. Questi utenti sovente avranno fusi orari diversi, pertanto dobbiamo tentare di gestire il loro carico di lavoro trovando un modo per capire come si combinerà con altri carichi di lavoro distribuiti.

Se tutti gli utenti si trovano nello stesso fuso orario, ovviamente non è necessario preoccuparsi di tutto questo ed è possibile utilizzare il calcolatore normalmente.

Utilizzo della nuova funzionalità per il fuso orario

Partendo dal presupposto che lo scenario richiede il supporto del fuso orario, come è possibile utilizzare la nuova funzionalità?

Procedendo con ordine, è necessario innanzitutto configurare la tabella TimeZone Configuration nel foglio di input. I parametri immessi determinano la forma della curva di utilizzo applicata per combinare i carichi di lavoro. I valori devono riflettere i modelli di utilizzo medi all'interno dell'organizzazione. A tale scopo, in genere esamino i dati sulle prestazioni relativi all'esecuzione dei server di Exchange e chiedo al cliente come pensa che lavorino i suoi utenti e quali siano i relativi periodi di picco.

Dopo avere completato il foglio di input, è possibile passare al foglio Client Mix, in cui sono disponibili due nuove aree per configurare i dati relativi al fuso orario.

In primo luogo vi è Timezone Model, che rappresenta il fuso orario della risorsa per cui viene effettuata la pianificazione, ovvero il collegamento di rete o il dispositivo di bilanciamento del carico. Nell'esempio precedente è possibile vedere che il fuso orario modello è stato impostato su GMT-5 per New York, che è la città in cui si trova il dispositivo di bilanciamento del carico.

In secondo luogo vi è una nuova colonna, denominata TimeZone, che rappresenta il fuso orario di ogni singolo sito rispetto all'ora di Greenwich (GMT). Notare che io sono inglese e che ho utilizzato questo orario di riferimento, ma posso passare all'ora UTC, se un numero sufficiente di persone lo richiede.

La previsione risultante viene visualizzata in un grafico al di sotto della tabella Client Mix, come mostrato in precedenza. I valori di questa tabella sono in Mbit/sec e rappresentano l'utilizzo di rete previsto in ogni ora del giorno.

Un ulteriore vantaggio

Uno degli altri vantaggi è rappresentato dal fatto che il calcolatore fornirà una tabella che può essere copiata nel Mailbox Role Calculator e utilizzata per la previsione della replica di rete DAG.

Esaminando la parte destra del grafico di previsione (foglio Client Mix) del Network Bandwidth Calculator, si noterà una tabella contenente la percentuale di variazione per ora del giorno… Copiando tali dati negli Appunti…

E scorrendo verso il basso il foglio di input del Mailbox Server Role Calculator, è possibile trovare una tabella relativa alla configurazione della replica dei registri (Log Replication Configuration). Incollare in tale tabella le cifre del Network Bandwidth Calculator.

In questo modo il Mailbox Server Role Calculator è ora in grado di prevedere i requisiti di larghezza di banda per la replica DAG considerando sia i dati dell'organizzazione sia la configurazione del fuso orario!

Conclusione

Spero che questa nuova funzionalità sia utile a molti per prevedere in modo più accurato i requisiti di larghezza di banda di rete. Non è necessaria per tutte le distribuzioni, ma mi auguro che faciliti il lavoro degli architetti di aziende di grandi dimensioni che devono affrontare questo problema.

Continuate a inviarci il vostro prezioso feedback, che sia positivo o negativo, all'indirizzo netcalc@microsoft. Ci fa piacere leggere i vostri commenti!

Neil Johnson
Senior Consultant, MCS UK

Questo è un post di blog localizzato. L'articolo originale è disponibile in Exchange Client Bandwidth Prediction – the time zone problem….