Posts Tagged ‘Redundanz’

Sonntag, 8. Juli 2018

Endlich ist es da: Die M2M- resp. OOB-SIM für Normalsterbliche

Seit Jahr und Tag bin ich auf der Suche nach einer Daten-SIM-Karte, welche ich als Out-of-Band-Lösung in meinen drei Netzwerk-Standorten installieren kann.

Die SIM möchte ich in ein UMTS-Modem einbauen, welches ich entweder extern per USB oder intern per Einbau an den ThinkPad-„Server“ der jeweiligen Location anhänge.

Fällt das Internet aus, oder verliere ich aus irgendeinem Grund den Remote-Zugriff ins LAN, aktiviert sich die SIM-Karte von alleine, meldet seine IP bei einem Dienst wie DynDNS, öffnet einen VPN-Tunnel und bietet mir so die Möglichkeit, Probleme aus der Ferne zu diagnostizieren.

Mit SimplyMobile von Swisscom scheint das nun Realität zu werden:

  • Prepaid-SIM, d.h. keine monatlich wiederkehrenden Kosten
  • Datenpaket von 750 MB für 9.90 CHF
  • Datenguthaben verfällt nicht

Quelle: SIMPLYMOBILE PREPAID

Fazit: Das Basteln kann beginnen!

Tags: , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 25. Juli 2013

Debian-Installation mit zwei Netzwerkkarten ausfallsicher(er) machen

Auf Grund eines defekten Kabelmodem-Netzteils und einem wackeligen Switch-Netzteil war mein Debian-Server im Elternheim kürzlich für mehr als 3 Tage offline. Für einen IT-Auditoren, welcher tagtäglich mit Load Balancing, Geo-Redundanz und Failovers in Kontakt kommt, eine untolerierbare lange Zeit!

Hintergrund: Als meine linke Hand mittels Telefonsupport das tote Kabelmodem analysierte, hatte er wohl aus Unachtsamkeit das Netzteil des Gigabit-Switches aus der Fassung gerissen (zu seiner Entschuldigung: Irgendetwas ist am Switch-Netzteil defekt, es sitzt nicht mehr fest in der Steckerleiste). Obwohl am nächsten Tag dank des Austauschs des Kabelmodem-Netzteils der Router und ein Teil des Netzwerks wieder online, blieb der Switch offline (ich war beim Austausch des Netzteils nicht vor Ort, konnte deshalb keine Diagnose machen — ansonsten hätte ich den dunklen Switch innert Minuten als Fehlerquelle isoliert).

Was tun? Einerseits habe ich mir auf Ricardo einen iKVM-Switch (Avocent SwitchView IP 1010 Remote Access Device) ersteigert, welchen ich in den nächsten Wochen mit dem Server verbinden werde. Das Netzwerkkabel wird direkt an den Router eingestöpselt, um Fehler in der restlichen Netzwerktopologie auszuschliessen.

Andererseits habe ich mich entschieden, den Server über zwei Netzwerkkarten an das Netzwerk anzubinden. Da ich mir vor langer Zeit eine performante Intel Gigabit-Netzwerkkarte geleistet habe, war mit dem Onboard-NIC meines Asus P5QPL-VM EPU bereits eine zweite Netzwerkschnittstelle vorhanden, die aktiviert werden wollte.

Natürlich ging es aber nicht darum, den Server mittels dieser zweiten NIC an den Router zu verbinden und dieser NIC eine zweite IP-Adresse zu geben — der Server sollte beim Ausfall der einen NIC logisch immer noch unter derselben IP-Adresse ansprechbar sein — physisch halt aber über die Onboard-NIC.

Bonding musste her!

Im Netz gibt es viele (alte und neuere) Anleitungen dazu, aber folgendermassen habe ich den Plunder nach langem Pröbeln zum Laufen gebracht:

bonding-Modul

In der Datei /etc/modules lädt man das bonding-Modul beim Start des Betriebssystems:

bonding
fuse
...

Die Konfiguration des Moduls — ich bin immer noch nicht sicher, ob es das wirklich braucht — legt man in /etc/modprobe.d/bonding ab:

alias bond0 bonding
options bonding mode=1 miimon=100

Erläuterungen:

  • alias bond0 bonding bond0 entspricht bonding — für was man dies genau benötigt, entzieht sich meiner Kenntnis
  • mode=1 Das Bonding-Modul kennt 6 verschiedene Modi. Modus 1 ist der active-backup-Modus: Es gibt eine aktive Netzwerkkarte und eine, die als Backup bereit steht und die Aufgabe der ersten Netzwerkkarte übernehmen kann.
  • miimon=100 Überwache die aktive Netzwerkkarte alle 100 Millisekunden auf einen Verlust des Links (bspw. Kabel ausgezogen, Switch ohne Strom).

Debian-Packages

Ob man diese Packages effektiv braucht, kann ich nicht sagen — installiert habe ich sie aber auf anraten von Anleitungen im Netz:

# apt-get install ifplugd ifenslave-2.6

/etc/network/interfaces

Vorbemerkung: Am Besten macht man sich zuallererst eine Kopie der aktuellen /etc/network/interfaces — bei meinen Tests musste ich zig Reboots durchführen und teilweise wieder die alte Interface-Konfiguration laden, um Dinge aus dem Netz herunterzuladen.

Meine finale, sauber funktionierende /etc/network/interfaces sieht folgendermassen aus:

auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
	address 192.168.100.101
	netmask 255.255.255.0
	network 192.168.100.0
	broadcast 192.168.100.255
	gateway 192.168.100.1
	bond-mode active-backup
	bond-miimon 500
	bond-slaves none

auto eth1
iface eth1 inet manual
	bond-master bond0
	bond-primary eth1 eth2

auto eth2
iface eth2 inet manual
	bond-master bond0
	bond-primary eth1 eth2

Wie man klar erkennen kann, werden hier die bonding-Parameter nach /etc/modprobe.d/bonding erneut gesetzt, und dies teilweise sogar mit anderen Werten. Einige Notizen:

  • Die Netzwerkkarten heissen bei mir leider Gottes aus mir unerfindlichen Gründen eth1 (Intel-Steckkarte) und eth2 (Onboard). In anderen Systemen werden die Karten wohl eher eth0 und eth1 heissen.
  • auto bond0 Nach Reboots war bond0 nicht aktiv und musste von mir immer zuerst mittels ifup bond0 geladen werden. Irgendwann einmal realisierte ich, dass ich Linux mittels auto bond0 sagen musste, das virtuelle Gerät automatisch zu starten.
  • Unklar ist, ob es eine Rolle spielt, wo die Konfiguration von bond0 innerhalb von /etc/network/interfaces steht. Ich habe es schlussendlich an den Anfang der Datei gesetzt, nach dem Loopback-Interface.
  • bond-mode active-backup ist dasselbe wie bond-mode 1
  • bond-miimon 500 Die Überprüfung des Netzwerkkabels alle 500 Millisekunden finde ich vernünftig
  • bond-slaves none Tönt komisch (nach meiner Lesart sind eth1 und eth2 die Slaves) — aber es klappt
  • bond-master bond0 Damit wird ein physisches Interface dem virtuellen Interface zugeteilt
  • bond-primary eth1 eth2 Damit gebe ich an, welche der beiden Netzwerkkarten verwendet wird, wenn beide einen funktionierenden Uplink haben. Natürlich habe ich mich für die performantere Intel-Karte entschieden und nicht die Onboard-NIC.

Status

Den Status des Bondings erfährt man über das proc-Dateisystem unter /proc/net/bonding/bond0:

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth1 (primary_reselect always)
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 500
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:00:00:00:00:00
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:00:00:00:00:00
Slave queue ID: 0

Via: Debian-Installation mit zwei Netzwerkkarten ausfallsicher(er) machen

Links

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen