-
ALLGEMEINER
STAND DER TECHNIK
-
Die
Erfindung betrifft das Gebiet der Datensicherungssysteme und im
Besonderen einen Online-Echtzeit-Gerätetreiber für Datensicherungssysteme.
-
Das
Kapital eines Unternehmens in Form von Information (Daten) ist wesentlich
für die
Geschäfte
des Unternehmens. Ununterbrochene Verfügbarkeit der Daten ist eine
Notwendigkeit. Daher ist es erforderlich, dass Datensicherungssysteme
ununterbrochene Verfügbarkeit
der Daten im Falle eines Systemausfalls in dem primären Speichersystem
garantieren. Die Personal- und Ausrüstungskosten für eine Wiederherstellung
verlorener Daten können
in mehrere hunderttausend Dollar gehen.
-
Lokale
Techniken zur Hardwarereplikation (z.B. gespiegelte Festplatten)
erhöhen
die Fehlertoleranz eines Systems, indem sie eine Sicherungskopie
einfach verfügbar
halten. Um ununterbrochenen Betrieb sogar im Falle katastrophalen
Ausfalls zu garantieren, wird eine aktuelle Sicherungskopie der
primären
Daten an einem Ort außer
Haus aufbewahrt. Wenn eine Datensicherung in regelmäßigen Abständen erfolgt,
und nicht in Echtzeit, können
Daten verloren gehen (z.B. die seit der letzten Sicherungsoperation
aktualisierten Daten). Ein Problem an herkömmlichen Fernsicherungstechniken
ist, dass sie auf der Anwendungsprogrammebene erfolgen. Noch dazu
ist Echtzeit-online-Fernsicherung relativ teuer und ineffizient.
-
Ein
Beispiel einer herkömmlichen
Methode der Festplattenlaufwerkspiegelung wird in der US-Patentschrift
5,764,903 offenbart. Hier werden klientseitige und serverseitige
Programme auf Anwendungsebene verwendet, um den Prozess der Datensicherung
zwischen einem primären
Server und einem Sicherungsserver zu steuern. Die Programme auf
Anwendungsebene steuern den Fluss der Schreibanfragen zwischen dem
lokalen Server und dem Sicherungsserver. Schreibanfragen, die zu
spiegeln sind, werden zum primären
Server und zum Sicherungsserver gesendet. Wenn die Sicherungsfestplatte
nicht auf die Schreibanfrage reagieren kann, sendet das Programm
auf Anwendungsebene auf dem Sicherungsserver eine Mitteilung an
den primären
Server, die Schreibanfrage erneut zu senden.
-
Ein
Storage Area Network (SAN) ist ein zugeordnetes Speichernetzwerk,
in dem Systeme und intelligente Subsysteme (z.B. primäre und sekundäre) miteinander
kommunizieren, um die Bewegung und das Speichern von Daten von einem
zentralen Punkt aus zu steuern und zu verwalten. Das Fundament eines
SAN ist die Hardware, auf der es aufbaut. Die hohen Installations-
und Wartungskosten für Hardware
und Software machen SANs unerschwinglich teuer für alle außer für die größten Unternehmen.
-
Ein
Private Backup Network (PBN) ist ein ausschließlich für den Datensicherungsverkehr
entworfenes Netzwerk. Datenmanagementsoftware ist zum Betreiben
dieses Netzwerks erforderlich. Das erhöht folglich die Konkurrenz
um Systemressourcen auf der Anwendungsebene. Die Datensicherung
erfolgt nicht in Echtzeit, setzt also das Unternehmen dem Risiko
eines Datenverlusts aus. Diese Konfiguration nimmt den gesamten
Datensicherungsverkehr aus dem öffentlichen
Netzwerk, zu den Kosten von Installation und Wartung eines gesonderten
Netzwerks. Die Ver wendung von PBNs in Unternehmen ist auf Grund
hoher Kosten eingeschränkt.
-
Eine
dritte bekannte Sicherungstechnik ist in die Datenbank (DB) integriertes
Sichern. Das wachsende Vertrauen von Unternehmen in Datenbanken hat
zu größerer Nachfrage
nach und größerem Interesse
an Datensicherungsverfahren geführt.
Die meisten kommerziellen Datenbanken haben eine integrierte Sicherungsfunktion.
Allerdings führen
Export/Import Hilfsprogramme und Offlinesicherungsroutinen zu Unterbrechung,
denn sie blockieren Datenbank und dazugehörige Strukturen, wodurch die Daten
für alle
Benutzer unzugänglich
werden. Da das Verarbeiten weichen muss, um das Sichern zuzulassen,
verfügt
dieses Verfahren selbstverständlich nicht über Echtzeitkapazitäten. Dasselbe
gilt für Fernsicherungsstrategien,
von denen die DB-Leistungsfähigkeit
zusätzlich
in Anspruch genommen wird. Während
Echtzeitkapazitäten
nicht erreicht werden, ist die Installation jedes dieser Datensicherungssysteme
eine zeitraubende und schwierige Aufgabe für den Datenbankadministrator
(DBA).
-
Daher
besteht eine Notwendigkeit eines Online-Fern-Informationssicherungssystems.
-
KURZDARSTELLUNG
DER ERFINDUNG
-
Gemäß der Erfindung
wird ein Echtzeit-Informationssicherungssystem vorgelegt, sowie
ein Verfahren zur Durchführung
von Echtzeit-Informationssicherung,
wie ausgeführt
in den einzelnen Ansprüchen.
-
Die
Datensicherungstechnik der vorliegenden Erfindung ist auf der Gerätetreiberebene
implementiert und erreicht die Sicherung durch "Klonen" jeder Veränderung des lokalen Systems
auf einem netzwerkverbundenen entfernten System.
-
Die
Vorteile dieses Systems verglichen mit den bisher bekannten Verfahren
nach dem Stand der Technik sind: Es ist leicht zu installieren,
die Sicherung erfolgt auf Gerätetreiberebene,
es erfordert keine Systemveränderungen,
und es ist leicht zu implementieren und zu warfen. Da die Sicherung
auf Gerätetreiberebene
erfolgt, ist sie völlig
transparent sowohl für
das Betriebssystem als auch für
die Anwendungsprogramme auf dem lokalen System, folglich ist nach
Installation kein weiterer Benutzereingriff erforderlich, es ist
wirtschaftlich und effizient, es leistet die gesamte systemweite
Echtzeit-online-Fernsicherung zu den minimalen Kosten eines Gerätetreibers.
-
Diese
und andere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung
werden näher
erläutert
in der nachfolgenden detaillierten Beschreibung bevorzugter Ausgestaltungen
der Erfindung, wie in den beiliegenden Zeichnungen dargestellt.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
1 zeigt
ein Blockdiagramm eines Online-Fern-Informationssicherungssystems;
-
2 zeigt
ein Blockdiagramm einer Kommunikation zwischen dem lokalen System
und dem entfernten System des Informationssicherungssystems der 1;
-
3 zeigt
ein Diagramm eines Einzel-Schreibleistungsvergleichs;
-
4 zeigt
ein Diagramm eines Block-Schreibleistungsvergleichs; und
-
5 zeigt
ein Diagramm eines Block-Schreibleistungsvergleichs.
-
DETAILLIERTE
BESCHREIBUNG DER ERFINDUNG
-
1 zeigt
ein Blockdiagramm eines Online-Fern-Informationssicherungssystems 10.
Das System 10 umfasst ein lokales System 12 und
ein Fernsicherungssystem 14, das über ein Kommunikationsmedium 16 verbunden
sein kann, wie beispielsweise LAN, WAN, Internet usw.
-
Das
lokale System 12 umfasst einen Plattenspeicher 18 (z.B.
mehrere Festplatten in Anordnung einer RAID Architektur) der mit
einem Festplattentreiber 20 gekoppelt ist. Der Festplattentreiber 20 ist
gekoppelt mit einem Disk Cashing Disk (DCD) Gerätetreiber 22, der
mit einem Plattentreiber 24 eines Echtzeit-online-fern-Informationssicherungssystems (RORIB:
Realtime Online Remote Information Backup) kommuniziert. Die DCD
Architektur wird offenbart in der US-Patentschrift 5,754,888 mit
dem Titel "System
for Destaging Data During Idle Time By Transferring to Destage Buffer,
Marking Segment Blank, Reordering Data in a Buffer, and Transferring
to Beginning of Segment" und
in der US-Patentschrift 6,243,795 mit dem Titel "Redundant Asymmetrically Parallel Disk
Cache for a Data Storage System",
beide hiermit durch Bezugnahme inkorporiert.
-
Der
RORIB Gerätetreiber 24 ist
transparent für
ein Benutzersystem 26 (z.B. ein Dateisystem und Anwendungsprogramme)
wie etwa ein Datenbankmanagementsystem (DBMS). Der RORIB Gerätetreiber 24 erfordert
keine Veränderungen
am vorhandenen Betriebssystem oder am physikalischen Datenlayout.
Folglich kann er wie ein "Drop-In" Filter verwendet
werden zwischen dem üblichen
Festplattengerätetreiber
und dem Dateisystem.
-
Der
RORIB Gerätetreiber 24 wirkt
als Brücke zwischen
dem Dateisystem 26 und den Gerätetreibern auf niedrigerer
Ebene, wie etwa einem NIC Treiber 28 und dem Festplattentreiber 20.
Zwischen dem RORIB Treiber und dem Raw Disk Treiber 20 befindet
sich der DCD Treiber 22, der geringe Schreibleistung erhöht. Eine
derartige mehrschichtige Gerätetreiberstruktur
reduziert den Aufwand bei der Implementierung und erhöht die Übertragbarkeit.
-
Das
entfernte System 14 umfasst einen NIC Treiber 50,
der Anfragen und Daten empfängt,
die von dem lokalen System 12 über das Netzwerk 16 gesendet
werden. Der NIC Treiber gibt die Anfragen und Daten an einen RORIB
Servergerätetreiber 52 weiter,
der die Daten auf eine Festplatte 54 des Sicherungssystems
schreibt, über
einen DCD Gerätetreiber 56 und
einen Festplattentreiber 58 des entfernten Systems. Der
RORIB Servergerätetreiber 52 reagiert
auch auf Anfragen von einem Serveranwendungsdateisystem 60.
-
Zum
Sichern von Daten, die auf die lokale Festplatte 18 zu
schreiben sind, schreibt der RORIB Klientgerätetreiber 24 auch
die lokalen Daten auf den lokalen NIC Treiber 28, der die
Daten an das Netzwerk 16 übergibt. Der RORIB Servergerätetreiber 52 empfängt dann
die lokalen über
das Netzwerk 16 kommunizierten Daten und schreibt die Daten
auf die Sicherungsfestplatte 54.
-
Der
RORIB Treiber 24 empfängt
verschiedene Befehle von dem Dateisystem 26 zum Zugriff
auf die lokale Festplatte 18. Zugriffe auf die lokale Festplatte 18 erfordern
eine Feststellung, ob die lokale Festplatte 18 aktiv oder
inaktiv ist, um die von dem Dateisystem 26 angefragten
Befehle auszuführen. Daher
stellt der RORIB Treiber 24 fest, ob die lokale Festplatte 18 aktiv
oder inaktiv ist. Der RORIB Treiber 24 sendet Befehle an
den DCD Treiber 22, um den Status der lokalen Festplatte
abzufragen. Der DCD Treiber 22 benachrichtigt dann den
lokalen Festplattentreiber 20, um zu prüfen, ob die lokale Festplatte 18 aktiv
ist. Der lokale Festplattentreiber 20 benachrichtigt den
DCD Treiber 22 von seiner Feststel lung, und der DCD Treiber 22 macht
diese Feststellung dem RORIB Treiber 24 verfügbar. Wenn
festgestellt wird, dass die lokale Festplatte 18 inaktiv
ist, gibt der RORIB Treiber 24 einen Aufruf an den NIC
Treiber 28 aus, eine Verbindung herzustellen mit dem entfernten
Sicherungssystem 14, um auf die Sicherungsdaten zuzugreifen.
Der NIC Treiber 28 macht eine Schnittstelle verfügbar zwischen
dem Kommunikationsnetzwerk 16 und einem Rechnersystem,
welches das Fernsicherungssystem 14 umfasst. Der NIC Treiber
stellt auch das notwendige Protokoll zur Verfügung, wie zum Beispiel ein
TCP/IP, das zum Senden und Empfangen von Mitteilungen aus dem Netz 16 notwendig
ist.
-
Wenn
eine Verbindung aufgebaut ist, geht das Fernsicherungssystem 14 dazu über, eine
Sicherungstechnik verfügbar
zu machen, die für
das Dateisystem 26, für
die Anwendungen und Benutzer des lokalen Systems 12 transparent
ist. Der entfernte NIC Treiber 50 empfängt und sendet Mitteilungen über das
Netzwerk 16. Wenn der entfernte NIC Treiber 50 einen
Aufruf vom lokalen NIC Treiber 28 empfängt, und die lokale Festplatte 18 nicht
aktiv ist, verarbeitet der entfernte NIC Treiber 50 die
Mitteilung und formatiert die Mitteilung so, dass es zur Verarbeitung
durch das RORIB 52 geeignet ist. Das RORIB 52 sendet
einen Aufruf an den DCD Treiber 56, der, wenn das erforderlich
ist, einen Aufruf an den Festplattentreiber 58 ausgibt
zum Verarbeiten von Befehlsaufrufen von dem RORIB 52. Auch
das Dateisystem 60 kann Aufrufe an das RORIB 52 ausgeben
zur Verarbeitung von internen Befehlen an das Fernsicherungssystem 14.
-
2 zeigt
ein Blockdiagramm einer Kommunikation zwischen dem lokalen System 12 und dem
entfernten System 14 des Informationssicherungssystems
der 1. Ein Treiber gibt eine Dateikennung über einen
verbundenen TCP Socket (nicht gezeigt) an einen Kerneltreiber 30 weiter.
Deshalb muss der Kerneltreiber 30 keine Ressourcen für die Verbindung
aufwenden. Das Protokoll ist wie folgt: wenn der Treiber aufgefor dert
wird, von einem Block Device zu lesen, sendet er ein "Anfrage"-Paket. Wenn die Operation vollständig ist,
antwortet der Server mit einem "Antwort"-Paket. Mit anderen
Worten: Ein Klient (Client) richtet eine Anfrage an eine lokale Quelle
(Ressource) und generiert dadurch eine Reaktion von einem Daemon
(einem speicherresidenten Programm) auf dem Server über den
Treiber. Nach dem Aufbau (Setup) beginnt das Klient/Server Handshake,
wenn der Server mit dem Klient eine Verbindung aushandelt. Wenn
die Initialisierung erfolgreich ist, erfolgt eine Verbindung vor
der Zeitüberschreitung
(Timeout). Die Verbindung wird durch den serverseitigen Daemon automatisch
erhalten, geprüft,
neu vermittelt und wiederhergestellt. Die Wiederherstellung ist
für den
Benutzer transparent, so lange es dabei eine intakte Verbindung
gibt.
-
Der
Daemon ist dazu da, alle Anschlüsse (Ports)
und Subprozesse zu überwachen
und zu erhalten, was für
die Benutzer transparent erfolgt. Auf dem Klient läuft ebenfalls
ein komplementärer
Daemon. Dieser Daemon verarbeitet Kernelanfragen nach Daten auf
der lokalen Festplatte. Die Daten werden dann über das Netzwerk zu dem anfragenden
Server weitergegeben.
-
Der
RORIB Gerätetreiber
vereinigt die Funktionen des Internet Protokoll (IP) Treibers und
des Speichertreibers derart, dass ausgewählte Speichersysteme, die über das
Netzwerk (z.B. das Internet) verbunden sind, dem Benutzer als ein
einheitliches Speichersystem erscheinen. Folglich kann das RORIB
nicht nur Echtzeitdatensicherung verfügbar machen, sondern auch verteilte
Datendienste für
ein Unternehmen oder eine Organisation mit dezentralisierten Standorten.
-
Das
Verfahren kann entweder unter Verwendung von Software auf Gerätetreiberebene
durchgeführt
werden oder unter Verwendung von Hardware auf Controllerebene. Eine
Testanordnung wurde unter Ver wendung von Software auf Gerätetreiberebene
unter Linux OS durchgeführt.
-
Die
Sicherungstechnik der vorliegenden Erfindung ist auf Treiberebene
implementiert und erfordert daher keine Änderung an dem Betriebssystem (OS)
und an den Softwareanwendungen. Dadurch reduziert sich der Aufwand,
wobei eine frühere
Erfindung des Anmelders verwendet wird, bezeichnet als DCD (Disk
Cashing Disk), um Echtzeit-online-Datensicherung Wirklichkeit werden
zu lassen.
-
Für die direkte
Kommunikation des Gerätetreibers
mit der Hardware der Festplatte wurde eine mehrschichtige Gerätetreiberstruktur
verwendet. Die Implementierung wurde dadurch erreicht, dass der RORIB
Gerätetreiber
oberhalb der traditionellen Gerätetreiber
angebracht wurde (Gerätetreiber
sind hardwarespezifisch). Der RORIB Treiber ruft den Plattentreiber
und den NIC Treiber auf niedrigerer Ebene auf, über die Standardschnittstelle
der Gerätetreiber,
die konkreten Ein-/Ausgabe Operationen durchzuführen. Dieser Ansatz hat drei
wesentliche Vorteile gegenüber
bisherigen Strukturen. Erstens wird der Implementierungsaufwand
beträchtlich
vereinfacht, da der RORIB Treiber die komplexe Aufgabe direkter
Kommunikation mit der Hardware vermeidet. Zweitens funktioniert
ein und derselbe RORIB Treiber mit allen Arten von Platten und NICs
in dem System, da alle Plattengerätetreiber auf niedriger Ebene
eine Standardschnittstelle benutzen. Drittens ist es leicht, die
derzeitige Implementierung auf andere Linux Systeme zu übertragen.
-
Die über das
Netzwerk (z.B. das Internet) zwischen dem lokalen und dem entfernten
System übertragenen
Daten können
mittels SSL (Secure Socket Layer) verschlüsselt werden, damit Datensicherheit
gegeben ist.
-
Linux
wird als Betriebssystem verwendet. Es ist möglich, spezifische Gerätetreiber
zu schreiben und zu integrieren. Die Gerätetreiber für eine Klasse von Block Devices
sehen klassenspezifische Schnittstellen für diese Geräteklasse vor.
-
Linux
unterstützt
mehrere verschiedene Block Device Treiber. Ein derartiges Gerät ist ein
Network Block Device (NBD) Treiber, der mittels TCP Protokollschicht
bewirkt, dass eine entfernte Quelle aussieht wie ein lokales Gerät. NBD existiert
als Kernelmodul, das heißt,
es kann jederzeit geladen oder entfernt werden.
-
Ein
Prototyp eines RORIB Gerätetreibers wurde
entworfen und individuell getestet (Loopback), bevor er in ein Netzwerk
integriert wurde. PostgreSQL wurde als DBMS verwendet. Die Systemkonfiguration
bestand aus zwei über
Netzwerk verbundenen PCs. Java Servtet läuft auf dem Webbrowser zur Messung
der Leistung. Zwei Reihen von Experimenten wurden durchgeführt. Das
erste Experiment verglich Einzellese- und Einzelschreibleistung der vorgeschlagenen
Sicherungsstrategie mit den bereits erörterten Sicherungsverfahren.
Das zweite Experiment verglich Blocklese- und Blockschreibleistung
in unterschiedlichen Zeitintervallen, um eine wirklichkeitsnahe
Umgebung zu simulieren, mit Multiklientverbindungen, wieder im Vergleich
zu verbreiteten Strategien.
-
Die
Ergebnisse des ersten Experiments waren wie folgt. Die Lesegeschwindigkeit
der vorgeschlagenen Sicherungsstrategie ist gleich der existierender
Verfahren an einer einzelnen Datenbank. Das ist erwartungsgemäß, denn
Datensicherung erfolgt nicht, bis die Datenbank aktualisiert wird.
-
Verbreitete
Datensicherungsverfahren sind gänzlich
ein Softwareprozess des DBMS. Sicherung erfolgt auf der Anwendungsebene. 3 zeigt
den Schreibleistungsvergleich für
einen Einzelschreibvorgang. In graphi scher Darstellung entspricht
Kurve 32 (Strategie 1) einem einmaligen Schreibvorgang
in eine einzelne Datenbank (keine Sicherung). Strategie 2,
Kurve 34, bestand in internetbasiertem Echtzeitonlinesichern
unter Verwendung des Gerätetreiberprototyps.
Strategie 3, Kurve 36, bestand darin, in zwei
Dateien auf verschiedenen lokalen Festplatten ein und derselben
Datenbank an einem Arbeitsplatz (Workstation) zu schreiben. Dieses
Vorgehen simuliert eine lokale Sicherungslösung auf Anwendungsebene. Strategie 4,
Kurve 38, bestand darin, in Datenbanken an zwei Arbeitsplätzen über das
Internet zu schreiben. Das simuliert eine Fernsicherungslösung auf
Anwendungsebene. Dieses Experiment zeigt, dass die Sicherungsstrategie,
die auf dem vorgeschlagenen Treiber basiert (Strategie 2),
höhere Schreibgeschwindigkeit
aufweist als die anderen Sicherungsstrategien (Strategie 3 und
Strategie 4). Das ist erwartungsgemäß, da Strategie 2 Überlastungen
auf Anwendungsebene eliminiert. Veränderungen in Hardwarekonfiguration
und Netzwerkinfrastrukturaufbau wirken sich auf die Sicherungsleistung
aus.
-
Das
zweite Experiment betrifft Blockschreibleistung unter verschiedenen
Arbeitsbelastungen und in verschiedenen Zeitintervallen, wie in 4 gezeigt.
Man beachte, dass die Blockleseleistung ähnlich der Einzelleseleistung
ist. Jeder Punkt im Diagramm in 4 steht
für die
Reaktionszeit für eine
20fache Datenbankeinfügung
(20 Teilprozesse), wodurch 20 Klienten simuliert
werden, die den Datenbankserver in verschiedenen Zeitintervallen
nutzen. Wie in 4 gezeigt, gibt es Fluktuationen
in der Reaktionszeit, was durch Konkurrenz verursacht ist. Strategie 1,
Kurve 40, (keine Sicherung) und Strategie 2, Kurve 42 (RORIB)
haben immer noch ähnliche Reaktionszeit
für Datenbankabfragen,
denn Strategie 2, Kurve 42, vermeidet Überlastung
auf Anwendungsebene bei der Durchführung von Online-Echtzeit-Informationssicherung.
Strategie 3, Kurve 44 (lokale Sicherung auf Anwendungsebene)
zeigt längere Reaktionszeit
als Strategie 4, Kurve 46, (Fernsicherung auf
Anwendungsebene) unter höherer
Arbeitsbelastung, wie in 5 gezeigt. An diesem Punkt verur sacht
Konkurrenz um lokale Rechnerquellen mehr Zeitverzögerung als
Konkurrenz im Netzverkehr. Wenn allerdings weniger lokale Konkurrenz
besteht, wird die Konkurrenz im Netzverkehr deutlicher erkennbar
als die Konkurrenz um lokale Quellen, wie in 5 gezeigt.
-
Die
Datensicherungstechnik der vorliegenden Erfindung ist auf Gerätetreiberebene
implementiert. Daher ist sie transparent für den Benutzer, das Dateisystem
und die Anwendungprogramme, wie etwa DBMS. Sie erfordert keine Änderungen
des vorhandenen Betriebssystems oder der physikalischen Dateistruktur.
Folglich kann sie wie ein "Drop-In" Filter verwendet
werden zwischen dem traditionellen Plattengerätetreiber und dem Dateisystem
in einem existierenden System und erlangt sofortige Funktionalität.
-
Ein
Prototyp des beschriebenen RORIB Gerätetreibers wurde getestet.
Die Ergebnisse des vorgeschlagenen Treibers zeigen bedeutende Leistungsverbesserungen
gegenüber
verbreiteten Sicherungsstrategien. Diese Leistungssteigerung wird ohne
eine wesentliche Kostenerhöhung
erreicht, wie sie bei Verwendung eines PBN oder SAN eintreten würde, also
liegt eine wirtschaftlich extrem wertvolle Lösung gegenüber den gegenwärtigen Alternativen vor.
-
Zu
der Verbesserung kommt es, weil zusätzliche Verarbeitungsanforderungen
von der Anwendungsebene auf die Gerätetreiberebene verlagert werden.
Durch Nutzung der vorhandenen Verarbeitungskapazität der Hardwaretechnologie
kann das zu zusätzlichen
Kapazitäten
im Dateimanagement führen,
die in den Hardwaregeräten
eher liegen als in dem verbreiteten langsameren Softwareansatz,
der gegenwärtig
zur Anwendung kommt.