Sheepdog ist ein skalierbares System, das virtuelle Maschinen mit verteilten Blockgeräten versorgt. Die Entwicklung begann 2009 mit Entwicklern des japanischen Unternehmens Nippon Telegraph and Telephone Corporation . Sheepdog ist eine Open Source-Anwendung unter der GPL2-Lizenz. Die neueste Version 0.9.3, die im November 2015 veröffentlicht wurde, ist das Erbe der Version 1.0, die für den kommerziellen Gebrauch geeignet ist 1 . (ist schon geworden - ca. pro.)
Aus Gründen des Interesses wurde die erste Version (0.1.0) im August 2010 von Entwicklern veröffentlicht - und gleichzeitig wurde die Unterstützung für Schäferhunde sofort in den Hauptentwicklungszweig von QEMU aufgenommen.
Die ersten Tests an einem Schäferhund habe ich im November 2011 durchgeführt 2 und die Ergebnisse waren gut für E / A-Operationen. Dann hatte das Sheepdog- System jedoch immer noch Probleme mit der Wiederherstellung des gefallenen Knotens. Dieses Problem wurde wahrscheinlich bald behoben, da die Anwendungsentwicklung ziemlich lebhaft ist, aber zu dieser Zeit habe ich eine andere Lösung verwendet.
Die Möglichkeiten
Das Arbeitsprinzip von Sheepdog ist in der veröffentlichten Präsentation sehr gut beschrieben, daher beschränke ich mich auf einen kurzen Überblick.
Es ist skalierbar
Das Clustervolumen kann sowohl auf Knotenebene willkürlich erhöht werden, wodurch die Kapazität und der Speicherplatz für Daten während des Betriebs erhöht werden, als auch indem die Anzahl der Knoten erhöht wird. Je mehr Knoten vorhanden sind, desto höher ist die Leistung von VDI I / O.
Er ist einfach
Im Gegensatz zu anderen Systemen wie CEPH arbeitet Sheepdog nicht direkt mit dem Dateisystem, sondern arbeitet mit Blöcken fester Größe. Daher sind keine separaten Dämonen erforderlich, um Metadaten bereitzustellen. Alle Kontrollen werden mit einem einzigen Hundewerkzeug durchgeführt , das direkt mit den Schafen kommuniziert
(Ceph verwendet auch Objekte - ca. pro.)
Berechnet einen gefallenen Knoten
Jeder VDI besteht aus diesen Blöcken (Objekten), die gleichzeitig auf mehrere Knoten repliziert werden. Wenn einer von ihnen fällt, bleiben die Daten verfügbar, und Objekte von den gefallenen Knoten beginnen, sich auf den anderen Knoten zu replizieren.
Unterstützt Blockgeräte-Snapshots
Sheepdog- Schnappschüsse funktionieren genauso wie Btrfs. Die angehängten VDI-Blöcke werden gespeichert und neue Daten werden in neue Blöcke geschrieben.
Die folgenden Funktionen können unter bestimmten Umständen problematisch sein:
Sheepdog unterstützt SPOF nicht
Wenn VDI über QEMU als Blockgerät verwendet wird, kann ein Problem auftreten, wenn es an mehreren Stellen gleichzeitig angeschlossen wird. SPOF 3 hätte dies verhindern können. Schäferhund hat nicht. In der neuen Version von Sheepdog kann VDI jedoch blockiert werden, um mehr als eine Verbindung zu verhindern.
Der Lebenszyklus von Datenobjekten
VDI-Objekte können nur gelöscht werden, wenn alle ihnen zugeordneten Klone und Snapshots gelöscht wurden. Dies ist genau das gleiche wie für Btrfs. Daher reicht das Entfernen nicht verwendeter Schnappschüsse möglicherweise nicht aus, um Platz für die Speicherung zu schaffen.
Kommunikationsdämon
Sheepdog ist im Vergleich zu Ceph oder GlusterFS lächerlich klein. Dies liegt daran, dass er nicht versucht, alle Probleme selbst zu lösen, sondern das, was bereits funktioniert, maximal nutzt.
Im Gegenzug bietet es ein Blockgerät, das als physische Festplatte verwendet werden kann, sowie einen Software-Raid usw.
Es kümmert sich nur um die Verteilung von Datenobjekten zwischen den Knoten, auf denen es ausgeführt wird.
Er benötigt jedoch die Informationen, die der Kommunikationsdämon bereitstellt - eine Schlüsselkomponente, ohne die Sheepdog nicht funktioniert.
Kommunikationsdämon - bietet keine Möglichkeit zum Datenaustausch zwischen Knoten. Dies ist, was Schafsdämonen tun. Dadurch erfahren Schafe nur, welche Knoten derzeit leben.
corosync
Zunächst geht Sheepdog davon aus, dass die Knoten über Corosync miteinander kommunizieren . Es unterstützt bis zu 64 Knoten, obwohl es theoretisch in der Lage sein sollte, mehr zu bedienen, ist seine Verwendung für kleine Cluster mit bis zu 16 Knoten optimal.
In der Regel verwendet corosync auch Pacemaker, sodass keine weiteren Installationen erforderlich sind.
Installieren Sie corosync unter Debian
Corosync befindet sich in den Distributionsrepositorys und ist einfach zu installieren:
$ apt-get install corosync libcorosync-common4
Corosync-Setup
Tierpfleger
Sheepdog- Entwickler empfehlen die Verwendung von zookeeper für größere Cluster. Laut den Entwicklern wurde ein Sheepdog -Testspeicher mit 1000 Knoten erstellt und getestet 4 .
Installieren Sie zookeeper auf Debian
$ apt-get install zookeeper zookeeperd
Starten des Daemons ..
$ /usr/share/zookeeper/bin/zkServer.sh start
Der Standardport, auf dem zookeeper ausgeführt wird, ist 2181
Laufender Schäferhund mit Tierpflegerunterstützung:
$ sheep -c zookeeper:IP1:PORT1,IP2:PORT2,IP3:PORT3 ...other...option...
Der Vorteil von zookeeper ist, dass Sheepdog in diesem Fall eine klarere und leichtere Konfiguration von Knoten hat, aber es gibt ein Problem, dass das Debian-Installationspaket seine Unterstützung nicht enthält.
Um einen Schäferhund mit Zookeeper-Unterstützung zu erhalten, müssen Sie ihn daher aus dem Quellcode kompilieren. Obwohl ich nicht ausschließen kann, dass die Situation derzeit anders sein kann.
(Die Unterstützung von Tierpflegern erfordert weiterhin eine Kompilierung aus dem Quellcode - ca. per.)
Einrichten des Schafdämons
Der Knoten wird Teil des Schäferhundes, wenn der Objektmanager, der Schafdämon, gestartet wird. Es funktioniert immer in zwei Kopien:
Die erste Instanz des Prozesses startet als Gateway, das E / A-Anforderungen von Clients (z. B. von den Treibern von QEMU-Blockgeräten) empfängt, die Zielknoten berechnet und Anforderungen zur weiteren Verarbeitung zwischen ihnen sendet. Das heißt, es werden viele Netzwerkverbindungen hergestellt.
- Ein anderer arbeitet als lokaler Objektmanager ( Objektmanager )
Die Konfigurationsparameter des Schafdämons können zur Laufzeit als Befehlszeilenargumente übergeben werden. Wenn keine vorhanden sind, werden die Standardwerte verwendet, mit denen Sie vorsichtig sein sollten:
Portnummer
Sofern nicht anders angegeben, wird der Schafdämon auf Port 7000 ausgeführt
Tresorpfad
Sofern nicht anders angegeben, verwendet das Verzeichnis shep das Verzeichnis / var / lib / libdog, und die VDI-Objekte werden in seinem Unterverzeichnis obj gespeichert.
Theoretisch hindert nichts mehrere Instanzen von Schafen daran, an einem Knoten zu arbeiten - die Hauptbedingung ist, dass jeder seine Portnummer und seinen eigenen Speicher verwendet. Das Problem mit der IP-Adresse des Knotens ist fast behoben. Jede laufende Instanz des Schafdämons, die auf einem anderen Port ausgeführt wird, stellt automatisch eine Verbindung zu einem vorhandenen Cluster her!
Wichtige Information ist, dass die Portnummer Teil der Konfiguration des VDI-Containers ist. Sie müssen wissen, ob Sie den Schafdämon so konfigurieren möchten, dass er auf dem anderen Port des vorhandenen Clusters ausgeführt wird.
Wenn Sie daher eine Instanz des Schafdämons mit einer anderen Portnummer, jedoch mit demselben Pfad zum Objektspeicher ausführen, können Informationen in vorhandenen VDI-Containern verloren gehen.
Das Dämonenschaf als Tor
Auf Computern ohne Speicherplatz für VDI-Objekte kann der Schafdämon ausschließlich im Gateway-Modus mit dem Flag -G .
In diesem Fall wird beim Verteilen von VDI-Objekten überhaupt kein lokaler Speicher verwendet, und die Daten werden direkt an andere Knoten verteilt.
Schafsdämon als Objektmanager
Die zweite ausgeführte Instanz fungiert als lokaler Objektmanager, empfängt E / A-Anforderungen von einer Instanz, die als Gateway startet, und führt R / W-Vorgänge im lokalen Objektspeicher ( Objektspeicher ) aus.
Objektspeicherung
Standardmäßig ist der Speicher für VDI-Objekte in Sheepdog das Verzeichnis /var/lib/sheepdog/obj , das auch vom /var/lib/sheepdog/obj als Teil seiner internen Verzeichnisstruktur verwendet wird. Dies ist der Standardspeicherpfad.
Wenn Sie möchten, dass VDI-Objekte an anderer Stelle gespeichert werden, können Sie den Pfad übergeben, in dem ein anderes Blockgerät beim Start als Parameter bereitgestellt wird.
sheep ... /cesta_do_přípojného_bodu
Es gibt noch mehr Möglichkeiten zu vermitteln. Die neue Version von Sheepdog unterstützt die sogenannte Multi-Device-Technologie, mit der Sie die Speicherkapazität bei Bedarf dynamisch erhöhen können, ohne den Sheepdog neu starten zu müssen. Das Erhöhen der Speicherkapazität funktioniert ähnlich wie bei Btrfs.
sheep ... /cesta_do_A,/cesta_do_B,/cesta_do_C
(Das erste angegebene Verzeichnis wird nur für Metadaten verwendet - ca. pro)
Zusätzlicher Speicher kann auch über den Hundeknoten md hinzugefügt (oder entfernt) werden
...
Die vom Multi-Gerät angebotene Funktionalität ist besonders nützlich, wenn das Speicherdateisystem dies nicht "von Natur aus" unterstützt (im Gegensatz zu Btrfs oder ZFS). Im Allgemeinen kann die Auswahl eines Dateisystems zum Speichern von Objekten, deren Eigenschaften, Parametern und Einstellungen die Leistung des E / A-Dateisystems einer virtuellen Maschine erheblich beeinflussen.
Die Multi-Device-Technologie erfordert erweiterte Attribute auf der Dateiseite, was für moderne Dateisysteme wie btrfs 5 kein Problem darstellt oder ext4. Einige ältere Dateisysteme wie reiserfs oder ext2 6 Unterstütze sie nicht.
Wenn Sie ein Dateisystem verwenden möchten, das keine erweiterten Attribute zum Speichern von Objekten unterstützt, müssen Sie Sheepdog ohne Unterstützung für mehrere Geräte kompilieren.
Lagertyp - einfach gegen Baum
Bei der Formatierung eines Clusters können Sie unter anderem den Speichertyp (Backend-Speicher) angeben. Sie können den Typ auf Ebene oder Baum setzen . Bei einem einfachen Typ sieht die Verzeichnisstruktur folgendermaßen aus:
| |- obj | |- <id > | | |-< > | | |-< > | | |-< > | | |- ... | |- <id > | | ... |- config [] |- epoch | |- < > | |- < > | |- ... |- journal \- sheep.log []
Alle VDI-Objekte im obj Verzeichnis werden an ein Unterverzeichnis gesendet, dessen Name auf der aktuellen Ära- obj basiert. Das heißt, für jede Epoche werden die entsprechenden VDI-Objekte separat gespeichert. Während einer Ära kann jedoch eine große Anzahl von VDI-Objekten im Verzeichnis erscheinen, was anschließend den Zugriff auf Dateien verlangsamt. Daher können Sie die zweite Option auswählen, nämlich den Baum :
|- obj | |- aa | | |-< > | | |-< > | | |-< > | | |- ... | |- ab | | ... | |- meta | | |- < > | | |- ... | |- 0a | | ... |- config [] |- epoch | |- < > | |- < > | |- ... \- sheep.log []
Bei dieser Art der Speicherung erstellt der obj eine Reihe von 256 Unterverzeichnissen mit den Namen 0a, ..., 99 im Verzeichnis obj und streut dann Objekte basierend auf den letzten beiden Zeichen der VDI-ID , die nicht nur für jeden VDI-Container, sondern auch für seine Snapshots oder eindeutig ist Klone.
VDI-Objektnamen
Wenn Sheepdog die Daten im VDI-Container speichert, werden Dateien im obj Datenspeicher obj , wobei jeder seinen eigenen Namen hat, der aus mehreren Elementen besteht:
../obj/8f/00e8b18f00000005 ^^
Die ersten beiden Zeichen geben den Objekttyp an. Datenobjekte beginnen mit 00... und Metadaten (die in einem anderen Verzeichnis gespeichert werden können) 80...
../obj/8f/00e8b18f00000005 ^^^^^^
Dann kommt der VDI. Es ist nicht nur für jeden Container einzigartig, sondern auch für seinen Snapshot oder Klon.
../obj/8f/00e8b18f00000005 ^^ ^^
Die letzten beiden Ziffern der VDI-Kennung geben - im Fall des Baumspeichertyps - an, in welchem Verzeichnis sich das Unterverzeichnis befindet, zu dem das Objekt gehört.
../obj/8f/00e8b18f00000005 ^^^^^^^^
Auf die Kennung des VDI-Containers in hexadezimaler Reihenfolge folgt die Seriennummer des Objekts im VDI-Container
Ära
Das Unterverzeichnis der epoch enthält binäre Listen von Objekten, die zur Epoche gehören. Die Anzahl der Epochen erhöht sich jedes Mal, wenn sich jeder Cluster ändert - wenn ein Knoten hinzugefügt oder entfernt wird. Jede solche Änderung startet den Wiederherstellungsprozess , bei dem der aktuelle Status lokaler Objekte auf den Knoten überprüft wird, gefolgt von einer Zunahme der Ära.
So wählen Sie den optimalen VDI-Objektspeicher aus
Die verfügbare Speicherkapazität wird basierend auf dem freien Speicherplatz auf den Knoten berechnet. Der von Schafen gewählte Speicherplatz hängt immer davon ab, wie viel Speicherplatz in dem Blockgerät verfügbar ist, in dem die VDI-Objekte gespeichert sind.
Die Größe eines VDI-Containers ist nur eine virtuelle Form, die in keiner Weise mit dem Platzbedarf von VDI-Objekten zusammenhängt. Es ist wichtig zu wissen, wie Sheepdog Daten in einem Cluster verarbeitet:
Sheepdog versucht immer, Daten gleichmäßig zwischen allen Maschinen der Ära zu speichern.
Dies bedeutet, dass wenn einer der Knoten fällt, sich die Ära ändert und Sheepdog sofort den Wiederherstellungsprozess startet, die fehlenden VDI-Objekte auf den verbleibenden Knoten erstellt werden, um den Verlust zu kompensieren.
Eine ähnliche Situation tritt auf, wenn ein neuer Knoten hinzugefügt wird. Sheepdog beginnt, VDI-Objekte gleichmäßig von neuen Knoten in sein Repository zu verschieben, damit die prozentuale Füllung des Datenraums auf den Knoten so ausgeglichen wie möglich ist. Verwenden Sie den folgenden Befehl, um eine globale Übersicht darüber zu erhalten, wie viel Speicherplatz derzeit auf Ihren Knoten verwendet wird:
nod1 ~ # collie node md info -A Id Size Used Avail Use% Path Node 0: 0 1.1 TB 391 GB 720 GB 35% /local/sheepdog-data/obj Node 1: 0 702 GB 394 GB 307 GB 56% /local/sheepdog-data/obj Node 2: 0 794 GB 430 GB 364 GB 54% /local/sheepdog-data/obj Node 3: 0 1.6 TB 376 GB 1.2 TB 22% /local/sheepdog-data/obj Node 4: 0 1.2 TB 401 GB 838 GB 32% /local/sheepdog-data/obj Node 5: 0 1.5 TB 370 GB 1.1 TB 24% /local/sheepdog-data/obj Node 6: 0 1.6 TB 388 GB 1.2 TB 23% /local/sheepdog-data/obj
E / A-Leistung
Es ist wichtig zu sagen, dass Sheepdog anders arbeitet als Ceph und unterschiedliche Prioritäten hat.
Für Ceph ist das "Gewicht" des OSD-Geräts beim Platzieren von Datenobjekten sowie die Leistung des Blockgeräts, die Host-Konnektivität und die Antwortgeschwindigkeit von entscheidender Bedeutung. (eigentlich nicht - ca. pro)
Tut Sheepdog so etwas, ich weiß es nicht. Möglicherweise. Daten für ihn stehen an erster Stelle. Die Leistung in Bezug auf E / A-Vorgänge ist zweitrangig. Natürlich kann bei leistungsstärkeren Knoten die E / A-Leistung verbessert werden, dies hängt jedoch immer von der spezifischen Struktur ab. ( Tests zeigen jedoch eine bessere Leistung von Schäferhunden im Vergleich zu Ceph - ca. pro)
Ich habe Sheepdog einen neuen Knoten hinzugefügt, dessen Daten auf einer rotierenden 2-TB-SATA-II-Festplatte gespeichert sind. Die maximale Schreibgeschwindigkeit für diese Disc beträgt ca. 80 M / s. Tatsächlich ist dies sehr unterschiedlich, da SATA-Laufwerke nicht gleichzeitig lesen und schreiben können.
Anfänglich betrug die durchschnittliche Schreibgeschwindigkeit auf VDI auf dieser Festplatte etwa 20 bis 30 M / s, da zusätzlich zu den Daten aus VDI im Rahmen des Wiederherstellungsprozesses 392G-Containerdaten darauf repliziert wurden. Dies dauerte 6,5 Stunden. Die Schreibgeschwindigkeit lag zwischen 40 und 55 M / s.
In diesem Fall war die Schreibgeschwindigkeit offensichtlich durch die E / A-Leistung des lokalen Blockgeräts begrenzt.
Für Sheepdog gilt die folgende Regel: "Je mehr VDI-Objekte sich auf den Knoten mit schneller Verbindung befinden, desto besser ist die Leistung von E / A-Vorgängen."
Aufgrund der Tatsache, dass das Verschieben von VDI-Objekten im Hintergrund bedeutet, dass der „schnelle Tod eines Knotens“ die Replikation der Datenobjekte verlangsamt, die den meisten Speicherplatz beanspruchen, äußert sich dies in einer Verringerung der Leistung von E / A-Vorgängen des VDI-Containers
Platz belegt
Beim Platzieren von Datenobjekten ist die Menge an freiem Speicherplatz für den Schafdämon entscheidend. Der Mechanismus scheint einfach. Der Schafdämon, über den Daten von Zeit zu Zeit mit dem VDI-Container übertragen werden, bestimmt die Nutzung des freien und belegten Speicherplatzes auf den Knoten, wodurch diese sortiert werden. Dann werden die Daten auf die Knoten mit der niedrigsten Auslastungsrate verteilt.
Wenn es einen überwiegend schnellen Schreibpfad gibt, ist auch die Schreiboperation in den VDI-Container schnell. Je schneller die E / A-Operationen des VDI-Containers ausgeführt werden, desto früher kann der Schafdämon mit der nächsten Operation fortfahren.
Wichtig ist, dass es bei Sheepdog keine Situation gibt, in der einer der Knoten vollständig gefüllt ist. Wenn die Auslastungsrate auf dem Knoten viel schlechter wird, beginnt der Schafdämon, seine Datenobjekte an einen anderen Ort zu verschieben.
Sheepdog funktioniert genau wie Btrfs - nur mit wirklich belegtem Platz. Auf diese Weise können Sie einen virtuellen VDI-Container mit einer Kapazität von 1 TB erstellen, der tatsächlich so viel Speicherplatz beansprucht wie die darin gespeicherten Daten. Unter diesem Gesichtspunkt ist es wünschenswert, solche Formate von virtuellen Festplatten und Dateisystemen in VDI-Containern zu verwenden, die sie nacheinander bereinigen können.
Clusterstart
Während alle Knoten gleichzeitig gestoppt werden können, können Knoten nicht gleichzeitig gestartet werden !!! Knoten sollten schrittweise verbunden werden. Beginnend mit dem Knoten, der zuerst in der Liste der Knoten angegeben wurde.
(Dies ist eine äußerst seltsame Aussage - ca. pro)
Vdi
Dies ist eine generische Abkürzung in Sheepdog für virtuelle Festplatten, nicht das spezifische Format. 7 . Im Allgemeinen handelt es sich hierbei um eine virtuelle Box mit Fächern fester Größe, in die Sheepdog dann die vom Client übertragenen Daten legt.
VDI erstellen
Bevor wir den ersten VDI erstellen oder importieren, müssen wir den Cluster formatieren. Beim Formatieren eines Clusters werden Parameter festgelegt, die dann standardmäßig beim Erstellen jedes nachfolgenden VDI verwendet werden.
Ein Beispiel für die Erstellung eines neuen VDI mit dem Namen Disk1 und einer Größe von 1 GB
root@nod1 :~
Id
VDI-Kennung
Größe
Die Größe des VDI, die nicht unbedingt sofort vorab zugewiesen wird.
Wenn dieses VDI im inkrementellen Format (qcow2 und dergleichen) qemu-img convert das mit qemu-img convert , entspricht es nicht der Größe der virtuellen Festplatte, wächst jedoch ständig.
Gebraucht
Informationen darüber, wie viel Speicherplatz VDI-Datenobjekte belegen.
VDI, für das während der Erstellung keine Zuordnung von Datenobjekten erforderlich ist, belegt überhaupt nichts, da noch keine Datenobjekte dafür erstellt wurden.
Geteilt
Das Volumen der Datenobjekte, die von anderen VDIs gemeinsam genutzt werden
Erstellungszeit
VDI-Erstellungszeit
Blockgröße
Die Größe des VDI-Objekts. Achtung! Es wird nicht in MB angegeben, sondern als Zweierpotenz. In älteren Versionen wurden nur 4 MB Objekte mit fester Größe verwendet. Derzeit kann VDI größere Objekte haben. Die optimale Größe für das VDI-Objekt einer normalen virtuellen Maschine sieht aus wie 64 MB (26). Die Standardgröße von 22 (4 MB) ist ebenfalls minimal. Weniger kann nicht installiert werden. Je kleiner das Objekt ist, desto mehr Dateien muss Sheepdog während der Arbeit mit VDI verarbeiten, und die Arbeit mit Dateien ist aus Sicht von IO kein billiges Problem. Eine große Anzahl von Dateien, insbesondere bei langsamen SATA-Controllern, kann zu einer starken Verschlechterung der Lese- und Schreibgeschwindigkeit führen. Die maximale Größe der Objekte, die verwendet werden können, beträgt 31 (2 GB). Dies kann von Vorteil sein, wenn VDI konsistent eine große Menge statischer Daten speichert, z. B. Sicherungen.
Vdi id
VDI-Kennung.
Was enthält VDI?
VDI-Inhalt sind Daten. Dies ist ein verteiltes Blockgerät, daher löst Sheepdog diese Daten oder diesen Müll nicht. Unter diesem Gesichtspunkt sieht VDI wie ein logisches LVM-Volume aus. Ein vorab ausgefüllter VDI entspricht einer klassischen LV-Partition mit einem dedizierten Bereich, während VDI einer in einem Pool erstellten Thin-LV-Partition ähnelt (siehe LVM (thin_provisioning)), jedoch mit dem Unterschied, dass die Datenbereiche (Objekte) nicht lokal gespeichert werden Geräte blockieren und sind zwischen Knoten verstreut.
Das VDI-Format funktioniert in dieser Analogie als Dateisystem. Einige belegen nacheinander reservierte Bereiche (Objekte), andere ordnen sie als Inodes zu und senden dann Daten direkt an sie. Eine falsche Kombination des Knotenspeicher-Dateisystems, des VDI-Formats und des internen Dateisystems kann zu einer erheblichen Verschlechterung der E / A-Leistung führen.
Um mehr über das VDI-Format zu erfahren, können Sie qemu-img info verwenden :
root@nod1 :~# qemu-img info sheepdog:localhost:8000:disk1 image: sheepdog:localhost:8000:test2 file format: qcow2 virtual size: 12G (12884901888 bytes) disk size: 4.0G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false
An der Ausgabe des Befehls können Sie erkennen, dass disk1 eine Nenngröße von 12 G hat. Derzeit dauert es nur 4G. Da es im qcow2-Format vorliegt, ist es offensichtlich, dass es inkrementell erstellt wurde.
root@nod1 :~# collie vdi list Name Id Size Used Shared Creation time VDI id Copies Tag Block Size Shift disk2 0 4.0 GB 4.0 GB 0.0 MB 2015-12-04 16:07 825dc1 2 31 root@nod1 :~# qemu-img info sheepdog:localhost:8000:disk2 image: sheepdog:localhost:8000:disk2 file format: raw virtual size: 4.0G (4294967296 bytes) disk size: 4.0G root@nod1 :~# find /datastore/obj/ | grep 825dc1 /datastore/obj/meta/80825dc100000000 /datastore/obj/c1/00825dc100000000 /datastore/obj/c1/00825dc100000001
In diesem Fall wurde Disk2 als vorab zugewiesener 4-GB-VDI im Rohformat mit einer Blockgröße von 2 GB erstellt, was tatsächlich nur zwei 2 GB dauert
Exportieren Sie VDI in eine Datei
VDI-Inhalte können auf verschiedene Arten aus Sheepdog exportiert werden. Vielleicht ist die schnellste Verwendung von Hundelesen . Der Befehl ist etwas verwirrend, bedeutet aber nur: "Laden Sie den Inhalt des VDI und senden Sie ihn an STDOUT ..", der in eine Datei umgeleitet werden kann:
root@nod1 :~
Wenn VDI 10G hat, aber nur 2G verwendet wird, wird eine Datei mit einer vollen Kapazität von 10 GB erstellt.
In diesem Befehl bleibt der Inhalt des VDI unverändert . Wenn also der Inhalt des VDI, z. B. eine virtuelle Festplatte im komprimierten qcow2-Format, direkt verwendet werden kann
.. -drive file=file:/disk1_exportovany_z_vdi,..,format=qcow2 ..
Eine andere Möglichkeit, den Inhalt von VDI in eine Datei zu übertragen, ist die Verwendung von qemu-img convert . Es ist nicht so schnell, aber Sie können VDI mit verschiedenen Optionen des entsprechenden virtuellen Festplattenformats in ein anderes Format konvertieren.
root@nod1 :~
Inkrementelle Sicherung
Erstellen Sie eine inkrementelle Sicherung
Delta zwischen dem ersten und zweiten Schnappschuss.
root@nod1 :~
Stellen Sie VDI aus der inkrementellen Sicherung wieder her
root@nod1 :~
Beim Importieren einer inkrementellen Sicherung sollte der VDI natürlich über den Snapshot verfügen, aus dem die Sicherung erstellt wurde.
Überprüfung durch Lesen des Originalinhalts des Bildtests ...
root@nod1 :~
VDI aus Datei importieren
Das Importieren einer vorhandenen virtuellen Festplatte als lokale FS-Datei kann ähnlich wie beim Exportieren durchgeführt werden. Aber mit dem Unterschied, dass Hundeschreiben verwendet wird ("Lesen von Daten aus STDIN und Schreiben in eine VDI-Datei ..")
root@nod1 :~
- Inhalte können nur in eine vorhandene VDI importiert werden.
- Importierte VDI beanspruchen immer mehr Speicherplatz als die Originaldatei, da die Datenblöcke, aus denen die VDI wiederhergestellt wird, Daten im markierten Bereich enthalten.
Wenn VDI noch nicht vorhanden ist und wir nicht wissen, wie viel Speicherplatz für die virtuelle Festplatte erforderlich ist, können wir qemu-img convert verwenden
root@nod1 :~
Obwohl VDI-Formate wie qcow2, qed und andere in VDI verwendet werden können. Für die E / A-Effizienz ist es besser, Datenblöcke vorab zuzuweisen.
, Sheepdog VDI.
http://www.sheepdog-project.org/doc/vdi_read_and_write.html
VDI
VDI , .
root@nod1 :~
VDI, . Sheepdog , . , .
: 'dog node kill' , ethernet , sheep . (, Ethernet), sheep . .
IO VDI
VDI . . , IO VDI.
Sheepdog SYNC, . -, VFS, , , .
VDI Sheepdog , . . Sheepdog VDI-.
VFS-
IO VDI sheep -n . SYNC , , VFS . , VFS , , !
. , — , , .
sheep -n ...
Sheepdog . -D
- . sheep - IO — SSD . , VDI, SYNC . .
, VDI , VDI . , , , VDI.
sheep -w size=20000,directio,dir=/dir ...
size
directio
sheep , . SSD.
dir
, .
( ) dog .
VDI dog vd cashe flush , VDI!
Magazin
— . VDI, VFS , (/store_dir/journal/[epoch]/[vdi_object_id]), , .
IO , (cik, cak), (sequence).
, Sheepdog VDI , , SSD-. , VDI , , VDI.
sheep —
$ sheep -j size=256M ...
, VDI , . -, — — -:
$ sheep -j dir=/dir,size=256M ...
dir = , . , SW RAID SSD.
: sheep , . , skip, .
$ sheep -j dir=/dir,size=256M,skip ...
- ↑ . 2015 . http://events.linuxfoundation.jp/sites/events/files/slides/COJ2015_Sheepdog_20150604.pdf
- ↑ http://www.abclinuxu.cz/blog/kenyho_stesky/2011/11/sheepdog-hrajeme-si-v-hampejzu
- ↑ SPOF ( S ingle p oint o f f ailure) , . SPOF VDI iSCSI tgtd
- ↑ 1
↑ Btrfs — COW, , . , -, . , , . , , . , :
autodefrag — , .
nocow — (), — GlusterFS
Btrfs , , FS, Sheepdog .
, , , Sheepdog.
↑ Ext2 . - FS Btrfs, ext2, inode. ext3 ext4 . inode , Sheepdog . , -, . , Sheepdog , dog vdi check . , ext2 , — - dog vdi md , VDI .
- ↑ , , vdi QEMU_Block_Disk
Referenzen
https://github.com/collie/sheepdog/wiki — ,
http://www.osrg.net/sheepdog/ — Nippon Telegraph and Telephone Corporation
http://www.sheepdog-project.org/doc/index.html — Sheepdog 0.8.0; — Valerio Pachera
http://www.admin-magazine.com/Archive/2014/23/Distributed-storage-with-Sheepdog — Udo Seidela Sheepdog , 23- Admin 2014