Hallo,
wir wollen in Perl ein spezielles Kommunkationsscript bauen, welches Datenaustausch zwischen Systemen sicherstellen soll - und später noch mehr. Dabei wollen wir Wert aud Trx-Sichrheit legen - das ist das A und O. Szenario: 1. A gibt Datei an Script 2. Script prüft, ob Datei soweit korrekt ist und legt sie intern ab 3. Script schreibt intern ein log - Datei von A liegt im internen Puffer 4. Script gibt A sein OK und A ist aus dem Geschäft.
Mein Problem: jetzt geht nach Punkt 4 das Licht aus und die Datei /und oder das Log sind noch nicht auf der Festplatte gelandet, sonden schwirren noch irgendeinem Cache rum (Rechner stehen zwar im teuren Rechenzentrum - aber man weiss ja nie...) Das Script starten irgendwann wieder und findet entweder ein unvollständiges Log oder die Datei nicht an ihrem Platz. Somit kann diese nicht an B übertragen werden und A denkt aber, alles ist OK gelaufen.
Wie realistisch ist das Szenario, und was kann man machen, um die Risiken zu minimeren. Kann ich explizit auf die Platte schreiben (Sync) und wirklich darauf vertrauen, dass die Daten weggeschreiben wurden??? Wie machen das die teuren dicken TRX-Server?
Mit freundlichen Grüßen
Jens Puruckherr
On Tue, 01 Oct 2002 09:36:15 +0200, Jens Puruckherr wrote:
Szenario:
- A gibt Datei an Script
- Script prüft, ob Datei soweit korrekt ist und legt sie intern ab
- Script schreibt intern ein log - Datei von A liegt im internen
Puffer 4. Script gibt A sein OK und A ist aus dem Geschäft.
Mein Problem: jetzt geht nach Punkt 4 das Licht aus und die Datei /und oder das Log sind noch nicht auf der Festplatte gelandet, sonden schwirren noch irgendeinem Cache rum (Rechner stehen zwar im teuren Rechenzentrum - aber man weiss ja nie...) Das Script starten irgendwann wieder und findet entweder ein unvollständiges Log oder die Datei nicht an ihrem Platz. Somit kann diese nicht an B übertragen werden und A denkt aber, alles ist OK gelaufen.
Wenn A nur wissen muß, daß B die Daten irgendwann bekommen wird, ist dein Modell OK. Wenn aber A allerdings wissen muß, daß B die Daten bereits bekommen hat, mußt du das Modell ändern. DAnn kannst dein Skipt erst an A des OK geben, wenn du an B geliefert hast.
Wie realistisch ist das Szenario, und was kann man machen, um die Risiken zu minimeren. Kann ich explizit auf die Platte schreiben (Sync) und wirklich darauf vertrauen, dass die Daten weggeschreiben wurden???
Klar geht das. Du hast 3 Puffer beim Schreiben via File auf die Platte: 1. den in Perl und libc 2. den Plattencache des Kernels 3. den Schreibcache in der Festplatte
für 1. gibts in C fflush für 2. gibts in C fsync oder eine mit Option "sync" gemountete Platte (Ich bin nicht sicher, ob Linux sync-gemountete Platten wirklich) synchron bereibt.) für 3. gibt es "Abschalten des Schreibcaches der Festplatte"
Goggle nach "perl fsync" befragt bringt viele Beispiele. z.B. http://search-dev.cpan.org/author/CEVANS/File-Sync-0.09/Sync.pm
Wie machen das die teuren dicken TRX-Server?
Genauso, nur hier und da optimiert und auf verteilte Transaktionen erweitert. Wenn du nur zwei beteiligte Rechner hast, reichen einfache Bestätigungen vom Empfänger um die Daten auf Senderseite zu löschen. Bei Ausfall+Wiederanlauf mußt du nochmal rückfragen.
Reinhard
lug-dd@schlittermann.de writes:
Wenn A nur wissen muß, daß B die Daten irgendwann bekommen wird, ist dein Modell OK.
Ja, so ist es.
Wenn aber A allerdings wissen muß, daß B die Daten bereits bekommen hat, mußt du das Modell ändern. DAnn kannst dein Skipt erst an A des OK geben, wenn du an B geliefert hast.
Nein, diese Anforderung steht nicht.
Klar geht das. Du hast 3 Puffer beim Schreiben via File auf die Platte:
- den in Perl und libc
- den Plattencache des Kernels
- den Schreibcache in der Festplatte
Wie immer sehr ausführlich. Ich mache mich mal auf den Weg. Danke.
Genauso, nur hier und da optimiert und auf verteilte Transaktionen erweitert. Wenn du nur zwei beteiligte Rechner hast, reichen einfache Bestätigungen vom Empfänger um die Daten auf Senderseite zu löschen. Bei Ausfall+Wiederanlauf mußt du nochmal rückfragen.
Rückfragen geht eben nicht, darum muss ich die Geweissheit haben, dass jede Zwischenstation unter allen Umständen die Daten behalten kann.
Mit freundlichen Grüßen
Jens Puruckherr
On Wed, 16 Oct 2002 08:17:15 +0200, Jens Puruckherr wrote:
Genauso, nur hier und da optimiert und auf verteilte Transaktionen erweitert. Wenn du nur zwei beteiligte Rechner hast, reichen einfache Bestätigungen vom Empfänger um die Daten auf Senderseite zu löschen. Bei Ausfall+Wiederanlauf mußt du nochmal rückfragen.
Rückfragen geht eben nicht, darum muss ich die Geweissheit haben, dass jede Zwischenstation unter allen Umständen die Daten behalten kann.
Dann mußt du versandte Daten, die noch unbestätigt sind, eben nach Wiederanlauf einfach nochmal schicken und auf Empfängerseite den Fall behandeln, daß irgendwelche Daten doppelt ankommen. Durchnummerieren der Datenpakete ist sicher keine dumem Idee um Doubletten zu erkennen.
Reinhard
Hallo,
Mein Problem: jetzt geht nach Punkt 4 das Licht aus und die Datei /und oder das Log sind noch nicht auf der Festplatte gelandet, sonden schwirren noch irgendeinem Cache rum (Rechner stehen zwar im teuren Rechenzentrum - aber man weiss ja nie...)
Man kann das Puffern beim Mounten per Option auch abschalten, was aber auf Kosten der Performance geht.
Risiken zu minimeren. Kann ich explizit auf die Platte schreiben (Sync) und wirklich darauf vertrauen, dass die Daten weggeschreiben wurden???
Journaling File System lautet die Antwort. Die merken sich im Plattenlog (wird ungepuffert geschrieben), was sie aendern und wie es vorher aussah. Wenn sie mit Aendern fertig sind, dann melden sie dass ans Log.
Sollte der Strom beim Aendern ausfallen, dann merken sie, dass im Log eine nicht beendete Operation liegt und bringen sie wieder auf den alten Stand (Aenderung also weg, aber Dateisystem konsistent).
ext3 nimmt meines Wissens nach sogar Data Journaling vor, was bedeutet, dass es sich auch merkt, was es gerade schreibt. Sollte also die Anforderung kommen etwas zu schreiben, dann landet auch das zu schreibende im Log, wodurch die Aenderungen sogar bei Stromausfall getaetigt werden, sofern es das Skript vorher geschafft hat, das zu schreibende an das System weiterzureichen.
Wie machen das die teuren dicken TRX-Server?
Die verwenden wahrscheinlich transaktionsfaehige Datenbanken (oder arbeiten nach diesem Prinzip): alles wird erst geschrieben, wenn alles fertig ist. Sollte waehrend der Operation der Strom ausfallen, so kommt das "Schreib-alles-auf-die-Platte"-Signal nicht und nichts geschieht. Die ganze Aktion hat quasi nie stattgefunden :-)
mfg, Fabian
Ich bin schon mal begeistert, die Beiutäge vom 1. Oktober zu bekommen...
lug-dd@schlittermann.de writes:
Man kann das Puffern beim Mounten per Option auch abschalten, was aber auf Kosten der Performance geht.
Nöö. der Rechner soll ja auch noch anderes machen...
Sollte der Strom beim Aendern ausfallen, dann merken sie, dass im Log eine nicht beendete Operation liegt und bringen sie wieder auf den alten Stand (Aenderung also weg, aber Dateisystem konsistent).
Das ist schlecht, da A ja immer noch glaubt, B bekommt die Daten...
ext3 nimmt meines Wissens nach sogar Data Journaling vor, was bedeutet, dass es sich auch merkt, was es gerade schreibt. Sollte also die Anforderung kommen etwas zu schreiben, dann landet auch das zu schreibende im Log, wodurch die Aenderungen sogar bei Stromausfall getaetigt werden, sofern es das Skript vorher geschafft hat, das zu schreibende an das System weiterzureichen.
Hmm, mal anschauen.
Mit freundlichen Grüßen
Jens Puruckherr
On Tue, 01 Oct 2002 12:17:42 +0200, Fabian Hänsel wrote:
Journaling File System lautet die Antwort.
Nein.
Die merken sich im Plattenlog (wird ungepuffert geschrieben)
Wer sagt, daß bei Journaling das Log ungepuffert geschrieben wird? Niemand.
, was sie aendern und wie es vorher aussah. Wenn sie mit Aendern fertig sind, dann melden sie dass ans Log.
Sollte der Strom beim Aendern ausfallen, dann merken sie, dass im Log eine nicht beendete Operation liegt und bringen sie wieder auf den alten Stand (Aenderung also weg, aber Dateisystem konsistent).
Eben - genau diesen Fall wollte Jens nicht. Journaling bringt erstmal nichts weiter als ein jederzeit konsistentes Dateisystem. Das ist aus Sicht der Datensicherheit völlig nutzlos. Was bringt es dir, nach einem Crash ein zwar sauberes FS zu haben wenn du dafuer alle Daten der letzten 10 Sekunden vor dem Crash verloren hast?
Journaling allein stellt _nicht_ sicher, daß bei Rückkehr des write() die Daten sicher auf der Platte gelandet sind und bringt damit nicht den von Jens gewünschten Effekt. Du mußt also bei einem journaling FS genauso fsync() auf die Daten zaubern wie bei einem herkömmlichen FS. (Und bei Linux u.U. auch auf geänderte Verzeichnisse. Keine Ahnung, ob das jetzt automatisch funktioniert.)
Journaling allein gibt dir also keinerlei Garantieen für die Sicherheit deiner Daten. Du musst immer schauen, bei welchen Optionen dir dein FS welche Zusicherungen macht.
BTW: In der iX muß mal ein netter Artikel zu Jounaling-FSs von Matthias Schuendehuette gewesen sein. Hat jemand die Ausgabe (September?) und könnte sie mir mal ausleihen?
Reinhard
Jens Puruckherr wrote:
Hallo,
wir wollen in Perl ein spezielles Kommunkationsscript bauen, welches Datenaustausch zwischen Systemen sicherstellen soll - und später noch mehr. Dabei wollen wir Wert aud Trx-Sichrheit legen - das ist das A und O. Szenario:
- A gibt Datei an Script
- Script prüft, ob Datei soweit korrekt ist und legt sie intern ab
Will heißen, schreibt auf Platte?
- Script schreibt intern ein log - Datei von A liegt im internen
Puffer
Welcher Puffer?
- Script gibt A sein OK und A ist aus dem Geschäft.
Davon kann man ausgehen.
Mein Problem: jetzt geht nach Punkt 4 das Licht aus und die Datei /und oder das Log sind noch nicht auf der Festplatte gelandet, sonden schwirren noch irgendeinem Cache rum (Rechner stehen zwar im teuren Rechenzentrum - aber man weiss ja nie...)
Dann sollte es ein Problem des Filesystems sein. Wenn ext3 oder ein anderes 'journaled FS' im Einsatz ist, soll's dich nicht weiter kümmern.
Das Script starten irgendwann wieder und findet entweder ein unvollständiges Log oder die Datei nicht an ihrem Platz. Somit kann diese nicht an B übertragen werden und A denkt aber, alles ist OK gelaufen.
Da sicherlich auch der Cache FIFO ist wird trotzdem zuerst das File und dann das Log geschrieben. Es bleibt also nur noch der 2. Fall übrig.
Wie realistisch ist das Szenario, und was kann man machen, um die Risiken zu minimeren. Kann ich explizit auf die Platte schreiben (Sync) und wirklich darauf vertrauen, dass die Daten weggeschreiben wurden???
Dann kannst Du nur das Logfile umfangreicher machen, also vor dem Speichern der Datei einen Logfileeintrag 'begin trx', dann Datei schreiben und zum Schluß 'end trx'. Beim Start kannst dur das Logfile auf diese unvollständige TRX wiederfinden und den Zustand überprüfen. Entweder hast du die Chance es zu vollenden oder machst es rückgängig.
Wenn du nach jeder Aktion einen sync einlegst, kann garnix mehr schiefgehen.
Wie machen das die teuren dicken TRX-Server?
Keine Ahnung.
Ciao Rico
lug-dd@mailman.schlittermann.de
-
Fabian Hänsel -
Jens Puruckherr -
Reinhard Foerster -
Rico Koerner