Referenztopologie für mehrere Rechenzentren

 

Letztes Änderungsdatum des Themas: 2012-01-24

Die Referenztopologie für mehrere Rechenzentren gilt für jede Organisationsgröße mit mehr als einem zentralen Standort. Die genaue Topologie in dem folgenden Diagramm bezieht sich auf eine Organisation mit 70.000 Benutzern, von denen sich 40.000 Benutzer am zentralen Standort A und 30.000 Benutzer am zentralen Standort B befinden. Der in diesem Diagramm gezeigte Topologietyp kann Organisationen mit einer beliebigen Benutzeranzahl umfassen.

Diese Topologie wird in mehreren Diagrammen gezeigt. Zunächst sehen Sie einen Überblick, gefolgt von detaillierten Ansichten der zentralen Standorte.

Überblick über die Referenztopologie für mehrere Rechenzentren

Referenztopologie für mehrere Rechenzentren: Detaillierte Ansicht des zentralen Standorts A

Referenztopologie für mehrere Rechenzentren: Detaillierte Ansicht des zentralen Standorts B

Referenztopologie für mehrere Rechenzentren: Detaillierte Ansicht des zentralen Standorts C

• Active Directory-Bereitstellung.   Sämtliche Bereitstellungen der Microsoft Lync Server 2010-Kommunikationssoftware befinden sich in einer einzelnen Active Directory-Gesamtstruktur. In dieser Topologie hat der Kunde Lync Server in zwei untergeordneten Domänen, retail.contoso.com und manufacturing.contoso.com bereitgestellt.

• Möglichkeit zur Unterstützung weiterer Benutzer durch das Hinzufügen zusätzlicher Front-End-Server.   Die im Diagramm gezeigte Organisation umfasst fünf Front-End-Server am zentralen Standort A (für 40.000 Benutzer) und vier Front-End-Server am zentralen Standort B (für 30.000 Benutzer). Wenn einer der beiden Standorte mehr Benutzer unterstützen soll, können Sie dem Pool am jeweiligen Standort einfach weitere Front-End-Server hinzufügen. Die maximale Anzahl von Benutzern pro Pool beträgt 80.000, mit acht Front-End-Servern.

  Jeder Standort kann jedoch noch mehr Benutzer unterstützen, wenn dem Standort ein weiterer Front-End-Pool hinzugefügt wird. Zur Unterstützung weiterer Benutzer müssen Sie lediglich einen zusätzlichen Front-End-Pool hinzufügen (d. h. je einzelne Pools an jedem Standort für A/V-Konferenzserver, Edgeserver und Director-Server sind ausreichend, wenngleich diesen Pools möglicherweise weitere Server hinzugefügt werden müssen).

• Verwenden eines Standard Edition-Servers an einem Zweigstellenstandort.   Neben seiner Verwendung in Lync Server zieht die Organisation den Einsatz von Standort C als Zweigstellenstandort in Betracht, da er nur 600 Mitarbeiter umfasst. Die dortigen Benutzer halten jedoch untereinander viele A/V-Konferenzen ab. Wenn der Standort in Lync Server als Zweigstellenstandort bereitgestellt würde, liefen die Medien für diese Konferenzen über das WAN zum zentralen Standort mit der Installation des A/V-Konferenzservers und wieder zurück. Um dieses potenzielle Leistungsproblem zu vermeiden, haben sie an diesem Standort einen Standard Edition-Server installiert, auf dem diese Konferenzen gehostet werden. Da dort ein Standard Edition-Server installiert wurde, betrachtet Lync Server ihn laut Definition als zentralen Standort, und er wird im Topologie-Generator und im Planungstool als solcher behandelt.

  Solange Benutzer an diesem Standort einen Pool an einem anderen Standort als Sicherungsregistrierungspool festgelegt haben, können sie für Enterprise-VoIP von hoher Verfügbarkeit profitieren – für die VoIP-Unterstützung wird automatisch ein Failover auf den Sicherungsregistrierungsstandort durchgeführt. Für eine vollständigere Hochverfügbarkeitslösung an diesem Standort könnten Sie dort einen zweiten Standard Edition-Server bereitstellen.

  Auch wenn Standort C als zentraler Standort betrachtet wird, müssen Sie dort keine Edgeserver bereitstellen. In diesem Beispiel verwendet Standort C die an Standort A bereitgestellten Edgeserver.

• Überwachen der gemeinsamen Ausführung von Monitoring Server und Archivierungsserver.   Diese Organisation stellt sowohl Monitoring Server als auch Archivierungsserver bereit. Für Organisationen, die beide Rollen bereitstellen, empfiehlt es sich, diese zusammenzulegen und so Serverinvestitionen einzusparen. Bei gemeinsamer Ausführung des Monitoring Servers und des Archivierungsservers kann jede Serverrolle bis zu 100.000 Benutzer unterstützen.

  Beachten Sie, dass Sie Monitoring Server und Archivierungsserver in nur einem zentralen Standort bereitstellen müssen. Wenn die Verbindung zwischen den beiden zentralen Standorten unterbrochen wird, bleiben die Daten während des vorübergehenden Verbindungsausfalls durch die MSMQ-Technologie (Message Queuing) erhalten, die sowohl vom Monitoring Server als auch vom Archivierungsserver verwendet wird.

  In dieser Topologie verwenden Monitoring Server und Archivierungsserver einen anderen Datenbankserver als die Front-End-Pools. Topologien, bei denen der Monitoring Server und der Archivierungsserver dieselben Datenbankserver verwenden wie die Front-End-Pools, werden ebenfalls unterstützt. In großen Bereitstellungen wie dieser werden aus Leistungsgründen jedoch separate Datenbankserver empfohlen.

• Optionen für Bereitstellungen an Zweigstellenstandorten.   Die Organisation in dieser Topologie hat Enterprise-VoIP als ihre VoIP-Lösung bereitgestellt. Die Zweigstellenstandorte 1 und 3 besitzen keine ausfallsichere WAN-Verbindung mit dem zentralen Standort. Daher werden Survivable Branch Appliances eingesetzt, um bei Ausfall der WAN-Verbindung mit dem zentralen Standort Telefondienste bereitzustellen. Zweigstellenstandort 2 verfügt jedoch über eine ausfallsichere WAN-Verbindung, daher wird nur ein PSTN-Gateway benötigt. Das dort bereitgestellte PSTN-Gateway unterstützt die Medienumgehung, deshalb wird an Zweigstellenstandort B kein Vermittlungsserver benötigt. Ausführliche Informationen dazu, welche Komponenten an einem Zweigstellenstandort bereitgestellt werden sollten, finden Sie unter Planen der Ausfallsicherheit für Enterprise-VoIP in der Planungsdokumentation.

• SIP-Trunking und Vermittlungsserver.   Beachten Sie, dass an Standort A der Vermittlungsserver nicht gemeinsam mit den Front-End-Servern ausgeführt wird. Der Grund hierfür liegt darin, dass für Standorte mit SIP-Trunking ein eigenständiger Vermittlungsserver empfohlen wird. In den meisten anderen Fällen empfiehlt sich die gemeinsame Ausführung des Vermittlungsservers mit dem Front-End-Server. Ausführliche Informationen zu den Vermittlungsservertopologien finden Sie unter Komponenten und Topologien für den Vermittlungsserver in der Planungsdokumentation.

• DNS-Lastenausgleich.   Der Front-End-Pool, der Edgeserver- und der Director-Pool wurden zum DNS-Lastenausgleich für SIP-Datenverkehr konfiguriert. Auf diese Weise sind keine Hardwaregeräte zum Lastenausgleich für die interne Schnittstelle der Edgeserver erforderlich, und der für Setup und Wartung der Hardwaregeräte zum Lastenausgleich für die weiteren Pools erforderliche Zeitraum wird erheblich verringert, da die Hardwaregeräte zum Lastenausgleich nur für HTTP-Datenverkehr benötigt werden. Ausführliche Informationen zum DNS-Lastenausgleich finden Sie unter DNS-Lastenausgleich in der Planungsdokumentation.

• Exchange UM-Bereitstellung.  Lync Server 2010 funktioniert sowohl mit lokalen Bereitstellungen von Exchange Unified Messaging (UM) als auch mit gehosteten Exchange UM-Diensten. Der zentrale Standort A umfasst einen Exchange Unified Messaging (UM)-Server, auf dem nicht Lync Server, sondern Microsoft Exchange Server ausgeführt wird. Die Exchange UM-Funktionalität für Lync Server wird im Front-End-Pool ausgeführt.

  Am zentralen Standort B wird gehostetes Exchange eingesetzt, daher wird die Exchange UM-Serverfunktionalität ebenfalls gehostet.

  Ausführliche Informationen zu Exchange UM finden Sie unter Integration in lokale Exchange Unified Messaging-Dienste und Integration in gehostete Exchange Unified Messaging-Dienste.