MQTT broker in Proxmox Umgebung - eigener Container?

[tritor]

Hallo an die Exepertenrunde,

ich bin am Umziehen von meinen 2 RaspPi's auf meinen Intel NUC mit Proxmox.

Es lauft ioBroker in einer Deb10 VM und influxDB und Grafana in einem Container.
Da ich den MQTT-broker noch umziehen möchte stellt sich die Frage wie am besten:

1. in der ioBroker VM dazuinstallieren
2. in dem influxDB/Grafana Container dazuinstallieren
3. in einem eigenen Container installieren

Die Auslastung bei Punkt 1 und 2 lassen das Dazinstallieren mit Sicherheit zu. Da bin ich mit durchschnittlicher CPU Load und Memory Auslastung unter 20%.

Der Punkt 3 hätte den Vorteil, daß die einzelnen Services besser aufgeteilt sind. Und sollte eine VM oder ein Container mal ein Problem haben, sind nicht gleich alle Services betroffen.

Für ein paar Ratschläge bin ich schon im Vorhinein dankbar.

Beste Grüße
tritor

Host: IntelNuc i3 8.Gen. Debian 10 for ioBroker
ioBroker: 4.1.1, Node.js: 12.16.2, NPM: 6.14.4, JS-controller: 3.0.20

[leon]

Das würde mich auch mal interessieren. Ich höre immer VM oder Container. Proxmox und Docker. Wäre es denn wirklich besser die einzelnen Services aufzuteilen? Habe eine TVHeadend Server mit OSCam und easymouse, iobroker mit MQTT mosquitto, Node-Red im Einsatz. Ich betreibe das alles auf einem PI 4 mit 4GB. Wenn der TVHeadend Server mit dem Timeshift mal spinnt, dann zieht er mir auch die anderen Services runter. Da ist schon was dran.
Vielleicht macht es wirklich sinn, den TVHeadend auf einen eigenen Container oder VM laufen zu lassen.

[mickym]

Also aus logischen Gründen käme für mich nur Option 1 oder 3 in Frage, da ich davon ausgehe, dass Du Deinen Datenbanken aus den Datenpunkten des iobrokers speist und nicht aus Deinem MQTT-Broker direkt.

Ob Option 1 oder 3 würde ich davon abhängig machen, ob Du den wirklich das eine oder andere unabhängig betreiben willst.
Die Performance den MQTT-Broker und iobroker auf einer Maschine zu haben (option 1), ist sicher dass das wahrscheinlich (wenn auch vielleicht nicht spürbar) performanter ist, da Du den ganzen Overhead und die virtuellen Switches Deiner virtuellen Umgebung nicht brauchst.

Eine Trennung der Services würde aus meiner Sicht nur dann Sinn machen, wenn Du mal planst ein anderes System mit Deinem MQTT-Server zu betreiben, als mit iobroker.

Deshalb ist für mich die Aufteilung der Services in einzelne Maschinen oder Container eher ein Nachteil und nur ein sinnvolles Clustern macht sinn und man hält das zusammen was zusammengehört - für jetzt und in der Zukunft. Sollten sich die Abhängigkeiten mal ändern ist das was anders. Oder andere Frage, was nützt Dir ein funktionierender MQTT-Server, wenn iobroker nicht läuft.

Andererseits kann man natürlich argumentieren, dass Du Deinen iobroker warten kannst und dafür Deine Geräte nichts merken, da Dein MQTT Broker noch online ist. Das wäre dann schon ein valider Grund für Option 3.

[BBTown]

@tritor
Ich persönlich würde immer erst den eigenen, separaten Container ausprobieren.
Dabei würde auch bei mir die Möglichkeit die Systeme separat warten zu können ausschlaggebend sein. Sofern ein Fehler in einem System auftritt, reisst es nicht gleich das andere mit ins Verderben.
Solltest Du auch einmal dein System so ändern, dass der MQTT gar nicht mehr benötigt wird, dann kannst Du das auch wieder schneller/leichter voneinander trennen ohne Altlasten auf einem System zu hinterlassen.

In wie weit Laufzeitverhalten eine signifikante Rolle bei den unterschiedlichen Variamten spielen, kann ich allerdings nicht beurteilen.

[danyo80]

@bbtown Moin, ist zwar schon etwas älter der Thread, aber wollte ihn nochmal aufleben lassen. Wir würdet ihr den Container für einen MQTT Mosquitto dimensionieren. (Plattenspeicher, RAM, etc.)....