Vorhersage der Bandbreitenanforderungen für Exchange Client – das Problem mit der Zeitzone ...

Veröffentlichung des Originalartikels: 20.06.2012

Update 22.06.2012 – Dieser Artikel und der zugehörige Download sind aktualisiert worden.

Das neueste Release des Exchange Client Network Bandwidth Calculator enthält mehrere Updates, von denen wohl die Zeitzonenunterstützung das wichtigste ist. Ich habe mich ungefähr die letzten zwölf Monate mit dem Zeitzonenproblem beschäftigt, und es hat eine Weile gedauert, bis ich eine praktikable Lösung gefunden habe. Aber eins nach dem anderen – schauen wir uns erst einmal an, worum es bei dem Zeitzonenproblem eigentlich geht.

Was ist das Zeitzonenproblem?

Ich gehe davon aus, dass jeder weiß, was Zeitzonen sind und wozu es sie gibt. Wer aber mehr darüber lesen will, dem empfehle ich den folgenden Wikipedia-Artikel:

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

Das eigentliche Problem bei Zeitzonen besteht in Bezug auf die Vorhersage der erforderlichen Netzwerkbandbreite darin, dass wir versuchen, Arbeitsauslastungen von Benutzern in den unterschiedlichsten Teilen der Welt zu modellieren, die entweder die gleiche Netzwerkverbindung oder den gleichen Enddienst verwenden. Daraus ergibt sich ein Problem, weil die Spitzenauslastungszeiten für die meisten Benutzer relativ zu ihrer lokalen Zeitzone liegen.

Wenn wir beispielsweise einen normalen Werktag für eine durchschnittliche Organisation mit 1.000 Benutzern betrachten, sehen wir zwei typische Spitzen: eine vormittags etwa um 10 Uhr, die zwei Stunden dauert, in eine spätere am Nachmittag ca. um 14 Uhr, die etwa vier Stunden dauert. In der grafischen Darstellung sieht das so aus:

Stellen wir uns vor, wir modellieren die Anforderungen für 5 verschiedene Standorte auf der ganzen Welt, jeweils mit 1.000 Benutzern, die auf eine freigegebene Ressource in New York zugreifen. Nehmen wir an diesem Punkt an, dass die freigegebene Ressource ein Lastenausgleichsmodul mit lokal installiertem Exchange 2010 als Front-End ist (ich dachte mir, ich nehme zur Abwechslung mal ein Beispiel mit lokaler Umgebung, J).

• London (GMT) = 1.000 Benutzer
• Warschau (GMT+1) = 1.000 Benutzer
• Jakarta (GMT+7) = 1.000 Benutzer
• Redmond (GMT-8) = 1.000 Benutzer
• New York (GMT-5) = 1.000 Benutzer

Wenn wir dies mit unserer bisherigen Methode zur Vorhersage der Spitzenauslastung für jede Benutzergruppe modellieren und dann addieren, erhalten wir folgendes Ergebnis:

Dieses Diagramm zeigt, dass jeder Standort mit 1.000 Benutzern in den täglichen Spitzenzeiten eine Bandbreite von rund 1,56 Mbits/s braucht, und wenn wir alles addieren, damit alle Benutzer berücksichtigt sind, die das Lastenausgleichsmodul in New York nutzen, erhalten wir eine Spitzenanforderung von 7,81 Mbits/s. So haben wir früher die Bandbreiten für verteilte Benutzer geplant – die Spitzenanforderungen vorhersagen und dann alle in eine Tabelle packen und addieren.

Das Problem dabei: Die Benutzer in Europa haben Feierabend, wenn die Benutzer in Redmond gerade erst aus den Federn steigen und die Benutzer in Jakarta kaum erst in den Tiefschlaf gefallen sind!

Wenn wir die Zeitzonen dieser Standorte berücksichtigen, verändert sich das Diagramm wesentlich:

Wie dieses Diagramm zeigt, ergibt die Zusammenfassung der Arbeitsauslastungen dann tatsächlich ein ganz anderes Verwendungsprofil, als das, was wir traditionell geplant hätten. Besonders interessant ist hierbei, dass unsere Spitzenauslastung jetzt bei nur 3,78 Mbits/s liegt und damit wesentlich niedriger ist (unsere ursprüngliche Vorhersage lautete 7,81 Mbits/s). Das Verwendungsprofil weicht auch erheblich von unserer ursprünglichen Vorhersage ab.

Wie können wir mit diesem Problem umgehen?

Nun, wie Sie bei den obigen Diagrammen vielleicht schon geahnt haben, haben wir den Netzwerkrechner mit einer Funktion zur Einbeziehung von Zeitzonendetails erweitert.

Was wir dazu im Grunde tun mussten, war Folgendes: Wir mussten die Idee aufgeben, nur die Spitzenarbeitsauslastung vorherzusagen. Stattdessen sagen wir jetzt die Bandbreitennutzung pro Stunde des Tages basierend auf den bereitgestellten Verwendungsmustern vorher, z. B. wann ist die Spitzenauslastung während des Vormittags, am Nachmittag usw. Dadurch "weiß" der Rechner nicht nur, wann Ihre Spitzenauslastung ist, sondern auch, wie die Auslastung während des restlichen Tages sein wird. Sobald wir wissen, wie diese Kurve aussehen wird, können wir die Daten unter Berücksichtigung von Zeitzonen addieren.

Gibt es irgendjemanden, der diese Konsolidierung durchführt?

Die einfache Antwort: ja. Viele Organisationen konsolidieren Arbeitsauslastungen so weit wie möglich. Dazu müssen Entwicklerteams Dienstauslastungen von geografisch weit verteilten Benutzern berechnen, oft mit unterschiedlichen Profilen und in unterschiedlichen Zeitzonen. Das ist besonders dort üblich, wo die Arbeitsauslastung in die Cloud verlagert wird, denn Office 365 stellt nur einzelne Standorte mit regionalen Mandanten bereit. Das bedeutet, dass eine globale Organisation, die Office 365 verwendet, ihre Planung darauf aufbauen muss, dass ein großer Teil ihrer Benutzer von völlig unterschiedlichen Regionen und Zeitzonen aus auf den Dienst zugreift, häufig über freigegebene Infrastruktur.

Zahlreiche Kunden, mit denen ich zusammenarbeite, konsolidieren zudem viele kleinere Rechenzentren zu wenigen größeren Rechenzentren – diese konsolidierten Standorte müssen dann die Arbeitauslastung von zuvor verteilten Benutzern verarbeiten können. Sehr oft befinden sich diese Benutzer in verschiedenen Zeitzonen, deshalb müssen wir bei der Einbeziehung ihrer Arbeitsauslastungen herausfinden, wie wir diese mit anderen verteilten Arbeitsauslastungen zusammenfassen können.

Wenn Ihre Benutzer alle in der gleichen Zeitzone ansässig sind, müssen Sie sich natürlich nicht mit all diesen Überlegungen beschäftigen und können den Rechner einfach wie gewohnt verwenden.

Verwenden des neuen Zeitzonenfeatures

OK, Sie haben also ein Szenario, für das Sie Zeitzonenunterstützung brauchen. Wie können Sie dies nun mit dem neuen Feature behandeln?

Als Erstes müssen wir die Konfigurationstabelle Zeitzonen auf dem Eingabeblatt konfigurieren. Die Parameter, die wir hier eingeben, steuern die Form der Auslastungskurve, die die Arbeitsauslastungen zusammenfasst. Die Werte hier müssen die durchschnittlichen Nutzungsmuster in Ihrer Organisation widerspiegeln. Ich sehe mir dazu meistens die Leistungsdaten der Ausführung von Exchange-Servern an und frage außerdem die Kunden, wie die Benutzer ihrer Meinung nach arbeiten und wann die Spitzenauslastungszeiten sind.

Sobald das Eingabeblatt fertig ist, gehen wir zum Clientkombinationsblatt – hier haben wir zwei neue Bereiche zum Konfigurieren von Zeitzonendaten.

Der erste ist die Modellzeitzone. Dies ist die Zeitzone der Ressource, für die wir planen, d. h. die Netzwerkverbindung oder Lastenausgleichskomponente. Im obigen Beispiel können Sie sehen, dass ich die Modellzeitzone auf GMT-5 für New York festgelegt habe, dort befand sich unser Lastenausgleichsmodul.

Der zweite ist eine neue Spalte namens Zeitzone. Diese stellt die Zeitzone jedes einzelnen Standorts relativ zur GMT (Greenwich Mean Time) dar. (Da ich Brite bin, habe ich hier GMT gewählt. Wenn sich genügend Leute beschwert haben, stelle ich das vielleicht einmal auf UTC [Coordinated Universal Time] um.)

Die daraus resultierende Vorhersage wird in einem Diagramm unter der Clientkombinationstabelle dargestellt, wie oben gezeigt. Die Werte in dieser Tabelle sind in Mbits/s angegeben und stellen die vorhergesagte Netzwerkauslastung zu jeder Stunde des Tages dar.

Ein zusätzlicher Vorteil

Eines der weiteren nützlichen Features ist, dass der Rechner eine Tabelle liefert, die Sie in den Mailbox Server Role Requirements Calculator kopieren können, um die DAG-Netzwerkreplikationsvorhersage zu vereinfachen.

Rechts neben dem Vorhersagediagramm (Clientkombinationsblatt) im Netzwerkrechner sehen Sie eine Tabelle mit dem Prozentsatz der Veränderung pro Stunde des Tages. Wenn Sie die einmal in die Zwischenablage kopieren ...

Scrollen Sie dann zum unteren Ende des Eingabeblatts im Mailbox Server Role Requirements Calculator. Dort finden Sie eine Tabelle für die Konfiguration der Protokollreplikation. Fügen Sie die Zahlen aus dem Netzwerkrechner in diese Tabelle ein.

Und schon haben Sie es! Der Mailbox Server Role Requirements Calculator kann jetzt die Bandbreitenanforderungen für die DAG-Replikation unter Einbeziehung Ihrer Organisationsdaten und der Zeitzonenkonfiguration berechnen.

Schlussbemerkung

Wir hoffen, dass Sie mit diesem neuen Feature Ihre Netzwerkbandbreitenanforderungen wesentlich genauer vorhersagen können. Das Zeitzonenfeature wird nicht für jede Bereitstellung benötigt, aber den Architekten in großen Unternehmen, die mit diesem Problem kämpfen, macht es das Leben hoffentlich leichter.

Bitte schicken Sie uns weiter Ihr geschätztes Feedback (ob positiv oder negativ) an die Adresse netcalc@microsoft.com. Wir freuen uns über Ihre Anregungen!

Neil Johnson
Senior Consultant, MCS UK

Dies ist ein übersetzter Blogbeitrag. Den Originalartikel finden Sie unter Exchange Client Bandwidth Prediction – the time zone problem…