Probleme beim wechseln von Ceph IPs/Subnet

[t0mc@]

Hallo zusammen,

wir betreiben einen Proxmox VE (8.1.4) / Ceph (18.2.1) Cluster bestehend aus 3 Nodes. Die aktuelle Ceph Config sieht so aus:

[global]
     auth_client_required = none
     auth_cluster_required = none
     auth_service_required = none
     cephx_sign_messages = false
     cluster_network = 172.20.82.0/24
     debug_asok = 0/0
     debug_auth = 0/0
     debug_buffer = 0/0
     debug_client = 0/0
     debug_context = 0/0
     debug_crush = 0/0
     debug_filer = 0/0
     debug_filestore = 0/0
     debug_finisher = 0/0
     debug_heartbeatmap = 0/0
     debug_journal = 0/0
     debug_journaler = 0/0
     debug_lockdep = 0/0
     debug_mds = 0/0
     debug_mds_balancer = 0/0
     debug_mds_locker = 0/0
     debug_mds_log = 0/0
     debug_mds_log_expire = 0/0
     debug_mds_migrator = 0/0
     debug_mon = 0/0
     debug_monc = 0/0
     debug_ms = 0/0
     debug_objclass = 0/0
     debug_objectcacher = 0/0
     debug_objecter = 0/0
     debug_optracker = 0/0
     debug_osd = 0/0
     debug_paxos = 0/0
     debug_perfcounter = 0/0
     debug_rados = 0/0
     debug_rbd = 0/0
     debug_rgw = 0/0
     debug_throttle = 0/0
     debug_timer = 0/0
     debug_tp = 0/0
     fsid = cd3e4269-8080-4a18-a7fa-e309fb6cebbd
     mon_allow_pool_delete = true
     mon_host = 172.20.82.12 172.20.82.11 172.20.82.13
     ms_bind_ipv4 = true
     ms_bind_ipv6 = false
     osd_pool_default_min_size = 2
     osd_pool_default_size = 3
     public_network = 172.20.82.0/24

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

[mds]
     keyring = /var/lib/ceph/mds/ceph-$id/keyring

[mds.edvdehq09001]
     host = edvdehq09001
     mds_standby_for_name = pve

[mds.edvdehq09002]
     host = edvdehq09002
     mds_standby_for_name = pve

[mds.edvdehq09003]
     host = edvdehq09003
     mds_standby_for_name = pve

[mon.edvdehq09001]
     public_addr = 172.20.82.11

[mon.edvdehq09002]
     public_addr = 172.20.82.12

[mon.edvdehq09003]
     public_addr = 172.20.82.13

Ceph funktioniert einwandfrei, wie man auch in der Proxmox GUI sehen kann:




Jetzt müssen wir das Subnetz, in dem der komplette Ceph Traffic läuft, von 172.20.82.0/24 auf 172.20.81.0/24 ändern.

Laut diesem Forum Post ist das ja eigentlich simpel duch ändern der entsprechenden IPs in der /etc/pve/ceph.conf möglich:
https://forum.proxmox.com/threads/how-to-change-ceph-cluster-and-network-ip.96524/

Aber wenn wir das machen (sprich in der config, alle .82 Einträge zu .81 ändern), sieht das sofort in der Proxmox GUI nicht mehr so gut aus.

1.) Alle Monitore haben den Status "unknown":


2.) Die Manager sind gar nicht mehr da:


3.) Die Ceph - Config Seite funktioniert nicht mehr:


4.) Der pvestatd Dienst wirft diese Fehler:


Ein Reboot aller drei PVE Nodes verändert nichts.
BTW: das Ceph Log selber sieht während der ganzen Zeit eigentlich ganz normal aus, so als ob Ceph an sich funktioniert.


Wenn wir die ceph.conf wieder auf das ursprüngliche Netz .82 ändern, ist die Proxmox GUI sofort wieder ok, alles funktioniert.

Daher stellen wir uns jetzt die Frage: Ist das vllt. nur ein Problem in der GUI von Proxmox? Oder müssen wir hier doch noch mehr tun, als nur die ceph.conf anpassen?
Hat jmd. einen Tip?

 

[gurubert]

Die IPs der MONs sind in der Cluster-Map festgelegt. Die IPs, die in der ceph.conf stehen, dienen nur den Clients beim Finden der MONs.

Es müssen erstmal neue MONs mit IPs aus dem neuen Netz ausgerollt werden, bevor die Knoten umnummeriert werden können.

In der Ceph-Dokumentation steht dazu sehr deutlich: "Existing monitors are not supposed to change their IP addresses."

https://docs.ceph.com/en/latest/rados/operations/add-or-rm-mons/#changing-a-monitor-s-ip-address

 

[t0mc@]

Vielen Dank schon mal für den Hinweis.
Wenn ich mir die Ceph Doku diesbzgl. so ansehe, sollte man in diesem Fall also so vorgehen:
1) Hinzufügen neuer Mons mit den neuen IPs
2) Entfernen der alten Mons
3) Anpassen der ceph.conf, damit die clients die neuen mons finden

Über die Proxmox GUI geht das aber schon mal nicht. Wenn man einen neuen Monitor auf einem Node hinzufügen will, schlägt das fehl:



Klar, dieser Monitor existiert ja tatsächlich schon.

Bedeutet das im Umkehrschluß, dass man den Weg aus der allgemeinen Ceph Doku gehen muß, wie hier beschrieben:
https://docs.ceph.com/en/latest/rad...nging-a-monitor-s-ip-address-preferred-method
https://docs.ceph.com/en/latest/rados/operations/add-or-rm-mons/#adding-a-monitor-manual

Kann man das einfach problem- und gefahrlos auch in einem per Proxmox GUI erzeugten Ceph Cluster machen? Oder gibt es doch irgendwie einen "Proxmox - Weg" für diesen Task?

 

[Falk R.]

Ob du das Ceph per GUI oder manuell anlegst ist egal. Halte dich einfach an die offizielle Dokumentation und wenn du fertig bist, sollte die GUI dir wieder korrekt alles anzeigen.
Ich frage mich nur warum muss man denn den IP Kreis wechseln? Das Ceph Netzwerk sollte eh nie geroutet werden und wenn keiner mit dem Netzwerk außer deinen PVE spricht, ist das Subnetz eigentlich egal.

 

[gurubert]

Moment, willst Du nur das Ceph-Cluster-Network ändern?

In Deiner Konfiguration sind momentan public_network = cluster_network = 172.20.82.0/24

Für das Ändern des Cluster-Networks reicht es, nur cluster_network auf 172.20.81.0/24 zu ändern und alle Ceph-Dienste neu zu starten.

Alle Knoten haben Interfaces in beiden Netzen?

 

[t0mc@]

Ob du das Ceph per GUI oder manuell anlegst ist egal. Halte dich einfach an die offizielle Dokumentation und wenn du fertig bist, sollte die GUI dir wieder korrekt alles anzeigen.
Ich frage mich nur warum muss man denn den IP Kreis wechseln? Das Ceph Netzwerk sollte eh nie geroutet werden und wenn keiner mit dem Netzwerk außer deinen PVE spricht, ist das Subnetz eigentlich egal.

Wir müssen an den Servern hardwareseitige Änderungen vornehmen, die das erforderlich machen.

 

[t0mc@]

Moment, willst Du nur das Ceph-Cluster-Network ändern?

In Deiner Konfiguration sind momentan public_network = cluster_network = 172.20.82.0/24

Für das Ändern des Cluster-Networks reicht es, nur cluster_network auf 172.20.81.0/24 zu ändern und alle Ceph-Dienste neu zu starten.

Alle Knoten haben Interfaces in beiden Netzen?

Nein, wir müssen alles, was .82 "heißt" entfernen bzw. auf ein anderes Netz (.81) ändern, nicht nur das cluster_network.

 

[t0mc@]

Und wenn ich die Ceph Doku richtig verstehe, finden sich die mons ja über diese interne monMap, die nicht neu erzeugt wird, wenn man die ceph.conf ändert. Dann dürfte doch das Neustarten der mon-Dienste auch nicht reichen oder? Zumindest haben wir das auch noch versucht, als wir die obige Situation hatten und es hat nicht funktioniert.

 

[Falk R.]

Ich habe soetwas auch noch nie gemacht, da ich den Bedarf noch nie hatte. Hardwareseitige Änderungen haben ja erst einmal mit IP Adressen gar nix zu tun. Eventuell gibt es Unternehmensvorgaben für die Nutzung bestimmter IP Kreise, dass hat aber nix mit Hardware zu tun.
In der Regel gibt man für Ceph einen eigenen ungenutzten IP Kreis und denn kann man ja beliebig über Hardware oder VLANs so verteilen wie man es braucht.
Mir stellt sich immer noch die Frage, müsst ihr euch tatsächlich solche Schmerzen bereiten oder ist das nur Kosmetisch?

 

[t0mc@]

Der Hintergrund ist, dass aus den Servern die Netzwerkkarte raus muß, wo gerade Ceph drüber läuft und daher auf einer anderen, auch schon für andere (kleinere) Dinge genutzte Netzwerkkarte gepackt werden muß, deren IP wir nicht ändern können / sollten. Aber vllt. packen wir auf der einfach die aktuelle 82er IP als virtuelle dazu...

 

[Falk R.]

Der Hintergrund ist, dass aus den Servern die Netzwerkkarte raus muß, wo gerade Ceph drüber läuft und daher auf einer anderen, auch schon für andere (kleinere) Dinge genutzte Netzwerkkarte gepackt werden muß, deren IP wir nicht ändern können / sollten. Aber vllt. packen wir auf der einfach die aktuelle 82er IP als virtuelle dazu...

Das ist mal deutlich sinnvoller und in dem Zuge könnt ihr das eventuell auch gleich in ein extra VLAN packen.

Ich persönlich würde die Ceph Netzwerkkarten niemals für andere Funktionen nutzen. Einzige Ausnahme, als weiterer Corosync Ring.

 

[t0mc@]

Gut, drüber gesprochen zu haben... manchmal kommt man auf bessere Alternativen selbst nicht

Inspiriert von hier: https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server#RSTP_Loop_Setup sind unsere 3 Proxmox Nodes mit 2 Ringen a 40GBit direkt untereinander verkabelt, ein Ring für Proxmox, einer für Ceph.
Für den Uplink bzw. Netwerkverkehr der VMs wurden die 4 Ports (jeweils 1GBit) eines onboard Nics zu einem Bond verbunden, nur diese haben Verbindung zu einem Switch.

Dementsprechend sieht die Netzwerkconfig auf allen drei Nodes aktuell so aus:

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

auto eno3
iface eno3 inet manual

auto eno4
iface eno4 inet manual

auto eno49
iface eno49 inet manual
    ovs_type OVSPort
    ovs_bridge vmbr1
    ovs_mtu 9000
    ovs_options other_config:rstp-port-mcheck=true other_config:rstp-port-admin-edge=false other_config:rstp-port-auto-edge=false vlan_mode=native-untagged other_config:rstp-path-cost=150 other_config:rstp-enable=true

auto eno49d1
iface eno49d1 inet manual
    ovs_type OVSPort
    ovs_bridge vmbr1
    ovs_mtu 9000
    ovs_options vlan_mode=native-untagged other_config:rstp-port-mcheck=true other_config:rstp-port-auto-edge=false other_config:rstp-port-admin-edge=false other_config:rstp-path-cost=150 other_config:rstp-enable=true

auto ens5
iface ens5 inet manual
    ovs_type OVSPort
    ovs_bridge vmbr2
    ovs_mtu 9000
    ovs_options other_config:rstp-port-mcheck=true other_config:rstp-port-admin-edge=false other_config:rstp-port-auto-edge=false vlan_mode=native-untagged other_config:rstp-path-cost=150 other_config:rstp-enable=true

auto ens5d1
iface ens5d1 inet manual
    ovs_type OVSPort
    ovs_bridge vmbr2
    ovs_mtu 9000
    ovs_options other_config:rstp-enable=true other_config:rstp-path-cost=150 vlan_mode=native-untagged other_config:rstp-port-admin-edge=false other_config:rstp-port-auto-edge=false other_config:rstp-port-mcheck=true

auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2 eno3 eno4
    bond-miimon 100
    bond-mode 802.3ad

auto vmbr0
iface vmbr0 inet manual
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
#VLAN1, VLAN2, VLAN4, VLAN5, VLAN10, VLAN11, VLAN99, VLAN100

auto vmbr1
iface vmbr1 inet static
    address 172.20.81.11/24
    ovs_type OVSBridge
    ovs_ports eno49 eno49d1
    ovs_mtu 9000
    up ovs-vsctl set Bridge ${IFACE} rstp_enable=true other_config:rstp-priority=32768 other_config:rstp-forward-delay=4 other_config:rstp-max-age=6
    post-up sleep 10
#Cluster und k8s Netzwerk

auto vmbr2
iface vmbr2 inet static
    address 172.20.82.11/24
    ovs_type OVSBridge
    ovs_ports ens5 ens5d1
    ovs_mtu 9000
    up ovs-vsctl set Bridge ${IFACE} rstp_enable=true other_config:rstp-priority=32768 other_config:rstp-forward-delay=4 other_config:rstp-max-age=6
    post-up sleep 10
#ceph Netzwerk

auto vlan4
iface vlan4 inet static
    address 172.20.4.11/24
    gateway 172.20.4.254
    vlan-raw-device bond0

source /etc/network/interfaces.d/*

Nun müssen wir also die Ports ens59 und ens59d1, demzufolge auch die vmbr2 mit der IP 172.20.82.x, entfernen und wollen die IPs 172.20.82.x mit auf den ersten Ring der eno49 Ports laufen lassen.

Ist es richtig, dass wir dafür "OVSIntPorts" brauchen, die dann die jeweiligen IPs 172.20.81.x und 172.20.82.x bekommen? Müssen wir aufgrund der Ring Topologien irgendwas beachten? Dazu haben wir noch das hier gefunden: https://pve.proxmox.com/wiki/Open_vSwitch

Dort wäre dann doch das "Example 4" dasjenige, was wir benötigen, richtig?

 

[t0mc@]

Hat jmd. ne Idee, ob das in unserem Szenario ein valides Vorgehen wäre?

 

[Falk R.]

Ich habe bisher noch nicht mit OVS gearbeitet. Bei einer klassischen IP Konfiguration gebe ich entweder 2 IPs auf einem Interface oder optimalerweise ein eigenes VLAN.