vLAN Free Interfaces verlieren Verbindung

  • Hallo,


    Ich betreibe auf zwei Root Servern, die mittels netcup vLAN verbunden sind, ein kleines Cluster. Hierbei habe ich täglich das Problem, dass sich das Cluster irgendwann verabschiedet und nicht mehr erreichbar ist. Als Ursache konnte ich heute folgendes ausmachen: Die vLAN Interfaces verlieren an zufälligen Zeitpunkten kurzzeitig die Verbindung zueinander (statische IPs), was das Cluster in einen inkonsistenten Zustand befördert, da Ressourcen unnötig und nur halb migriert werden, bis die Verbindung wiederhergestellt ist.


    Ist eine solche Service-Unterbrechung bei netcups vLAN zu erwarten (Feature) oder handelt es sich um einen Bug? Sollte es ein Feature sein, kann ich dann wenigstens davon ausgehen, dass die externen Netzwerkinterfaces stabil laufen? In dem Fall würde ich das vLAN durch einen Server-zu-Server Tunnel ersetzen können.


    OS: CentOS 8 minimal

    vLAN: Free 100 mbit

    Hosts: RS500 (2 CPUs, 4 GB RAM, 240 GB SAS)


    Grüße


    Anbei noch der Auszug aus den Logs, der das Problem veranschaulicht:


    Dec 14 09:00:04 mx1 corosync[1329]: [KNET ] link: host: 2 link: 0 is down

    Dec 14 09:00:04 mx1 corosync[1329]: [KNET ] host: host: 2 (passive) best link: 0 (pri: 1)

    Dec 14 09:00:04 mx1 corosync[1329]: [KNET ] host: host: 2 has no active links

    Dec 14 09:00:04 mx1 corosync[1329]: [TOTEM ] Token has not been received in 273 ms

    Dec 14 09:00:04 mx1 corosync[1329]: [TOTEM ] A processor failed, forming new configuration.

    Dec 14 09:00:05 mx1 corosync[1329]: [TOTEM ] A new membership (1:128) was formed. Members left: 2

    Dec 14 09:00:05 mx1 corosync[1329]: [TOTEM ] Failed to receive the leave message. failed: 2

    Dec 14 09:00:05 mx1 corosync[1329]: [CPG ] downlist left_list: 1 received

    Dec 14 09:00:05 mx1 corosync[1329]: [QUORUM] Members[1]: 1

    Dec 14 09:00:05 mx1 corosync[1329]: [MAIN ] Completed service synchronization, ready to provide service.

    Dec 14 09:00:05 mx1 pacemaker-attrd[1591]: notice: Lost attribute writer mx2-cr

    Dec 14 09:00:05 mx1 pacemakerd[1518]: notice: Node mx2-cr state is now lost

    Dec 14 09:00:05 mx1 pacemaker-fenced[1589]: notice: Node mx2-cr state is now lost

    Dec 14 09:00:05 mx1 pacemaker-based[1588]: notice: Node mx2-cr state is now lost

    Dec 14 09:00:05 mx1 pacemaker-based[1588]: notice: Purged 1 peer with id=2 and/or uname=mx2-cr from the membership cache

    Dec 14 09:00:05 mx1 pacemaker-attrd[1591]: notice: Node mx2-cr state is now lost

    Dec 14 09:00:05 mx1 pacemaker-attrd[1591]: notice: Removing all mx2-cr attributes for peer loss

    Dec 14 09:00:05 mx1 pacemaker-attrd[1591]: notice: Purged 1 peer with id=2 and/or uname=mx2-cr from the membership cache

    Dec 14 09:00:05 mx1 pacemaker-attrd[1591]: notice: Recorded local node as attribute writer (was unset)

    Dec 14 09:00:05 mx1 pacemaker-controld[1593]: notice: Node mx2-cr state is now lost

    Dec 14 09:00:05 mx1 pacemaker-controld[1593]: warning: Our DC node (mx2-cr) left the cluster

    Dec 14 09:00:05 mx1 pacemaker-fenced[1589]: notice: Purged 1 peer with id=2 and/or uname=mx2-cr from the membership cache

    Dec 14 09:00:05 mx1 pacemaker-controld[1593]: notice: State transition S_NOT_DC -> S_ELECTION

    Dec 14 09:00:05 mx1 pacemaker-controld[1593]: notice: State transition S_ELECTION -> S_INTEGRATION

    Dec 14 09:00:06 mx1 pacemaker-schedulerd[1592]: notice: On loss of quorum: Ignore

    Dec 14 09:00:06 mx1 pacemaker-schedulerd[1592]: notice: Calculated transition 2, saving inputs in /var/lib/pacemaker/pengine/pe-input-226.bz2

    Dec 14 09:00:06 mx1 pacemaker-controld[1593]: notice: Transition 2 (Complete=0, Pending=0, Fired=0, Skipped=0, Incomplete=0, Source=/var/lib/pacemaker/pengine/pe-input-226.bz2): Complete

    Dec 14 09:00:06 mx1 pacemaker-controld[1593]: notice: State transition S_TRANSITION_ENGINE -> S_IDLE

    Dec 14 09:00:07 mx1 kernel: drbd bst mx2: PingAck did not arrive in time.

    Dec 14 09:00:07 mx1 kernel: drbd git mx2: PingAck did not arrive in time.

    Dec 14 09:00:07 mx1 kernel: drbd bst mx2: conn( Connected -> NetworkFailure ) peer( Secondary -> Unknown )

    Dec 14 09:00:07 mx1 kernel: drbd bst/0 drbd8 mx2: pdsk( UpToDate -> DUnknown ) repl( Established -> Off )

    Dec 14 09:00:07 mx1 kernel: drbd git mx2: conn( Connected -> NetworkFailure ) peer( Secondary -> Unknown )

    Dec 14 09:00:07 mx1 kernel: drbd git/0 drbd1 mx2: pdsk( UpToDate -> DUnknown ) repl( Established -> Off )

    Dec 14 09:00:07 mx1 kernel: drbd git mx2: ack_receiver terminated

    Dec 14 09:00:07 mx1 kernel: drbd git mx2: Terminating ack_recv thread

    Dec 14 09:00:07 mx1 kernel: drbd bst mx2: ack_receiver terminated

    Dec 14 09:00:07 mx1 kernel: drbd bst mx2: Terminating ack_recv thread

    Dec 14 09:00:07 mx1 kernel: drbd git mx2: Aborting remote state change 0 commit not possible

    Dec 14 09:00:07 mx1 kernel: drbd bst mx2: Aborting remote state change 0 commit not possible

    Dec 14 09:00:07 mx1 kernel: drbd bst mx2: Restarting sender thread

    Dec 14 09:00:07 mx1 kernel: drbd git mx2: Restarting sender thread

    Dec 14 09:00:07 mx1 kernel: drbd git mx2: Connection closed

    Dec 14 09:00:07 mx1 kernel: drbd bst mx2: Connection closed

    Dec 14 09:00:07 mx1 kernel: drbd git mx2: conn( NetworkFailure -> Unconnected )

    Dec 14 09:00:07 mx1 kernel: drbd bst mx2: conn( NetworkFailure -> Unconnected )

    Dec 14 09:00:07 mx1 kernel: drbd git mx2: Restarting receiver thread

    Dec 14 09:00:07 mx1 kernel: drbd bst mx2: Restarting receiver thread

    Dec 14 09:00:07 mx1 kernel: drbd git mx2: conn( Unconnected -> Connecting )

    Dec 14 09:00:07 mx1 kernel: drbd bst mx2: conn( Unconnected -> Connecting )

  • Deine Logs zeigen zwar die Ausfälle, aber zur Ursachenforschung tragen sie nur wenig bei.


    Was hier oft gefragt wird, ist, ob der Fehler etwa auch im Rettungssystem auftritt?

    https://www.netcup-wiki.de/wiki/Rettungssystem


    Auch wäre zu klären, ob der Ausfall IPv4 oder IPv6 betrifft.

    Bei IPv6 wären bitte die sysctl-settings, wie sie u.a. auch in https://www.netcup-wiki.de/wik…_IP_Adresse_konfigurieren deklariert sind, zu beachten:

    Code
    net.ipv6.conf.default.accept_ra=0
    net.ipv6.conf.default.autoconf=0
    net.ipv6.conf.all.accept_ra=0
    net.ipv6.conf.all.autoconf=0
    net.ipv6.conf.eth0.accept_ra=0
    net.ipv6.conf.eth0.autoconf=0


    Bei IPv4 sollte freilich nur ein Gateway für die defaultroute eingetragen sein - keine Ahnung, ob das in Deiner Konfiguration so ist. Pardon, wenn ich frage.


    Technisch wird VLAN bei netcup über VxLAN realisiert. D.h. über UPD-Pakete. https://de.wikipedia.org/wiki/Virtual_Extensible_LAN

    Im Grunde kann es da schon einmal kurze Aussetzer geben.


    Tritt generell zwischen Deinen RS Paketverlust auf?

  • eripek


    Danke für deine Antwort, ich liefere gerne mehr Daten so ich denn kann.


    • IPv6 ist auf meinen Servern dauerhaft deaktiviert, der Ausfall betrifft also allein IPv4
    • Die IPv4 Route scheint auf den ersten Blick in Ordnung zu sein:
    Code
    [root@mx2 ~]# ip route show
    default via 37.120.184.1 dev ens3 proto dhcp metric 100 
    37.120.184.0/22 dev ens3 proto kernel scope link src 37.120.187.52 metric 100 
    172.16.0.0/16 dev ens6 proto kernel scope link src 172.16.12.11 metric 101


    • Generell Paketverlust zwischen den RS würde ich das nicht nennen:
    Code
    [root@mx2 ~]# netstat -s | grep segments
        1062841 segments received
        744342 segments sent out
        104 segments retransmitted
        0 bad segments received


    Hier das Rettungssystem zu starten halte ich für nicht zielführend. Einerseits treten diese Ausfälle sporadisch ohne festes Muster auf und ich kann sie nicht provozieren, andererseits läge solange das Rettungssystem läuft keine Last auf der Verbindung, was das "beobachten" des Problems unmöglich macht.

  • Ich habe jetzt zwei gleichermaßen schlechte Workarounds für das Problem gefunden, wurde aber im CentOS IRC Chat darauf hingewiesen, dass es sich hier eindeutig um ein Problem auf Seiten von Netcup handelt, da ich über die vNICs keine Kontrolle habe.


    Möglichkeit 1:

    SUSE Dokumentation zu DRBD Resource-Level fencing


    Hier blockt DRBD in dem Fall, dass der Replikation Link down ist, die Migration von Ressourcen und gibt diese erst wieder frei, sobald der Link wieder online und eine automatische Replikation durchgelaufen ist.


    Pro:

    • Pacemaker migriert keine Ressourcen vom aktuellen Master weg, alle Dienste bleiben erreichbar

    Con:

    • Ein kompletter Node Failure vom Master stoppt sämtliche Dienste bis alle Nodes wieder online und synchron sind. Hochverfügbarkeit hat sich damit effektiv erledigt.


    Möglichkeit 2:

    DRBD timeouts anpassen


    Getestet habe ich bisher folgendes:

    Code
    common {
      net {
            connect-int 15;
            ping-int 15;
            ping-timeout 30;
            timeout 100;
      }
    }


    Pro:

    • Ein kompletter Node Failure zieht sämtliche Ressourcen von Node1 auf Node2 um, alle Dienste bleiben erreichbar
    • Ein Timeout im vLAN startet nach ein paar Sekunden zwar eine Migration, beendet diese aber und rollt sie automatisch wieder zurück, sobald der Link wieder online ist

    Con:

    • Nach einem Node Recovery läuft die Re-Migration automatisch an, wird aber nicht fehlerfrei beendet und bedarf manueller Intervention
    • Anpassungen an den Timeouts sind nach oben begrenzt. Bisher ist diese Lösung nur bei Link Downtimes von < 5 Sekunden "stabil"
  • Ich habe jetzt zwei gleichermaßen schlechte Workarounds für das Problem gefunden, wurde aber im CentOS IRC Chat darauf hingewiesen, dass es sich hier eindeutig um ein Problem auf Seiten von Netcup handelt, da ich über die vNICs keine Kontrolle habe.

    Inwiefern spielt das eine Rolle? Hat man über virtuelle NICs denn jemals irgendwo die Kontrolle?

    Das Beste, was Du tun kannst, ist, den virtio-Treiber zu verwenden.

    Passend zur Bandbreite (100mbit/s im Fall von cloud vlan free) wäre es gut, die queuelen zu prüfen und zu setzen. (1000?)


    Wie bereits erläutert, ist das Cloud VLAN bei netcup auf VxLAN basierend. UDP kann nun einmal im Gegensatz zu TCP Pakete verlieren.

    DRBD selbst lässt darüber TCP oder ein TCP-ähnliches Protokoll laufen (siehe drdb 9 manual). Eigentlich müsste das das Problem kompensieren.

  • Den virtio Treiber nutze ich bereits und gemessen am Output von ifconfig ist die queue lenght auch korrekt

    Code
    [root@mx1 ~]# ifconfig ens6
    ens6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 172.16.12.10  netmask 255.255.0.0  broadcast 172.16.255.255
            inet6 fe80::9ca0:19ea:e7ce:97ae  prefixlen 64  scopeid 0x20<link>
            ether ba:75:dc:8c:f1:81  txqueuelen 1000  (Ethernet)
            RX packets 579046  bytes 1062994030 (1013.7 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 574493  bytes 910653981 (868.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


    Folgender Gedankensprung geht an mir leider vorbei: "Eigentlich müsste das das Problem kompensieren". Könntest Du hier bitte ein bisschen genauer ausführen, inwiefern die queue lenght dieses TCP-over-UDP Problem lösen sollte? Danke!

  • Folgender Gedankensprung geht an mir leider vorbei: "Eigentlich müsste das das Problem kompensieren". Könntest Du hier bitte ein bisschen genauer ausführen, inwiefern die queue lenght dieses TCP-over-UDP Problem lösen sollte? Danke!

    Das bezog sich auf DRBD und sein Replikationsprotokoll laut DRBD9-Manual.


    Das mit der Txqueue war eine andere Überlegung - nämlich die, dass der Virtio-Adapter Gigabit-Ethernet zur Verfügung stellt, aber für das VxLAN (auf Basis von UDP) Shaping für das Cloud vlan free (100 Mbit/s) irgendwo greifen muss. Die Überlegung daraus wäre, dass die txqueuelen eventuell zu gross ist, und die Lags mit dem Shaping (=Pakete verwerfen) zu tun hätten, oder, dass eventuell eine Form von Bufferbloat hier mitspielt. Reine Mutmaßungen meinerseits. Eventuell hilfreiche Lektüre am Rande: https://www.bufferbloat.net/projects/bloat/wiki/Linux_Tips/