Backup für Linux oder Erstellen eines Snapshots

    Hallo an alle! Ich arbeite bei Veeam am Projekt Veeam Agent für Linux. Mit Hilfe dieses Produkts können Sie eine Maschine mit Linux-Betriebssystem sichern. "Agent" im Titel bedeutet, dass Sie mit dem Programm physische Maschinen sichern können. Virtuelle werden ebenfalls gesichert, befinden sich jedoch gleichzeitig auf dem Gastbetriebssystem.

    Die Inspiration für diesen Artikel war mein Bericht auf der Linux Piter- Konferenz , die ich als Artikel für alle interessierten Künstler herausgeben wollte.

    In diesem Artikel werde ich das Thema der Erstellung von Momentaufnahmen behandeln, mit dem Sie eine Sicherungskopie erstellen und über die Probleme informieren können, mit denen wir beim Erstellen unseres eigenen Mechanismus zum Erstellen von Momentaufnahmen von Blockgeräten konfrontiert waren.

    Alle interessiert an Fragen unter der Katze!



    Am Anfang ein bisschen Theorie


    In der Vergangenheit gibt es zwei Ansätze zum Erstellen von Sicherungen: Dateisicherung und Volumensicherung. Im ersten Fall kopieren wir jede Datei als separates Objekt, im zweiten kopieren wir den gesamten Inhalt des Datenträgers als Bild.

    Beide Methoden haben viele Vor- und Nachteile, aber wir werden sie nach einem Misserfolg durch das Prisma der Genesung betrachten:

    • Bei der Dateisicherung müssen Sie zunächst das Betriebssystem und dann die erforderlichen Dienste installieren, um den Server als Ganzes vollständig wiederherstellen zu können, und erst danach die Dateien aus der Sicherung wiederherstellen.
    • Bei einer Volumensicherung reicht es für eine vollständige Wiederherstellung aus, nur alle Volumes der Maschine ohne zusätzlichen Aufwand von der Person wiederherzustellen.

    Offensichtlich können Sie im Falle einer Volume-Sicherung das System so schnell wie möglich wiederherstellen. Dies ist eine wichtige Funktion des Systems . Daher halten wir für uns das Volume-Backup für eine bevorzugte Option.

    Wie nehmen und behalten wir das gesamte Volumen vollständig? Natürlich werden wir durch einfaches Kopieren nichts Gutes erreichen. Während des Kopierens werden auf dem Datenträger einige Aktivitäten mit Daten ausgeführt, wodurch inkonsistente Daten in der Sicherung angezeigt werden. Die Dateisystemstruktur wird beschädigt, Datenbankdateien werden beschädigt, und andere Dateien, mit denen Operationen während des Kopierens ausgeführt werden.

    Um all diese Probleme zu vermeiden, hat die progressive Menschheit eine Momentaufnahme-Technologie erfunden - eine Momentaufnahme. Theoretisch ist alles einfach: Erstellen Sie eine unveränderliche Kopie (Momentaufnahme) und sichern Sie die Daten davon. Wenn die Sicherung abgeschlossen ist, wird der Snapshot zerstört. Es klingt einfach, aber wie immer gibt es Nuancen.

    Aufgrund dieser wurden viele Implementierungen dieser Technologie geboren. Zum Beispiel bieten Device-Mapper- basierte Lösungen wie LVM und Thin Provisioning zwar vollständige Volume-Snapshots, erfordern jedoch bei der Systeminstallation eine spezielle Datenträgerauszeichnung, was bedeutet, dass sie im Allgemeinen nicht geeignet sind.

    BTRFS und ZFS bieten die Möglichkeit, Momentaufnahmen von Dateisystem-Unterstrukturen zu erstellen, was sehr cool ist, aber im Moment ist der Anteil auf den Servern gering, und wir versuchen, eine universelle Lösung zu schaffen.

    Angenommen, es gibt ein banales EXT auf unserem Blockgerät. In diesem Fall können wir dm-snap verwenden (übrigens wird ein dm-Bogen entwickelt ), hier jedoch eine Nuance. Sie müssen ein freies Blockgerät bereithalten, damit die Snapshot-Daten dort abgelegt werden können.
    Bei der Beachtung alternativer Sicherungslösungen stellten wir fest, dass sie in der Regel ihr Kernelmodul verwenden, um Snapshots von Blockgeräten zu erstellen. Wir haben uns entschieden, diesen Weg zu gehen, indem wir unser eigenes Modul schreiben. Es wurde beschlossen, es unter der GPL-Lizenz zu vertreiben, so dass es auf github öffentlich verfügbar ist .

    Wie es funktioniert - theoretisch


    Schnappschuss unter dem Mikroskop


    Wir werden uns nun mit dem allgemeinen Funktionsprinzip des Moduls beschäftigen und werden im Einzelnen auf Kernprobleme eingehen.

    Tatsächlich ist veeamsnap (wie wir unser Kernelmodul nennen) ein Blockgerätetreiberfilter.



    Seine Aufgabe ist es, Anfragen an den Blockgerätetreiber abzufangen.

    Das Modul fängt die Schreibanforderung ab und kopiert Daten vom ursprünglichen Blockgerät in den Snapshot-Datenbereich. Nennen wir dieses Gebiet Snapstory.



    Und was ist der Schnappschuss selbst? Dies ist ein virtuelles Blockgerät, eine Kopie des Originalgeräts zu einem bestimmten Zeitpunkt. Wenn Sie auf Datenblöcke auf diesem Gerät zugreifen, können sie entweder aus Snapstores oder vom Originalgerät gelesen werden.

    Ich möchte darauf hinweisen, dass der Snapshot ein Blockgerät ist, das zum Zeitpunkt der Snapshot-Entfernung vollständig mit dem Original identisch ist. Dank dessen können wir das Dateisystem als Momentaufnahme einbinden und die erforderliche Vorverarbeitung durchführen.

    Zum Beispiel können wir eine Karte mit belegten Blöcken aus dem Dateisystem erhalten. Der einfachste Weg, dies zu tun, ist die Verwendung von ioctl GETFSMAP .
    Mit den Daten zu den belegten Blöcken können Sie nur tatsächliche Daten aus dem Schnappschuss lesen.

    Sie können auch einige Dateien ausschließen. Nun, eine ganz optionale Aktion: Indexieren Sie Dateien, die in das Backup fallen, für die Möglichkeit eines granularen Restaurants in der Zukunft.

    CoW gegen RoW


    Lassen Sie uns ein wenig auf die Wahl des Schnappschuss-Algorithmus eingehen. Die Auswahl ist hier nicht besonders umfangreich: Copy-on-Write oder Redirect-on-Write .

    Beim Umleiten beim Schreiben wird eine Schreibanforderung abgefangen und zum Snapstore umgeleitet, wonach alle Anforderungen zum Lesen dieses Blocks dorthin gehen. Bemerkenswerter Algorithmus für Speichersysteme basierend auf B + -Bäumen wie BTRFS, ZFS und Thin Provisioning. Die Technologie ist so alt wie die Welt, aber sie zeigt sich besonders gut in Hypervisoren. Dort können Sie eine neue Datei erstellen und dort für die Dauer des Schnappschusses neue Blöcke schreiben. Die Leistung ist im Vergleich zu CoW hervorragend. Es gibt jedoch ein schweres Minus - die Struktur des ursprünglichen Geräts ändert sich, und wenn Sie den Schnappschuss entfernen, müssen Sie alle Blöcke aus den Snapstores an den ursprünglichen Ort kopieren.

    Beim Abfangen einer Anforderung kopiert Copy-on-Write die Daten in den Snapshot, der geändert werden soll, und lässt sie an ihrem ursprünglichen Ort überschreiben. Zum Erstellen von Momentaufnahmen für LVM-Volumes und Schattenkopien von VSS. Offensichtlich ist es besser geeignet, Momentaufnahmen von Blockgeräten zu erstellen. ändert die Struktur des ursprünglichen Geräts nicht, und wenn Sie löschen (oder abstürzen), können Snapshots einfach gelöscht werden, ohne die Daten zu gefährden. Der Nachteil dieses Ansatzes ist eine Verringerung der Leistung, da zu jeder Schreiboperation ein Paar Lese- / Schreiboperationen hinzugefügt wird.

    Da der Erhalt der Daten für uns oberste Priorität hat, haben wir uns für CoW entschieden.

    Bisher sieht alles einfach aus, also werfen wir einen Blick auf die realen Probleme.

    Wie es funktioniert - in der Praxis


    Vereinbarte Bedingung


    Um seinetwillen und alle Gedanken.
    Wenn zum Beispiel zum Zeitpunkt der Erstellung eines Schnappschusses (in erster Näherung kann davon ausgegangen werden, dass er sofort erstellt wird), wird eine Datei in eine Datei geschrieben, und im Schnappschuss ist die Datei undefiniert, was bedeutet, dass sie beschädigt und ohne Bedeutung ist. Bei den Datenbankdateien und dem Dateisystem selbst ist die Situation ähnlich.

    Aber wir leben im 21. Jahrhundert! Es gibt Journalmechanismen, die vor solchen Problemen schützen! Die Bemerkung ist wahr, es gibt jedoch ein wichtiges „Aber“: Dieser Schutz ist nicht vor dem Scheitern, sondern vor dessen Folgen. Beim Wiederherstellen in einen konsistenten Zustand gemäß dem Protokoll werden die unvollständigen Vorgänge verworfen, was bedeutet, dass sie verloren gehen. Daher ist es wichtig, die Priorität auf den Schutz gegen die Ursache zu verlagern und nicht die Folgen zu behandeln.

    Das System kann gewarnt werden, dass die Momentaufnahme erstellt wird. Zu diesem Zweck verfügt der Kernel über die Funktionen freeze_bdev und thaw_bdev . Sie ziehen die Dateisystemfunktionen freeze_fs und unfreeze_fs ab. Beim ersten Aufruf muss das System den Cache zurücksetzen, die Erstellung neuer Anforderungen an das Blockgerät unterbrechen und warten, bis alle zuvor generierten Anforderungen abgeschlossen sind. Wenn unfreeze_fs aufgerufen wird, stellt das Dateisystem seinen normalen Betrieb wieder her.

    Es stellt sich heraus, dass wir das Dateisystem warnen können. Und was ist mit den Anwendungen? Hier ist leider alles schlecht. In Windows gibt es einen VSS- MechanismusMit Hilfe von Writers bietet Interaktion mit anderen Produkten. In Linux geht jeder seinen eigenen Weg. Im Moment hat dies dazu geführt, dass die Aufgabe des Systemadministrators darin besteht, die Skripts zum Einfrieren und Nachauftauen zu schreiben (zu kopieren, zu stehlen , zu kaufen usw.), die ihre Anwendung für Momentaufnahmen vorbereiten. In unserem nächsten Release werden wir die Unterstützung für Oracle Application Processing einführen, die von unseren Kunden am häufigsten geforderte Funktion ist. Dann werden vielleicht andere Anwendungen unterstützt, aber im Allgemeinen ist die Situation eher traurig.

    Wo platzieren Sie Snapstoru?


    Dies ist das zweite Problem auf unserem Weg. Auf den ersten Blick ist das Problem nicht offensichtlich, aber wenn wir ein wenig verstanden haben, werden wir feststellen, dass dies immer noch ein Dorn im Auge ist.

    Natürlich ist es die einfachste Lösung, den Snapstore im RAM abzulegen. Für den Entwickler ist die Option einfach großartig! Alles ist schnell, es ist sehr praktisch zum Debuggen, aber es gibt eine Überlegung: RAM ist eine wertvolle Ressource, und niemand wird uns einen großen Snapstore geben.

    OK, lassen Sie uns Snapstore eine reguläre Datei machen. Ein anderes Problem tritt jedoch auf: Es ist nicht möglich, das Volume, auf dem sich der Snapstore befindet, zu sichern. Der Grund ist einfach: Wir fangen Anforderungen für die Aufnahme ab, was bedeutet, dass wir unsere eigenen Anforderungen für die Aufnahme in Snapstore abfangen werden. Pferde liefen in Kreisen, wissenschaftlich festgefahren. Dann besteht der Wunsch, eine separate Festplatte zu verwenden, aber niemand wird dem Server für uns Festplatten hinzufügen. Wir müssen an dem arbeiten können, was ist.

    Eine Momentaufnahme aus der Ferne platzieren - die Idee ist ausgezeichnet, aber in sehr engen Kreisen von Netzwerken mit hoher Bandbreite und mikroskopischer Latenzzeit realisierbar. Andernfalls hat die Maschine, während sie den Schnappschuss hält, eine rundenbasierte Strategie.

    Daher müssen Sie den Snapshot auf eine lokale Festplatte kopieren. In der Regel ist jedoch der gesamte Speicherplatz auf lokalen Festplatten bereits auf Dateisysteme verteilt, und gleichzeitig müssen wir uns überlegen, wie das Deadlock-Problem gelöst werden kann.

    Die Richtung des Denkens ist im Prinzip eine Sache: Sie müssen irgendwie Speicherplatz aus dem Dateisystem zuweisen, arbeiten jedoch direkt mit dem Blockgerät. Die Lösung für dieses Problem wurde im Benutzerraumcode im Dienst implementiert.

    Es gibt einen Fallocate -Systemaufruf , mit dem Sie eine leere Datei der gewünschten Größe erstellen können. In diesem Fall werden in dem Dateisystem tatsächlich nur Metadaten erstellt, die den Speicherort der Datei auf dem Volume beschreiben. Und mit ioctl FIEMAP können wir eine Karte des Standorts der Dateiblöcke erhalten.

    Und voila: Wir erstellen eine Datei unter snapstore mit fallocate, FIEMAP gibt uns eine Karte des Speicherorts der Blöcke dieser Datei, die wir in unser Modul veeamsnap übertragen können. Wenn Sie auf SnapStop zugreifen, stellt das Modul außerdem Anforderungen in bekannten Blöcken und keine Deadlocks direkt an das Blockgerät.

    Aber es gibt eine Nuance. Der Fallocate-Systemaufruf unterstützt nur XFS, EXT4 und BTRFS. Bei anderen Dateisystemen wie EXT3 müssen Sie die Datei vollständig aufschreiben, um eine Datei zuzuordnen. Auf der Funktionsweise wirkt sich dies auf die Verlängerung der Zeit für die Vorbereitung von Schnappstöcken aus, aber es ist keine Auswahl erforderlich. Wieder müssen Sie in der Lage sein, an dem zu arbeiten, was ist.

    Und was ist, wenn ioctl FIEMAP auch nicht unterstützt wird? Dies ist die Realität von NTFS und FAT32, wo die alte FIBMAP nicht einmal unterstützt wird. Ich musste einen generischen Algorithmus implementieren, dessen Arbeit nicht von den Funktionen des Dateisystems abhängt. Kurz gesagt, der Algorithmus ist:

    1. Der Dienst erstellt eine Datei und beginnt, ein bestimmtes Muster zu schreiben.
    2. Das Modul fängt Anforderungen zur Aufzeichnung ab und prüft die aufgezeichneten Daten.
    3. Wenn die Daten des Blocks dem angegebenen Muster entsprechen, wird der Block als zum Snapstore gehörig markiert.

    Ja, schwierig, ja, langsam, aber besser als nichts. Es wird in Einzelfällen für Dateisysteme ohne die Unterstützung von FIEMAP und FIBMAP verwendet.

    Snapshot-Überlauf


    Vielmehr endet der Platz, den wir für den Snapstor zugewiesen haben. Der Kern des Problems besteht darin, dass neue Daten nirgends verworfen werden müssen, was bedeutet, dass die Momentaufnahme unbrauchbar wird.
    Was zu tun ist?

    Offensichtlich müssen Sie die Größe der Momentaufnahmen erhöhen. Wie viel Die einfachste Methode zum Festlegen der Größe von Momentaufnahmen ist die Bestimmung des Prozentsatzes an freiem Speicherplatz auf dem Volume (wie bei VSS). Für ein 20-TB-Volume werden 10% 2 TB sein - was für einen entladenen Server eine Menge ist. Bei einem Volumen von 200 GB sind 10% 20 GB, was für einen Server, der seine Daten intensiv aktualisiert, möglicherweise zu klein ist. Und es gibt noch dünne Bände ...

    Im Allgemeinen kann nur der Systemadministrator des Servers die optimale Größe der erforderlichen Snapshots im Voraus abschätzen, das heißt, Sie müssen die Person dazu bringen, nachzudenken und ein Expertengutachten abzugeben. Dies steht nicht im Einklang mit dem Prinzip "Es funktioniert einfach".

    Um dieses Problem zu lösen, haben wir den Stretch-Snapshot-Algorithmus entwickelt. Die Idee ist, Schnappschüsse in Brocken aufzubrechen. Gleichzeitig werden nach der Erstellung von Momentaufnahmen neue Teile erstellt.



    Wieder ein kurzer Algorithmus:

    1. Vor dem Erstellen des Snapshots wird der erste Teil des Snapshots erstellt und an das Modul übergeben.
    2. Wenn der Schnappschuss erstellt wird, füllt sich der Teil.
    3. Sobald die Hälfte des Teils gefüllt ist, wird eine Anforderung an den Dienst gesendet, um einen neuen zu erstellen.
    4. Dienst erstellt es, gibt die Daten an das Modul.
    5. Das Modul füllt die nächste Charge.
    6. Der Algorithmus wird so lange wiederholt, bis entweder die Sicherung abgeschlossen ist oder bis die Auslastung des freien Speicherplatzes erreicht ist.

    Es ist wichtig zu wissen, dass das Modul Zeit haben sollte, neue Teile von Snapstores nach Bedarf zu erstellen, andernfalls Überlauf, Dump-Snapshots und keine Sicherung. Der Betrieb eines solchen Algorithmus ist daher nur auf Dateisystemen möglich, die Fallocate unterstützen, wo Sie schnell eine leere Datei erstellen können.

    Was ist in anderen Fällen zu tun? Wir versuchen die erforderliche Größe zu erraten und erstellen den gesamten Snapstor vollständig. Laut unserer Statistik verwenden mittlerweile die meisten Linux-Server EXT4 und XFS. EXT3 wird auf älteren Maschinen gefunden. In SLES / openSUSE können Sie jedoch auf BTRFS stoßen.

    Blockverfolgung ändern (CBT)


    Inkrementelle oder differenzielle Unterstützung (übrigens ist Rettich-Meerrettich süßer oder nicht, ich schlage vor, hier zu lesen ) - ohne sie ist kein Erwachsenenprodukt für die Sicherung vorstellbar. Und damit dies funktioniert, brauchen Sie CBT. Wenn jemand versäumt hat: CBT ermöglicht es Ihnen, Änderungen zu verfolgen und nur die Daten der letzten Sicherung in die Sicherung zu schreiben.



    Viele Menschen haben auf diesem Gebiet ihre eigenen Erfahrungen. In VMware vSphere ist diese Funktion beispielsweise ab Version 4 in 2009 verfügbar. Die Unterstützung für Hyper-V wurde mit Windows Server 2016 eingeführt. 2012 wurde ein eigener VeeamFCT-Treiber entwickelt, um frühere Versionen zu unterstützen. Daher haben wir für unser Modul nicht begonnen, bereits funktionierende Algorithmen zu verwenden.
    Ein bisschen darüber, wie es funktioniert.



    Das gesamte überwachte Volumen ist in Blöcke unterteilt. Das Modul verfolgt einfach alle Schreibanforderungen und markiert die geänderten Blöcke in der Tabelle. Tatsächlich ist die CBT-Tabelle ein Byte-Array, wobei jedes Byte einem Block entspricht und die Nummer der Momentaufnahme enthält, in der es geändert wurde.
    Während des Backups wird die Snapshot-Nummer in die Backup-Metadaten geschrieben. Wenn Sie die aktuelle Momentaufnahme-Nummer und die Nummer kennen, von der die vorherige Sicherung erfolgreich durchgeführt wurde, können Sie die Karte des Speicherorts der geänderten Blöcke berechnen.

    Es gibt zwei Nuancen.

    Wie gesagt, der Snapshot-Nummer in der CBT-Tabelle wird ein einzelnes Byte zugewiesen. Dies bedeutet, dass die maximale inkrementelle Kettenlänge nicht größer als 255 sein darf. Wenn dieser Schwellenwert erreicht ist, wird die Tabelle zurückgesetzt und eine vollständige Sicherung erfolgt. Es mag unbequem erscheinen, aber in der Tat ist eine Kette von 255 Inkrementen bei der Erstellung eines Backup-Plans alles andere als die beste Lösung.
    Die zweite Funktion ist die Speicherung von CBT-Tabellen nur im RAM. Dies bedeutet, dass beim Neustart des Zielcomputers oder beim Entladen des Moduls dieses zurückgesetzt wird und Sie erneut eine vollständige Sicherung erstellen müssen. Eine solche Lösung ermöglicht es nicht, das Problem des Startens des Moduls beim Systemstart zu lösen. Außerdem müssen die CBT-Tabellen nicht gespeichert werden, wenn das System ausgeschaltet ist.

    Leistungsproblem


    Backup ist immer eine gute Last für Ihre IO-Geräte. Wenn bereits genügend aktive Aufgaben vorhanden sind, kann der Sicherungsprozess Ihr System in eine Art Faultier verwandeln .
    Mal sehen warum.

    Stellen Sie sich vor, der Server schreibt einfach lineare Daten. Die Aufnahmegeschwindigkeit ist in diesem Fall maximal, alle Verzögerungen werden minimiert, die Leistung ist maximal. Nun fügen wir hier den Sicherungsvorgang hinzu, der bei jedem Schreibvorgang noch Zeit haben muss, um den Copy-on-Write-Algorithmus auszuführen, und dies ist eine zusätzliche Leseoperation, auf die ein Schreibvorgang folgt. Vergessen Sie nicht, dass Sie zur Sicherung auch die Daten von demselben Volume lesen müssen. Kurz gesagt, Ihr schöner linearer Zugriff wird zu einem gnadenlosen Direktzugriff mit allen Konsequenzen.

    Offensichtlich müssen wir etwas unternehmen, und wir haben eine Pipeline implementiert, um Anforderungen nicht einzeln, sondern in ganzen Batches zu verarbeiten. Das funktioniert so.



    Beim Abfangen von Anforderungen werden sie in die Warteschlange gestellt, von wo aus sie durch ihren speziellen Fluss in Portionen abgerufen werden. Zu diesem Zeitpunkt werden CoW-Anforderungen erstellt, die ebenfalls in Chunks verarbeitet werden. Bei der Verarbeitung von CoW-Anforderungen werden zuerst alle Lesevorgänge für den gesamten Stapel ausgeführt, und anschließend werden Schreibvorgänge ausgeführt. Erst nachdem die Verarbeitung des gesamten Teils der CoW-Anforderungen abgeschlossen ist, werden die abgefangenen Anforderungen ausgeführt. Eine solche Pipeline ermöglicht den Datenträgerzugriff auf große Teile der Daten, wodurch temporäre Verluste minimiert werden.

    Throttling


    Bereits in der Phase des Debugging tauchte mehr Nuance auf. Während der Sicherung reagierte das System nicht mehr, d. H. System-E / A-Anforderungen wurden mit langen Verzögerungen gestartet. Andererseits wurden Anforderungen zum Lesen von Daten aus der Momentaufnahme mit einer Geschwindigkeit nahe dem Maximum ausgeführt.
    Ich musste den Backup-Prozess ein wenig durch den Trab-Mechanismus einschränken. Dazu wird der Prozess, der aus dem Snapshot-Image liest, in den Wartezustand übertragen, wenn die Warteschlange der abgefangenen Anforderungen nicht leer ist. Wie erwartet wurde das System lebendig.



    Wenn daher die Belastung des E / A-Systems dramatisch ansteigt, wird der Vorgang des Auslesens aus dem Snapshot abgewartet. Wir haben uns hier für das Prinzip entschieden, dass die Sicherung mit einem Fehler abgeschlossen werden sollte, als den Server zu beschädigen.

    Deadlock


    Ich denke, es ist notwendig, etwas ausführlicher zu erklären, was es ist.

    Bereits in der Testphase begannen wir mit der Diagnose komplizierter Situationen des Gesamtsystems: sieben Probleme - ein Reset.

    Begann zu verstehen. Es stellte sich heraus, dass eine solche Situation beobachtet werden kann, wenn Sie beispielsweise eine Momentaufnahme eines Blockgerätes erstellen, auf dem sich das LVM-Volume befindet, und sich die Momentaufnahme auf demselben LVM-Volume befindet. Ich möchte Sie daran erinnern, dass LVM das Device Mapper-Kernel-Modul verwendet.



    Wenn in diesem Fall eine Schreibanforderung abgefangen wird, sendet das Modul durch Kopieren der Daten in den Snapshot eine Schreibanforderung an den LVM-Datenträger. Der Geräte-Mapper leitet diese Anfrage an ein Blockgerät weiter. Die Anforderung vom Device Mapper wird erneut vom Modul abgefangen. Eine neue Anfrage kann jedoch erst bearbeitet werden, wenn die vorherige Anfrage bearbeitet wurde. Infolgedessen wird die Anforderungsverarbeitung blockiert, und Sie werden von einem Deadlock begrüßt.

    Um dies zu verhindern, wird im Kernel-Modul selbst ein Timeout für das Kopieren von Daten in den Snapshot bereitgestellt. Auf diese Weise können Sie einen Deadlock erkennen und die Sicherung abbrechen. Die Logik hier ist die gleiche: Es ist besser, kein Backup zu machen, als den Server zu hängen.

    Runde Robin-Datenbank


    Dies ist bereits ein Problem, das von Benutzern nach der Veröffentlichung der ersten Version aufgeworfen wurde.
    Es stellte sich heraus, dass es solche Dienste gibt, die die einzigen sind, die die gleichen Blöcke ständig neu schreiben. Ein anschauliches Beispiel ist die Überwachung von Diensten, die ständig Systemzustandsdaten generieren und diese in einem Kreis überschreiben. Verwenden Sie für solche Aufgaben spezielle zyklische Datenbanken ( RRD ).
    Es stellte sich heraus, dass beim Sichern solcher Datenbanken der Snapshot garantiert überläuft. Bei einer detaillierten Untersuchung des Problems haben wir einen Fehler bei der Implementierung des CoW-Algorithmus festgestellt. Wenn derselbe Block überschrieben wurde, wurden die Daten jedes Mal in den Schnappschuss kopiert. Ergebnis: Datenvervielfältigung im Snapstore.



    Natürlich haben wir den Algorithmus geändert. Jetzt ist das Volume in Blöcke unterteilt und die Daten werden in die Snapshot-Blöcke kopiert. Wenn der Block bereits einmal kopiert wurde, wird dieser Vorgang nicht wiederholt.

    Blockgröße auswählen


    Wenn Snapstora nun in Blöcke unterteilt wird, stellt sich die Frage: Welche Größe müssen Blöcke zum Aufteilen von Snapstores bilden?

    Das Problem ist zweifach. Wenn ein Block groß gemacht wird, ist die Bedienung für ihn einfacher. Wenn sich jedoch mindestens ein Sektor ändert, muss der gesamte Block an den Snapshot gesendet werden. Infolgedessen erhöhen sich die Chancen für überlaufende Snapshots.



    Je kleiner die Blockgröße ist, desto höher ist der Prozentsatz an nützlichen Daten, die an den Snapshot gesendet werden. Aber wie wird dies die Leistung beeinflussen?

    Die Wahrheit wurde empirisch gesucht und kam in 16 KB zum Ergebnis. Beachten Sie auch, dass Windows VSS auch 16-KB-Blöcke verwendet.

    Anstelle des Schlusses


    Das ist alles für jetzt. Ich werde viele andere ebenso interessante Probleme über Bord gehen lassen, wie Abhängigkeit von Kernel-Versionen, Auswahl der Modulverteilungsoptionen, Kompatibilität mit kABI, Arbeiten unter Backporting-Bedingungen usw. Der Artikel erwies sich als umfangreich, daher beschloss ich, mich mit den interessantesten Problemen zu beschäftigen.

    Jetzt bereiten wir uns auf die Release-Version 3.0 vor, der Modulcode befindet sich auf Github und kann von jeder unter der GPL-Lizenz verwendet werden.

    Jetzt auch beliebt: