Willkommen im Loxone Community Forum. Um alle Funktionen nutzen und sehen zu können, registriere dich bitte zuerst. Dies gilt auch für das herunterladen von Dateien.
Was Prof.Mobilux anbieten will ist eine einfache Lösung, die jeder DAU konfigurieren kann.
SD Karte flashen, in den Pi und loslegen. Also den Sinn hinter dem Pi versteh ich durchaus.
Ich kenn mich selber auch (noch) nicht wirklich aus, aber da ich ein NAS habe, welches visualisieren kann, stelle ich mir die Frage ob man das Image nicht auch in einer VM zum laufen bringen könnte. Dann würde das Ganze am gebackupten RAID5 liegen. Da hätte ich weniger Bedenken bzgl. Ausfällen.
Bin da bei dir, Christian, ein Raspberry-Image lässt sich nicht sauber in einer VM betreiben. Dafür ist es aber auch nicht gemacht. Ich frage mich allerdings, wie hoch der Aufwand ist, das Image auf eine VM anzupassen... da ich mehrere Virtualisierungsserver habe (Xen und VMware), kann ich das aber gerne mal austesten, sobald das Image vorliegt.
@Shogun1978: das wär echt spitze von dir! Ich hab zwar grundsätzlich nichts gegen den Pi (hab 2 2er in ständiger Verwendung), jedoch würde ich für so einen Andwendungfall definitiv ein VM Image vorziehen.
Was Prof.Mobilux anbieten will ist eine einfache Lösung, die jeder DAU konfigurieren kann.
SD Karte flashen, in den Pi und loslegen. Also den Sinn hinter dem Pi versteh ich durchaus.
Ja, das geht vielen so. Der Anfangschwung kann aber schnell verloren sein, wenn die Anwender etwas mehr Leistung benötigen und durch die Hardware beschränkt werden. Und da ist der RasPI leider eine Sackgasse. Je nach Unterbau wird es einfacher oder schwieriger das auf andere Plattformen zu Portieren. Da wird das Forum und Wiki wieder gefordert sein.
(Für die richtigen Hipster unter uns wäre das sowieso nur ein reines Docker-Thema ;-)
Also ich sehe das auch als Panikmache. Der RaspberryPi2 hat einen Quadcore Prozessor. Was der leistet ist enorm. Und das geräuschlos und ohne Kühler auf'm Kopf. Ich benutze den Pi für viele Dinge und wenn ich da mal draufsehe, schläft der vor sich hin. Sicher, der RaspberryPi ist kein Hochleistungsrechner. Doch wer das erwartet ist dabei auch fehl am Platz. Hat man den Eindruck dass der Raspberry nicht der Leistung gewachsen ist die benötigt wird. Der kann sich ja mehrere davon aufbauen. Das ist noch immer günstiger in der Anschaffung und Unterhaltung als ein flüssig laufender Windowsrechner.
Wer Angst hat, durch zu viele Speicherzugriffe die SD-Karte zu Schrotten, der kann ja immernoch das Rootfilesystem auf eine Platte spielen und dann davon Booten. Bevor ich gleich eins auf den Deckel bekomme ... Ja, der RaspberryPi kann nur von der SD-Karte gebotet werden. Allerdings betrifft das nur die Bootsequenz und damit den Ordner /boot. Der komplette Rest kann auf eine Festplatte ausgelagert werden. Auf /Boot wird nur bei Updates geschrieben.
Gruß Sven
Miniserver; KNX; Vitogate; EnOcean (EnOceanPi); Loxone Air; Caldav-Kalenderanbindung; RaspberryPi und für keine Frickellösung zu schade :-)
Sicher ist der Raspberry Pi keine Monsterrechenmaschine - braucht man aber in dem Fall auch nicht. Was aber durchaus sinnvoll wäre, ist die optionale Anbindung eines NAS-Speichers. Die sind doch mittlerweile bei vielen Leuten verbreitet. Ich selbst nutze auch ein Openmediavault-System mit MariaDB. Dort läuft das OS auf einer SSD und die Datenbank selbst auch. Warum? Weil hier kaum bis gar nicht geschrieben wird, da ich die MariaDB nur für meinen Kodi-Clients (alles Raspberry Pi2) nutze. Da wird in 95 % der Fälle gelesen. Für eine "normale" Datenbank tut's eine kleine HDD oder man spiegelt (meist mit Bordmitteln des Mainboards) die Daten zwischen zwei SSDs. Da ist ja keine große Last drauf. Zum Thema Haltbarkeit:
SLC (Single Level Cell) - highest performance, at a very high cost, enterprise grade NAND
~ 90-100,000 program/erase cycles per cell (highest endurance)
- lowest density (1 bit per cell, lower is better for endurance)
- lower power consumption
- faster write speeds
- much higher cost (3 times higher than MLC)
- good fit for industrial grade devices, embedded systems, critical applications.
eMLC (Enterprise Multi Level Cell) - good performance, aimed at enterprise use
~ 20-30,000 program/erase cycles per cell
- higher density (2 bits per cell)
- lower endurance limit than SLC, higher than MLC
- lower cost
- good fit for light enterprise use and high-end consumer products with more disk writes than MLC.
MLC (Multi Level Cell) - average performance, consumer grade NAND
~ 10,000 program/erase cycles per cell
- higher density (2 or more bits per cell)
- lower endurance limit than SLC
- lower cost (3 times lower than SLC)
- good fit for consumer products. Not suggested for critical applications which require frequent updates of data
TLC (Three Level Cell) - lower performance, lowest cost NAND
~ 3-5,000 program/erase cycles per cell
- highest density (3 bits per cell)
- lower endurance limit than MLC and SLC
- best price point (30% lower than MLC)
- somewhat slower read and write speed than MLC
- good fit for lower-end consumer products. Not recommended for critical applications which require frequent updating of data
TLC kommt bei USB-Sticks und SD-Karten zum Einsatz. Also 3000-5000 Schreib-/Löschzyklen. Allein der Einsatz einer normalen Consumer SSD verdoppelt hier den Wert (10.000 Zyklen). Wenn man bedenkt, dass man aber noch einen gewissen Overhead in den SSDs hat (eine 32GB SSD hat definitiv mehr als 32 GB in MLC Chips, i.d.R. 10-25% mehr), dann merkt man schnell: das System hält normalerweise ein paar Jahre. Hier mal ein Rechenbeispiel: wenn ich bei TLC Speicher (max. 3000 Zyklen) 1 MB pro Sekunde auf den Speicher schreiben würde, dann würde eine 32 GB SD-Karte immer noch 9,6 Jahre halten (bei optimaler Verteilung). Bei einer SSD Festplatte (mit MLC) wären es dann entweder 3 MB pro Sekunde oder 316 Jahre bei 1 MB pro Sekunde. Ich befürchte, dass beim Einsatz einer SSD Festplatte mit MLC Speicher eher die restliche Hardware veraltet als dass die SSD den Geist auf gibt... ;-)
Die Rechnung geht für SSD's auf, das ist nach heutigen Erkentnissen kein Problem. Bei SD-Cards liegen die Probleme noch etwas Anders. Da kommt es auch extrem darauf an, was für ein Filesystem schlussendlich darauf läuft. Und das wear leveling ist eine Blackbox. Das führt zu komischen Empfehlungen in Embedded-Kreisen. So sinngemäss kauf eine 16GB SD, formatiere nur 8GB und das Teil hält doppelt so lang. Leider genau umgekehrt. FFS https://en.wikipedia.org/wiki/Flash_file_system setzen sich dann doch nicht so durch. Und SLC-MicroSD will niemand bezahlen.
Die sind ja mal echt bezahlbar! Aber worauf ich eigentlich hinaus wollte: die wenigstens werden im täglichen Betrieb diese Grenzen erreichen... vorher bastelt jeder von uns noch an anderen Lösungen rum. Und die meisten Bastelarbeiten bringen neue Hardware mit sich ;-)
Im Prinzip ist es ja einfach: Alle zu beschreibenden Dateien liegen in einem gemeinsamen Verzeichnis (mit Unterordnern). Ob das ein Verzeichnis ist (Standard-Image) oder ein Mountpoint, ist ja egal.
Man muss halt alle schreibenden Prozesse, auch wenn sie aus Raspbian kommen, dort hin umverbiegen. Und das könnte ein Aufwand werden.
lg, Christian
Wie gesagt, das ist überhaupt kein Aufwand und dafür braucht es auch kein zusätzliches NAS.
USB Platte an den Raspi. Ext4 formatieren. Alles außer /boot darauf kopieren. Rootmountpoint der SD-Karte deaktivieren dafür Rootmountpoint für die USB-Platte anlegen und in der bootconfig also Rootdevice die USB-Platte angeben und schon kommt alles außer /boot von der Platte.
Miniserver; KNX; Vitogate; EnOcean (EnOceanPi); Loxone Air; Caldav-Kalenderanbindung; RaspberryPi und für keine Frickellösung zu schade :-)
Stimmt, Svethi, mit einer USB Platte geht das auch. Ich habe halt schon ein NAS, daher der Wunsch. Ein NAS muss man für so eine Lösung sicher nicht erst kaufen. Aber ich habe hier schon bei dem ein oder anderen gemerkt, dass eine gewisse Affinität zu technischen Spielereien vorhanden ist - was oft auch in einem "Familien-NAS" endet (für Bilder, Filme, Musik etc.)
Ah, nun ja... ich hab festgestellt, dass bei ca. 500 Filme, über 800 Serien-Episoden sowie Musik, Bildern und persönlichen Daten (die kann man vernachlässigen) 3 TB etwas knapp sind. Ergo: es erfolgte ein Umbau auf Openmediavault (Quadcore-Celeron mit 8 GB - nur als Reserve, falls ich mal auf ZFS oder Btrfs wechsele, 3x 4 TB im Raid 5). Seither läuft alles doch um einiges schneller. Und da meine Frau als Physikerin eine gewisse IT-Affinität aufweist, konnte ich sogar ein 19" Rack (im Abstellraum) durchsetzen :-)
Ich hatte es ja schon einmal geschrieben: Prinzipiell ist eine Portierung auf einen anderen Minicomputer, NAS oder sonstwas überhaupt kein Problem. Der Loxberry besteht lediglich aus ein paar Perl-Skripten und der auf Debian basierenden Distri Raspbian. Das sollte nicht weiter problematisch sein den Loxberry auf eine andere Hardwarebasis zu portieren.
Die Schreibzugriffe auf die SD-Karte möglichst zu minimieren finde ich eine sehr gute Idee. Alles vom loxberry liegt schon jetzt in einem Unterverzeichnis von /opt. Alle anderen Schreibzugriffe auf das Linuxsystem sollten sich zu 99% unter /var abspielen. Man könnte /var einfach mit einem Link auf /opt/var umbiegen. Anschließend ließe sich die komplette /opt-Hierarchie einfach auf einen USB-Stick, eine SSD, USB-Platte oder ein NAS-Laufwerk verschieben.
Also dann kann ich gerne ein entsprechendes ovf oder ähnliches erstellen. Gerne auch ein minimales Debian, wenn du mir eine Art Tutorial dessen an die Hand gibst, was du installiert hast. Ich baue das einfach nach und wir können ein Image für den Raspberry Pi und eins für virtuelle Umgebungen anbieten. Mit ovf wird von den meisten Virtualisierungsplattformen unterstützt. Docker oder andere Containerformate sind noch zu wenig verbreitet.
Preis: guckst du hier...http://www.saelig.com/product/M00047001.htm.... also garnicht günstig und für den hier beschriebenen Einsatzzweck auch ein bisschen aufgeblasen. ;-)
Gruß Micha..
bin leider auch erst sehr spät auf dieses Thema gestoßen und finde es echt ne super idee. Bin mal auf die Beta gespannt und schon mal vielen Dank für die ganzen Mühen. Denke dass sich auch einige Unterstützer finden werden.
Wir verarbeiten personenbezogene Daten über Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen, Werbung zu personalisieren und Websiteaktivitäten zu analysieren. Wir können bestimmte Informationen über unsere Nutzer mit unseren Werbe- und Analysepartnern teilen. Weitere Einzelheiten finden Sie in unserer Datenschutzrichtlinie.
Wenn Sie unten auf "Einverstanden" klicken, stimmen Sie unserer Datenschutzrichtlinie und unseren Datenverarbeitungs- und Cookie-Praktiken wie dort beschrieben zu. Sie erkennen außerdem an, dass dieses Forum möglicherweise außerhalb Ihres Landes gehostet wird und Sie der Erhebung, Speicherung und Verarbeitung Ihrer Daten in dem Land, in dem dieses Forum gehostet wird, zustimmen.
Kommentar