Speichervirtualisierung

Unterstützte Hardware

Server

OSL Storage Cluster 4.8 ist prinzipiell unter Solaris und Linux lauffähig (auch gemischt). Während unter Solaris bestimmte aktuelle SPARC-Systeme oder auch x86-Systeme in Frage kommen, ist unter Linux ein nochmals breiteres Spektrum von Hardware (insbesondere ultraschnelle Netzwerkkarten, NVMe-Storage usw.) einsetzbar. Bei der Betriebssystemauswahl (die eigentlich von untergeordneter Bedeutung ist) sollte den Empfehlungen der OSL gefolgt werden (vgl. Softwarebeschreibungen / Datenblätter). Die verfügbaren Optionen für die Server-Hardware ergeben sich dann aus den gewählten Betriebssystemen. Letztere bestimmen insbesondere verwendbare Netzwerk-, SAN- oder Plattencontroller.

Betriebssysteme:

• Linux (prinzipiell erst ab Kernel 4), aktuell empfohlen SLES 15.5. Andere Versionen bzw. Distributionen (z. B. Tumbleweed) auf Anfrage.
• Solaris in den Versionen 10 / 11, auf Anfrage ab 7

Beachten Sie auch die Freigabeinformationen der Hersteller zu den jeweiligen Systemen.

Steuerung des virtuellen Rechenzentrums

Der OSL Storage Cluster kann auf eine große Anzahl von geclusterten Knoten und Zonen skaliert werden. Der Cluster-Stack ist vollständig integriert und wird mit der Standardinstallation ausgeliefert. Um Aufgaben Ihres virtuellen Rechenzentrums zu verwalten, können Sie die Kommandozeile oder die webbasierte Benutzeroberfläche verwenden.

Kommandozeile
Die komplette Steuerung und Verwaltung des virtuellen Rechenzentrums erfolgt über die Komandozeile. Zusätzlich zur schriftlichen Dokumentation werden bei der Installation Manpages integriert. Mit Hilfe der Kommandozeile können Sie Ihren gesamten Cluster von jedem beliebigen Knoten Ihres Clusters aus verwalten. Sie benötigen keinen dedizierten Manager-Knoten.

WebGUI
Einen bequemere Kontrollmöglichkeit über Ihre Cluster haben Sie mit der integrierten grafischen Benutzeroberfläche. Die zentrale Webschnittstelle basiert auf einem JavaScript-Framework und kann folglich mittels eines normalen Webbrowsers (empf. Firefox) bedient werden. Sie hilft Ihnen, Ihren Cluster zu steuern und den Zustand jedes einzelnen Knotens zu überblicken. Dazu gehören unter anderem die Administration von Speicherressourcen, die Steuerung von Applikationen sowie ein umfangreiches Performance Monitoring der einzelnen Knoten, so dass Sie als Systemverwalter stets über die Auslastung Ihrer Server im Bilde sind.

Hochverfügbarkeitscluster

Was den OSL Storage Cluster aus technologischer Sicht einzigartig werden lässt, ist die Verknüpfung von Speichervirtualisierung und Clustering. Durch die Kombination dieser beiden Technologien gelingt es, Applikationen auf dem Host zu integrieren. Nur die Betrachtungsweise vom Host aus ermöglicht schließlich eine ganzheitliche Sicht auf Anwendung, Betriebssystem, Hardwarebasis sowie ergänzende Soft- und Hardwaretechnologien. Wahre Applikationsorientierung kann demzufolge im Grunde nur per hostbasierter Software erreicht werden.
Cluster sind allgemein als sehr geeignete Lösungen für Hochverfügbarkeit und Ausfallsicherheit anerkannt. Anders als viele Wettbewerbslösungen benötigt der OSL Storage Cluster keine auf Standardnetzwerktechnik aufsetzende dedizierte und redundant ausgelegte Cluster-Interconnect-Verbindung. Mithilfe von im ausfallsicheren RAID-System abgelegten Informationen (Cluster-Datenbank) kommunizieren die Knoten über die Datenkanäle (z.B. FC-SAN) miteinander. Die dabei ausgetauschten Daten belegen  einen kaum messbaren Anteil der zur Verfügung stehenden Bandbreite.

Mit dem OSL Storage Cluster tragen wir mit einem effektiven Schutz vor Hardwareausfällen Sorge, dass Anwendungen im Katastrophenfall auf ein anderes Stück Hardware migrieren. Ein für solche Fälle vorgehaltener Host übernimmt die Applikation. Offline-Zeiten werden so vermieden. Diese Vorgehensweise setzt allerdings voraus, dass auf Hardware-Ressourcen abstrahiert zugegriffen werden kann. Prozesse und Anwendungen müssen beschrieben, ggf. angepasst werden. Erreicht wird damit nicht zuletzt eine deutliche Verringerung der durch den Administrator zu verwaltenden Komplexität. Mit klarer Befehlssyntax, zentraler Administration von jedem beliebigen Clusterknoten aus und durchweg einheitlichen Gerätenamen besticht der OSL Storage Cluster mit weiterer Bediensicherheit.

Aktiv/aktiv, aktiv/passiv oder keines von beiden?

Von herkömmlichen Clusterlösungen kennt man aktiv/aktiv-Varianten, bei denen mindestens zwei Applikationsserver online sind und bei Ausfall eines Servers der andere dessen Aufgaben übernimmt. Weiterhin kennt man aktiv/passiv-Lösungen, bei denen ein Standby-Gerät vorgehalten wird, welches einspringt, wenn das Primärsystem ausfällt. Wenngleich auch solche Architekturen unterstützt werden, beschränkt sich das Clusterkonzept von OSL nicht auf diese beiden althergebrachten Varianten. Denn mit dem OSL Storage Cluster lassen sich weitaus intelligentere Konfigurationen abbilden. Mit der Application Control Option (ACO) steuert die Software per ressourcenbasiertem Selbstmanagement Ihre Anwendungen clusterweit automatisch und weist sie den zur Verfügung stehenden Hosts entsprechend ihrem Ressourcenbedarf zu. Bei Hardwareausfällen ordnen sich die betroffenen Anwendungen den verbleibenden Hosts gemäß ihrer Priorität neu zu:

Der OSL-Anwender ordnet seinen Applikationen Prioritäten zu. Auf Grundlage von Performancebenchmarks, Anwendungsbeschreibungen und Prioritäten wird eine Zuordnung der Applikationen auf unterschiedliche Server des Clusters vorgenommen. Dies kann entsprechend der Leistungsfähigkeit, der zur Verfügung stehenden Hardware automatisiert erfolgen.

Fällt nun ein Clusterknoten aus, findet anhand der jeweils benötigten Hardwareressourcen im notwendigen Ausmaß eine Neuverteilung der Anwendungen über die noch zur Verfügung stehenden Clusterknoten statt. Höher priorisierte Anwendungen können dabei sogar weniger priorisierte verdrängen, um selbst weiterhin online zu bleiben. So kann der Anwender seine Produktivapplikationen entsprechend hoch und Test-, Entwicklungs- oder QS-Applikationen niedrig priorisieren, um im K-Fall die wichtigen Anwendungen verfügbar zu halten.

Ist die ausgefallene Hardware später wieder online, können die heruntergefahrenen Applikationen erneut gestartet werden. Eine nochmalige Migration laufender Anwendungen ist danach nicht zwingend notwendig.

❮ ❯

Disaster Recovery

Hier wird von einer komplett redundanten Auslegung aller beteiligten RZ-Komponenten ausgegangen. Insbesondere bei großen Unternehmen mit 24/7 Verfügbarkeitsanforderung wird dieses Ziel mit dem Aufbau eines räumlich getrennten zweiten Rechenzentrums erreicht, das bei Ausfall des primären (z.B. bei einem Stromausfall) die wichtigen Anwendungen hostet. OSL hat es sich zur Aufgabe gemacht auch Disaster Recovery Probleme effizient und einfach zu lösen.

Alle großen Speicherhersteller bieten in verschiedenen Formen auch DR-Lösungen an. Dabei wird meistens von einem großen Produktiv-RAID-System ausgegangen, das wenigstens in Teilen permanent an einen anderen Standort (Notfall-RZ) gespiegelt wird. Sollte nun das Produktiv-RAID-System ausfallen, soll das Notfall-RZ übernehmen. Prinzipiell kann damit schon ein Großteil der gewünschten Ausfallsicherheit abgebildet werden. Leider verkompliziert es die Handhabung der gesamten RZ-Umgebung erheblich, insbesondere durch eine Zuordnung Anwendung ↔ LUN des RAID-Systems, die nicht immer einfach herzustellen ist. Gleiche Probleme kennt man schon von Backup- bzw. Restore-Konzepten, wo im Ernstfall leider viel zu oft kein schneller Wiederanlauf möglich ist.
Als besonders kritisch stellen sich Datenbank-Systeme dar, da neben der reinen Datenbank auch Logarchive, Onlinelogs und Controlfiles (z.B. bei Oracle) bis zum Ausfallzeitpunkt vorhanden sein müssen, damit ein Wiederanlauf ohne Transaktionsverlust möglich wird. Durch die permanente Spiegelung hat man auch das zusätzliche Problem der sofortigen Replikation von Datenbankfehlern auf das entfernte Speichersystem. Die gespiegelten Daten sind mit einem Schlag unbrauchbar.

Ein ganzheitliches Konzept für große Datenbanken/SAP-Systeme mit OSL Storage Cluster
Der OSL Storage Cluster bietet insbesondere für große Datenbanken/SAP-Systeme eine Lösung, die Disaster Recovery, Backup-to-Disk, Backup-to-Tape und Instant Recovery vereinigt. Eine ausgewogene Kombination synchroner und asynchroner Spiegel gewährleistet maximalen Schutz vor typischen Ausfall- und Fehlersituationen. Unsere Lösung zeichnet sich aus durch:

• "schnellen Wiederanlauf für Datenbanken" - vor allem für große Datenbanken oft ein Problem
• beeindruckende Performance und
• geringe Hardwareanforderungen und damit auch deutliche Kostenreduzierungen.

Der ganz große Vorteil gegenüber allen anderen am Markt befindlichen Lösungen ist die Applikationsorientierung. Man definiert im OSL Storage Cluster Anwendungen mit allen notwendigen Ressourcen (virtuelle Interfaces, Filesysteme, Start-, Stop- und Break-Prozeduren, usw.) und erhält damit für jede Anwendung ein administratives Objekt, das mit einfachen Befehlen auf allen Cluster-Knoten gestartet und auch verwaltet werden kann.

Applikationsspiegel zu Disaster Recovery Zwecken als Instant Recovery
Zu dieser bestehenden Anwendung können nun wiederum mit einem einfachen Befehl Spiegel-Applikationen (XDM) erstellt werden. Durch das Universen-Konzept von OSL haben Produktiv- und Backup-Applikationen den gleichen Namen, sie unterscheiden sich lediglich durch das Universum. So behält man auch bei vielen Anwendungen den Überblick. Durch eine sinnvolle Verteilung der Universen kann man neben dauerhaft synchronisierten Spiegelapplikationen auch Backups auf Disk zu definierten Zeitpunkten verwirklichen. Die Backup-Spiegel können jederzeit mit der Produktion synchronisiert sowie atomar und damit (zeit-)konsistent abgetrennt werden. Man erhält so immer ein sofort startbares Image der Gesamtapplikation auf Disk, auf das im Disasterfall zurückgegriffen werden kann. Bei der Verwendung von Datenbanken (z.B. Oracle) wird zudem der Backup-Modus aktiviert, so dass ein Online-Backup verfügbar ist. In Verbindung mit den permanenten Spiegeln (Redologs) hat man die Möglichkeit, das Backup (auch automatisiert) auf jeden gewünschten Stand vorzufahren, ohne dass ein Tape involviert ist. Kurz gesagt: Instant Recovery.

Das Backup-Konzept kann zudem mit einer Tape-Anschlusslösung (z.B. Networker) erweitert werden. Das Backup wird dann zunächst auf Disk erstellt, das dann vom zentralen Backup-Server auf Tape geschrieben wird. Dieses Vorgehen zeichnet sich durch folgende Vorteile aus:

• Das Tape-Backup belastet die Produktion überhaupt nicht, da lediglich die Backup-Applikation auf Band geschrieben wird.
• Es wird nur ein Backup-Server pro Cluster verwendet und somit die Lizenzen für die Backup-Clients eingespart.
• Der Stream auf Band läuft über dedizierte SAN-Verbindungen mit deutlich gesteigerter Performance. Wenn nun also das Produktiv-RZ ausfällt, kann mit Hilfe der Spiegel-Applikationen die Produktion im Notfall-RZ wieder aufgenommen werden.

Applikationsintegration mit virtualisierten Ablaufumgebungen
Unter Zugrundelegung der beschriebenen Clustertechnologie stellt OSL Storage Cluster Ihren Anwendungen die benötigten Systemressourcen über einheitliche, virtualisierte Schnittstellen zur Verfügung. Wegen der Anpassungen der Umgebungsparameter von Applikationen wird dieses Konzept als Virtual Runtime Environments bezeichnet. Im Vergleich zu den weit verbreiteten virtuellen Maschinen zeichnen sie sich vor allem durch leichte Administrierbarkeit aufgrund klarer Gliederung von Prozessen und Services aus. Da die Hardware nicht mit einem aufwendigen Hypervisor abstrahiert wird, arbeiten Anwendungen in virtualisierten Ablaufumgebungen mit der Performance einer nativen Ausführung.

Die Anwendung als Dreh- und Angelpunkt
Anwendungen sind das höchste Gut im Rechenzentrum. Solange die Applikationen trotzdem ohne Datenverluste weiterlaufen können, ist der Ausfall von Hardware in aller Regel zu verschmerzen. Die Virtual Runtime Environments stellen Anwendungen konsequent in den Mittelpunkt des RZ-Betriebs. Nur wahre Applikationsorientierung hilft, weitere Herausforderungen wie Backup, Archivierung, Systemkopien und Disaster Recovery oder Storage Management überzeugend zu bewältigen. Nach dem Konzept von OSL werden Prozesse durch intelligente Software aus der Sichtweise der Applikation vom Host aus optimal gestaltet.

Framework für virtuelle Maschinen

Das Clusterframework bietet ebenso den vollen Komfort der Application Control Option für virtuelle Maschinen unter Solaris oder Linux. Durch einen eigenen Abstraktionslayer werden Solaris Zonen, LDOMs sowie Linux-basierte Hypervisor-Technologien über einheitliche Verfahren und Bedienschnittstellen integriert. Unter Linux besteht im Sinne der für den jeweiligen Anwendungsfall am besten geeigneten Technologien so völlige Wahlfreiheit zwischen KVM und VirtualBox (a. A. auch XEN). Selbstverständlich sorgt das Clusterframework für alle wichtigen Funktionen von Provisionierung, Ressourcenmanagement bis hin zu Live-Migration, Hochverfügbarkeit, clusterweitem Backup und Disaster Recovery.

Backup

Mit OSL Storage Cluster gelingt es - bei laufender Anwendung (online) - sofort wiederanlauffähige Backups zu erzeugen. Für eine Langzeitarchivierung können diese Backups - rückwirkungsfrei für Ihre Produktivanwendung - auf Tapes gesichert werden.

Daten dürfen nicht verloren gehen. So lautet eine der zentralen Zielstellungen informationstechnischer Einrichtungen. Die sichere Informationsverwahrung ist jedoch nur ein Aspekt des Datenmanagements. Um Stillstandszeiten geschäftskritischer Anwendungen zu vermeiden, müssen bestimmte Datenbestände stets für einen produktiven Zugriff verfügbar sein. Nur durch ein Betriebskonzept, das verschiedene technologische und organisatorische Ansatzpunkte überzeugend verknüpft, kann diesen Anforderungen entsprochen werden. Die hostbasierte Softwarelösung OSL Storage Cluster stellt dafür die erforderlichen Hilfsmittel bereit.

Vom Backup bis zur Archivierung mit einer integrierten und hochverfügbaren Gesamtlösung
Im Mittelpunkt eines Backup-Konzepts sollte die Verfügbarkeit der Anwendungen stehen. Laufende Anwendungen erfordern immer den Zugriff auf die dazugehörige Datenbasis. Wenn Hardware ausfällt, ist diese Voraussetzung prinzipiell gefährdet. Redundante Systeme und Spiegelkonfigurationen allein beseitigen diesen Mangel noch nicht. Denn nur damit kann eine Applikation im K-Fall trotzdem noch nicht auf die benötigten Daten zugreifen. Hierzu ist weitere Software-Intelligenz gefragt. OSL erfüllt diese Anforderungen mit einer applikationsorientierten Lösung, bei der die Sichtweise der Anwendung im Vordergrund steht.

Produktivdaten geschäftskritischer Anwendungen werden sinnvollerweise in hochwertigen RAID-Systemen (Primärspeicher) abgelegt. Mithilfe von Applikationsbeschreibungen und anwendungsorientierten Spiegelmechanismen erstellt die Software OSL Storage Cluster Anwendungsimages auf preiswertem Sekundärspeicher (bspw. SATA-RAID). Diese Images erfahren mit geringem Zeitaufwand in regelmäßigen Abständen Synchronisationen. Sollte der Produktivspeicher ausfallen, stehen die Applikationsimages sofort für einen produktiven Zugriff bereit - durch permanente Spiegelung von Log-Files sogar ganz ohne Datenverluste. Ein im herkömmlichen Sinne dem Wiederanlauf vorgelagerter Restore ist so gar nicht mehr erforderlich. Die Produktivdaten werden einfach zur Laufzeit in den instandgesetzten Primärspeicher resynchronisiert. Sollte ein Knoten ausfallen, ist mit der integrierten Clusterfunktion sichergestellt, dass die Anwendung durch einen anderen Knoten übernommen werden kann.

Durch Anbindung eines Backup-Knotens lassen sich die Applikationsimages bequem und dank Disk-Backup hochperformant (Streaming der Bänder) auf Tape schreiben. Die Nutzung preiswerter SATA-Drives als Sekundärspeicher ist im Übrigen durchaus zu empfehlen, da diese mit dem hier im Regelfall ausschließlich stattfindenden sequenziellen Datenverkehr sehr gut zurecht kommen.