Es gibt zahlreiche Methoden, Mac OS X Server-Dienste ausfallsicher zu gestalten.

Unabhängig davon, ob es um Verzeichnisdienste, DHCP, AFP, SMB/CIFS oder sonstige in Mac OS X Server enthaltene Dienste geht, bietet sich meist die Möglichkeit zwischen einer Active/Active- und einer Active/Passive-Konfiguration zu wählen.

Active/Active vs. Active/Passive

Active/Active bedeutet, dass zwei oder mehr Server gleichzeitig dieselben Dienste mit dem selben Datenbestand anbieten, also beide gleichzeitig aktiv sind, während in einer Active/Passive-Konfiguration ein Server aktiv die gewünschten Dienste anbietet und ein zweiter passiv darauf wartet, dass der erste Server ausfällt, damit der zweite dann dessen Dienste übernehmen kann.

Active/Active

In einer Active/Active-Konfiguration liegt die Herausforderung darin, dass mehrere Server gleichzeitig dieselben Inhalte bereitstellen.

Bei den Verzeichnisdiensten von Mac OS X Server z.B. funktioniert das automatisch, indem Sie einen Server als Open Directory Master einrichten, den zweiten hingegen als Open Directory Replik.
Dadurch werden alle Verzeichnisdaten vom Master auf die Replik kopiert, spätere Änderungen werden ebenfalls an die Replik weitergegeben, so dass beide Server immer auf dem selben Stand sind. Da der Open Directory Master die Client-Rechner überdies automatisch über das Vorhandensein von Repliken unterrichtet, greifen die Clients automatisch auf beide Server zu.
Die Active/Active-Konfiguration der Verzeichnisdienste des Mac OS X Server erfolgt also dadurch, dass beide Server jeweils lokal den selben Datenbestand vorhalten.

Man kann sagen, dass die Verzeichnisdienste sich selbsttätig um die Redundanz kümmern, so dass an dieser Stelle Redundanz auf Applikationsebene erreicht wird.

Leider können nicht alle Dienste selbsttätig eine Active/Active-Konfiguration erreichen, so dass wir dann ein bisschen nachhelfen müssen.

In diesem Artikel soll es vor allem um das Bereitstellen von Daten über einen Fileserver gehen. Würden wie im obigen Falle bei den Verzeichnisservern zwei Server jeweils dieselben Daten bereitstellen, die sie jeweils lokal vorhalten (z.B. mittels eines jeweils direkt angebundenen Xserve RAID-Systems), so benötigten wir zum einen immer doppelt so viel Speicherplatz wie wir Daten bereitstellen wollen (was teuer ist), zum anderen benötigten wir einen Mechanismus, der jede Datei, die auf einem System geändert wird, auch auf das zweite System kopierte.

Clusterdateisysteme (z.B. Xsan)

Als Alternative bietet es sich an, beide (oder mehrere) Fileserver auf denselben Datenbestand zugreifen zu lassen. Dafür wird ein clusterfähiges Dateisystem benötigt, um zu verhindern, dass zwei oder mehr Maschinen gleichzeitig dieselben Daten beschreiben, wodurch zum einen die zu schreibende Datei selbst korrumpiert würde, zum anderen das gesamte Dateisystem sehr schnell beschädigt werden könnte, was zum kompletten Datenverlust führen kann.

Ein Cluster-Dateisystem wie z.B. Apples Xsan hingegen erlaubt es mehreren Rechnern gleichzeitig Daten mit hoher Bandbreite auf das selbe Dateisystem zu schreiben.
Xsan bedeutet jedoch auch, dass das gesamte Netzwerk deutlich komplexer wird als es bei einer Lösung mit HFS+-Volumes der Fall wäre.

Weiterhin ist aus einem einzelnen Xserve RAID-System mehr Leistung mit HFS+ als mit Xsan als Dateisystem herauszulocken (im Ergebnis ist HFS+ ungefähr doppelt so schnell bei einem einzigen Xserve RAID).
Dennoch benötigen Sie für die meisten Videoumgebungen Xsan als Speicherdateisystem, da Sie anderenfalls über Ethernet statt über Fibre Channel auf Ihre Daten zugreifen müssen, was für Videoanwendungen in den meisten Echtzeitumgebungen wenig Sinn macht.

Da außerdem ein einzelner aktiver Fileserver (mehr geht mit HFS+ nicht), die maximale Bandbreite, die dieser Server bereitstellen kann, auf maximal 6 x 1 Gb begrenzt ist (mit einer zusätzlichen 4 x 10Gb SmallTree-Ethernetkarte), benötigen Sie in großen Speicherumgebungen sowieso mehrere Server, so dass Sie an einem Clusterdateisystem wie Xsan nicht mehr vorbeikommen.

Active/Passive-Konfiguration mit HFS+-Volumes

Wenn Sie keine Echtzeit-Videoanwendungen auf Ihr Storagesystem zugreifen lassen, können Sie ein oder mehrere Xserve RAIDs per Fibre Channel mit einem Xserve verbinden und die auf dem Xserve RAID enthaltenen Daten vom Xserve aus über Ethernet an Ihre Client-Computer übermitteln.

Auf diese Weise setzen Sie Ihren Xserve als NAS-Head ein, als Network Attached Storage.

Die im folgenden beschriebene Lösung eignet sich vor allem für kleinere Umgebung mit ein oder zwei Xserve RAID-Systemen, bei mehr Speichersystemen empfiehlt sich wie bereits oben erwähnt in der Regel Xsan als Dateisystem.

Im Ergebnis geht es im folgenden darum, diese Konfiguration zu erreichen:

IP failover setup with HFS+ volume

Dabei greifen die drei links dargestellen Client-Rechner über einen Switch per AFP oder SMB/CIFS auf den oberen, aktiven Xserve zu, der wiederum per Fibre Channel über einen Fibre Channel-Switch auf das Xserve RAID rechts zugreift.

Der untere, passive Xserve wartet im Normalbetrieb darauf, dass der erste Xserve ausfällt, um dann dessen IP-Adresse zu übernehmen, das Xserve RAID zu mounten und die Daten, die auf dem Xserve RAID liegen, über AFP und SMB/CIFS freizugeben.

Setup

Hier die einzelnen Konfigurationsschritte:

  • Der obere, aktive Xserve wird als gewöhnlicher Fileserver eingerichtet. Er erhält also eine Fibre Channel-Karte, wird mit einem Fibre Channel-Switch verbunden, und daran hängt dann das Xserve RAID. Ich empfehle, sowohl das Xserve RAID als auch den Xserve auf Point-to-Point und 2Gb-Fibre Channel-Verbindungen zu stellen.
  • Der untere, passive Xserve wird zunächst genau so eingerichtet wie der aktive Xserve (allerdings mit einer anderen IP-Adresse und einem anderen Namen). Wenn alle Dienste konfiguriert und getestet sind, sollten die konfigurierten Dienste abgeschaltet werden.
  • Da nun beide Xserves beim Start das Xserve RAID-System mounten, muss dem passiven Server mitgeteilt werden, dass er das Xserve RAID nicht automatisch beim Starten, sondern nur im IP-Failover-Falle mountet. Dies geht wie folgt: Tippen Sie im Terminal diskutil list. Sie sehen nun in etwa folgendes:
    /dev/disk2
    #: type name size identifier
    0: GUID_partition_scheme *233.8 GB disk2
    1: EFI 200.0 MB disk2s1
    2: Apple_HFS Xserve_RAID 233.4 GB disk2s2

    Unser Xserve RAID-System wurde zuvor im Festplattendienstprogramm mit HFS+ als Dateisystem formatiert und das resultierende Volume “Xserve_RAID” genannt.
    Tippen Sie nun sudo nano /etc/fstab und kopieren Sie folgenden Text hinein:

    LABEL=Xserve_RAID none hfs rw,noauto

    Sollte Ihr Xserve RAID-Volume einen anderen Namen als Xserve_RAID tragen, verwenden Sie diesen stattdessen.
    Sichern Sie die Datei, und starten Sie Ihren passiven Server nun neu.
    Wenn das Xserve RAID nun nicht mehr automatisch gemountet wird, hat alles geklappt.

  • Schalten Sie nun den ersten Xserve aus, und mounten Sie das Xserve RAID auf dem zweiten Server. Wenn Ihr Xserve RAID sich oben als /dev/disk2s2 gemeldet hat, tippen Sie nun
    diskutil mount /dev/disk2s2
  • Richten Sie nun das eigentliche IP-Failover ein. Folgen Sie dazu der Anleitung in der Apple-Dokumentation ab Seite 180.
  • Achten Sie darauf, wenn Sie die PreAcquisition-, PostAcquisition-, PreRelease- und PostRelease-Skripts schreiben, dass zunächst das Xserve-RAID gemountet werden sollte bevor die Fileservices gestartet werden. Im Idealfall könnte ein erstes Skript auf dem zweiten Server eine Steckdosenleiste mit Webinterface ansteuern, an der der erste Server hängt. Somit könnte man dem ersten Server den Strom abstellen, um zu gewährleisten, dass dieser nicht mehr auf das Xserve RAID zugreift.
  • So könnten die Skripts auf dem zweiten Server aussehen:
    PreAcq10.MountRAID
    PostAcq10.StartAFP
    PostAcq20.StartSMB
    PreRel20.StopSMB
    PreRel10.StopAFP
    PostRel10.UnmountRAID
    mit jeweils folgendem Inhalt:
    PreAcq10.MountRAID:

    #!/bin/bash
    # PreAcq10.MountRAID
    #
    /usr/sbin/diskutil mount /dev/disk2s2

    PostAcq10.StartAFP:

    #!/bin/bash
    # PostAcq10.StartAFP:
    #
    /usr/sbin/serveradmin start afp

    PostAcq20.StartSMB:

    #!/bin/bash
    # PostAcq20.StartSMB
    #
    /usr/sbin/serveradmin start smb

    PreRel20.StopSMB:

    #!/bin/bash
    # PreRel20.StopSMB
    #
    /usr/sbin/serveradmin stop smb

    PreRel10.StopAFP:

    #!/bin/bash
    # PreRel10.StopAFP
    #
    /usr/sbin/serveradmin stop afp

    PostRel10.UnmountRAID:

    #!/bin/bash
    # PostRel10.UnmountRAID
    #
    /usr/sbin/diskutil unmount /dev/disk2s2

Machen Sie die Skripts mit chmod +x Skriptname ausführbar, und testen Sie das Failover, indem Sie den ersten Server ausschalten.

Achten Sie darauf, dass der erste Server prinzipiell vor dem ersten Server eingeschaltet werden muss.

Beachten Sie auch, dass das sogenannte Fallback, also die Freigabe der IP-Adresse vom zweiten an den ersten Server nicht immer zuverlässig funktioniert. Schalten Sie also den zweiten Server lieber aus, bevor Sie den ersten wieder aktivieren.

Ich hoffe, dass Ihnen diese Informationen beim Einrichten einer IP-Failover-Lösung behilflich sind und wünsche Ihnen viel Erfolg beim Ausprobieren.

Publiziert am 2. September, 2007 von André Aulich. Veröffentlicht in Mac OS X Server.

Die Kommentarfunktion ist geschlossen.