Datenbankserver aber wie ?

hallo Toby-ch,

grundsätzlich gilt: die Datenbank so nahe wie möglich an die Applikation bringen, Netzwerkverkehr vermeiden, Latenzen möglichst gering halten. Heißt bei dir: Wenn dein unraid es von der Leistung her gestemmt bekommt, lass die Datenbank(en) auf deinem docker host laufen, um sie so nah wie möglich an die Applikation zu bringen.

unraid ist ein Linux und docker ist bekannt dafür, hier so gut wie kein overhead zu haben, deine Container laufen also nativ auf einem Linuxkernel und verbrauchen so gut wie keine unnötigen Ressourcen. Ich verweise hier auf das Paper von Felter et al. im Auftrag von IBM aus dem Jahre 2014. Dort wurde die Performance von Software auf bare metal, KVM und docker getestet. Zusammenfassung: Software läuft in Docker quasi mit nativer Geschwindigkeit (bare metal) und hat weniger als ein Prozent, meistens sogar weniger als 1 Promille Performanceverlust durch die Nutzung von cgroups und namespaces. AUSNAHME: NAT! solltest du also irgendwas krasses schweres im Netzwerk machen, merkst du die Umsetzung im docker Netzwerk auf NAT und die Abstraktionsschicht frisst Performance. Ausnahme der Ausnahme: Netzwerktyp host. Da läuft alles wieder quasi mit nativer Geschwindigkeit, aber du Verlierst die Isolation der Container und des Netzwerkverkehrs durch die namespaces. Aber sowas macht man eigentlich nicht, wenn man nicht muss oder weiß was man da tut...

Warum ich das erwähne? Du spielst also mit dem Gedanken, deine Datenbanken von deinen Applikationen zu trennen und an einen anderen Standort im Netzwerk zu verschieben. An sich eine gute Idee. Machen wir im Rechenzentrum genau so. Die Rackstation 1221+ scheint dafür auch geeignet mit ihren 4 Netzwerkports. 2 für das Hauptnetzwerk und mit 2 im LACP machst du ein eigenes Speichernetzwerk auf. Oder 1/3 oder 3/1. So wie du es bei dir brauchst.

Habe nur bitte im Hinterkopf, dass dir docker bei Daten über das Netzwerk performance klaut für das Umsetzen/Übersetzen im NAT. wie kann man das umgehen?

Du machst ein eigenes Speichernetzwerk (SAN) auf zwischzen deinem unraid und deiner Rackstation. bedeutet es gibt ein exklusives Netzwerk, welches nur für die Verbindung der Container und deiner Datenbanken gedacht ist. kein Broadcast vom Smartphone, keine Gäste, kein Internet... direkte Verbindung zwischen den Containern und den Datenbanken.
Wie du das genau machst überlasse ich dir und deinen Begebenheiten vor Ort. Komplette physische Trennung mit eigenem Switch, eigenen Kabeln, oder DAC... Du kennst dein Netzwerk besser als ich :D
Ich persönlich würde eine Portgruppe auf meinem Switch in ein eigenes VLAN heben (/30 oder /28 oder je nachdem was du brauchst) und die Netzwerkschnittstellen via 802.1AX (LACP) zusammenfassen. Gibt auch andere Konfigurationen... auch hier: mach, was dir am besten in dein Netzwerk und deinen Geldbeutel passt.
Deine Container bekommen dann einen zweiten Netzwerkanschluss, NICHT mit Bridge, sondern mit host, direkt auf dem SAN-Netzwerk.. et voila. so gut wie kein Overhead mehr durch NAT, docker container und getrennte Datenbanken.

meine Meinung? du hast nen unraid-Server und eine Rackstation mit x86_64 CPU (Ryzen V1500B). such dir einen der Hosts aus und lass da immer schön alles zusammen laufen. Kein netzwerk ist so schnell und performant wie syscalls und sockets im kernel im selben Arbeitsspeicher... also immer eine App zusammen mit einer DB auf einem Host laufen lassen. SAN ist ne schöne Sache, macht hier aber nicht wirklich Sinn bei so einem kleinen Aufbau... MEINE MEINUNG! kannste auch ignorieren und mal testweise ein SAN bauen (: machst Erfahrungen und lernst dadurch. _könnte_ sogar Spaß machen..... :D
fasse die beiden Hosts in einen Docker Schwarm zusammen, gib dem Schwarm mit glusterFS oder ceph einen gemeinsamen Datenpool (egal wo) und nutze die jeweils andere Maschine (unraid/rackstation) für die Backups. so hast du Redundanz, Geschwindigkeit und Backups und Docker... (:

es ist übrigend vom Design her bei Docker so, dass für jeden Service ein eigener Container hochgefahren und bereitgestellt wird. 2 Datenbanken brauchen also 2 Container. besonders oder gerade weil die beiden dazugehörigen Apps nichts miteinander zu tun haben und getrennt voneiniander zu betrachten sind. die beiden Datenbanken der beiden getrennten Apps jetzt zusammenzufassen entspricht nicht dem Gedanken und dem Design von Docker. App 1 braucht Version X und App 2 braucht Version Y der Datenbank. Da wird es sehr schnell sehr komisch und es zerschießt dir die Apps und du musst da auf Fehlersuche gehen, etc.
Genau das will man ja durch den Einsatz von Docker vermeiden... Ich kann auf einem einzelnen Host ohne große Probleme unendlich viele unterschiedliche Versionen einer Software laufen lassen und die kommen sich alle nicht in die Quere... hängt sich einer auf oder spackt rum oder funktioniert nicht richtig, baue ich den Container einfach neu und ersetze den fehlerhaften Container durch den frischen.
Performanceverlust? Deswegen nehme ich für so gut wie jeden Container alpine. die 50 MB RAM für einen weiteren Container solltest du auf deinem unraid oder deiner Rackstation schon noch übrig haben ;)