Beispiele für Verfügbarkeitskonzepte

Dieser Abschnitt enthält zwei Beispiele für Verfügbarkeitsstrategien, die auf der identitätsbasierten Kommunikationslösung eines mittelständischen Unternehmens (1000 bis 5000 Mitarbeiter) basieren, die zuvor unter Identitätsbasiertes Kommunikationsbeispiel erläutert wurden. In der ersten Verfügbarkeitsstrategie ist der Lastenausgleich für Messaging Server dargestellt. In der zweiten Strategie wird eine Failover-Lösung erläutert, bei der Sun Cluster-Software zum Einsatz kommt.

Beispiel des Lastenausgleichs für Messaging Server

In der folgenden Tabelle sind die Einschätzungen hinsichtlich CPU-Kapazität für die einzelnen logischen Messaging Server-Komponenten in der logischen Architektur aufgeführt. In dieser Tabelle wird die endgültige Einschätzung erneut verwendet, die im Abschnitt CPU-Einschätzungen aktualisieren berechnet wurden.

Tabelle 5–6 Anpassungen von CPU-Einschätzungen für unterstützende Komponenten

Komponente	CPUs	Arbeitsspeicher
Messaging Server (MTA, Eingang)	2	4 GB
Messaging Server (MTA, Ausgang)	2	4 GB
Messaging Server (MMP)	2	4 GB
Messaging Server (Nachrichtenspeicher)	2	4 GB

Gehen Sie bei diesem Beispiel davon aus, dass in der Phase der technischen Anforderungen folgende Dienstqualitätsanforderungen festgelegt wurden:

• Verfügbarkeit. Die Gesamtverfügbarkeit des Systems sollte 99,99 % betragen (geplante Ausfallzeiten sind hier nicht berücksichtigt). Der Ausfall eines einzelnen Computersystems sollte nicht zu einem Dienstausfall führen.

• Skalierbarkeit. Kein Server sollte eine Auslastung von mehr als 80 % der täglichen Spitzenauslastung erreichen und im System muss das langfristige Wachstum von 10 % pro Jahr berücksichtigt werden.

Um die Verfügbarkeitsanforderung zu erfüllen, müssen für jede Messaging Server-Komponente zwei Instanzen bereitgestellt werden (jeweils eine auf separaten Servern). Wenn ein Server einer Komponente ausfällt, wird der Dienst vom anderen Server bereitgestellt. In der folgenden Abbildung wird das Netzwerkdiagramm für diese Verfügbarkeitsstrategie dargestellt.

In der obigen Darstellung hat sich die Anzahl der CPUs im Vergleich zur ursprünglichen Einschätzung verdoppelt. Für die Verdoppelung der CPUs gibt es folgende Gründe:

• Wenn ein Server ausfällt, stellt der verbleibende Server die CPU-Kapazität zur Handhabung der Last bereit.

• Hinsichtlich der Skalierbarkeitsanforderung, wonach kein einzelner Server zu mehr als 80 % der Spitzenauslastung beansprucht werden soll, wird dieser Sicherheitsspielraum durch die zusätzliche CPU-Kapazität bereitgestellt.

• Hinsichtlich der Skalierbarkeitsanforderung, wonach ein Lastanstieg von 10 % pro Jahr berücksichtigt werden soll, wird durch die zusätzliche CPU-Kapazität latente Kapazität verfügbar gemacht, die die wachsende Last abdeckt, bis zusätzliche Skalierung erforderlich wird.

Failover-Beispiel mit Sun Cluster-Software

In der folgenden Abbildung wird ein Beispiel einer Failover-Strategie für das Calendar Server-Back-End und den Messaging Server-Datenspeicher dargestellt. Das Calendar Server-Back-End und der Nachrichtenspeicher werden auf separaten Servern repliziert und unter Verwendung von Sun Cluster-Software für das Failover konfiguriert. Die Anzahl an CPUs und der entsprechende Arbeitsspeicher werden in Sun Cluster auf jedem Server repliziert.

Abbildung 5–6 Failover-Konzept mit Sun Cluster-Software

Beispiel für Replikation von Verzeichnisdiensten

Verzeichnisdienste können repliziert werden, um Transaktionen auf unterschiedliche Server aufzuteilen und auf diese Weise die Hochverfügbarkeit zu gewährleisten. Directory Server bietet u. a. folgende Strategien für die Replikation von Diensten:

• Mehrere Datenbanken. Speichert unterschiedliche Bestandteile eines Verzeichnisbaums in separaten Datenbanken.

• Verkettung und Referrals. Nimmt die Verknüpfung verteilter Daten in einen einzelnen Verzeichnisbaum vor.

• Einzelmaster-Replikation. Stellt eine zentrale Quelle für die Master-Datenbank bereit, die im Anschluss auf Verbraucher-Replikate aufgeteilt wird.

• Multimaster-Replikation. Verteilt die Master-Datenbank auf mehrere Server. Von jedem dieser Master wird die zugehörige Datenbank auf Verbraucher-Replikate verteilt.

Verfügbarkeitsstrategien für Directory Server sind ein komplexes Thema, das den Rahmen dieses Handbuchs sprengen würde. In den folgenden Abschnitten, Einzelmaster-Replikation und Multimaster-Replikation werden die grundlegenden Replikationsstrategien erläutert. Ausführliche Informationen finden Sie in Kapitel 12, Designing a Highly Available Deployment, im Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide.

Einzelmaster-Replikation

In der folgenden Abbildung ist eine Einzelmaster-Replikationsstrategie dargestellt, anhand der grundlegende Replikationskonzepte veranschaulicht werden.

Abbildung 5–7 Beispiel für eine Einzelmaster-Replikation

In einer Einzelmaster-Replikation verwaltet eine Instanz von Directory Server die Master-Verzeichnisdatenbank und protokolliert sämtliche Änderungen. Die Master-Datenbank wird auf einer beliebigen Anzahl an Verbraucher-Datenbanken repliziert. Die Verbraucher-Instanzen von Directory Server werden für Lese- und Suchvorgänge optimiert. Sämtliche Schreibvorgänge, die von einem Verbraucher empfangen werden, werden an den Master zurückverwiesen. Die Verbraucher-Datenbanken werden in regelmäßigen Abständen vom Master aktualisiert.

Zu den Vorteilen einer Einzelmaster-Replikation zählen:

• Einzelne für datenbankbezogene Lese- und Schreibvorgänge optimierte Directory Server-Instanz

• Eine beliebige Anzahl von für Lese- und Suchvorgänge optimierten Verbraucher-Instanzen von Directory Server

• Horizontale Skalierbarkeit für Verbraucher-Instanzen von Directory Server

Multimaster-Replikation

In der folgenden Abbildung ist eine Multimaster-Replikationsstrategie dargestellt, die zur globalen Verteilung des Verzeichniszugriffs verwendet werden kann.

In einer Multimaster-Replikation wird die Master-Verzeichnisdatenbank von einer oder mehreren Instanzen von Directory Server verwaltet. Jeder Master weist eine Replikationsvereinbarung auf, aus der Vorgehensweisen für die Synchronisierung der Master-Datenbanken ersichtlich sind. Jeder Master wird auf eine beliebige Anzahl an Verbraucher-Datenbanken repliziert. Wie bei der Einzelmaster-Replikation werden die Verbraucher-Instanzen von Directory Server für den Lese- und Suchzugriff optimiert. Sämtliche Schreibvorgänge, die von einem Verbraucher empfangen werden, werden an den Master zurückverwiesen. Die Verbraucher-Datenbanken werden in regelmäßigen Abständen vom Master aktualisiert.

Abbildung 5–8 Beispiel für eine Multimaster-Replikation

Die Multimaster-Replikationsstrategie bietet alle Vorteile einer Einzelmaster-Replikation und zusätzlich eine Verfügbarkeitsstrategie, durch die der Lastenausgleich für Aktualisierungen des Masters bereitgestellt werden kann. Sie können auch eine Verfügbarkeitsstrategie implementieren, die die lokale Steuerung von Verzeichnisvorgängen ermöglicht, ein wichtiger Aspekt für Unternehmen mit global verteilten Datenzentren.