digiwf-core
digiwf-core copied to clipboard
it-at-m
Dateien temporär nicht vom S3-Storage abrufbar
Describe the bug Der Inhalt eines Ordners auf dem LHM-S3-Storage ließ sich nicht permanent mit WinSCP abrufen. Durch Aktualisieren des Ordnerinhalts werden mal mehr mal weniger Verzeichnisse angezeigt. Diese "Aussetzer" führen in DigiWF-Prod dazu, dass Dokumente im User task nicht vollständig abgerufen werden können. Auch dort werden Dokumente je nach Zeitpunkt des Reloads mal angezeigt und mal nicht.
Das Verhalten hat sich allerdings inzwischen gelegt.
Team Storage geht davon aus, dass die Synchronisation zwischen den nodes noch nicht abgeschlossen war. Zwischen Upload der Dateien und dem letzten Downloadversuch mit mit den beschriebenen Aussetzern liegen allerdings zwei Tage. BTW. "Amazon garantiert die Synchronisation selber nur innerhalb von 15 Tagen."
To Reproduce Sporadischer Fehler. Kann nur reproduziert werden, wenn ein Fachbereich so einen Fall meldet. Man kann es, ohne in den Vorgang zu gehen, gut nachvollziehen, indem man die betroffenen Dateien mit WinSCP direkt vom S3-Storage abfragt.
- Lasse dir die Requests der DigiWF zeigen. Eventuell reicht das schon, um den Speicherort auf dem S3 abzulesen. Eventuell suche auf der Datenbank nach dem Ablageort.
- Frage die Dateien mit WinSCP ab.
Expected behavior Dateien sind in User Tasks jederzeit und vollständig abrufbar.
Screenshots
Antwort vom Support:
Hallo Marko, der [Dienstleister entfernt]-Support hat sich inzwischen auch gemeldet. Er hat keine vergleichbaren Fehlerfälle gefunden. Er möchte gerne, dass wir das ganze mit AWS-CLI (ist ein Kommandozeilentool das OnPremise installierbar ist) nachstellen, um WinSCP als Fehlerursache auszuschließen. Dazu müsste wir aber erst WinSCP dazu bekommen den Fehler zu reproduzieren um einen direkten Vergleich zu haben.
Ich hab selbst auch nochmal versucht das Problem nachzustellen. In der Movia-Admin-Umgebung friert mir WinSCP ein beim Versuch auf den Bucket zuzugreifen. Mit dem lokalen WinSCP ist der Zugriff zäh aber er funktioniert. Bei zu häufigen Refresh friert er aber auch lokal ein. Der Zugriff per CLI funktioniert dauert aber auch etwas. War es bei dir der WinSCP in normalen Movia/DiMA oder in der Movia-Admin-Umgebung?
Ich hab jetzt mal nachgesehen. Im Bucket sind 69753 Objekte enthalten. Da S3 in Wirklichkeit keine Ordner kennt (die werden einem vom Client nur vorgetäuscht) muss immer der ganze Bucketinhalt vom Storagesystem abgefragt werden. Die Antwort ist bei 69753 Objekten entsprechend lang. Das so mancher Client damit etwas überfordert ist, wäre für mich jetzt auch nicht ganz abwegig. Vor allem muss sich der Client die Ordner selbst herausrechnen. Das JSON, dass der Client verarbeiten muss ist 34 MB groß.
Meine Antwort:
Bitte auch mal prüfen welche WinSCP-Version du hast.
Ich habe WinSCP der Movia-Admin-Umgebung verwendet. Es ist also die Version, die der Großteil der Benutzer verwendet. Wenn das Tool iwo anzeigen würde, welche Version es ist, könnte ich sie dir nennen, finde es aber nicht.
um WinSCP als Fehlerursache auszuschließen
Aus meiner Sicht ist WinSCP als Fehlerquelle schon dadurch ausgeschlossen, dass das Problem durch die Benutzung von DigiWF aufgefallen ist. Im Browser wurden exakt wie mit WinSCP mal die einen mal die anderen Ordner bzw. Dateien angezeigt. Es ist also das identische Verhalten mit unterschiedlichen Tools aufgetreten.
Dazu müsste wir aber erst WinSCP dazu bekommen den Fehler zu reproduzieren um einen direkten Vergleich zu haben.
Ich habe von dir bisher die Auskunft erhalten, dass es an nicht synchronen Nodes liegt. Der Fehler tritt mit WinSCP nicht mehr auf, woraus ich geschlussfolgert habe, dass die Synchronisation nun hergestellt ist.
Im Bucket sind 69753 Objekte enthalten. Da S3 in Wirklichkeit keine Ordner kennt (die werden einem vom Client nur vorgetäuscht) muss immer der ganze Bucketinhalt vom Storagesystem abgefragt werden. Die Antwort ist bei 69753 Objekten entsprechend lang. Das so mancher Client damit etwas überfordert ist, wäre für mich jetzt auch nicht ganz abwegig. Vor allem muss sich der Client die Ordner selbst herausrechnen. Das JSON, dass der Client verarbeiten muss ist 34 MB groß.
Um in WinSCP zu dem betroffenen Vorgang zu kommen, öffne ich nicht erst den gesamten Bucketinhalt, sondern
Strg+O > in 'Verzeichnis Öffnen' '[Ordner zensiert]' eintragen > OK
Der Ordner öffnet sofort und ich würde sagen, dass kein 34 MB großes JSON verarbeitet werden muss.
Kurz: WinSCP als Fehlerursache ist meiner Meinung nach die falsche Spur.
18.03.2024 13:57:11 Uhr ‐ S3-Team:
Hallo Marko,
es hat sich nun herausgestellt, dass sich StorageGRID entsprechend des Konsistenz-Levels richtig verhalten hat. Aber der Reihe nach:
Alle Schreib-, Lese- und Löschanfragen, die an Storagegrid geschickt werden, sind "irgendwann konsistent". Ausgenommen davon ist das Schreiben eines neuen Objekts. Dieses ist sofort für nachfolgende Leseanfragen verfügbar. Das gilt aber nur wenn das Objekt explizit gelesen wird. Bei einer Abfrage des Bucketinhalts ist das leider nicht der Fall. (Der Mechanismus, der beim expliziten Lesen eine sofortige Konsistenz ermöglicht, funktioniert bei der Inhaltsabfrage des Buckets nicht.)
Entsprechend der Logs konnte ich sehen, dass deine Anwendung (DigiWF) nicht die Objekte direkt liest, sondern erst den Bucketinhalt abfrägt. Diese Operation ist aber erst "irgendwann konsistent", wie im vorherigen Absatz beschrieben. Laut der Logs unternimmt DigiWF dann gar keinen expliziten Lesezugriff mehr auf das Objekt, nachdem das Objekt nicht im Bucketinhalt auftaucht.
Das Konsistenzverhalten "irgendwann konsistent" ist für S3 (so bedauerlich es auch ist) aufgrund seiner Architektur der Regelfall. Es gibt nun zwei Möglichkeiten. Die Erste ist, dass DigiWF direkt versucht die Objekte zu lesen ohne vorgelagerte Abfrage des Bucketinhalts. Überschreibungen und Löschungen sind bei diesem Vorgehen aber weiterhin „irgendwann konsistent“. Die zweite Möglichkeit ist, wie schon besprochen, der HTTP-Header "Consistency-Control: strong-global". Das wird aber auch zur Folge haben, dass bei Ausfällen von S3-Systemkomponenten (RZ-Ausfall, >1 Storageknoten fällt aus) deine Anwendung mit höherer Wahrscheinlichkeit nicht mehr Schreiben, Lesen und Löschen kann, während andere Anwendungen noch problemlos weiterarbeiten können. (Natürlich kannst du in diesem Fall den Header wieder herausnehmen und dann kann auch deine Anwendung (DigiWF) wieder auf S3 zugreifen, wie alle anderen Anwendungen auch. Auch sollte so ein Ausfallszenario hoffentlich nie eintreten.)
Auch solltest du noch bedenken, dass es Anwendungen gibt, welche nicht damit zurechtkommen, dass sie ggf. nicht mehr schreiben können. Das kann sogar soweit gehen, dass Datenverlust auftritt. Das ist aber von Anwendung zu Anwendung unterschiedlich und musst du für DigiWF ggf. zusammen mit dem Hersteller individuell klären.
Bei weiteren Fragen zum Konsistenz-Level kannst du dich gerne nochmal melden.
P.S.: Storagegrid hat das evtl. gelogt, da aber eine Zustimmung diese Logs an den Hersteller weiterzugeben nicht erteilt wurde, konnten diese nicht weiter ausgewertet werden.
Habe das weiter analysiert. An der Stelle, wo es fehlschlägt, wollen wir unter anderem prüfen, ob die Datei existiert, bevor wir die Presigned-Url rausgeben. Dafür werden momentan sämtliche Dateinamen eines Ordners geladen und dann geprüft, ob die angefragte Datei dabei ist. So eine Ornderabfrage wird uns, wie oben geschrieben, aber nicht garantiert.
Die Lösung des Problems kann teilweise darin bestehen, dass wir versuchen, die Metadaten des Datei-Objekts zu laden. Gelingt das, ist die Datei vorhanden.
Um das Szenario mit inkonstenten Nodes zu vermeiden, müssten S3-Ordnerabfragen komplett ausgebaut oder ab einem bestimmten Zeitpunkt für neue Uploads vermieden werden. Das Frontend müsste so umgebaut werden, dass es keine Ordnerinhalte, sondern nur noch direkt Dateiobjekte anfragt.
Das geht leider nicht so einfach, da man offen halten möchte, welche und wie viele Dateien der User hochlädt. Gleichzeitig ist es Richtung Dateihandling im Prozess ein Feature, dass man alle Dateien, z.B. alle Eingangs-Dateien, mit einem Wert adressieren kann.
Wir sollten nochmal über das Thema sprechen
https://docs.netapp.com/us-en/storagegrid-116/s3/consistency-controls.html#consistency-controls
Zurück auf New, da hier nochmal ein gesamtheitliches Konzept erarbeitet werden muss.
S3 DB wird mit #1264 abgeschafft. Für DigiWF ist der Rest nicht mehr relevant