Test Results

 

Letztes Änderungsdatum des Themas: 2011-03-02

In diesem Thema werden die Ergebnisse des Microsoft-Tests der Failoverlösung beschrieben, die in diesem Abschnitt vorgeschlagen wird.

Wartezeit für die Verbindung zum zentralen Standort

Wir haben einen Netzwerkwartezeit-Simulator verwendet, um Wartezeit auf der simulierten WAN-Verbindung zwischen den Standorten North und South zu implementieren. Die empfohlene Topologie unterstützt eine maximale Wartezeit von 20 ms zwischen den geografischen Standorten. Dank der Verbesserungen in der Architektur von Lync Server 2010 kann die zulässige Wartezeit höher sein als der Maximalwert von 15 ms in der Microsoft Office Communications Server 2007 R2-Ausfallsicherheitstopologie für innerstädtische Standorte.

• 15 ms.   Wir begannen mit einer Roundtrip-Wartezeit von 15 ms sowohl für den Netzwerkpfad zwischen zwei Standorten als auch für den Datenpfad für die Datenreplikation zwischen den beiden Standorten. Die Topologie funktionierte unter diesen Bedingungen und unter Belastung weiterhin problemlos.

• 20 ms.   Dann begannen wir, die Wartezeit anzuheben. Bei einer Roundtrip-Wartezeit von 20 ms sowohl für das Netzwerk als auch für den Datenverkehr funktionierte die Topologie weiterhin problemlos. 20 ms ist die maximale Roundtrip-Wartezeit, die für diese Topologie in Lync Server 2010 unterstützt wird.

  Wichtig:
  Microsoft unterstützt keine Lösungen, bei denen die Netzwerk- und die Datenwartezeit 20 ms überschreitet.

• 30 ms.   Bei einer Roundtrip-Wartezeit von 30 ms konnten wir die ersten Leistungseinbußen beobachten. Insbesondere die Meldungswarteschlangen für die Archivierungs- und Überwachungsdatenbanken begannen anzuwachsen. Infolge dieser erhöhten Wartezeiten verschlechterte sich auch die Leistung der Benutzeroberfläche. Sowohl die der Anmeldevorgang als auch die Konferenzerstellung verlängerten sich, und die A/V-Leistung verschlechterte sich deutlich. Aus diesen Gründen unterstützt Microsoft keine Lösung, bei der die Roundtrip-Wartezeit 20 ms übersteigt.

Failover

Wie bereits erwähnt, verwendeten alle Windows Server 2008 R2-Cluster in der Topologie das Quorum Knoten- und Dateifreigabemehrheit. Infolgedessen mussten wir, um einen Failover des Standorts zu simulieren, alle Server und Cluster isolieren, indem wir die Verbindung sowohl zum Standort South als auch zum Zeugenstandort lösten. Dazu führten wir ein "unsauberes" Herunterfahren aller Server am Standort North durch.

Im Folgenden die Ergebnisse und unsere Beobachtungen nach dem Ausfall des Standorts North:

• Der passive SQL Server-Clusterknoten wurde innerhalb von wenigen Minuten aktiv. Die genaue Zeitdauer hierfür kann variieren und hängt von den Details der Umgebung ab. Interne Benutzer, die eine Verbindung zum Standort North hatten, wurden abgemeldet und dann automatisch wieder angemeldet. Während des Failovers wurde die Anwesenheit nicht aktualisiert, und bei neuen Aktionen, etwa neuen Sofortnachrichtensitzungen oder -konferenzen, traten Fehler mit entsprechenden Meldungen auf. Nach Abschluss des Failovers traten keine weiteren Fehler auf.

• Solange ein gültiger Netzwerkpfad zwischen Peers bestand, wurden laufende Peer-zu-Peer-Anrufe ohne Unterbrechung fortgesetzt.

• UC-PSTN-Anrufe wurden getrennt, wenn das Gateway für den betreffenden Anruf nicht mehr verfügbar war. In diesem Fall konnten die Benutzer den Anruf manuell wiederherstellen.

• Lync 2010-Benutzer, die eine Verbindung zum Standort North hatten, wurden getrennt und dann innerhalb von Minuten automatisch mit dem Standort South verbunden. Anschließend konnten die Benutzer wie bisher weitermachen.

• Gruppenchatclient-Benutzer mussten sich, um die Verbindung wiederherzustellen, abmelden und dann wieder abmelden. Der Gruppenchat--Kanaldienst und der Suchdienst am Standort South, die beide an dem Standort beendet oder deaktiviert wurden, mussten manuell gestartet werden.

• Für Konferenzen, die am Standort North gehostet wurden, wurde automatisch en Failover zum Standort South ausgeführt. Nach Abschluss des Failovers wurden alle Benutzer aufgefordert, sich wieder in die Konferenz einzuklinken. Clients konnten wieder an der Besprechung teilnehmen. Die Besprechungsaufzeichnung wurde während des Failovers fortgesetzt. Die Archivierung wurde angehalten, bis der unmittelbar betriebsbereite Standby-Archivierungsserver wieder online geschaltet war.

• Die Verwaltbarkeit war während des Ausfalls des Standorts North sichergestellt. Beispielsweise konnten Benutzer von der Survivable Branch Appliance zum Front-End-Pool verschoben werden.

• Sobald der Standort North offline war, wurden die SQL Server-Cluster und Dateifreigabecluster am Standort South innerhalb weniger Minuten online geschaltet.

• Die Dauer des Standortfailovers, wie wir sie während des Tests beobachteten, betrug nur ein paar Minuten.

Failback

Zu Testzwecken definierten wir Failback als das Wiederherstellen aller Funktionen am Standort North, z. B. dass Benutzer wieder Verbindungen zu Servern an diesem Standort herstellen können. Nach der Wiederherstellung des Standorts North wurden alle Clusterressourcen wieder zu ihren Knoten am Standort North zurück verschoben.

Wir empfehlen, den Failback kontrolliert durchzuführen, vorzugsweise außerhalb der Geschäftszeiten, da es während der Ausführung der Failbackverfahren zu Unterbrechungen für die Benutzer kommen kann. Im Folgenden die Ergebnisse und unsere Beobachtungen nach dem Failback des Standorts North:

• Bevor Clusterressourcen zu ihren Knoten am Standort North zurück verschoben werden konnten, musste der Speicher vollständig neu synchronisiert werden. Unterbleibt die Neusynchronisierung des Speichers, können die Cluster nicht wieder online geschaltet werden. Die Neusynchronisierung des Speichers erfolgte automatisch.

• Um die Auswirkungen für die Benutzer zu minimieren, wurde festgelegt, dass kein automatischer Failback der Cluster ausgeführt wird. Wir empfehlen, den Failback bis zum nächsten Wartungsfenster zu verschieben, nachdem sichergestellt wurde, dass der Speicher vollständig neu synchronisiert wurde.

• Die Front-End-Server werden online geschaltet, wenn sie Verbindungen zu den Active Directory-Domänendiensten herstellen können. Ist die Back-End-Datenbank noch nicht verfügbar, wen die Front-End-Server online geschaltet werden, stehen den Benutzern nur begrenzte Funktionen zur Verfügung.

  Nachdem die Front-End-Server am Standort North online sind, werden neue Verbindungen an sie weitergeleitet. Benutzer, die online sind und normalerweise Verbindungen über Front-End-Server am Standort North herstellen, werden abgemeldet und anschließend auf ihrem üblichen Server am Standort North wieder angemeldet.

  Wenn Sie verhindern möchten, dass die Front-End-Server am Standort North automatisch wieder online geschaltet werden – beispielsweise, wenn Sie mehr Kontrolle über den gesamten Prozess wünschen oder wenn die Wartezeit zwischen den beiden Standorten noch nicht wieder einen akzeptablen Wert erreicht hat –, wird empfohlen, die Front-End-Server herunterzufahren.

• Die Dauer des Standortfailbacks, wie wir sie während des Tests beobachteten, betrug unter eine Minute.