Installation Proxmox Cluster und CEPH - Fehler 500

stewen78

Member
Jan 19, 2021
17
3
8
46
Hallo beisammen,
Ich habe mir einen Cluster aus drei Nodes für mein Homelab zusammengestellt.
Ich möchte in jedem Node zwei 6TB Festplatten per CEPH zusammenschalten.
Mein Ablaufplan:
1.) Proxmox auf alle drei Nodes installieren
2.) Updates (aus no-subscription) einspielen
3.) Netzwerkkarten konfigurieren (3x NIC pro Node) und testen (per Ping = jeweils ok)
3a) Cluster erstellen -> klappt
3b) Hosts-Datei anpassen und alle drei Nodes eintragen
4.) CEPH auf dem ersten Node installieren und konfigurieren (1x NIC für Public und 1x NIC für Cluster)
5.) CEPH auf dem zweiten Node per GUI installieren (!!!)
Hier passiert der Fehler. Bei der Installation von CEPH per GUI meldet er - im Hintergrund ist noch die Installation zu sehen - einen Timeout-Fehler.
Der CEPH auf Node1 schaut ok aus, auf den beiden anderen passiert der oben geschilderte Fehler.
Danach funktioniert nix wie es zu erwarten wäre, immer kommt Timeout (500) oder“Could Not Connect to Ceph Cluster despite configured Monitors“ ...
Was mach ich falsch? Danke schonmal für die Hilfe!

VG
Stephan
 
Last edited:
Hm, nö hab ich nicht. Ich kann einfach nicht nachvollziehen, warum bei der Installation von Ceph auf den weiteren Nodes ein Error 500 kommt. Ich hab das früher schon einige Male so installiert, da hat’s ohne Probleme funktioniert. Könnte es an den Netzwerkkarten liegen? In der Zwischenzeit hab ich die Variante ohne Switch versucht (nach dieser Beschreibung: Full Mesh), aber auch hier tritt das Verhalten beim Installieren von Ceph auf. Kann mir das nicht erklären ...
Wo würde ich die MTU (und auf welchen Wert) erhöhen?
Danke für die Antwort btw ;)
 
Wo würde ich die MTU (und auf welchen Wert) erhöhen?
Ok, dann ist die MTU 1500. ;) Die MTU ändert man auch in /etc/network/interfaces oder WebUI.

Hm, nö hab ich nicht. Ich kann einfach nicht nachvollziehen, warum bei der Installation von Ceph auf den weiteren Nodes ein Error 500 kommt. Ich hab das früher schon einige Male so installiert, da hat’s ohne Probleme funktioniert. Könnte es an den Netzwerkkarten liegen?
Würde ich erstmal nicht tippen. Oft liegt es an der Netzwerkkonfiguration. ;) Bitte poste mal deine Netzwerk- und Ceph-Konfiguration.
 
Hier die /etc/network/interfaces vom dritten Node:
# network interface settings; autogenerated # Please do NOT modify this file directly, unless you know what # you're doing. # # If you want to manage parts of the network configuration manually, # please utilize the 'source' or 'source-directory' directives to do # so. # PVE will preserve these directives, but will NOT read its network # configuration from sourced files, so do not attempt to move any of # the PVE managed interfaces into external files! auto lo iface lo inet loopback iface eno1 inet manual auto enp6s0 iface enp6s0 inet manual auto enp7s0 iface enp7s0 inet manual auto bond0 iface bond0 inet static address 192.168.234.23/24 bond-slaves enp6s0 enp7s0 bond-miimon 100 bond-mode broadcast #CEPH Mesh auto vmbr0 iface vmbr0 inet static address 192.168.78.23/24 gateway 192.168.78.1 bridge-ports eno1 bridge-stp off bridge-fd 0 #Frontend und Coronet

Ich hab nun nochmal alle Nodes neu aufgesetzt und die Netzwerkkonfiguration gesetzt. Die anderen beiden Nodes haben 192.168.78.21 und 192.168.78.22 sowie beim Bond die 192.168.234.21 sowie 192.168.234.22. Die 234er Netzwerkkarten sind nun wie in dem oben erwähnten Artikel direkt über Kreuz verbunden, der Ping funktioniert in alle Richtungen. Die Konfig hab ich in der GUI erstellt.

Soll ich die MTU für den Bond ändern oder für die physikalischen Adapter? Und auf welchen Wert? 5000?

Als nächstes würde ich jetzt den Cluster einrichten und danach von einem Node aus die CEPH Installation durchführen.

Danke für die Hilfe!

VG Stephan

Hier noch die Pings:
ping 192.168.234.21 PING 192.168.234.21 (192.168.234.21) 56(84) bytes of data. 64 bytes from 192.168.234.21: icmp_seq=1 ttl=64 time=0.275 ms 64 bytes from 192.168.234.21: icmp_seq=2 ttl=64 time=0.255 ms 64 bytes from 192.168.234.21: icmp_seq=3 ttl=64 time=0.266 ms --- 192.168.234.21 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 27ms rtt min/avg/max/mdev = 0.255/0.265/0.275/0.015 ms ping 192.168.234.22 PING 192.168.234.22 (192.168.234.22) 56(84) bytes of data. 64 bytes from 192.168.234.22: icmp_seq=1 ttl=64 time=0.369 ms 64 bytes from 192.168.234.22: icmp_seq=2 ttl=64 time=0.264 ms 64 bytes from 192.168.234.22: icmp_seq=3 ttl=64 time=0.265 ms --- 192.168.234.22 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 53ms rtt min/avg/max/mdev = 0.264/0.299/0.369/0.051 ms ping 192.168.234.23 PING 192.168.234.23 (192.168.234.23) 56(84) bytes of data. 64 bytes from 192.168.234.23: icmp_seq=1 ttl=64 time=0.015 ms 64 bytes from 192.168.234.23: icmp_seq=2 ttl=64 time=0.007 ms 64 bytes from 192.168.234.23: icmp_seq=3 ttl=64 time=0.020 ms --- 192.168.234.23 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 45ms rtt min/avg/max/mdev = 0.007/0.014/0.020/0.005 ms ping 192.168.78.21 PING 192.168.78.21 (192.168.78.21) 56(84) bytes of data. 64 bytes from 192.168.78.21: icmp_seq=1 ttl=64 time=0.562 ms 64 bytes from 192.168.78.21: icmp_seq=2 ttl=64 time=0.299 ms 64 bytes from 192.168.78.21: icmp_seq=3 ttl=64 time=0.297 ms --- 192.168.78.21 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 52ms rtt min/avg/max/mdev = 0.297/0.386/0.562/0.124 ms ping 192.168.78.22 PING 192.168.78.22 (192.168.78.22) 56(84) bytes of data. 64 bytes from 192.168.78.22: icmp_seq=1 ttl=64 time=0.542 ms 64 bytes from 192.168.78.22: icmp_seq=2 ttl=64 time=0.305 ms 64 bytes from 192.168.78.22: icmp_seq=3 ttl=64 time=0.298 ms --- 192.168.78.22 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 36ms rtt min/avg/max/mdev = 0.298/0.381/0.542/0.115 ms ping 192.168.78.23 PING 192.168.78.23 (192.168.78.23) 56(84) bytes of data. 64 bytes from 192.168.78.23: icmp_seq=1 ttl=64 time=0.027 ms 64 bytes from 192.168.78.23: icmp_seq=2 ttl=64 time=0.006 ms 64 bytes from 192.168.78.23: icmp_seq=3 ttl=64 time=0.006 ms --- 192.168.78.23 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 52ms rtt min/avg/max/mdev = 0.006/0.013/0.027/0.009 ms
 
So, jetzt läuft auch der Cluster wieder - alle Nodes sind nun über eine GUI erreichbar und es sind keine Fehler aufgetreten. Das Coronet läuft über die 78er Netzwerkkarten.
Nun möchte ich CEPH installieren, aber genau hier ist gestern der Fehler passiert. Wenn also noch jemand eine Idee oder einen Hinweis hat bevor ich da dran gehe, dann gerne immer her damit.

Danke und VG
Stephan
 
Hallo nochmal, es ist wieder passiert. Ich habe nun wieder Ceph 15.2 installiert, zuerst ohne Fehler auf Node 1 (auf IP 192.168.234.21). Die Installation des zweiten Node (192.168.234.22) schlägt fehl - inmitten der Installation bricht das Fenster ab und meldet "got timeout (500)". Und nun das Beste: ab jetzt klappt der Ping nur noch zwischen den Nodes 2 und 3 (also von Node 2 auf 192.168.234.23 und von Node 3 auf 192.168.234.22). Der Ping von und zum Node 1 (mit Ceph drauf) haut nicht mehr ordentlich hin.

Von Node 1 auf Node 2:
PING 192.168.234.22 (192.168.234.22) 56(84) bytes of data. 64 bytes from 192.168.234.22: icmp_seq=1 ttl=64 time=3124 ms 64 bytes from 192.168.234.22: icmp_seq=2 ttl=64 time=2102 ms 64 bytes from 192.168.234.22: icmp_seq=3 ttl=64 time=6966 ms 64 bytes from 192.168.234.22: icmp_seq=4 ttl=64 time=5942 ms 64 bytes from 192.168.234.22: icmp_seq=5 ttl=64 time=4940 ms 64 bytes from 192.168.234.22: icmp_seq=6 ttl=64 time=3926 ms 64 bytes from 192.168.234.22: icmp_seq=7 ttl=64 time=2902 ms 64 bytes from 192.168.234.22: icmp_seq=8 ttl=64 time=1878 ms 64 bytes from 192.168.234.22: icmp_seq=9 ttl=64 time=854 ms 64 bytes from 192.168.234.22: icmp_seq=10 ttl=64 time=0.268 ms 64 bytes from 192.168.234.22: icmp_seq=11 ttl=64 time=0.250 ms --- 192.168.234.22 ping statistics --- 14 packets transmitted, 11 received, 21.4286% packet loss, time 260ms rtt min/avg/max/mdev = 0.250/2966.570/6965.660/2209.136 ms, pipe 7

Und von Node 2 auf Node 1:
PING 192.168.234.21 (192.168.234.21) 56(84) bytes of data. 64 bytes from 192.168.234.21: icmp_seq=1 ttl=64 time=0.206 ms 64 bytes from 192.168.234.21: icmp_seq=2 ttl=64 time=0.259 ms 64 bytes from 192.168.234.21: icmp_seq=3 ttl=64 time=0.268 ms 64 bytes from 192.168.234.21: icmp_seq=4 ttl=64 time=0.265 ms 64 bytes from 192.168.234.21: icmp_seq=5 ttl=64 time=4951 ms 64 bytes from 192.168.234.21: icmp_seq=6 ttl=64 time=3927 ms 64 bytes from 192.168.234.21: icmp_seq=7 ttl=64 time=2903 ms 64 bytes from 192.168.234.21: icmp_seq=8 ttl=64 time=1879 ms 64 bytes from 192.168.234.21: icmp_seq=9 ttl=64 time=855 ms 64 bytes from 192.168.234.21: icmp_seq=13 ttl=64 time=7543 ms 64 bytes from 192.168.234.21: icmp_seq=14 ttl=64 time=6519 ms --- 192.168.234.21 ping statistics --- 23 packets transmitted, 11 received, 52.1739% packet loss, time 474ms rtt min/avg/max/mdev = 0.206/2598.150/7543.275/2659.060 ms, pipe 8

Von Node 3 (noch kein Ceph) auf Node 1 schauts so aus:
PING 192.168.234.21 (192.168.234.21) 56(84) bytes of data. From 192.168.234.23 icmp_seq=1 Destination Host Unreachable From 192.168.234.23 icmp_seq=2 Destination Host Unreachable From 192.168.234.23 icmp_seq=3 Destination Host Unreachable From 192.168.234.23 icmp_seq=4 Destination Host Unreachable From 192.168.234.23 icmp_seq=8 Destination Host Unreachable From 192.168.234.23 icmp_seq=9 Destination Host Unreachable --- 192.168.234.21 ping statistics --- 11 packets transmitted, 0 received, +6 errors, 100% packet loss, time 232ms, pipe 4

Wenn der Timeout eingetreten ist, dann funktioniert auch der Ping wieder mit normalen Werten (hier also etwas um die 0.3ms). Sobald ich auf einem Node wieder in das Ceph-Menü springe, hängt der Ping wieder. Es ist, als würde etwas den Traffic blockieren!? Da kein Switch dazwischen hängt, kann ich mir da momentan keinen Reim drauf machen :(

Hier mal das Beispiel von Node 2 auf Node 1; wo die Werte auf mehrere Sekunden hochgehen hab ich in der GUI bei Node 2 auf das Ceph-Menü geklickt. Nachdem dann der Timeout (5 Sekunden) kommt, normalisieren sich die Werte.

64 bytes from 192.168.234.21: icmp_seq=722 ttl=64 time=0.262 ms 64 bytes from 192.168.234.21: icmp_seq=723 ttl=64 time=0.263 ms 64 bytes from 192.168.234.21: icmp_seq=724 ttl=64 time=0.229 ms 64 bytes from 192.168.234.21: icmp_seq=725 ttl=64 time=0.270 ms 64 bytes from 192.168.234.21: icmp_seq=726 ttl=64 time=6849 ms 64 bytes from 192.168.234.21: icmp_seq=727 ttl=64 time=5825 ms 64 bytes from 192.168.234.21: icmp_seq=728 ttl=64 time=4801 ms 64 bytes from 192.168.234.21: icmp_seq=729 ttl=64 time=3777 ms 64 bytes from 192.168.234.21: icmp_seq=730 ttl=64 time=2753 ms 64 bytes from 192.168.234.21: icmp_seq=731 ttl=64 time=1729 ms 64 bytes from 192.168.234.21: icmp_seq=732 ttl=64 time=705 ms 64 bytes from 192.168.234.21: icmp_seq=733 ttl=64 time=0.189 ms 64 bytes from 192.168.234.21: icmp_seq=734 ttl=64 time=0.267 ms 64 bytes from 192.168.234.21: icmp_seq=735 ttl=64 time=0.259 ms 64 bytes from 192.168.234.21: icmp_seq=736 ttl=64 time=0.280 ms

Jetzt blick ich wirklich nicht mehr durch ... hat jemand eine Idee? Was übersehe ich hier?

Danke schonmal!
VG Stephan
 
Last edited:
Ich glaube, ich habe das Problem gefunden. Die installierten Netzwerkkarten sind vom Typ „UBIT Dual PCI-E“ (die lagen noch in der Kiste), diese verwenden den Chip Realtek RTL8111G. Offenbar sind Probleme mit diesen Adaptern - zumindest out of the box - keine Seltenheit. Ich werde mir also mal die Treiber-Seite vornehmen und sehen, ob es was bringt. Wenn ich diese Karte zum Frontend mache, bekomme ich mit dem Standard-Treiber direkt bei der Installation noch nicht mal eine IP per DHCP zugewiesen. Ich werde berichten ...
Gute Nacht :)
 
Hallo beisammen,
das Problem ist gelöst! Die verbauten Karten nutzen das Treibermodul r8169, welches für die Karten mit dem Chipsatz RTL8111G nicht zuverlässig funktioniert. Man müsste manuell das Modul r8168 installieren, dann klappt auch eine stabile Verbindung mit den Karten. Eine Neu-Installation mit anderen Netzwerkkarten (echte r8169 von TP-Link) klappt völlig ohne ein Problem. Das hat mich schön zwei Tage gekostet ;)
Danke an "Alwin Artreich" für den Hilfeversuch.
Gute Zeit!
Stephan
 
  • Like
Reactions: Alwin Antreich

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!