gluster2 und gluster3 von paedml nicht erreichbar

[Rüdiger Kupper]

Ich kann vom paedml aus gluster2 und 3 weder anpingen noch ssh machen. Gluster1 und 4 klappen.
Lagge ich mich aber auf gluster1 ein, so kann ich von dort aus problemlos auch gluster2 und 3 erreichen.
Alles jeweils über die 10.3.0.x-Adressen in VLAN18.

Ist da etwas faul?

[Rüdiger Kupper]

Über die Adressen 10.0.255.x komme ich vom paedml aus auf alle vier gluster-Server …

[Rüdiger Kupper]

Kleine Korrektur, bei den 10.0.255.x-Adressen sieht es so aus (vom paedml):

10.0.255.1

pingt, ssh möglich

10.0.255.2

pingt, ssh timeout

10.0.255.3

pingt, ssh möglich

10.0.255.4

pingt, ssh timeout

Mysteriös. Fällt Dir dazu etwas ein?

[bau]

• Der Zugang zu den Gluster-Servern muss zwingend über das VLAN18 erfolgen, dazu haben wir die Routen zusammengebastelt.
• Beim Testen der Routen aus dem grünen Netz habe ich leider den Default-Router auf dem paedml nicht wieder entfernt.
• Die anderen IP sind nur dafür da, dass die Gluster-Server Internetzugang erhalten.

[Rüdiger Kupper]

Replying to bau:

• Der Zugang zu den Gluster-Servern muss zwingend über das VLAN17 erfolgen, dazu haben wir die Routen zusammengebastelt.

Äh, und welche sind das dann, die 10.3.0.x? Dachte, das ist VLAN18, verliere gerade ein bisschen die Übersicht ;-).

• Beim Testen der Routen aus dem grünen Netz habe ich leider den Default-Router auf dem paedml nicht wieder entfernt.

Super, ssh klappt jetzt vom paedml auf alle gluster.

• Die anderen IP sind nur dafür da, dass die Gluster-Server Internetzugang erhalten.

Dann wäre noch die Frage, über welche IPs sich die Gluster-Server gegenseitig ansprechen?. Da stehen auch die 10.3.0.x-Adressen in den /etc/hosts.

[bau]

Hier das Setting:

• VLAN 18 (GlusterFS)
• Die Gluster-Server sprechen sich über die IPs 10.3.0.1 / 10.3.0.2 / 10.3.0.3 / 10.3.0.4 an, sie hängen alle im VLAN18 udn haben direkten Kontakt zueinander
• Aus dem Lehrernetz gibt es ein direktes Routing über den Standard-Router (10.16.112.126/10.16.112.254/10.16.113.126/10.16.113.254 auf ciscoServerraum) in das VLAN18, die Gluster finden den Weg über das eingetragene Gateway 10.3.0.254 (auf ciscoServerraum) zurück in das Lehrernetz
• Im Schülernetz ist auf ciscoServerraum ein Router eingerichtet auf der IP 10.32.1.252, über diesen erreichen die Clients im Schülernetz das VLAN18, die Rückroute über das eingetragene Gateway 10.3.0.254 (auf ciscoServerraum) zurück in VLAN7

[bau]

Problem von oben ist auch gelöst: Die Glusters ziehen sich aus dem Gastnetzwerk ihre IP von aktuell zwei DHCP-Servern (10.0.0.249 (proxyl auf ProxmoxLS) und 10.0.0.250 (proxyl auf ProxmoxTGS). Diese sind redundant und routen den Gastnetzwerktraffic je nach Last über die beiden Knoten. Angedacht ist, auf jedem Knoten mit öffentlicher IP so einen Router/DHCP bereitszustellen, dann fällt da nicht gleich alles aus, wenn mal ein Knoten weg ist. Ebenso wäre das im iPad-WLAN gut. Nun haben sich die vier Glusters dann auch bei beiden DHCP-Servern bedient, aktuell:

• 10.0.0.249: Gluster 1 und 4
• 10.0.0.250: Gluster 2 und 3

Daher erklärt sich das unterschiedliche Verhalten bei ping/ssh: anpingen geht bei allen, ssh geht nur bei 2/3, also denen, wo das Standard-Gateway nicht auf dem proxmoxLS auf den router des Gastnetzwerks trifft, der auch auf dem ProxmoxLS liegt. Also auch dieses Phänomen geklärt.

Die Rückroute konnte leider bislang im Schülernetz nicht gehen, da der Router 10.3.0.254 bislang auf den Glustern nicht eingetragen war, das habe ich gerade nachgeholt. Jetzt geht auch die Rückroute ins grüne VLAN 7.

/etc/network/intefaces

post-up ip route add 10.32.0.0/12 via 10.3.0.254 dev bond0

[Rüdiger Kupper]

Ich muss sagen, dass mir das Routing in unserem Netzwerk noch immer unklar ist.
Ich setze rich auf CC, der hat sich Gedanken zu DNS und vielleicht auch DHCP gemacht. Und er braucht die Daten für netbox.

[bau]

ein weiterer TOP bei unserem Treffen zu checkMK und netbox

[bau]

@rich: das wäre ein ToDo für uns dieses Schuljahr: das Inventur-System (netbox oder ???)

[Stephan Richter]

Inzwischen bin ich etwas pessimistisch, dass wir mit unseren begrenzten Ressourcen den Ist-Zustand des Netzwerks sauber in Netbox abbilden können - es ist ja doch ziemlich Komplex mit den diversen VLANs und diversen Hosts mit jeweils diversen NICs die in den besagten verschiedenen VLANs hängen ;-)

Was man aber auf jeden Fall angehen könnte, wäre eine Verwaltung der VLANs und IP-Adressen in Netbox, so dass es hier in Zukunft seltener zu IP-Konflikten und sonstigen Unklarheiten kommt.

[bau]

Mir wäre eine Inventur der PC wichtig.
Vor allem nach dem Ausrollen eines neuen Images möchte ich von den Rechnern wissen, was sie "drauf" haben.
Aber auch jeden Tag wäre es schön, eine Inventur zu haben.
Außerdem wäre es sehr hilfreich zu wissen, welche Rechner morgens gebootet haben. Dann könnte eine Hardwarebereitschaft kurz nach den anderen schauen.
Kann das netbox?

[Stephan Richter]

Replying to bau:

Kann das netbox?

Nein.

Netbox ist als "source of truth" gedacht - es soll der gewünschte Zustand des Netzwerks abgebildet werden --> Handarbeit. Über die API können aber andere Tools diese Daten auslesen und mit der Realität abgleichen:
​https://docs.netbox.dev/en/stable/introduction/#serve-as-a-source-of-truth
​https://kaonbytes.com/p/netbox-dynamic-inventory-for-ansible-as-a-feedback-loop/

Ich bin aber der Meinung, dass wir für das Aufsetzen und Pflegen eines solchen Systems keine Ressourcen haben.

[bau]

OK, dann verfolge ich eher das bisherige Ziel ein kleines Script aufzusetzen, mit welchem die Clients alles, was für uns wichtig ist beim Booten an den Server melden.