Red Hat Enterprise Linux 5

Überblick über die Cluster-Suite

Red Hat Cluster Suite für Red Hat Enterprise Linux 5

Ausgabe 3

Logo

Rechtlicher Hinweis

Copyright © 2009 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

Zusammenfassung

Überblick über die Red Hat Cluster Suite liefert einen Überblick über die Red Hat Cluster Suite für Red Hat Enterprise Linux 5.

Einführung

Dieses Dokument bietet einen umfassenden Überblick über die Red Hat Cluster Suite für Red Hat Enterprise Linux 5 und ist wie folgt aufgebaut:
Auch wenn es sich bei den Informationen in diesem Dokument um einen Überblick handelt, sollten Sie über ausreichende Kenntnisse von Red Hat Enterprise Linux verfügen und die Konzepte von Server-Rechnern verstehen, um ein gutes Verständnis der Informationen zu erlangen.
Werfen Sie einen Blick auf die folgenden Quellen für weitere Informationen zur Verwendung von Red Hat Enterprise Linux:
  • Red Hat Enterprise Linux Installationshandbuch — Liefert Informationen bezüglich der Installation von Red Hat Enterprise Linux 5.
  • Red Hat Enterprise Linux Deployment-Handbuch — Liefert Informationen bezüglich des Einsatzes, der Konfiguration und der Administration von Red Hat Enterprise Linux 5.
Werfen Sie einen Blick auf die folgenden Quellen für weitere Informationen zur Red Hat Cluster Suite für Red Hat Enterprise Linux 5.
  • Konfiguration und Verwaltung eines Red Hat Clusters — Liefert Informationen zur Installation, Konfiguration und Verwaltung von Red Hat Cluster-Komponenten.
  • Logical Volume Manager Administration — Provides a description of the Logical Volume Manager (LVM), including information on running LVM in a clustered environment.
  • Global File System: Konfiguration und Administration — Liefert Informationen zur Installation, Konfiguration und Pflege von Red Hat GFS (Red Hat Global File System).
  • Global File System 2: Konfiguration und Administration — Liefert Informationen zur Installation, Konfiguration und Pflege von Red Hat GFS (Red Hat Global File System 2).
  • Verwendung des Device-Mapper Multipath — Liefert Informationen bezüglich des Device-Mapper Multipath Features von Red Hat Enterprise Linux 5.
  • Verwendung von GNBD mit Global File System — Liefert einen Überblick über die Verwendung des Global Network Block Device (GNBD) mit Red Hat GFS.
  • Linux-Virtual-Server Administration — Liefert Informationen zur Konfiguration von Hochleistungssystemen und -diensten mit dem Linux Virtual Server (LVS).
  • Red Hat Cluster Suite Release Notes — Liefert Informationen zum aktuellen Release der Red Hat Cluster Suite.
Dokumentation zur Red Hat Cluster Suite und weitere Red Hat-Dokumente stehen als HTML-, PDF- und RPM-Versionen auf der Red Hat Enterprise Linux-Dokumentations-CD und online unter http://www.redhat.com/docs/ zur Verfügung.

1. Dokumentkonventionen

Dieses Handbuch verwendet mehrere Konventionen, um bestimmte Wörter und Sätze hervorzuheben und Aufmerksamkeit auf bestimmte Informationen zu lenken.
In PDF- und Papierausgaben verwendet dieses Handbuch Schriftbilder des Liberation-Fonts-Sets. Das Liberation-Fonts-Set wird auch für HTML-Ausgaben verwendet, falls es auf Ihrem System installiert ist. Falls nicht, werden alternative, aber äquivalente Schriftbilder angezeigt. Beachten Sie: Red Hat Enterprise Linux 5 und die nachfolgende Versionen beinhalten das Liberation-Fonts-Set standardmäßig.

1.1. Typografische Konventionen

Es werden vier typografische Konventionen verwendet, um die Aufmerksamkeit auf bestimmte Wörter und Sätze zu lenken. Diese Konventionen und die Umstände, unter denen sie auftreten, sind folgende:
Nichtproportional Fett
Dies wird verwendet, um Systemeingaben hervorzuheben, einschließlich Shell-Befehle, Dateinamen und -pfade. Es wird ebenfalls zum Hervorheben von Tasten und Tastenkombinationen verwendet. Zum Beispiel:
Um den Inhalt der Datei my_next_bestselling_novel in Ihrem aktuellen Arbeitsverzeichnis zu sehen, geben Sie den Befehl cat my_next_bestselling_novel in den Shell-Prompt ein und drücken Sie Enter, um den Befehl auszuführen.
Das oben aufgeführte Beispiel beinhaltet einen Dateinamen, einen Shell-Befehl und eine Taste. Alle werden nichtproportional fett dargestellt und alle können, dank des Kontextes, leicht unterschieden werden.
Tastenkombinationen unterscheiden sich von einzelnen Tasten durch das Pluszeichen, das die einzelnen Teile einer Tastenkombination miteinander verbindet. Zum Beispiel:
Drücken Sie Enter, um den Befehl auszuführen.
Drücken Sie Strg+Alt+F2, um zu einem virtuellen Terminal zu wechseln.
Das erste Beispiel hebt die zu drückende Taste hervor. Das zweite Beispiel hebt eine Tastenkombination hervor: eine Gruppe von drei Tasten, die gleichzeitig gedrückt werden müssen.
Falls Quellcode diskutiert wird, werden Klassennamen, Methoden, Funktionen, Variablennamen und Rückgabewerte, die innerhalb eines Abschnitts erwähnt werden, wie oben gezeigt nichtproportional fett dargestellt. Zum Beispiel:
Zu dateiverwandten Klassen zählen filesystem für Dateisysteme, file für Dateien und dir für Verzeichnisse. Jede Klasse hat ihren eigenen Satz an Berechtigungen.
Proportional Fett
Dies kennzeichnet Wörter oder Sätze, die auf einem System vorkommen, einschließlich Applikationsnamen, Text in Dialogfeldern, beschriftete Schaltflächen, Bezeichnungen für Auswahlkästchen und Radio-Buttons, Überschriften von Menüs und Untermenüs. Zum Beispiel:
Wählen Sie SystemEinstellungenMaus in der Hauptmenüleiste aus, um die Mauseinstellungen zu öffnen. Wählen Sie im Reiter Tasten auf das Auswahlkästchen Mit links bediente Maus und anschließend auf Schließen, um die primäre Maustaste von der linken auf die rechte Seite zu ändern (d.h., um die Maus auf Linkshänder anzupassen).
Um ein Sonderzeichen in eine gedit-Datei einzufügen, wählen Sie AnwendungenZubehörZeichentabelle aus der Hauptmenüleiste. Wählen Sie als Nächstes SuchenSuchen aus der Menüleiste der Zeichentabelle, geben Sie im Feld Suchbegriff den Namen des Zeichens ein und klicken Sie auf Weitersuchen. Das gesuchte Zeichen wird daraufhin in der Zeichentabelle hervorgehoben. Doppelklicken Sie auf dieses hervorgehobene Zeichen, um es in das Feld Zu kopierender Text zu übernehmen und klicken Sie anschließend auf die Schaltfläche Kopieren. Gehen Sie nun zurück in Ihr Dokument und wählen Sie BearbeitenEinfügen aus der gedit-Menüleiste.
Der oben aufgeführte Text enthält Applikationsnamen, systemweite Menünamen und -elemente, applikationsspezifische Menünamen sowie Schaltflächen und Text innerhalb einer grafischen Oberfläche. Alle werden proportional fett dargestellt und sind anhand des Kontextes unterscheidbar.
Nichtproportional Fett Kursiv oder Proportional Fett Kursiv
Sowohl bei nichtproportional fett als auch bei proportional fett weist ein zusätzlicher Kursivdruck auf einen ersetzbaren oder variablen Text hin. Kursivdruck kennzeichnet Text, der nicht wörtlich eingeben wird, oder angezeigten Text, der sich abhängig von den gegebenen Umständen unterscheiden kann. Zum Beispiel:
Um sich mit einer Remote-Maschine via SSH zu verbinden, geben Sie an einem Shell-Prompt ssh username@domain.name ein. Falls die Remote-Maschine example.com ist und Ihr Benutzername auf dieser Maschine John lautet, geben Sie also ssh john@example.com ein.
Der Befehl mount -o remount file-system hängt das angegebene Dateisystem wieder ein. Um beispielsweise das /home-Dateisystem wieder einzuhängen, verwenden Sie den Befehl mount -o remount /home.
Um die Version des derzeit installierten Pakets zu sehen, verwenden Sie den Befehl rpm -q package. Die Ausgabe sieht wie folgt aus: package-version-release.
Beachten Sie die kursiv dargestellten Begriffe oben — username, domain.name, file-system, package, version und release. Jedes Wort ist ein Platzhalter entweder für Text, den Sie für einen Befehl eingeben, oder für Text, der vom System angezeigt wird.
Neben der Standardbenutzung für die Darstellung des Titels eines Werks zeigt der Kursivdruck auch die erstmalige Verwendung eines neuen und wichtigen Begriffs an. Zum Beispiel:
Publican ist ein DocBook Publishing-System.

1.2. Konventionen für Seitenansprachen

Ausgaben des Terminals und Auszüge aus dem Quellcode werden visuell vom umliegenden Text hervorgehoben durch sogenannte Seitenansprachen (auch Pull-Quotes genannt).
Eine an das Terminal gesendete Ausgabe wird in den Schrifttyp nichtproportional Roman gesetzt und wie folgt dargestellt:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Auszüge aus dem Quellcode werden ebenfalls in den Schrifttyp nichtproportional Roman gesetzt, doch wird zusätztlich noch die Syntax hervorgehoben:
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,
                 struct kvm_assigned_pci_dev *assigned_dev)
{
         int r = 0;
         struct kvm_assigned_dev_kernel *match;

         mutex_lock(&kvm->lock);

         match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head,
                                       assigned_dev->assigned_dev_id);
         if (!match) {
                 printk(KERN_INFO "%s: device hasn't been assigned before, "
                   "so cannot be deassigned\n", __func__);
                 r = -EINVAL;
                 goto out;
         }

         kvm_deassign_device(kvm, match);

         kvm_free_assigned_device(kvm, match);

out:
         mutex_unlock(&kvm->lock);
         return r;
}

1.3. Anmerkungen und Warnungen

Zu guter Letzt verwenden wir drei visuelle Stile, um die Aufmerksamkeit auf Informationen zu lenken, die andernfalls vielleicht übersehen werden könnten.

Anmerkung

Eine Anmerkung ist ein Tipp, ein abgekürztes Verfahren oder ein alternativer Ansatz für die vorliegende Aufgabe. Das Ignorieren von Anmerkungen sollte keine negativen Auswirkungen haben, aber Sie verpassen so vielleicht einen Trick, der Ihnen das Leben vereinfachen könnte.

Wichtig

Die Wichtig-Schaukästen lenken die Aufmerksamkeit auf Dinge, die sonst leicht übersehen werden können: Konfigurationsänderungen, die nur für die aktuelle Sitzung gelten oder Dienste, für die ein Neustart nötig ist, bevor eine Aktualisierung wirksam wird. Das Ignorieren von Wichtig-Schaukästen würde keinen Datenverlust verursachen, kann aber unter Umständen zu Ärgernissen und Frustration führen.

Warnung

Eine Warnung sollte nicht ignoriert werden. Das Ignorieren von Warnungen führt mit hoher Wahrscheinlichkeit zu Datenverlust.

2. Feedback

Falls Sie Fehler entdecken (inhaltlich wie orthografisch), oder Vorschläge bzw. Anregungen zur Verbesserung dieses Dokuments machen möchten, freuen wir uns über Ihr Feedback. Bitte reichen Sie einen Fehlerbericht in Bugzilla (http://bugzilla.redhat.com/bugzilla/) für die Komponente Documentation-cluster ein.
Be sure to mention the document's identifier:
Cluster_Suite_Overview(EN)-5 (2009-08-18T15:49)
By mentioning this document's identifier, we know exactly which version of the guide you have.
Falls Sie Vorschläge zur Verbesserung der Dokumentation haben, versuchen Sie so spezifisch wie möglich zu sein. Falls Sie einen Fehler entdeckt haben, fügen Sie bitte die Nummer des Abschnitts, sowie einigen angrenzenden Text ein, damit wir die Stelle leicht wiederfinden können.

Kapitel 1. Überblick über die Red Hat Cluster Suite

Cluster-Systeme bieten Zuverlässigkeit, Skalierbarkeit und Verfügbarkeit für kritische Produktionsdienste. Mit Hilfe der Red Hat Cluster Suite können Sie ein Cluster erstellen, das Ihren Anforderungen hinsichtlich Leistung, Hochverfügbarkeit, Lastverteilung, Skalierbarkeit, gemeinsamen Dateizugriff und Wirtschaftlichkeit entspricht. Dieses Kapitel bietet einen Überblick über Komponenten der Red Hat Cluster Suite und deren Funktionen und besteht aus den folgenden Abschnitten:

1.1. Cluster-Grundlagen

Ein Cluster besteht aus zwei oder mehreren Computern (auch Knoten oder Mitglieder genannt), die bei der Durchführung einer Aufgabe zusammenarbeiten. Es gibt vier Haupttypen von Clustern:
  • Speicher-Cluster
  • Hochverfügbarkeits-Cluster
  • Lastverteilungs-Cluster
  • Hochleistungs-Cluster
Speicher-Cluster stellen ein Image mit konsistentem Dateisystem zwischen Servern in einem Cluster zur Verfügung. Dies erlaubt den Servern, gleichzeitig auf ein einzelnes gemeinsam genutztes Dateisystem lesend und schreibend zuzugreifen. Ein Speicher-Cluster vereinfacht die Speicheradministration, indem es die Installation und das Patchen von Applikationen auf ein Dateisystem reduziert. Auch eliminiert ein Speicher-Cluster den Bedarf für redundante Kopien von Applikationsdaten durch ein clusterweites Dateisystem und vereinfacht Backup und Notfallwiederherstellung. Die Red Hat Cluster Suite stellt Speicher-Clustering via Red Hat GFS zur Verfügung.
Hochverfügbarkeits-Cluster bieten kontinuierliche Verfügbarkeit von Diensten, indem sie einzelne Ausfallpunkte eliminieren und Dienste von einem Cluster-Knoten auf einen anderen transferieren, falls ein Knoten nicht funktionsfähig ist. Typischerweise schreiben und lesen Dienste Daten in einem Hochverfügbarkeits-Cluster (via eingehängte Dateisysteme, die lesbar/beschreibbar sind). Aus diesem Grund muss ein Hochverfügbarkeits-Cluster die Integrität von Daten gewährleisten, wenn ein Cluster-Knoten die Kontrolle eines Dienstes von einem anderen Cluster-Knoten übernimmt. Knotenausfälle in einem Hochverfügbarkeits-Cluster sind von Clients außerhalb des Clusters nicht sichtbar. (Hochverfügbarkeits-Cluster werden manchmal auch als Ausfallsicherungs-Cluster bezeichnet.) Die Red Hat Cluster Suite stellt Hochverfügbarkeits-Clustering im Rahmen der Hochverfügbarkeitsdienst-Management-Komponente zur Verfügung.
Lastverteilungs-Cluster versenden Anfragen von Netzwerk-Diensten an mehrere Cluster-Knoten, um die Auslastung durch die Anfrage gleichmäßig zwischen den Cluster-Knoten zu verteilen. Lastverteilung bietet eine kostengünstige Skalierbarkeit, da die Anzahl der Knoten mit den Auslastungsanforderungen abgeglichen werden kann. Falls ein Knoten in einem Lastverteilungs-Cluster nicht mehr funktionsfähig ist, erkennt die Lastverteilungs-Software diesen Ausfall und leitet Anfragen an andere Cluster-Knoten weiter. Knoten-Ausfälle in einem Lastverteilungs-Cluster sind nicht ersichtlich von Clients außerhalb des Clusters. Die Red Hat Cluster Suite stellt Lastverteilung via LVS (Linux Virtual Server) zur Verfügung.
Hochleistungs-Cluster verwenden Cluster-Knoten zur Durchführung von gleichzeitigen Berechnungen. Ein Hochleistungs-Cluster erlaubt Applikationen, parallel zu arbeiten und steigert daher die Leistungsfähigkeit der Applikationen. (Hochleistungs-Cluster werden auch als Computer-Cluster oder Grid-Computing bezeichnet.)

Anmerkung

Die Cluster-Typen, die in diesem vorausgehenden Text zusammengefasst sind, geben Grundkonfigurationen wieder. Ihre Anforderungen erfordern ggf. eine Kombination der beschriebenen Cluster.

1.2. Red Hat Cluster Suite Introduction

Die Red Hat Cluster Suite (RHCS) ist ein integriertes Set von Software-Komponenten, das in einer Vielzahl von Konfigurationen eingesetzt werden kann, um Ihren Anforderungen in Sachen Leistung, Hochverfügbarkeit, Lastverteilung, Skalierbarkeit, gemeinsamen Dateizugriff und Wirtschaftlichkeit gerecht zu werden.
RHCS consists of the following major components (refer to Abbildung 1.1, „Red Hat Cluster Suite Introduction“):
  • Cluster-Infrastruktur — Bietet grundlegende Funktionen für Knoten für die Zusammenarbeit als ein Cluster: Verwalten der Konfigurationsdatei, der Zugehörigkeit, der Sperrung und der Datenabgrenzung (Fencing).
  • Hochverfügbarkeitsdienst-Management — Bietet die Übertragung von Diensten von einem Knoten auf einen anderen, falls ein Knoten nicht mehr funktionsfähig ist.
  • Cluster Administrations-Tools — Konfigurations- und Management-Tools zum Einrichten, Konfigurieren und Verwalten eines Red Hat-Clusters. Die Tools sind zur Verwendung mit den Cluster-Infrastruktur-Komponenten, den Hochverfügbarkeits-Komponenten und den Dienst-Management-Komponenten und Speicher gedacht.
  • Linux Virtual Server (LVS) — Routing-Software, die IP-Lastverteilung bietet. LVS läuft als ein Paar redundanter Server, die Client-Anfragen gleichmäßig auf reale Server hinter den LVS-Servern verteilen.
Sie können die Red Hat Cluster Suite durch die folgenden Komponenten, die Teil eines optional Pakets sind (und nicht Teil der Red Hat Cluster Suite), ergänzen:
  • Red Hat GFS (Global File System) — Bietet ein Cluster-Dateisystem zur Verwendung mit der Red Hat Cluster Suite. GFS ermöglicht mehreren Knoten, Speicher auf einem Blocklevel gemeinsam zu nutzen, als ob der Speicher lokal mit jedem Cluster-Knoten verbunden wäre.
  • Cluster Logical Volume Manager (CLVM) — Bietet das Verwalten von Datenträgern eines Cluster-Speichers.

    Anmerkung

    When you create or modify a CLVM volume for a clustered environment, you must ensure that you are running the clvmd daemon. For further information, refer to Abschnitt 1.6, „Cluster Logical-Volume-Manager“.
  • Global Network Block Device (GNBD) — Eine Hilfskomponente von GFS, die Blocklevel-Speicher für das Ethernet exportiert. Dies ist eine ökonomische Art und Weise, Blocklevel-Speicher für Red Hat GFS verfügbar zu machen.
For a lower level summary of Red Hat Cluster Suite components and optional software, refer to Kapitel 2, Zusammenfassung der Komponenten der Red Hat Cluster Suite.
Red Hat Cluster Suite Introduction

Abbildung 1.1. Red Hat Cluster Suite Introduction


Anmerkung

Abbildung 1.1, „Red Hat Cluster Suite Introduction“ includes GFS, CLVM, and GNBD, which are components that are part of an optional package and not part of Red Hat Cluster Suite.

1.3. Cluster Infrastructure

Die Cluster-Infrastruktur der Red Hat Cluster Suite liefert die Grundfunktionen für eine Gruppe von Computern (auch Knoten oder Mitglieder genannt), damit diese in einem Cluster zusammenarbeiten können. Sobald ein Cluster unter Verwendung der Cluster-Infrastruktur gebildet wurde, können Sie weitere Komponenten der Red Hat Cluster Suite verwenden, um Ihren Clustering-Anforderungen gerecht zu werden (z.B. das Einrichten eines Cluster für den gemeinsamen Dateizugriff auf einem GFS-Dateisystem oder das Einrichten von Dienst-Übertragungen bei einem Ausfall). Die Cluster-Infrastruktur führt die folgenden Funktionen durch:
  • Cluster-Management
  • Lock-Management
  • Fencing
  • Cluster-Konfigurations-Management

1.3.1. Cluster-Management

Cluster management manages cluster quorum and cluster membership. CMAN (an abbreviation for cluster manager) performs cluster management in Red Hat Cluster Suite for Red Hat Enterprise Linux 5. CMAN is a distributed cluster manager and runs in each cluster node; cluster management is distributed across all nodes in the cluster (refer to Abbildung 1.2, „CMAN/DLM Overview“).
CMAN keeps track of cluster quorum by monitoring the count of cluster nodes. If more than half the nodes are active, the cluster has quorum. If half the nodes (or fewer) are active, the cluster does not have quorum, and all cluster activity is stopped. Cluster quorum prevents the occurrence of a "split-brain" condition — a condition where two instances of the same cluster are running. A split-brain condition would allow each cluster instance to access cluster resources without knowledge of the other cluster instance, resulting in corrupted cluster integrity.
Ein Quorum wird durch die Kommunikation von Meldungen zwischen Cluster-Knoten via Ethernet bestimmt. Optional kann ein Quorum durch eine Kombination aus kommunizierenden Meldungen via Ethernet und durch eine Quorum-Platte bestimmt werden. Bei einem Quorum via Ethernet besteht dieses zu 50 Prozent aus den Knotenstimmen plus 1. Bei einem Quorum via Quorum-Platte besteht dieses aus benutzerspezifischen Bedingungen.

Anmerkung

Standardmäßig besitzt jeder Knoten eine Quorum-Stimme. Optional können Sie jeden Knoten so konfigurieren, dass er mehr als eine Stimme besitzt.
CMAN behält die Zugehörigkeit im Auge, indem er die Meldungen von anderen Cluster-Knoten überwacht. Wenn sich Cluster-Zugehörigkeiten ändern, informiert der Cluster-Manager die anderen Infrastruktur-Komponenten, die dann die entsprechenden Aktionen einleiten. Wenn beispielsweise Knoten A einem Cluster beitritt und ein GFS-Dateisystem einhängt, welches Knoten B und C bereits eingehängt haben, dann wird ein zusätzliches Journal- und Lock-Management für Knoten A benötigt, um dieses GFS-Dateisystem verwenden zu können. Falls ein Cluster-Knoten eine Meldung nicht innerhalb einer vorgeschriebenen Zeitspanne übermittelt, entfernt der Cluster-Manager den Knoten aus dem Cluster und kommuniziert mit anderen Cluster-Infrastruktur-Komponenten, dass der Knoten kein Mitglied mehr ist. Andere Cluster-Infrastruktur-Komponenten wiederum bestimmen, welche Aktionen als Folge der Benachrichtigung, dass der Knoten nicht mehr länger ein Bestandteil des Clusters ist, einzuleiten sind. "Fencing" würde den Knoten, der kein Mitglied mehr ist, beispielsweise ausgrenzen.
CMAN/DLM Overview

Abbildung 1.2. CMAN/DLM Overview


1.3.2. Lock-Management

Lock management is a common cluster-infrastructure service that provides a mechanism for other cluster infrastructure components to synchronize their access to shared resources. In a Red Hat cluster, DLM (Distributed Lock Manager) is the lock manager. As implied in its name, DLM is a distributed lock manager and runs in each cluster node; lock management is distributed across all nodes in the cluster (refer to Abbildung 1.2, „CMAN/DLM Overview“). GFS and CLVM use locks from the lock manager. GFS uses locks from the lock manager to synchronize access to file system metadata (on shared storage). CLVM uses locks from the lock manager to synchronize updates to LVM volumes and volume groups (also on shared storage).

1.3.3. Fencing

Fencing is the disconnection of a node from the cluster's shared storage. Fencing cuts off I/O from shared storage, thus ensuring data integrity. The cluster infrastructure performs fencing through the fence daemon, fenced.
Wenn CMAN bemerkt, dass ein Knoten ausgefallen ist, kommuniziert er mit den anderen Cluster-Infrastruktur-Komponenten, dass der Knoten ausgefallen ist. Sobald fenced von dem Ausfall unterrichtet ist, grenzt er den ausgefallenen Knoten ab. Die anderen Cluster-Infrastruktur-Komponenten bestimmen, welche Schritte einzuleiten sind — d.h. sie führen sämtliche Wiederherstellungsmaßnahmen durch, die durchgeführt werden müssen. So suspendieren beispielsweise DLM und GFS beim Erhalt der Information über einen Knoten-Ausfall sämtliche Aktivitäten, bis sie feststellen, dass der fenced den Fencing-Prozess für den ausgefallenen Knoten abgeschlossen hat. Nach der Bestätigung, dass der ausgefallene Knoten abgegrenzt ist, führen DLM und GFS Wiederherstellungsmaßnahmen durch. DLM gibt die Locks für den ausgefallenen Knoten frei und GFS stellt das Journal des ausgefallenen Knotens wieder her.
Das Fencing-Programm ermittelt anhand der Cluster-Konfigurationsdatei, welche Fencing-Methode verwendet werden soll. Zwei Schlüsselelemente in der Cluster-Konfigurationsdatei definieren eine Fencing-Methode: Der Fencing-Agent und das Fencing-Gerät. Das Fencing-Programm startet einen Aufruf zu einem in der Cluster-Konfigurationsdatei angegebenen Fencing-Agent. Der Fencing-Agent grenzt den Knoten im Gegenzug via Fencing-Gerät ab. Nach Abschluss des Fencings, unterrichtet das Fencing-Programm den Cluster-Manager.
Die Red Hat Cluster Suite stellt eine Vielzahl von Fencing-Methoden zur Verfügung:
  • Power-Fencing — Eine Fencing-Methode, die einen Power-Kontroller verwendet, um einen nicht mehr funktionierenden Knoten auszuschalten.
  • Fibre-Channel-Switch-Fencing — Eine Fencing-Methode, die den Fibre-Channel-Port deaktiviert, der den Speicher mit einem nicht funktionsfähigen Knoten verbindet.
  • GNBD fencing — A fencing method that disables an inoperable node's access to a GNBD server.
  • Sonstiges Fencing — Mehrere sonstige Fencing-Methoden, die I/O oder den Strom eines nicht funktionsfähigen Knotens deaktiviert, inklusive IBM-Bladecenters, PAP, DRAC/MC, ILO, IPMI, IBM RSA II und weitere.
Abbildung 1.3, „Power Fencing Example“ shows an example of power fencing. In the example, the fencing program in node A causes the power controller to power off node D. Abbildung 1.4, „Fibre Channel Switch Fencing Example“ shows an example of Fibre Channel switch fencing. In the example, the fencing program in node A causes the Fibre Channel switch to disable the port for node D, disconnecting node D from storage.
Power Fencing Example

Abbildung 1.3. Power Fencing Example


Fibre Channel Switch Fencing Example

Abbildung 1.4. Fibre Channel Switch Fencing Example


Das Angeben einer Fencing-Methode beinhaltet das Bearbeiten einer Cluster-Konfigurationsdatei für die Zuweisung eines Namens für die Fencing-Methode, dem Fencing-Agent und dem Fencing-Gerät für jeden Knoten im Cluster.
The way in which a fencing method is specified depends on if a node has either dual power supplies or multiple paths to storage. If a node has dual power supplies, then the fencing method for the node must specify at least two fencing devices — one fencing device for each power supply (refer to Abbildung 1.5, „Fencing a Node with Dual Power Supplies“). Similarly, if a node has multiple paths to Fibre Channel storage, then the fencing method for the node must specify one fencing device for each path to Fibre Channel storage. For example, if a node has two paths to Fibre Channel storage, the fencing method should specify two fencing devices — one for each path to Fibre Channel storage (refer to Abbildung 1.6, „Fencing a Node with Dual Fibre Channel Connections“).
Fencing a Node with Dual Power Supplies

Abbildung 1.5. Fencing a Node with Dual Power Supplies


Fencing a Node with Dual Fibre Channel Connections

Abbildung 1.6. Fencing a Node with Dual Fibre Channel Connections


Sie können einen Knoten mit einer oder mehreren Fencing-Methoden konfigurieren. Wenn Sie einen Knoten mit einer Fencing-Methode konfigurieren, ist dies die einzige Fencing-Methode, die für das Fencing dieses Knotens zur Verfügung steht. Wenn Sie einen Knoten mit mehreren Fencing-Methoden konfigurieren, werden die Fencing-Methoden von einer Fencing-Methode zu einer anderen kaskadiert, nach der in der Cluster-Konfigurationsdatei angegebenen Reihenfolge für Fencing-Methoden. Falls ein Knoten ausfällt, wird er mit der ersten in der Cluster-Konfigurationsdatei für diesen Knoten angegebenen Fencing-Methode abgegrenzt. Falls die erste Fencing-Methode nicht erfolgreich ist, wird die zweite für diesen Knoten angegebene Fencing-Methode verwendet. Falls keine der Fencing-Methoden erfolgreich ist, startet der Fencing-Prozess erneut mit der ersten angegebenen Fencing-Methode und geht die Fencing-Methoden in der in der Cluster-Konfigurationsdatei angegebenen Reihenfolge solange durch, bis der Knoten abgegrenzt wurde.

1.3.4. Cluster Configuration System

The Cluster Configuration System (CCS) manages the cluster configuration and provides configuration information to other cluster components in a Red Hat cluster. CCS runs in each cluster node and makes sure that the cluster configuration file in each cluster node is up to date. For example, if a cluster system administrator updates the configuration file in Node A, CCS propagates the update from Node A to the other nodes in the cluster (refer to Abbildung 1.7, „CCS Overview“).
CCS Overview

Abbildung 1.7. CCS Overview


Other cluster components (for example, CMAN) access configuration information from the configuration file through CCS (refer to Abbildung 1.7, „CCS Overview“).
Accessing Configuration Information

Abbildung 1.8. Accessing Configuration Information


Die Cluster-Konfigurationsdatei (/etc/cluster/cluster.conf) ist eine XML-Datei, die die folgenden Cluster-Charakteristiken beschreibt:
  • Cluster-Name — Zeigt den Cluster-Namen, das Revisionslevel der Cluster-Konfigurationsdatei und grundlegende Fence-Timing-Eigenschaften an, die verwendet werden, wenn ein Knoten einem Cluster beitritt oder aus einem Cluster abgegrenzt wird.
  • Cluster — Zeigt jeden Knoten des Clusters an, unter Angabe des Knoten-Namens, der Knoten-ID, der Zahl der Quorum-Stimmen und der Fencing-Methode für diesen Knoten.
  • Fence-Gerät — Zeigt die Fence-Geräte im Cluster an. Die Parameter variieren je nach Typ des Fence-Geräts. Für einen Power-Kontroller beispielsweise, der als Fence-Gerät benutzt wird, definiert die Cluster-Konfiguration den Namen des Power-Kontroller, dessen IP-Adresse, das Login und das Passwort.
  • Verwaltete Ressourcen — Zeigt die Ressourcen an, die zum Erstellen von Cluster-Diensten benötigt werden. Verwaltete Ressourcen umfassen die Definition von Ausfallsicherungs-Domains, Ressourcen (zum Beispiel einer IP-Adresse) und Dienste. Zusammen definieren die verwalteten Ressourcen Cluster-Dienste und Ausfallsicherungsverhalten der Cluster-Dienste.

1.4. Hochverfügbarkeitsdienst-Management

Hochverfügbarkeitsdienst-Management liefert die Fähigkeit, Hochverfügbarkeits-Cluster-Dienste in einem Red Hat-Cluster zu erstellen und zu managen. Die Schlüsselkomponente für Hochverfügbarkeitsdienst-Management in einem Red Hat-Cluster, rgmanager, implementiert Ausfallsicherung für Standardapplikationen. In einem Red Hat-Cluster wird eine Applikation mit anderen Cluster-Ressourcen konfiguriert, um ein einen Hochverfügbarkeits-Cluster-Dienst zu bilden. Ein Hochverfügbarkeits-Cluster-Dienst kann zur Ausfallsicherung von einem Cluster-Knoten auf einen anderen wechseln, ohne signifikante Unterbrechung für Cluster-Clients. Cluster-Dienst-Ausfallsicherung kann dann in Kraft treten, wenn ein Knoten ausfällt, oder wenn ein Cluster-Systemadministrator den Dienst von einem Cluster-Knoten auf einen anderen verschiebt (beispielsweise für einen geplanten Ausfall eines Cluster-Knotens).
Um einen Hochverfügbarkeitsdienst zu erstellen, müssen Sie diesen in der Cluster-Konfigurationsdatei konfigurieren. Ein Cluster-Dienst besteht aus Cluster-Ressourcen. Cluster-Ressourcen bilden Blöcke, die Sie in der Cluster-Konfigurationsdatei erstellen und verwalten können — beispielsweise eine IP-Adresse, ein Skript zur Initialisierung einer Applikation oder eine via Red Hat GFS gemeinsam genutzte Partition.
You can associate a cluster service with a failover domain. A failover domain is a subset of cluster nodes that are eligible to run a particular cluster service (refer to Abbildung 1.9, „Ausfallsicherungs-Domains“).

Anmerkung

Ausfallsicherungs-Domains werden für den Betrieb nicht benötigt.
Ein Cluster-Dienst kann zur Gewährleistung der Datenintegrität nur auf einem Cluster-Knoten gleichzeitig laufen. Sie können eine Ausfallsicherungspriorität in einer Ausfallsicherungs-Domain angeben. Die Angabe einer solchen Ausfallsicherungspriorität besteht aus der Zuweisung eines Prioritätslevels für jeden Knoten in einer Ausfallsicherungs-Domain. Das Prioritätslevel ermittelt die Reihenfolge der Ausfallsicherung — dabei wird bestimmt, auf welchen Knoten ein Cluster-Dienst im Falle eines Ausfalls wechseln soll. Falls Sie keine Ausfallsicherungspriorität angeben, kann ein Cluster-Dienst im Falle eines Ausfalls auf jeden beliebigen Knoten innerhalb seiner Ausfallsicherungs-Domain wechseln. Auch können Sie angeben, ob ein Cluster-Dienst so eingeschränkt werden soll, dass er nur auf Knoten seiner verknüpften Ausfallsicherungs-Domains läuft. (Ist ein Cluster-Dienst mit einer uneingeschränkten Ausfallsicherungs-Domain verknüpft, kann er auf jedem beliebigen Cluster-Knoten starten für den Fall, dass kein Mitglied der Ausfallsicherungs-Domain zur Verfügung steht.)
In Abbildung 1.9, „Ausfallsicherungs-Domains“, Failover Domain 1 is configured to restrict failover within that domain; therefore, Cluster Service X can only fail over between Node A and Node B. Failover Domain 2 is also configured to restrict failover with its domain; additionally, it is configured for failover priority. Failover Domain 2 priority is configured with Node C as priority 1, Node B as priority 2, and Node D as priority 3. If Node C fails, Cluster Service Y fails over to Node B next. If it cannot fail over to Node B, it tries failing over to Node D. Failover Domain 3 is configured with no priority and no restrictions. If the node that Cluster Service Z is running on fails, Cluster Service Z tries failing over to one of the nodes in Failover Domain 3. However, if none of those nodes is available, Cluster Service Z can fail over to any node in the cluster.
Ausfallsicherungs-Domains

Abbildung 1.9. Ausfallsicherungs-Domains


Abbildung 1.10, „Web Server Cluster Service Example“ shows an example of a high-availability cluster service that is a web server named "content-webserver". It is running in cluster node B and is in a failover domain that consists of nodes A, B, and D. In addition, the failover domain is configured with a failover priority to fail over to node D before node A and to restrict failover to nodes only in that failover domain. The cluster service comprises these cluster resources:
  • IP Adressen-Ressource — IP-Adresse 10.10.10.201.
  • An application resource named "httpd-content" — a web server application init script /etc/init.d/httpd (specifying httpd).
  • A file system resource — Red Hat GFS named "gfs-content-webserver".
Web Server Cluster Service Example

Abbildung 1.10. Web Server Cluster Service Example


Clients greifen auf den Cluster-Dienst via IP-Adresse 10.10.10.201 zu, was eine Interaktion mit der Web-Server-Applikation, httpd-content, ermöglicht. Die Applikation "httpd-content" verwendet das "gfs-content-webserver"-Dateisystem. Falls der Knoten B ausfallen sollte, würde der Cluster-Dienst "content-webserver" auf Knoten D wechseln. Falls Knoten D nicht verfügbar sein sollte, oder auch ausgefallen ist, würde der Dienst auf Knoten A wechseln. Es läge eine Ausfallsicherung ohne nennenswerte Unterbrechung für andere Cluster-Clients vor. Der Cluster-Dienst wäre von einem anderen Cluster-Knoten aus unter derselben IP-Adresse erreichbar, wie vor der Ausfallsicherung.

1.5. Red Hat GFS

Red Hat GFS ist ein Cluster-Dateisystem, das einem Cluster aus Knoten ermöglicht, gleichzeitig auf ein Blockgerät zuzugreifen, welches von allen Knoten gemeinsam genutzt wird. GFS ist ein ursprüngliches Dateisystem, das eine direkte Schnittstelle zur VFS-Schicht der Dateisystem-Schnittstelle des Linux-Kernels bietet. GFS setzt verteilte Metadaten und mehrfache Journals für den optimalen Betrieb in einem Cluster ein. Um die Integrität des Dateisystems zu gewährleisten, verwendet GFS einen Lock-Manager, um I/O zu koordinieren. Wenn ein Knoten Daten auf einem GFS-Dateisystem ändert, wird diese Änderung umgehend ersichtlich für andere Cluster-Knoten, die dieses Dateisystem verwenden.
Indem Sie Red Hat GFS verwenden, können Sie eine maximale Laufzeit einer Applikation durch die folgenden Vorteile erreichen:
  • Vereinfachung Ihrer Daten-Infrastruktur
    • Installation und Fehlerbehebung von Applikationen für das gesamte Cluster.
    • Der Bedarf redundanter Kopien von Applikationsdaten (Duplikation) wird eliminiert.
    • Paralleler Lese-/Schreib-Zugriff auf Daten durch viele Clients wird ermöglicht.
    • Backup und Notfallsicherung wird vereinfacht (nur ein Dateisystem muss gesichert oder wiederhergestellt werden).
  • Die Verwendung von Speicherressourcen wird maximiert, was die Administrationskosten gleichzeitig minimiert.
    • Speicher kann als Ganzes verwaltet werden, anstatt pro Partition.
    • Verringerung der gesamten Speicheranforderungen durch das Eliminieren von Datenreplikationen.
  • Nahtlose Skalierung des Clusters durch Hinzufügen von Servern oder Speicher im laufenden Betrieb.
    • Kein Partitionierungsspeicher mehr durch komplizierte Techniken.
    • Hinzufügen von Servern zum Cluster im laufenden Betrieb durch das Einhängen in das allgemeine Dateisystem.
Knoten, auf denen Red Hat GFS läuft, werden mit den Konfigurations- und Management-Tools der Red Hat Cluster Suite verwaltet. Datenträger-Management wird vom CLVM (Cluster Logical Volume Manager) verwaltet. Red Hat GFS bietet das gemeinsame Nutzen von Daten zwischen GFS-Knoten in einem Red Hat-Cluster. GFS stellt einen einfache, konsistente Ansicht des Namenraums des Dateisystems der gesamten GFS-Knoten in einem Red Hat-Cluster zur Verfügung. GFS erlaubt das Installieren und Ausführen von Applikationen ohne großer Kenntnis der darunterliegenden Speicher-Infrastruktur. Auch bietet GFS Features, die typischerweise in einer Unternehmensumgebung benötigt werden, wie Quotas, mehrere Journals und Unterstützung von "multipath".
GFS liefert eine vielseitige Methode für Netzwerkspeicher je nach den Anforderungen Ihrer Speicherumgebung hinsichtlich Leistungsfähigkeit, Skalierbarkeit und Wirtschaftlichkeit. Dieses Kapitel liefert einige grundlegende Informationen in gekürzter Fassung als Hintergrund, um Ihnen beim Verständnis von GFS behilflich zu sein.
You can deploy GFS in a variety of configurations to suit your needs for performance, scalability, and economy. For superior performance and scalability, you can deploy GFS in a cluster that is connected directly to a SAN. For more economical needs, you can deploy GFS in a cluster that is connected to a LAN with servers that use GNBD (Global Network Block Device) or to iSCSI (Internet Small Computer System Interface) devices. (For more information about GNBD, refer to Abschnitt 1.7, „Global Network Blockgerät“.)
Die folgenden Abschnitte liefern Beispiele, wie GFS eingesetzt werden kann, um Ihren Anforderungen hinsichtlich Leistung, Skalierbarkeit und Wirtschaftlichkeit gerecht zu werden:

Anmerkung

Die GFS-Einsatzbeispiele spiegeln Grundkonfigurationen wider. Ihre Anforderungen erfordern ggf. eine Kombination der in diesen Beispielen gezeigten Konfigurationen.

1.5.1. Höhere Leistung und Skalierbarkeit

You can obtain the highest shared-file performance when applications access storage directly. The GFS SAN configuration in Abbildung 1.11, „GFS with a SAN“ provides superior file performance for shared files and file systems. Linux applications run directly on cluster nodes using GFS. Without file protocols or storage servers to slow data access, performance is similar to individual Linux servers with directly connected storage; yet, each GFS application node has equal access to all data files. GFS supports over 300 GFS nodes.
GFS with a SAN

Abbildung 1.11. GFS with a SAN


1.5.2. Leistung, Skalierbarkeit, Angemessener Preis

Multiple Linux client applications on a LAN can share the same SAN-based data as shown in Abbildung 1.12, „GFS and GNBD with a SAN“. SAN block storage is presented to network clients as block storage devices by GNBD servers. From the perspective of a client application, storage is accessed as if it were directly attached to the server in which the application is running. Stored data is actually on the SAN. Storage devices and data can be equally shared by network client applications. File locking and sharing functions are handled by GFS for each network client.
GFS and GNBD with a SAN

Abbildung 1.12. GFS and GNBD with a SAN


1.5.3. Wirtschaftlichkeit und Leistung

Abbildung 1.13, „GFS und GNBD mit direkt angehängtem Speicher“ shows how Linux client applications can take advantage of an existing Ethernet topology to gain shared access to all block storage devices. Client data files and file systems can be shared with GFS on each client. Application failover can be fully automated with Red Hat Cluster Suite.
GFS und GNBD mit direkt angehängtem Speicher

Abbildung 1.13. GFS und GNBD mit direkt angehängtem Speicher


1.6. Cluster Logical-Volume-Manager

Der Cluster Logical Volume Manager (CLVM) stellt eine clusterweite Version von LVM2 zur Verfügung. CLVM bietet dieselben Fähigkeiten wie LVM2 auf einem einzelnen Knoten, stellt jedoch die Datenträger allen Knoten in einem Red Hat-Cluster zur Verfügung. Die mit CLVM erstellten logischen Datenträger stellen allen Knoten in einem Cluster logische Datenträger zur Verfügung.
The key component in CLVM is clvmd. clvmd is a daemon that provides clustering extensions to the standard LVM2 tool set and allows LVM2 commands to manage shared storage. clvmd runs in each cluster node and distributes LVM metadata updates in a cluster, thereby presenting each cluster node with the same view of the logical volumes (refer to Abbildung 1.14, „CLVM Overview“). Logical volumes created with CLVM on shared storage are visible to all nodes that have access to the shared storage. CLVM allows a user to configure logical volumes on shared storage by locking access to physical storage while a logical volume is being configured. CLVM uses the lock-management service provided by the cluster infrastructure (refer to Abschnitt 1.3, „Cluster Infrastructure“).

Anmerkung

Die Verwendung von gemeinsam genutzter Speicher im Rahmen der Red Hat Cluster Suite setzt voraus, dass der Cluster Logical Volume Manager Daemon (clvmd) oder die High Availability Logical Volume Management Agenten (HA-LVM) ausgeführt werden. Falls Sie aus betrieblichen Gründen oder aufgrund unzureichender Berechtigungen weder den clvmd-Daemon, noch HA-LVM besitzen, dürfen Sie kein Single-Instance-LVM auf den gemeinsam genutzten Platten einsetzen, da dies zu korrumpierten Daten führen kann. Falls Sie Bedenken haben, setzen Sie sich bitte mit einem Red Hat Service-Vertreter in Verbindung.

Anmerkung

Bei der Verwendung von CLVM sind geringe Anpassungen an /etc/lvm/lvm.conf für clusterweites Locking (Dateisperren) erforderlich.
CLVM Overview

Abbildung 1.14. CLVM Overview


You can configure CLVM using the same commands as LVM2, using the LVM graphical user interface (refer to Abbildung 1.15, „LVM Graphical User Interface“), or using the storage configuration function of the Conga cluster configuration graphical user interface (refer to Abbildung 1.16, „Conga LVM Graphical User Interface“) . Abbildung 1.17, „Creating Logical Volumes“ shows the basic concept of creating logical volumes from Linux partitions and shows the commands used to create logical volumes.
LVM Graphical User Interface

Abbildung 1.15. LVM Graphical User Interface


Conga LVM Graphical User Interface

Abbildung 1.16. Conga LVM Graphical User Interface


Creating Logical Volumes

Abbildung 1.17. Creating Logical Volumes


1.7. Global Network Blockgerät

Global Network Block Device (GNBD) bietet einen Zugriff auf Blockgeräte für Red Hat GFS via TCP/IP. GNBD entspricht vom Konzept her NBD, ist jedoch GFS-spezifisch und ausschließlich für die Verwendung mit GFS optimiert. GNBD ist sinnvoll, falls Anforderungen für robustere Technologien — Fibre-Channel oder Single-Initiator-SCSI — nicht notwendig oder aus Kostengründen ausgeschlossen sind.
GNBD consists of two major components: a GNBD client and a GNBD server. A GNBD client runs in a node with GFS and imports a block device exported by a GNBD server. A GNBD server runs in another node and exports block-level storage from its local storage (either directly attached storage or SAN storage). Refer to Abbildung 1.18, „GNBD Überblick“. Multiple GNBD clients can access a device exported by a GNBD server, thus making a GNBD suitable for use by a group of nodes running GFS.
GNBD Überblick

Abbildung 1.18. GNBD Überblick


1.8. Linux Virtual Server

Linux Virtual Server (LVS) ist ein Set integrierter Software-Komponenten für das gleichmäßige Verteilen von IP-Load innerhalb einer Gruppe realer Server. LVS läuft auf einem Paar gleich konfigurierter Computer: Ein Computer, der einen aktiven LVS-Router darstellt und ein Computer, der als ein Backup-LVS-Router agiert. Der aktive LVS-Router erfüllt zwei Rollen:
  • Gleichmäßige Verteilung der Auslastung unter den realen Servern.
  • Überprüfung der Integrität der Dienste auf jedem realen Server.
Der Backup-LVS-Router überwacht den aktiven LVS-Router und übernimmt dessen Aufgaben im Falle eines Ausfalls.
Abbildung 1.19, „Components of a Running LVS Cluster“ provides an overview of the LVS components and their interrelationship.
Components of a Running LVS Cluster

Abbildung 1.19. Components of a Running LVS Cluster


Der pulse-Daemon läuft sowohl auf den aktiven als auch den passiven LVS-Routern. Auf dem Backup-LVS-Router sendet pulse einen heartbeat an die öffentliche Schnittstelle des aktiven Router, um sicherzustellen, dass der aktive LVS-Router ordnungsgemäß funktioniert. Auf dem aktiven LVS-Router startet pulse den lvs-Daemon und reagiert auf heartbeat-Anfragen des Backup-LVS-Routers.
Sobald er gestartet wird, ruft der lvs-Daemon das ipvsadm-Dienstprogramm auf, um die IPVS (IP Virtual Server) Routing-Tabelle im Kernel zu konfigurieren und zu pflegen, und startet einen nanny-Prozess für jeden konfigurierten virtuellen Server auf jedem realen Server. Jeder nanny-Prozess überprüft den Status eines konfigurierten Dienstes auf einem realen Server und unterrichtet den lvs-Daemon darüber, ob der Dienst auf diesem realen Server nicht korrekt funktioniert. Falls eine Fehlfunktion entdeckt wird, weist der lvs-Daemon ipvsadm an, diesen realen Server aus der IPVS-Routing-Tabelle zu entfernen.
Falls der Backup-LVS-Router keine Antwort vom aktiven LVS-Router erhält, leitet er eine Ausfallsicherung ein, indem er send_arp aufruft, alle virtuellen IP-Adressen den NIC Hardware-Adressen (MAC Adressen) des Backup-LVS-Router neu zuzuweisen. Weiterhin sendet er einen Befehl an den aktiven LVS-Router, sowohl durch die öffentliche, als auch die private Netzwerkschnittstelle, den lvs-Daemon auf dem aktiven LVS-Router zu beenden, und startet den lvs-Daemon auf dem Backup-LVS-Router, um Anfragen für die konfigurierten virtuellen Server zu akzeptieren.
Für einen außenstehenden Benutzer, der auf einen gehosteten Dienst zugreift (wie einer Website oder Datenbankapplikation), erscheint LVS als ein Server. Tatsächlich greift der Benutzer jedoch auf reale Server hinter den LVS-Routern zu.
Da es keine integrierte Komponente in LVS gibt, um Daten unter realen Servern zu verteilen, stehen Ihnen zwei Grundoptionen zur Verfügung:
  • Synchronisation der Daten unter den realen Servern.
  • Hinzufügen einer dritten Ebene zur Topologie für den Zugriff auf gemeinsam genutzte Daten.
Die erste Option wird vorzugsweise für Server verwendet, die einer großen Anzahl von Benutzern das Hochladen oder Verändern von Daten auf realen Servern untersagt. Falls die realen Server einer großen Anzahl von Benutzern gestatten, Daten zu verändern, wie beispielsweise einer E-Commerce-Website, ist das Hinzufügen einer dritten Schicht besser.
Es gibt viele Möglichkeiten, Daten zwischen realen Servern zu synchronisieren. Sie können zum Beispiel Shell-Skripte verwenden, um aktualisierte Web-Seiten gleichzeitig an reale Server zu schicken. Auch können Sie Programme wie rsync verwenden, um aktualisierte Daten im Rahmen eines bestimmten Intervalls auf allen Knoten zu replizieren. Allerdings funktionieren Skripte in Umgebungen, in denen Benutzer häufig Dateien hochladen oder Datenbank-Transaktionen durchführen, nicht optimal. Aus diesem Grund ist eine three-tiered topology besser geeignet zur Synchronisation von Daten für reale Server, auf die eine große Menge Daten hochgeladen wird oder mit Datenbank-Transaktionen oder ähnlichem Datenverkehr.

1.8.1. Two-Tier LVS Topology

Abbildung 1.20, „Two-Tier LVS Topology“ shows a simple LVS configuration consisting of two tiers: LVS routers and real servers. The LVS-router tier consists of one active LVS router and one backup LVS router. The real-server tier consists of real servers connected to the private network. Each LVS router has two network interfaces: one connected to a public network (Internet) and one connected to a private network. A network interface connected to each network allows the LVS routers to regulate traffic between clients on the public network and the real servers on the private network. In Abbildung 1.20, „Two-Tier LVS Topology“, the active LVS router uses Network Address Translation (NAT) to direct traffic from the public network to real servers on the private network, which in turn provide services as requested. The real servers pass all public traffic through the active LVS router. From the perspective of clients on the public network, the LVS router appears as one entity.
Two-Tier LVS Topology

Abbildung 1.20. Two-Tier LVS Topology


Dienstanfragen, die bei einem LVS-Router ankommen, werden an eine virtuelle IP Adresse oder VIP adressiert. Dies ist eine öffentlich routbare Adresse, die der Administrator einer Site mit einem vollständigen Namen einer Domain (FQDN) verknüpft, wie z.B. www.example.com und die einem oder mehreren virtuellen Servern zugewiesen wird.[1]. Beachten Sie bitte, dass eine VIP-Adresse während einer Ausfallsicherung von einem LVS-Router auf den anderen migriert und auf diese Weise eine Präsenz auch weiterhin unter dieser IP-Adresse gewährleistet ist. Dies ist auch als Floating IP-Adressen bekannt.
VIP-Adressen können eine Alias-Bezeichnung mit demselben Gerät erhalten, welches den LVS-Router mit dem öffentlichen Netzwerk verbindet. Wenn zum Beispiel eth0 mit dem Internet verbunden ist, dann können mehrere virtuelle Server eine Alias-Bezeichnung eth0:1 erhalten. Alternativ kann jeder virtuelle Server mit einem separaten Gerät pro Dienst verknüpft werden. Beispielsweise kann HTTP-Datenverkehr auf eth0:1 und FTP-Datenverkehr auf eth0:2 verwaltet werden.
Nur jeweils ein LVS-Router ist aktiv. Die Aufgabe des aktiven LVS-Routers ist es, Dienstanfragen von virtuellen IP-Adressen an die realen Server umzuleiten. Die Umleitung basiert auf einem von acht Algorithmen für den Lastverteilung:
  • Round-Robin-Scheduling — Verteilt jede Anfrage nacheinander in einen Pool von realen Servern. Bei der Verwendung dieses Algorithmus werden alle realen Server als gleichwertig behandelt, ohne Rücksicht auf deren Kapazität oder Auslastung.
  • Gewichtetes Round-Robin-Scheduling — Verteilt jede Anfrage nacheinander in einem Pool von realen Servern, teilt jedoch Servern mit einer höheren Kapazität mehr Jobs zu. Die Kapazität wird durch einen durch einen Benutzer zugewiesenen Gewichtungsfaktor angezeigt, der dann durch eine dynamische Auslastungsinformation entweder nach oben oder unten korrigiert wird. Dies ist die bevorzugte Wahl falls signifikante Unterschiede der Kapazität von realen Servern in einem Server-Pool vorliegen. Wenn die Last durch Anfragen jedoch dramatisch variiert, kann ein stark gewichteter Server ggf. mehr Anfragen beantworten, als ihm zugeteilt sind.
  • Least-Connection — Verteilt mehr Anfragen an reale Server mit weniger aktiven Verbindungen. Dies ist ein dynamischer Scheduling-Algorithmus-Typ und stellt eine bessere Wahl dar, falls eine hohes Maß an Abweichung in der Anfragelast vorliegt. Es ist am besten für einen Pool von realen Server geeignet, in dem jeder Server-Knoten in etwa dieselbe Kapazität besitzt. Falls die realen Server unterschiedliche Kapazitäten besitzen, ist das gewichtete Least-Connection-Scheduling die bessere Wahl.
  • Gewichtete Least-Connections (Standard) — Verteilt mehrere Anfragen an Server mit weniger aktiven Verbindungen in Relation zu ihrer Kapazität. Die Kapazität wird durch eine benutzerdefinierte Gewichtung angezeigt, welche dann wiederum je nach dynamischer Lastinformation nach oben oder unten korrigiert wird. Der Zusatz der Gewichtung macht diesen Algorithmus zu einer idealen Alternative, wenn der Pool der realen Server aus Hardware mit unterschiedlichen Kapazitäten besteht.
  • Locality-Based Least-Connection Scheduling — Verteilt mehrere Anfragen an Server mit weniger aktiven Verbindungen in Relation zu ihren Ziel-IPs. Dieser Algorithmus ist für den Einsatz in einem Proxy-Cache-Server-Cluster gedacht. Er routet die Pakete für eine IP-Adresse solange an den Server für diese Adresse, bis dieser Server seine Kapazitätsgrenze überschreitet und einen Server mit dessen halber Last vorliegen hat. In diesem Fall weist er die IP-Adresse einem realen Server mit der geringsten Auslastung zu.
  • Locality-Based Least-Connection Scheduling mit Replication Scheduling — Verteilt mehr Anfragen an Server mit weniger aktiven Verbindungen in Relation zu ihren Ziel-IPs. Dieser Algorithmus ist auch für den Einsatz in einem Proxy-Cache-Server-Cluster gedacht. Es unterscheidet sich vom Locality-Based Least-Connection Scheduling durch das Zuordnen der Ziel-IP-Adresse zu einer Teilmenge von realer Server-Knoten. Anfragen werden anschließend zum Server in dieser Teilmenge mit der niedrigsten Anzahl an Verbindungen geroutet. Falls alle Knoten für die Ziel-IP über der Kapazität liegen, repliziert er einen neuen Server für diese Ziel-IP-Adresse, indem er den realen Server mit den wenigsten Verbindungen aus dem gesamten Pool der realen Server zur Teilmenge der realen Server für diese Ziel-IP hinzufügt. Der Knoten mit der höchsten Last wird dann aus der Teilmenge der realen Server entfernt, um eine Überreplikation zu verhindern.
  • Source-Hash-Scheduling — Verteilt Anfragen an den Pool realer Server, in dem er die Quell-IP in einer statischen Hash-Tabelle sucht. Dieser Algorithmus ist für LVS-Router mit mehreren Firewalls gedacht.
Auch überwacht der aktive LVS-Router dynamisch die Gesamtverfassung der speziellen Dienste auf den realen Servern durch einfache send/expect-Skripte. Als Hilfe bei der Analyse der Verfassung eines Dienstes, der dynamische Daten wie HTTPS oder SSL benötigt, können Sie auch externe ausführbare Dateien aufrufen. Falls ein Dienst auf einem realen Server nicht ordnungsgemäß funktioniert, hört der aktive LVS-Router auf, Jobs an diesen Server zu senden, bis dieser wieder auf normalem Betriebslevel ist.
Der Backup-LVS-Router übernimmt die Rolle eines Systems in Bereitschaft. Die LVS-Router tauschen periodisch Heartbeat-Meldungen durch die primäre externe öffentliche Schnittstelle, und im Falle einer Ausfallsicherung durch die private Schnittstelle aus. Erhält der Backup-LVS-Router keine Heartbeat-Meldung innerhalb eines erwarteten Intervalls, leitet er eine Ausfallsicherung ein und übernimmt die Rolle des aktiven LVS-Routers. Während der Ausfallsicherung übernimmt der Backup-LVS-Router die VIP-Adressen, die vom ausgefallenen Router bereitgestellt wurden, unter Verwendung einer Technik, die als ARP-Spoofing bekannt ist — hier zeigt der Backup-LVS-Router an, dass er das Ziel für IP-Adressen darstellt, die an den ausgefallenen Knoten gerichtet sind. Falls der ausgefallene Knoten wieder aktiv wird, nimmt der Backup-LVS-Router seine Backup-Rolle wieder auf.
The simple, two-tier configuration in Abbildung 1.20, „Two-Tier LVS Topology“ is suited best for clusters serving data that does not change very frequently — such as static web pages — because the individual real servers do not automatically synchronize data among themselves.

1.8.2. Three-Tier LVS Topology

Abbildung 1.21, „Three-Tier LVS Topology“ shows a typical three-tier LVS configuration. In the example, the active LVS router routes the requests from the public network (Internet) to the second tier — real servers. Each real server then accesses a shared data source of a Red Hat cluster in the third tier over the private network.
Three-Tier LVS Topology

Abbildung 1.21. Three-Tier LVS Topology


Diese Topologie eignet sich gut für gut ausgelastete FTP-Server, bei denen Daten, auf die zugegriffen werden kann, auf einem Hochverfügbarkeits-Server gespeichert werden und auf die von jedem realen Server via einem exportierten NFS-Verzeichnis oder einer Samba-Freigabe zugegriffen wird. Diese Topologie wird außerdem für Websites empfohlen, die auf eine zentrale, Hochverfügbarkeits-Datenbank für Transaktionen zugreifen. Zusätzlich können Sie unter Verwendung einer aktiv-aktiv-Konfiguration in Zusammenhang mit einem Red Hat-Cluster ein Hochverfügbarkeits-Cluster so konfigurieren, dass es diese beiden Rollen gleichzeitig ausübt.

1.8.3. Routing-Methoden

Sie können das Routen via Network Address Translation (NAT) oder direktes Routen via LVS verwenden. Die folgenden Abschnitte beschreiben NAT-Routing und direktes Routen mit LVS kurz.

1.8.3.1. NAT-Routing

Abbildung 1.22, „LVS Implemented with NAT Routing“, illustrates LVS using NAT routing to move requests between the Internet and a private network.
LVS Implemented with NAT Routing

Abbildung 1.22. LVS Implemented with NAT Routing


In dem Beispiel existieren zwei NICs im aktiven LVS-Router. Die NIC für das Internet besitzt eine reale IP-Adresse auf eth0 und eine floating IP-Adresse, mit einem Alias nach eth0:1. Die NIC für die private Netzwerkschnittstelle besitzt eine reale IP-Adresse auf eth1 und eine floating IP-Adresse, mit einem Alias nach eth1:1. Bei einer Ausfallsicherung werden die virtuelle Schnittstelle, die sich zum Internet hin richtet und die nach privat ausgerichtete virtuelle Schnittstelle gleichzeitig vom Backup-LVS-Router übernommen. Alle realen Server im privaten Netzwerk verwenden die floating IP für den NAT-Router als ihre standardmäßige Route, um mit dem aktiven LVS-Router zu kommunizieren, so dass ihre Fähigkeiten, auf Anfragen aus dem Internet zu reagieren, nicht beeinträchtigt werden.
In the example, the LVS router's public LVS floating IP address and private NAT floating IP address are aliased to two physical NICs. While it is possible to associate each floating IP address to its physical device on the LVS router nodes, having more than two NICs is not a requirement.
Bei der Verwendung dieser Topologie erhält der aktive LVS-Router die Anfragen und routet sie an den entsprechenden Server weiter. Der reale Server verarbeitet anschließend die Anfrage und gibt die Pakete an den LVS-Router zurück. Der LVS-Router verwendet Network Address Translation, um die Adresse des realen Servers in den Paketen durch die öffentliche VIP-Adresse der LVS-Router zu ersetzen. Dieser Prozess wird als IP-Masquerading bezeichnet, da die tatsächlichen IP-Adressen der realen Server vor den anfragenden Clients versteckt wird.
Mit Hilfe von NAT-Routing können reale Server beliebige Rechner sein, auf denen eine Vielzahl an Betriebssystemen laufen. Der Hauptnachteil von NAT-Routing ist, dass der LVS-Router in größeren Einsatzszenarien zu einer Art Engpass werden kann, da er ausgehende und eingehende Anfragen verarbeiten muss.

1.8.3.2. Direktes Routing

Direktes Routing bietet den Vorteil einer höheren Leistung im Vergleich zu NAT-Routing. Direktes Routing ermöglicht den realen Servern, Pakete direkt zu verarbeiten und an einen anfragenden Benutzer zu routen, anstatt ausgehende Pakete durch den LVS-Router zu leiten. Direktes Routing vermindert die Wahrscheinlichkeit von Problemen bei der Netzwerkleistung, indem es den Job des LVS-Routers nur auf das Verarbeiten von eingehenden Paketen beschränkt.
LVS Implemented with Direct Routing

Abbildung 1.23. LVS Implemented with Direct Routing


In einer typischen Direktes-Routing-LVS-Konfiguration empfängt ein eingehender Server Anfragen durch eine virtuelle IP (VIP) und verwenden einen Plan-Algorithmus, um die Anfragen an reale Server zu routen. Jeder reale Server verarbeitet Anfragen und senden Antworten direkt an Clients und umgeht dabei die LVS-Routers. Direktes Routing ermöglicht Skalierbarkeit, so dass reale Server hinzugefügt werden können, ohne dass der LVS-Router zusätzlich belastet wird, ausgehende Pakete vom realen Server zum Client zu routen, was bei hoher Netzwerkauslastung zu einem Engpass führen kann.
Auch wenn es viele Vorteile zur Verwendung von direktem Routing in LVS gibt, existieren auch einige Einschränkungen. Das häufigste Problem mit direktem Routing und LVS tritt bei Address Resolution Protocol (ARP) auf.
In typical situations, a client on the Internet sends a request to an IP address. Network routers typically send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP requests are broadcast to all connected machines on a network, and the machine with the correct IP/MAC address combination receives the packet. The IP/MAC associations are stored in an ARP cache, which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations.
Das Problem mit ARP-Anfragen in einer Direkt-Routing-LVS-Konfiguration ist, dass aufgrund der Tatsache, dass eine Client-Anfrage an eine IP-Adresse mit einer MAC-Adresse verknüpft sein muss, damit diese Anfrage behandelt werden kann, die virtuelle IP-Adresse des LVS-Router ebenfalls mit einer MAC verknüpft sein muss. Da aber sowohl der LVS-Router, als auch die realen Server dieselbe VIP besitzen, wird die ARP-Anfrage an alle mit dem VIP verknüpften Knoten verbreitet. Dies kann zu einigen Problemen führen, z.B. dass die VIP direkt mit einem der realen Server verknüpft wird und Anfragen direkt weiterleitet und dabei den LVS-Router komplett umgeht, was den Zweck der LVS-Konfiguration außer Kraft setzt. Das Verwenden eines LVS-Routers mit einer leistungsfähigen CPU, der schnell auf Client-Anfragen eingehen kann, beseitigt dieses Problem nicht notwendigerweise. Falls der LVS-Router unter hoher Auslastung steht, kann er ggf. langsamer auf die ARP-Anfrage reagieren, als ein unterbeschäftigter realer Server, der schneller reagiert und dem die VIP im ARP-Cache des anfragenden Clients zugewiesen wird.
Um dieses Problem zu lösen, sollten die eingehenden Anfragen nur den VIP mit dem LVS-Router verknüpfen, welcher die Anfragen ordnungsgemäß verarbeiten und sie an den Pool der realen Server senden wird. Dies kann mit Hilfe des Tools arptables zur Paketfilterung durchgeführt werden.

1.8.4. Persistenz und Firewall-Markierungen

In bestimmten Situationen kann es wünschenswert sein, dass sich ein Client immer wieder mit demselben realen Server erneut verbindet, anstatt dass ein LVS Lastverteilungs-Algorithmus diese Anfrage an den am besten verfügbaren Server schickt. Beispiele für eine solche Situation umfassen Web-Formulare, die sich über mehrere Bildschirme erstrecken, Cookies, SSL- und FTP-Verbindungen. In diesen Fällen funktioniert ein Client ggf. nicht ordnungsgemäß, bis die Transaktionen von demselben Server behandelt werden, um den Kontext beizubehalten. LVS bietet zwei verschiedene Features, um dies zu handhaben: Persistenz und Firewall Markierungen.

1.8.4.1. Persistence

Sofern aktiviert, agiert die Persistenz wie ein Timer. Wenn sich ein Client mit einem Dienst verbindet, merkt sich LVS die letzte Verbindung für eine angegebene Zeitspanne. Falls sich dieselbe Client-IP-Adresse erneut innerhalb dieser Spanne verbindet, wird es an denselben Server weitergeleitet, mit dem sie sich zuvor bereits verbunden hatte — dabei werden die Mechanismen zum Lastverteilung übergangen. Falls eine Verbindung außerhalb des Zeitfenster zustandekommt, wird sie anhand der Scheduling-Regeln, die gerade in Kraft sind, behandelt.
Persistenz erlaubt Ihnen auch die Angabe einer Subnet-Maske, die für den Test der Client-IP-Adresse angewendet werden kann, als ein Tool zur Kontrolle, welche Adressen ein höheres Level an Persistenz besitzen, so dass Verbindungen mit diesem Subnet gruppiert werden.
Das Gruppieren von Verbindungen, die für verschiedene Ports bestimmt sind, kann für Protokolle von Bedeutung sein, die mehr als einen Port für die Kommunikation verwenden, wie beispielsweise FTP. Allerdings stellt Persistenz nicht die effektivste Art und Weise dar, Probleme mit der Gruppierung von Verbindungen, die für verschiedene Ports bestimmt sind, zu behandeln. Für diese Situationen werden am besten Firewall-Markierungen vewendet.

1.8.4.2. Firewall-Markierungen

Firewall-Markierungen sind eine leichte und effektive Art und Weise, um Ports zu gruppieren, die für ein Protokoll oder eine Gruppe von verwandten Protokollen verwendet werden. Wenn LVS beispielsweise im Rahmen einer E-Commerce-Site eingesetzt wird, können Firewall-Markierungen dazu verwendet werden, HTTP-Verbindungen auf Port 80, sowie sichere HTTPS-Verbindungen auf Port 443 zu bündeln. Indem dieselbe Firewall-Markierung für jedes Protokoll zum virtuellen Servern zugewiesen wird, können Informationen über den Zustand der Transaktion erhalten bleiben, da der LVS-Router alle Anfragen an denselben realen Server weiterleitet, nachdem eine Verbindung geöffnet wurde.
Aufgrund seiner Effizienz und der einfachen Handhabung sollten Administratoren wann immer möglich Firewall-Markierungen zugunsten von Persistenz für Gruppierungsverbindungen verwenden. Allerdings sollten Sie immer noch Persistenz in Verbindung mit Firewall-Markierungen zu den virtuellen Servern hinzufügen um sicherzustellen, dass Clients wieder mit demselben Server für eine angemessene Zeitspanne verbunden werden.

1.9. Cluster Administrations-Tools

Die Red Hat Cluster Suite bietet eine Vielfalt an Tools zur Konfiguration und Verwaltung Ihres Red Hat-Clusters. Dieser Abschnitt liefert einen Überblick über die Administrations-Tools, die im Rahmen der Red Hat Cluster Suite zur Verfügung stehen:

1.9.1. Conga

Conga ist ein integriertes Set von Software-Komponenten, welches zentralisiertes Konfigurieren und Managen von Red Hat-Clustern und Speicher zur Verfügung stellt. Conga bietet die folgenden Haupt-Features:
  • Eine Web-Oberfläche zur Verwaltung von Cluster und Speicher
  • Automatisierter Einsatz von Cluster-Daten und Hilfspakete
  • Einfache Integration in existierende Cluster
  • Kein Bedarf einer erneuten Authentifizierung
  • Integration des Cluster-Status und Protokolldateien
  • Differenzierte Kontrolle über Benutzerberechtigungen
Die primären Komponenten in Conga sind luci und ricci, welche getrennt installiert werden können. luci ist ein Server, der auf einem Computer läuft und mit mehreren Clustern und Computern via ricci kommuniziert. ricci ist ein Agent, der auf jedem Computer läuft (entweder einem Cluster-Mitglied oder einem Standalone-Computer) und der von Conga verwaltet wird.
Auf luci kann via Web-Browser zugegriffen werden. Es stellt drei Hauptfunktionen zur Verfügung, auf die via folgende Reiter zugegriffen werden kann:
  • Homebase — Liefert Tools für das Hinzufügen und Löschen von Computern und Benutzern, sowie das Konfigurieren von Benutzerberechtigungen. Nur ein Systemadministrator darf auf diesen Reiter zugreifen.
  • Cluster — Bietet Tools für das Erstellen und Konfigurieren von Clustern. Jede Instanz von luci listet Cluster auf, die mit luci erstellt wurden. Ein Systemadministrator kann alle auf diesem Reiter aufgelisteten Cluster administrieren. Andere Benutzer können nur Cluster administrieren, für die sie (von einem Administrator zugewiesene) Berechtigungen zur Verwaltung besitzen.
  • Storage — Bietet Tools für die Administration von Speicher von remote aus. Mit den Tools auf diesem Reiter können Sie Speicher auf Computern verwalten, unabhängig davon, ob sie zu einem Cluster gehören, oder nicht.
Um ein Cluster oder Speicher zu administrieren, fügt ein Administrator ein Cluster oder einen Computer zu einem luci-Server hinzu (oder registriert dieses). Wenn ein Cluster oder ein Computer bei luci registriert wird, wird der FQDN-Hostname oder die IP-Adresse auf jedem Computer in einer luci-Datenbank gespeichert.
Sie können die Datenbank von einer luci-Instanz durch eine andere luci-Instanz füllen. Diese Fähigkeit bietet eine Möglichkeit zur Replizierung einer luci Server-Instanz und liefert einen effizienten Pfad zur Aktualisierung und zum Testen. Wenn Sie eine Instanz von luci installieren, ist dessen Datenbank leer. Sie können jedoch Teile oder eine gesamte luci-Datenbank von einem existierenden luci-Server importieren, wenn Sie einen neuen luci-Server einsetzen.
Jede luci-Instanz besitzt einen Benutzer bei der erstmaligen Installation — admin. Nur der Benutzer 'admin' darf Systeme zu einem luci-Server hinzufügen. Auch kann dieser Benutzer zusätzliche Benutzerkonten erstellen und festlegen, welche Benutzer auf Cluster und Computer, die in der luci-Datenbank registriert sind, zugreifen dürfen. Es ist möglich, Benutzer im Rahmen einer Batch-Operation in einen neuen luci-Server zu importieren, genauso wie Cluster und Computer.
Wenn ein Computer zu einem luci-Server hinzugefügt wird, um administriert zu werden, wird die Authentifizierung einmal durchgeführt. Ab dann ist keine Authentifizierung mehr notwendig (bis das verwendete Zertifikat von einer CA für ungültig erklärt wird). Danach können Sie Cluster und Speicher von remote aus via luci Benutzeroberfläche konfigurieren und verwalten. luci und ricci kommunizieren untereinander via XML.
Die folgende Abbildung zeigt Beispielanzeigen der drei Haupt-luci-Reiter: Homebase, Cluster, und Storage.
Werfen Sie einen Blick auf Konfiguration und Verwaltung eines Red Hat Clusters und die Online-Hilfe für den ricci-Server für weitere Informationen zu Conga.
luci Homebase-Reiter

Abbildung 1.24. luci Homebase-Reiter


luci Cluster-Reiter

Abbildung 1.25. luci Cluster-Reiter


luci Storage-Reiter

Abbildung 1.26. luci Storage-Reiter


1.9.2. Cluster Administrations-GUI

This section provides an overview of the system-config-cluster cluster administration graphical user interface (GUI) available with Red Hat Cluster Suite. The GUI is for use with the cluster infrastructure and the high-availability service management components (refer to Abschnitt 1.3, „Cluster Infrastructure“ and Abschnitt 1.4, „Hochverfügbarkeitsdienst-Management“). The GUI consists of two major functions: the Cluster Configuration Tool and the Cluster Status Tool. The Cluster Configuration Tool provides the capability to create, edit, and propagate the cluster configuration file (/etc/cluster/cluster.conf). The Cluster Status Tool provides the capability to manage high-availability services. The following sections summarize those functions.

1.9.2.1. Cluster Configuration Tool

You can access the Cluster Configuration Tool (Abbildung 1.27, „Cluster Configuration Tool) through the Cluster Configuration tab in the Cluster Administration GUI.
Cluster Configuration Tool

Abbildung 1.27. Cluster Configuration Tool


Das Cluster Configuration Tool repräsentiert Cluster-Konfigurations-Komponenten in der Konfigurationsdatei (/etc/cluster/cluster.conf) mit einer hierarchischen grafischen Anzeige im linken Panel. Ein dreieckiges Symbol links neben dem Namen einer Komponente zeigt an, dass der Komponente eine oder mehrere untergeordnete Komponenten zugewiesen sind. Ein Klick auf das dreieckige Symbol klappt dem Teilbereich eines Verzeichnisbaums unterhalb einer Komponente auf und zu. Die im GUI angezeigten Komponenten können wie folgt zusammengefasst werden:
  • Cluster Nodes — Zeigt Cluster-Knoten an. Knoten werden durch ihren Namen als untergeordnete Elemente unter Cluster Nodes dargestellt. Mit Hilfe von Konfigurationsschaltflächen am unteren Ende des rechten Frames (unterhalb von Properties können Sie Knoten hinzufügen, löschen und deren Eigenschaften bearbeiten und Fencing-Methoden für jeden Knoten konfigurieren.
  • Fence Devices — Zeigt Fence-Geräte an. Fence-Geräte werden durch untergeordnete Elemente unter Fence Devices dargestellt. Mit Hilfe von Konfigurationsschaltflächen am unteren Ende des rechten Frames (unterhalb von Eigenschaften können Sie Fence-Geräte hinzufügen, löschen und deren Eigenschaften bearbeiten. Fence-Geräte müssen definiert werden, bevor Sie Fencing (mit der Schaltfläche Manage Fencing For This Node) für jeden Knoten konfigurieren können.
  • Managed Resources — Zeigt Ausfallsicherungs-Domains, Ressourcen und Dienstes an.
    • Failover Domains — Zur Konfiguration von einem oder mehreren Subsets von Cluster-Knoten, die dazu verwendet werden, einen Hochverfügbarkeitsservice im Falle eines Ausfalls eines Knotens auszuführen. Ausfallsicherungs-Domains werden als untergeordnete Elemente unter Failover Domains dargestellt. Mit Hilfe von Konfigurationsschaltflächen am unteren Ende des rechten Frames (unterhalb von Properties können Sie Ausfallsicherungs-Domains hinzufügen (wenn Failover Domains ausgewählt ist) oder die Eigenschaften von Ausfallsicherungs-Domains bearbeiten (wenn eine Failover Domain ausgewählt ist).
    • Resources — Zur Konfiguration von gemeinsam genutzten Ressourcen, die von Hochverfügbarkeitsdienste verwendet werden sollen. Gemeinsam genutzte Ressourcen bestehen aus Dateisystemen, IP-Adressen, NFS-Einhängepunkten und -Exporte und von Benutzern erstellte Skripte, die jedem beliebigen Hochverfügbarkeitsdienst in dem Cluster zur Verfügung stehen. Ressourcen werden als untergeordnete Elemente unter Resources dargestellt. Mit Hilfe von Konfigurationsschaltflächen am unteren Ende des rechten Frames (unterhalb von Properties können Sie Ressourcen erstellen (wenn Resources ausgewählt ist) oder die Eigenschaften von Ressourcen bearbeiten (wenn eine Ressource ausgewählt ist).

      Anmerkung

      Das Cluster Configuration Tool bietet auch die Fähigkeit zur Konfiguration privater Ressourcen. Eine private Ressource ist eine Ressource, die zur Verwendung von lediglich einem Dienst konfiguriert wird. Sie können eine private Ressource im Rahmen einer Dienst-Komponente im GUI konfigurieren.
    • Services — Zur Erstellung und Konfiguration von Hochverfügbarkeitsdiensten. Ein Dienst wird konfiguriert, indem Ressourcen zugewiesen werden (gemeinsam genutzte oder private), eine Ausfallsicherungs-Domain zugewiesen wird und eine Richtlinie zur Wiederherstellung des Dienstes definiert wird. Dienste werden als untergeordnete Elemente unter Services dargestellt. Mit Hilfe der Konfigurationsschaltflächen im unteren Bereich des rechten Frames (unterhalb von Properties) können Sie Dienste erstellen (wenn Services ausgewählt ist), oder die Diensteigenschaften bearbeiten (wenn ein Dienst ausgewählt ist).

1.9.2.2. Cluster Status Tool

You can access the Cluster Status Tool (Abbildung 1.28, „Cluster Status Tool) through the Cluster Management tab in Cluster Administration GUI.
Cluster Status Tool

Abbildung 1.28. Cluster Status Tool


Die im Cluster Status Tool dargestellten Knoten und Dienste werden in der Cluster-Konfigurationsdatei (/etc/cluster/cluster.conf) bestimmt. Sie können das Cluster Status Tool verwenden, um einen Hochverfügbarkeitsdienst zu aktivieren, zu deaktivieren, neuzustarten oder zu verschieben.

1.9.3. Administrationstools für die Kommandozeile

In addition to Conga and the system-config-cluster Cluster Administration GUI, command line tools are available for administering the cluster infrastructure and the high-availability service management components. The command line tools are used by the Cluster Administration GUI and init scripts supplied by Red Hat. Tabelle 1.1, „Kommandozeilentools“ summarizes the command line tools.

Tabelle 1.1. Kommandozeilentools

Kommandozeilentool Wird verwendet mit Zweck
ccs_tool — Cluster Configuration System Tool Cluster Infrastructure ccs_tool ist ein Programm zur Durchführung von Online-Aktualisierungen an der Cluster-Konfigurationsdatei. Es bietet die Fähigkeit, Cluster-Infrastruktur-Komponenten zu erstellen und zu modifizieren (zum Beispiel, Erstellen eines Clusters, Hinzufügen und Entfernen eines Knotens). Für weitere Informationen zu diesem Tool, werfen Sie einen Blick auf die Handbuchseite von ccs_tool(8).
cman_tool — Cluster Management Tool Cluster Infrastructure cman_tool ist ein Programm, dass den CMAN-Cluster-Manager verwaltet. Es bietet die Fähigkeit, einem Cluster beizutreten, es zu verlassen, einen Knoten zu entfernen oder die erwarteten Quorum-Stimmen eines Knotens in einem Cluster verändern. Für weitere Informationen, werfen Sie einen Blick auf die cman_tool(8) Handbuchseite.
fence_tool — Fence-Tool Cluster Infrastructure fence_tool ist ein Programm, das dazu verwendet wird, der Standard-Fence-Domain beizutreten oder sie zu verlassen. Speziell startet es den Fence-Daemon (fenced), um der Domain beizutreten und beendet den fenced, um die Domain zu verlassen. Für weitere Informationen, werfen Sie einen Blick auf die fence_tool(8) Handbuchseite.
clustat — Cluster Status Dienstprogramm Hochverfügbarkeitsdienst-Management-Komponenten Der Befehl clustat zeigt den Status des Clusters an. Es zeigt Informationen über Zugehörigkeiten, Quorum-Anzeige und den Zustand aller konfigurierten Benutzerdienste. Für weitere Informationen, werfen Sie einen Blick auf die clustat(8) Handbuchseite.
clusvcadm — Cluster User Service Administration Dienstprogramm Hochverfügbarkeitsdienst-Management-Komponenten Der Befehl clusvcadm ermöglicht Ihnen, Hochverfügbarkeitsdienste in einem Cluster zu aktivieren, zu deaktivieren, zu verschieben und neuzustarten. Für weitere Informationen, werfen Sie einen Blick auf die clusvcadm(8) Handbuchseite.

1.10. Linux Virtual Server Administrations-GUI

Dieser Abschnitt liefert einen Überblick über das LVS-Konfigurationstool, das im Rahmen der Red Hat Cluster Suite zur Verfügung steht — Piranha Configuration Tool. Das Piranha Configuration Tool ist eine grafische Benutzeroberfläche (GUI) für den Web-Browser, die eine strukturierte Methode für das Erstellen der Konfigurationsdatei für LVS liefert — /etc/sysconfig/ha/lvs.cf.
Um auf das Piranha Configuration Tool zuzugreifen, muss der Dienst piranha-gui auf dem aktiven LVS-Router laufen. Sie können auf das Piranha Configuration Tool lokal oder von remote aus mit einem Web-Browser zugreifen. Unter der URL http://localhost:3636 erreichen sie das Tool lokal. Von remote aus erreichen Sie das Tool durch die Eingabe von entweder des Hostnamens oder der realen IP-Adresse, gefolgt von :3636. Wenn Sie von remote aus auf das Piranha Configuration Tool zugreifen, benötigen Sie eine ssh-Verbindung als Root-Benutzer mit dem aktiven LVS-Router.
Starting the Piranha Configuration Tool causes the Piranha Configuration Tool welcome page to be displayed (refer to Abbildung 1.29, „The Welcome Panel“). Logging in to the welcome page provides access to the four main screens or panels: CONTROL/MONITORING, GLOBAL SETTINGS, REDUNDANCY, and VIRTUAL SERVERS. In addition, the VIRTUAL SERVERS panel contains four subsections. The CONTROL/MONITORING panel is the first panel displayed after you log in at the welcome screen.
The Welcome Panel

Abbildung 1.29. The Welcome Panel


Die folgenden Abschnitte bieten eine kurze Beschreibung der Konfigurationsseiten des Piranha Configuration Tool.

1.10.1. CONTROL/MONITORING

Das Panel CONTROL/MONITORING zeigt den Laufzeit-Status an. Es stellt den Status des pulse-Daemons, der LVS-Routing-Tabelle und der von LVS erzeugten nanny-Prozesse dar.
The CONTROL/MONITORING Panel

Abbildung 1.30. The CONTROL/MONITORING Panel


Auto update
Aktiviert das automatische Aktualisieren der Statusanzeige zu einem vom Benutzer konfigurierten Intervall, das im Textfeld Update frequency in seconds (der Standardwert ist 10 Sekunden).
Es wird nicht empfohlen, die automatische Aktualisierung auf einen Zeitintervall von weniger als 10 Sekunden zu setzen. Andernfalls kann es problematisch werden, das Zeitintervall für die Auto update neu zu konfigurieren, da die Seite zu schnell neu lädt. Falls Sie dieses Problem haben, klicken Sie einfach auf ein anderes Panel und dann zurück auf CONTROL/MONITORING.
Update information now
Bietet eine manuelle Aktualisierung der Statusinformationen.
CHANGE PASSWORD
Ein Klick auf diese Schaltfläche führt Sie zu einer Hilfeseite mit Informationen, wie Sie das administrative Passwort für das Piranha Configuration Tool ändern können.

1.10.2. GLOBAL SETTINGS

The GLOBAL SETTINGS panel is where the LVS administrator defines the networking details for the primary LVS router's public and private network interfaces.
The GLOBAL SETTINGS Panel

Abbildung 1.31. The GLOBAL SETTINGS Panel


The top half of this panel sets up the primary LVS router's public and private network interfaces.
Primary server public IP
Die öffentlich routbare reale IP-Adresse für den primären LVS-Knoten.
Primary server private IP
Die reale IP-Adresse für eine alternative Netzwerkschnittstelle auf dem primären LVS-Knoten. Diese Adresse wird ausschließlich als alternativer Heartbeat-Channel für den Backup-Router verwendet.
Use network type
Wählt NAT-Routing aus.
The next three fields are specifically for the NAT router's virtual network interface connected the private network with the real servers.
NAT Router IP
Die private floating IP in diesem Textfeld. Diese floating IP sollte als das Gateway für die realen Server verwendet werden.
NAT Router netmask
If the NAT router's floating IP needs a particular netmask, select it from drop-down list.
NAT Router device
Definiert den Gerätenamen der Netzwerkschnittstelle für die floating IP-Adresse, wie z.B. eth1:1.

1.10.3. REDUNDANCY

Das Panel REDUNDANCY ermöglicht Ihnen die Konfiguration des Backup-LVS-Router-Knotens und das einstellen verschiedener Heartbeat-Überwachungsoptionen.
The REDUNDANCY Panel

Abbildung 1.32. The REDUNDANCY Panel


Redundant server public IP
Die öffentliche reale IP-Adresse für den Backup-LVS-Router.
Redundant server private IP
The backup router's private real IP address.
Der Rest des Panels ist zur Konfiguration des Heartbeat-Channels, welcher vom Backup-Knoten verwendet wird, um den primären Knoten auf Ausfall zu überwachen.
Heartbeat Interval (seconds)
Stellt die Anzahl an Sekunden zwischen Heartbeats ein — Das Zeitintervall, im Rahmen dessen der Backup-Knoten den funktionalen Status des primären LVS-Knoten überprüft.
Assume dead after (seconds)
Falls der primäre LVS-Knoten nicht nach dieser Anzahl an Sekunden antwortet, leitet der Backup-LVS-Knoten die Ausfallsicherung ein.
Heartbeat runs on port
Stellt den Port ein, auf dem Heartbeat mit dem primären LVS-Knoten kommuniziert. Der Standardwert ist auf 539 eingestellt, falls dieses Feld leer gelassen wird.

1.10.4. VIRTUAL SERVERS

Das Panel VIRTUAL SERVERS zeigt Informationen zu jedem derzeit definierten virtuellen Server an. Jeder Tabelleneintrag zeigt den Status des virtuellen Servers, dessen Namen, die dem Server zugeteilte virtuelle IP, die Netzmaske der virtuellen IP, die Portnummer, auf der der Dienst kommuniziert, das verwendete Protokoll und die Schnittstelle des virtuellen Geräts.
The VIRTUAL SERVERS Panel

Abbildung 1.33. The VIRTUAL SERVERS Panel


Jeder Server, der im Panel VIRTUAL SERVERS angezeigt wird, kann auf den nachfolgenden Bildschirmen oder Unterabschnitten konfiguriert werden.
Um einen Dienst hinzuzufügen, klicken Sie auf die Schaltfläche ADD. Um einen Dienst zu entfernen, wählen Sie diesen aus, indem Sie auf das Auswahlsymbol neben dem virtuellen Server und dann auf die Schaltfläche DELETE klicken.
Um einen virtuellen Server in der Tabelle zu aktivieren oder zu deaktivieren, klicken Sie auf dessen Auswahlsymbol und anschließend auf die Schaltfläche (DE)ACTIVATE.
Nach Hinzufügen eines virtuellen Servers, können Sie diesen konfigurieren, indem Sie auf das Auswahlsymbol links daneben und anschließend auf die Schaltfläche EDIT klicken, um den Unterabschnitt VIRTUAL SERVER anzuzeigen.

1.10.4.1. Der Unterabschnitt VIRTUAL SERVER

The VIRTUAL SERVER subsection panel shown in Abbildung 1.34, „The VIRTUAL SERVERS Subsection“ allows you to configure an individual virtual server. Links to subsections related specifically to this virtual server are located along the top of the page. But before configuring any of the subsections related to this virtual server, complete this page and click on the ACCEPT button.
The VIRTUAL SERVERS Subsection

Abbildung 1.34. The VIRTUAL SERVERS Subsection


Name
Ein aussagekräftiger Name zur Identifizierung des virtuellen Server. Dieser Name ist nicht der Hostname für die Maschine und sollte daher veranschaulichend und einfach identifizierbar sein. Sie können sogar das Protokoll angeben, das vom virtuellen Server verwendet werden soll, wie zum Beispiel HTTP.
Application port
Die Portnummer, auf der die Dienst-Applikation horcht.
Protocol
Bietet eine Wahl zwischen UDP oder TCP, in einem Drop-Down-Menü.
Virtual IP Address
The virtual server's floating IP address.
Virtual IP Network Mask
Die Netzmaske für diesen virtuellen Server, im Drop-Down-Menü.
Firewall Mark
Zur Eingabe eines ganzzahligen Wert für die Firewall-Markierung bei der Bündelung von Protokollen mit mehreren Ports oder zur Erstellung eines virtuellen Servers mit mehreren Ports für separate, aber benachbarte Protokolle.
Device
Der Name des Netzwerkgeräts, mit dem sich die im Feld Virtual IP Address definierte floating IP-Adresse verbinden soll.
Sie sollten ein Alias für die öffentliche floating IP-Adresse zur Ethernet-Schnittstelle, die mit dem öffentlichen Netzwerk verbunden ist, erstellen.
Re-entry Time
Ein ganzzahliger Wert, der die Anzahl der Sekunden definiert, bevor der aktive LVS-Router versucht, einen realen Server zu verwenden, nachdem der reale Server ausgefallen ist.
Service Timeout
Ein ganzzahliger Wert, der die Anzahl der Sekunden definiert, bevor ein realer Server als funktionsuntüchtig und nicht verfügbar eingestuft wird.
Quiesce server
Wenn das Auswahlsymbol Quiesce server aktiviert ist, wird - jedes Mal, wenn ein neuer realer Server-Knoten online geht - die Tabelle mit den wenigsten Verbindungen auf Null zurückgesetzt, so dass der aktive LVS-Router Anfragen so routet, als ob alle realen Server frisch zum Cluster hinzugefügt wurden. Diese Optionen verhindert, dass sich ein neuer Server beim Eintreten in ein Cluster durch eine hohe Anzahl an Verbindungen verzettelt.
Load monitoring tool
Der LVS-Router kann die Auslastung auf verschiedenen realen Servern entweder mit Hilfe von rup oder ruptime überwachen. Falls Sie rup aus dem Drop-Down-Menü auswählen muss auf jedem realen Server der rstatd-Dienst laufen. Falls Sie ruptime auswählen, muss auf jedem realen Server der rwhod-Dienst laufen.
Scheduling
Der bevorzugte Scheduling-Algorithmus aus dem Drop-Down-Menü. Der Standardwert lautet Weighted Least-Connection.
Persistence
Wird verwendet, wenn Sie persistente Verbindungen mit dem virtuellen Server während Client-Transaktionen benötigen. Gibt die Zahl der Sekunden für Inaktivität an, bevor eine Verbindung in diesem Textfeld die Zeit überschreitet.
Persistence Network Mask
Um die Persistenz für ein bestimmtes Subnetz einzuschränken, wählen Sie die entsprechende Netzwerkmaske aus dem Drop-Down-Menü.

1.10.4.2. REAL SERVER Unterabschnitt

Ein Klick auf die Verknüpfung des Unterabschnitts REAL SERVER im oberen Bereich des Panels zeigt den Unterabschnitt EDIT REAL SERVER an. Es zeigt den Status des physikalischen Server-Hosts für einen bestimmten virtuellen Dienst.
The REAL SERVER Subsection

Abbildung 1.35. The REAL SERVER Subsection


Click the ADD button to add a new server. To delete an existing server, select the radio button beside it and click the DELETE button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in Abbildung 1.36, „The REAL SERVER Configuration Panel“.
The REAL SERVER Configuration Panel

Abbildung 1.36. The REAL SERVER Configuration Panel


Dieses Panel besteht aus drei Eingabefeldern:
Name
Ein veranschaulichender Name für den realen Server.

Anmerkung

Dieser Name ist nicht der Hostname für die Maschine und sollte daher veranschaulichend und einfach identifizierbar sein.
Address
The real server's IP address. Since the listening port is already specified for the associated virtual server, do not add a port number.
Weight
An integer value indicating this host's capacity relative to that of other hosts in the pool. The value can be arbitrary, but treat it as a ratio in relation to other real servers.

1.10.4.3. EDIT MONITORING SCRIPTS Subsection

Klicken Sie auf die Verknüpfung MONITORING SCRIPTS am oberen Ende der Seite. Der Unterabschnitt EDIT MONITORING SCRIPTS erlaubt dem Administrator die Angabe einer Send/Expect String-Sequenz um zu verifizieren, dass der Dienst für den virtuellen Server auf jedem realen Server funktionsfähig ist. Es ist außerdem der Ort, an dem der Administrator angepasste Skripte angeben kann, um Dienste zu überprüfen, die dynamisch verändernde Daten erfordern.
The EDIT MONITORING SCRIPTS Subsection

Abbildung 1.37. The EDIT MONITORING SCRIPTS Subsection


Sending Program
Zur etwas fortgeschrittenen Dienstverifizierung können Sie dieses Feld zur Angabe des Pfades zu einem Skript zur Überprüfung eines Dienstes verwenden. Diese Funktion ist besonders für Dienste hilfreich, die dynamisch verändernde Daten erfordern, wie beispielsweise HTTPS oder SSL.
Um diese Funktion zu verwenden, müssen Sie ein Skript schreiben, das eine Antwort in Textform zurückgibt, dieses ausführbar machen und den Pfad im Feld Sending Program eingeben.

Anmerkung

Falls im Feld Sending Program ein externes Programm eingegeben wird, dann wird das Feld Send ignoriert.
Send
Ein String für den nanny-Daemon für das Versenden an jeden realen Server in diesem Feld. Standardmäßig wird das Feld 'Senden' für HTTP vervollständigt. Sie können diesen Wert gemäß Ihrer Anforderungen anpassen. Falls Sie dieses Feld leer lassen, versucht der nanny-Daemon, den Port zu öffnen und geht davon aus, dass der Dienst läuft, wenn er erfolgreich ist.
Nur eine Send-Sequenz ist in diesem Feld gestattet und es kann nur druckbare, ASCII-Zeichen, sowie die folgenden Code-Umschaltzeichen enthalten:
  • \n für Zeilenumbruch.
  • \r für Wagenrücklauf.
  • \t für Tabulator.
  • \ für den Escape des nächsten Zeichens, das darauf folgt.
Expect
Die Antwort in Textform, die der Server zurückgeben sollte, wenn er korrekt funktioniert. Falls Sie Ihre eigenes Programm zum Versenden geschrieben haben, geben Sie die von Ihnen vorgegebene zu versendende Antwort ein, falls es erfolgreich war.


[1] Ein virtueller Server ist ein Dienst, der so konfiguriert ist, dass er auf einer speziellen virtuellen IP horcht.

Kapitel 2. Zusammenfassung der Komponenten der Red Hat Cluster Suite

Dieses Kapitel liefert eine Zusammenfassung von Komponenten der Red Hat Cluster Suite und besteht aus den folgenden Abschnitten:

2.1. Cluster-Komponenten

Tabelle 2.1. Software-Subsystem-Komponenten des Red Hat Cluster Suite

Funktion Komponenten Beschreibung
Conga luci Remote-Management-System - Management-Station.
ricci Remote-Management-System - Verwaltete Station.
Cluster Configuration Tool system-config-cluster Der Befehl, der zur Verwaltung einer Cluster-Konfiguration in einer grafischen Umgebung verwendet wird.
Cluster Logical Volume Manager (CLVM) clvmd Der Daemon, der Aktualisierungen von LVM-Metadaten in einem Cluster verteilt. Er muss auf allen Knoten im Cluster laufen und gibt einen Fehler zurück, falls der Daemon auf einem Knoten im Cluster nicht läuft.
lvm LVM2-Tools. Liefert die Kommandozeilen-Tools für LVM2.
system-config-lvm Liefert die grafische Benutzeroberfläche für LVM2.
lvm.conf Die Konfigurationsdatei für LVM. Der vollständige Pfad lautet /etc/lvm/lvm.conf..
Cluster Configuration System (CCS) ccs_tool ccs_tool ist Bestandteil des Cluster Configuration Systems (CCS). Es wird für Online-Aktualisierungen von CCS-Konfigurationsdateien verwendet. Zusätzlich kann es dazu verwendet werden, Cluster-Konfigurationsdateien von mit GFS 6.0 (oder älter) erstellten CCS-Archiven auf das in diesem Release der Red Hat Cluster Suite verwendete XML-Format-Konfigurationsformat zu verbessern.
ccs_test Ein Befehl zur Diagnose und zum Testen, der für das Abrufen von Informationen von Konfigurationsdateien via ccsd verwendet wird.
ccsd Der CCS-Daemon, der auf allen Cluster-Knoten läuft und Konfigurationsdateidaten für die Cluster-Software bereitstellt.
cluster.conf Dies ist die Cluster-Konfigurationsdatei. Der vollständige Pfad lautet /etc/cluster/cluster.conf.
Cluster Manager (CMAN) cman.ko Das Kernelmodul für CMAN.
cman_tool Dies ist das administrative Front-End für CMAN. Es startet und stoppt CMAN und kann einige interne Parameter wie "votes" verändern.
dlm_controld Der Daemon, der vom cman Init-Skript gestartet wird, um dlm im Kernel zu verwalten. Wird nicht vom Benutzer verwendet.
gfs_controld Der Daemon, der vom cman Init-Skript gestartet wird, um gfs im Kernel zu verwalten. Wird nicht vom Benutzer verwendet.
group_tool Wird dazu verwendet, um eine Liste von den Gruppen zu bekommen, die in Verbindung stehen mit "fencing", DLM, GFS und um Debug-Informationen abzurufen. Umfasst Funktionen, die in RHEL 4 durch cman_tool services zur Verfügung gestellt wurde.
groupd Der Daemon, der vom cman Init-Skript gestartet wird, um zwischen openais/cman und dlm_controld/gfs_controld/fenced zu koordinieren. Wird vom Benutzer nicht verwendet.
libcman.so.<version number> Die Bibliothek für Programme, die mit cman.ko interagieren müssen.
Resource Group Manager (rgmanager) clusvcadm Der Befehl, der verwendet wird, um Benutzerdienste in einem Cluster manuell zu aktivieren, zu deaktivieren, zu verlagern und neu zu starten.
clustat Der Befehl, um den Status des Clusters anzuzeigen, inklusive der Knoten-Mitgliedschaften und der laufenden Dienste.
clurgmgrd Der Daemon, der zur Verwertung der Benutzerdienstanfragen verwendet wird, inklusive Starten, Deaktivieren, Verlagerung und Neustart des Dienstes.
clurmtabd Der Daemon, der zur Handhabung von geclusterten NFS-Mount-Tabellen verwendet wird.
Fence fence_apc Fence-Agent für das APC-Netzteil.
fence_bladecenter Fence-Agent für IBM-Bladecenters mit Telnet-Schnittstelle.
fence_bullpap Fence-Agent für die Bull Novascale Platform Administration Processor (PAP) Schnittstelle.
fence_drac Fencing-Agent für die Dell Remote Access Card.
fence_ipmilan Fence-Agent für Maschinen, die via LAN von IPMI (Intelligent Platform Management Interface) kontrolliert werden.
fence_wti Fence-Agent für das WTI-Netzteil.
fence_brocade Fence-Agent für den Brocade Fibre Channel Switch.
fence_mcdata Fence-Agent für den McData Fibre Channel Switch.
fence_vixel Fence-Agent für den Vixel Fibre Channel switch.
fence_sanbox2 Fence-Agent für den SANBox2 Fibre Channel Switch.
fence_ilo Fence-Agent für HP-ILO-Schnittstellen (formerly fence_rib).
fence_rsa I/O Fencing-Agent für IBM RSA II.
fence_gnbd Fence-Agent, der mit GNBD-Speicher verwendet wird.
fence_scsi I/O Fencing-Agent für SCSI-persistente Reservierungen.
fence_egenera Fence-Agent, der mit dem Egenera BladeFrame System verwendet wird.
fence_manual Fence-Agent zur manuellen Interaktion. HINWEIS Diese Komponente wird für Produktionsumgebungen nicht unterstützt.
fence_ack_manual Benutzerschnittstelle für den fence_manual-Agent.
fence_node Ein Programm, dass IO-Fencing auf einem einzelnen Knoten durchführt.
fence_xvm I/O-Fencing-Agent für virtuelle Xen-Maschinen.
fence_xvmd I/O-Fencing-Agent-Host für virtuelle Xen-Maschinen.
fence_tool Ein Programm zum Beitreten und Verlassen der Fence-Domain.
fenced Der I/O Fencing-Daemon.
DLM libdlm.so.<version number> Eine Bibliothek zur Unterstützung des Distributed Lock Manager (DLM).
GFS gfs.ko Kernelmodul, das das GFS-Dateisystem implementiert und auf GFS-Cluster-Knoten geladen wird.
gfs_fsck Ein Befehl, der ein nicht eingehängtes GFS-Dateisystem repariert.
gfs_grow Ein Befehl, der ein eingehängtes GFS-Dateisystem vergrößert.
gfs_jadd Ein Befehl, der Journals zu einem eingehängten GFS-Dateisystem hinzufügt.
gfs_mkfs Ein Befehl, der ein GFS-Dateisystem auf einem Speichergerät erstellt.
gfs_quota Ein Befehl, der Quotas auf einem eingehängten GFS-Dateisystem verwaltet.
gfs_tool Ein Befehl, der ein GFS-Dateisystem konfiguriert oder tunt. Dieser Befehl kann weiterhin eine Vielfalt an Informationen über das Dateisystem sammeln.
mount.gfs Mount-Hilfsprogramm, das von mount(8) aufgerufen wird. Wird vom Benutzer nicht verwendet.
GNBD gnbd.ko Kernelmodul, das den GNBD-Gerätetreiber auf Clients implementiert.
gnbd_export Ein Befehl zum Erstellen, Exportieren und Verwalten von GNBDs auf einem GNBD-Server.
gnbd_import Ein Befehl zum Importieren und Verwalten von GNBDs auf einem GNBD-Client.
gnbd_serv Ein Server-Daemon, der einem Knoten gestattet, lokalen Speicher via Netzwerk zu exportieren.
LVS pulse This is the controlling process which starts all other daemons related to LVS routers. At boot time, the daemon is started by the /etc/rc.d/init.d/pulse script. It then reads the configuration file /etc/sysconfig/ha/lvs.cf. On the active LVS router, pulse starts the LVS daemon. On the backup router, pulse determines the health of the active router by executing a simple heartbeat at a user-configurable interval. If the active LVS router fails to respond after a user-configurable interval, it initiates failover. During failover, pulse on the backup LVS router instructs the pulse daemon on the active LVS router to shut down all LVS services, starts the send_arp program to reassign the floating IP addresses to the backup LVS router's MAC address, and starts the lvs daemon.
lvsd Der lvs-Daemon läuft auf dem aktiven LVS-Router, sobald er von pulse aufgerufen wird. Er liest die Konfigurationsdatei /etc/sysconfig/ha/lvs.cf, ruft das Dienstprogramm ipvsadm auf, um die IPVS-Routing-Tabelle zu erstellen und zu pflegen und weist jedem konfigurierten LVS-Dienst einen nanny-Prozess zu. Falls nanny meldet, dass ein realer Server nicht mehr erreichbar ist, weist lvs das Dienstprogramm ipvsadm an, den realen Server aus der IPVS-Routing-Tabelle zu entfernen.
ipvsadm Dieser Dienst aktualisiert die IPVS-Routing-Tabelle im Kernel. Der lvs-Daemon richtet LVS ein und verwaltet es, indem er ipvsadm aufruft, um Einträge in der IPVS-Routing-Tabelle hinzuzufügen, zu ändern oder zu löschen.
nanny Der nanny Überwachungs-Daemon läuft auf dem aktiven LVS-Router. Mit Hilfe dieses Daemons bestimmt der aktive LVS-Router die Verfassung eines jeden realen Servers und überwacht optional dessen Arbeitsbelastung überwachen. Ein separater Prozess läuft für jeden Dienst, der auf jedem realen Server definiert ist.
lvs.cf Dies ist die LVS-Konfigurationsdatei. Der vollständige Pfad für die Datei lautet /etc/sysconfig/ha/lvs.cf. Alle Daemons erhalten ihre Konfigurationsinformationen direkt oder indirekt von dieser Datei.
Piranha Configuration Tool Dies ist das webbasierte Tool zur Überwachung, Konfiguration und Administration von LVS. Es ist das Standard-Tool zur Pflege der LVS-Konfigurationsdatei /etc/sysconfig/ha/lvs.cf.
send_arp Dieses Programm sendet während der Ausfallsicherung ARP-Broadcasts beim Übertragen von IP-Adressänderungen von einem Knoten auf einen anderen.
Quorum-Platte qdisk Ein plattenbasierter Quorum-Daemon für CMAN- / Linux-Cluster.
mkqdisk Cluster-Quorum-Platten-Dienstprogramm.
qdiskd Cluster-Quorum-Platten-Daemon.

2.2. Handbuchseiten

Dieser Abschnitt listet Handbuchseiten, die für die Red Hat Cluster Suite relevant sind, als zusätzliche Quellen.
  • Cluster-Infrastruktur
    • ccs_tool (8) - Das Tool, das für die Online-Aktualisierung von CCS-Konfigurationsdateien verwendet wird
    • ccs_test (8) - Das Diagnose-Tool für ein laufendes Cluster Configuration System
    • ccsd (8) - Der Daemon, der für den Zugriff auf CCS-Cluster-Konfigurationsdateien verwendet wird
    • ccs (7) - Cluster Configuration System
    • cman_tool (8) - Cluster Management Tool
    • cluster.conf [cluster] (5) - Die Konfigurationsdatei für Cluster-Produkte
    • qdisk (5) - Ein plattenbasierter Quorum-Daemon für CMAN- / Linux-Cluster
    • mkqdisk (8) - Cluster-Quorum-Platten-Dienstprogramm
    • qdiskd (8) - Cluster-Quorum-Platten-Daemon
    • fence_ack_manual (8) - Ein Programm, das von einem Operator als ein Teil des manuellen I/O-Fencing ausgeführt wird
    • fence_apc (8) - I/O-Fencing-Agent für APC MasterSwitch
    • fence_bladecenter (8) - I/O-Fencing-Agent für IBM-Bladecenter
    • fence_brocade (8) - I/O-Fencing-Agent für Brocade FC Switches
    • fence_bullpap (8) - I/O-Fencing-Agent für die Bull FAME-Architektur, kontrolliert von einer PAP-Managment-Konsole
    • fence_drac (8) - Fencing-Agent für die Dell Remote Access Card
    • fence_egenera (8) - I/O-Fencing-Agent für das Egenera BladeFrame
    • fence_gnbd (8) - I/O-Fencing-Agent für GNBD-basierte GFS-Cluster
    • fence_ilo (8) - I/O-Fencing-Agent für die HP Integrated Lights Out Card
    • fence_ipmilan (8) - I/O-Fencing-Agent für Maschinen, die von IPMI via LAN kontrolliert werden
    • fence_manual (8) - Ein Programm, das von 'fenced' als Teil des manuellen I/O-Fencing ausgeführt wird.
    • fence_mcdata (8) - I/O-Fencing-Agent für McData FC Switches
    • fence_node (8) - Ein Programm, das I/O-Fencing auf einem einzelnen Knoten durchführt
    • fence_rib (8) - I/O-Fencing-Agent für die Compaq Remote Insight Lights Out Card
    • fence_rsa (8) - I/O-Fencing-Agent für IBM RSA II
    • fence_sanbox2 (8) - I/O-Fencing-Agent für QLogic SANBox2 FC Switches
    • fence_scsi (8) - I/O-Fencing-Agent für SCSI-persistente Reservierungen
    • fence_tool (8) - Ein Programm zum Beitreten und Verlassen der Fence-Domain
    • fence_vixel (8) - I/O-Fencing-Agent für Vixel FC Switches
    • fence_wti (8) - I/O-Fencing-Agent für WTI Network Power Switch
    • fence_xvm (8) - I/O-Fencing-Agent für virtuelle Xen-Maschinen
    • fence_xvmd (8) - I/O-Fencing-Agent-Host für virtuelle Xen-Maschinen
    • fenced (8) - Der I/O-Fencing-Daemon
  • Hochverfügbarkeits-Service-Management
    • clusvcadm (8) - Cluster User Service Administrations-Dienstprogramm
    • clustat (8) - Cluster Status-Dienstprogramm
    • Clurgmgrd [clurgmgrd] (8) - Resource Group (Cluster Service) Manager Daemon
    • clurmtabd (8) - Cluster NFS Remote Mount Table Daemon
  • GFS
    • gfs_fsck (8) - Offline GFS-Dateisystem-Checker
    • gfs_grow (8) - Vergrößern eines GFS-Dateisystems
    • gfs_jadd (8) - Hinzufügen von Journals zu einem GFS-Dateisystem
    • gfs_mount (8) - GFS-Einhängeoptionen
    • gfs_quota (8) - GFS Platten-Quotas bearbeiten
    • gfs_tool (8) - Schnittstelle für GFS ioctl-Aufrufe
  • Cluster Logical-Volume-Manager
    • clvmd (8) - Cluster-LVM-Daemon
    • lvm (8) - LVM2-Tools
    • lvm.conf [lvm] (5) - Konfigurationsdatei für LVM2
    • lvmchange (8) - Attribute des Logical Volume Manager verändern
    • pvcreate (8) - Eine Platte oder Partition für die Verwendung durch LVM initialisieren
    • lvs (8) - Informationen über logische Datenträger ausgeben
  • Global Network Blockgerät
    • gnbd_export (8) - Die Schnittstelle, um GNBDs zu exportieren
    • gnbd_import (8) - GNBD-Blockgeräte auf einem Client bearbeiten
    • gnbd_serv (8) - GNBD Server-Daemon
  • LVS
    • pulse (8) - Heartbeating-Daemon zur Überwachung der Verfassung von Cluster-Knoten
    • lvs.cf [lvs] (5) - Konfigurationsdatei für LVS
    • lvscan (8) - Auf logische Datenträger überprüfen (alle Platten)
    • lvsd (8) - Daemon zur Kontrolle der Red Hat Clustering-Dienste
    • ipvsadm (8) - Linux Virtual Server Administration
    • ipvsadm-restore (8) - Wiederherstellung der IPVS-Tabelle von stdin
    • ipvsadm-save (8) - Speichern der IPVS-Tabelle nach stdout
    • nanny (8) - Tool zur Überwachung des Status der Dienste in einem Cluster
    • send_arp (8) - Tool zur Benachrichtigung des Netzwerks über eine neue IP-Adress- / MAC-Adress-Zuweisung

2.3. Kompatible Hardware

Für Informationen zu Hardware, die mit Red Hat Cluster Suite-Komponenten kompatibel ist (z.B. unterstützte Fence-Geräte, Speicher-Geräte und Fibre Channel-Switches), werfen Sie einen Blick auf die Richtlinien zur Hardware-Konfiguration unter http://www.redhat.com/cluster_suite/hardware/.

Revisionsverlauf

Versionsgeschichte
Version 3-8.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Version 3-82012-07-18Anthony Towns
Rebuild for Publican 3.0
Version 1.0-0Tue Jan 20 2008Paul Kennedy
Zusammenfassung vorhergehender Veröffentlichungen

Stichwortverzeichnis

C

cluster
displaying status, Cluster Status Tool
cluster administration
displaying cluster and service status, Cluster Status Tool
cluster component compatible hardware, Kompatible Hardware
cluster component man pages, Handbuchseiten
cluster components table, Cluster-Komponenten
Cluster Configuration Tool
accessing, Cluster Configuration Tool
cluster service
displaying status, Cluster Status Tool
command line tools table, Administrationstools für die Kommandozeile
compatible hardware
cluster components, Kompatible Hardware
Conga
overview, Conga
Conga overview, Conga

F

feedback, Feedback

I

introduction, Einführung
other Red Hat Enterprise Linux documents, Einführung

L

LVS
direct routing
requirements, hardware, Direktes Routing
requirements, network, Direktes Routing
requirements, software, Direktes Routing
routing methods
NAT, Routing-Methoden
three tiered
high-availability cluster, Three-Tier LVS Topology

M

man pages
cluster components, Handbuchseiten

N

NAT
routing methods, LVS, Routing-Methoden
network address translation (Siehe NAT)

O

overview
economy, Red Hat GFS
performance, Red Hat GFS
scalability, Red Hat GFS

P

Piranha Configuration Tool
CONTROL/MONITORING, CONTROL/MONITORING
EDIT MONITORING SCRIPTS Subsection, EDIT MONITORING SCRIPTS Subsection
GLOBAL SETTINGS, GLOBAL SETTINGS
login panel, Linux Virtual Server Administrations-GUI
necessary software, Linux Virtual Server Administrations-GUI
REAL SERVER subsection, REAL SERVER Unterabschnitt
REDUNDANCY, REDUNDANCY
VIRTUAL SERVER subsection, VIRTUAL SERVERS
Firewall Mark , Der Unterabschnitt VIRTUAL SERVER
Persistence , Der Unterabschnitt VIRTUAL SERVER
Scheduling , Der Unterabschnitt VIRTUAL SERVER
Virtual IP Address , Der Unterabschnitt VIRTUAL SERVER
VIRTUAL SERVERS, VIRTUAL SERVERS

R

Red Hat Cluster Suite
components, Cluster-Komponenten

T

table
cluster components, Cluster-Komponenten
command line tools, Administrationstools für die Kommandozeile