ETCD Datenbank zu langsam auf Ceph Storage

[gio2022]

Hallo zusammen,
wir betreiben ein Proxmox-Cluster mit Ceph-Storage.
Trotz der Verwendung von NVMe-Speichern, mit denen alle anderen Anwendungen sehr zufrieden sind, berichtet die ETCD-Datenbank unseres Kubernetes-Clusters über eine zu hohe Latenz beim Schreiben.
Nach meinem Verständnis ist die ETCD-Datenbank so konzipiert, dass sie eine Schreibbestätigung erst nach dem tatsächlichen Schreiben auf die Festplatte sendet. Designbedingt darf kein Cache verwendet werden...
Ich muss eine Latenz von unter 10ms halten, um Probleme zu vermeiden. Die blaue Linee repräsentiert die ETCD auf dem Proxmox-Cluster mit Ceph. Die anderen beiden Linieen gehören zu unserem alten Cluster.
Hier sieht man, dass der blaue Balken gerne nach oben ausschlägt... und leider auch bis zu 200ms erreicht, wenn auf anderen viruelle Maschinen intensive I/O-Operationen stattfinden. Eine Lösung könnte sein, in diesem Cluster speziell sehr schnelle, kleine NVMe-Speicher ausschließlich für die ETCD zu verwenden. Meine Frage: Was wäre die beste Lösung für die Anbindung diese Kleine Platten an Proxmox? Welche Art von Storage sollte ich am besten verwenden?
Vielen Dank

 

[aaron]

Wie ist euer Ceph Cluster aufgebaut?

• Netzwerk das Ceph verwendet?
• Was für NVMEs? Insbesondere, sind es datacenter SSDs mit PLP?
• CPUs?

Wie ist die VM configuriert in der das läuft? qm config {VMID}
Sind alle Power Saving Features im BIOS deaktiviert? Hardware Hersteller haben mitunter Anleitungen welche BIOS Einstellungen nützlich sind um High Performance bzw. Virtualisierte Workloads zu optimieren.

 

[gio2022]

Hallo Aaron,
Netzwerk nur 10G - mehr können wir nicht nicht
NVME sind kioxa Datacenter
96 x AMD EPYC 7443 24-Core Processor (2 Sockets)
qm config 6808
agent: 1
balloon: 0
boot: order=scsi0;net0
cipassword: **********
ciuser: XXXXXXX
cores: 4
cpu: host
hotplug: disk,network,usb
ipconfig0: ip=192.168.68.8/17,gw=192.168.64.2
memory: 16000
meta: creation-qemu=7.2.0,ctime=1685963055
name: kube-etcd01
net0: virtio=ae:b5:41:19:f2:79,bridge=vmbr1
numa: 0
ostype: l26
scsi0: cephvm:vm-6808-disk-0,backup=0,cache=writeback,iothread=1,size=64G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=0be78a3b-4be9-4d34-a535-77f7e75f46e0
sockets: 2
tags:
vmgenid: 7bb719d7-3326-40cd-83e7-8826f6889aac

 

[Falk R.]

Gerade mit nur 10 GBit und einer HCI Lösung wie Ceph, wird das vermutlich nichts werden. Dann schlagen die Peaks wenn andere VMs Traffic machen sofort durch und du bekommst solche Latenzpeaks. Das ist kein Problem nur von Ceph, sondern von fast jeder HCI Lösung.

Das Netzwerkdesign ist extem wichtig bei Ceph. Ich habe kleine Mittelständler mit 100GBit für Ceph ausgestattet. Bei 4x 1,9 TB Kioxia NVMe kommen da im Peak schon mal bis zu 60 GBit Traffic zusammen. Also bitte mehrere 25GBit Links oder 100GBit Links nutzen um die NVMes auch nur Ansatzweise auszulasten.

 

[Falk R.]

Ich habe keine Ahnung von Kubernetes, aber soweit ich weiß ist die etcd Datenbank ja eine verteilte Datenbank und du kannst auf Applikationsebene Redundanz schaffen. Da würde ich lieber jeweils eine oder zwei Disks Pro Node nativ nutzen und die Verfügbarkeit auf Datenbankebene schaffen.

 

[gio2022]

Gerade mit nur 10 GBit und einer HCI Lösung wie Ceph, wird das vermutlich nichts werden. Dann schlagen die Peaks wenn andere VMs Traffic machen sofort durch und du bekommst solche Latenzpeaks. Das ist kein Problem nur von Ceph, sondern von fast jeder HCI Lösung.

Das Netzwerkdesign ist extem wichtig bei Ceph. Ich habe kleine Mittelständler mit 100GBit für Ceph ausgestattet. Bei 4x 1,9 TB Kioxia NVMe kommen da im Peak schon mal bis zu 60 GBit Traffic zusammen. Also bitte mehrere 25GBit Links oder 100GBit Links nutzen um die NVMes auch nur Ansatzweise auszulasten.

Hallo Falk,
das würde ich sofort umsetzen, aber ich finde niemanden, der mir die Switche sponsert . Also kann ich nicht über 10G hinausgehen. Abgesehen von dieser netten ETCD-VM ist alles andere für unsere Anforderungen zufriedenstellend.

 

[gio2022]

Ich habe keine Ahnung von Kubernetes, aber soweit ich weiß ist die etcd Datenbank ja eine verteilte Datenbank und du kannst auf Applikationsebene Redundanz schaffen. Da würde ich lieber jeweils eine oder zwei Disks Pro Node nativ nutzen und die Verfügbarkeit auf Datenbankebene schaffen.

Ja, genau das möchte ich tun. Eine Platte pro Node und Replica durch ETCD selbst machen.
Was ich gerne wissen wollte, war, wie binde ich diese Platte in Proxmox? Mache ich ein zpool create one-disk /dev/sdxyz ?

 

[Falk R.]

Du kannst das alles über die GUI machen. Entweder ZFS Pool oder LVM-Thin Pool wäre meine erste Wahl.

 

[Falk R.]

Hallo Falk,
das würde ich sofort umsetzen, aber ich finde niemanden, der mir die Switche sponsert . Also kann ich nicht über 10G hinausgehen. Abgesehen von dieser netten ETCD-VM ist alles andere für unsere Anforderungen zufriedenstellend.

Kommt ganz darauf an wie groß dein Cluster ist. Die kleinen 3 Node Cluster statte ich immer mit zwei 4 Port 100G Switches aus (Microtik CRS504) da kostet ein Switch 800€.

 

[gio2022]

Vielen Dank. Einer der ETCD VM ist auf die flotte Micron Platte und benimmt sich super

Kommt ganz darauf an wie groß dein Cluster ist. Die kleinen 3 Node Cluster statte ich immer mit zwei 4 Port 100G Switches aus (Microtik CRS504) da kostet ein Switch 800€.

Hello Falk, Cluster hat 5 Nodes. Das heisst, die Switche sollten stackable sein und ich brächte 2 davon. Dann die Karte für die Server .... Voilá ist es sehr viel Geld... Falls ich auch mit andere Anwendungen Probleme haben werde, werde ich wahrscheinlich doch wieder auf ZFS umsteigen müssen

 

[Falk R.]

Hello Falk, Cluster hat 5 Nodes. Das heisst, die Switche sollten stackable sein und ich brächte 2 davon. Dann die Karte für die Server .... Voilá ist es sehr viel Geld... Falls ich auch mit andere Anwendungen Probleme haben werde, werde ich wahrscheinlich doch wieder auf ZFS umsteigen müssen

25GBit Nics kosten kaum mehr als 10GBIt. Dann nimm 25G und Stacking würde ich auch nicht machen, denn du hast dann einen Logischen Switch, und beim Firmwareupdate bootet der ganze Stack. Dann lieber MLAG oder die properitären Ableger nutzen.
Ich nehme auch gern die FS S5850-24B4C Switches, da bekommst du fü 3,8k einen 24Port 25G mit 4x 100G Uplinks. Wenn man dann DAC Kabel nutzt, ist das gar nich so teuer.

 

[CoolTux]

Was für eine Kubernetes Distribution verwendet Ihr?
Bei klassischem k8s würde ich für die 3 controle-plane Nodes lokalen storage nehmen.
Bei rke2 kann man sehen das man den etcd separat verteile von der controle-plane. Oder Du machst sogar den etcd als Service statt als static Pod.