[Nearly SOLVED] Seperates corosync Netzwerk - nachträgliche Definition

[grefabu]

Moin,

ich baue einen Cluster aus drei Knoten auf.

Die Knoten haben jeweils 4 GBit Karten8bzw. Ports) und jeweils zwei 10Bit Karten mit 2 Ports.
Aufgesetzt habe ich die Knoten über das GBit Interface, den Cluster habe ich auch darüber aufgebaut.

Die Verbindung zwischen den Knoten über die 10GBit Karten habe ich per iperf gemessen, die 10GBit kommen auch an.

Über den WikiEintrag https://pve.proxmox.com/wiki/Separate_Cluster_Network habe ich das Cluster Netzwerk separiert, alle Knoten neu gestartet.
pvecm --status sieht gut aus.

Wenn ich jetzt aber eine Migration von einem Knoten auf den anderen starte, scheint es, als würde alles über die GBit Schnittstelle übertragen?
Jedenfalls schließe ich das mittels eines iftop -i en01. auf den 10GBit Karten habe ich so gut wie keine Auslastung.

Oder verstehe ich da etwas nicht richtig, werden die Mschinen nicht über das Clusternetzwerk migriert?

Anbei noch meine corosync.conf:

root@ph-pve004:~# cat /etc/pve/corosync.conf 
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: ph-pve004
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.0.55.41
  }
  node {
    name: ph-pve005
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.0.55.42
  }
  node {
    name: ph-pve006
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 10.0.55.43
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: ph-pvecluster2
  config_version: 5
  interface {
    bindnetaddr: 10.0.55.0
    linknumber: 0
  }
  ip_version: ipv4-6
  secauth: on
  version: 2
}

die Ausgabe von ip a auf einem Knoten:

root@ph-pve004:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether 94:57:a5:5a:e6:9c brd ff:ff:ff:ff:ff:ff
3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 94:57:a5:5a:e6:9d brd ff:ff:ff:ff:ff:ff
4: eno3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 94:57:a5:5a:e6:9e brd ff:ff:ff:ff:ff:ff
5: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 94:57:a5:5a:e6:9f brd ff:ff:ff:ff:ff:ff
6: bcm10Gp1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 94:57:a5:67:b3:a0 brd ff:ff:ff:ff:ff:ff
    inet 10.0.55.41/24 scope global bcm10Gp1
       valid_lft forever preferred_lft forever
    inet6 fe80::9657:a5ff:fe67:b3a0/64 scope link 
       valid_lft forever preferred_lft forever
7: bcm10Gp2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 94:57:a5:67:b3:a4 brd ff:ff:ff:ff:ff:ff
8: mlx10Gp1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:02:c9:19:7c:a0 brd ff:ff:ff:ff:ff:ff
    inet 10.0.45.41/24 scope global mlx10Gp1
       valid_lft forever preferred_lft forever
    inet6 fe80::202:c9ff:fe19:7ca0/64 scope link 
       valid_lft forever preferred_lft forever
9: mlx10Gp2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:02:c9:19:7c:a1 brd ff:ff:ff:ff:ff:ff
10: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 94:57:a5:5a:e6:9c brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.41/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::9657:a5ff:fe5a:e69c/64 scope link 
       valid_lft forever preferred_lft forever

Und noch die hosts Datei:

root@ph-pve004:~# cat /etc/hosts
127.0.0.1       localhost
10.0.1.41       ph-pve004.peiker-holding.de     ph-pve004

 

[t.lamprecht]

Hi,

Oder verstehe ich da etwas nicht richtig, werden die Mschinen nicht über das Clusternetzwerk migriert?

Nein, übers Cluster Netzwerk läuft der corosync traffic. Das Migrationsnetzwerk kann man separat setzen.
Einfach unter Datacenter → Optionen → Migrations Einstellungen das entsprechende Netzwerk auswählen.

 

[grefabu]

Moin,

danke wer lesen und Suchen kann ist klar im Vorteil,...
Vielleicht noch eine Frage nach der Priorität der Netzwerke bzw. dem Anspruch an Performance:

Ich habe wie gesagt 4x Gbit und 4x 10GBit.

Über die 10GBit Karten wollte die Corosync/Migration und CEPH betreiben, jeweils über ein Bond zur Ausfallsicherheit.

Wenn die Migration nicht über das corosync läuft, wäre es in meinen Augen Ausreichend für das corosync Netzwerk eine GBit Verbindung (ebenfalls redundant) aufzubauen, corosync bewegt ja nicht viel Daten sondern hat nur Ansprüche an die Latenz?

Grüße

Gregor

 

[t.lamprecht]

Wenn die Migration nicht über das corosync läuft, wäre es in meinen Augen Ausreichend für das corosync Netzwerk eine GBit Verbindung (ebenfalls redundant) aufzubauen, corosync bewegt ja nicht viel Daten sondern hat nur Ansprüche an die Latenz?

Genau, und meiner Meinung nach nicht nur ausreichend, sondern empfehlenswert. Generell sollte es vermieden werden corosync über das selbe Netzwerk wie Storage traffic (ceph) aufzusetzen, wenn dann nur als "fallback". Denn diese Art von Traffic beeinträchtigt Latenz kritische Anwendungen meist stark. Meistens wäre es besser ein 100MB/s link alleinig für corosync zu haben als 10G/s (oder mehr) zusammen mit ceph. Wird zwar meistens bei normallast funktionieren, aber genau in Problem situationen (OSD oder gar Host fällt aus) steigt der ceph Traffic zum rebalancen stark und bringt dann corosync ins schwanken.