- Erste Schritte
- Anforderungen
- Hardwareanforderungen
- Softwareanforderungen
- Webserver auf einer einzelnen Maschine
- Bereitstellung mit mehreren Knoten
- Hohe Verfügbarkeit (High Availability)
- Notfallwiederherstellung - Aktiv/Passiv
- Notfallwiederherstellung - Zwei aktive Rechenzentren
- Best Practices
- Installation
- Wird aktualisiert
- Identity Server
- Fehlerbehebung bei Startfehlern
Notfallwiederherstellung - Zwei aktive Rechenzentren
Modell zur Bereitstellung der Disaster Recovery für zwei aktive Rechenzentren, das sowohl hohe Verfügbarkeit als auch Failover-Resilienz bietet.
Das unten dargestellte Bereitstellungsmodell kann implementiert werden, um sowohl Hochverfügbarkeit als auch Notfallwiederherstellung sicherzustellen. Hier sind beide Orchestrator-Knoten aktiv, und der Lastenausgleich leitet den Datenverkehr mithilfe eines bestimmten Algorithmus, z. B. Roundrobin oder einer seiner Varianten, an sie weiter.
Diese Konfiguration erfordert eine gute Netzwerkkonnektivität zwischen den Rechenzentren, die sich in verschiedenen geografischen Gebieten befinden. Das Modell kann vor Ort oder cloudbasiert implementiert werden. Für die Cloudimplementierung müssen Sie für den primären und sekundären Standort unterschiedliche Regionen auswählen.
Dieses Bereitstellungsmodell erfordert Folgendes:
- SQL Server 2012 oder höher und das High Availability add-on für Orchestrator. Frühere Versionen von SQL Server unterstützen AG nicht, und eine Aktiv/Aktiv-Konfiguration wird von Open-Source-Redis nicht unterstützt.
- Zwei High Availability Add-on-Lizenzen.
Abbildung 1. Notfallwiederherstellung - Zwei aktive Rechenzentren
Um eine Hochverfügbarkeit für den Netzwerklastausgleich bereitzustellen (wenn sich der NLB im primären Rechenzentrum befindet), sollte ein sekundärer NLB im Notfallwiederherstellungsrechenzentrum bereitgestellt werden. Die beiden NLB müssen in eine Primär-Sekunden-Konfiguration (oder Master-Replikat) gesetzt werden.
In ein und demselben Rechenzentrum kann ein NLB mit verschiedenen virtuellen Servern (VIPs) für Orchestrator und Elasticsearch verwendet werden. Derselbe NLB kann zur optimalen Lastverteilung auf Orchestrator- und Elasticsearch-Knoten verwendet werden.
Die Funktion Verfügbarkeitsgruppe Immer ein (Always On Availability Group) kann aus mindestens 2 Maschinen bestehen:
- Primäre DB im ersten Rechenzentrum;
- Sekundäre DB im sekundären Rechenzentrum.
Hinweis:
Für HAA und Elasticsearch sind in jedem Rechenzentrum mindestens drei Knoten erforderlich, die in verschiedenen Clustern konfiguriert und synchronisiert sind.
Siehe hier die Voraussetzungen, Einschränkungen und Empfehlungen für die Verfügbarkeitsgruppe Immer ein (Always On Availability Group).