Planen der Hochverfügbarkeit und Notfallwiederherstellung für server mit beständigem Chat in Skype for Business Server 2015
Zusammenfassung: Lesen Sie dieses Thema, um zu erfahren, wie Sie Hochverfügbarkeit und Notfallwiederherstellung für den Server für beständigen Chat in Skype for Business Server 2015 planen.
Hochverfügbarkeit und Notfallwiederherstellung für den Server für beständigen Chat erfordern zusätzliche Ressourcen, die über die normalerweise für den vollständigen Betrieb erforderlichen Ressourcen hinausgehen.
Hinweis
Die Verwendung von SQL AlwaysOn-Verfügbarkeitsgruppen wird für Datenbanken des Servers für beständigen Chat nicht unterstützt.
Hinweis
Beständiger Chat ist in Skype for Business Server 2015 verfügbar, wird aber in Skype for Business Server 2019 nicht mehr unterstützt. Die gleiche Funktionalität ist in Teams verfügbar. Weitere Informationen finden Sie unter Erste Schritte mit Ihrem Microsoft Teams-Upgrade. Wenn Sie beständigen Chat verwenden müssen, können Sie entweder Benutzer, die diese Funktionalität benötigen, zu Teams migrieren oder Skype for Business Server 2015 weiterhin verwenden.
Ressourcenanforderungen
Stellen Sie vor dem Konfigurieren des Servers für beständigen Chat für Hochverfügbarkeit und Notfallwiederherstellung sicher, dass Sie über die folgenden zusätzlichen Ressourcen verfügen.
Eine dedizierte Datenbank instance sich im selben physischen Rechenzentrum befinden, in dem sich das Home-Front-End des Serverdiensts für beständigen Chat befindet. Diese Datenbank dient als SQL Server Spiegel für die primäre Datenbank für beständigen Chat. Optional können Sie einen zusätzlichen SQL Server festlegen, der als Spiegelungszeuge fungieren soll, wenn Sie ein automatisiertes Failover auf die Spiegel-Datenbank wünschen.
Eine dedizierte Datenbankinstanz in dem anderen physischen Rechenzentrum. Diese Datenbank dient als SQL Server sekundäre Datenbank für den Protokollversand für die Datenbank im primären Rechenzentrum.
Eine dedizierte Datenbank instance als SQL Server Spiegel für die sekundäre Datenbank dienen. Optional können Sie einen zusätzlichen SQL Server server als Spiegelungszeugen festlegen. Beide Instanzen müssen sich im selben physischen Rechenzentrum wie die sekundäre Datenbank befinden.
Wenn die Serverkonformität für beständigen Chat aktiviert ist, sind drei zusätzliche dedizierte Datenbankinstanzen erforderlich. Ihre Verteilung entspricht der verteilung, die zuvor für die Datenbank für beständigen Chat beschrieben wurde. Es ist zwar möglich, dass die Kompatibilitätsdatenbank die gleichen SQL Server instance wie die Datenbank für beständigen Chat verwendet, aber eigenständige Instanzen für Hochverfügbarkeit und Notfallwiederherstellung werden empfohlen.
Für die SQL Server Protokollversandtransaktionsprotokolle muss eine Dateifreigabe erstellt und festgelegt werden. Alle SQL Server-Instanzen in beiden Rechenzentren, in denen Datenbanken für beständigen Chat ausgeführt werden, müssen Über Lese-/Schreibzugriff auf diese Dateifreigabe verfügen. Diese Freigabe wird nicht als Teil einer FileStore-Rolle definiert.
Eine Dateifreigabe auf dem sekundären Datenbankserver, die als Zielordner für die SQL Server Transaktionsprotokolle dient, die aus der Dateifreigabe des primären Servers kopiert werden.
Lösungen für Notfallwiederherstellung und hohe Verfügbarkeit
Skype for Business Server unterstützt mehrere Hochverfügbarkeitsmodi für Ihre Back-End-Server, einschließlich Datenbankspiegelung. Weitere Informationen finden Sie unter Plan for high availability and disaster recovery in Skype for Business Server 2015.
Die in diesem Thema beschriebene Notfallwiederherstellungslösung für den Server für beständigen Chat basiert auf einem Stretched Persistent Chat Server-Pool. Ein stretched Virtual Local Area Network (VLAN) ist nicht erforderlich. Indem Sie einen Serverpool für beständigen Chat ausdehnen, konfigurieren Sie einen Pool in der Topologie logisch, aber Sie platzieren die Server physisch in dem Pool in zwei verschiedenen Rechenzentren. Sie konfigurieren SQL Server Spiegelung für die Datenbank auf die gleiche Weise und stellen die Datenbank und die Spiegel im selben Rechenzentrum bereit. Sie müssen eine Sicherungsdatenbank im sekundären Rechenzentrum konfigurieren (mit einem optionalen Spiegel, um Hochverfügbarkeit während der Notfallwiederherstellung bereitzustellen). Dies ist die Sicherungsdatenbank, die für das Failover während der Notfallwiederherstellung verwendet wird.
Ausführliche Informationen zum Konfigurieren von Hochverfügbarkeit und Notfallwiederherstellung für Server für beständigen Chat finden Sie unter Konfigurieren von Hochverfügbarkeit und Notfallwiederherstellung für server mit beständigem Chat in Skype for Business Server 2015.
Die folgenden Abbildungen zeigen, wie der Serverpool für beständigen Chat in zwei verschiedenen Stretched Pool-Topologien konfiguriert werden kann:
Stretched Persistent Chat Server-Pool, wenn Sich Rechenzentren geografisch mit hoher Bandbreite/geringer Latenz befinden.
Stretched Persistent Chat Server-Pool, wenn Sich Rechenzentren geografisch mit geringer Bandbreite/hoher Latenz befinden.
Abbildung 1 zeigt eine Stretched Persistent Chat Server-Pooltopologie, in der sich Rechenzentren in geografischer Lage mit hoher Bandbreite/geringer Latenz befinden. Für die logischen und physischen Topologien wird Folgendes angenommen:
Die logische Topologie beinhaltet die folgenden Komponenten:
Einen Pool für beständigen Chat über die Standorte 1 und 2 hinweg mit den Servern 1 bis einschließlich 8.
Ein Front-End-Serverpool, eine Datenbank für beständigen Chat, eine gespiegelte Datenbank und optional eine Zeugendatenbank (nicht im Diagramm dargestellt), die sich physisch an Standort 1 befinden.
Einen zweiten Front-End-Server-Pool und eine Sicherungsdatenbank, die physisch auf Standort 2 liegen.
Die physische Topologie besteht wie folgt aus den Standorten 1 und 2:
Einen Pool für beständigen Chat mit den Servern 1 bis einschließlich 4, zwei aktiv und zwei im Leerlauf, an Standort 1.
Einen Pool für beständigen Chat mit den Servern 5 bis einschließlich 8, zwei aktiv und zwei im Leerlauf, an Standort 2.
Ein Front-End-Serverpool, eine Datenbank für beständigen Chat, eine gespiegelte Datenbank und optional eine Zeugendatenbank (nicht im Diagramm dargestellt) an Standort 1.
Einen Front-End-Server-Pool und eine Sicherungsdatenbank, die das SQL-Protokollversandziel ist, auf Standort 2.
Gestreckter Serverpool für beständigen Chat bei Rechenzentren an einem geografischen Standort mit hoher Bandbreite und niedriger Latenz
Abbildung 2 zeigt eine Pooltopologie mit Stretched Persistent Chat Server, in der sich Rechenzentren geografisch mit geringer Bandbreite/hoher Latenz befinden.
Die logische Topologie beinhaltet die folgenden Komponenten:
Einen Pool für beständigen Chat über die Standorte 1 und 2 hinweg mit den Servern 1 bis einschließlich 8.
Ein Front-End-Serverpool, eine Datenbank für beständigen Chat, eine gespiegelte Datenbank und optional eine Zeugendatenbank (nicht im Diagramm dargestellt), die sich physisch an Standort 1 befinden.
Einen zweiten Front-End-Server-Pool und eine Sicherungsdatenbank, die physisch auf Standort 2 liegen.
Die physische Topologie besteht wie folgt aus den Standorten 1 und 2:
Einen Pool für beständigen Chat mit den Servern 1 bis einschließlich 4, alle aktiv, an Standort 1.
Einen Pool für beständigen Chat mit den Servern 5 bis einschließlich 8, alle im Leerlauf, an Standort 2.
Ein Front-End-Serverpool, eine Datenbank für beständigen Chat, eine gespiegelte Datenbank und optional eine Zeugendatenbank (nicht im Diagramm dargestellt) an Standort 1.
Einen Front-End-Server-Pool und eine Sicherungsdatenbank, das SQL-Protokollversandziel ist, an Standort 2.
Gestreckter Pool mit Servern für beständigen Chat, bei dem sich die Rechenzentren an einem geografischen Standort mit niedriger Bandbreite und hoher Latenz befinden
