Wie ändere ich den Bonding-Mode in XenServer 5.5?

Standardmäßig nutzt XenServer 5.5 ein “source-based ARP load balancing” (balance-slb) für die erstellten Bonds. In unserem Fall, wollen wir uns jedoch am IEEE-Standard 802.3ad  / LACP (Link Aggregation Control Protocol ) orientieren.

Im generellen, bietet XenServer 5.5 folgende unterstützte Bonding-Typen an:

• balance-rr
• active-backup
• balance-xor
• broadcast
• 802.3ad
• balance-tlb
• balance-alb
• balance-slb

Um nun den gewünschten Modus zu aktivieren, muss innerhalb der /opt/xensource/libexec/interface-reconfigure der Bond-Mode in Zeile 863 angepasst werden.

Das geht schnell und einfach mit:

vi /opt/xensource/libexec/interface-reconfigure

Hinweis: Um Schnell in die richtige Zeile zu kommen einfach “863G” in VIM eingeben. Mit “i” in den Insert-Modus wechseln, Änderungen vornehmen und mit “:wq” speichern und beenden.

Um zu überprüfen ob der Bond funktioniert kann man folgenden Befehl nutzen:

cat /proc/net/bonding/bond<bondnumber>

Vorher:

Nachher:

Die dazu benötigte Bondnummer erhält man mit dem Befehl:

ifconfig

Es empfiehlt sich die Netzwerkkarten danach nocheinmal zu deaktivieren und wieder zu aktivieren, damit die Änderungen angenommen werden können:

/etc/init.d/networking restart

Thomas Gronenwald

Wie Ihr vielleicht wisst, gehören die Worte “Intel” und “PROSet” nicht zu den Worten, die mich ruhig schlafen lassen.  Jedoch muss ich heute der Firma Intel mal zu der (aus meiner Sicht) zuverlässigsten Intel PROSet-Version ab Version 10.0 gratulieren.

Nach immerhin 18 Monaten hat es Intel nun tatsächlich geschafft, ein zuverlässiges Intel PROSet (Version 14.8.43.0) zu veröffentlichen.

Zur Historie: Vor etwa 1,5 Jahren hat Intel eine neue Version (10.0) von PROSet mit  WMI-Integration veröffentlicht (damit das Teaming auch schön über den Klickibunti Windows-Gerätemanager gesteuert werden kann). Da eben diese Integration von PROSet einen Fehler im WMI verursachte, wurde im Zusammenspiel mit Viren- oder Netzwerkscannern die Netzwerkverbindungen getrennt oder die Reiter für Teaming und VLAN im Gerätemanager einfach ausgeblendet. Ergebnis: Eine nachträgliche Konfiguration des Teamings war nicht mehr möglich. Und dabei blieb es nicht: Es kam zu regelmäßigen Verbindungsabbrüchen.

Jetzt hat Intel diese Fehler mit der Intel PROSet-Version 14.8.43.0 behoben.

Ich gratuliere hiermit zur erfolgreichen Beseitigung eines Fehlers nach immerhin 1,5 Jahren.

Links:

Network Connectivity Issues on Intel Teamed NICs when Symantec AntiVirus or Endpoint Protection Client is installed [Symantec]

Network Adapter Drivers for Windows XP and Windows Server 2003 [Intel]

Sascha Giebelhausen

Intel…die fünf Buchstaben des Teufels. I-N-T-E-L. Ich verzweifele seit geraumer Zeit an Deinstallationen von alten PROSet Installation. Richtig…P-R-O-S-E-T: Die sechs Buchstaben des Satans – spaß beiseite…

Bei mir stand diese Herausforderung heute (mal) wieder auf der Tagesordnung. Ich musste Intel PROSet 11.2.50.0 deinstallieren und durch die Version 14.8.43.0 ersetzen. Eine Aufgabe, wie sie einfacher nicht sein könnte (deswegen habe ich damit um 11:30 Uhr angefangen – dann bin ich pünktlich um 12 Uhr in der Kantine). Leider konnte PROSet nach der Deinstallation nicht mehr neu installiert werden. Dies galt für die neue, als auch für die alte Version. Ich erhielt immer nur den Fehler, dass für die Anwendung kein Update vorgesehen ist und diese vorher deinstalliert werden muss.

Die Lösung ist erstaunlicherweise einfach, aber fragt mich bitte nicht wie ich darauf gekommen bin (meine sich andeutende Unterzuckerung hat mein Kurzzeitgedächtnis scheinbar genullt).

Workaround:

1. Entpacken des Installationspakets des neues Intel PROSet
2. Entfernung aller virtueller Gruppen und VLAN’s via Gerätemanager
3. Deinstallation der Anwendung PROSet (über Systemsteuerung\Software)
4. Deinstallation der Netzwerkkarten im Gerätemanager
5. Installation der neuen Treiber über den Gerätemanager und die Treiber im Installationspaket
6. Navigation in den Unterordner  [Installationspaket]\APPS\PROSETDX\Win32
7. Ausführung der Silent-Installation von PROSet über den Befehl “DxSetup.exe -qn”
8. Zuweisung/Erstellung der Gruppen und VLAN’s
9. Einrichtung der Netzwerkeinstellungen

Ich habe im übrigen noch eine viel bessere Geschichte auf Lager, welche die Kompetenz und/oder Inkompetenz der Intel-Entwickler auf das deutlichste unter Beweis stellt. Dazu morgen mehr….

Sascha Giebelhausen

Es begnetet mir nahezu jeden Tag. Ein Kunde möchte Systeme ausfallsicher aufbauen, möchte seine jährliche Verfügbarkeit steigern. Eine Lösungsoption dafür ist Clustering. Also die Bereitstellung eines Dienstes auf mehreren System (sog. “Nodes”) verteilt. So können Downtimes von verfügbaren Nodes abgefangen werden.

Unter Windows brauch man dafür folgendes:

• ein SAN oder Speicher, welcher von beiden Systemen erreichbar ist (für Quorum und Shared Files)
• ein Backbone Switch (um auf das SAN zuzugreifen, als FibreChannel oder GBit LAN (iScsi))
• min. zwei Systeme
• min. zwei Windows Server, Enterprise Lizenz ($$$$$$!)

Zugegeben, die eigentliche Einrichtung ist dafür denkbar einfach (weil Assistengesteuert).

Es gibt da aber auch was, was nichts kostet und aus Hardwaretechnischer Sicht nicht so aufwändig ist: UCARP. Als kostenlose Alternative zu VRRP (Cisco Patent!) und OpenSource, also beliebig veränderbar. UCARP macht eigentlich nichts anderes, als ein Node (z. B. per PING) zu überwachen, und wenn dieser nicht mehr da sein sollte, alle seine Dienste zu übernehmen (also Dienste mit vorhandenen (vorher synchronisierten) Konfigurationsparametern zu starten). Natürlich wird noch eine virtuelle IP Adresse “übernommen” und per ARP Publish auf die Switche/Router verteilt. Ein “Clusterschwenk” dauert circa 4-7 Sekunden, abhängig von den ganzen zu startenden Diensten (es ist ein Irrglaube, das MS-Cluster es schneller schaffen). Da UCARP keine besondere Schnittstelle bietet, ist eigentliche jede Software komptibel-eine besondere “Clusterfähigkeit” wird also nicht vorraussgesetzt (ich habe es mit XORP, NTPD und MySQL getestet-ich bin begeistert).

Tolle Konfigurationsbeispiele und den Download findet ihr auf http://www.ucarp.org/project/ucarp und natürlich bei mir.

Florian Thiessenhusen

Die Kombination aus Fujitsu Siemens Serverhardware (RX100 S3), Windows Server 2008 Betriebssystem und Broadcom-Netzwerkkarten in Verbindung mit BACS3 (Broadcom Advanced Control Suite 3) kann unter bestimmten Umständen die Hölle auf Erden bedeuten. Nach wochenlanger Recherche, unzähligen Calls bei Herstellern und zahlreichen Troubleshooting-Stunden, ist die Welt “vorerst” wieder in Ordnung.

Hintergrund:
In einer Umgebung mit oben geschilderter Konstellation stürzen in regelmäßigen Abständen die Server ab (eingefroren / nichts geht mehr). Mal passiert eine Woche gar nichts, dann wieder fünf mal am Tag – und das nicht nur bei einem, sondern bei unzähligen Systemen. Ein Hardwareaustausch verlief ohne Erfolg – scheinbar alles in Ordnung. Eventlog-Einträge und Dump-Files brachten auch keinen Aufschluß – mmh.

Bis heute! In einem englischen Forum dann der nächste Strohhalm nach dem wir greifen:

After I found out we have 2 free calls to MS with the schools agreement I logged a call with them. After quite a lengthy process to establish the problem and every possible piece of information from the logs, registry, etc, being uploaded to them, they came back with remove the broadcom management suite as the logs showed some issues with it and they had seen it before on other setups! So far so good, the big test will be when the kids are back after half term.

Keeping my fingers crossed!

Und siehe da: Nach Auflösung der NLB-Teams von BACS3 und anschließender Deinstallation der Suite funktionieren die Systeme wieder wie sie sollen – bis jetzt.

Großer Dank gilt meinem Kollegen Florian Thiessenhusen, der den entscheidenen Beitrag recherchiert hat und natürlich dem Kollegen aus Wales!

Thomas Gronenwald