Sun Cluster Konzepthandbuch für Solaris OS

Failover-Szenarien

Sie können die Verwaltungsparameter so konfigurieren, dass die Zuweisung in der Projektkonfiguration (/etc/project) im normalen Cluster-Betrieb und in Switchover- und Failover-Situationen funktioniert.

Die nachfolgenden Abschnitte sind als Beispiel gedachte Szenarien.

In einer Cluster-Umgebung wird eine Anwendung als Teil einer Ressource und eine Ressource als Teil einer Ressourcengruppe (RG) konfiguriert. Wenn ein Fehler auftritt, wechselt die Ressourcengruppe zusammen mit den zugeordneten Anwendungen auf einen anderen Knoten. In den nachstehenden Beispielen sind die Ressourcen nicht explizit angegeben. Angenommen, jede Ressource umfasst nur eine Anwendung.


Hinweis –

Ein Failover erfolgt in der bevorzugten Reihenfolge, wie sie in der Knotenliste im RGM angegeben ist.


Für die nachstehenden Beispiele gelten folgende Beschränkungen:

Obwohl die Anzahl der zugeordneten Anteile gleich bleibt, ändert sich der jeder Anwendung zugewiesene Prozentsatz an CPU-Zeit nach dem Failover. Dieser Prozentsatz hängt von der Anzahl der auf dem Knoten ausgeführten Anwendungen sowie von der Anzahl an Anteilen ab, die jeder aktiven Anwendung zugeordnet sind.

In diesen Szenarien werden folgende Konfigurationen vorausgesetzt.

Zwei-Knoten-Cluster mit zwei Anwendungen

Auf einem Zwei-Cluster-Knoten können Sie zwei Anwendungen konfigurieren, um sicherzustellen, dass jeder reale Host (phys-schost-1, phys-schost-2) als Standardmaster für eine Anwendung fungiert. Jeder reale Host fungiert als Sekundärknoten für den anderen realen Host. Alle Projekte, die Anwendung 1 und Anwendung 2 zugeordnet sind, müssen in den Datenbankdateien der Projekte auf beiden Knoten vertreten sein. Im normalen Cluster-Betrieb wird jede Anwendung auf dem eigenen Standard-Master ausgeführt und erhält über die Verwaltungsfunkton die gesamte CPU-Zeit zugewiesen.

Nach einem Failover oder Switchover werden beide Anwendungen auf einem einzigen Knoten ausgeführt und erhalten die Anteile zugewiesen, die in der Konfigurationsdatei angegeben wurden. Dieser Eintrag in der /etc/project-Datei gibt zum Beispiel an, dass Anwendung 1 vier Anteile und Anwendung 2 ein Anteil zugewiesen wird.

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

Die nachstehende Abbildung illustriert den normalen und den Failover-Betrieb in dieser Konfiguration. Die Anzahl der zugewiesenen Anteile ändert sich nicht. Der Prozentsatz an CPU-Zeit, der jeder Anwendung zur Verfügung steht, kann sich jedoch je nach Anzahl der Anteile ändern, die jedem Prozess mit CPU-Zeit-Bedarf zugewiesen werden.

Abbildung: Die Erläuterung zur Grafik ergibt sich aus dem vorstehenden Kontext.

Zwei-Knoten-Cluster mit drei Anwendungen

Auf einem Zwei-Knoten-Cluster mit drei Anwendungen können Sie einen realen Host (phys-schost-1) als Standard-Master für eine Anwendung und den zweiten realen Host (phys-schost-2 ) als Standard-Master für die restlichen zwei Anwendungen konfigurieren. Im folgenden Beispiel wird davon ausgegangen, dass die Projekt-Datenbankdatei auf jedem Knoten vorhanden ist. Die Projekt-Datenbankdatei wird bei einem Failover oder Switchover nicht geändert.

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none)
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)

Im normalen Cluster-Betrieb sind der Anwendung 1 fünf Anteile auf dem entsprechenden Standard-Master phys-schost-1 zugewiesen. Dies entspricht 100 Prozent der CPU-Zeit, weil es die einzige Anwendung ist, die CPU-Zeit auf diesem Knoten benötigt. Den Anwendungen 2 und 3 sind jeweils drei und zwei Anteile auf dem dazugehörigen Standard-Master phys-schost-2 zugewiesen. Damit entfällt auf Anwendung 2 60 Prozent der CPU-Zeit und auf Anwendung 3 40 Prozent der CPU-Zeit im normalen Betrieb.

Wenn Anwendung 1 bei einem Failover oder Switchover auf phys-schost-2 wechselt, bleiben die Anteile für alle drei Anwendungen gleich. Aber der Prozentsatz der CPU-Ressourcen wird anhand der Projekt-Datenbankdatei neu zugewiesen.

Die nachstehende Abbildung illustriert den normalen und den Failover-Betrieb in dieser Konfiguration.

Abbildung: Die Erläuterung zur Grafik ergibt sich aus dem vorstehenden Kontext.

Failover der Ressourcengruppe

In einer Konfiguration, in der mehrere Ressourcengruppen denselben Standard-Master haben, kann eine Ressourcengruppe (und die zugeordneten Anwendungen) bei einem Failover oder Switchover auf einen Sekundärknoten wechseln. Dabei läuft der Standard-Master im Cluster weiter.


Hinweis –

Die Anwendung, die den Failover-Vorgang durchführt, erhält dabei die Ressourcen auf dem Sekundärknoten zugewiesen, die in der Konfigurationsdatei angegeben sind. In diesem Beispiel haben die Projekt-Datenbankdateien auf Primär- und Sekundärknoten dieselbe Konfiguration.


Diese Beispielskonfigurationsdatei gibt an, dass Anwendung 1 ein Anteil, Anwendung 2 zwei Anteile und Anwendung 3 zwei Anteile zugewiesen werden.

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)
 

Die nachstehende Abbildung illustriert den normalen und den Failover-Betrieb in dieser Konfiguration, wobei RG-2 mit Anwendung 2 zu phys-schost-2 wechselt. Beachten Sie, dass sich die Anzahl der zugewiesenen Anteile nicht ändert. Der Prozentsatz an CPU-Zeit, der jeder Anwendung zur Verfügung steht, kann sich jedoch je nach Anzahl der Anteile ändern, die jeder Anwendung mit CPU-Zeit-Bedarf zugewiesen werden.

Abbildung: Die Erläuterung zur Grafik ergibt sich aus dem vorstehenden Kontext.