Kapazitätsplanung für Mobilität
Letztes Änderungsdatum des Themas: 2011-12-05
Das Bestimmen der für die Mobilität erforderlichen Kapazität ist ein iterativer Prozess, der das Schätzen der Mobilitätsnutzung, Messen der aktuellen Kapazität, Planen zusätzlicher Kapazität und Überwachen von Leistungsindikatoren umfasst. Die folgende Abbildung veranschaulicht die Phasen der Kapazitätsplanung und die an jeder Phase beteiligten Faktoren.
Workflow zur Planung der Mobilitätskapazität
.jpg "015701c0-77a2-4622-9c01-76576dea0140")
In diesem Abschnitt werden die Faktoren beschrieben, die beim Schätzen der Mobilitätsnutzung berücksichtigt werden müssen, und enthält Richtlinien zum Bestimmen der Größe, die für die Bereitstellung der Mobilität erforderlich ist.
Ausführliche Informationen zum Überwachen der Nutzung und Leistungsindikatoren finden Sie unter:
Ausführliche Informationen zum Überwachen des Serverspeichers finden Sie unter Überwachen der Serverspeicher-Kapazitätslimits.
Ausführliche Informationen zum Überwachen der Mobilitätsnutzung finden Sie unter Überwachen der Nutzung des Mobilitätsdiensts.
Ausführliche Informationen zum Überwachen der IIS-Ablaufverfolgungsprotokolldateien finden Sie unter Überwachen der Protokolldateien der IIS-Ablaufverfolgung für Anforderungen.
Ausführliche Informationen zu den Leistungsindikatoren, die zum Überwachen der Mobilität verwendet werden können, finden Sie unter Leistungsindikatoren für Mobilität.
Ausführliche Informationen zum Konfigurieren des Mobilitätsdiensts für hohe Leistung finden Sie unter Konfigurieren des Mobilitätsdiensts für hohe Leistung.
Faktoren mit Einfluss auf die Kapazität
Die folgenden drei Faktoren beeinflussen die Kapazitätsplanung für Front-End-Server, auf denen der Microsoft Lync Server 2010-Mobilitätsdienst ausgeführt wird:
Benutzermodell
Merkmale des mobilen Geräts
Verfügbarer Arbeitsspeicher (RAM)
Benutzermodell
Das in diesem Abschnitt beschriebene Benutzermodell bildet die Grundlage für die Messungen und Empfehlungen in Bezug auf die Kapazitätsplanung für die Mobilität.
Durchschnittliche Anzahl von Kontakten pro Benutzer
| Kategorie von Kontakten | Durchschnittliche Anzahl pro Benutzer |
|---|---|
Alle Kontakte |
80 |
Unternehmenskontakte |
64 |
Partnerkontakte |
8 |
Kontakte aus öffentlichem Sofortnachrichtensystem |
6 |
Verteilergruppen |
2 |
Am häufigsten verwendete Kontakte |
15 |
Zuletzt verwendete Kontakte |
10 |
Tägliche Aktivität pro Benutzer
| Tägliche Aktivität | Anzahl während der Arbeitszeit | Anzahl außerhalb der Arbeitszeit |
|---|---|---|
Anmeldungen bei mobiler Anwendung |
10 |
2 |
Telefonanrufe (Anzahl) |
10 |
2 |
Telefonanrufe (Dauer) |
2 Minuten pro Anruf |
2 Minuten pro Anruf |
Konferenzen |
1 pro Woche |
0 |
Teilnehmer pro Konferenz |
<10 |
0 |
Statushinweisänderungen |
1 |
0 |
Anzeige der Visitenkarte |
6 |
1 |
Anzeige der Kontaktliste |
9 |
1 |
Bildlauf durch Kontaktliste |
3 |
0 |
Suchen in globaler Adressliste (GAL) |
5* |
- |
Manuelle Anwesenheitsaktualisierungen |
0,5 |
0 |
Anwesenheitsaktualisierungen pro Kontakt insgesamt |
6 |
0 |
Anrufweiterleitung |
0,5 |
0 |
Sofortnachrichtensitzungen (Anzahl) |
3 |
1 |
Sofortnachrichtensitzungen (Dauer) |
6 Minuten pro Sitzung; 1 Nachricht pro 30 Sekunden |
6 Minuten pro Sitzung; 1 Nachricht pro 30 Sekunden |
Kalendersuchen (Verbindungen mit Exchange-Webdienste) |
11 |
3 |
* Anzahl von GAL-Suchen = 1 manuelle Suche pro Tag + automatische Suchen in der Hälfte der ausgehenden Sofortnachrichten und Anrufe. Also: 1 + 2 (Sofortnachrichten) + 2 (Anrufe) = 5.
Merkmale des mobilen Geräts
Auf den für die Mobilität unterstützten mobilen Geräten wird eine Vielzahl von Betriebssystemen ausgeführt. Die Art, in der Anwendungen vom Betriebssystem verwaltet werden, wenn ein Benutzer zu einer anderen Anwendung wechselt, hat Einfluss auf die Kapazitätsplanung. Im Rahmen der Kapazitätsplanung können Betriebssysteme in die folgenden Kategorien unterteilt werden:
Hintergrundaktiviert Wenn ein Benutzer auf einem mobilen Apple- oder Windows Phone-Gerät eine andere mobile Anwendung aufruft, wechselt die mobile Lync 2010-Anwendung in den Hintergrund und verliert die Verbindung mit Lync Server 2010. Die mobile Anwendung wird durch eine Pushbenachrichtigung oder wenn der Benutzer die Anwendung manuell in den Vordergrund schaltet erneut aktiviert.
Immer verbunden Wenn ein Benutzer auf einem mobilen Android- oder Nokia-Gerät eine andere mobile Anwendung aufruft, hält die mobile Lync 2010 Anwendung die Verbindung mit Lync Server 2010 aufrecht, solange der Benutzer angemeldet bleibt.
Mobile Android- und Nokia-Geräte erzeugen eine größere Serverlast, da sie die Verbindung mit dem Server auch aufrechterhalten, wenn der Benutzer die mobile Anwendung nicht aktiv verwendet.
Verfügbarer Speicher
Mit den später in diesem Abschnitt beschriebenen Richtlinien zur Größenbestimmung kann der für die Mobilität erforderliche Speicherplatz besser definiert werden. Mit dem Leistungsindikator Speicher, Verfügbare MB kann der physische Speicherplatz ermittelt werden, der auf dem Server verfügbar ist. Dieser Leistungsindikator zeigt die Menge des physischen Speichers in Megabytes an, der zum Ausführen von Prozessen verfügbar ist. Beträgt der Anteil des zum Ausführen von Prozessen verfügbaren Speicherplatzes am gesamten physischen Speicher weniger als fünf Prozent (5 %), ist der Speicherplatz auf dem Server unzureichend, und dies kann zu einem vermehrten Auslagern führen.
Richtlinien zur Größenbestimmung
Der Mobilitätsdienst belegt zusätzlichen Speicher und beansprucht zusätzliche Prozessorressourcen und Netzwerkressourcen auf den Front-End-Servern. Wenn Sie die Kapazität planen, müssen Sie die Auswirkungen der Mobilitätslast auf den Front-End-Pool kennen und entscheiden, ob für die Mobilitätslast zusätzliche Hardware erforderlich ist. Mit den Beispielen zur Größenbestimmung in der folgenden Tabelle können Sie besser feststellen, ob und in welchem Umfang zusätzliche Hardware erforderlich ist.
Die Beispiele in der Tabelle basieren auf einigen Formeln und Annahmen, die wie folgt definiert sind:
AV steht für die Anzahl mobiler Anwendungen, die im Benutzermodell immer verbunden sind.
HA steht für die Anzahl von mobilen Anwendungen, die im Benutzermodell für den Hintergrund aktiviert sind.
Die Formeln und Annahmen lauten wie folgt:
Zielspeicher (ZSP) in Megabytes = 164 + (AV x 534 + HA x 400) : 1024.
ZSP ist der mindestens erforderliche Speicher.
Basierend auf dem zuvor beschriebenen Benutzermodell beträgt die Anzahl der Verbindungen mit dem Front-End-Pool AV x 2 + HA x 0,20.
Der gemessene Speicher kann höher sein (bis zu 1 MB pro Endpunkt), wenn der Speicher auf dem Server nicht ausgelastet ist. Der Zielspeicher kann höher sein, wenn das Benutzermodell höhere Anforderungen stellt, wenn beispielsweise mehr Audio/Video-Anrufe (A/V) oder Kontakte usw. vorhanden sind.
Die Anzahl der pro Sekunde hergestellten Verbindungen ist niedriger als 30/Sekunde pro 1.000 Benutzer. Diese Anzahl hängt von den Verbindungspoolingeinstellungen auf dem Hardwaregerät zum Lastenausgleich und den Keep-Alive-Einstellungen ab.
Die folgende Tabelle enthält Beispiele zur Größenbestimmung, wenn gemäß Benutzermodell 50 % der Benutzer immer verbunden sind.
Beispiele zur Größenbestimmung
| Anzahl der Benutzer | Speicher (MB) | Durchschnittliche CPU-Auslastung | Maximale CPU-Auslastung CPU |
|---|---|---|---|
1.000 |
620,05 |
1 % |
2,5 % |
2.000 |
1076,11 |
6 % |
8 % |
3.000 |
1532,16 |
14 % |
18 % |
4.000 |
1988,22 |
14 % |
18 % |
5.000 |
2444,27 |
14 % |
18 % |
Szenariobeispiele
Die folgenden Beispiele zeigen die Anwendung der Regeln zur Größenbestimmung auf ein fiktives großes Unternehmen und einen Front-End-Pool, der zwei Server umfasst.
Großes Unternehmen
Contoso hat 75.000 Benutzer in drei Pools mit jeweils vier Front-End-Server pro Pool bereitgestellt. Contoso plant, für 30.000 Benutzer Mobilitätsdienste bereitzustellen.
In der Planungsphase erfassen Contoso-Administratoren folgende Daten:
Auf jedem Front-End-Server sind 3 GB Speicher verfügbar.
Die CPU-Auslastung beträgt weniger als 60 %.
Alle Benutzer haben entweder ein iPhone oder ein Windows Phone.
Das Benutzermodell für Contoso ist dem weiter oben in diesem Abschnitt beschriebenen Benutzermodell für die Kapazitätsplanung ähnlich.
Der mindestens erforderliche Speicher für jeden Server beträgt 164 + 2500 x 400 : 1024 = 1133 MB. Wenn Speicher verfügbar ist, kann mehr Speicherplatz für mobile Anwendungen reserviert werden, da je nach Bedarf bis zu 2,7 GB freigegeben werden können. In beiden Situationen muss Contoso kein Upgrade der Front-End-Server-Hardware vornehmen.
.gif "note") Hinweis: |
|---|
| Das Ziel für die Mobilität ist eine CPU-Auslastung von durchschnittlich 10 %. Contoso muss die Prozessorzeit überwachen, wenn sie sich dem Serverlimit von 70 % nähert. |
Front-End-Pool mit zwei Servern
Contoso hat 8.000 Benutzer in einem Front-End-Pool mit zwei Servern bereitgestellt. Contoso plant, für alle Benutzer Mobilitätsdienste bereitzustellen.
In der Planungsphase erfassen Contoso-Administratoren die folgenden Daten:
Auf jedem Front-End-Server ist 2,5 GB Speicherplatz verfügbar.
Die CPU-Auslastung beträgt weniger als 60 %.
Alle Benutzer haben entweder ein mobiles Nokia- oder Android-Gerät.
Das Benutzermodell für Contoso ist dem weiter oben in diesem Abschnitt beschriebenen Benutzermodell für die Kapazitätsplanung ähnlich.
Der mindestens erforderliche Speicher für jeden Server beträgt 164 + 4000 x 534 : 1024 = 2242 MB. Theoretisch kann ein Server die Last also tragen. Dies ist jedoch nicht der Fall, wenn zwischen den beiden Servern ein Failover auftritt. Darüber hinaus liegt die CPU-Auslastung über 10 %, und das Server-CPU-Limit von 70 % wird erreicht.
Für dieses Szenario wird empfohlen, dem Pool einen Server hinzuzufügen. Die neue Lastverteilung ist 2667 (d. h. 8000/3) Benutzer pro Front-End-Server. Die zusätzlichen Mobilitätskosten betragen 2667 x 534 : 1024 = 1390 MB.
Wenn ein Server hinzugefügt wird, akzeptiert bei einem Serverausfall jeder der drei Server im Pool 1.300 weitere Benutzer, und der Lastanstieg beträgt 600 MB. Bei dieser neuen Lastverteilung bleibt die CPU-Auslastung unter dem Serverlimit von 70 %.