Ich habe auf 4 Knoten ein komplett neues Betriebssystem mit Proxmox installiert. Jeder Knoten hat 2xNVMe und 1xHD, eine NIC öffentlich, eine NIC privat. Im öffentlichen Netzwerk läuft zusätzlich eine Wireguard-Schnittstelle für die PVE-Cluster-Kommunikation. Die private Schnittstelle sollte nur für den zukünftigen verteilten Speicher verwendet werden.
# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
link/ether 6c:b3:11:07:f1:18 brd ff:ff:ff:ff:ff:ff
inet 10.255.255.2/24 brd 10.255.255.255 scope global enp3s0
valid_lft forever preferred_lft forever
inet6 fe80::6eb3:11ff:fe07:f118/64 scope link
valid_lft forever preferred_lft forever
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b4:2e:... brd ff:ff:ff:ff:ff:ff
inet 168..../26 brd 168....127 scope global eno1
valid_lft forever preferred_lft forever
inet6 2a01:.../128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::b62e:99ff:fecc:f5d0/64 scope link
valid_lft forever preferred_lft forever
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether a2:fd:6a:c7:f0:be brd ff:ff:ff:ff:ff:ff
inet6 2a01:....::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::..:f0be/64 scope link
valid_lft forever preferred_lft forever
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.3.0.10/32 scope global wg0
valid_lft forever preferred_lft forever
inet6 fd01:3::a/128 scope global
valid_lft forever preferred_lft forever
Mit den Knoten ist alles in Ordnung und der PVE-Cluster läuft wie erwartet.
# pvecm status
Cluster information
-------------------
Name: ac-c01
Config Version: 4
Transport: knet
Secure auth: on
Quorum information
------------------
Date: Tue Dec 15 22:36:44 2020
Quorum provider: corosync_votequorum
Nodes: 4
Node ID: 0x00000002
Ring ID: 1.11
Quorate: Yes
Votequorum information
----------------------
Expected votes: 4
Highest expected: 4
Total votes: 4
Quorum: 3
Flags: Quorate
Membership information
----------------------
Nodeid Votes Name
0x00000001 1 10.3.0.4
0x00000002 1 10.3.0.10 (local)
0x00000003 1 10.3.0.13
0x00000004 1 10.3.0.16
Die PVE-Firewall ist im Cluster aktiv, aber es gibt eine Regel, dass alle PVE-Knoten über jedes Protokoll auf jedem Port auf jeder Schnittstelle miteinander kommunizieren können. Das stimmt – ich kann zwischen allen Knoten auf allen IPs Ping, SSH usw. verwenden.
Dann habe ich Ceph installiert.
pveceph install
Auf dem ersten Knoten habe ich ceph initialisiert mit
pveceph init -network 10.255.255.0/24
pveceph createmon
Das funktioniert.
Beim zweiten habe ich dasselbe versucht (ich bin nicht sicher, ob ich die -networkOption einstellen muss – ich habe es mit und ohne versucht). Das funktioniert auch.
Aber pveceph createmon schlägt auf jedem Knoten fehl mit:
# pveceph createmon
got timeout
Ich kann auch Port 10.255.255.1:6789 auf jedem Knoten erreichen. Was auch immer ich versuche – ich bekomme auf jedem Knoten außer Knoten1 die Meldung „Zeitüberschreitung“. Auch das Deaktivieren der Firewall hat keine Wirkung.
Wenn ich die Option entferne -network, kann ich alle Befehle ausführen. Es sieht so aus, als ob es nicht über die zweite Schnittstelle kommunizieren kann. Aber die Schnittstelle ist in Ordnung.
Wenn ich „Netzwerk“ 10.3.0.0/24und „Cluster-Netzwerk“ einstelle 10.255.255.0/24, funktioniert es auch, aber ich möchte, dass die gesamte Ceph-Kommunikation über läuft 10.255.255.0/24. Was ist falsch?
Antwort1
Nur als Referenz: In der offiziellen Dokumentation wird erwähnt, dass Jumbo-Frames wichtige Leistungsverbesserungen bringen:
https://ceph.io/en/news/blog/2015/ceph-loves-jumbo-frames/
Ich für meinen Teil habe eine Verbesserung der Lese-/Schreibleistung von rund 1400 % festgestellt, nachdem wir die MTU auf den 6 von uns eingerichteten Knoten (3 Speicher, 3 Rechenknoten) geändert haben.
Und nein, das ist kein Schreibfehler. Wir sind von 110 MB/s Lesen/Schreiben bei ddTests in Linux-VMs auf 1,5-1,6 GB/s danach gekommen (1 Gbps öffentliches Netzwerk, 10 Gbps privates Netzwerk, OSDs auf SATA-SSDs).
Nota Bene: Das Ändern der MTU auf allen Netzwerkschnittstellen (öffentlich UND privat) scheint ziemlich wichtig zu sein! In unserem Fall hat die Änderung nur auf den privaten Netzwerkkarten das ganze System durcheinandergebracht.
Aus Redhats Dokument:
Wichtig
Red Hat Ceph Storage erfordert für alle Netzwerkgeräte im Kommunikationspfad den gleichen MTU-Wert, End-to-End für öffentliche und Cluster-Netzwerke.
Ich hoffe, das hilft jemandem! Prost
Antwort2
Das Problem ist - die MTU 9000 ist ein Problem. Auch wenn ich den kompletten Proxmox Cluster über das private Netzwerk betreibe kommt es zu Fehlern.
ip link set enp3s0 mtu 1500
Ceph hat also ein Problem mit Jumbo-Frames.