Architektur für ZFS mit NVMe Cache

[VolkerK]

Hallo zusammen,

derzeit plane ich die Ablösung einer seit etlichen Jahren gewachsenen "Homegrown" Virtualisierungs-Lösung basierend auf SATA-Disks mit MD-RAID und LVM-RAW-Volumes mit KVM.

Ziel ist es, neben dem fälligen Hardwareersatz mehr Disk-Performance und eine komfortablere Verwaltung der Qemu-VMs zu erreichen sowie in den Genuss eines externen Supports zu kommen.

Für letzteres teste ich derzeit Proxmox 4.3 auf einer Testmaschine.

Zunächst hatte ich - weil wir das seit langer Zeit ohne Probleme einsetzen und gut beherrschen - LVM im Auge. Das für die SSD nötige LVM-Cache oder andere Lösungen sind aber in Proxmox nicht drin - wenn auch technisch möglich, aber ich möchte das System möglichst wenig modifizieren, um den Vorteil der supporteten Lösung nicht kaputt zu machen.

Daher überlege ich jetzt, im neuen Host ZFS mit einer NVMw ein zu setzen. Was ich darüber gelesen habe, klingt ja toll.

Genauer will ich:

- 2x 2TB SATA 7200RPM
- 1x 512GB NVMe
- ZFS RAID1 auf den SATA-Disks , hierauf Rootfs und Thin-Provisioned Disks für VMs
- NVMw als LOG/ZIL Cache für den "Speedup"
- Kein HW-RAID
- 128GB RAM
- Darauf 5-6 VMs

Das könnte ggf. um weitere 2x 2TB Disks erweitert werden. Plattenplatz ist aber nicht so das Problem. Die 2TB reichen vollkommen.
Auf Hardware-RAID wollte ich verzichten, weil lt. Doku bei ZFS eher von Nachteil.

Jetzt die Fragen:

1. Sinnvoll so?

2. Ich lese in der Doku auf der SSD zwei Partitionen an zu legen und dann dort LOG und ZIL ab zu legen. Wie groß sollten diese sein?

3. Was mache ich (ggf.) mit dem Rest des Spaces auf der SSD?


Gruß
Volker

 

[VolkerK]

Nach einem Powerloss meiner Testumgebung habe ich jetzt prompt das hier beschriebene Problem:
https://forum.proxmox.com/threads/proxmox-4-beta-2-doesnt-boot-anymore.23740/

Vielleicht wäre es ratsam, das Rootfilesystem doch auf LVM/EXT4 laufen zu lassen?

 

[wolfgang]

Hi,

zu 1.)
Das machen viele so und wir haben auch produktive Nodes so laufen.

zu 2.)
zil muss nicht groß sein da sie alle 5 sec raus gesynct wird.
log kann beliebig groß sein, bedenke es kostet Ram. ca 1GB Ram per 1TB Daten.

zu 3.)
nichts entweder mit dem log verbrauchen oder ungenutzt lassen. Kein anderes fs installieren das killt dir die Performance.

Kannst du mehr zu den Powerlost schreiben, da das eigentlich nicht passieren sollte.

 

[fabian]

Nach einem Powerloss meiner Testumgebung habe ich jetzt prompt das hier beschriebene Problem:
https://forum.proxmox.com/threads/proxmox-4-beta-2-doesnt-boot-anymore.23740/

Vielleicht wäre es ratsam, das Rootfilesystem doch auf LVM/EXT4 laufen zu lassen?

ist die fehlermeldung wirklich exakt die gleiche?

 

[VolkerK]

Hi Wolfgang,

danke für die Info!
Ich werde die Maschine mal so bestellen. Mit 128GB RAM und "nur" 2TB netto Daten dürfte der RAM-Bedarf von LOG kein Problem sein.

Noch eine Frage dazu:
Wir haben auf vielen VMs den typischen LAMP-Stack.
Wäre es - unter Performance-Aspekten des Hypervisor-Systems - sinnvoll, die MySQL-Datenbanken auf einer VM zu konsolidieren, statt einer MySQL DB pro VM? Wie groß wäre der Nutzen? Ich muss zwischen Performance-Nutzen und dem (Management) Aufwand abwägen.


Wg. Powerloss:
- Ich habe Proxmox als VM auf einen anderen Hypervisor Lösung mit 2-SATA-Disk als ZFS RAID1 installiert (Teststellung auf meinem Notebook)
- Der andere Hypervisor ist gecrashed => die VM wurde quasi einfach ausgeschaltet
- Proxmox startet jetzt nicht mehr. Grub Fehler: " compression algorithm inherit not supported"
- Ich habe die Proxmox VM mit der Proxmox-Baremetal-Installer-CD gebootet und den Installer abgebrochen, um einen Shell zu bekommen
- Ein zpool import -a führt zum Kernel-Crash!
- Ich habe dann die SATA-Disks zu SCSI-Disks geändert
- Dann crashed der Kernel nicht mehr
- Aber der import bricht ab mit:

cannot import 'rpool': I/O error
Destroy and re-create the pool from
a backup source.

Meine Recherchen haben ergeben, dass diese Meldung wohl "ernst" gemeint ist. D.h. das ZFS ist Asche.

An dieser Stelle habe ich aufgegeben und das System neu installiert. Aber nicht auf meinem Notebook, sondern auf einem anderen Host unter KVM. Damit testen wir jetzt weiter. Ich muss vor dem Einsatz erst ein Migrationsszenario erarbeiten, da wir die Downtime so kurz wie möglich halten wollen und außerdem auch gleich noch eine paar andere Dinge aufräumen wollen (das wird viel Arbeit "zwischen den Jahren").

Gruß
Volker

 

[VolkerK]

ist die fehlermeldung wirklich exakt die gleiche?

Ja, exakt! Siehe auch meine Post von eben.
Hintergrund dürfte wohl das irreparabel beschädigte ZFS sein.

 

[fabian]

das könnte eventuell durch cache einstellungen des hypervisors passiert sein.. ZFS sollte im power loss fall (abgesehen von hardware schäden!) immer konsistent bleiben (aber je nach setup ist datenverlust der letzten X sekunden/minuten natürlich möglich). wenn der hypervisor jetzt aber behauptet, er hat daten geschrieben und die aber tatsächlich nur in memory hatte, kann es eventuell auch zu korruption kommen. ich vermute die grub meldung ist hier einfach nur irreführend, weil grub mit so einem kaputten pool nichts anfangen kann..

 

[VolkerK]

Gut möglich, dass der Hypervisor gecached hat.
Ich habe die neue Testumgebung jetzt auf KVM mit cache=none und 2x SCSI-Virtio Disk laufen.
Aber macht ja nix. Ist nur die Testumgebung.

Die finale Hardware wird dann auch kein HW-RAID haben und an einer UPS dran sein, um genau das zu vermeiden

 

[LnxBil]

Ziel ist es, neben dem fälligen Hardwareersatz mehr Disk-Performance

Dann solltest du deinem System auch mehr Disk-Performance geben :-D
Das geht nur mit SAS oder gleich SAS SSDs.

Falls du noch keine Hardware gekauft hast, überlege dir, ob du kein reines SSD-System möchtest, was definitiv viel schneller sein wird als ein 2 (!) Disk SATA mit ZIL auf NVMe. L2ARC von der Größe scheint mir viel zu viel zu sein. Dein Cache ist dann viertel so groß wie dein Pool und schreit förmlich dazu gleich alles mit SSD zu machen. Du solltest bei den SSDs natürlich auch mindestens die gleiche (Prosumer-)Qualität wie die NVMe haben (wird wohl Samsung oder Intel sein) und am Besten gleich Enterprise SSDs verwenden. Damit wirst du auf jeden Fall über einen längeren Zeitraum mehr Performance haben. (Geld scheint ja nicht so wichtig zu sein, wenn man 128 GB-RAM verbaut :-D)

Bzgl. deiner MySQL-Frage:
Generell ist es natürlich schneller alles in einer DB zu haben, die sich alle die gleichen Prozesse inkl. Logwriter etc. teilen, jedoch ist es dann auch sehr schwierig einzelne Dinge zurückzuspielen, vor allem wenn man die Möglichkeiten von Proxmox VE verwenden will. Ich würde hier eine Trennung von "allem" der Konsolidierung vorziehen, sodass man hier feingranularer Snapshots machen, aber auch zurückspielen kann. Man kann z.B. auch schneller einen Abzug einer VM (also Fronend + Backend in einem) machen und damit rumspielen (z.B. Update fahren) ohne eine komplexe Umgebung zu klonen und danach anpassen zu müssen.

 

[VolkerK]

Hi LnxBill,

danke für die Info!

Gruß
VK

 

[morph027]

Zum MySQL muss ich aus Erfahrung sagen, dass es einfacher ist, einen MariaDB Galera MultiMaster Cluster mit HA-Proxy zu fahren. Das ganze Backup Konzept von VMs ist eben einfach nicht richtig application-aware. Wenn noch Tabellen offen (im RAM) waren, kann das Backup Müll sein. Hab auch schon mal kaputte Datenbanken zurückgespielt

Ich versuche generell Dienste, die das selbst können (MySQL, Dovecot, Postgres, ...), auf Anwendungsebene zu clustern. Die Anwendungsentwickler wissen meist besser, auf was sie achten müssen, als der generische Hypervisor.

Momentan fahre ich MySQL mit extra eingebundenen ZFS-Datasets in LXC Containern. Vor dem Start/Anlegen:

$ zfs create -o recordsize=16k tank/data/databases/mysql-node-a
$ echo "mp0: /tank/data/databases/mysql-node-a,mp=/var/lib/mysql" >> /etc/pve/lxc/<my-database-lxc-id>.conf 
$ pct start <my-database-lxc-id>
$ pct exec <my-database-lxc-id> /bin/sh -- -c "chown -R mysql /var/lib/mysql"

Jetzt kann man MySQL installieren. Geht natürlich auch nachträglich, da muss man halt mal Dateien vorher hin und her schieben. So kann man auch einfach den Container wegwerfen und á la Docker mit den vorhandenen Daten neu instanziieren