Server Konsole friert immer mal wieder ein

[Jan Novak]

Hallo,

auf 3 aktuellen Debian Systemen läuft jeweils ein Proxmox System im
Cluster. Am Wochenende hatte ich einen Stromausfall (ohne USV), alle
sind leider abrupt stehen geblieben.
Einer hat einen HD Schaden (schon vorher, Platte ist bereits getauscht).

Seit dem hängt aber die Konsole der Server (bisher nur Remote getestet)
immer mal wieder für 5-10 Sekunde und läuft dann normal weiter. Die
Häufigkeit ist sehr unterschiedlich. Mal läufts für 10 Minuten, mal alle
1-2 Minuten.

Das betrifft alle 3 Rechner im Cluster. Die anderen beiden Server hatten
und haben keine HD Probleme (lt. smartctl).
Es existiert kein höherer Netzwerk oder IO traffic als sonst üblich.


Irgend eine Idee, wie ich dem auf die Schliche kommen kann?

Jan

[Tim Ritberg]

Am 15.02.24 um 10:57 schrieb Jan Novak:

Raid-rebuild?

Tim

[Jan Novak]

Am 15.02.24 um 11:31 schrieb Tim Ritberg:

Ja, hatte ich anfangs auch gedacht. Aber der eine Server, der den Raid
rebuild wegen der getauschten Platte gemacht hatte, ist schon fertig und
das Raid ist wieder verfügbar.
Abgesehen davon, beträfe das ja die beiden anderen nicht.

Jan

[Jan Novak]

Am 15.02.24 um 10:57 schrieb Jan Novak:

Noch ein kleiner Hinweis, welcher mir gerade aufgefallen ist:

Wenn ich 2 Remote SSH Sitzungen zu einem Server habe und die eine
Sitzung friert ein, friert die andere Sitzung nicht immer auch mit ein,
manchmal schon, oder sie ist früher wieder erreichbar als die jeweils
andere.

Ich habe versucht, mit diesem Script das einfrieren zu messen, aber es
löst "nie" aus, selbst wenn der Rechner für 5 Sekunden stand.
Offensichtlich friert auch die Zeit des Rechners ein.

#!/bin/bash
logfile="freeze_log.txt"
timeout_threshold=4

while true; do
start_time=$(date +%s%N)
ping -c 1 localhost >/dev/null 2>&1
end_time=$(date +%s%N)
elapsed_time=$(( ($end_time - $start_time) / 1000000 ))
if [ $elapsed_time -gt $timeout_threshold ]; then
echo "$(date +'%Y-%m-%d %H:%M:%S') - hang for $elapsed_time"
|tee -a "$logfile"
else
echo -n "."
fi
sleep 1
done




Jan

[Jan Novak]

Am 15.02.24 um 10:57 schrieb Jan Novak:

[Jan Novak]

Am 15.02.24 um 12:38 schrieb Jan Novak:

> Am 15.02.24 um 10:57 schrieb Jan Novak:
>> Hallo,
>>
>> auf 3 aktuellen Debian Systemen läuft jeweils ein Proxmox System im
>> Cluster. Am Wochenende hatte ich einen Stromausfall (ohne USV), alle
>> sind leider abrupt stehen geblieben.
>> Einer hat einen HD Schaden (schon vorher, Platte ist bereits getauscht).
>>
>> Seit dem hängt aber die Konsole der Server (bisher nur Remote
>> getestet) immer mal wieder für 5-10 Sekunde und läuft dann normal
>> weiter. Die Häufigkeit ist sehr unterschiedlich. Mal läufts für 10
>> Minuten, mal alle 1-2 Minuten.
>>
>> Das betrifft alle 3 Rechner im Cluster. Die anderen beiden Server
>> hatten und haben keine HD Probleme (lt. smartctl).
>> Es existiert kein höherer Netzwerk oder IO traffic als sonst üblich.
>>
>
> Noch ein kleiner Hinweis, welcher mir gerade aufgefallen ist:
>
> Wenn ich 2 Remote SSH Sitzungen zu einem Server habe und die eine
> Sitzung friert ein, friert die andere Sitzung nicht immer auch mit ein,
> manchmal schon, oder sie ist früher wieder erreichbar als die jeweils
> andere.
>
> Ich habe versucht, mit diesem Script das einfrieren zu messen, aber es
> löst "nie" aus, selbst wenn der Rechner für 5 Sekunden stand.
> Offensichtlich friert auch die Zeit des Rechners ein.

Was natürlich Quatsch ist.
Nicht die Rechner frieren ein, sondern die Netzwerkverbindung. Daher
sind auch alle 3 betroffen.
Zwischen den Rechnern, aber nicht generell scheint das Problem zu sein.
Eine Übertragung von einer großen Datei fängt schnell an und ist nach
ein paar Minuten bei nur noch einigen KB/s. Dann gehts wieder auf ein
paar MB hoch und sackt wieder ab.


Jan


Jan

[Tim Ritberg]

Am 15.02.24 um 13:22 schrieb Jan Novak:

> Was natürlich Quatsch ist.
> Nicht die Rechner frieren ein, sondern die Netzwerkverbindung. Daher
> sind auch alle 3 betroffen.

Mal ssh -v laufen lassen (client) und gucken...

Tim

[Sieghard Schicktanz]

Hallo Jan,

Du schriebst am Thu, 15 Feb 2024 13:22:17 +0100:

> Nicht die Rechner frieren ein, sondern die Netzwerkverbindung. Daher
> sind auch alle 3 betroffen.
> Zwischen den Rechnern, aber nicht generell scheint das Problem zu sein.

Hängen die alle an 3 einem Switch, die anderen aber nicht?
Könnte ggfs. eine Folge des Stromausfalls am Switch sein?

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Jan Novak]

Am 15.02.24 um 20:18 schrieb Sieghard Schicktanz:

> Hallo Jan,
>
> Du schriebst am Thu, 15 Feb 2024 13:22:17 +0100:
>
>> Nicht die Rechner frieren ein, sondern die Netzwerkverbindung. Daher
>> sind auch alle 3 betroffen.
>> Zwischen den Rechnern, aber nicht generell scheint das Problem zu sein.
>
> Hängen die alle an 3 einem Switch, die anderen aber nicht?
> Könnte ggfs. eine Folge des Stromausfalls am Switch sein?

Ich hatte extra einen neue Switch dran gehängt, keine Verbesserung. Aber
2 Netzwerkkarten scheinen etwas ab bekommen zu haben. Da die Server
mehere NICs hatten, und eine unbenutzt war, habe ich es umgestellt - und
jetzt ist wieder alles ok.

Nun frage ich mich, wie kann denn eine onboard NIC kaputt gehen?

Jan

[Jan Novak]

Am 15.02.24 um 14:47 schrieb Tim Ritberg:

Das ahtte ich auch gemacht... am Ende (sie nächste Mail), waren es 2
Netzwerkkarten.


Jan

[Marc Haber]

Jan Novak <rep...@gmail.com> wrote:
>Nun frage ich mich, wie kann denn eine onboard NIC kaputt gehen?

Sollte eigentlich nicht, vielleicht ein Duplex Mismatch? Hattest Du
Fehlerzähler ungleich Null? Ist der Switch managebar?

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[Jan Novak]

Am 16.02.24 um 10:27 schrieb Marc Haber:

> Jan Novak <rep...@gmail.com> wrote:
>> Nun frage ich mich, wie kann denn eine onboard NIC kaputt gehen?
>
> Sollte eigentlich nicht, vielleicht ein Duplex Mismatch? Hattest Du
> Fehlerzähler ungleich Null? Ist der Switch managebar?

Moin,

ne, der Switch ist "dumm".
Fehlerzähler? Wo finde ich den?

Ich hatte je gestern Abend zuerst einen (ganz) neuen Switch zum Test
dran gehängt, dennoch gleiches Ergebnis.
Erst mit der Umstellung auf die andere NIC wars wieder ok (am neuen
Switch). Werde heute Nachmittag wieder auf den alten und eingebauten
Switch zurück stellen.


jan

[Marc Haber]

Jan Novak <rep...@gmail.com> wrote:
>Am 16.02.24 um 10:27 schrieb Marc Haber:
>> Jan Novak <rep...@gmail.com> wrote:
>>> Nun frage ich mich, wie kann denn eine onboard NIC kaputt gehen?
>>
>> Sollte eigentlich nicht, vielleicht ein Duplex Mismatch? Hattest Du
>> Fehlerzähler ungleich Null? Ist der Switch managebar?
>
>Moin,
>
>ne, der Switch ist "dumm".
>Fehlerzähler? Wo finde ich den?

Den rechnerseitigen in ip -s link show, den switchseitigen im
Mangement-Interface.

Ein weiteres Argument warum ich eigentlich nur managebare Switche als
akzeptabel einstufe, ohne Management ist man in solchen Fällen blind.

[Peter J. Holzer]

On 2024-02-16 09:27, Marc Haber <mh+usene...@zugschl.us> wrote:
> Jan Novak <rep...@gmail.com> wrote:
>>Nun frage ich mich, wie kann denn eine onboard NIC kaputt gehen?
>
> Sollte eigentlich nicht, vielleicht ein Duplex Mismatch?

Duplex Mismatch gibt es nicht mehr. Gigabit-Ethernet ist immer Full
Duplex. Da müsste man schon 100MBit oder 10Mbit verwenden ...

hp

[Jan Novak]

Am 16.02.24 um 13:44 schrieb Marc Haber:

> Jan Novak <rep...@gmail.com> wrote:
>> Am 16.02.24 um 10:27 schrieb Marc Haber:
>>> Jan Novak <rep...@gmail.com> wrote:
>>>> Nun frage ich mich, wie kann denn eine onboard NIC kaputt gehen?
>>>
>>> Sollte eigentlich nicht, vielleicht ein Duplex Mismatch? Hattest Du
>>> Fehlerzähler ungleich Null? Ist der Switch managebar?
>>
>> Moin,
>>
>> ne, der Switch ist "dumm".
>> Fehlerzähler? Wo finde ich den?
>
> Den rechnerseitigen in ip -s link show, den switchseitigen im
> Mangement-Interface.

danke für den Heinweis.

>
> Ein weiteres Argument warum ich eigentlich nur managebare Switche als
> akzeptabel einstufe, ohne Management ist man in solchen Fällen blind.

Korrekt... wobei das in diesem Fall meine Home Server sind und ich nicht
so viel Geld dafür augeben wollte.
Da ich aber demnächst VLAN nutzen will, muss ich auch neue Switch'e
kaufen ...

Jan

[Marc Haber]

Jan Novak <rep...@gmail.com> wrote:
>Am 16.02.24 um 13:44 schrieb Marc Haber:

>> Ein weiteres Argument warum ich eigentlich nur managebare Switche als
>> akzeptabel einstufe, ohne Management ist man in solchen Fällen blind.
>
>Korrekt... wobei das in diesem Fall meine Home Server sind und ich nicht
>so viel Geld dafür augeben wollte.

Meist funktioniert das ja auch. Aber auch switchseitig Fehlerzähler zu
haben und auch Trafficstatistiken führen zu können ist nett.

>Da ich aber demnächst VLAN nutzen will, muss ich auch neue Switch'e
>kaufen ...

Und ja, VLANs sind essenziell.

[Marc Haber]

Pferde, Apotheke. Dinge passieren. Auch bei der Aushandlung der
Datenrate.

[Kay Martinen]

Am 16.02.24 um 09:09 schrieb Jan Novak:

> Am 15.02.24 um 20:18 schrieb Sieghard Schicktanz:
>> Hallo Jan,
>>
>> Du schriebst am Thu, 15 Feb 2024 13:22:17 +0100:
>>
>>> Nicht die Rechner frieren ein, sondern die Netzwerkverbindung. Daher
>>> sind auch alle 3 betroffen.
>>> Zwischen den Rechnern, aber nicht generell scheint das Problem zu sein.

Erster Gedanke: Irgendwelche Änderungen an der Einrichtung von
LAN/NICs/IP die nicht reboot-fest gespeichert waren?

Seit mind. PVE 6 o. 7 kann man die Netzwerk-Einrichtung in der GUI ja;
ohne Reboot; direkt anwenden. Aber auf so sachen wie sysctl trifft das
m.E. nicht zu.

>> Hängen die alle an 3 einem Switch, die anderen aber nicht?
>> Könnte ggfs. eine Folge des Stromausfalls am Switch sein?
>
> Ich hatte extra einen neue Switch dran gehängt, keine Verbesserung. Aber
> 2 Netzwerkkarten scheinen etwas ab bekommen zu haben. Da die Server
> mehere NICs hatten, und eine unbenutzt war, habe ich es umgestellt - und
> jetzt ist wieder alles ok.
>
> Nun frage ich mich, wie kann denn eine onboard NIC kaputt gehen?

Möglicherweise hat es beim Stromausfall eine kurze Spannungsspitze
gegeben. Da du "Ohne USV" schriebst könnte die aus dem Stromnetz
gekommen sein. Eine Vorgeschaltete USV könnte so was wegfiltern, aber
wenn der Switch da nicht ebenfalls mit dran hängt...

Hast du die Onboard-NICs mit UTP oder STP verkabelt?

Bye/
/Kay

--
nix

[Kay Martinen]

Am 16.02.24 um 16:58 schrieb Marc Haber:

> Jan Novak <rep...@gmail.com> wrote:
>> Am 16.02.24 um 13:44 schrieb Marc Haber:
>>> Ein weiteres Argument warum ich eigentlich nur managebare Switche als
>>> akzeptabel einstufe, ohne Management ist man in solchen Fällen blind.
>>
>> Korrekt... wobei das in diesem Fall meine Home Server sind und ich nicht
>> so viel Geld dafür augeben wollte.

Definiere "nicht viel" :) Ich hab alle Managebare Switche die ich hier
habe schon vor Jahren für weniger als je 30-50€ Gebraucht gekauft und
die laufen teils immer noch. Gut, die meisten sind zwar 100Mbit Geräte
die bestenfalls 2 GbE Combo-Ports für den Uplink haben. Aber die
WS-C-3508G waren auch nicht teurer und haben 8 GBIC Ports. Sind mom.
nicht im Einsatz, könnten sie aber. Alle können SNMP und VLANs.

> Meist funktioniert das ja auch. Aber auch switchseitig Fehlerzähler zu
> haben und auch Trafficstatistiken führen zu können ist nett.

Eben. Egal ob mit Cacti, Observium, Nagios o.a. macht es die Sache
einfacher wenn man im Monitoring direkt sehen kann ob auf einem Link
z.b. der Graph der Fehler (ggf. nach Typ) hoch läuft, der Link
ausgelastet wäre oder sonst was. Und so ein Monitoring kann einen ja
auch alarmieren. Per Mail oder anderen Wegen.

Dagegen ist z.B. 'Netdata' auf dem Host zwar nett an zu sehen aber auch
manchmal etwas geschwätzig und taugt nur für die Lokale Maschine.

>> Da ich aber demnächst VLAN nutzen will, muss ich auch neue Switch'e
>> kaufen ...
>
> Und ja, VLANs sind essenziell.

Bei einem Cluster-setup (wie IMO beim OP gegeben) wird m.E. eh dazu
geraten alle Cluster Nodes mit einem Separaten Link untereinander zu
verbinden. Das "könnte" auch ein VLAN sein.

Und ohne VLAN im Switch braucht man für PVE physische Interfaces für
jedes Separierte Netzwerksegment. Mit Management ist's einfacher. Man
setzt die Bridge (z.b. vmbr0) auf "vlan-aware" und kann in der GUI pro
VM-interface einfach eine VLAN ID eingeben. Fertig.

Bye/
/Kay

--
nix

[Sieghard Schicktanz]

Hallo Jan,

Du schriebst am Fri, 16 Feb 2024 09:09:27 +0100:

> Nun frage ich mich, wie kann denn eine onboard NIC kaputt gehen?

Wie jede andere auch? Sicher, die Datenleitungen sind galvanisch getrennt.
Aber wenn die Leitungsschirme angeschlossen sind, kann über die Verbindung
trotzdem Überspannung auf die Anschlüsse kommen. Und dann ist es eher noch
ein günstiger Fall, wenn dadurch "nur" die Schnittstelle aufgibt und nicht
noch weiteres an den Interna der Maschine in Mitleidenschaft gezogen wird.

[Jan Novak]

Am 16.02.24 um 20:27 schrieb Kay Martinen:

>>> Korrekt... wobei das in diesem Fall meine Home Server sind und ich nicht
>>> so viel Geld dafür augeben wollte.
>
> Definiere "nicht viel" :) Ich hab alle Managebare Switche die ich hier
> habe schon vor Jahren für weniger als je 30-50€ Gebraucht gekauft und
> die laufen teils immer noch. Gut, die meisten sind zwar 100Mbit Geräte

Ich benötige hier 3 Switche als 19" mit mindestens 12 Ports und 1Gbit.
Das bekommst du nicht gebraucht nicht unter 150€... da kaufe ich mir
dann (bei Gelegenheit) lieber nen Neuen.

> Eben. Egal ob mit Cacti, Observium, Nagios o.a.

lustriger Zufall. Ich richte gerade Zabbix ein ... der kann auch SMNP
... das wäre dann zukünftig eine Monitoring Möglichkeit.

> Bei einem Cluster-setup (wie IMO beim OP gegeben) wird m.E. eh dazu
> geraten alle Cluster Nodes mit einem Separaten Link untereinander zu
> verbinden. Das "könnte" auch ein VLAN sein.

Ich habe mir gestern 2 mal 2,5Gbe und eine 4Port 2,5Gbe Netzwerkkarte
bestellt und verbinde die Server damit direkt und ohne Switch.

> Und ohne VLAN im Switch braucht man für PVE physische Interfaces für
> jedes Separierte Netzwerksegment. Mit Management ist's einfacher. Man
> setzt die Bridge (z.b. vmbr0) auf "vlan-aware" und kann in der GUI pro
> VM-interface einfach eine VLAN ID eingeben. Fertig.

Das wird Teil der Wochenendarbeit :-)

Jan

[Kay Martinen]

Am 17.02.24 um 11:07 schrieb Jan Novak:

> Am 16.02.24 um 20:27 schrieb Kay Martinen:
>>>> Korrekt... wobei das in diesem Fall meine Home Server sind und ich
>>>> nicht
>>>> so viel Geld dafür augeben wollte.
>>
>> Definiere "nicht viel" :)

> Ich benötige hier 3 Switche als 19" mit mindestens 12 Ports und 1Gbit.

Hmm. Wenn ich von einem Cluster mit 3 Nodes ausgehe der Redundant
angebunden ist dann zähle ich 3*2 GbE + 3*1-2 FE für Corosync allein für
dessen an- und ver-bindung.

Macht in Summe 6 GbE Ports und max. ebenso viele für den Sync der Nodes.

Und bei entsprechender Einrichtung der Beiden GbE Links pro Node kannst
du 2 GB/s/Richtung mit Fehlertoleranz haben - mit einem Switch der das
auch kann. Mit einem Dumb Switch geht da IMO nur eine abgespeckte Variante.

> Das bekommst du nicht gebraucht nicht unter 150€... da kaufe ich mir
> dann (bei Gelegenheit) lieber nen Neuen.

Okay. Nach meiner Zählung liegen hier 7 19" Switche rum mit zusammen 8
HE von denen mom. aber nur 2-3 im Einsatz sind. Und die haben (fast)
alle 24+ Ports. ;)

>> Eben. Egal ob mit Cacti, Observium, Nagios o.a.
>
> lustriger Zufall. Ich richte gerade Zabbix ein ... der kann auch SMNP
> ... das wäre dann zukünftig eine Monitoring Möglichkeit.

Hab ich wohl schon von gehört aber noch nicht rein geschnuppert. Scheint
aber ähnlich wie Nagios auch mit Agents auf den Hosts arbeiten zu können.

Hatten wir das nicht irgendwo kürzlich, host war ping-bar aber service
nicht erreichbar - weil monitoring auf der gleichen maschine keine
fehler meldete... :)

>> Bei einem Cluster-setup (wie IMO beim OP gegeben) wird m.E. eh dazu
>> geraten alle Cluster Nodes mit einem Separaten Link untereinander zu
>> verbinden. Das "könnte" auch ein VLAN sein.
>
> Ich habe mir gestern 2 mal 2,5Gbe und eine 4Port 2,5Gbe Netzwerkkarte
> bestellt und verbinde die Server damit direkt und ohne Switch.

Hast du das hier gelesen?

https://pve.proxmox.com/wiki/Separate_Cluster_Network#Introduction

Bei neueren Versionen steht in der online hilfe sinngemäß das gleiche.
Man solle die Corosync Links nicht über das normale LAN laufen lassen
auf dem die UI und der VM-Traffic liegt - sondern über ein separates das
auch nur ein Fastethernet sein kann. Sprich: da läuft dann nichts
anderes drüber, auch nicht Backups oder VM-Migrationen. Nur der Realtime
Traffic zur Cluster-synchronisation.

Dafür brauchst du keine 2.5 GbE Karten als Direktlinks. Und wenn du die
für die normalen Links nehmen willst brauchst du noch einen passenden
Switch dazu - sonst hängt dir der Traffic der beiden anderen nodes auf
dem 3. mit der 4-port Karte und muß von dem auch noch umgeleitet werden.

Die 4-port Karte sollte in den Node der den Server spielen soll oder?

>> Und ohne VLAN im Switch braucht man für PVE physische Interfaces für
>> jedes Separierte Netzwerksegment. Mit Management ist's einfacher. Man
>> setzt die Bridge (z.b. vmbr0) auf "vlan-aware" und kann in der GUI pro
>> VM-interface einfach eine VLAN ID eingeben. Fertig.
>
> Das wird Teil der Wochenendarbeit :-)

Hast du evtl. schon einen VLAN-fähigen 2.5 GbE Switch?

Bye/
/Kay

--
nix

[Marc Haber]

Kay Martinen <use...@martinen.de> wrote:
>Am 16.02.24 um 16:58 schrieb Marc Haber:

>>> Da ich aber demnächst VLAN nutzen will, muss ich auch neue Switch'e
>>> kaufen ...
>>
>> Und ja, VLANs sind essenziell.
>
>Bei einem Cluster-setup (wie IMO beim OP gegeben) wird m.E. eh dazu
>geraten alle Cluster Nodes mit einem Separaten Link untereinander zu
>verbinden. Das "könnte" auch ein VLAN sein.

Bei einem Cluster geht es darum, zwischen "Switch kaputt", "eigenes
Netzinterface kaputt" und "andere Clusternode kaputt" unterscheiden zu
können. Das geht natürlich nicht wenn man ein VLAN benutzt.

Ich mag in solchen Situationen den Uplink redundant auslegen, so dass
auch die Übertragung der Nutzdaten einen Switchreboot überlebt (dann
gibt es ja noch den anderen), unter diesen Umständen kann man auch den
Clusterlink über so einen Link schicken. Netzwerkinterfaces sind
wertvoll.

Leider ist "clusterlink über serielle Schnittstelle" ausgestorben und
"clusterlink über USB" hat nie so richtig abgehoben.

[Marcel Mueller]

Am 16.02.24 um 13:44 schrieb Marc Haber:

>> Fehlerzähler? Wo finde ich den?
>
> Den rechnerseitigen in ip -s link show, den switchseitigen im
> Mangement-Interface.
>
> Ein weiteres Argument warum ich eigentlich nur managebare Switche als
> akzeptabel einstufe, ohne Management ist man in solchen Fällen blind.

Das muss einem halt auch den Faktor 10 Aufpreis wert sein. Neben der
Anschaffung ist üblicherweise auch der 24/7 Stromverbrauch deutlich
höher. Das läppert sich bei TCO.
Erst bei größeren Switches macht es nicht mehr so viel aus.


Marcel

[Marcel Mueller]

Am 16.02.24 um 20:50 schrieb Sieghard Schicktanz:

> Hallo Jan,
>
> Du schriebst am Fri, 16 Feb 2024 09:09:27 +0100:
>
>> Nun frage ich mich, wie kann denn eine onboard NIC kaputt gehen?
>
> Wie jede andere auch? Sicher, die Datenleitungen sind galvanisch getrennt.
> Aber wenn die Leitungsschirme angeschlossen sind, kann über die Verbindung
> trotzdem Überspannung auf die Anschlüsse kommen. Und dann ist es eher noch
> ein günstiger Fall, wenn dadurch "nur" die Schnittstelle aufgibt und nicht
> noch weiteres an den Interna der Maschine in Mitleidenschaft gezogen wird.

Dann müsste es aber schon ein Blitzeinschlag gewesen sein. Wo sollen
sonst die Differenzspannungen am Kabelschirm bei einem Stromausfall her
kommen?

Bei Einschlägen in der Umgebung ist ein vermaschter Potentialausgleich
aber tatsächlich eine große Antenne, um die EM-Felder effektiv in
defekte Geräte umzuwandeln.


Marcel

[Jan Novak]

Am 17.02.24 um 14:22 schrieb Kay Martinen:

> Hast du das hier gelesen?
>
> https://pve.proxmox.com/wiki/Separate_Cluster_Network#Introduction
>
> Bei neueren Versionen steht in der online hilfe sinngemäß das gleiche.
> Man solle die Corosync Links nicht über das normale LAN laufen lassen
> auf dem die UI und der VM-Traffic liegt - sondern über ein separates das
> auch nur ein Fastethernet sein kann. Sprich: da läuft dann nichts
> anderes drüber, auch nicht Backups oder VM-Migrationen. Nur der Realtime
> Traffic zur Cluster-synchronisation.

Ja, den Link kannte ich schon.

> Dafür brauchst du keine 2.5 GbE Karten als Direktlinks. Und wenn du die
> für die normalen Links nehmen willst brauchst du noch einen passenden
> Switch dazu - sonst hängt dir der Traffic der beiden anderen nodes auf
> dem 3. mit der 4-port Karte und muß von dem auch noch umgeleitet werden.

Das stimmt zwar... eigentlich besteht das Cluster aus 5 Nodes, 2 sind
extern. Da habe ich keine physikalische Netzwerkverbindung, nur per VPN.
Ja, ich weiss, das wird von Proxmox "gar nicht" empfohlen. Es
funktioniert aber seit 2 Jahren ohne Probleme.
Letztendlich läuft es aber auch hier auf VLAN hinaus, durch den Tunnel.
Dann hat das Proxmox Cluster net sein eigenes LAN. Wie ich das dann
alles konfigurieren werde, weiss ich noch nicht. Aer gemach... step by step.

> Die 4-port Karte sollte in den Node der den Server spielen soll oder?

Ja, habe ich jetzt verworfen und mir einen 8Port 2,5GB Switch managed
von T-PLink bestellt.

> Hast du evtl. schon einen VLAN-fähigen 2.5 GbE Switch?

Kommt nächste Woche.
Wenn der dann da ist, dann werde ich versuchen das VLAN ein zu richten
und dann das Cluster Netz darüber fahren.


Jan

[Marc Haber]

Marcel Mueller <news.5...@spamgourmet.org> wrote:
>Am 16.02.24 um 13:44 schrieb Marc Haber:
>>> Fehlerzähler? Wo finde ich den?
>>
>> Den rechnerseitigen in ip -s link show, den switchseitigen im
>> Mangement-Interface.
>>
>> Ein weiteres Argument warum ich eigentlich nur managebare Switche als
>> akzeptabel einstufe, ohne Management ist man in solchen Fällen blind.
>
>Das muss einem halt auch den Faktor 10 Aufpreis wert sein. Neben der
>Anschaffung ist üblicherweise auch der 24/7 Stromverbrauch deutlich
>höher. Das läppert sich bei TCO.

Das ist leider richtig. Aber ein unmanagebarer Switch ist Spielzeug.

[Kay Martinen]

Am 18.02.24 um 08:41 schrieb Marc Haber:

> Kay Martinen <use...@martinen.de> wrote:
>> Am 16.02.24 um 16:58 schrieb Marc Haber:
>>>> Da ich aber demnächst VLAN nutzen will, muss ich auch neue Switch'e
>>>> kaufen ...
>>>
>>> Und ja, VLANs sind essenziell.
>>
>> Bei einem Cluster-setup (wie IMO beim OP gegeben) wird m.E. eh dazu
>> geraten alle Cluster Nodes mit einem Separaten Link untereinander zu
>> verbinden. Das "könnte" auch ein VLAN sein.
>
> Bei einem Cluster geht es darum, zwischen "Switch kaputt", "eigenes
> Netzinterface kaputt" und "andere Clusternode kaputt" unterscheiden zu
> können. Das geht natürlich nicht wenn man ein VLAN benutzt.

Deshalb das "Könnte" in Anführungszeichen und die erwähnung das der Sync
der Nodes auch über einen FE-Switch ginge - der dann auch ohne VLANs
einfach Dumb sein kann.

Wenn die Clusternodes HA machen und sich gegenseitig engmaschig
überwachen sollte man annehmen das beim ausfall eines Ports des
ClusterNets oder des Switches sofort der ganze Node oder der Cluster als
Down oder irgendwie gesplittet betrachtet wird. Gegenmaßnahme wäre auch
hier Redundanz. Also nur für den cluster-link zwei NICs, idealerweise
noch zu zwei verschiedenen Switches. Dann müssten erst mindestens 2
Switches und 2 NICs ausfallen bis das passiert. Ob das nur mit einem
Qourum und ungerader Nodezahl zu verhindern ist...?

Angeblich soll ein Raspi ausreichen um die Nodezahl ungerade zu machen
und beim Qourum zu helfen. Der ist dann weder VM noch Storage-host, nur
ein Pseudo-Node. Habe ich wo gelesen.

> Ich mag in solchen Situationen den Uplink redundant auslegen, so dass
> auch die Übertragung der Nutzdaten einen Switchreboot überlebt (dann
> gibt es ja noch den anderen), unter diesen Umständen kann man auch den
> Clusterlink über so einen Link schicken. Netzwerkinterfaces sind
> wertvoll.

Wenn da ein Business dran hängt dann wird man das wohl auch so machen -
und mehr. Privat profitiert man vermutlich mehr davon das bei
Link-Aggregation nicht nur einer ausfallen kann sondern man im
Normalfall die Doppelte Bandbreite erreichen könnte.

> Leider ist "clusterlink über serielle Schnittstelle" ausgestorben und

Ist mir nur an einer Stelle geläufig, bei APC mit der Share-UPS. :-) Die
aber auch nur einen Smart-Port hat und 7 Hosts via Simple-Port einen
Shutdown senden könnte.

Auf der PC-Schiene krankt das wohl eher an den nominal max 4 Seriellen
Ports mit denen das nicht gut hoch skalierbar ist. Und eine Art
Seriellen Hub/Switch dazu zu erfinden ist vermutlich auch nicht billiger
als eine Speziellere Multiportkarte als Alternative.

Ist Clustering nicht im Grunde oft nur eine Art Lebenszeichen zu senden
an eine "Ping-Box" die dann Last man Standing spielt? :)

[Sorry wenn nicht zutreffend. Der Vergleich kam mir eben in den Sinn und
ich fand ihn lustig genug ihn zu posten]

> "clusterlink über USB" hat nie so richtig abgehoben.

Ohne Optokoppler dazwischen würde ich auch ungern PC1-USB mit PC2-USB
verbinden wollen - oder mehr. Da weißt du doch nicht was du dir außer
Datensignalen noch so einfängst.

Bye/
/Kay

--
nix

[Ralph Aichinger]

Marcel Mueller <news.5...@spamgourmet.org> wrote:
> Das muss einem halt auch den Faktor 10 Aufpreis wert sein. Neben der
> Anschaffung ist üblicherweise auch der 24/7 Stromverbrauch deutlich
> höher. Das läppert sich bei TCO.

Naja, Faktor 10 muß nicht sein. Ich bin gerade selbst wieder beim
Switche kaufen, und meinem Gefühl nach redet man von dumm zu
managed oft von einem Faktor 3 oder so.

Obwohl man natürlich auch einiges an Geld ausgeben kann, wenn man will.
Wobei ich irgendwie von allen halbwegs erschwinglichen managed Switches
etwas enttäuscht bin, das User Interface ist bei allen reichlich
umständlich, egal ob CLI oder Webgui.

> Erst bei größeren Switches macht es nicht mehr so viel aus.

Bei gebrauchten Switches (die ich derzeit kaufe) hat man sogar oft
das Phänomen, dass man die großen (mit 48 Ports) billiger kriegt als
die kleinen (wegen Platzbedarf, Stromverbrauch, Lärm) einfach weil
kaum jemand daheim 48 Ports braucht, die aber in Firmen haufenweise
rausgeworfen werden.

/ralph -- letzte Erwerbung: Ein HP/Aruba 1920, auch einigermaßen
umständliche Bedienung, funktioniert aber sonst gut.

[Ralph Aichinger]

Jan Novak <rep...@gmail.com> wrote:
> Seit dem hängt aber die Konsole der Server (bisher nur Remote getestet)
> immer mal wieder für 5-10 Sekunde und läuft dann normal weiter. Die
> Häufigkeit ist sehr unterschiedlich. Mal läufts für 10 Minuten, mal alle
> 1-2 Minuten.

> Irgend eine Idee, wie ich dem auf die Schliche kommen kann?

Was sagt "dmesg" dann wenn das passiert ist?

/ralph

[Jan Novak]

Am 19.02.24 um 03:23 schrieb Ralph Aichinger:

Das habe ich nicht mehr geprüft. Habe jetzt neue 2,5Gbit Karten drin.

Jan

[Jan Novak]

Am 16.02.24 um 16:56 schrieb Kay Martinen:

> Möglicherweise hat es beim Stromausfall eine kurze Spannungsspitze
> gegeben. Da du "Ohne USV" schriebst könnte die aus dem Stromnetz
> gekommen sein. Eine Vorgeschaltete USV könnte so was wegfiltern, aber
> wenn der Switch da nicht ebenfalls mit dran hängt...
>
> Hast du die Onboard-NICs mit UTP oder STP verkabelt?

Alles STP, durch die Bank weg.
Ich werde die nächsten Tage mal die alte NIC wieder anschliessen...
einfach nur mal zu kucken, ob sich da was tut.


Jan

[Marcel Mueller]

Am 19.02.24 um 02:56 schrieb Ralph Aichinger:

> Marcel Mueller <news.5...@spamgourmet.org> wrote:
>> Das muss einem halt auch den Faktor 10 Aufpreis wert sein. Neben der
>> Anschaffung ist üblicherweise auch der 24/7 Stromverbrauch deutlich
>> höher. Das läppert sich bei TCO.
>
> Naja, Faktor 10 muß nicht sein. Ich bin gerade selbst wieder beim
> Switche kaufen, und meinem Gefühl nach redet man von dumm zu
> managed oft von einem Faktor 3 oder so.

Bekommt man die jetzt schon für 30€?

>> Erst bei größeren Switches macht es nicht mehr so viel aus.
>
> Bei gebrauchten Switches (die ich derzeit kaufe) hat man sogar oft
> das Phänomen, dass man die großen (mit 48 Ports) billiger kriegt als
> die kleinen (wegen Platzbedarf, Stromverbrauch, Lärm) einfach weil
> kaum jemand daheim 48 Ports braucht, die aber in Firmen haufenweise
> rausgeworfen werden.

Ja, gebraucht ist nochmal eine andere Tüte.
Aber vom Stromverbrauch kann ich mir jedes Jahr einen anderen kaufen.


Marcel

[Ralph Aichinger]

Marcel Mueller <news.5...@spamgourmet.org> wrote:
> Am 19.02.24 um 02:56 schrieb Ralph Aichinger:
>> Marcel Mueller <news.5...@spamgourmet.org> wrote:
>>> Das muss einem halt auch den Faktor 10 Aufpreis wert sein. Neben der
>>> Anschaffung ist üblicherweise auch der 24/7 Stromverbrauch deutlich
>>> höher. Das läppert sich bei TCO.
>>
>> Naja, Faktor 10 muß nicht sein. Ich bin gerade selbst wieder beim
>> Switche kaufen, und meinem Gefühl nach redet man von dumm zu
>> managed oft von einem Faktor 3 oder so.
>
> Bekommt man die jetzt schon für 30€?

Irgendwo dort fangen die an, oder knapp drüber, vielleicht 40 Euro.

Gerade noch mal nachgeschaut, "Smart" Switches (Web-UI) kriegt man ab
ca 25 Euro, z.B. den da:

https://geizhals.at/tp-link-tl-sg605e-desktop-gigabit-smart-switch-tl-sg605e-a3112152.html?hloc=at&hloc=de&hloc=eu&hloc=pl&hloc=uk

Nein, die will man nicht unbedingt. Genausowenig wie man 10 Euro ungemanagte
Switches will. Aber man könnte glaub ich notfalls VLANs drauf
konfigurieren und andere einfache Layer2-Funktionen.

Die nächstteurere Klasse ist aber schon ganz brauchbar, einiges von
TP-Link, d-link, die Web-Managbaren von HP/Aruba/HPE (oder wie sie im
Moment gerade heißen) sind für manches auch ganz brauchbar.

Ja, die "echten", ernsthaften managbaren Switches gehen bei den
Neupreisen noch mal ein Stück drüber los, aber auch die kann man
gebraucht billig kaufen. Ich hab mir z.B. gerade einen HP/Aruba 2530 für
45 Euro gebraucht zugelegt, sowas in der Art findet man oft.

Schwierig ist es halt immer billig, lüfterlos, managebar, aktuell, mit
gutem CLI in einem Gerät vereint zu bekommen, aber irgendwas ist halt
immer.

> Aber vom Stromverbrauch kann ich mir jedes Jahr einen anderen kaufen.

Du mußt dir keinen 48-Port Rechenzentrumsswitch mit redundantem Netzteil
und Sound wie ein startendes Flugzeug kaufen. Ein HP 1820 oder so
braucht auch nicht mehr Strom als ein vergleichbarer ungemanagter.

Selbst mein gebrauchter 2530 von oben sollte unter 30 Watt bleiben für
24 Ports. Ja, es gibt sparsamere, aber das Management ist so viel
angenehmer als das Web-CLI der billigeren. Ich glaub ich werfe alle
meine billigeren raus, und stell flächendeckend auf HP 2530 um. Spart
soviel Nerven.

/ralph

[Stefan Froehlich]

On Wed, 21 Feb 2024 19:59:02 Ralph Aichinger wrote:
> Selbst mein gebrauchter 2530 von oben sollte unter 30 Watt bleiben
> für 24 Ports. Ja, es gibt sparsamere, aber das Management ist so
> viel angenehmer als das Web-CLI der billigeren. Ich glaub ich
> werfe alle meine billigeren raus, und stell flächendeckend auf HP
> 2530 um. Spart soviel Nerven.

Bei "soviel Nerven" stellt sich mir die Frage: Wie viele Switches
hast Du bei Dir daheim, und wie oft konfigurierst Du bei denen etwas
herum? Hier stehen zwei, und deren Konfiguration habe ich seit 5
Jahren nicht mehr angefasst.

Dafür lohnt es sich kaum, sich groß den Kopf zu zerbrechen (aber
andererseits ist es bei dieser Menge auch ziemlich egal, ob die
Teile 20 Euro mehr oder weniger kosten).

Servus,
Stefan

> /ralph

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Grau und frech!
(Sloganizer)

[Ralph Aichinger]

Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
> Bei "soviel Nerven" stellt sich mir die Frage: Wie viele Switches
> hast Du bei Dir daheim, und wie oft konfigurierst Du bei denen etwas
> herum? Hier stehen zwei, und deren Konfiguration habe ich seit 5
> Jahren nicht mehr angefasst.

Naja, das ist bei mir auch Spielzeug und Versuchslabor, in dem man Dinge
probieren kann, die man in der Arbeit im Echtbetrieb nicht ausprobieren
will. Bei mir ist das immer phasenweise, es gibt manchmal ein Jahr, in
dem ich den Switch kaum anfasse, und so Phasen wie die letzten 4 Monate,
wo ich einiges mit IPv6-Netzen rumgespielt habe, wo ich sicher 20
Varianten von VLAN-Einstellungen (am Switch und auf den Access-Points
mit dem VLAN entsprechenden SSIDs) ausprobiert habe. Erst heute wieder
hab ich mich versehentlich aus einem Access Point ausgesperrt, weil ich
das VLAN falsch konfiguriert hab. Leiter geholt, AP abmontiert, failsafe
gebootet, Einstellung konrrigiert, wieder montiert. Elegant ist anders,
bei gemanagten Switches hat man für solche Fälle z.B. eine serielle
Konsole.

> Dafür lohnt es sich kaum, sich groß den Kopf zu zerbrechen (aber
> andererseits ist es bei dieser Menge auch ziemlich egal, ob die
> Teile 20 Euro mehr oder weniger kosten).

Auch bei Sachen, die man selten benötigt kann es manchmal angenehm sein,
dass man weiß, dass sie im Fall des Falles elegant zu lösen sind.

/ralph

[Stefan Froehlich]

On Wed, 21 Feb 2024 20:55:54 Ralph Aichinger wrote:
> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
>> Bei "soviel Nerven" stellt sich mir die Frage: Wie viele Switches
>> hast Du bei Dir daheim, und wie oft konfigurierst Du bei denen
>> etwas herum? Hier stehen zwei, und deren Konfiguration habe ich
>> seit 5 Jahren nicht mehr angefasst.

> Naja, das ist bei mir auch Spielzeug und Versuchslabor, in dem man
> Dinge probieren kann, die man in der Arbeit im Echtbetrieb nicht
> ausprobieren will.

Ok, wenn Du das gleiche im Job auch brauchst, ist das sinnvoll. Dann
aber am besten auch die gleichen Marken (egal ob elegant oder nicht)?

> Erst heute wieder hab ich mich versehentlich aus einem Access
> Point ausgesperrt, weil ich das VLAN falsch konfiguriert hab.

:-)

> Leiter geholt, AP abmontiert, failsafe gebootet, Einstellung
> konrrigiert, wieder montiert. Elegant ist anders, bei gemanagten
> Switches hat man für solche Fälle z.B. eine serielle Konsole.

Bei meinen Unifi APs komme ich auf die Befehlszeile, und wenigstens
ein factory reset wäre dort möglich. Aber die haben eh alle das
gleiche, seit 6 Jahren unveränderte Setup...

> Auch bei Sachen, die man selten benötigt kann es manchmal angenehm sein,
> dass man weiß, dass sie im Fall des Falles elegant zu lösen sind.

Wirklich angenehm ist nur, wenn ich auch noch weiß, *wie* sie
elegant zu lösen sind. Es macht zwar durchaus Spaß, sich die Eleganz
ein paar Jahre später neu zu erarbeiten, wenn das im Anlassfall
passiert, fehlen mir dafür aber meist die Zeit u/o die Nerven.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Für maskierte Baeuche in gezierten Gewittern!
(Sloganizer)

[Marc Haber]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
>On Wed, 21 Feb 2024 19:59:02 Ralph Aichinger wrote:
>> Selbst mein gebrauchter 2530 von oben sollte unter 30 Watt bleiben
>> für 24 Ports. Ja, es gibt sparsamere, aber das Management ist so
>> viel angenehmer als das Web-CLI der billigeren. Ich glaub ich
>> werfe alle meine billigeren raus, und stell flächendeckend auf HP
>> 2530 um. Spart soviel Nerven.
>
>Bei "soviel Nerven" stellt sich mir die Frage: Wie viele Switches
>hast Du bei Dir daheim, und wie oft konfigurierst Du bei denen etwas
>herum? Hier stehen zwei, und deren Konfiguration habe ich seit 5
>Jahren nicht mehr angefasst.

Ich habe drei, davon wird einer nur bei Bedarf eingeschaltet (seit
"vor Corona" nicht mehr, inzwischen habe ich Angst dass mir beim
Einschalten das Netzteil abbrennt

Ich habe einen 52-Port PoE Switch von TP-Link und als dieser nahezu
voll war kam ein 24-Port-GbE-plus-4-Port-10-GbE-Port Switch dazu, an
dem inzwischen hauptsächlich die im Rack befindlichen Systeme hängen.

Konfiguration? Wenn es darum geht mal einen Accesspoint zu entstromen
oder wenn ich am Labortisch ein anderes VLAN brauche. Also so etwa
ein-, zweimal im Monat.

[Jan Novak]

Am 22.02.24 um 13:24 schrieb Stefan Froehlich:

> Wirklich angenehm ist nur, wenn ich auch noch weiß, *wie* sie
> elegant zu lösen sind. Es macht zwar durchaus Spaß, sich die Eleganz
> ein paar Jahre später neu zu erarbeiten, wenn das im Anlassfall
> passiert, fehlen mir dafür aber meist die Zeit u/o die Nerven.

Dem kann ich mich bedingungslos anschliessen.
Beim Einrichten: "wozu aufschreiben, ist ja klar, wie's funktioniert"
und nach ein paar Jahren ... "verdammt, wie war das nochmal ..."


Jan