Beiträge von rbrt.mrz

Wenn es sich um das VLAN Produkt handelt, mit dem man auch die vServer bei NC verbinden kann, dann musst du das im Server Control Panel erst einstellen. Ich hab mal vom VLAN Free auf das VLAN 1 GBps geupgradet und dafür ein neues VLAN im Control Panel angezeigt bekommen. Das muss dann entsprechend auch auf dem NC vServer eingebunden und eingerichtet werden.

Zitat von eripek

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.

Alles anzeigen

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

[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!

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:

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"

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:

[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:

[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.

lindesbs

Hast du das Problem hier irgendwie lösen können? Ich habe bei zwei mittels vLAN Free verbundenen Nodes das Problem, dass die Verbindung unregelmäßig und spontan abschmiert und damit mein ganzes Cluster beeinträchtigt.

Grüße

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 )

[netcup] Felix P.

Hallo,

Entgegen der Darstellung in einigen Beiträgen hier sollen meine beiden RS 500 (selbes Produkt) in einem sich überschneidenden Zeitfenster neu gestartet werden. Ironischerweise habe ich tatsächlich vor, beide zu einem Cluster zusammenzuschalten, was in diesem Fall aber leider nicht helfen wird. Die Server IDs kann ich bei Bedarf gerne mitteilen, die beiden Zeitfenster sind:

29.07.2019 16:40 - 18:40 CEST

29.07.2019 17:20 - 19:20 CEST

Was wird netcup unternehmen, damit nicht beide Server gleichzeitig down gehen und werde ich entsprechend informiert, wann welcher Server nicht mehr erreichbar sein wird?

Freundliche Grüße,

Robert Maerz