Dedicated Server vs. Cloud (Datenbankabfragen)

Hallo,

ich habe mir bereits zahlreiche Gegenüberstellungen durchgelesen was das Thema Dedicated Server vs. Cloud angeht. Allerdings hat mich die Aussage eines Hosting-Providers zum Thema Performance etwas verwundert:

Ein "Cloud-Server" mit 4 vCores (Xeons), 8 GB RAM, 2x160 GB SSD (Raid) soll angeblich performanter als ein Dedicated Server mit 4 Cores (Xeons), 32 GB RAM, 2x256 GB SSD (Raid). Beide kosten ungefähr gleich viel.

CloudServer: 1und1, Cloud Server XXL


-------
DedicatedServer: Server4You Blueline mit 2x250GB SSD (https://www.server4you.de/dedicated-server)


Stimmt diese Aussage in Bezug auf folgende Ausgangssituation:
Website auf Basis des Zend Framework 2 mit einer 21 GB großen MySQL Datenbank.

Mein Bauchgefühl sagt mir, dass die Webanwendung auf dem Dedicated Server viel schneller laufen müsste, da z. B. die Datenbank ja komplett ins RAM passt.

Was meint ihr dazu? Ist RAM in der Cloud zu vernachlässigen für solch große Datenbanken?

Momentan läuft die Anwendung auf einem älteren Athlon System mit 16 GB RAM und konventionellen HDDs. Durchschnittlicher Seitenaufruf: 450ms

Was wäre in meinem Fall geeigneter?

Grüße mfuesslin

Bei Datenbank kommt es nicht auf RAM und Vcores etc darauf an, sondern wie die Disk Performen. Also die IOPS! Natürlich ist Ram auch wichtig für eine DB aber die Daten werden auf der Disk gelesen und geschrieben.

Der Vergleich von dir ist nicht Vollständig gibt es dazu noch mehr Informationen? Raid 0 oder Raid 1 und vorallem wie hoch ist die IOPS?

/e: Nur als Beispiel: Um die besste Performance bei einem DB Server (in deinem Fall zu vernachlässigen) wird in grösseren umgebungen auch die Block Size der Disk angepasst, so das diese optimiert ist für die gewünschte DB.

Zum Ram eine DB ist nie vollständig im RAM, da wenn der Server die Stromzufuhr verliert, sind alle Daten, welche nicht auf die Disk geschrieben wurden, weg.

Ram auch wichtig für eine DB aber die Daten werden auf der Disk gelesen und geschrieben.

Zum Vergrößern anklicken....

Wenn die Daten alle ins RAM geladen sind? Spätestens dem OS ist das völlig egal. Das OS schreibt die auf die Platte wenn es Lust hat oder keine. Da müsste das RDBMS schon die ganze Platte selbst verwalten. Was es nicht tut weil MySQL.

Alle, wirklich ALLE Anfragen werden aus dem RAM bedient werden wenn es groß genug ist, selbst wenn MySQL meint es müsste von der Platte laden weil es schlecht programmiert ist bzw. Oracle seinen anderen Produkten keine Konkurrenz machen will.

Ein dedizierter Server mit v-Cores? Das klingt eher nach einer virtuellen Maschine wo sich auf der selben Hardware X VM-Instanzen um die Hardware streiten. Genauso wie der "Cloud-Server" sehr danach klingt eine 0815 virtuelle Kiste zu sein.
Wobei ich ja unter "dediziertem Server" verstehen würde, dass ist reale Hardware wirklich exklusiv bereitsteht.

Das unspezifische Bullshitbingo... Ähm Buzzword "Cloud" ändert nichts an den Anforderungen einer Datenbank. Die heißen (häufig verwendeten) Daten will man im CPU Cache haben, wenn das nicht geht will man diese Daten im Ram haben und möglichst nur Festspeicherzugriffe wenn es darum geht Daten zu schreiben.

Was den langsamen Seitenaufruf auf der aktuellen Hardware angeht. da wäre es angebracht mal zu schauen wie es um die Auslastung von Festspeicher, CPU, Ram steht und was der Webserver / die Datenbank zu ihrer Auslastung zu sagen haben.

Kenny [CH] schrieb:

Bei Datenbank kommt es nicht auf RAM und Vcores etc darauf an, sondern wie die Disk Performen. Also die IOPS! Natürlich ist Ram auch wichtig für eine DB aber die Daten werden auf der Disk gelesen und geschrieben.

Der Vergleich von dir ist nicht Vollständig gibt es dazu noch mehr Informationen? Raid 0 oder Raid 1 und vorallem wie hoch ist die IOPS?

/e: Nur als Beispiel: Um die besste Performance bei einem DB Server (in deinem Fall zu vernachlässigen) wird in grösseren umgebungen auch die Block Size der Disk angepasst, so das diese optimiert ist für die gewünschte DB.

Zum Ram eine DB ist nie vollständig im RAM, da wenn der Server die Stromzufuhr verliert, sind alle Daten, welche nicht auf die Disk geschrieben wurden, weg.

Zum Vergrößern anklicken....

Habe gerade recherchiert, und folgende Studie gefunden, die die Performance auf dem CloudServer (1und1) untersucht hat:
https://blog.1und1.de/blog-de/wp-co...opean-Cloud-Service-Provider_Report_final.pdf

Die Studie hat 2 Messungen durchgeführt:
Messung 1 ("large file size with a small block size", vgl. S. 15):
IOPS Median Sequenziell: 1008
IOPS Median Random: 1058

Messung 2 ("small file size with a large block size", vgl. S. 15):
IOPS Median Sequenziell: 1769
IOPS Median Random: 1746

Für den Dedicated Server konnte ich nur eine ungenaue Angabe finden "bis zu 100.000 IOPS". Wobei jedem klar sein dürfte das man das wohl wahrscheinlich getrost halbieren kann (wie bei den DSL Geschwindigkeiten die mit bis zu werben)...

Kurz und knapp: Ram wichtig keine Frage. Disk für DB System ist wichtiger.
Anfragen werden natürlich mit der Ram verarbeitet und dann auf die Disk geschrieben. Das File auf der Disk ist der Master!
Das DBMS (Datenbank Management System) verwalltet nicht die Harddisk/SSD selbst sonder das DB File (also das .frm und das .ibd File)
Bei MSSQL wären das die .mdf, .ndf und .ldf Files

@Piktogramm Ich habe nachgeschaut der TE hatte einen Fehler der dedicated Server hat keine VCores

Piktogramm schrieb:

Ein dedizierter Server mit v-Cores? Das klingt eher nach einer virtuellen Maschine wo sich auf der selben Hardware X VM-Instanzen um die Hardware streiten. Genauso wie der "Cloud-Server" sehr danach klingt eine 0815 virtuelle Kiste zu sein.
Wobei ich ja unter "dediziertem Server" verstehen würde, dass ist reale Hardware wirklich exklusiv bereitsteht.

Das unspezifische Bullshitbingo... Ähm Buzzword "Cloud" ändert nichts an den Anforderungen einer Datenbank. Die heißen (häufig verwendeten) Daten will man im CPU Cache haben, wenn das nicht geht will man diese Daten im Ram haben und möglichst nur Festspeicherzugriffe wenn es darum geht Daten zu schreiben.

Was den langsamen Seitenaufruf auf der aktuellen Hardware angeht. da wäre es angebracht mal zu schauen wie es um die Auslastung von Festspeicher, CPU, Ram steht und was der Webserver / die Datenbank zu ihrer Auslastung zu sagen haben.

Zum Vergrößern anklicken....

Hatte mich vertippt! Der dedicated Server hat 4 echte Xeon Cores, das "v" ist mir ausversehen hineingerutscht. Habe den 1. Beitrag editiert und Informationen um welche Hoster / Pakete es geht eingefügt.

Ein Datenbankserver sollte immer so viel RAM haben, dass alle regelmäßig verwendeten Daten im RAM gehalten werden können, sonst wird das extrem zäh.

Was I/O Zugriffe angeht, so sind diese nur notwendig, wenn Daten geschrieben werden, was in der Regel deutlich weniger oft vorkommt als Lesezugriffe.
Wenn SSDs verwendet werden, dann haben diese auf jeden Fall mwhr als genug Performance um alle deine Schreibzugriffe abzudecken ob im RAID oder nicht.

Ich muss aber sagen, dass hier viele Fragen offen bleiben:
1.) Welche Netzwerkanbindung
2.) CPU Typ, Taktrate und Cache
3.) Geteilt mit anderen oder nicht?
4.) Welcher RAID Controller (RAID Controller müssen zwingend batteriegestützt sein)

Aus dem Bauch heraus würde ich eher sagen dein Provider will dir was einreden, damit er aus Kostengründen virtualisieren kann.

Nur mal so: So sieht es bei Azure Cloud aus und wie du hier sehen kanst werden einige Informationen mehr angegeben als bei 1&1. Auch die IOPS der Disk. 1&1 gibt dir darüber aber keine Informationen, nur CPU RAM und Disk, was im Serverbereich nicht immer ausreichend ist. Wenn du die möglichkeit hast, würde ich andere Hoster anschauen, evtl findest du da ein besseres Angebot.

Wir setzten in der Firma als Beispiel nur Azure Cloud als Hoster ein und haben fast alle Server dahin gezügelt.

@TE was wird mit der Webseite gemacht? 21GB grosse DB deutet für mich auf ein System hin, was z.B. ein Forum oder Webshop beinhalten könnte.

Unabhängig von den beiden Lösungen die du in den Raum gestellt hast.

Wie wäre es sich gar keine großen Gedanken um die DB zu machen und einen MySQL DB Service zu nehmen, wie z.B. bei AWS.
Siehe: https://aws.amazon.com/rds/mysql/

Dazu müsste dann noch ein WebServer (EC2) in gewünschter Größe dazu genommen werden.

Solch Kombi ist Wartungsfreier, erleichtert Administration und die Performance ist durchaus gut.

Eine Datenbank die vollständig ins RAM passt ist beim Lesen viel, viel schneller als eine Datenbank die zu groß fürs RAM ist. Wenn es möglich ist, würde ich immer versuchen genug RAM für die gesamte DB im Server zu haben.

Beim Schreiben sind die IOPS der Festplatte/SSD entscheidend. In einer vernünftigen Datenbank die nicht im Kamikaze-Modus arbeitet, muss für jeden Schreibvorgang auf die Platte geschrieben werden. Was nur im RAM ist, wäre bei einem Absturz weg. Das kann man bei vielen Datenanken auch anders einstellen, aber dann kann es sein das die letzten Schreibvorgänge verloren gehen wenn der Server abschmiert, oder noch schlimmer das die Datenbank korrupt wird.

In der Cloud sind die Platten häufig nicht lokal, sondern übers Netzwerk. Das ist grundsätzlich langsamer, aber auch viel flexibler da Du einfach mehr Platten in die virtuellen Server einbinden kannst. Irgendwo in der Dokumentation ist meistens versteckt wie viele IOPS man bekommt.

Bei dedicated Server hat man einfach eine lokale Platte, das kann schnell oder langsam sein. HDD ist langsam, SSD ist gut, und man bekommt durchaus auch NVMe-SSD, die dann richtig schnell sind.

Generell sind dedicated Server bei gleicher Leistung viel billiger als AWS & Co. Wenn ich AWS und Hetzner vergleiche ist das so ein Faktor 5-10x. Ist aber auch kein fairer Vergleich da AWS ungleich flexibler ist und viele andere Vorteile bietet. Wenn man diese Flexibilität nicht braucht, zahlt man da aber auch anständig drauf im Vergleich zum dedicated Server.

Als Vergleich mal einen Hetzner dedicated server:

https://www.hetzner.de/dedicated-rootserver/px61-nvme


Ist mit 70 EUR etwas teuerer, aber 64GB RAM und 2x 512 GB NVMe SSDs, die gerade bei Datenbanken für anständig Performance sorgen sollten.

kaikuwe schrieb:

Unabhängig von den beiden Lösungen die du in den Raum gestellt hast.

Wie wäre es sich gar keine großen Gedanken um die DB zu machen und einen MySQL DB Service zu nehmen, wie z.B. bei AWS.
Siehe: https://aws.amazon.com/rds/mysql/

Dazu müsste dann noch ein WebServer (EC2) in gewünschter Größe dazu genommen werden.

Solch Kombi ist Wartungsfreier, erleichtert Administration und die Performance ist durchaus gut.

Zum Vergrößern anklicken....

Was würdet ihr denn Preisleistungstechnisch vorschlagen: AWS ist ziemlich teuer, wenn man ein Kontingent buchen will, das genug RAM hat, um die komplette Datenbank aufzunehmen (nicht für in-memory, sondern für die innodb_buffer_pool_size).
Das Angebot von Server4You ist eigentlich ziemlich gut: 32GB RAM sind genug für die DB und WebServer sollte auch noch parallel gehen.

AWS (db.r3.xlarge, 30 GB RAM): 0,475*31*24 = 353 € / Monat
AWS (db.m4.2xlarge, 32 GB RAM): 0,7*31*24 = 520 € / Monat

Was wäre denn eine sinnvolle Menge an RAM, würdet ihr sagen 32 GB müssen sein oder kann man bei 21 GB Datenbankvolumen auch weniger fahren? 16 GB?

Kenny [CH] schrieb:

@TE was wird mit der Webseite gemacht? 21GB grosse DB deutet für mich auf ein System hin, was z.B. ein Forum oder Webshop beinhalten könnte.

Zum Vergrößern anklicken....

Bei der Anwendung handelt es sich um eine Suchmaschine, es ist also unwahrscheinlich, dass alle Daten gleichoft abgefragt werden. Theoretisch müssten also auch 16 GB reichen, wenn man mal davon ausgeht, dass 3/4 aller Daten abgefragt werden. Der Rest könnte ja dann bei Bedarf von der Platte gekratzt werden, da das vermutlich eh nicht sehr häufig vorkommt...

mfuesslin schrieb:

Suchmaschine, es ist also unwahrscheinlich, dass alle Daten gleichoft abgefragt werden.

Zum Vergrößern anklicken....

Also viel Read und wenig bis fast keine Write?
Wenn keine Writes vorhanden sind musst du nicht (wie ich gesagt habe auf die IOPS achten etc) dann ist das Ram definitv wichtiger.

Die IOPS werden dann wichtig wenn z.B. Ein Webshop, Forum oder Eine Software kontinuerlich darauf zugreift und liest und schreibt.