Datenbankserver lokal oder auf 2. Server?

  • Hi, ich bräuchte mal ein paar Tipps zum folgenden Thema:
    Ich miete derzeit 2 x RS 2000 SSD G8 a1 12M.

    Der eine Server ist ein Windows Server mit einer MS SQL Datenbank.

    Der 2. Server dient als (CentOS 7.7) Web-, Datenbank-, und Teamspeakserver.


    Den MS SQL Server würde ich gerne so lassen, da ich nichts zu beanstanden habe.


    Den Web/DB/TS-Server würde ich gerne etwas umstrukturieren.


    In diesem Zusammenhang 3 Fragen:
    1. Habt ihr eure Datenbanken auf dem Webserver (also lokal), oder auf einem 2. Server ?

    2. Warum habt ihr euch dafür entschieden?

    3. Welches OS nutzt ihr für euren DB-Server?


    Ich würde den Datenbank- und den TS-Server gerne auf einen separaten Server packen.

    Es geht in erster Linie nicht um die Leistung o. ä. Diese sollte natürlich durch die Umstrukturierung nicht abnehmen.


    Bspw. möchte ich derzeit von CentOS 7.7 auf 8 umsteigen. Wäre mein Webserver von den übrigen getrennt, könnte ich nur diesen Updaten und den Rest so belassen, da mein Datenbank- und TS-Server nicht unbedingt auf CentOS 8 laufen müssen.


    EDIT: vielleicht noch zur Erklärung: ein Update von CentOS 7.7 auf 8 gibt es nicht. Das bedeutet ich muss das OS neu installieren. Kommt mir gelegen, da ich das centos web panel loswerden möchte.

  • Ich würde das hauptsächlich von der Last auf dem Server bzw. der Größe der Datenbank abhängig machen, da man im Hintergrund auch immer ein wenig die Kosten berücksichtigen muss. Hast du hierzu ein paar Daten? Aber prinzipiell ist die Trennung von Datenbank und Webserver eine gute Idee. Dank dem kostenlosen Cloud VLAN bei Netcup kann man den Zugriff auch prima schützen. Vorher musste man da SSL Zertifiakte verwenden, was nicht immer einfach gewesen war bzw. ist( killerbees19 hat da auch ein paar nette Geschichten zu erzählen, wenn ich mich richtig erinnere).


    Bei mir laufen die meisten Datenbanken mittlerweile als Container. Das hat vor allem die ganze Update Geschichte stark verändert und vereinfacht. Bei einigen kleinen Projekten läuft die Datenbank aber weiterhin mit auf dem gleichen Server. Hier spielt die DB Version im Grunde keine Rolle und die Zugriffe auf die DB sind recht überschaubar. Hier würde sich ein separater DB Server überhaupt nicht lohnen. Es kommt also immer etwas darauf an.

  • Die Datenbankgrößen in MB: 0.45444775, 1.01562500, 3.51562500, 3.84199810, 4.82812500, 4.88529301, 5.78125000, 6.31250000, 7.06389046, 10.21206188, 13.34994888, 16.79687500


    Bezüglicher der Last habe ich mich nie darum gekümmert, da ich bisher zufrieden gewesen bin. Welche Daten sind hier relevant? Aus dem SCP oder anderweitig?

  • Auf Grund dessen, was hier in den letzten Monaten so zum Thema TS-Server zu lesen war - nicht aus eigener Erfahrung - würde ich keinen Gedanken daran verschwenden, einen TS-Server gemeinsam mit irgend etwas produktivem auf den selben Server zu stecken. Zumindest wenn es dabei um irgendwelche Spiele geht ;). Irgendwie scheinen TS-Server DDOS-Attacken magisch anzuziehen. Das muss ich für meine Datenbanken oder Websites dann nicht haben. Zumal, wenn der Datenbankserver dann dank TS-Server darnieder liegt, ist der Webserver ja praktisch auch tot.


    Ansonsten bin ich bei Paul, it depends ...

  • https://en.wikipedia.org/wiki/Unix_domain_socket

    <-- ist ca. 30 mal schneller als das Loopback Device, deswegen laufen alle Application und Datenbankdienste zusammen, es sei denn man muss clustern.

    Aber selbst da läuft die Replik auf dem Applicationserver, mindestens aber der Router zum Cluster sollte da lokal laufen.


    MSSQL läuft ja mittlerweile auch auf Linux.

    Für MongoDB, MariaDB und Postgres verwende ich eigentlich immer entweder Debian, Alpine oder CentOS.


    Dank dem kostenlosen Cloud VLAN bei Netcup kann man den Zugriff auch prima schützen. Vorher musste man da SSL Zertifiakte verwenden

    Man verwendet das VLAN auch nicht dazu, um TLS auf offener Strecke abzulösen.

    Um vor Zugriffen zu schützen, gibt es iptables - und auf TLS sollte man auch im VLAN nicht verzichten.

    Es kann dir keiner garantieren, dass da nicht mal Pakete woanders lang huschen. Da reicht es bereits einen Server von dir zu übernehmen und ganz frech auf ARP Requests zu reagieren, und schon bekomme ich eine Kopie deiner Pakete, die du ja jetzt nicht mehr verschlüsselst.


    ( killerbees19 hat da auch ein paar nette Geschichten zu erzählen, wenn ich mich richtig erinnere).

    Die kann dir nicht nur killerbees19 erzählen. Diese ganze YaSSL Geschichte ist einfach nur zum Hände über den Kopf schlagen.

  • Den Hinweis bezüglich des TS Servers habe ich registriert und werde den dann auf einen VPS o. ä. packen, was am günstigsten ist.

    MSSQL wird für JTL verwendet. JTL hat einen sogen. Worker und dieser läuft nur unter Windows.


    Also zusammengefasst: Datenbank lokal hosten und erst wenn Clustering infrage kommt, muss man einen 2.,3... Server verwenden?

  • Die Datenbankgrößen in MB: 0.45444775, 1.01562500, 3.51562500, 3.84199810, 4.82812500, 4.88529301, 5.78125000, 6.31250000, 7.06389046, 10.21206188, 13.34994888, 16.79687500

    Also bei solchen Daten lohnt es sich überhaupt nicht, die Datenbank auszulagern. Lass sie ruhig mit auf dem Server laufen (vorausgesetzt, die Applikation läuft mit der neueren MariaDB Version, die mit CentOS8 mitkommt) - aber selbst in diesem Fall sollte man eher die Applikation aktualisieren :-)


    https://en.wikipedia.org/wiki/Unix_domain_socket

    <-- ist ca. 30 mal schneller als das Loopback Device, deswegen laufen alle Application und Datenbankdienste zusammen, es sei denn man muss clustern.

    Aber selbst da läuft die Replik auf dem Applicationserver, mindestens aber der Router zum Cluster sollte da lokal laufen.

    Zumindest theoretisch. In der Praxis merkt man diesen Unterschied allerdings kaum.


    Man verwendet das VLAN auch nicht dazu, um TLS auf offener Strecke abzulösen.

    Um vor Zugriffen zu schützen, gibt es iptables - und auf TLS sollte man auch im VLAN nicht verzichten.

    Es kann dir keiner garantieren, dass da nicht mal Pakete woanders lang huschen. Da reicht es bereits einen Server von dir zu übernehmen und ganz frech auf ARP Requests zu reagieren, und schon bekomme ich eine Kopie deiner Pakete, die du ja jetzt nicht mehr verschlüsselst.


    Die kann dir nicht nur killerbees19 erzählen. Diese ganze YaSSL Geschichte ist einfach nur zum Hände über den Kopf schlagen.

    Es macht schon einen Unterschied, ob die Zugriffe über das VLAN laufen oder über die Public IPs. Ich halte es durchaus für eine gute Alternative (anstatt Public IP + SSL), gerade weil du ja auch schon richtig angedeutet hast, dass SSL Implementationen oft nicht ganz so super umgesetzt wurden (jetzt konkret für diesen Fall gesprochen, ich möchte hier nicht generell SSL schlecht reden).

    Wenn wir jetzt aber bei dem Beispiel des TE bleiben, dann hat er sowieso verloren, wenn einer der Server übernommen wurde. Wurde der Webserver übernommen, hat der Angreifer Zugriff auf die DB (dank der Credentials, die ja irgendwo auf dem Webserver zu finden sind), hat er Zugriff auf den DB Server, hat er den Zugriff ebenfalls. Recht hast du natürlich, wenn unzählige Server in dem VLAN laufen, die eigentlich sonst nichts miteinander zu tun haben. Das ist dann aber wieder eine andere Geschichte.

  • Leistung, große Datenbanken die ausgelagert werden müssen, oder die Kosten sind mehr oder weniger irrelevant, solange sich alles in Grenzen hält.


    Ich wollte eher wissen, ob jemand von euch einen extra Datenbank-Server betreibt und wieso er das für sich so entschieden hat.


    Ich habe bspw. gesehen, dass jemand in einem Thread geschrieben hatte, dass er 3 x RS 2000 fürs MariaDB clustering verwendet. Da wüsste ich gerne, was ihn bspw. angeregt hat clustering zu verwenden.


    Edit: mal ne Frage zur "Übernahme" eines Servers: Wenn ich den externen Root Zugriff ausschalte und lediglich user anlege, die auf bestimmte Verzeichnisse Zugriff haben, ist dann euer Übernahme-Szenario nach wie vor möglich? Keiner hat root rechte, ich würde root quasi lokal über die SCP Konsole verwenden.

  • Edit: mal ne Frage zur "Übernahme" eines Servers: Wenn ich den externen Root Zugriff ausschalte und lediglich user anlege, die auf bestimmte Verzeichnisse Zugriff haben, ist dann euer Übernahme-Szenario nach wie vor möglich? Keiner hat root rechte, ich würde root quasi lokal über die SCP Konsole verwenden.

    Natürlich! Schwachstellen kann es immer geben, siehe nur z.B. die aktuelle exim-Problematik

    ChestSort: Automatische Kistensortierung in Minecraft - www.chestsort.de


    www.raucher-werden.de - www.serioese-alternative.de - www.jeff-media.de

  • Da wüsste ich gerne, was ihn bspw. angeregt hat clustering zu verwenden.

    Ein Clusterbetrieb von Datenbanken hat meistens zwei Ursachen:


    1. Ich möchte die Verfügbarkeit erhöhen und keinen Single Point of Failure. Wenn ein Server ausfällt soll ein zweiter meine Leseanfragen und ggf. Schreibanfragen bearbeiten.


    2. Lastverteilung - ich habe so viele Leseanfragen, dass ein Server dadurch ins Schwitzen kommt. Ich möchte diese Leseanfragen auf mehrere Server verteilen.


    Und dann gibt es noch (Geo)sharding, was idR aber nur bei stark beanspruchten Enterprise Lösungen verwendet wird (z.B. die Spotify Server Software)



    Es macht schon einen Unterschied, ob die Zugriffe über das VLAN laufen oder über die Public IPs. Ich halte es durchaus für eine gute Alternative (anstatt Public IP + SSL)

    Du verkennst, dass VXLANs auch nur Datenpakete auf den Switches im Netcup Rechenzentrum sind, genau wie Datenverkehr über die öffentlichen IP Adressen zwischen zwei Netcup Servern.


    Wenn jemand Datenpakete zwischen öffentlichen IP Adressen sniffen kann, kann er das auch mit dem Verkehr auf den VLANs. Das führt dein TLS Verzicht ad absurdum.

  • Ich wollte eher wissen, ob jemand von euch einen extra Datenbank-Server betreibt und wieso er das für sich so entschieden hat.

    Etwas ähnliches spiel ich grad durch. Zwar nicht mit Datenbanken, aber mit anderen Diensten. So wie in deinem Fall sind die leistungstechnischen und finanziellen Aspekte vernachlässigbar. Ich teil meine Dienste zurzeit schlicht und einfach deswegen auf mehrere getrennte Systeme auf, weil meine Anwendungen ein klassischer Fall von #homelab sind, und da experimentiert man doch dann und wann mal herum. Da tauscht man mal einen einzelnen Dienst aus. In deinem Fall wirst du vielleicht mal versuchen den Kumpels Mumble/Murmur schmackhaft zu machen statt TS, oder man macht einen gröberen Versionssprung bei einem Dienst oder sonstiger Software, die eine aufwändige Baustelle aufmacht. Und da es mittlerweile die technischen Mittel zulassen, viele einzelne kleine Server leistbar zu betreiben (kann man da auch von Microservices sprechen?), seh ich keinen Grund mehr, wie vor zwanzig Jahren einen einzigen Server bis auf Anschlag mit Diensten zuzustopfen wie einen Reisekoffer von Kim Kardashian. Ich will nicht mehr nachdenken, wen aus der Familie, Verwandschaft oder Freundschaft ich noch belästige, wenn ich Dienst X für einen Tag in den dreckigen binären Abgrund reiß, nur weil ich Server X nach /dev/null beförder um irgendwas umzustellen oder auszuprobieren.


    Der Sicherheitsaspekt ist wahrscheinlich in deinem Fall auch vernachlässigbar. Datenbankserver, ich nehm an es geht hier am Webserver um MySQL, ist üblicherweise das geringste Problem. Die pure Anwesenheit einer Wordpress Instanz stellt jegliche Sicherheitsbedenken in Sachen Datenbanken in den Hintergrund, und mit anderen gängigen Webframeworks verhält es sich ähnlich. Nicht die Datenbank ist die Schwachstelle, sondern das was im Webroot liegt. Und wenn das was im Webroot liegt angegriffen wird, ist auch die Datenbank potentiell dahin, egal wo sie liegt - weil das Zeug im Webroot üblicherweise alle Zugangsdaten zur Datenbank in Plaintext und gut sichtbar präsentiert. In 15 Jahren als hauptberuflicher Web Entwickler hab ichs übrigens kein einziges mal erlebt, dass eine Datenbank was abbekommen hat. Lohnt sich auch nicht, das einzig interessante an Datenbanken, Personendatensätze, gibts für weniger Risiko und weniger Aufwand selbst bei legalen Adresshändlern um etwa 12 Cent pro Stück.


    Ich kenn natürlich deine Dienste und Websites nicht, ich würd aber bei den genannten Datenbankgrößen tippen, dass du den Webserver mitsamt Datenbank leistungstechnisch auf einem VPS200, und den TS Server auch auf einem eigenen VPS200 unterbringen kannst, ohne in der Praxis Geschwindigkeitsnachteile zu bemerken. Ob die 20GB reichen, kommt natürlich auf die Menge an Daten in den Files an. Du hast bei den VPS aber im Gegensatz zu den RS den Vorteil, die Dinger stundenweise kündigen und austauschen zu können, falls es mal mehr braucht.

  • ein Update von CentOS 7.7 auf 8 gibt es nicht

    hm, bin ich mir nicht sicher - zumindest bei RHEL gibts einen Upgradepfad von 7.7 auf 8. Allerdings bei ein paar Einschränkungen und on eine Neuinstallation nicht sauberer ist, lass ich mal im Raum stehen ;-) Wenns da geht, sollte es auch bei Centos gehen, sofern dort auch leapp zur Verfügung steht (https://www.tecmint.com/upgrade-from-rhel-7-to-rhel-8/).

    Gruss,

  • Habt ihr eure Datenbanken auf dem Webserver (also lokal), oder auf einem 2. Server ?


    Wenn es nicht lokal läuft, dann muss auf einmal alles übers Netzwerk. Da kann es schnell mal Probleme mit der Bandbreite geben und mit Latenzen, die sich summieren weil es ja meistens nicht bei der 1 DB-Abfrage bleibt. Ein 2. Server bringt keinen Geschwindigkeitsvorteil sondern erstmal nur Nachteile. Das lohnt sich nur wenn die Anwendung drauf optimiert ist oder anderweitig so stark profitiert daß die Nachteile ausgeglichen werden.

  • ...

    Ich kenn natürlich deine Dienste und Websites nicht, ich würd aber bei den genannten Datenbankgrößen tippen, dass du den Webserver mitsamt Datenbank leistungstechnisch auf einem VPS200, und den TS Server auch auf einem eigenen VPS200 unterbringen kannst, ohne in der Praxis Geschwindigkeitsnachteile zu bemerken. Ob die 20GB reichen, kommt natürlich auf die Menge an Daten in den Files an. Du hast bei den VPS aber im Gegensatz zu den RS den Vorteil, die Dinger stundenweise kündigen und austauschen zu können, falls es mal mehr braucht.

    Das hört sich interessant an und werde ich so mal umsetzen.


    Ich hoste lediglich ein paar Wordpress Seiten und 4 Onlineshops. Die Shops haben jeweils um die 500 Artikel, also befinden sich im unteren Bereich.

    Das Thema mit dem Server "mal eben neustarten" ist auch ab und an mal ein Problem und einer der Gründe, wieso ich gerne alles etwas aufteilen würde.


    Eine Frage zum VPS200: der vServer hat "2GB RAM". Momentan sind laut meines Verwaltungstools derzeit 3-6 GB bereits in Verwendung. Demnach würde ich mit 2 GB nicht hinkommen, oder wie läuft das ab?


    Ich hatte mich damals bewusst für eine Nummer größer entschieden (RS 2000) - punkto RAM und CPU - um eben diese beiden Punkte als bottleneck ausschließen zu können. Natürlich muss das System erst optimiert werden, aber so hatte ich schon mal die Grundvoraussetzungen.

  • Momentan sind laut meines Verwaltungstools derzeit 3-6 GB bereits in Verwendung. Demnach würde ich mit 2 GB nicht hinkommen, oder wie läuft das ab?

    Was genau braucht denn wieviel RAM? So pauschal verwendet jedes Betriebssystem der letzten Jahre alles was möglich ist Cache.

  • Code
    1. # free -m
    2. total used free shared buff/cache available
    3. Mem: 15884 1292 9836 169 4756 14012
    4. Swap: 6143 0 6143


    Welcher Wert ist ausschlaggebend?


  • und das 4,7 GiB für buff/cache reserviert sind, ist egal?

    Was ist wenn ich 1,3 GiB benötige und 2 GiB Ram habe, wird das Betriebssystem automatisch buff/cache auf die Festplatte schreiben?

  • und das 4,7 GiB für buff/cache reserviert sind, ist egal?

    Was ist wenn ich 1,3 GiB benötige und 2 GiB Ram habe, wird das Betriebssystem automatisch buff/cache auf die Festplatte schreiben?

    Nein, das läuft andersrum: wenn du genug RAM frei hast, werden oft benutzte Teile des Dateisystems in den RAM geladen. Wenn nicht, dann eben nicht.

    ChestSort: Automatische Kistensortierung in Minecraft - www.chestsort.de


    www.raucher-werden.de - www.serioese-alternative.de - www.jeff-media.de

  • wird das Betriebssystem automatisch buff/cache auf die Festplatte schreiben?

    Jede offene Datei in Linux geht durch den RAM. D.h. wenn du eigentlich auf die Festplatte schreibst, schreibst du in Wirklichkeit in den RAM, bis fflush sync oder fclose vorbei kommen. Diese Bereiche werden im buff/cache abgespeichert.


    Bei einer 20 GiB großen SSD, sind 25% Cache schon ein bisschen overkill. Linux nimmt sich hier immer das, was keiner sonst braucht.