Notfallwiederherstellung für Front-End-Pools in Skype for Business Server
Für die Notfallwiederherstellung bietet Skype for Business Server poolpaare mit Failover an, falls ein Pool ausfällt.
Für die robustesten Notfallwiederherstellungsoptionen in Skype for Business Server stellen Sie Front-End-Poolspaare auf zwei geografisch verteilten Standorten bereit. Jeder Standort verfügt über einen Front-End-Pool, für den es einen entsprechenden Front-End-Pool am anderen Standort gibt. Beide Standorte sind aktiv, und der Sicherungsdienst ermöglicht die Datenreplikation in Echtzeit, damit die Pools synchronisiert bleiben. Informationen zum Implementieren der Front-End-Poolpaare finden Sie unter Bereitstellen gekoppelter Front-End-Pools für die Notfallwiederherstellung in Skype for Business Server.
Falls der Pool an einem Standort ausfällt, können Sie für die Benutzer ein Failover von diesem Pool auf den Pool am anderen Standort vornehmen, von dem dann für alle Benutzer in beiden Pools Dienste bereitgestellt werden. Für die Kapazitätsplanung sollte bei einem Notfall jeder Pool in der Lage sein, die Arbeitsauslastung aller Benutzer in beiden Pools zu bewältigen.
Zwei Rechenzentren, die die als Paar bereitgestellten Front-End-Pools enthalten, können beliebig weit voneinander entfernt stehen. Wir empfehlen die Verwendung zweier Rechenzentren in derselben Weltregion mit Hochgeschwindigkeitsverbindung.
Die Verwendung zweier Rechenzentren in verschiedenen Weltregionen ist zwar möglich, führt jedoch u. U. zu größeren Datenverlusten aufgrund von Wartezeiten bei der Datenreplikation.
Beachten Sie bei der Planung, welche Pools als Paar bereitgestellt werden, dass nur die folgenden Paarungen unterstützt werden:
Enterprise Edition-Pools können nur mit anderen Enterprise Edition-Pools gepaart werden. Entsprechend können Standard Edition-Pools nur mit anderen Standard Edition-Pools gepaart werden.
Physische Pools können nur mit anderen physischen Pools gepaart werden. Entsprechend können virtuelle Pools nur mit anderen virtuellen Pools gepaart werden.
Gepaarte Pools müssen unter demselben grundlegenden Betriebssystem laufen.
Eine Paarung zweier Pools, die nicht diesen Empfehlungen entspricht, wird weder durch den Topologie-Generator noch durch die Topologieüberprüfung verhindert. Der Topologie-Generator lässt z. B. die Paarung eines Enterprise Edition-Pools mit einem Standard Edition-Pool zu. Diese Art von Paarung wird jedoch nicht unterstützt.
Sichern von Registrierungsstellenbeziehungen und Survivable Branch Appliances
Neben der Notfallwiederherstellung dienen die verbundenen Pools als Sicherungsregistrierungsstellen füreinander. Jeder Pool kann nur die Sicherung für einen anderen Front-End-Pool sein.
Auch wenn Beziehungen von Sicherungsregistrierungsstellen zwischen zwei Front-End-Pools 1:1 und symmetrisch sein müssen, kann jeder Front-End-Pool auch eine Sicherungsregistrierung für eine Reihe von Survivable Branch Appliances sein.
Beachten Sie, dass Skype for Business die Notfallwiederherstellung für Benutzer auf einer Survivable Branch Appliance unterstützt. Wenn ein Front-End-Pool ausfällt, der als Sicherung für eine Survivable Branch Appliance dient, werden die bei der Survivable Branch Appliance angemeldeten Benutzer in den Ausfallsicherheitsmodus versetzt, selbst nachdem die Benutzer auf dem Front-End-Pool auf den Backup-Front-End-Pool verschoben wurden.
Wiederherstellungsdauer bei einem Failover und Failback eines Pools
Für Poolfailover und Pool-Failback beträgt das Engineeringziel für Recovery Time Objective (RTO) 15 bis 20 Minuten. Dies ist die Zeit, die für das Failover erforderlich ist, nachdem Administratoren festgestellt haben, dass ein Notfall aufgetreten ist und die Failoverprozeduren gestartet haben. Es umfasst weder die Zeit, die Administratoren die Situation bewerten und eine Entscheidung treffen können, noch die Zeit für die erneute Anmeldung von Benutzern nach Abschluss des Failovers.
Für Poolfailover und Poolfailbacks liegt das Entwicklungsziel für das Recovery Time Objective (RTO) bei 5 Minuten. Dies definiert die Zeitspanne, in der Daten aufgrund des Notfalls und aufgrund der Replikationswartezeit des Sicherungsdienstes verloren gehen können. Wenn ein Pool z. B. um 10.00 Uhr ausfällt und das RPO bei 5 Minuten liegt, werden die Daten, die zwischen 09.55 Uhr und 10.00 Uhr in den Pool geschrieben werden, möglicherweise nicht im Backup-Pool repliziert und gehen dann verloren.
Bei allen RTO- und RPO-Nummern in diesem Dokument wird davon ausgegangen, dass sich die beiden Rechenzentren in derselben Weltregion mit hochgeschwindigkeitsem Transport mit geringer Latenz zwischen den beiden Standorten befinden. Diese Zahlen werden für einen Pool mit 40.000 gleichzeitig aktiven Benutzern und 200.000 Benutzern gemessen, die für Skype for Business aktiviert sind, in Bezug auf ein vordefiniertes Benutzermodell, in dem kein Backlog bei der Datenreplikation vorhanden ist. Sie können sich basierend auf Leistungstests und -validierungen ändern.
Failover des zentralen Verwaltungsspeichers
Der zentrale Verwaltungsspeicher enthält Konfigurationsdaten zu Servern und Diensten in Ihrer Bereitstellung. Jede Skype for Business Server Bereitstellung enthält einen zentralen Verwaltungsspeicher, der vom Back-End-Server eines Front-End-Pools gehostet wird.
Wenn Sie den Pool koppeln, der den zentralen Verwaltungsspeicher hostet, wird im Sicherungspool eine Datenbank des zentralen Verwaltungsspeichers eingerichtet. Zu einem beliebigen Zeitpunkt ist eine der beiden Datenbanken des zentralen Verwaltungsspeichers aktiv, und die andere ist ein Standby.At any point, the other is a standby. Der Inhalt wird vom Sicherungsdienst von der aktiven Datenbank in den Standby repliziert.
Während eines Poolfailovers, von dem die Pools betroffen sind, die den zentralen Verwaltungsspeicher hosten, müssen Sie den zentralen Verwaltungsspeicher ändern, bevor Sie das Failover für den Front-End-Pool durchführen.
Nach der Behebung des Notfalls ist es nicht erforderlich, einen Failback des zentralen Verwaltungsspeichers durchzuführen. Der zentrale Verwaltungsspeicher kann in dem Pool bleiben, zu dem er geändert wurde.
Die Entwicklungsziele für den zentralen Verwaltungsspeicher sind 5 Minuten für die Wiederherstellungsdauer (Recovery Time Objective, RTO) und 5 Minuten für den Wiederherstellungspunkt (Recovery Point Objective, RPO).
Datensicherheit beim Bilden von Front-End-Poolpaaren
Der Sicherungsdienst überträgt kontinuierlich Benutzerdaten und Konferenzinhalte zwischen zwei gepaarten Front-End-Pools. Zu den Benutzerdaten gehören SIP-URIs von Benutzern sowie Konferenzpläne, Kontaktlisten und Einstellungen. Zu Konferenzinhalten gehören hochgeladene Microsoft PowerPoint-Präsentationen sowie in Konferenzen genutzte Whiteboards.
Vom Quellpool werden die Daten aus dem lokalen Speicher exportiert, gezippt und zum Zielpool übertragen, wo sie entzippt und in den lokalen Speicher importiert werden. Der Sicherungsdienst geht davon aus, dass die Kommunikationsverbindung zwischen den beiden Rechenzentren innerhalb des Unternehmensnetzwerks besteht, das vor dem Internet geschützt ist. Daher werden die übertragenen Daten nicht zwischen den zwei Rechenzentren verschlüsselt und auch nicht innerhalb eines sicheren Protokolls, etwa HTTPS, nativ verschlüsselt. Daher ist ein Man-in-the-Middle-Angriff durch interne Mitarbeiter innerhalb des Unternehmensnetzwerks möglich.
Jedes Unternehmen, das Skype for Business Server über mehrere Rechenzentren hinweg bereitstellt und die Notfallwiederherstellungsfunktion verwendet, muss sicherstellen, dass der Datenverkehr zwischen Rechenzentren durch sein Unternehmensintranet geschützt wird. Unternehmen, die ihren Datenverkehr vor internen Angriffen schützen möchten, müssen die Kommunikationsverbindungen zwischen den Rechenzentren schützen. Dies ist eine standardmäßige Voraussetzung, die auch viele andere Arten von vertraulichen Unternehmensdaten schützt, die zwischen Rechenzentren übertragen werden.
Das Risiko von Man-in-the-Middle-Angriffen innerhalb des Unternehmensnetzwerks besteht zwar, doch ist es im Vergleich zur Gefährdung des Datenverkehrs im Internet relativ begrenzt. Insbesondere die Benutzerdaten, die vom Sicherungsdienst verfügbar gemacht werden (z. B. SIP-URIs), sind für alle Mitarbeiter im Unternehmen über andere Mittel wie etwa das globale Adressbuch oder andere Verzeichnissoftware allgemein verfügbar. Daher sollte der Schwerpunkt auf dem Schutz des WANs zwischen den beiden Rechenzentren liegen, wenn der Sicherungsdienst zum Kopieren von Daten zwischen einem Poolpaar verwendet wird.
Minimieren von Sicherheitsrisiken
Sie haben viele Möglichkeiten, den Sicherheitsschutz für den Datenverkehr des Sicherungsdiensts zu verbessern. Dies reicht von der Einschränkung des Zugriffs auf die Rechenzentren bis hin zum Sichern des WAN-Transports zwischen den beiden Rechenzentren. In den meisten Fällen verfügen Unternehmen, die Skype for Business Server bereitstellen, möglicherweise bereits über die erforderliche Sicherheitsinfrastruktur. Für Unternehmen, die nach Anleitungen suchen, bietet Microsoft eine Lösung als Beispiel für den Aufbau einer sicheren IT-Infrastruktur. Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/p/?LinkId=268544.
Wir implizieren weder, dass dies die einzige Lösung ist, noch implizieren wir, dass es die bevorzugte Lösung für Skype for Business Server ist. Wir empfehlen, dass Unternehmen die Lösung wählen, die ihrem individuellen Bedarf am meisten entspricht, je nach ihrer IT-Sicherheitsinfrastruktur und ihren Sicherheitsanforderungen. In der Microsoft-Beispiellösung werden IPsec und Gruppenrichtlinien für die Server- und Domänenisolation verwendet.
Eine weitere mögliche Lösung besteht in der Verwendung von IPSec ausschließlich zur Sicherung der vom Sicherungsdienst selbst gesendeten Daten. Wenn Sie sich für diese Methode entscheiden, konfigurieren Sie die IPSec-Regeln für das SMB-Protokoll auf den folgenden Servern, wenn Pool A und Pool B zwei verbundene Front-End-Pools sind.
Der SMB-Dienst (TCP/445) von jedem Front-End-Server in Pool A an den von Pool B verwendeten Dateispeicher.
Der SMB-Dienst (TCP/445) von jedem Front-End-Server in Pool B an den von Pool A verwendeten Dateispeicher.
Vorsicht
IPsec ist nicht als Ersatz für Sicherheit auf Anwendungsebene wie etwa SSL/TLS gedacht. Ein Vorteil der Verwendung von IPsec liegt darin, dass es Sicherheit für Netzwerkdatenverkehr für vorhandene Apps bereitstellen kann, ohne dass diese geändert werden müssen. Unternehmen, die nur den Transport zwischen den beiden Rechenzentren sichern möchten, sollten sich an ihre jeweiligen Netzwerkhardwareanbieter wenden, um mithilfe der Geräte des Anbieters sichere WAN-Verbindungen einzurichten.