hängendes Netzwerk
Hallo allerseits! Ich brauche mal Nachhilfe bzw. Tipps bei folgendem Problem: Erkennbar ist, dass an einem Linux-Server mit Samba 3.5.7 (SuSE 11.4) manchmal keine Anmeldung möglich ist, ein andermal das Profil nicht geladen wird und man damit kaum arbeiten kann. Problem 1 ist gefunden: Die Nutzerprofile hatte ich auf eine zweite Festplatte ausgelagert. Diese SATA-Festplatte ist aber gegenüber dem SAS-Raid schneckenlahm (etwa 80MB/s gegenüber 240MB/s) und bremst damit bei paralleler Anmeldung mehrerer Schüler natürlich aus. Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen? Der zweite Teil des Problems liegt in dropped packets auf den Netzwerkkarten. Es kann sein, dass ich hier ein Verständnisproblem habe. Daher etwas ausführlicher zum Netzwerkaufbau: Es gibt 4 Netzwerk-Interfaces (Intel 1000er-Karten). Aus technischen Gründen ist ein Interface (eth3) auf 100MBit gedrosselt und landet am Switch auf einem getrennten VLAN (Wiederherstellung vom Laptops mit 100MBit-Karte per Multicast-Netzwerk). Die Interfaces eth0-eth2 sind gebündelt, das Netzwerkinterface ist also bond0. Was auffällt: Die Zahl der dropped packet von eth3 und bond0 stimmt (fast) überein (unterscheiden sich um genau 100), beide wachsen im exakt gleichen Maß. An den realen Interfaces eth0-eth2 gibt es keine dropped-Pakete, der angezeigte Durchsatz ist völlig in Ordnung. Zwischen eth3 und bond0 ist natürlich ein forward-Regel eingebaut. Auf der Firewall ist laut iptables -L keine Regel mit DROP. Die SuSE-Firewall ist aus, eine manuelle Regel sorgt dafür, dass zwei sezielle Rechner Samba-Zugriffe mit Reject beantwortet bekommen (ist notwendig). Frage 2: Warum gibt überhaupt ca. 1% Netzwerkpakete bei dropped? Wo werden die möglicherweise gedropped? Gibt es einen Grund, warum eth3 und bond0 fast identische Zahlen dabei haben? um nicht zu sehr zu raten die Zahlen von bond0: -- schnipp RX packets:73486162 errors:0 dropped:19165992 overruns:0 frame:0 TX packets:71049331 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:54676801251 (52143.8 Mb) TX bytes:68091939812 (64937.5 Mb) -- schnapp Bin für jede gute Idee dankbar Reiner ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Am 03.12.2011, 10:34 Uhr, schrieb Reiner Klaproth klapr...@online.de: Hallo Reiner, snip Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen? d.h. Du willst dafür bestehende Partitionen verkleinern? Ist nur 'offline' vorgesehen - siehe z.B. http://wiki.ubuntuusers.de/Dateisystemgröße_ändern Nutzt Du LVM? Grüße, Bernhard ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Hallo Rainer,
Reiner Klaproth klapr...@online.de (Sa 03 Dez 2011 10:34:34 CET):
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der
Server läuft (aber niemand angemeldet ist), um Platz für eine weitere
Partition zu schaffen?
Ungefährlich. Denn es geht nicht. Du kannst ext{3,4} nur offline
resizen, aber dann ist es ungefährlich, wenn man rechnen kann.
Der zweite Teil des Problems liegt in dropped packets auf den Netzwerkkarten.
Es kann sein, dass ich hier ein Verständnisproblem habe. Daher etwas
ausführlicher zum Netzwerkaufbau:
Es gibt 4 Netzwerk-Interfaces (Intel 1000er-Karten).
Aus technischen Gründen ist ein Interface (eth3) auf 100MBit gedrosselt und
landet am Switch auf einem getrennten VLAN (Wiederherstellung vom Laptops
mit 100MBit-Karte per Multicast-Netzwerk).
Die Interfaces eth0-eth2 sind gebündelt, das Netzwerkinterface ist also bond0.
Was auffällt: Die Zahl der dropped packet von eth3 und bond0 stimmt (fast)
überein (unterscheiden sich um genau 100), beide wachsen im exakt gleichen
Maß.
An den realen Interfaces eth0-eth2 gibt es keine dropped-Pakete, der
angezeigte Durchsatz ist völlig in Ordnung.
Wie oft wird das eth3 gebraucht? Wenn ich den Zweck oben richtig
verstehe, dann ja eher selten, oder?
Zwischen eth3 und bond0 ist natürlich ein forward-Regel eingebaut.
Auf der Firewall ist laut iptables -L keine Regel mit DROP. Die SuSE-Firewall
ist aus, eine manuelle Regel sorgt dafür, dass zwei sezielle Rechner
Samba-Zugriffe mit Reject beantwortet bekommen (ist notwendig).
DROP in der Firewall hat mit dropped der Netzkarte m.E. nichts zu tun.
Die dropped in der NIC könnten Empfängerüberläufe sein.
Frage 2: Warum gibt überhaupt ca. 1% Netzwerkpakete bei dropped?
Wo werden die möglicherweise gedropped? Gibt es einen Grund, warum
eth3 und bond0 fast identische Zahlen dabei haben?
Das ist merkwürdig. Gibt es Traffic, der mit beiden Karten etwas zu tun
hat. VLANs machen auch manchmal komische Dinge. Ist das ein 802.1q VLAN?
Wie ist gebondet: Als Bündel und alle gemeinsam, oder wie? Ich denke, es
gibt ja da verschiedene Bond-Modi.
--
Heiko
signature.asc
Description: Digital signature
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Hallo! Am Samstag, 3. Dezember 2011, 12:07:44 schrieb Bernhard Bittner: Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen? d.h. Du willst dafür bestehende Partitionen verkleinern? Ist nur 'offline' vorgesehen Bereits erledigt. Dienste stoppen - umount /home - gparted nutzen und machen lassen. Die Partition wurde ohne Datenverlust verkleinert, die neue Partition für die Profile eingerichtet. /etc/fstab anpassen und neu booten. Die Frage bezog sich vor allem darauf, dass ich alles per ssh machen muss, ohne die zwei Tage physisch an den Server zu kommen. Gruss Reiner ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Hallo!
Am Samstag, 3. Dezember 2011, 16:01:48 schrieb Heiko Schlittermann:
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der
Server läuft (aber niemand angemeldet ist), um Platz für eine weitere
Partition zu schaffen?
Ungefährlich. Denn es geht nicht. Du kannst ext{3,4} nur offline
resizen, aber dann ist es ungefährlich, wenn man rechnen kann.
Richtig, habe ich nur falsch beschrieben. Man muss die Partition umounten,
dann geht alles.
Die Interfaces eth0-eth2 sind gebündelt, das Netzwerkinterface ist also
bond0. Was auffällt: Die Zahl der dropped packet von eth3 und bond0
stimmt (fast) überein (unterscheiden sich um genau 100), beide wachsen
im exakt gleichen Maß.
An den realen Interfaces eth0-eth2 gibt es keine dropped-Pakete, der
angezeigte Durchsatz ist völlig in Ordnung.
Wie oft wird das eth3 gebraucht? Wenn ich den Zweck oben richtig
verstehe, dann ja eher selten, oder?
Jaein. Neben den Laptops, die sonst per WLAN am Netz hängen gibt
es noch LCD-Bildschirme mit integriertem Computer, die auch über dieses
Interface gehen müssen.
Witzigerweise haben die Gigabit-Netzwerkkarten, aber die PXE-Software für
diese Karten kann nur 100MBit (hat mich damals Tage gekostet, das
herauszufinden...)
Einen Reboot später weiß ich mehr:
Jetzt zählt nicht mehr der Zähler an eth3 hoch, sondern der an eth2
(Weiß der Fuchs warum...)
Jetzt verstehe ich aber die Zahlen: An eth2, das zu bond0 gebündelt ist,
verschwinden RX-Pakete.
Die Frage, die ich jetzt klären muss: Warum verschwinden die Pakete und
warum ausschließlich an eth2.
Die andere Frage: Warum zeigte das ifconfig erst an eth3 statt eth2?
Kernel SuSE-default zu OpenSuSE 11.4
Wie ist gebondet: Als Bündel und alle gemeinsam, oder wie? Ich denke, es
gibt ja da verschiedene Bond-Modi.
Richtig. Ich hatte einige Anleitungen gelesen und vieles getestet. Am Ende
hat es erst funktioniert, wenn man NICHTS vorher eingestellt hat und
die Intel-Karten hat machen lassen. In dem Fall haben sich die Karten mit
dem (HP ProCurve) Switch selbst geeinigt. Der schaltete seinerseits
die Eingänge zum Bündel automatisch zusammen, wenn man keine
Parameter angegeben hat.
Mit Parameter gab es Probleme mal am Switch, mal mit den Karten
Gruss
Reiner
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Am 03.12.2011, 18:00 Uhr, schrieb Reiner Klaproth klapr...@online.de:
Servus,
Am Samstag, 3. Dezember 2011, 16:01:48 schrieb Heiko Schlittermann:
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn
der
Server läuft (aber niemand angemeldet ist), um Platz für eine weitere
Partition zu schaffen?
Ungefährlich. Denn es geht nicht. Du kannst ext{3,4} nur offline
resizen, aber dann ist es ungefährlich, wenn man rechnen kann.
Richtig, habe ich nur falsch beschrieben. Man muss die Partition
umounten,
dann geht alles.
ja, wenn man eine Partition zur Verfügung hat, die umounten im laufenden
System mitmacht, geht es latürnich so wie Du es geschrieben hast.
Abgesehen von Kandidaten wie eben /home, ggf. noch /opt oder /srv hörts
dann aber m.W. schon auf.
Nicht daß noch jemand durch 'es geht nicht' - 'dann geht alles' verwirrt
wird ;-)
Seit ich mit nem ähnlichen Szenario zu tun hatte, bin ich begeisterter
Nutzer von LVM (an dieser Stelle props an Dimitri Puzin, der mich da
rangeführt hat :-).
Grüße,
Bernhard
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Hallo! Am Samstag, 3. Dezember 2011, 18:00:53 schrieb Reiner Klaproth: Einen Reboot später weiß ich mehr: Jetzt zählt nicht mehr der Zähler an eth3 hoch, sondern der an eth2 (Weiß der Fuchs warum...) Auch das ist erklärbar: Die Netzwerkkarten sind Intel-Serverkarten, die mit einem Baustein zwei Netzwerk-Interfaces anbieten. Somit sind also eth2 und eth3 physisch an einen Baustein gekoppelt (und haben dieselbe MAC-Adresse!). Daher hatte der Kernel das Problem, die Karten zuzuordnen. Darin steckt offenbar auch das Problem: Laut lspci haben diese Karten keinen Interrupt zugeteilt bekommen. Das ACPI-Management liefert als IRQ 66 und 76. Fakt ist offenbar, dass Intel die Karten selbst auch als Bündel betreibt. Offenbar schaltet nicht nur eth3 auf 100MBit herunter, sondern parallel auch eth2. Das erklärt die verlorenen Pakete. Erster Würg-Around: Nur noch eth0 und eth1 sind auf bond0 gebündelt, denn diese funktionieren (auch eine Intel-Dual-Port-Serverkarte). Wahrscheinlich muss der Server eine weitere Netzwerkkarte erhalten für das 100MBit-Interface. Schön, dass so etwas nirgends ordentlich dokumentiert ist... Gruss Reiner ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
