Datendienst-Projektkonfiguration

Datendienste können für einen Start mit einem Solaris-Projektnamen konfiguriert werden, wenn sie mit dem RGM online gebracht werden. Die Konfiguration ordnet einer vom RGM verwalteten Ressource oder Ressourcengruppe eine Solaris Projekt-ID zu. Durch die Zuordnung der Ressource oder Ressourcengruppe zu einer Projekt-ID können Sie anspruchsvolle Steuerfunktionen, die in der Solaris-Umgebung verfügbar sind, für die Verwaltung von Arbeitslasten und Verbrauch in Ihrem Cluster einsetzen.

Diese Konfiguration können Sie nur dann durchführen, wenn Sie mit der aktuellen Version der Sun Cluster-Software unter Solaris 9 arbeiten.

Mithilfe der Solaris-Verwaltungsfunktion in einer Cluster-Umgebung können Sie sicherstellen, dass die wichtigsten Anwendungen Priorität erhalten, wenn sie einen Knoten mit anderen Anwendungen teilen. Anwendungen können einen Knoten teilen, wenn Sie mit konsolidierten Diensten arbeiten oder weil Anwendungen bei einem Failover den Knoten gewechselt haben. Die Verwendung der hier beschriebenen Verwaltungsfunktion kann die Verfügbarkeit einer kritischen Awendung verbessern, indem andere Anwendungen mit niedrigerer Priorität daran gehindert werden, zu viele Systemleistungen wie CPU-Zeit in Anspruch zu nehmen.

In der Solaris-Dokumentation zu dieser Funktion werden CPU-Zeit, Prozesse, Aufgaben und vergleichbare Komponenten als 'Ressourcen' beschrieben. In der Sun Cluster-Dokumentation hingegen wird der Begriff 'Ressourcen' zur Beschreibung von Entitäten verwendet, die vom RGM gesteuert werden. Im nachstehenden Abschnitt wird der Begriff 'Ressource' für Sun Cluster-Entitäten verwendet, die vom RGM gesteuert werden, und der Begriff 'Leistungen' für CPU-Zeit, Prozesse und Aufgaben.

Dieser Abschnitt enthält eine konzeptuelle Beschreibung zur Konfiguration von Datendiensten, um die Prozesse in einem gegebenen Solaris 9 project(4) zu starten. In diesem Abschnitt werden auch mehrere Failover-Szenarien beschrieben. Des Weiteren enthält er Empfehlungen zur Planung, wie die in der Solaris-Umgebung zur Verfügung gestellte Verwaltungsfunktion eingesetzt werden kann. Detaillierte konzeptionelle und verfahrenstechnische Dokumentation zur Verwaltungsfunktion finden Sie im System Administration Guide: Resource Management and Network Services aus der Solaris 9 System Administrator Collection.

Bei der Konfiguration von Ressourcen und Ressourcengruppen zur Verwendung der Solaris-Verwaltungsfunktion in einem Cluster können Sie folgenden Prozess auf höchster Ebene einsetzen:

1. Konfigurieren von Anwendungen als Teil der Ressource.

2. Konfigurieren von Ressourcen als Teil einer Ressourcengruppe.

3. Aktivieren von Ressourcen in der Ressourcengruppe.

4. Aktivieren der Verwaltung einer Ressourcengruppe.

5. Erstellen eines Solaris-Projekts für die Ressourcengruppe.

6. Konfigurieren von Standardeigenschaften, um den Ressourcengruppennamen dem unter Punkt 5 erstellten Projekt zuzuordnen.

7. Online-bringen der Ressourcengruppe.

Verwenden Sie zur Konfiguration der Standardeigenschaften Resource_project_name oder RG_project_name die -y-Option mit dem scrgadm(1M)-Befehl, um die Solaris-Projekt-ID der Ressource oder Ressourcengruppe zuzuordnen. Stellen Sie die Eigenschaftenwerte für die Ressource oder die Ressourcengruppe ein. Die Definitionen der Eigenschaften finden sie unter “Standard Properties” in Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Siehe r_properties(5) und rg_properties(5) for property descriptions.

Der angegebene Projektname muss in der Projektdatenbank (/etc/project) vorhanden sein, und der Root-Benutzer muss als Mitglied des genannten Projekts konfiguriert sein. Konzeptionelle Informationen zur Projektnamen-Datenbank finden Sie unter “Projects and Tasks” in System Administration Guide: Resource Management and Network Servicesin der Solaris 9 System Administrator Collection. Eine Beschreibung der Syntax der Projektdatei finden Sie unter project(4).

Wenn der RGM Ressourcen oder Ressourcengruppen online bringt, startet er die verknüpften Prozesse unter dem Projektnamen.

Benutzer können die Ressource oder Ressourcengruppe jederzeit einem Projekt zuordnen. Der neue Projektname ist jedoch erst gültig, wenn die Ressource oder Ressourcengruppe mit dem RGM offline genommen und wieder online gebracht wird.

Durch das Starten von Ressourcen und Ressourcengruppen unter dem Projektnamen können Sie die folgenden Funktionen zur Verwaltung der Systemleistungen in Ihrem Cluster konfigurieren.

• Erweiterte Berechnung – Ein flexibler Weg zur Aufzeichnung des Verbrauchs auf Aufgaben- oder Prozessbasis. Mit dieser Funktion können Sie die historische Nutzung nachverfolgen und den Leistungsbedarf für zukünftige Arbeitslasten beurteilen.

• Steuerungen – Ein Mechanismus zur Einschränkung von Systemleistungen. Damit kann verhindert werden, dass Prozesse, Aufgaben und Projekte große Anteile von bestimmten Systemleistungen verbrauchen.

• Faire Nutzungsplanung (FSS) – Damit besteht die Möglichkeit, die Zuweisung der verfügbaren CPU-Zeit auf die Arbeitslasten je nach ihrer Bedeutung zu steuern. Die Bedeutung der Arbeitslast wird durch die Anteile an CPU-Zeit ausgedrückt, die Sie jeder Arbeitslast zuweisen. Eine Beschreibung der Befehlszeile, um FSS als Ihren Standardplaner festzulegen, finden Sie unter dispadmin(1M). Weitere Informationen finden Sie unter priocntl(1), ps(1) und FSS(7).

• Pools – Damit besteht die Möglichkeit, Partitionen je nach Anwendungsanforderungen für interaktive Anwendungen zu nutzen. Pools können zur Partitionierung eines Servers eingesetzt werden, der eine Reihe unterschiedlicher Softwareanwendungen unterstützt. Die Verwendung von Pools führt zu einer besser vorhersehbaren Antwort für jede Anwendung.

Bestimmen der Anforderungen der Projektkonfiguration

Bevor Sie die Datendienste zur Verwendung der von Solaris zur Verfügung gestellten Steuermöglichkeiten in einer Sun Cluster-Umgebung konfigurieren, müssen Sie entscheiden, wie Sie die Ressourcen bei Switchover- oder Failover-Vorgängen steuern und verfolgen möchten. Identifizieren Sie vor der Konfiguration eines neuen Projekts die Abhängigkeiten innerhalb Ihres Clusters. Ressourcen und Ressourcengruppen hängen zum Beispiel von Plattengerätegruppen ab. Verwenden Sie die Ressourcengruppeneigenschaften nodelist, failback, maximum_primaries und desired_primaries, die mit scrgadm(1M) konfiguriert werden, um die Prioritäten in der Knotenliste für Ihre Ressourcengruppe zu identifizieren. Eine kurze Erläuterung der Abhängigkeiten in der Knotenliste zwischen Ressourcengruppen und Plattengerätegruppen finden Sie unter “Relationship Between Resource Groups and Disk Device Groups” in Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Detaillierte Beschreibungen der Eigenschaften finden Sie unter rg_properties(5).

Legen Sie die Prioritäten der Knotenliste für die Plattengerätegruppe mit den Eigenschaften preferenced und failback fest, die mit scrgadm(1M) und scsetup(1M) konfiguriert werden. Verfahrenstechnische Informationen finden Sie unter “So ändern Sie die Plattengeräteeigenschaften” unter “Administering Disk Device Groups” in Sun Cluster System Administration Guide for Solaris OS. Konzeptionelle Informationen zur Knotenkonfiguration und dem Verhalten von Failover- und Scalable-Datendiensten finden Sie unter SunPlex-System-Hardware- und Softwarekomponenten.

Wenn Sie alle Cluster-Knoten gleich konfigurieren, werden die Nutzungsgrenzen auf Primär- und Sekundärknoten identisch durchgesetzt. Die Konfigurationsparameter der Projekte müssen nicht für alle Anwendungen in den Konfigurationsdateien auf allen Knoten gleich sein. Auf alle der Anwendung zugeordneten Projekte muss zumindest die Projektdatenbank auf allen potenziellen Mastern der Anwendung zugreifen können. Angenommen, der Master für Anwendung 1 ist phys-schost-1, kann aber durch ein Switchover oder Failover auch phys-schost-2 oder phys-schost-3 sein. Auf allen drei Knoten (phys-schost-1, phys-schost-2 und phys-schost-3) muss Zugriff auf das der Anwendung 1 zugeordnete Projekt bestehen.

Die Projektdatenbank-Informationen können eine lokale /etc/project-Datenbankdatei sein oder in der NIS-Karte oder im LDAP-Verzeichnisdienst gespeichert sein.

Die Solaris-Umgebung ermöglicht eine flexible Konfiguration der Nutzungsparameter, und Sun Cluster erlegt nur wenige Einschränkungen auf. Die Konfigurationsauswahl hängt von den Standortbedürfnissen ab. Beachten Sie die allgemeinen Richtlinien in den nachfolgenden Abschnitten, bevor Sie Ihre Systeme konfigurieren.

Einstellen virtueller Speicherbegrenzungen für Prozesse

Stellen Sie die process.max-address-space-Steuerung ein, um den virtuellen Speicher auf Prozessbasis zu begrenzen. Detaillierte Informationen zur Einstellung des process.max-address-space-Wertes finden Sie unter rctladm(1M).

Konfigurieren Sie bei Verwendung von Verwaltungssteuerungen die Speicherbegrenzung angemessen, um unnötige Failover-Vorgänge von Anwendungen und einen “Ping-Pong”-Effekt bei den Anwendungen zu vermeiden. Im Allgemeinen gilt Folgendes:

• Stellen Sie die Speicherbegrenzungen nicht zu niedrig ein.

  Wenn eine Anwendung die Speicherbegrenzung erreicht, kann ein Failover erfolgen. Diese Richtlinie ist besonders für Datenbankanwendungen von Bedeutung, wo das Erreichen einer virtuellen Speicherbegrenzung unerwartete Folgen haben kann.

• Stellen Sie die Speicherbegrenzungen für Primär- und Sekundärknoten nicht identisch ein.

  Identische Begrenzungen können einen Ping-Pong-Effekt auslösen, wenn eine Anwendung die Speichergrenze erreicht und ein Failover auf einen Sekundärknoten mit einer identischen Speicherbegrenzung erfolgt. Stellen Sie die Speicherbegrenzung auf dem Sekundärknoten etwas höher ein. Network MultipathingDer Unterschied bei den Speicherbegrenzungen trägt zur Vermeidung des Ping-Pong-Szenarios bei und gibt dem Systemverwalter Zeit, die Parameter nach Bedarf zu korrigieren.

• Verwenden Sie die Speicherbegrenzung der Ressourcenverwaltung für den Lastausgleich.

  Sie können zum Beispiel eine fehlerhaft arbeitende Anwendung mit Speicherbegrenzungen davon abhalten, zu viel Auslagerungsspeicher zu belegen.

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 den ersten beiden Abschnitte, “Zwei-Knoten-Cluster mit zwei Anwendungen“ und “Zwei-Knoten-Cluster mit drei Anwendungen,“ werden Failover-Szenarien für ganze Knoten beschrieben.

• Der Abschnitt “Failover der Ressourcengruppe“ illustriert den Failover-Vorgang einer einzigen Anwendung.

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.

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:

• Anwendung 1 (Anw-1) ist in der Ressourcengruppe RG-1 konfiguriert.

• Anwendung 2 (Anw-2) ist in der Ressourcengruppe RG-2 konfiguriert.

• Anwendung 3 (Anw-3) ist in der Ressourcengruppe RG-3 konfiguriert.

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.

• Alle Anwendungen sind unter einem gemeinsamen Projekt konfiguriert.

• Jede Ressource enthält nur eine einzige Anwendung.

• Die Anwendungen sind die einzigen aktiven Prozesse auf den Knoten.

• Die Projektdatenbanken sind auf allen Knoten des Clusters gleich konfiguriert.

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.

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.

• Anwendung 1 erhält mit 5 Anteilen 50 Prozent der CPU.

• Anwendung 2 erhält mit 3 Anteilen 30 Prozent der CPU.

• Anwendung 3 erhält mit 2 Anteilen 20 Prozent der CPU.

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

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.

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.