High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

Cluster-Setup

Um nun den HA-Cluster einzurichten, gibt es mehrere Möglichkeiten. Mit »system-config-cluster« ( Abbildung 4 ) und Conga gibt es zwei grafische Anwendungen, jedoch ist es auch keine Problem, die XML-basierte Konfigurationsdatei manuell zu erzeugen und den Cluster auf diese Weise zu konfigurieren. Viele Optionen stehen über die grafischen Tools auch gar nicht zur Verfügung, sodass ein manuelles Bearbeiten der Datei sowieso in den meisten Fällen notwendig ist. Listing 7 zeigt eine bespielhafte Cluster-Konfigurationsdatei.

Listing 7

/etc/cluster/cluster.conf

 

Abbildung 4: system-config-cluster ist eine grafische Anwendung zur Konfiguration des HA-Clusters.

Die Konfigurationsdatei besteht aus mehreren Abschnitten. Zuerst sind die einzelnen Clusterknoten aufgeführt. Hier ist darauf zu achten, dass die verwendeten Rechnernamen über das interne Clusternetzwerk auflösbar sind, sonst findet die ganze Cluster-Kommunikation über das öffentliche Netzwerk statt. Für jeden Knoten ist mindestens eine Fencing-Methode anzugeben. Da im Beispiel ein Blade Center zum Einsatz kommt, liegt es nahe, das eigene Blade-Managementsystem als primären Notaus-Mechanismus zu verwenden.

Als Backup-Methode ist manuelles Fencing konfiguriert. Der Clustermanager basiert auf dem Open-AIS-Framework. Für dessen Heartbeat-Meldungen wandert ein Token zwischen den einzelnen Clusterknoten hin und her. Für dessen Übertragung kommt Multicast zum Einsatz. Sollten die verwendeten Netzwerk-Switches Probleme mit der Default-Multicast-Adresse haben, so lässt sich diese beliebig ändern.

Als Nächstes sind die eigentlichen Fence-Devices näher zu beschreiben, hier beispielsweise die IP-Adressen und Logindaten für das Blade-Managementsystem. Eine Liste der unterstützten Fence-Devices findet sich unter [6] . Soll ein virtuelles System primär auf einem bestimmten Clusterknoten laufen, dann lässt sich dies über so genannte Failover-Domains realisieren. Dieser Mechanismus ist gerade beim Einsatz von mehreren Systemen sehr nützlich, möchte man verhindern, dass auf einmal alle virtuellen Maschinen auf dem gleichen System laufen.

Nachhilfe für KVM

Im letzten Abschnitt folgt schließlich der Ressourcen-Manager. Jede virtuelle Maschinen-Instanz ist hier mit Namen aufzuführen. Kommt als Hypervisor Xen zum Einsatz, lässt sich in diesem Abschnitt auch der Speicherort der Konfigurationsdateien mit angeben. Diese können bei Xen nämlich auf einem von allen Knoten gemeinsam genutzen Datenspeicher liegen.

Für KVM existiert diese Möglichkeit noch nicht. Hier muss der Admin die Konfigurationsdateien der virtuellen Maschinen im lokalen Dateisystem ablegen und zwischen den einzelnen Clusterknoten synchronisieren. In einer der nächsten Versionen der Clustersuite wird allerdings auch hier die Speicherung der Konfigurationsdateien auf Shared Storage möglich sein. Da die virtuellen Maschinen zu diesem Zeitpunkt noch nicht existieren, ist dieser Abschnitt in der aufgeführten Konfigurationsdatei noch auskommentiert.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023