zusätzliche Netze werden ignoriert

G

gefinke

New Member
Dec 8, 2023
10
2
3
Weimar
Hallo,
ich habe ein Cluster aus 3 'bewährten' Lenovo Rechnern gebaut, je 3 Netzkarten 1x OnBoard, 1x DualProt.
Das StandardNetz jeweils die OnBoardKarte 192.168.20.x funktioniert, auch die vLans die darauf liegen. Die VMs/Container funktionieren.
Ich hatte den 1.Port der DualCard für die ClusterKommunikation 192.168.66.x gedacht, den 2. Port für Ceph 192.168.88.x
Das Einrichten hat auch soweit funktioniert.
Allerdings scheinen die Karten so gut wie nicht genutzt zu werden (Statistik auf dem Switch), sie lassen sich auch nicht gegenseitig pingen, manchmal kommt eine Antwort im >5 sec Bereich.
Auf einen anderen separaten Switch nur für Ceph oder Cluster hab ich das schon probiert, ändert nix.

hier die config eines der proxe
auto lo iface lo inet loopback iface enp1s0 inet manual auto enp4s0 iface enp4s0 inet static address 192.168.88.10/24 mtu 9000 #ceph auto enp5s0 iface enp5s0 inet static address 192.168.66.10/24 mtu 9000 #cluste auto vmbr0 iface vmbr0 inet static address 192.168.20.10/24 gateway 192.168.20.1 bridge-ports enp1s0 bridge-stp off bridge-fd 0

Firewal des Clusters ist aus.

Wo steckt mein Denkfehler ?

Gruß
Gert
 
Last edited:
Sind auf dem Switch Jumbo Frames aktiviert? Da muss die MTU mind 9128 betragen.
 
Hast du denn auch explizit die IPs 192.168.88.10 und 192.168.66.10 in ceph und cluster eingerichtet und nicht ausversehen IPs aus dem 192.168.20.0/24 Subnetz?
 
Falk R. said:
Sind auf dem Switch Jumbo Frames aktiviert? Da muss die MTU mind 9128 betragen.
Click to expand...
ja, der Switch kann Jumboframes und für diese Ports hab ich sie auch aktiviert. Das Verhalten war ohne die MTU schon das Gleiche, Ich hatte versucht mit den JumboFrames dieNetzte 'attraktiver' zu machen, hat aber auch nixt genutzt.
 
Dunuin said:
Hast du denn auch explizit die IPs 192.168.88.10 und 192.168.66.10 in ceph und cluster eingerichtet und nicht ausversehen IPs aus dem 192.168.20.0/24 Subnetz?
Click to expand...
ja, die netze waren jeweils vorher schon eingerichtet, und ich habe sowohl beim Einrichten des Clusters als auch beim Einrichten von Ceph diese Netze explizit angegeben.

hier mal die configs:
Code: 
[global]
         auth_client_required = cephx
         auth_cluster_required = cephx
         auth_service_required = cephx
         cluster_network = 192.168.88.10/24
         fsid = 48175749-4731-4e12-ac0f-8ecc907c2ea6
         mon_allow_pool_delete = true
         mon_host = 192.168.20.10 192.168.20.11 192.168.20.12
         ms_bind_ipv4 = true
         ms_bind_ipv6 = false
         osd_pool_default_min_size = 2
         osd_pool_default_size = 3
         public_network = 192.168.20.10/24

[client]
         keyring = /etc/pve/priv/$cluster.$name.keyring

[mon.prox1]
         public_addr = 192.168.20.10

[mon.prox2]
         public_addr = 192.168.20.11

[mon.prox3]
         public_addr = 192.168.20.12
Code:

Code: 
root@prox1:~# more /etc/corosync/corosync.conf
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: prox1
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 192.168.66.10
    ring1_addr: 192.168.20.10
  }
  node {
    name: prox2
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 192.168.66.11
    ring1_addr: 192.168.20.11
  }
  node {
    name: prox3
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 192.168.66.12
    ring1_addr: 192.168.20.12
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: PrxClu
  config_version: 3
  interface {
    linknumber: 0
  }
  interface {
    linknumber: 1
  }
  ip_version: ipv4-6
  link_mode: passive
  secauth: on
  version: 2
}
 
Das Cluster Network ist für den Backend Traffic von Ceph zwischen den OSDs. Das Client Network ist für den Storagezugriff der VMs auf den Ceph Cluster. Somit geht der Storagezugriff über dein normales LAN.
 
Falk R. said:
Das Cluster Network ist für den Backend Traffic von Ceph zwischen den OSDs. Das Client Network ist für den Storagezugriff der VMs auf den Ceph Cluster. Somit geht der Storagezugriff über dein normales LAN.
Click to expand...
Ja so war der Plan.
Abe irgendwie scheint das nicht zu funktionieren.
der Status vom Ceph wird nie grün, ständig stehen delays von mehreren hundert im log, mal sind osds down, mal sind alle up,
aber der Status wird nie grün .
und der Traffic auf dem Switch sind nur ein paar Pakete in de n~66.x und ~88.x Netzwerken, im normalen VM Netzwerk sind es mehrere Millionen
Und wirklich Arbeit hat das System noch nicht. Da läuft ein HomeAssistant, ein paperless, ein mqtt
 
Du nutzt ja auch das 192.168.20.x Netzwerk für Ceph.
Steht so in deiner Konfiguration.
Was für SSDs benutzt du denn für Ceph?
 
gefinke said:
je eine 2TB Sata III (Verbatim)
Click to expand...
Die wird das ganze auch noch zusätzlich bremsen. Bring erst einmal das Netzwerk in Ordnung und wenn die Latenzen bleiben, kann die SSD einfach nicht mehr.
 
Falk R. said:
Die wird das ganze auch noch zusätzlich bremsen. Bring erst einmal das Netzwerk in Ordnung und wenn die Latenzen bleiben, kann die SSD einfach nicht mehr.
Click to expand...
was genau meinst Du mit Netzwerk in Ordnung bringen ? Was ist denn falsch ? Irgendwie hab ich dich nicht verstanden.

Du schreibst, "Das Cluster Network ist für den Backend Traffic von Ceph zwischen den OSDs." so hatte ich das auch verstanden.
Aber gerade dieses Netzwek hat fast keinen sichbaren traffik, und das scheint die Latenzen zu erzeugen. Aber wie bekomme ich das weg ?
 
Dann lese mal Beitrag 6 und guck dir deine Konfiguration mal an.
 
Die Latenzen können von den SSDs kommen oder das Netzwerk ist nicht sauber.
Hast du mal mit iperf getestet ob du volle Bandbreite bekommst?
 
sehr merkwürdig :(
(iperf kannte ich noch nicht)
im ~20.x netz ist alles schick .
im ~66.x und im 88.x bekomme ich unterschiedlichste Ergebnisse von 'connection refused', 70MByte/s. bis 950MByte/s
(ja, das sind 1 gigabitkarten, ist ja auch nur für kleine Dinge, die man so zu Hause braucht :) )

Das passiert auch wenn ich einen andren (unmanaged) Switch nehme .

Deswegen ist das ja auch meine Ausgangsfrage,
Das das ceph dann nicht geht ist ja völlig klar.
Kann das sein, dass die DualPort-Karten nicht richtig laufen - wo würde ich da in welchem log was finden ?
 
gefinke said:
sehr merkwürdig :(
(iperf kannte ich noch nicht)
im ~20.x netz ist alles schick .
im ~66.x und im 88.x bekomme ich unterschiedlichste Ergebnisse von 'connection refused', 70MByte/s. bis 950MByte/s
(ja, das sind 1 gigabitkarten, ist ja auch nur für kleine Dinge, die man so zu Hause braucht :) )
Click to expand...
Das ceph unter 10Gbit NICs nicht viel Sinn macht und man schon Enterprise SSDs nehmen sollte hast du vermutlich auch schon gelesen?
https://pve.proxmox.com/wiki/Deploy_Hyper-Converged_Ceph_Cluster said:
For estimating your bandwidth needs, you need to take the performance of your disks into account.. While a single HDD might not saturate a 1 Gb link, multiple HDD OSDs per node can already saturate 10 Gbps too. If modern NVMe-attached SSDs are used, a single one can already saturate 10 Gbps of bandwidth, or more. For such high-performance setups we recommend at least a 25 Gpbs, while even 40 Gbps or 100+ Gbps might be required to utilize the full performance potential of the underlying disks.
If unsure, we recommend using three (physical) separate networks for high-performance setups: * one very high bandwidth (25+ Gbps) network for Ceph (internal) cluster traffic. * one high bandwidth (10+ Gpbs) network for Ceph (public) traffic between the ceph server and ceph client storage traffic. Depending on your needs this can also be used to host the virtual guest traffic and the VM live-migration traffic. * one medium bandwidth (1 Gbps) exclusive for the latency sensitive corosync cluster communication.
Click to expand...

gefinke said:
Kann das sein, dass die DualPort-Karten nicht richtig laufen - wo würde ich da in welchem log was finden ?
Click to expand...
Syslog/journald
 
Last edited:
  • Like
Reactions: pakuzaz
OK, die logs sind voll von Fehlern mit den Netzkarten RTL8111E Chipsatz wird als 8169 erkannt.
Hab gelesen, dass es seit Version 8 viele Probleme damit gibt.

Da schau ich mal, ob ich was anderes finde oder die beschrieben Fixes versuche.
 
  • Like
Reactions: Falk R.
You must log in or register to reply here.
Top Bottom