Findings and Recommendations

 

Letztes Änderungsdatum des Themas: 2011-03-25

Die Ausfallsicherheitslösung für innerstädtische Standorte wurde getestet und wird offiziell von Microsoft unterstützt. Dennoch sollten Sie, bevor Sie diese Topologie bereitstellen, die folgenden Erkenntnisse und Empfehlungen berücksichtigen.

Erkenntnisse

  • Der Clusterfailover funktionierte wie erwartet. Es waren keine manuellen Schritte erforderlich, außer beim Gruppenchatserver, beim Archivierungsserver und beim Monitoring Server. Front-End-Server konnten nach dem Failover wieder eine Verbindung zu den Back-End-Datenbankservern herstellen und den Normalbetrieb wieder aufnehmen. Microsoft Lync 2010-Clients wurden automatisch wieder verbunden.

  • Der Clusterfailback funktionierte wie erwartet. Es ist wichtig, vor dem Beginn des Failbacks sicherzustellen, dass der Speicher neu synchronisiert wurde.

    Die Benutzer sehen während der Rückübermittlung auf ihren üblichen Front-End-Server, sobald dieser wieder verfügbar ist, eine schnelle Folge von Abmelde-/Anmeldevorgängen.

  • Als der Failover erfolgte, musste der Suchdienst des Gruppenchat-Kanaldiensts am Failoverstandort manuell gestartet werden. Zudem musste die Einstellung für den Gruppenchat-Kompatibilitätsserver manuell aktualisiert werden. Ausführliche Informationen hierzu finden Sie unter Sichern des Kompatibilitätsservers in der Betriebsdokumentation.

Empfehlungen

  • Auch wenn beim Testen zwei Knoten (einer pro Standort) in jedem SQL Server-Cluster verwendet wurden, empfehlen wir, zusätzliche Knoten bereitzustellen, um standortinterne Redundanz für alle Komponenten in der Topologie zu erzielen. Wenn beispielsweise der aktive SQL Server-Knoten nicht mehr verfügbar ist, kann ein Sicherungs-SQL Server-Knoten am gleichen Standort, der Teil des gleichen Clusters ist, die Arbeitslast übernehmen, bis der ausgefallene Server wieder online ist oder ersetzt wurde.

  • Beim Testen wurden Komponenten eingesetzt, die von bestimmten Drittanbietern stammen. Die Lösung ist jedoch weder von bestimmten Anbietern abhängig, noch werden durch die Lösung bestimmte Anbieter befürwortet. Solange die verwendeten Komponenten von Microsoft zertifiziert sind und unterstützt werden, ist jeder qualifizierte Anbieter geeignet.

  • Alle einzelnen Komponenten der Lösung (beispielsweise geografisch verteilte Clusterkomponenten) müssen von Microsoft unterstützt und ggf. zertifiziert sein. Das bedeutet jedoch nicht, dass Microsoft direkt Support für einzelne Komponenten von Drittanbietern leistet. Informationen zur Unterstützung einer Komponente erhalten Sie beim betreffenden Drittanbieter.

  • Auch wenn keine vollständige Bereitstellung getestet wurde, ist zu erwarten, dass die veröffentlichten Skalierungsdaten für Lync Server 2010 tragfähig sind. In diesem Sinne sollten Sie eine ausreichende Kapazität planen, sodass auch im Falle eines Failovers genügend Kapazität übrig bleibt, um den Betrieb fortzusetzen. Ausführliche Informationen finden Sie unter Kapazitätsplanung in der Planungsdokumentation.

  • Die Informationen in diesem Abschnitt sind lediglich als Orientierungshilfe gedacht. Bevor Sie diese Lösung in einer Produktionsumgebung bereitstellen, sollten Sie sie daher in Ihrer eigenen Topologie erstellen und testen.

noteHinweis:
Microsoft unterstützt Implementierungen dieser Lösung nicht in Umgebungen, in denen die Netzwerk- und Datenreplikationswartezeit zwischen den primären und sekundären Standorten 20 ms überschreitet oder die Bandbreite das Benutzermodell für eine Organisation nicht unterstützt. Wenn die Wartezeit 20 ms überschreitet, verschlechtert sich die Leistung aus Endbenutzersicht rapide. Zudem verschlechtert sich wahrscheinlich die Leistung von Archivierungsservern und Gruppenchat-Kompatibilitätsservern. Dies kann wiederum dazu führen, dass Front-End-Server und Gruppenchat-Suchserver beendet werden.