NEWS
Umzug von Docker auf Proxmox - Redis / SQL?
-
Hallo zusammen,
ein ioBroker von Docker soll auf eine Proxmox Installation umzuziehen - dabei möchte ich gerne auch auf den aktuellen Stand kommen.
Daher es einfach zwei Jahre her ist, verstehe ich meine eigene Installation nicht mehr. Etwas ratlos lässt mich mein Docker zurück auf dem ein Redis-Server und ein MySQL Server läuft.
Etwas dunkel erinnere ich mich an Kopierscripte und Wartezeiten mit denen von "Standard" auf "Redis" umgestellt worden ist, ob ich beide Systeme für ioBroker aber nutze ist mir unklar.
Suchen nach iobroker, config, Konfiguration, show, anzeigen, redis setup usw waren aber nicht zielführend.
Wie checke ich meine Konfiguration drauf, ob ich Redis oder MySQL nutze und wie bekomme ich die Daten auf den neuen Server?
Soll ich dort dann auch gleich eine (andere) Datenbank wie Maria / Influx anbieten wenn es die Hardware hergibt?
Grüße & Danke
-
mysql
mysql wirst du wahrscheinlich für die historisierung von datenpunkten benutzen.
gehe einfach mal alle datenpunkte durch und schau ob da was aktiviert ist.redis
der aktuelle standard für iobroker ist jsonl. dies kommt ohne zusätzlichen service aus
überprüft und konfiguriert werden kann das von der shell aus mitiob setup custom
für die neue installation eine datenbank mysql/maria/influx nur dann wenn du die daten bspw mit grafana auswerten willst. für einfachere auswertungen kannst du ja die vorhandenen/aber noch zu installierenden adapter echart, flot, rickshaw, etc verwenden
den Umzug nach proxmox hast du die gut überlegt?
Aktuell finde ich die Aktualisierung des Basissystems mit docker (also betriebssystem, node und iob-js-controller) wesentlich einfacher.
eine vm reserviert den ram halt fix, container verwenden ihn dynamisch. -
@oliverio
Ganz vielen Dank - damit hast du mir schon mal sehr geholfen und ich kann an gewissen Punkten ansetzen.Ich nutze offensichtlich ganz klassisch den History Adapter und halte die Daten 1 Jahr im Filesystem.
Aus irgendeinem Grund möchte ich Daten aber endlos speichern und da erscheint mir eine Datenbank dann sinnvoller zu sein als Flatfile. Nur ein Gefühl.
Ich nutze aktuell ECharts, bin damit aber nie so richtig warm geworden und visualisiere dann nur im Fehlerfall oder bin am Ende mit dem Ergebnis nicht zufrieden. Ich werfe mal einen Blick auf Grafana, evtl. ergibt sich dadurch auch der Gedanke mit der DB.Redis:
Die Ausgabe ergibt:- Objects database:
- Type: jsonl
- Host/Unix Socket: 0.0.0.0
- Port: 9001
- States database:
- Type: redis
- Host/Unix Socket: 172.19.0.10
- Port: 6379
- Data Directory: ../../iobroker-data/
Bedeutet also wohl, ich muss auch den Redis-Server umziehen. Schade, ein weiterer Schritt der zu tun ist.
Das könnte noch ein relikt sein, als der iob auf dem Raspi lief und am Anschlag war.
Soweit ich lesen konnte, ist redis eigentlich nicht notwendig wenn der Host ausreichend Power hat. Ggf. also von redis zurück in json konvertieren und den redis server abklemmen. Ein System weniger...Zum Umzug auf Proxmox:
Guter Hinweis - denn ich habe mir das nicht besonders überlegt. Das Ziel des Umzugs ist vorhandene Systeme (HTPC mit Docker: iob & deconz + Raspi: CCU) zu konsolidieren auf einen ThinClient und in eine sinnvolle, einheitliche Datensicherung zu bringen. Da scheint es nur Proxmox + Proxmox Backup Server zu geben.
In Proxmox eine VM mit Docker einzuspielen um in diesem Docker dann den iob zu betreiben fänd ich auch etwas merkwürdig.Hast du da schon Erfahrungen mit beiden Varianten gemacht?
- Objects database:
-
@gutgut30 sagte in Umzug von Docker auf Proxmox - Redis / SQL?:
Soweit ich lesen konnte, ist redis eigentlich nicht notwendig wenn der Host ausreichend Power hat. Ggf. also von redis zurück in json konvertieren und den redis server abklemmen. Ein System weniger...
es kommt auf die anzahl der objecte an nicht auf die schnelligkeit der maschiene
-
@arteck said in Umzug von Docker auf Proxmox - Redis / SQL?:
es kommt auf die anzahl der objecte an nicht auf die schnelligkeit der maschiene
Das wären bei mir:
Objekte: 14227, Zustände: 12428Und sehr viel größer wird die Installation in absehbarer Zeit wohl auch nicht.
-
@gutgut30 dann kannst du auf jsonl gehen..
du kannst es umkonvertieren von redis auf jsonl... und dann redis abschalten
-
@gutgut30
Redis mysql maria
verwalten ihre Daten im Endeffekt auch in flatfiles.
Warum bei dir objects und states in gemischten Services liegen, würde ich auch korrigieren.Docker in einer Vm oder in einem lxc Container laufen zu lassen scheint wohl kein Problem zu sein. Wenn du nach „docker in proxmox“ suchst findest du diverse Artikel
-
@gutgut30 sagte in Umzug von Docker auf Proxmox - Redis / SQL?:
Aus irgendeinem Grund möchte ich Daten aber endlos speichern und da erscheint mir eine Datenbank dann sinnvoller zu sein als Flatfile. Nur ein Gefühl.
ich nutze History seit >4 Jahren und habe >200 DP teilweise im 5 Sekunden Takt dauerhaft gesichert.
Ja, die History hat jetzt fast 50GBaber ich wollte ohne weiteres externes Programm auskommen.
-
@arteck sagte in Umzug von Docker auf Proxmox - Redis / SQL?:
@gutgut30 dann kannst du auf jsonl gehen..
du kannst es umkonvertieren von redis auf jsonl... und dann redis abschalten
Gibt es eine Anzahl von Objekte/Zustände ab wann der Umstieg auf Redis Sinn macht?
-
@fredf said in Umzug von Docker auf Proxmox - Redis / SQL?:
Gibt es eine Anzahl von Objekte/Zustände ab wann der Umstieg auf Redis Sinn macht?
Da kann ich auch gerne mal helfen. Laut:
https://forum.iobroker.net/topic/26327/redis-in-iobroker-überblick"Dieses Setup wird für die meisten Installationen mit State- und Objektanzahlen bis weit in den 5-stelligen Bereich und mehreren 10.000 Ereignissen/15s selbst auf einem aktuellen Raspberrry Pi problemlos funktionieren."
-
@arteck said in Umzug von Docker auf Proxmox - Redis / SQL?:
@gutgut30 dann kannst du auf jsonl gehen..
du kannst es umkonvertieren von redis auf jsonl... und dann redis abschalten
Danke - werde ich machen. Macht den Umzug dann ja auch wesentlich leichter.
Sollte es doch später dann doch mal lahmen, kann ich ja immer noch eine Redis Instanz in der ioBroker VM installieren.