Buanet-docker auf QNAP NAS mit 2 getrennten IP Netzen

[wendy2702]

@kla960 Also da ist mein Sohn auch aktiv aber das dadurch bei uns der Stream oder etwas anderes unterbrochen wurde hatten wir noch nie.

Mal das aktiviert für die Geräte die Streamen:

[kla960]

@wendy2702 Vielleicht können wir uns hier wieder auf das eigentliche Thema konzentrieren. Danke

[wendy2702]

@kla960 Sicherlich.

Wollte eigentlich nur darauf hinweisen das es auch ohne zwei getrennte Netze funktionieren sollte.

[wendy2702]

@kla960 sagte in Buanet-docker auf QNAP NAS mit 2 getrennten IP Netzen:

Ein paar Punkte sind aber noch nicht ganz sauber.

• kann man mein single Backup in Multihost verwenden? Wenn ja, wie?

Was genau meinst du mit „single“ Backup? Wenn du das erstellt hast bevor du ein Multihost System erstellt hast enthält es nur die Daten vom Master, stellt dir also beim Restore nur den Master her.

• Wie kann man bestimmen das Frontend (mein FB Netz) die erste Schnittstelle im Container wird?

Da kann ich leider nichts zu sagen da ich keinen Docker auf QNAP nutze.

• und dann noch mac_address: zuweisen, damit mir die FB nicht immer mitteilt, dass ein neues Gerät hinzugekommen ist.

Verstehe nicht genau was du damit meinst. Im Einfachsten die Benachrichtigungen der FB deaktivieren aber von welcher MAC redest du denn?

• Macht es Sinn noch Redis als db hinzuzufügen? Nachdem was ich lese eigentlich nur für states. Was macht Ihr diesbezüglich?

Redis ist/soll etwas schneller sein als File aber mit JS-Controller wird das format eh, wenn man will auf JSONFile umgestellt wodurch das System stabiler und sicherer gegen z.B. Stromausfälle werden soll.

[kla960]

@wendy2702 sagte in Buanet-docker auf QNAP NAS mit 2 getrennten IP Netzen:

@kla960 sagte in Buanet-docker auf QNAP NAS mit 2 getrennten IP Netzen:

Ein paar Punkte sind aber noch nicht ganz sauber.

• kann man mein single Backup in Multihost verwenden? Wenn ja, wie?

Was genau meinst du mit „single“ Backup? Wenn du das erstellt hast bevor du ein Multihost System erstellt hast enthält es nur die Daten vom Master, stellt dir also beim Restore nur den Master her.
im

Momentan habe ich ja noch mein Single ioBroker laufen. Das Multisystem teste ich gerade. Wenn es das macht, was ich will, sollten schon die meisten Objekte übertragen werden. Will nicht unbedingt alles neu anlegen. Der erste Versuch mein Single System Backup im Multimaster herzustellen war nicht so erfolgreich.
Den /opt/iobroker Pfad umhängen war vielversprechender.

• Wie kann man bestimmen das Frontend (mein FB Netz) die erste Schnittstelle im Container wird?

Da kann ich leider nichts zu sagen da ich keinen Docker auf QNAP nutze.

• und dann noch mac_address: zuweisen, damit mir die FB nicht immer mitteilt, dass ein neues Gerät hinzugekommen ist.

Verstehe nicht genau was du damit meinst. Im Einfachsten die Benachrichtigungen der FB deaktivieren aber von welcher MAC redest du denn?

Lt. dem was ich gelesen habe, werden die beiden Punkte ein Problem bleiben, da man die Netzwerkschnittstellen nicht priorisieren kann. MAC-Adressen Zuordnung ist auch nicht gut implementiert.
Beispiel in docker compose:

mac_address: 02:42:4e:ec:ad:97

• Macht es Sinn noch Redis als db hinzuzufügen? Nachdem was ich lese eigentlich nur für states. Was macht Ihr diesbezüglich?

Redis ist/soll etwas schneller sein als File aber mit JS-Controller wird das format eh, wenn man will auf JSONFile umgestellt wodurch das System stabiler und sicherer gegen z.B. Stromausfälle werden soll.

Habe jetzt mal die states in Redis verlagert. Habe halt langsame Platten keine SSDs in meinem NAS. Nach allem was ich lese, sollte das besser für die Performanz sein. Memory hat mein NAS mit 8 GB eigentlich ausreichend, hingegen läuft auf dem NAS ja mehr als nur ioBroker und die HDDs bremsen unter Last schon ordentlich.

[kla960]

@wendy2702 sagte in Buanet-docker auf QNAP NAS mit 2 getrennten IP Netzen:

@kla960 Sicherlich.

Wollte eigentlich nur darauf hinweisen das es auch ohne zwei getrennte Netze funktionieren sollte.

Wenn das für dich funktioniert? Aber das wirkt sich nur auf die upload Rate aus. Sieht man dann auch im Monitor. Steht auch so bei AVM.
Link Text

[wendy2702]

@kla960 das steht da aber nicht so.

Wenn du Echtzeit anwendest geht das in beide Richtungen. Im Beispiel steht ja extra drin wofür es ist:

Die Kategorie "Echtzeitanwendungen" eignet sich besonders für Anwendungen, die sehr hohe Anforderungen an die Übertragungsrate und Reaktionszeit stellen, z.B. Internettelefonie, IPTV oder Video-on-Demand.

Wenn du also deine Streaming devices mit Echtzeit priorisieren schauen deine Kids beim Download von Steam in die Röhre da das keine echtzeitanwendung ist.

Aber nochmal zum multihost.

Wenn das System funktioniert sollte es ausreichen die Instanz vom Master auf dem Slave zu „verschieben“. Es installiert sich dann die entsprechende Instanz auf dem Slave und ab danach übernimmt dieser die Arbeit. Du musst auf dem Slave kein Backup einspielen oder sonstiges machen.

Hoffe ich habe dich was den Punkt betrifft richtig verstanden.

[kla960]

@wendy2702 doch hier:

Priorisierte Anwendungen

Solange die Internetverbindung nicht von Echtzeitanwendungen ausgelastet wird, können Netzwerkgeräte und -anwendungen in der Kategorie "Priorisierte Anwendungen" bis zu 90% der Upload-Datenrate beanspruchen. Geräte und Anwendungen, die nicht priorisiert sind, erhalten somit auch dann 10% der Upload-Datenrate, wenn priorisierte Anwendung mit voller Last übertragen.

Nutzen mehrere priorisierte Anwendungen die Internetverbindung, wird die Datenrate gleichmäßig verteilt. Die Kategorie "Priorisierte Anwendungen" eignet sich für Anwendungen, die eine schnelle Reaktionszeit erfordern, z.B. VPN- und Terminal-Anwendungen oder Online-Spiele.

90% der Upload-Datenrate hier wird nur von Upload-Datenrate gesprochen.
Wie auch immer. Bei mir sind nur die Kinder am motzen, wenn die sich gegenseitig Ihre datenrate zuballern. Hauptsache meine Frau und ich haben uneingeschränkten Genuss

[wendy2702]

@kla960 nicht verwechseln!

Es gibt Echtzeit priorisierte Anwendungen/ Geräte

Und Priorisierte Anwendungen

[kla960]

Lt. dem was ich gelesen habe, werden die beiden Punkte ein Problem bleiben, da man die Netzwerkschnittstellen nicht priorisieren kann. MAC-Adressen Zuordnung ist auch nicht gut implementiert.
Beispiel in docker compose:

mac_address: 02:42:4e:ec:ad:97

Für den Fall, dass jemand dasselbe Problem hat. So sieht die Lösung für Docker Compose aus.

    mac_address: 02:42:4e:ec:ad:97
    networks:
      frontend-master:
        priority: 1000
        ipv4_address: 192.168.178.110
      intern:

Die frontend-master Schnittstelle kommt jetzt vor intern hoch und erhält die definierte mac_address.