Seit ein paar Monaten regiert in Berlin eine große Koalition, und einstmals verfeindete Lager entdecken, dass man durchaus auch zusammen etwas erreichen kann. Im Gegenteil, durch Synergie-Effekte wird in der Zusammenarbeit manches Thema sogar effizienter

Im Gegenteil, durch Synergie-Effekte wird in der Zusammenarbeit manches Thema sogar effizienter bearbeitet, als es allein möglich gewesen wäre. Was für die Zusammenarbeit von Parteien oder Menschen im Allgemeinen gilt, lässt sich aber oft auch guten Gewissens auf IT-Infrastrukturen übertragen, denn auch hier kann man einst verfeindete Lager sehr wohl zu einer Kooperation bringen und dabei für die Allgemeinheit, sprich das Unternehmen, deutlichen Nutzen erzielen.

  Schauen wir uns doch mal die Situation an, wie man sie in so manchem Unternehmen, vor allem auch im Mittelstand, findet. Ein Großteil der Anwender arbeitet an "normalen" Windows-Workstations, die auf zentrale Applikations-, File- und Datenbankserver zugreifen. Daneben gibt es aber eine Gruppe von CAD-Anwendern, die auf UNIX- oder Linux-Workstations arbeitet und die daher in der Regel auch auf einen eigenen Fileserver zugreift. Und -last but not least- ist da die Werbeabteilung, die Ihre geliebten Macs einsetzt, natürlich mit einem Mac Xserve als Fileserver. Solche Konstellationen wird man relativ häufig finden, und aus manchem Blickwinkel heraus betrachtet, machen solche Szenarien auch Sinn, da so jede Kern-Anwendung in einer für sie optimierten Umgebung läuft und keine Wechselwirkungen mit den "anderen Welten" zu befürchten sind. Die Kehrseite der Medaille zeigt sich, wenn man das Gesamt-Konstrukt aus der Perspektive der Datensicherung überprüft, weil dann eine Reihe von Schwachstellen auffällt, die aus der abteilungsweisen Betrachtung heraus nicht erkennbar ist. Wie wird die Datensicherung denn klassischerweise in einem solchen Umfeld betrieben? Schauen wir uns das doch einmal in einem Beispiel an:   Abb. 1   In der Regel ist die "Windows-Welt" einigermaßen gut abgesichert, da hier meist die vitalen Prozesse des Unternehmens laufen. Warenwirtschaftssystem oder ERP werden generell mit ebenso großer Sorgfalt gesichert wie Datenbanken, Fileserver und Groupware- / Messaging-Systeme (á la MS Exchange etc.). In manchen älteren Installationen findet man zwar leider immer noch dezentrale Backup-Konzepte, bei denen jeder Server sein eigenes Datensicherungsgerät hat, aber die zentrale Sicherung auf Tape-Libraries setzt sich aus vielen Gründen immer mehr durch. Zu den Vorteilen zentralisierter Backups zählen u.a. die Möglichkeit, Medien zentral zu verwalten und effizienter zu nutzen, die deutlich besseren Möglichkeiten der Automatisierung und die vereinfachte Administration. Außerdem ist es sehr viel einfacher, auf die Schnelle noch einen weiteren Server in das Backup-Konzept mit einzubinden. Dezentrale Backup-Strategien kranken oft daran, dass weniger wichtige Server nur unregelmäßig oder gar nicht gesichert werden, da ein eigener Streamer zu teuer und zu aufwendig zu administrieren wäre. Wenn aber dann irgendwann z.B. das Intranet nicht mehr zur Verfügung steht, sind der Ärger und der Aufwand groß, Daten zu rekonstruieren oder neu einzugeben. Die CAD-Abteilung verfügt in unserem Beispiel über einen eigenen Server mit eigener Datensicherung. Die Konstruktionsdaten enthalten schließlich einen guten Anteil des Know-hows des Unternehmens, und die möchte man nicht mit anderen Daten vermischen. Oft spielen auch historische Gründe eine Rolle, weil z.B. ein anderer Administrator für die CAD verantwortlich war, der "seine" wertvollen UNIX-Daten nicht mit denen der Windows-Fraktion vermengt haben wollte. Also wird brav dezentral mit tar oder zusätzlicher Backup-Software auf ein separates Band gesichert. Und schließlich ist da die Kreativ-Abteilung mit ihren Macs: Genau wie in vielen Werbeagenturen werden Daten hier oft nur unzulänglich bis gar nicht gesichert. Vielfach werden nur die einzelnen Projekte auf CD gebrannt, die CDs aber dann vielleicht nicht sachgemäß gelagert, und wenn man doch mal auf die alten Daten zurückgreifen möchte... dann sind sie leider nicht mehr lesbar. In ungünstigen Fällen kann das Sonnenbad auf einer Fensterbank oder das Beschriften mit einem ungeeigneten Filzschreiber eine CD-ROM erheblich beschädigen . Fassen wir unsere Beispielfirma also mal aus der Backup-Sicht zusammen: Dezentrale Backup-Hardware, dezentrale Datensicherung, evtl. mehrere Medientypen, mit Sicherheit aber sehr viele Mediensätze, hoher administrativer Aufwand, hohe Kosten in Anschaffung, Wartung und Betrieb. Unterm Strich also sicherlich keine Lösung, die dauerhaft zufrieden stellen kann. Aber wie könnte denn ein alternatives Szenario aussehen, ohne dass man jetzt mit horrenden Kosten alles neu machen müßte? Kann man denn überhaupt die verschiedenen Betriebssystem-Welten "unter einen Hut" bringen? Ja, man kann, das steht außer Frage - schließlich besteht diese Problematik nicht erst seit gestern. Deshalb hat es für Großunternehmen schon seit längerem Entwicklungen gegeben, wo man mit leistungsfähiger Backup-Software Unterstützung für viele Betriebssysteme und Applikationen darstellen kann. Der Haken ist, dass allein diese Software oft schon mehrere zehntausend Euro kostet, von zentraler Backup-Hardware in Form von Libraries ganz zu schweigen. Für den Mittelstand ist das meist keine akzeptable Lösung, auch wenn die Kosten-Nutzen-Rechnung über die Jahre hinweg aufgehen würde. Die anfängliche Investition für Hard- und Software ist schlicht und ergreifend zu teuer. Also suchen wir einen anderen Weg, der bei erträglichen Investitionskosten dieselben Vorteile bietet. Konzentrieren wir uns zunächst einmal auf das, was die "verfeindeten Lager" vereinen könnte, also die Gemeinsamkeiten der Betriebssysteme. Ähnlich wie die große Koalition in Berlin hat ja auch unsere heterogene Landschaft der Betriebssysteme durchaus Gemeinsamkeiten. Die grundsätzlichen Ziele sind ja dieselben: Man stellt Programmen und Anwendern Funktionen zur Verfügung, um Daten manipulieren und ablegen zu können. In manchen Bereichen spricht man sogar dieselbe Sprache: Ob es nun Windows, UNIX, Linux oder Mac OS ist, alle können mit der universellen Sprache des Internets, TCP/IP, umgehen. Und alle können auch über das SCSI-Protokoll mit Festplatten und Streamern kommunizieren. Was liegt also näher, als auf diese beiden bewährten Standards zurückzugreifen, die im iSCSI-Verfahren gemeinsam zur Anwendung kommen Workstations und Servern auf der einen Seite und Datensicherungsgeräten auf der anderen Seite sicher zu stellen? Beim iSCSI-Verfahren werden SCSI-Daten in TCP/IP-Pakete verpackt und über das Netzwerk transportiert. Dabei entsteht eine virtuelle Point-to-Point (Ende-zu-Ende) Verbindung, so dass also z.B. ein Server auf eine iSCSI-Festplatte, die als Device irgendwo in LAN oder sogar im WAN verfügbar ist, genauso zugreifen kann wie auf eine lokal installierte Festplatte. Das Verfahren ist für das Betriebssystem völlig transparent, es wird lediglich ein iSCSI-Treiber benötigt, der die Zugriffe vom Server (iSCSI-Initiator) auf das Storage-Device (iSCSI-Target) regelt. Für Windows- und Linux-basierte Systeme ist der Einsatz von iSCSI denkbar einfach und zudem kostenlos, bei ersteren wird lediglich der Microsoft iSCSI Initiator installiert und konfiguriert. Bei Linux ist etwas mehr Handarbeit gefragt, aber Sourcen und Dokumentationen findet man an vielen Stellen im Internet . Für Mac OS X ab Version 10.3.5 gibt es mehrere Anbieter , die iSCSI-Initiator Software anbieten, zum Teil gebundelt mit anderen Softwareprodukten, wie, z.B., SAN-Management Software. Die Installation des Initiators ist je nach Betriebssystem verschieden komplex, vom Grundsatz her aber nicht viel anders als die Installation eines Netzwerk-Treibers. Tieferen Einblick ins Thema gibt die sehr gute Dokumentation des Microsoft iSCSI Initiators .   Wie sähe also unser Szenario der "großen Koalition" nach der Umstellung auf iSCSI aus? Die Server, die bisher ihre eigenen Streamer oder Autoloader besaßen, sind nun über ein iSCSI Netzwerk mit einer zentralen Backup-Lösung verbunden. Idealerweise besteht diese aus einer kombinierten Disk- /Tape-Lösung, da es sonst sehr schnell zu Engpässen kommen kann, wenn mehrere Server gleichzeitig ihre Backup-Jobs abzusetzen versuchen. Am Beispiel von Produkten aus dem Hause Tandberg Data sei dies hier kurz skizziert:
Abb. 2 Kernstück des iSCSI-SANs bildet hier ein intelligentes, Disk-basiertes Backup-Device, das Tandberg Bakstor, das mit 2 bis max. 6 Ethernet-Ports an das Netzwerk angeschlossen ist. Damit ist sowohl ausreichend Bandbreite als auch hohe Fehlertoleranz (im Falle des Ausfalles einzelner Kabel oder Ethernet-Ports) gewährleistet. Bakstor bildet dann quasi die "Erstversorgung" der Backup-Jobs. Unabhängig vom Betriebssystem sehen die jeweiligen Server Bakstor als ein LTO2-Tapelaufwerk, da sich das Gerät mit der sogenannten Virtual Tape Technologie so präsentiert. Für die Server gibt es also keinen Unterschied zu einem Backup auf lokal angeschlossene Bandlaufwerke, obwohl Bakstor unter Umständen mehrere hundert Meter entfernt in einem anderen Serverraum steht. Die Sicherung erfolgt auch tatsächlich genau so wie auf ein Band, also linear und im Format der jeweiligen Backup-Software. Der Unterschied besteht zum einen darin, dass wesentlich schneller, nämlich mit Disk-Geschwindigkeit, geschrieben werden kann und darüber hinaus das virtuelle Tape seine Kapazität dynamisch anpasst. Braucht der Backup-Job nur 20 GB, so werden auch nur 20 GB Kapazität verbraucht, braucht er z.B. 500 GB, so werden diese genauso bereitgestellt, während ein "echtes" LTO2-Tapelaufwerk hier schon einen Bandwechsel hätte durchführen müssen. Die Ausnutzung der Gesamtkapazität wird also durch die virtuellen Tapes sehr viel flexibler und effizienter als bei physikalischen Bändern. Darüber hinaus gibt es, bedingt durch die Disk-Technologie, entscheidende Vorteile beim Restore. Die Wiederherstellung einzelner Dateien, was laut Umfrage unter Administratoren den häufigsten Restore Fall darstellt, kann in einem Bruchteil der Zeit geschehen, die beim Restore vom Band benötigt würde. Doch Bakstor ist nicht als Endlager für die Daten gedacht, meist wird man ja zusätzlich noch auf Bänder schreiben wollen, um diese irgendwo sicher zu lagern. Dazu wird ein Autoloader oder eine Library, z.B. der Tandberg StorageLoader, direkt per SCSI an Bakstor angeschlossen und von diesem auch direkt verwaltet. Man hinterlegt also auf Bakstor Regeln, nach denen die Daten von den virtuellen Bändern auf echte physikalische Bänder verschoben werden. Da das aber unabhängig vom Backup-Zeitfenster geschehen kann, wird dieses deutlich verkleinert, wir haben das Primär-Backup ja bereits mit Disk-Geschwindigkeit durchgeführt und können den langsameren Teil des Kopierens auf Band dann in aller Ruhe tagsüber durchführen, ohne den Geschäftsbetrieb zu beeinträchtigen.

Fazit: Mittlerweile sind in heterogenen Umgebungen Backup-Szenarien denkbar und möglich, die nicht nur aus administrativer Sicht Sinn machen. Auch wirtschaftliche Überlegungen spielen eine Rolle, da unterm Strich weniger Laufwerke, weniger Mediensätze und weniger Administrationszeit benötigt werden. Mit relativ wenig Hardware und dementsprechend überschaubaren Kosten wird das gesamte Backup deutlich effizienter und sicherer, zudem auch noch skalierbarer, da man nur an einer Stelle zusätzliche Kapazitäten bereitstellen kann und nicht für jeden Server und / oder jedes Betriebssystem separate Hardware und Medien beschaffen muss.

Vorteile: · zentralisiertes Backup · weniger administrativer Aufwand · einfachere Erweiterbarkeit, "mitwachsende" Lösung möglich · geringer Umstellungsaufwand · MS zertifizierte iSCSI Hardware · vom Betriebssystem unabhängig · schnelleres Backup und vor allem Restore