Datenbanken auf dediziertem Server??

  • Bei den meisten vServern dürfte der größte RAM-Fresser das Datenbanksystem seien. Also warum nicht alle Datenbanken auf einen (oder mehrere) physische Server auslagern?
    Ein DB-Nutzer, der alle Rechte an seinen DBs hat, reicht bei 99% aller Anwendungen aus. Unterschiedliche Konfigurationen - wie bspw. bei Apache - gibt es nicht; es muss natürlich für den Betrieb vieler Datenbanken optimiert werden.


    So ein "Datenbank-Paket" stelle ich mir analog zu dem Backupspace-Angebot vor. Für einen monatlichen Obolus kann man es zu seinem vServer hinzubuchen; eventuell gestaffelt nach Anzahl User/DBs und Speicherplatz. Zur Auswahl sollten dabei MySQL und PostgreSQL stehen.


    Vielleicht konnte ich ja eine kleine Anregung geben... ;)

    "EDV-Systeme verarbeiten, womit sie gefüttert werden. Kommt Mist rein, kommt Mist raus." - André Kostolany

  • Klingt natürlich interessant um die vServer zu entlasten, allerdings sieht man an T-Online und 1&1 das selbst große Konzerne es nicht auf die Reihe bekommen saubere SQL Cluster zu erstellen.


    Man müsste zum einen dafür eine Farm einrichten und 1-2 Leute haben die sich permanent nur darum kümmern.

  • Muss ja keine Cluster-Lösung sein. :)


    Auf Arbeit haben wir einen Sparc-Server auf dem ~50 MySQL-Datenbanken hauptsächlich für Webanwendungen (CMS, Blogs, etc.) laufen. Nach ein bisschen Stellen an den Caches läuft er performant.


    Netcup müsste halt schauen, wieviel User/Datenbanken eine Maschine verkraften kann und ob sich solche Server dann profitabel betreiben lassen.

    "EDV-Systeme verarbeiten, womit sie gefüttert werden. Kommt Mist rein, kommt Mist raus." - André Kostolany

  • Ich find die Idee super, würde die vServer deutlich entlasten & man hätte mehr Kapaiztäten frei. Das Ganze würde netcup auch deutlich von den anderen Anbietern unterscheiden... ;-)

  • Schön wäre es natürlich, aber ich denke das der Preis der entsteht, aufgrund des Aufwandes etc. dann für die meisten doch zu hoch ist.


    Ein Cluster müsste es aber in jedem Fall werden, sonst hätte man einen Seidenen Faden geschaffen, der zig seiten blockieren kann.


    Ich denke es müssten mindestens 3 Maschinen sein und sowas kostet natürlich und nicht nur Geld. Der Betreiber muss eine menge Zeit allein schon in die Einrichtung des Systems stecken, von der Wöchentlichen Pflege einmal abgesehen.


    Außerdem entsteht dadurch natürlich auch ein gewisses Risiko, da der externe Zugriff möglich ist.


    Natürlich auch bei jedem einzelnen, aber wenn zum Beispiel der root gehackt wird, wirds garantiert lustig.


    Der nächste Punkt wäre die Leistung pro Kunde Rechnung.


    So wie es jetzt ist, ist schön, volle Kontrolle über alles, keine Einschränkungen, läuft.


    Ich würde mir keine DB hohlen.


    MfG
    Newbi

  • Für den Betreiber eines vServers mag es sicher interessant sein wenn er seine Datenbank auslagern könnte. Allerdings darf nicht vergessen werden, dass dabei nur die Last verschoben wird. Verringert wird sie dabei nicht. Hinzu kommt noch der Engpass "Netzwerk". Ein separater Datenbankserver sollte maximal in einem "geswitchten" Netz stehen.


    Das große Manko ist an der Sache die Kontrolle der Ressourcen. Es kann nur sehr schwer verhindert werden das ein User den ganzen Datenbankserver für sich beansprucht, zumindest wenn der externe Server MySQL anbieten soll.


    Zum Vergleich: Bei einem vServer kann ein Kunde die Ressourcen buchen die er braucht. Bei einem Webhostingpaket, einer sog. "shared"-Lösung, können wir durch die Kontrolle von PHP / Perl die Zugriffe eines jeden Kunden auf die Datenbank kontrollieren. Das ist z.B. auch der Grund dafür warum nur bei großen Webhostingpaketen externer MySQL-Zugriff möglich ist. Bei der hier angefragten Lösung ist eine Kontrolle der Lastverteilung nur schwer möglich.


    Mein Lösungsvorschlag wäre einen zweiten vServer zu buchen auf dem dann die Datenbank arbeitet. Gerne können wir darauf achten und den zweiten vServer auf anderer Hardware aber im selben Netz bereit zu stellen.


    Meistens reicht es aber auch aus einfach die Ressourcen des vServers zu erhöhen.

  • Wenn schon Cluster Lösungen, dann lohnt sich soetwas eigentlich erst wirklich, wenn die ganze Website als Cluster betrieben wird. Denn nur die Datenbank auszulagern würde bei wirklich großen Websites auch nichts bringen, da bricht dann halt PHP oder Perl zusammen, je nachdem was man verwendet, da nützt der beste eAccelerator auch nichts mehr. Und das angesprochene Ressourcen Problem würde einem eigentlich auf den Stand eines Shared Webhosting Pakets zurückwerfen, was sicher die wenigsten freuen würde.


    [netcup] Felix;2206 wrote:


    Mein Lösungsvorschlag wäre einen zweiten vServer zu buchen auf dem dann die Datenbank arbeitet. Gerne können wir darauf achten und den zweiten vServer auf anderer Hardware aber im selben Netz bereit zu stellen.


    Das wäre bestimmt besser, einfacher und günstiger. Wie bereits mein Vorposter geschrieben hatte: Ich würde mir auch keine solche DB Lösung nehmen, lieber gleich einen stärkeren oder zweiten vServer - da hätte ich wenigstens weiterhin alle Freiheiten und kann mich austoben :D



    MfG Christian

  • killerbees19 wrote:

    Wenn schon Cluster Lösungen, dann lohnt sich soetwas eigentlich erst wirklich, wenn die ganze Website als Cluster betrieben wird. ...


    Bei richtig großen Sites und/oder vielen Zugriffen kommt man um mehrere dedizierte Server und Loadbalancer nicht herum. Bei einer solchen Cluster-Lösung würde ich VServer allemal als Cold-Standby-Server einsetzen; was natürlich eine hochverfügbare SAN-Lösung voraussetzt.
    Die Idee/der Vorschlag war auch eher N VServer-Hosts einen DB-Server im gleichen Netzsegment zur Seite zu stellen.


    Aber meine Intention war, wie auch Felix schrieb, die Last des DB-Servers vom eigenen VServer zu verlagern.
    Das MySQL - wie richtige DBMSe :rolleyes: - keine CPU/IO-Begrenzung pro Benutzer/Datenbank/Session ermöglicht, ist das(!) Problem. Da könnten einige Transaktionen dann verhungern...


    [netcup wrote:

    Felix]Mein Lösungsvorschlag wäre einen zweiten vServer zu buchen auf dem dann die Datenbank arbeitet. Gerne können wir darauf achten und den zweiten vServer auf anderer Hardware aber im selben Netz bereit zu stellen.


    Das ist natürlich der Königsweg. Obwohl dann rechnerisch ein größerer VServer wahrscheinlich besser wäre.
    Aber schreibt diese Möglichkeit - als Alleinstellungsmerkmal - ruhig auf eure Website. Bspw. ein großer Hoster mit H ist nicht im Stande zu gewährleisten, dass zwei VServer auch auf verschiedenen Hosts liegen; egal ob aus Performance- oder Verfügbarkeitsgründen.


    Gruß
    Filewalker

    "EDV-Systeme verarbeiten, womit sie gefüttert werden. Kommt Mist rein, kommt Mist raus." - André Kostolany