Verständnisfrage zu gluster, nfs-ganesha und virtualIP

[Geier0815]

Moin Moin,

da ich ceph erst einmal zurück gestellt habe, beschäftige ich mich derzeit intensiv mit GlusterFS und nfs-ganesha-HA.
Dabei bin ich, unter debian testing, jetzt auf ein Problem mit der "virtual IP" in nfs-ganesha gestoßen.
Verwendet werden drei Server, gluster volume als dispersed Volume

Die virtual IP wird in der /run/gluster/shared_storage/nfs-ganesha/ganesha-ha.conf für jeden node angegeben. Ich habe dann per DNS diese IP mit dem Namen des Nodes mit angehängtem vip veröffentlicht und zusätzlich in den /etc/hosts eingetragen. Also aus storage-cluster-10 10.1.120.10 wird dann zusätzlich storage-cluster-10vip 10.1.130.10.

Nach "gluster nfs-ganesha enable" kommt pacemaker auch hoch allerdings mit den Ressourcen

 * Resource Group: storage-cluster-10-group:
    * storage-cluster-10-nfs_block	(ocf::heartbeat:portblock):	 Started storage-cluster-10
    * storage-cluster-10-cluster_ip-1	(ocf::heartbeat:IPaddr):	 Stopped
    * storage-cluster-10-nfs_unblock	(ocf::heartbeat:portblock):	 Stopped

Und dies für alle drei Maschinen.

Des weiteren

Failed Resource Actions:
  * storage-cluster-10-cluster_ip-1_start_0 on storage-cluster-10 'invalid parameter' (2): call=70, status='complete', exitreason='', last-rc-change='2021-05-19 08:16:06 +02:00', queued=0ms, exec=16ms
  * storage-cluster-20-cluster_ip-1_start_0 on storage-cluster-10 'invalid parameter' (2): call=58, status='complete', exitreason='', last-rc-change='2021-05-19 08:16:06 +02:00', queued=0ms, exec=17ms
  * storage-cluster-30-cluster_ip-1_start_0 on storage-cluster-10 'invalid parameter' (2): call=64, status='complete', exitreason='', last-rc-change='2021-05-19 08:16:06 +02:00', queued=0ms, exec=15ms

ebenfalls für alle drei Maschinen.

Grund des Ganzen scheint mir zu sein das die virtellen IPs zwar von pacemaker (laut pcs status) verwurstet werden aber nicht den Netzwerkkarten zugewiesen werden. "ip ad sh" zeigt immer nur die IP 10.1.120.10.

Nun meine Frage: Sollte die virtual IP nicht durch pacemaker bzw nfs-ganesha zusätzlich der Netzwerkkarte zugewiesen werden? Ich also 2 IPs (10.1.120.10 UND 10.1.130.10) sehen können?
Oder hab ich da etwas komplett falsch verstanden und ich muß die IPs noch zusätzlich händisch vergeben, was ja dem Sinn der flooding IP entgegen sprechen würde?

 

[Gräfin Klara]

Meines Wissens wird die "Virtual IP" nur bei Fehler von pacemaker zugeteilt,
wobei der Ausdruck "Virtual" in diesem Zusammenhang irreführend ist.
Das gibt es nicht mehr.

 

[spoensche]

Wie sieht den die PCS Resource Konfiguration im Detail aus? Pacemaker beanstandet ja einen "invalid parameter".

Wird das ein Active/Passive Storage oder Active/Active?

 

[Geier0815]

Es handelt sich um einen Active/Active. Theoretisch läuft der Ganesha-NFS dann auf allen drei Servern. Jeder von denen sollte über die VIP angesprochen werden können und im Fall eines Ausfalls sollte die VIP dann auf einen der zwei verbliebenen Server verschoben werden und damit die NFS-Verbindung erhalten bleiben.
Der pacemaker wird vollständig durch Gluster konfiguriert, bzw über die ganesha-ha.conf

Group: storage-cluster-10-group
Resource: storage-cluster-10-nfs_block (class=ocf provider=heartbeat type=portblock)
Attributes: action=block ip=10.1.130.10 portno=2049 protocol=tcp
Operations: monitor interval=10s timeout=10s (storage-cluster-10-nfs_block-monitor-interval-10s)
start interval=0s timeout=20s (storage-cluster-10-nfs_block-start-interval-0s)
stop interval=0s timeout=20s (storage-cluster-10-nfs_block-stop-interval-0s)
Resource: storage-cluster-10-cluster_ip-1 (class=ocf provider=heartbeat type=IPaddr)
Attributes: cidr_netmask=32 ip=10.1.130.10
Operations: monitor interval=15s (storage-cluster-10-cluster_ip-1-monitor-interval-15s)
start interval=0s timeout=20s (storage-cluster-10-cluster_ip-1-start-interval-0s)
stop interval=0s timeout=20s (storage-cluster-10-cluster_ip-1-stop-interval-0s)
Resource: storage-cluster-10-nfs_unblock (class=ocf provider=heartbeat type=portblock)
Attributes: action=unblock ip=10.1.130.10 portno=2049 protocol=tcp reset_local_on_unblock_stop=true tickle_dir=/run/gluster/shared_storage/nfs-ganesha/tickle_dir/
Operations: monitor interval=10s timeout=60s (storage-cluster-10-nfs_unblock-monitor-interval-10s)
start interval=0s timeout=60s (storage-cluster-10-nfs_unblock-start-interval-0s)
stop interval=0s timeout=60s (storage-cluster-10-nfs_unblock-stop-interval-0s)

Wäre jetzt ein Auszug der für den ersten Server gilt. Hierbei ist zu sehen das die VIP intern verwurstet wird. Allerdings, meine ich, sollte sie eben eben auch einem Network-Device zugewiesen werden, da sie ansonsten witzlos ist.
Ich habe auch schon damit herum gespielt die IP per Hand zu vergeben. Ergebnis ist dann dass das Device dann in den Status "link down" versetzt wird. Das Ganze greift also schon in die Konfig der Netzwerkschnittstellen ein aber eben nicht so wie von mir erwartet. Ebenso hab ich mich über die Subnetmask gewundert aber die kann ich über die ganesha-ha.conf nicht beeinflussen.

Ich persönlich vermute einen Fehler im debian-paket, wollte aber noch keinen bugreport eröffnen, weil es ja sein könnte das ich etwas mißverstanden hab.

 

[Gräfin Klara]

Attributes: cidr_netmask=32 ip=10.1.130.10

Das ist kaum möglich

Ebenso hab ich mich über die Subnetmask gewundert aber die kann ich über die ganesha-ha.conf nicht beeinflussen.

Die cidr ist die Subnetmask, nur stellt /32 kein Netzwerk dar. min. dafür wäre /30 = 255.255.255.252
Der kernel benötigt für die Zuteilung einer IP an ein device IMMER ein Netzwerk,
sonst kann er ja die default route nicht korrekt setzen. (Hat mit via oder gateway nichts zu tun)

.. per Hand zu vergeben. Ergebnis ist "link down"

Wenn die route vom kernel nicht vergeben werden kann, schaltet dieser den link down.
Test:

# ip addr add 10.1.130.10/30 broadcast 10.1.130.11 dev eno1

setzt network IP/30 in den scope "global" und muß ergeben eine weitere route von:

# ip route show dev eno1

10.1.130.8/30 = default route im scope "link" automatisch gesetzt vom proto "kernel".

Das device sollte nun über 10.1.130.10 ansprechbar sein und hat "link up"
Diese zweite IP (oder wieviele auch immer) stehen OHNE Abhängigkeit und Priorität zueinander. (separaten Tabelleneintrag)
Es ist also keine "VIP" weil es IP aliasing nicht mehr gibt. Daran kann weder pacemaker noch Wikipedia etwas ändern.

 

[Geier0815]

@Gräfin Klara,

Erstens: Eine 32er subnetmask ist möglich, wird verwendet für eine point-to-point Verbindung, zumindest war das so zu Zeiten als man DSL noch per PPPoE betrieben hat. Dies hat mit meinem Problem aber insofern nichts zu tun, weil ich die mask nicht konfiguriere!
Zweitens: Für was hältst Du die cluster-IP bei pacemaker? Ist das keine "virtuelle" IP? Ok, man nennt es da eine "floating" IP und in einem Active/Passiv Konstrukt wandert sie immer auf den aktiven Server. Welchen Namen das Kind hat, ist mir letztlich egal.

Nochmal ganz langsam zum mitschreiben: Ich konfiguriere an pacemaker/corosync einzig und alleine den User hacluster und authentifiziere die Server gegeneinander per "pcs host auth storage-cluster-10 storage-cluster-20 storage-cluster-30"! Alles Andere an Konfiguration wird durch "gluster nfs-ganesha enable" durchgeführt. Grundlage dafür ist die /run/gluster/shared_storage/nfs-ganesha/ganesha-ha.conf die ich abgeleitet habe aus der /etc/ganesha/ganesha-ha.conf.sample

die von debian im Paket glusterfs-server ausgeliefert wird und auch so in der Anleitung von gluster.org gezeigt wird.

Entschuldige wenn mein Ton nicht gerade freundlich ist aber ich hänge jetzt schon seit 3 Wochen an dem Sch**ß dran, hab zig Anleitungen zu dem Thema gelesen und will jetzt eigentlich nur noch wissen ob der Fehler evtl. nicht doch noch an einem Verständnisproblem meinerseits hängt oder ob da tatsächlich ein Problem mit den debian-Paketen vorliegt.

Um noch weitere Fragen, die aufkommen könnten, schon im Vorfeld zu beantworten: Ja, ich habe schon die Pakete von gluster.org ausprobiert, die sind noch grottiger, da fehlen Teile wie zB das ganesha-ha.sh script. Und ja, ich habe apparmor schon deaktiviert (weil die Anleitung ja explizit von SELinux schreibt, dies unter debian aber nicht verwendet wird).

[Edit] Weil nicht drauf eingegangen:
Als ich per Hand eine IP vergeben habe, hab ich eine /16 netmask vergeben und die IP bzw das Device war UP. Es wurde erst auf DOWN gesetzt nachdem ich "gluster nfs-ganesha enable" ausgeführt hab[/Edit]

 

[Gräfin Klara]

Erstens: Eine 32er subnetmask ist möglich, wird verwendet für eine point-to-point Verbindung, zumindest war das so zu Zeiten als man DSL noch per PPPoE betrieben hat.

Das hat mit dem Thema nichts zu tun, aber das ist dir sowieso klar.

Dies hat mit meinem Problem aber insofern nichts zu tun, weil ich die mask nicht konfiguriere!

Du brauchst ein Netzwerk, /32 ist keines, Hier kann deinem Gedankengang nicht folgen,

Zweitens: Für was hältst Du die cluster-IP bei pacemaker? Ist das keine "virtuelle" IP? Ok, man nennt es da eine "floating" IP und in einem Active/Passiv Konstrukt wandert sie immer auf den aktiven Server. Welchen Namen das Kind hat, ist mir letztlich egal.

Ich versuche in der Kommunikation immer die korrekte Bezeichnung zu verwenden.
Das ist nicht Besserwisserei, sondern verhindert das Abgleiten in Undeutlichkeiten.
Eine "floating IP" in einem "masterless network" ist selbsterklärend und bedarf keiner Diskussion.

Nochmal ganz langsam zum mitschreiben ...

Ich habe und hatte dich verstanden.

Entschuldige wenn mein Ton nicht gerade freundlich ist aber ich hänge jetzt schon seit 3 Wochen ..

Kurz und prägnant empfinde ich nicht als unfreundlich.

... Verständnisproblem meinerseits hängt oder ob da tatsächlich ein Problem mit den debian-Paketen vorliegt.

Ich habe mich mit diesem Thema vor Jahren auseinandersetzen müssen.
Nach einigen Problemen, die oft seltsame Ursachen hatten, ging es dann in Betrieb.
Als IPv6 Thema wurde, ließ ich es aus Performance- und Wartungsgründen wieder entfernen.
An ein debian Problem glaube ich aus mehreren Gründen nicht, auch weil Verständnisprobleme
in diesem Zusammenhang nicht ungewöhnlich sind. Wir haben es danach mit ISCSI gelöst.

Um noch weitere Fragen, die aufkommen könnten, schon im Vorfeld zu beantworten ..

Ich bin sowieso davon ausgegangen, dass deine Nebenschauplätze bereinigt sind.

Als ich per Hand eine IP vergeben habe, hab ich eine /16 netmask vergeben und die IP bzw das Device war UP.

Ok

Es wurde erst auf DOWN gesetzt nachdem ich "gluster nfs-ganesha enable" ausgeführt hab

Das ist doch aktuell dein eigentliches Problem ... oder verstehe ich etwas falsch.
Das Setzen der floating IP muß an dieser Stelle nicht passieren aber der Zustand DOWN darf hier nicht auftreten.
Willst du diese Ursache erkunden? Ich würde das als den logisch nächsten Schritt sehen.

 

[Geier0815]

Das Problem ist jetzt genauer eingekreist: Mit der VIP in der ganesha-ha.conf wird die virtuelle IP (ja @Gräfin Klara das nennt sich bei ganesha-ha tatsächlich so) zugewiesen aber nicht auf welches Network-Device er das packen soll.

Wenn ich

pcs resource update storage-cluster-10-cluster_ip-1 nic=eno1

eingebe wird automatisch die IP 10.1.130.10 zugewiesen. Das gleiche für die anderen beiden Server auch noch gemacht und "pcs status" zeigt keine Probleme mehr. Alle Rechner sind dann pingbar und die VIP eines heruntergefahrenen Servers wandert auf einen der beiden verbliebenen.
Damit kann ich dann jetzt einen Bugreport schreiben das in der ganesha-ha.conf.sample zumindest stehen sollte das man die nic nachträglich eingeben muß, bzw das ein Weg dokumentiert wird wie die in der ganesha-ha.conf richtig angegeben wird, so dies überhaupt vorgesehen ist.

 

[Gräfin Klara]

großartig!
D.h. wenn du den nic NICHT definierst, geht eno1 DOWN?

 

[Geier0815]

Nicht ganz. Wenn ich eno1:1 die 10.1.130.10/16 gebe, das Device Up bringe und dann "gluster nfs-ganesha enable" ausführe, verschwindet eno1:1 und damit die 10.1.130.10. Wenn ich eno2 die 10.1.130.10 zuweise, das Device Up bringe und dann "gluster nfs-ganesha enable" ausführe wird eno2 link DOWN.

eno1 mit der 10.1.120.10 läuft in jedem Fall weiter, ich habe immer Zugriff auf den Rechner.
Gebe ich die 10.1.130.10 gar nicht vor und gebe dann den pcs-Befehl ein, wird eno1:1 mit der 10.1.130.10 erzeugt und UP gesetzt.

 

[Gräfin Klara]

ok, danke, verstanden, zumindest fast

Wenn ich eno2 die 10.1.130.10 zuweise, das Device Up bringe und dann "gluster nfs-ganesha enable" ausführe wird eno2 link DOWN.

Das ist mir ein Rätsel ...

 

[Geier0815]

Im Verständnis dessen was ich beschreibe? Oder warum das geschieht?

 

[Gräfin Klara]

Im Verständnis dessen was ich beschreibe? Oder warum das geschieht?

warum das geschieht

 

[spoensche]

Mir ist gerade aufgefallen, dass du bei der VIP von einer einzelnen IP sprichst, oder?

 

[Geier0815]

@Gräfin Klara,

ich vermute das dies quasi ein Aufräumen ist. pcs bzw pacemaker startet, stellt fest das eine IP die er einrichten soll schon vorhanden ist und geht davon aus das dies ein Überbleibsel eines Ausfalls ist. Daraufhin schaltet er die, aus seiner Sicht doppelte, IP down um sie eigentlich sauber wieder hoch zu bringen und fliegt dabei (beim Hochbringen) auseinander. Ergebnis wäre dann das was ich beobachtet hab.

@spoensche,

Ja, für diesen einzelnen Server ja. Insgesamt gebe ich aber 3 VIPs an, für jeden Server eine eigene. Des weiteren hat jeder Server auch noch seine "normale" IP. Und alle 6 IPs werden in der /etc/hosts (und noch in meinem DNS) auf Namen aufgelöst. Jeweils einmal auf den "echten" hostname mit der "echten" IP und einmal auf einen scheinbar frei wählbaren Namen mit der VIP. Wenn Du dann einen NFS-Client anbindest, spricht der entweder eine VIP an oder den, dieser VIP zugeordnetem, Namen. Geht nun der Server kaputt, wird die IP auf einen noch funktionierenden Server verschoben und der Client wandert mit. Dadurch fliegt dir die Verbindung nicht auseinander.