Ermitteln von Verfügbarkeitsstrategien

Ziehen Sie bei der Ausarbeitung einer Strategie für Verfügbarkeitsanforderungen die Interaktion zwischen Komponenten sowie die Anwendungsanalyse in Betracht, um zu ermitteln, welche Verfügbarkeitslösungen infrage kommen. Gehen Sie bei der Analyse jede Komponente einzeln durch und ermitteln Sie so die in Bezug auf Verfügbarkeit und Failover am besten geeignete Lösung.

Nachfolgend sind Beispiele für Angaben aufgeführt, die bei der Ermittlung von Verfügbarkeitsstrategien hilfreich sind:

• Wie viele Verfügbarkeits-Neunen sind angegeben?

• Wie sehen die Leistungsspezifikationen in Bezug auf Failover-Situationen aus (z. B. mindestens 50 % Leistung bei Failover)?

• Gehen aus der Anwendungsanalyse Zeiten mit Spitzenauslastung und andere Zeiten hervor?

• Welche geografischen Überlegungen gibt es?

In der von Ihnen ausgewählten Verfügbarkeitsstrategie müssen auch die Anforderungen hinsichtlich der Wartungseignung berücksichtigt werden, die unter Konzeption für optimale Ressourcennutzung beschrieben sind. Komplexe Lösungen mit großem Verwaltungs- und Wartungsaufwand sollten vermieden werden.

Verfügbarkeitsstrategien

Die Verfügbarkeitsstrategien für Java Enterprise System-Bereitstellungen beinhalten folgende Punkte:

• Lastenausgleich. Nutzt redundante Hard- und Softwarekomponenten zur verteilten Lastenverarbeitung. Von einem Lastenausgleichssystem werden sämtliche Anforderungen eines Dienstes an eine von mehreren symmetrischen Instanzen des Dienstes weitergeleitet. Wenn eine der Instanzen ausfällt, sind andere Instanzen verfügbar, die eine größere Last übernehmen.

• Failover. Umfasst die Verwaltung redundanter Hard- und Software zur Gewährleistung des ununterbrochenen Zugriffs von Diensten und der Sicherheit kritischer Daten beim Ausfall einer Komponente.

  Sun Cluster-Software beinhaltet eine Failover-Lösung für kritische Daten, die von Back-End-Komponenten verwaltet werden, beispielsweise der Nachrichtenspeicher für Messaging Server und Kalenderdaten für Calendar Server.

• Replikation von Diensten. Durch die Replikation von Diensten werden mehrere Zugriffsmöglichkeiten auf dieselben Daten bereitgestellt. Directory Server enthält zahlreiche Replikations- und Synchronisierungsstrategien für den LDAP-Verzeichniszugriff.

Die nachfolgenden Abschnitte enthalten Beispiele für Verfügbarkeitslösungen, die unterschiedliche Ebenen hinsichtlich Lastenausgleich, Failover und Replikation von Diensten bereitstellen.

System mit nur einem Server

Platzieren Sie alle Rechnerressourcen für einen Dienst auf einem einzelnen Server. Wenn der Server ausfällt, schlägt der gesamte Dienst fehl.

Abbildung 5–2 System mit nur einem Server

Sun bietet High-End-Server mit folgenden Vorteilen:

• Austausch und Neukonfiguration von Hardwarekomponenten im laufenden Betrieb

• Ausführung mehrerer Anwendungen in fehlerisolierten Domänen auf dem Server

• Aufrüstung hinsichtlich Kapazität und Leistungsgeschwindigkeit sowie E/A-Konfiguration ohne Neustart des Systems

Ein High-End-Server ist in der Regel teurer als ein vergleichbares System mit mehreren Servern. Ein einzelner Server hilft Kosten hinsichtlich Verwaltung, Überwachung und Hosting für Server in einem Datenzentrum zu sparen. Lastenausgleich, Failover und Entfernung von Single-Point-of-Failure gestalten sich in einem System mit mehreren Servern flexibler.

Horizontal redundante Systeme

Es gibt mehrere Möglichkeiten, die Verfügbarkeit mit parallel redundanten Servern zu erhöhen, die sowohl Lastenausgleich als auch Failover bieten. In der nachfolgenden Abbildung sind zwei Replikationsserver dargestellt, die ein N+1-Failover-System zur Verfügung stellen. In einem N+1-System ist ein zusätzlicher Server vorhanden, der bei Ausfall eines Servers 100 %-ige Kapazität bereitstellt.

Abbildung 5–3 N+1-Failover-System mit zwei Servern

Die Rechnerkapazität der Server in der oben gezeigten Abbildung Horizontal redundante Systeme ist identisch. Die Leistungsanforderungen werden von einem Server allein gehandhabt. Der andere Server stellt 100 % Leistung bereit, wenn er als Reserve in Anspruch genommen wird.

Der Vorteil eines N+1-Failover-Konzepts besteht darin, dass während eines Failovers 100 % Leistung bereitgestellt werden können. Zu den Nachteilen zählen die höheren Hardwarekosten, denen keine entsprechende Steigerung der Gesamtleistung gegenübersteht (da ein Server ausschließlich für den Einsatz in Failover-Situationen vorgesehen ist).

In der folgenden Abbildung ist ein System dargestellt, in dem Lastenausgleich plus Failover implementiert werden und so die Leistung zwischen zwei Servern aufgeteilt wird.

Abbildung 5–4 Lastenausgleich plus Failover zwischen zwei Servern

In dem System, das in Horizontal redundante Systeme oben dargestellt ist, stehen beim Ausfalls eines Servers sämtliche Dienste zur Verfügung, jedoch nur zu einem bestimmten Prozentsatz der vollen Kapazität. Der verbleibende Server stellt die Rechnerkapazität von 6 CPUs bereit, es werden also 60 % der 10-CPU-Anforderung erfüllt.

Ein Vorteil dieses Konzepts besteht in der zusätzlichen latenten Kapazität von 2 CPUs, wenn beide Server verfügbar sind.

Aus der folgenden Abbildung geht die Verteilung zwischen mehreren Servern in Bezug auf Leistung und Lastenausgleich hervor.

Abbildung 5–5 Verteilung der Last zwischen n Servern

Da das in der Abbildung Horizontal redundante Systeme dargestellte Konzept 5 Server umfasst, stellen beim Ausfall eines Servers die verbleibenden Server die Rechnerkapazität von insgesamt 8 CPUs bereit; dies entspricht 80 % der 10-CPU-Leistungsanforderung. Wenn Sie dem Konzept einen zusätzlichen Server mit einer Kapazität von 2 CPUs hinzufügen, verfügen Sie über ein n+1-Konzept. Wenn ein Server ausfällt, wird die Leistungsanforderung von den verbleibenden Servern zu 100 % erfüllt.

Dieses Konzept bringt folgende Vorteile mit sich:

• Mehr Leistung bei Ausfall eines einzelnen Servers

• Gewährleistete Verfügbarkeit sogar beim Ausfall mehrerer Server

• Server können zu Wartungs- und Aktualisierungszwecken abwechselnd aus dem aktiven Betrieb genommen werden

• Mehrere Low-End-Server sind in der Regel kostengünstiger als ein einzelner High-End-Server

Durch zusätzliche Server können die Verwaltungs- und Wartungskosten jedoch deutlich ansteigen. Zudem müssen die Kosten für das Hosting der Server in einem Datenzentrum berücksichtigt werden. Ab einem bestimmten Punkt führt das Hinzufügen weiterer Server zu einer verringerten Rendite.

Sun Cluster-Software

In Situationen, in denen ein hohes Maß an Verfügbarkeit erforderlich ist (z. B. bei vier oder fünf Neunen), sollten Sie Sun Cluster-Software als Bestandteil Ihres Verfügbarkeitskonzepts in Erwägung ziehen. Bei einem Cluster-System handelt es sich um die Kombination redundanter Server mit Speicher und anderen Netzwerkressourcen. Die Server in einem Cluster kommunizieren ständig miteinander. Wenn einer der Server in den Offline-Modus versetzt wird, wird er von den verbleibenden Geräten im Cluster isoliert und der Failover-Vorgang für jegliche Anwendungen oder Daten vom deaktivierten Knoten in einen anderen Knoten durchgeführt. Der Failover-Vorgang läuft relativ schnell und mit nur geringer Beeinträchtigung der Dienstbereitstellung für die Benutzer des Systems ab.

Für Sun Cluster-Software sind zusätzliche dedizierte Hardware und besondere Kenntnisse hinsichtlich Konfiguration, Verwaltung und Wartung erforderlich.

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.