Hardware

[hackmann]

Hallo liebe alle,

zur Zeit läuft unsere Virtualisierung auf einer Hardware seit mehr als 3 Jahren sehr gut. Der Rechner ist aber schon etwas älter!

product: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz
physical id: 4

Manufacturer: ASUSTeK COMPUTER INC.
Product Name: P8H61-M LE R2.0

-----------------------------------------------------

proxmox-ve: 5.4-1 (running kernel: 4.15.18-15-pve)

----------------------------------------------------

ZFS

1x SSD für das Proxmox
2x TB Platten / Raid1 / für die VMS mit ZFS SNAPSHOTS, da jede VM ein Dataset bekommt.

NAME STATE READ WRITE CKSUM
datenproxmox ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
wwn-0x50014ee2b4e15406 ONLINE 0 0 0
wwn-0x50014ee25fa4d0a6 ONLINE 0 0 0



pool: rpool
state: ONLINE
scan: scrub repaired 0B in 0h1m with 0 errors on Tue Jul 27 23:01:52 2021
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
sata-Samsung_SSD_840_EVO_250GB_S1DBNSADB27489A-part2 ONLINE 0 0 0

----------------------------------------------------------

Nun wird ein neuer Rechner benötigt. Mit meinem Chef abgesprochen, Wir nehmen wieder Workstationen, die können später auch als Arbeitsplatzrechner dienen.
Das Budget erlaubt zwei Rechner, also hatte ich mich für Die Workstation FUJITSU Desktop ESPRIMO P9010 entschieden. Ich habe maximal 2000 Euro zur Verfügung!

Eine SSD ist schon dabei, dazu zusätzlich zwei 8TB Platten. Die gleiche Konfiguration wie beim altem Rechner.

Von FUJITSU bekomme ich natürlich keinen Support, ist auch klar.

Hat jemand eventuell einen Rechner FUJITSU Desktop ESPRIMO P9010 mit Proxmox am laufen?

Wir haben 4 VMs, diese werden über ein Dataset"ZFS" angelegt

/vms/server1
/vms/server2
/vms/server3
/vms/server4

Storage als Verzeichnis und qcow2 als VM

Gesichert wird über ZFS Snapshots.

Die Server werden über ein Script nachts heruntergefahren, Snapshot, dann wieder hochgefahren. Dauert zur Zeit pro VM maximal 15 Sekunden! pro VM. "KEINE Templates sondern Container"
Danach werden die Snapshots inkrementell auf einen zweiten Rechner gesichert.

Zusätzlich werden von einem Bacula Server alle relevanten Daten von den Servern nochmals gesichert. Maximale Duration von den Daten 2 Wochen!

Mit dieser Konfiguration fahre ich seit mehr als 4 Jahren sehr gut.

Wir haben ca. 20 User die auf Nextcloud zugreifen, einen Zentyal Server der das DNS/DHCP übernimmt und einen Samba auf dem Proxmox, der die internen Daten Verwaltet und auch die Daten per ZFS sichert. "dazu sollte man den Samba anhalten!"
Zusätzlich läuft noch ein 2ter Bacula Server auch auf einem anderem Proxmox, der andere Daten sichert.


-------------------------------------------------------

Ich bin leider nicht der Guru, was Hardware angeht.

Für jeden Tipp bin ich sehr dankbar. Zumal mir die Mittel fehlen, um mal ordentlich eine Hardware zu Testen fehlen.

Und bitte keine Antworten zu meiner Konfiguration, wieso und warum, dass geht besser und schlechter.

Dass sind die Anforderungen.

lieben dank

 

[Dunuin]

Wir haben 4 VMs, diese werden über ein Dataset"ZFS" angelegt

/vms/server1
/vms/server2
/vms/server3
/vms/server4

Storage als Verzeichnis und qcow2 als VM

Gesichert wird über ZFS Snapshots.

Warum lässt du die VMs als Directory mit qcow2 laufen wenn alles über ZFS läuft? Das ist doch eigentlich doppelt gemoppelt, wenn du da ein CoW auf einem CoW laufen lässt und erzeugt zusätzlich Overhead. Normal wäre ja die VMs ohne ein Directory Storage direkt als zvol auf ZFS laufen zu lassen mit RAW statt qcow2 als Format.

 

[ThorstenS]

Ich kenne die Hardware nicht, aber mEn läuft proxmox auch auf consumer Hardware gut.
Ich würde die SSD nicht komplett für proxmox reservieren, das ist Perlen vor die Säue.

Du kannst eine Partition dem ZFS Pool als Cache bei Seite stellen. Das bringt richtig Geschwindigkeit ins Setup.
(sowas wie zpool add zfspool cache /dev/sda3).

 

[Dunuin]

Ich kenne die Hardware nicht, aber mEn läuft proxmox auch auf consumer Hardware gut.
Ich würde die SSD nicht komplett für proxmox reservieren, das ist Perlen vor die Säue.

Du kannst eine Partition dem ZFS Pool als Cache bei Seite stellen. Das bringt richtig Geschwindigkeit ins Setup.
(sowas wie zpool add zfspool cache /dev/sda3).

Das würde ich persönlich nicht machen im produktiven Betrieb. Bis vor kurzem war es nicht möglich den L2ARC persistent anzulegen (also ich glaube mit PVE 6.X geht das noch nicht weil die ZoL Version zu alt ist) und dann würde bei jedem Reboot auch immer die komplette Partitionsgröße neu geschrieben werden müssen, was dann für ordentlich Writes auf der SSD sorgt, selbst wenn es nur ein Read-Cache ist. Writes möchte man ja eigentlich nicht auf der System SSD, weil dann garnichts mehr geht, wenn die mal auffällt, besonders wenn diese wie beim Thread-Ersteller nicht einmal für Ausfallsicherheit gespiegelt ist.
Und selbst mit einem persistentem L2ARC würde ja ständig etwas auf die SSD geschrieben werden, weil sich ja die Daten ändern, welche der Cache zum schnellen Abrufen bereithält.
Außerdem versucht man ja für Produktivsysteme die Systemlaufwerke von den VM Storage zu trennen, damit die Gäste nicht die System-Laufwerke ausbremsen können und so PVE vom Hypervisen abhalten. Holst du dir einen Cache für den VM Pool auf die System-SSD, dann hast du wieder das gleiche Problem, dass da Gäste den Host in die Knie zwingen könnten und man könnte PVE auch gleich zusammen mit den VMs auf die HDDs installieren.

 

[hackmann]

Vielen Dank für eure Antworten,

zur Frage 1
Warum lässt du die VMs als Directory mit qcow2 laufen wenn alles über ZFS läuft? Das ist doch eigentlich doppelt gemoppelt, wenn du da ein CoW auf einem CoW laufen lässt und erzeugt zusätzlich Overhead. Normal wäre ja die VMs ohne ein Directory Storage direkt als zvol auf ZFS laufen zu lassen mit RAW statt qcow2 als Format.

-.-

danke Dunuin ----
Weil ich die qcow2 per winscp nochmals sichere, dass mache ich schon seit 4 Jahren so , zumal diese auch einmal im Monat mit Bacula gesichert werden.

Und hier mal kurz eine Info von Herrn Zengel was zvols angeht, da muss man sich wirklich auskennen, "ZFS Overhead durch falsche Volblocksize und Plattenplatz".


Herr Zengel hat das ausführlich beschrieben, auf was man da achten sollte, du hast bestimmt recht, aber bei 20 Usern gebe ich mir diesen riss nicht.
Zumal dass ganze auf einer Workstation läuft.

Und beim zvol was sie Sicherung angeht per zfs send auf einen anderen Rechner?

Wenn auf dem Ziel Rechner eine andere zfs Version vorhanden ist, dann kann es möglich sein, dass der zfs rollback nicht passt.

Alles im allem möchte ich den Aufwand gering halten, ein Image kann ich selbst ohne ZFS Guru zu sein, auf einem anderen Proxmox mit LVM zurückspielen, der 2 Versionen zurück liegt, ohne ZFS.

Ich habe das so eingerichtet, dass selbst ein Mitarbeiter am Wochenende oder in einem Krankheitsfall eine VM zurückspielen werden kann, ohne gleich eine Firma anrufen zu müssen, die einen haufen Geld kostet.

Also, meine Prio liegt in der Verfügbarkeit und nicht an dem Overhead.

Ich lese leider immer " die Geschwindigkeit und noch mehr Speed"!

Wenn Wir uns auf der Autobahn treffen, mit einem VOLLSPEED SSD/ZVOL nach deinem Ratschlag, an uns vorbei ballerst und uns die nächsten 10000 Kilometer ansehen, dann werde ich dich eventuell mit einem Lachen überholen.

Der Kunde sollte seine Fahrt geniessen und diese auch bezahhlen können!

Ich gehe immer bei meinen Fragen vom Kunden aus, nicht von den Spezialisten!

danke liebe grüsse

 

[hackmann]

Was den ZFS Speicher angeht, RAM per SSD, wird voll in die Hose, wenn man bestimmte Dinge nIcht beachtet!
Leider wurden diese hier in diesem Forum nicht aufgeführt!.

Lieben dank für eure Antwort.

 

[Dunuin]

danke Dunuin ----
Weil ich die qcow2 per winscp nochmals sichere, dass mache ich schon seit 4 Jahren so , zumal diese auch einmal im Monat mit Bacula gesichert werden.

Wenn es nur darum geht das du mit zvols keine Datei hast die du einfach per WinSCP auf ein Backup-Laufwerk kopieren könntest wäre "zfs send" immer noch eine Option. Du musst ja nicht zwangsweise zfs send | zfs receive benutzen um ein zvol von einem ZFS pool auf einen anderen ZFS pool zu verschieben. Du kannst auch einfach den Steam in eine Datei pipen zfs send > /mein/backup.bck und die Backup-Datei dann sonst wo wegsichern. Wenn du dann mal ein Backup wiederherstellen willst, dann kann man das ganze halt wieder umkehren: zfs receive < /mein/backup.bck