[SOLVED] Bonding lässt Node nicht mehr mit Cluster kommunizieren (Corosync.conf Fehler?)

[NexorProject]

Guten Tag Zusammen

Also ich habe ein ziemlich merkwürdiges Problem, das ich nicht so recht nachvollziehen kann, da ich das Bonding mehr oder weniger direkt nach dem von Proxmox gestellten Tutorial gemacht habe.

Also hier mein Setup:
ich habe 4 Nodes mit je 4 NICs. Eine davon ist für die Linux Bridge für die VMs vmbr0. So war das Cluster bis vor kurzem Konfiguriert und lauffähig. Nun habe ich zum Testing von Migrationsgeschwindigkeit von VMs Ceph installiert und wollte diesem ein Netzwerk Bond geben, um den höheren Durchsatz nutzen zu können. Dafür habe ich zwei weitere NICs an unseren Switch angeschlossen und ein Bond mit einer Statischen nicht vergebenen IP-Adresse vergeben. (Ceph lief davor übrigens ebenfalls ohne Probleme über die Standard NIC welche auch Proxmox und die VMs als Bridge verwenden). Nun egal welchen Bond-Modus ich verwende, die Node ist nach Neustart nicht mehr im Cluster registriert (no quorum), ist jedoch übers Web GUI Ansprechbar und pingbar auf die alte NIC und die Bond-IP-Adresse. Jedoch wird sie im restlichen Cluster als Offline angezeigt und ich kann keine VMs starten (aufgrund der "no quorum" Fehlermeldung, was meiner Erfahrung nach bedeutet, das die Node sich nicht korrekt am Cluster anmelden konnte).

Woran kann das liegen? Die IP-Adresse sind 100% nicht im Konflikt mit anderen IP-Adressen und wenn ich das Bond wieder deaktiviere, registriert sich die Node wieder Normal im Cluster mit allen Funktionalitäten.

Hier noch ein Auszug aus meiner /etc/network/interfaces einer Node mit aktiven Bond:

Spoiler: /etc/network/interfaces

auto lo
iface lo inet loopback

iface eno1 inet manual

iface eno2 inet manual

iface eno3 inet manual

iface eno4 inet manual

auto bond0
iface bond0 inet static
        address  192.168.203.46
        netmask  255.255.255.0
        gateway  192.168.203.3
        bond-slaves eno2 eno3
        bond-miimon 100
        bond-mode balance-rr

auto vmbr0
iface vmbr0 inet dhcp
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
#address 192.168.100.2
#netmask 255.255.255.0
#gateway 192.168.100.1

auto vmbr1
iface vmbr1 inet static
        address  192.168.123.1
        netmask  255.255.255.0
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        network  192.168.123.0
        post-up /sbin/iptables -t nat -A POSTROUTING -o vmbr0 -j MASQUERADE
        pre-down /sbin/iptables -t nat -D POSTROUTING -o vmbr0 -j MASQUERADE

(Hinweis: Ja die vmbr1 ist aus Absicht an keinem Port angeschlossen).

EDIT: Okay, es scheint zu funktionieren, wenn ich eno1 Port von vmbr0 entferne, eno1 dem bond0 zuweise und bond0 dann als Port zu vmbr0 hinzufüge. Jedoch hätte ich gerne eine getrennte Leitung vom Proxmox sowie Service verkehr und dem Ceph-Cluster, ist es nicht Möglich mehrere NICs unter verschiedenen Anforderungen parallel zu haben (Wie in meinem ersten Setup)?

EDIT2: Also ich bin jetzt schon mal soweit das ich weiss das etwas mit der corosync.conf nicht stimmt jedoch nicht was. Wenn ich meine Konfiguration verwende kann corosync nicht booten, "systemctl status corosync.service" spuckt folgenden Fehler aus:

 corosync.service - Corosync Cluster Engine
   Loaded: loaded (/lib/systemd/system/corosync.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2018-11-19 16:15:39 CET; 8s ago
     Docs: man:corosync
           man:corosync.conf
           man:corosync_overview
  Process: 4382 ExecStart=/usr/sbin/corosync -f $COROSYNC_OPTIONS (code=exited, status=20)
 Main PID: 4382 (code=exited, status=20)
      CPU: 99ms

Nov 19 16:15:39 test corosync[4382]: info    [WD    ] no resources configured.
Nov 19 16:15:39 test corosync[4382]: notice  [SERV  ] Service engine loaded: corosync watchdog service [7]
Nov 19 16:15:39 test corosync[4382]: notice  [QUORUM] Using quorum provider corosync_votequorum
Nov 19 16:15:39 test corosync[4382]: crit    [QUORUM] Quorum provider: corosync_votequorum failed to initialize.
Nov 19 16:15:39 test corosync[4382]: error   [SERV  ] Service engine 'corosync_quorum' failed to load for reason 'configuration error: nodelist or quorum.expected_vo
Nov 19 16:15:39 test corosync[4382]: error   [MAIN  ] Corosync Cluster Engine exiting with status 20 at service.c:356.
Nov 19 16:15:39 test systemd[1]: corosync.service: Main process exited, code=exited, status=20/n/a
Nov 19 16:15:39 test systemd[1]: Failed to start Corosync Cluster Engine.
Nov 19 16:15:39 test systemd[1]: corosync.service: Unit entered failed state.
Nov 19 16:15:39 test systemd[1]: corosync.service: Failed with result 'exit-code'.

Meine corosync.conf sieht folgendermassen aus:

Spoiler: corosync.conf

logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: backup
    nodeid: 4
    quorum_votes: 1
    ring0_addr: 192.168.203.189
  }
  node {
    name: clients
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 192.168.203.39
  }
  node {
    name: server
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 192.168.203.190
  }
  node {
    name: test
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 192.168.203.159
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: SANTIS
  config_version: 4
  interface {
    bindnetaddr: 192.168.203.0
    ringnumber: 0
  }
  ip_version: ipv4
  secauth: on
  version: 2
}

Die IP-Adressen und die bindnetaddr scheinen unserem Netzwerk und den einzelnen Nodes zu entsprechen. Jemand eine Idee? Ausserdem finde ich nicht wirklich etwas zum Status 20 als exit-code über Google.

EDIT 3: Problem gelöst. Es scheint ein bekannter Fehler zu sein siehe: https://bugs.launchpad.net/fuel/+bug/1546947. Das ganze lässt sich beheben in dem man über den bond0 eine vmbr legt und die IP-Adresse der neuen vmbr-Schnittstelle zuweist anstelle des bond0-Anschlusses (Zu beachten ist, das der bond0 nicht auf Autostart gesetzt wird, dafür jedoch die vmbr).

Freundliche Grüsse
NexorProject

 

[Ingo S]

Wir haben einen 8 Node Cluster, mit getrennten Netzen (VLAN!) für Corosync, LAN der VM's und Ceph. Corosync und Ceph laufen rein über ein bond interface, damit haben wir keinerlei Probleme.

Spoiler: /etc/network/interfaces

# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage part of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT 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 ens3f1 inet manual
#Client Access (Trunk)

iface enp3s0f0 inet manual
#Corosync (VLAN116) (active)

iface ens3f0 inet manual
#Ceph (VLAN115)

iface enp3s0f1 inet manual
#Corosync (VLAN116) (backup)

iface ens6f0 inet manual

iface ens6f1 inet manual

iface ens6f2 inet manual

iface ens6f3 inet manual

auto bond0
iface bond0 inet manual
slaves ens3f1
bond_miimon 100
bond_mode active-backup
#Client Access (Trunk)

auto bond2
iface bond2 inet static
address 192.168.15.2
netmask 255.255.255.0
slaves ens3f0
bond_miimon 100
bond_mode active-backup
#Ceph (VLAN115)

auto bond1
iface bond1 inet static
address 192.168.16.2
netmask 255.255.255.0
slaves enp3s0f0
bond_miimon 100
bond_mode active-backup
#Corosync (VLAN116)

auto vmbr0
iface vmbr0 inet static
address 192.168.1.4
netmask 255.255.255.0
gateway 192.168.1.254
bridge_ports bond0
bridge_stp off
bridge_fd 0
bridge_vlan_aware yes
#Client Access (Trunk)

Ich vermute die Ursache eher darin, dass aus irgendeinem Grund das Multicasting nicht mehr funktioniert, wenn du das Bonding nutzt. Corosync ist explizit auf Multicasting angewiesen. Wenn da durch das bonding der Querier verschwindet, bricht dir dein Multicast Netz weg.

Es ist definitiv nicht zwingend nötig, eine vmbr Bridge zu haben über das das Corosync läuft.
(PVE 5.2-2)