Wenn es darum geht, das System für maximale Leistung zu optimieren, kann es sehr leicht sein, Fehler zu machen, wenn Sie die Praktiken anderer rücksichtslos anwenden. Eine solche Praxis besteht darin, Nobarrier beim Mounten von Dateisystemen anzugeben.
Wie diese Notiz geboren wurde
Ich arbeite als Ingenieur bei Mail.Ru Cloud Solutions und beschäftige mich hauptsächlich mit allen möglichen Problemen „rund um“ den Blockspeicher, auf dem die virtuellen Maschinen unserer Benutzer liegen - und dementsprechend treten häufig interessante Fälle im Zusammenhang mit der Leistung und Stabilität virtueller Maschinen auf, die ausgeführt werden Anwendungen - und insbesondere Datenbanken.
In der Regel sehen wir in fast der Hälfte der Fälle während der „Nachbesprechung“ dasselbe - ein Dateisystem, das mit der Nobarrier-Option bereitgestellt wird. Und wenn wir fragen: "Warum haben Sie diese Option geschrieben?", Erhalten wir fast immer eine der Antwortoptionen: "Mir wurde gesagt, dass sie schneller ist. Ich habe gelesen, dass sie schneller ist. Ich wurde so eingerichtet." Danach versuchen wir höflich und sorgfältig, dies zu erklären SO muss nicht. Warum? Denn dies ist der erste sichere Schritt auf dem Weg zum Datenverlust.
Kurzer Ausflug
Dateisystem - Die Struktur ist sehr komplex und hoch geladen. Um maximale Leistung zu gewährleisten, werden Caching und parallele Aufzeichnung aktiv verwendet. Dementsprechend geht ein Teil der Daten in den Cache und wird nach Möglichkeit / Bedarf oder "on demand" verworfen. Eine Barriere ist eine spezielle Operation, um zu erzwingen, dass alle Caches auf die Festplatte geleert werden.
Wenn es um Datenbanken geht, müssen wir sicherstellen, dass die dem Client (Clientanwendung) bestätigte Transaktion dauerhaft ist und nicht verschwindet. Einerseits verwenden DBMS aktiv ihr eigenes Caching, um maximale Leistung zu erzielen - und um Konsistenz zu gewährleisten. Journaling wird verwendet - die Änderung wird in das Protokoll geschrieben, das Protokoll wird "synchronisiert" und dann wird die Änderung in die Daten geschrieben (und wenn sie geschrieben wird, gelangt sie in den Cache). Wenn das Protokoll voll ist, wird eine erzwungene Synchronisierung mit allen Daten im Cache durchgeführt, und das Protokoll wird erneut gefüllt.
Synchronisierungsvorgang
Wenn die Synchronisierung ausgeführt wird, löscht das Betriebssystem nicht nur den Seiten-Cache, sondern sendet standardmäßig einen Befehl zum Leeren aller Festplatten-Caches (und dies möglicherweise wiederholt) - den sogenannten
spülen . Das Löschen von Puffern ist „teuer“ und nimmt viel Zeit in Anspruch - dies ist jedoch erforderlich, da in Dateisystemen die Reihenfolge des Schreibens wichtig ist. Wenn dies verletzt wird, kann sich beispielsweise herausstellen, dass die Datei bei einem plötzlichen Neustart anstelle von Daten Müll enthält, da das Gerät beschlossen, die Aufzeichnung neu zu ordnen. Und wenn durch Flush alle Caches zwangsweise geleert werden - dies stellt sicher, dass zuerst geschrieben wird, was vor dem Flush ist, und erst dann, was danach passiert -, dh eine „Barriere“ erstellt wird, die die Einträge in „vor der Barriere“ und „nach der Barriere“ (von hier aus) unterteilt und der Name "Barriere schreiben") - und dies ermöglicht es zu gewährleisten, dass die Aufzeichnungen nach der Barriere nicht früher als die Aufzeichnungen vor der Barriere angewendet werden.
Nobarrier-Effekt
Die Nobarrier-Option deaktiviert das Senden von Forced Flush, während das Dateisystem ausgeführt wird. Dies führt dazu, dass die Datensätze neu angeordnet werden können - und wenn ein Fehler auftritt, das Dateisystem (und im Allgemeinen die Daten im allgemeinen Fall) möglicherweise nicht konsistent sind - erinnern wir uns an das, was im vorherigen Absatz über die Aufzeichnungsreihenfolge erwähnt wurde.
Warum ist diese Option enthalten? Bei kostengünstigen SSDs ist der Flush-Betrieb sehr teuer. Beispielsweise führen kostengünstige SSDs (und viele teure SSDs, die als „Server“ positioniert sind) 10 bis 20.000 Schreibvorgänge pro Sekunde ohne Flush aus und fallen bei eingeschaltetem Flush auf 1-2 Tausend ab. In solchen Fällen bietet Nobarrier eine erhebliche Leistungssteigerung, wodurch die oben beschriebenen Risiken für die Datenintegrität entstehen.
Virtuelle Umgebung
Im Fall einer virtuellen Maschine - wenn wir beispielsweise über die klassische Konfiguration virtueller Maschinen auf einem Linux-Hypervisor sprechen - haben wir QEMU - einen Prozess, der tatsächlich für die Emulation von E / A für das Gastbetriebssystem verantwortlich ist. Und was am wichtigsten ist: Wenn wir in einer virtuellen Maschine nicht dateibasierte Festplatten verwenden, liegt der Cache einer solchen virtuellen Festplatte (plötzlich!?) Im Benutzerbereich - im Adressraum des entsprechenden QEMU-Prozesses. Und wenn dieser Prozess abstürzt - zum Beispiel laut SEGFAULT / SIGSEGV -, sterben alle seine Caches damit ab. Ein Beispiel für einen solchen Blockgerätetreiber ist der RBD (Ceph) -Treiber.
Und selbst wenn Sie beispielsweise nicht Ceph, sondern iSCSI / FC verwenden, verschwindet die Fehlerstufe nicht - sie wechselt einfach von QEMU zum Host-Betriebssystem (Hypervisor). Der Hypervisor ist gefallen - sein Seitencache ist gestorben (dies gilt für io = 'threads' in Kombination mit cache = 'writeback' oder cache = 'unsicher'). Ups
s / Cloud / Alien-Computer / g
Wenn Ihre virtuelle Maschine in der Cloud bereitgestellt wird ... Dann wissen Sie nicht, wie der Hypervisor konfiguriert ist, wie QEMU konfiguriert ist, welche Festplattentreiber betroffen sind, ob der Seitencache des Hosts funktioniert usw., und Sie können dies in den allermeisten Fällen nicht beeinflussen. Und selbst wenn es Ihre Cloud ist - wo Sie all dies wissen und es mehr oder weniger kontrollieren -, ist es keineswegs eine Tatsache, dass Ihr Hypervisor nicht "herunterfällt" - und den gesamten Datencache vergräbt.
Zusammenfassung
Die Verwendung von Nobarrier in der Cloud bedeutet, dass Sie Ihre Daten sehr wahrscheinlich gefährden. Sind Sie sicher, dass Sie auf Kosten solcher Risiken eine höhere Produktivität erzielen möchten?