Proxmox VE auf alter Hardware (Nehalem Xeon)

[ahofmann]

Hallo zusammen,

ich recherchiere gerade verschiedene Setups für Proxmox VE. Ich will unter anderem zwei Windows 10 Installationen virtualisieren. Eine davon soll einen Lexware Server werden, dass heißt da läuft ein SQL Server drauf. Beim herumstöbern für Hardware bin ich auf lauter Angebote gestoßen, wo ziemlich billig Dell R710 Server verscherbelt werden. Das Hauptproblem, dass ich an so einem Ding sehe, ist das die Intel CPUs alte Nehalems sind und auch wenn die auf dem Papier über 3 GHz kommen, einfach recht lahm sein werden. Hat jemand hier Erfahrung mit Nehalem Xeons (oder so einen R710 bei sich herumstehen) ob da ein Windows 10 über Proxmox so läuft, dass es angenehm ist? Oder sind die CPUs nicht mal so wichtig, sondern viel eher das man den Storage performant hinbekommt?
Momentan arbeitet die Buchhaltung im Lexware mit einem ganz normalen PC, Intel i3 Ivy Bridge und irgendeiner S-ATA Platte. Wenn so ein alter R710 über Proxmox nicht langsamer als das wäre, wäre das ein super Schnäppchen.

 

[hec]

Welche CPU ist denn genau verbaut?

Wir haben auch solche Systeme im Einsatz (X5650). Ich kann keine Probleme erkennen. In den meisten Fällen ist das Problem zu wenig RAM oder langsames Storage.

 

[ahofmann]

Welche CPU ist denn genau verbaut?

Wir haben auch solche Systeme im Einsatz (X5650). Ich kann keine Probleme erkennen. In den meisten Fällen ist das Problem zu wenig RAM oder langsames Storage.

Als CPU habe ich mir auch sowas wie den X5650 überlegt. Wird da auch Windows virtualisiert? Langsamer storage wäre für mich natürlich tödlich, es soll ja ein SQL Server drauf laufen und der darf nicht langsamer werden als er jetzt auf einem consumer PC ist. Ich habe mich mal bei ZFS reingelesen und vermute dass durch den Einsatz einer SSD als l2arc das insgesamt schneller werden dürfte, als es jetzt auf besagtem consumer PC ist.

 

[hec]

Nachdem ich bei einem Cluster gerade am Testen bin habe ich ein Windows 10 ausgerollt.

Das läuft recht gut. Allerdings läuft das bei uns alles auf einem NetApp Metrocluster mit ausreichend Flash. Somit gehen nur die wenigsten Zugriffe auf das Diskbackend.

 

[hec]

Bei SQL Server am besten DB und LOG direkt als LUNs in die VM verbinden. Da hast du meistens die beste Performance.

 

[ahofmann]

Also falls mal jemand per Google auf diesen Thread stoßen sollte: Der Server läuft seit Monaten ganz Okay, die Prozessoren habe ich auf zwei X5672 gepimpt. Jetzt zieht die Kiste 200 Watt aus der Leitung, aber die 3,2 GHz machen sich bemerkbar. Wie @hec schon gesagt hat, die CPU ist selten das Problem, meistens fehlt einem RAM und Storage ist auch immer zu langsam. Konkret heißt das: man kann ein paar Sekunden lang mit 100 MByte/sec in einer VM schreiben, dann fängt die ganze Maschine an abzuspacken, eine SSH Shell auf den physikalischen Server hört auf zu reagieren usw. Das ist ziemlich gruselig und die Ursache davon habe ich noch nicht gefunden. Ist im Alltag aber nicht relevant. 32 GB RAM sind drin, mehr wäre schöner. ZFS ist ein Monstrum, dass zu verstehen die mit Abstand meiste Zeit gebraucht hat und weiterhin braucht. Es erinnert mich stark an MySQL, das man auch mit gefühlt 400 Configflags einstellen kann und deren Default Config total sch...lecht ist. Bei MySQL ist das Problem das es viel zu wenig RAM nimmt (32 MByte in der Debian default config) und bei ZFS ist es viel zuviel. Man muß sehr genau wissen welche Flags relevant sind (was ich bei ZFS noch nicht weiß) und wie die Config mit der eingesetzten Hardware zusammenpasst. Momentan habe ich für ZFS folgende Config:

options zfs zfs_dirty_data_max_percent=40

options zfs zfs_resilver_delay = 2
options zfs zfs_scrub_delay = 4

options zfs zfs_txg_timeout=15

# use the prefetch method
options zfs zfs_prefetch_disable=0


# max write speed to l2arc
# tradeoff between write/read and durability of ssd (?)
# default : 8 * 1024 * 1024
# setting here : 500 * 1024 * 1024
options zfs l2arc_write_max=524288000


# number of max device writes to precache
# default : 2
options zfs l2arc_headroom=12

# default : 32768
options zfs zfs_immediate_write_sz=131072
# default : 1024*1024 = 1mb
options zfs zil_slog_limit=536870912

 

[hec]

MySQL ist in der Standardkonfiguration für nichts zu gebrauchen.
Gerade bei größern Tabellen sind die Sorts bzw Temp Tables auf Disk ein Problem. Das muss im RAM erfolgen oder man hat echt ein Problem.

Ich finde Storage und Hypervisor sollten getrennt sein. ZFS hat Ähnlichkeiten mit NetApps WAFL Filesystem. Allerdings sind die Controller entsprechend mit Hardware ausgestattet. Wir reden hier von 64GB RAM bei den kleinen Controllern. ZFS ist genauso Speicherhungrig. Unter 128 bzw besser 256GB RAM würde ich heute keine Server mehr nehmen.