Flash Karte als Schwachstelle?

More
5 years 3 months ago #11 by Thomas Mayer
Permanente Schreib-Operationen auf der Flash Karte führen zu einem schnellen Verschleiß der Karte. Abhilfe schafft
  • Eine industrietaugliche Flash-Karte
  • Schreiboperationen ins Memory auslagern

Welche Schreiboperationen werden vom Laufzeitsystem logi.RTS bzw. vom Webserver logi.WEB permanent durchgeführt?

Please Log in or Create an account to join the conversation.

More
5 years 3 months ago #12 by Rainer Poisel
Im Falle des Laufzeitsystems und des Webservers gibt es drei Möglichkeiten, die zu Schreiboperationen am Zielrechner (in diesem Falle dem Raspberry Pi) führen:
  1. Download des Code-Images
  2. Das Speichern von Zuständen (Retaining) über mehrere RTS-Sessions hinweg
  3. Das Speichern einer Laufzeitstatistik
Die letzten beiden Punkte werden von logi.RTS und logi.WEB am Raspberry noch nicht unterstützt. Es ist daher nur beim Code-Download mit Schreiboperationen auf der Flash-Karte zu rechnen.

Eine weitere Variante wäre es, logi.RTS und logi.WEB so einzurichten, dass diese am Raspberry Pi auf einer RAM-Disk laufen. Dies hätte allerdings den Nachteil, dass bei Neustart des Systems die auf der RAM-Disk enthaltenen Daten (logi.RTS, logi.WEB und das Code-Image) verloren sind bzw. diese neu auf die RAM-Disk übertragen werden müssten.
The following user(s) said Thank You: Thomas Mayer

Please Log in or Create an account to join the conversation.

More
5 years 3 months ago #13 by Jodok Sutterlüty
Denkbar wäre auch ein Overlay-Dateisystem wie AUFS:

Die Flash-Karte wird read-only inkl. Deaktivierung des last-read-flags (ganz wichtig!) von ext4 gemountet. Es können also keine Schreiboperationen mehr durchgeführt werden. Nun legt man AUFS darüber, was alle Schreibzugriffe transparent abfängt und in eine eigene Buffer-Datei (die z.B. im RAM liegt) speichert bzw. wieder daraus liest. Diese Buffer-Datei wird dann periodisch oder vor einem Reboot auf die Flash-Karte geschrieben. So wird die Anzahl der Schreibzugriffe minimiert. Zugleich hat man auch ein kompaktes Backup aller relevanten Daten.

Jodok
The following user(s) said Thank You: Thomas Mayer, Rainer Poisel

Please Log in or Create an account to join the conversation.

More
5 years 3 months ago #14 by Rainer Poisel
Die Idee mit dem Overlay-Dateisystem finde ich gut! Das sollten wir auf jedenfall mal ausprobieren.

Ich möchte in absehbarer Zeit auch mal einen Test mit der inotify-Schnittstelle des Linux-Kernels durchführen. Damit lassen sich Statistiken über die Nutzung von Dateisystembereichen erstellen: iNotify im Ubuntu Wiki (z. B. mit inotifywatch und inotifywait). Mit Hilfe der Statistiken lässt sich dann überschlagsmäßig ermitteln, mit welcher Lebensdauer der eingesetzten Flash-Karten dann gerechnet werden kann.

Please Log in or Create an account to join the conversation.

More
5 years 3 months ago #15 by Jodok Sutterlüty
Eine weitere Möglichkeit, die mir einfällt, wäre, das ganze System im RAM laufen zu lassen.
Dazu braucht man auf der Flash Karte im wesentlichen nur noch 2 Files:
* den Kernel
* die RAM-DISK (initrd)
Der Bootloader lädt zunächst den Kernel und startet diesen. Als erstes wird die initrd entpackt (in eine temporäre RAM-Disk). Danach erzeugt das minimale Init-Script ein tmpfs RAM-Dateisystem mit ca. 20-30 MB (je nachdem, wieviel man braucht - wäre auch als Bootoption parametrierbar) und kopiert das komplette System in diese hinein. Danach findet der remount für das root Filesystem statt (pivot_root) und nun wird das eigentliche System-Init-Script gestartet.
Man kann das ganze auch noch um Module ergänzen, die nach dem Starten nach Bedarf zur Laufzeit von der Flash-Karte in die RAM-Disk geladen werden.
Auf diese Art und Weise hat man eine handvoll Dateien auf der Flash-Karte und das wars. Release-Rollout-Management ist dadurch natürlich relativ einfach.
Die persistente Sicherung der Daten geschieht dabei entweder wiederum mittels AUFS oder man führt Buch über die zu sichernde Dateien in einem File. Im Sicherungsfall liest das Script diese Datei aus und speichert alle relevanten Files in ein TAR Archiv (auf die Flash-Karte, USB-Stick, via Netzwerk auf einen Remote-Server usw.).

Dieses Verfahren macht nur Sinn, wenn man das System hoch optimiert (sprich alles weglässt, was man für den Betrieb nicht braucht). So wird aus einem Root-Filesystem mit ca. 2GB Größe schnell ein Filesystem mit ein paar MB (ich schätze, das System selber braucht mit den wichtigsten Tools vielleicht einmal 30-40 MB).
Zusätzlicher Vorteil: Die Sicherheit steigt, da extrem überschaubar.

Man bekommt so eine Art Appliance, die man recht gut unter Kontrolle hat.

Please Log in or Create an account to join the conversation.

More
5 years 3 months ago #17 by Thomas Mayer
Es wäre natürlich wünschenswert das gesamte System im Ram laufen zu lassen. Bis dahin kann man mit einer 1GB Karte die industrietauglich ist um € 24,28 auch gut leben, oder?

Please Log in or Create an account to join the conversation.

LOGI.CALS AUSTRIA

Address

Europaplatz 7/1,
3100 St. Pölten

LOGI.CALS GERMANY

Address

Postfach 1306,
40738 Langenfeld
© 1987 - 2019 logi.cals GmbH