toby-ch
Goto Top

Datenbankserver aber wie ?

Hallo zusammen

Ich zerbrich mir gerade ein wenig den den Kopf wie ich das in Zukunft mit den Datenbanken lösen soll.
Aktuelle habe ich es wie folgt gelöst:
docker-db
Der Docker dienst läuft auf einem Unraid System, dieses nutze ich ausschliesslich für Docker Container.
Alle 24H wird ein Backup der Container auf meine RS erstellt.
Betreffend Datenbanken habe ich dies wie im Bild dargestellt gelöst, jede Applikation ( Bookstack,Mediawiki) haben jeweils einen eigenen MariaDB Container.

docker-db-nas
Alternativ ich installiere das ganze auf meiner Synology, als Maria DB App und erstell dort die jeweiligen Datenbanken.


Was ist aus eurer Sicht die bessere Lösung?

Besten Dank für eure Inputs.

Content-Key: 6696124268

Url: https://administrator.de/contentid/6696124268

Printed on: July 27, 2024 at 00:07 o'clock

Member: LordGurke
LordGurke Apr 09, 2023 at 13:03:21 (UTC)
Goto Top
Auf den ersten Blick scheint es sinnvoll, einen zentralen Datenbankserver zu haben - allerdings ist ja der Vorteil der dedizierten Datenbanken, dass du exakt die Version mit den Einstellungen betreiben kannst, mit denen das zugehörige Projekt funktioniert. Es könnte (theoretisch) dazu kommen, dass Mediawiki spezielle Datenbankparameter benötigt oder eine neuere Version von MariaDB, mit denen Bookstack nicht funktioniert.

Von daher ist es eigentlich "Docker-Konform" jedes Projekt als eine Blase zu betrachten, in der sich alles befinden muss, mit dem das Projekt funktioniert und dazu gehört dann auch die Datenbank-Instanz.
Member: leisefuxX
leisefuxX Apr 10, 2023 updated at 09:12:21 (UTC)
Goto Top
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 ;)
Member: Toby-ch
Toby-ch Apr 10, 2023 at 19:55:26 (UTC)
Goto Top
Zitat von @leisefuxX:
Habe nur bitte im Hinterkopf, dass dir docker bei Daten über das Netzwerk performance klaut..


Ich habe da noch etwas verschwiegen der Docker Container erhält eine lokale IP von meinem Router in meinem VM-Vlan. Genau so auch der Docker der MariaDB, somit könne diese nicht direkt miteinander Kommunizieren.
Dies habe ich auch aus dem Grund gemacht da bei mehren DB,s der Standart Port verwendet werden kann.
Schlau oder das gegenteil? Sprich nutze nicht das "DockerNetzwerk"

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...

Genau dies war mein Gedanke ;)
übrigens sehr gut geschrieben dein Roman face-smile
Member: Mr-Gustav
Mr-Gustav Apr 11, 2023 at 08:42:23 (UTC)
Goto Top
Ist das mit den Containern nicht die Sache mit dem "Alles in einen Container packen" Sache damit ich den einfach speichern kann und das der dann wenn ich Fertig bin überall lauffähig ist ( In entspr. Containerinfrastrukturen natürlich )?

Spaß bei Seite......
Was ich von unserer Entwicklung her weiß ( ich Betreue den Teil der VMWare Umgebung / Tanzu irgendwas )
und unsere Entwickler Projektieren immer alles in einen Container wenn es denn geht.
Multi User Anwendungen mit verschiedenen UI von verschiedenen Systemen mit DB Zugriff mal außen vor.
Vorteil ist, wenn alles zusammen ist, das man die Container einfach gegeneinander austauschen kann.
Es gibt keine Beeinflussung der DB durch eine andere Anwendung.
Wenn z.B. in einer Anwendung der Strombedarf bzw. 100 Energieparameter erfasst werden sollen und diese dann in eine DB geschreiben werden sollen dann macht es eigentlich keinen Sinn das ich in die DB noch die Daten der Alarmanlage bzw. Parameter deren reinschreiben lasse.
Bsp.
Ich habe 2 Containeranwendungen: 1 x Energiemonitoring und 1 x Daten der Alarmanlage/Zutrittskontrolle.
Beide haben ihre eigene DB im Container. EnergieMon Container fällt aus -- Alarm/ZK läuft weiter und zeichet weiter auf. usw.....
Wenn es jetzt eine Zentrale DB gibt und diese dann ausfällt dann geht nix mehr.

Container haben ja auch den Vorteil das besondere Abhängikeiten sich nicht mehr auf andere Anwendungen / Systeme auswirken.

Wenn ich zb. für Container 1 die Library XYZ_SECURITY_0815 brauche für den DB Zugriff und die andere Anwendung aber mindestens LIB_SEC_0820 braucht dann stehe ich da...... Klar kann man es Probieren aber .........
Der Sinn von Containern war ja mitunter das die Abhängikeiten komplett im Container sind und es kein Update hin und her gibt.
Für Privat ist durchaus ein nettes Experiment .....Aber auch da versuche ich soviel DB Zugriffe wie möglich lokal zuhalten denn Zugriff = Latenz = eventuell Timeout bzw. Performance schlechter

Dann gibts z.b. noch die Sache mit den Lizenzen.... Wenn ich als Bsp. von Irgendeinem DB Server ( im Bsp. MSSQL / kann auch ein anderer sein welche eine Lizenzierung hat sein ) für X Lizenziert habe und ich somit nur eine Instanz betreiben darf dann wird´s eben nur einen DB Server geben. Alternativ Lizenziere ich nach und darf dann weitere einzelne DB Server Betreiben.
Bei den Lizenz Pflichtigen Programmen/Anwendungen/Servern ist das immer so ein heikles Thema an das kaum jemand denkt face-smile Ich sprech da aus erfahrung. Die Gesichter werden dann immer lang wenn ich sage das wir dann aber 5 Lizenzen brauchen .....