Der Software Distribution (SWD) Server lief schon viele Jahre hindurch auf zwei Hosts im aktiv/passiv Betrieb, zunächst 2x SunFire E450, später SunFire 3800 + E450 mit gemeinsamem Storage. Im Jahr 2007 wurden die jetzt noch laufenden SunFire T2000 Maschinen in Betrieb genommen. Diese scheinbar hohe Redundanz konnte aber die Verfügbarkeit des Servers insgesamt nicht wesentlich steigern. Das lag daran, dass die Stabilität der Server Hardware schon ein sehr hohes Maß erreicht hatte, Software- und Konfigurations-Probleme meist aber auch das Storage mit betrafen, welches damit zu einem Single Point of Failure wurde, obwohl seine eigene Verfügbarkeit doch schon sehr hoch war.

Es wurde daher Anfang 2008 ein zweites Storage AMS 500 angeschafft, welches den Namen AMS 502 erhielt, und das ein bitgenaues Abbild der Bereiche des bestehenden AMS 500 darstellt, die dem SWD-Server zuzurechnen sind. Schließlich wurde noch Mitte 2008 ein weiterer SunFire T2000 Host angeschafft, der ständig mit dem AMS 502 verbunden, der "remote" SWD-Server für einen zweiten Standort werden sollte. Es standen somit ab diesem Jahr zwei komplette SWD-Server Hosts betriebsbereit zur Verfügung, wobei weiterhin zu jedem Zeitpunkt einer der Primary und der andere der Secondary war (Abb. 1).

Die Storage-Daten werden mit der Replication Software TrueCopy von Hitachi synchron auf einer Trunk-Verbindung über die Brocade Switches 200e übertragen. Der Primary ist aktiver SWD-Server, der Secondary hat zwar read-only Zugriff auf seine eigenen Datenbereiche (LUNs), da aber kein Zugriff auf die noch im Cache des Primary befindlichen Datenblöcke besteht, sieht er immer ein inkonsistentes Bild der Filesysteme. Nur nach einem synchronisierenden Unmount und anschließendem Takeover kann der nun zum Primary gewordene Secondary wirklich mit konsistenten Daten arbeiten.

Die Uptime des Software-Servers im Folgejahr 2009 konnte mit TrueCopy auf den bisherigen Höhepunkt von 99,93 % der Gesamtzeit gesteigert werden. Allerdings war das Umschalten auf den anderen Host nur halb automatisch möglich, und die gegenseitigen Abhängigkeiten von TrueCopy, Logical Volume Manager (LVM) und Filesystem Mounts mussten händisch in einzelnen Schritten aufgelöst werden, da es keine übergeordnete Steuerungssoftware gab.

Auf der Suche nach einem geeigneten Softwarepaket, welches ein weitgehend automatisches Takeover ermöglicht, stößt man auf Solaris Cluster. Diese sehr leistungsfähige Software von Sun (jetzt Oracle) ermöglicht sowohl High Availability (HA) Applications wie auch scalable Applications (also Applikationen, die auf mehreren der verfügbaren Hosts im Cluster gleichzeitig laufen können). Selbstverständlich werden alle bei Sun üblichen Filesysteme und Volume Manager unterstützt (LVM Metasets, Veritas, Raw Devices als Datenbankbereiche sowie ZFS). Auch globale Mounts von Filesystemen an allen Hosts des Clusters sind möglich. Die Caches werden dann über das Cluster Interconnect synchron gehalten. Die prinzipielle Topologie, die Solaris Cluster zu Grunde liegt, ist in Abb. 2 dargestellt.

Was wir aber lange nicht herausfinden konnten, war die Verträglichkeit von Solaris Cluster mit dem bereits auf den Storages des SWD-Bereichs laufenden TrueCopy von Hitachi. Dass sie zumindest in einem Cluster koexistieren können, war schon bald klar. Aber erst vor einem Jahr bekamen wir Dokumente von Sun, in denen beschrieben wurde, wie die Switch-Mechanismen von Solaris Cluster und von Replication Paketen, wie Hitachi TrueCopy oder EMC SRDF aufeinander abgestimmt werden können. Tatsächlich gibt es dieses Feature ab Solaris Cluster 3.2 Update 1, und wir strebten das damals höchste Solaris Cluster 3.2 Update 3 an. Zu diesem Zeitpunkt war bereits beschlossen worden, den NAS-Server als Solaris Cluster zu implementieren, wobei in diesem Cluster ein Testbereich für den SWD-Server vorzusehen war, auf dem alle erforderlichen Eigenschaften, insbesondere die Verträglichkeit mit TrueCopy Replication, untersucht werden können. In der Folge ist es uns dann auch gelungen, zwei LUNs im Cluster so einzurichten, dass sie mit TrueCopy repliziert werden und gleichzeitig als Device Group im Solaris Cluster aufscheinen.

Während über die Möglichkeiten von Solaris Cluster intensiv nachgedacht wurde, nahm das Ausweichrechenzentrum Gußhausstraße (ARZ) konkretere Formen an. Es war das Ziel, für die wichtigen Services jeder Abteilung zumindest einen Host auch im ARZ zu betreiben, der dort im Notfall auch autonom laufen könnte. Die Abteilung Standardsoftware ließ sich rechtzeitig vier Farben einer Verbindung über Glasfaser nach dem CWDM-Verfahren (Coarse Wavelength Division Multiplex) reservieren (Abb. 3). Diese wird seit Dezember 2010 für TrueCopy Replication verwendet, nachdem bereits lokale Tests im Jahr 2009 gute Ergebnisse gebracht hatten und das CWDM-Verfahren sich als stabiles und verlustfreies Multiplexing erwiesen hatte.

Zur Inbetriebnahme des ARZ für den SWD-Server hat man sich entschlossen, das bestehende AMS 500 Storage-System nicht mehr zu übersiedeln, was mit einem großen Risiko und Versicherungskosten verbunden gewesen wäre. Vielmehr wurde das neue Ersatzsystem AMS 2103 (Abb. 4) direkt ins ARZ geliefert und dort installiert. Das hatte darüber hinaus den Vorteil, dass ein modernes und leistungsfähiges Storage direkt in die 19 Zoll Rittal-Schränke montiert werden konnte und wegen des geringeren Stromverbrauchs über Pulsare (Abb. 5) an normale 16A-Steckerleisten angeschlossen werden konnte. Die zugehörigen Brocade Switches 200e swdswc und swdswd wurden ganz einfach übersiedelt (Abb. 6).

Der auf dieser Hardware-Basis installierte Solaris Cluster für den SWD-Server läuft daher derzeit noch etwas unsymmetrisch, bis das letzte AMS 500 Storage durch ein gleichwertiges, aber leistungsfähigeres Storage vom Typ AMS 2100 abgelöst wird, welches dann AMS 2101 heißen wird. Abbildung 7 zeigt die Struktur des SWD-Clusters mit dem NAS-Cluster in einem Zustand nach der Ablöse Mitte dieses Jahres. Zur Installation der Solaris Cluster Software Version 3.2 Update 8 ist zu sagen, dass diese relativ einfach und wie beschrieben erfolgt. Die Vorbereitungen dazu erwiesen sich aber auf Grund von sehr komplexen Hardware- und Software-Abhängigkeiten mit AMS 2100, HDLM 6.x, Solaris OS Version 10 Update 8 (muss auf allen Hosts gleich sein) und dem LVM als äußerst mühsam und zeitaufwendig. Daher laufen jetzt alle in einen Cluster eingebundenen Hosts mit Solaris 10 Update 8.