Bonding zwischen Xenserver, Bladecenter-Switch, Cisco Catalyst C3550
Hallo miteinander,
ich stehe momentan vor folgendem Problem und bin mir nicht sicher, wie ich das lösen soll. Folgendes Szenario:
ein Bladecenter H beinhaltet 4 Blades, auf denen Xenserver 6.2 installiert ist. Das Bladecenter H Gehäuse hat zwei Netzwerkswitche, das sind Nortel Layer2-3 Gbe Switche, welches die einzelnen Blades als jeweiliges Netzwerkinterface sehen. Jeder Blade besitzt quasi somit zwei Netzwerkkarten und jeder Xenserver hat also zwei phsyikalische Netzwerkinterface: NIC0 und NIC1.
Diese zwei Nortel-Switche sind physikalisch wie folgt mit dem Cisco Catalyst C3550 verbunden. Ich habe jeweils 4 Ports auf dem C3550 verwendet, um einen LACP Port-Channel zu den zwei jeweiligen Bladecenter-Switches zu verbinden. Port-Channel1 hat somit 4 einzelne Leitungen, die in den ersten Bladecenter-Switch gehen, und Port-Channel2 hat ebenfalls 4 einzelne Leitungen, die in den zweiten Bladecenter-Switch verlaufen. Diese zwei LACP Kanäle sind beide aktiv und vollständig funktionsfähig. Die Konfiguration habe ich jeweils auf den zwei Nortel-Switches und dem C3550 durchgeführt.
Bis zu diesem Aufbau, weiß ein einzelner Blade (=Xenserver) jedoch absolut nichts darüber, dass hinter ihm LACP-Kanal vorhanden wäre. Für den Xenserver ist es irrelevant was dahinter kommt, er sieht lediglich eine NIC0 und eine NIC1.
Wenn ich mit diesem Setup nun auf jedem einzelnen Xenserver 10 VMs betreiben würde (in Summe also 40 VMs), die allesamt NIC0 als Netzwerk eingetragen haben, dann würde Xenserver den Traffic für all diese VMs über NIC0 abwickeln, und somit über den Port-Channel1. Das wäre Blödsinn, weil mein Port-Channel2 somit nie zum Einsatz kommen würde.
Wenn ich mit diesem Setup jedoch die Hälfte der VMs (also 20VMs) die NIC0 zuweisen würde, und den restlichen 20VMs die NIC1 zuweisen würde, dann hätte ich manuell für Load-Balancing innerhalb der VM-Gruppe gesorgt. Das würde nun auch den Port-Channel2 nutzen, aber diese manuelle Variante ist auch nicht das gelbe vom Ei, denn ich müsste mich bei jeder Installation einer neuen VM selbst darum kümmern, eine ausgeglichene Netzwerkkarten-Verteilung zu gewährleisten, also abwechseln mal NIC0 oder NIC1 für eine VM verwenden. Das ist aber blöd und kann bei großer VM-Anzahl oder häufigen Änderungen sehr aufwendig sein.
Also habe ich mir folgendes als Lösung überlegt: ich erstelle in Xenserver ein Bonding. Dort hat man folgende Auswahlmöglichkeiten...
Interessant für meine Zwecke wären "Active-Active" oder "LACP with load-balancing based on <egal was für ein Algorithmus>". Eigentlich nutze ich vorzugsweise immer LACP, aber hier bin ich mit meinem Latein am Ende. Wenn ich tatsächlich versuchen würde NIC0+NIC1 mittels LACP zu bündeln, dann müsste ja der Gegenpartner von NIC0 und NIC1 ebenfalls mit LACP konfiguriert würden. Wie zum Geier soll das denn aber gehen? Das Gegenstück von NIC0 ist nämlich der erste Nortel-Switch und das Partner von NIC1 ist der zweite Nortel-Switch. Das geht doch schlecht, oder nicht???
Wenn also diese LACP-Möglichkeit wegfallen müsste, bleibt mir also nur Active-Active und damit müsste das doch eigentlich klappen, oder? Denn das Xenserver-Handbuch zu diesem Active-Active Modus sagt:
Ist demnach dieses Active-Active-Bonding, das was ich anstreben sollte? freue mich über euer feedback und Hilfestellung. Besten Dank im Voraus und eine schöne Woche wünscht...
Pangu
ich stehe momentan vor folgendem Problem und bin mir nicht sicher, wie ich das lösen soll. Folgendes Szenario:
ein Bladecenter H beinhaltet 4 Blades, auf denen Xenserver 6.2 installiert ist. Das Bladecenter H Gehäuse hat zwei Netzwerkswitche, das sind Nortel Layer2-3 Gbe Switche, welches die einzelnen Blades als jeweiliges Netzwerkinterface sehen. Jeder Blade besitzt quasi somit zwei Netzwerkkarten und jeder Xenserver hat also zwei phsyikalische Netzwerkinterface: NIC0 und NIC1.
Diese zwei Nortel-Switche sind physikalisch wie folgt mit dem Cisco Catalyst C3550 verbunden. Ich habe jeweils 4 Ports auf dem C3550 verwendet, um einen LACP Port-Channel zu den zwei jeweiligen Bladecenter-Switches zu verbinden. Port-Channel1 hat somit 4 einzelne Leitungen, die in den ersten Bladecenter-Switch gehen, und Port-Channel2 hat ebenfalls 4 einzelne Leitungen, die in den zweiten Bladecenter-Switch verlaufen. Diese zwei LACP Kanäle sind beide aktiv und vollständig funktionsfähig. Die Konfiguration habe ich jeweils auf den zwei Nortel-Switches und dem C3550 durchgeführt.
Bis zu diesem Aufbau, weiß ein einzelner Blade (=Xenserver) jedoch absolut nichts darüber, dass hinter ihm LACP-Kanal vorhanden wäre. Für den Xenserver ist es irrelevant was dahinter kommt, er sieht lediglich eine NIC0 und eine NIC1.
Wenn ich mit diesem Setup nun auf jedem einzelnen Xenserver 10 VMs betreiben würde (in Summe also 40 VMs), die allesamt NIC0 als Netzwerk eingetragen haben, dann würde Xenserver den Traffic für all diese VMs über NIC0 abwickeln, und somit über den Port-Channel1. Das wäre Blödsinn, weil mein Port-Channel2 somit nie zum Einsatz kommen würde.
Wenn ich mit diesem Setup jedoch die Hälfte der VMs (also 20VMs) die NIC0 zuweisen würde, und den restlichen 20VMs die NIC1 zuweisen würde, dann hätte ich manuell für Load-Balancing innerhalb der VM-Gruppe gesorgt. Das würde nun auch den Port-Channel2 nutzen, aber diese manuelle Variante ist auch nicht das gelbe vom Ei, denn ich müsste mich bei jeder Installation einer neuen VM selbst darum kümmern, eine ausgeglichene Netzwerkkarten-Verteilung zu gewährleisten, also abwechseln mal NIC0 oder NIC1 für eine VM verwenden. Das ist aber blöd und kann bei großer VM-Anzahl oder häufigen Änderungen sehr aufwendig sein.
Also habe ich mir folgendes als Lösung überlegt: ich erstelle in Xenserver ein Bonding. Dort hat man folgende Auswahlmöglichkeiten...
Interessant für meine Zwecke wären "Active-Active" oder "LACP with load-balancing based on <egal was für ein Algorithmus>". Eigentlich nutze ich vorzugsweise immer LACP, aber hier bin ich mit meinem Latein am Ende. Wenn ich tatsächlich versuchen würde NIC0+NIC1 mittels LACP zu bündeln, dann müsste ja der Gegenpartner von NIC0 und NIC1 ebenfalls mit LACP konfiguriert würden. Wie zum Geier soll das denn aber gehen? Das Gegenstück von NIC0 ist nämlich der erste Nortel-Switch und das Partner von NIC1 ist der zweite Nortel-Switch. Das geht doch schlecht, oder nicht???
Wenn also diese LACP-Möglichkeit wegfallen müsste, bleibt mir also nur Active-Active und damit müsste das doch eigentlich klappen, oder? Denn das Xenserver-Handbuch zu diesem Active-Active Modus sagt:
Ist demnach dieses Active-Active-Bonding, das was ich anstreben sollte? freue mich über euer feedback und Hilfestellung. Besten Dank im Voraus und eine schöne Woche wünscht...
Pangu
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 249191
Url: https://administrator.de/contentid/249191
Ausgedruckt am: 21.11.2024 um 18:11 Uhr
11 Kommentare
Neuester Kommentar
Ein klassisches Szenario und gut beschrieben
Heutzutage mit aktueller Switch Hardware hast du 2 Optionen:
a.) Die Switches sind stackbare Switches und können über ein Stacking logisch wie ein Switch agieren. Folglich sehen dann die Adapter NIC0 und auch NIC1 dann die beiden physischen Switches im Stack als einen logischen Switch und alles ist gut.
Eine LACP Link Aggregation ist dann so problemlos konfigurierbar mit NIC0 und NIC1.
b.) Viele Hersteller supporten ein virtuelles Zusammenfassen von separaten Switches für die 802.3ad / LACP Link Aggreagtion. Diese Verfahren sind leider nicht standartisiert und jeder Hersteller nennt das anders. z.B. Cisco = VSS oder VPC (Virtual Port Channel), Brocade = MCT (Multi Chassis Trunking) usw. usw.
Damit kann man dann 2 Switches für eine Link Aggreagtion zusammenführen. Auch hier "sieht" das Endgerät dann aus .ad / LACP Sicht wieder nur ein Gerät obwohl es physisch 2 sind.
Ursprünglich kam das Verfahren von Nortel ! und nannte sich Split Multi-Link Trunking (SMLT) http://en.wikipedia.org/wiki/Split_multi-link_trunking
Nortel hat das also federführend angestossen.
Wenn du also Glück hast supporten deine beiden Nortel Gurken diese Option b.) und du kannst das so dann problemlos lösen. Hier hilft wie immer ein Blick ins Handbuch der Switches !
Stackbar sind sie vermutlich nicht, oder ?
Leider hast du keinen Modell Namen hier angegeben und zwingst uns so mal wieder zum raten
Der IEEE Standard 802.3ad / LACP supportet offiziell so ein Splitting auf unterschiedliche HW generell nicht, sondern lässt einen Trunk immer nur auf einem physischen Gerät zu.
Die o.a. genannten Hersteller Verfahren sind heute aber mehr oder weniger Standard bei allen besseren Switch Herstellern.
Wenn deine Nortel Gurken wider Erwarten allerdings keins der genannten Verfahren oder Techniken supporten dann hast du keinerlei Chance das sinnvoll umzusetzen.
Es spielt übrigens keine Rolle ob du LACP Trunks oder Active-Active machst. letzterer ist ein statischer Trunk ohne LACP und birgt erhebliche Risiken wie Loops usw. so das du davon besser die Finger lassen solltest !
Deine Verfahrensweise generell den Standard LACP einzusetzen ist schon genau richtig und sollte man in einem heterogenen Umfeld auch IMMER machen wenn möglich.
Grundlegende Erklärungen zu LACP findest du z.B. auch hier:
Netzwerk Management Server mit Raspberry Pi
Das Gegenstück von NIC0 ist nämlich der erste Nortel-Switch und das Partner von NIC1 ist der zweite Nortel-Switch. Das geht doch schlecht, oder nicht???
Das kommt wie immer auf die Switches drauf an ob die sowas supporten ?!Heutzutage mit aktueller Switch Hardware hast du 2 Optionen:
a.) Die Switches sind stackbare Switches und können über ein Stacking logisch wie ein Switch agieren. Folglich sehen dann die Adapter NIC0 und auch NIC1 dann die beiden physischen Switches im Stack als einen logischen Switch und alles ist gut.
Eine LACP Link Aggregation ist dann so problemlos konfigurierbar mit NIC0 und NIC1.
b.) Viele Hersteller supporten ein virtuelles Zusammenfassen von separaten Switches für die 802.3ad / LACP Link Aggreagtion. Diese Verfahren sind leider nicht standartisiert und jeder Hersteller nennt das anders. z.B. Cisco = VSS oder VPC (Virtual Port Channel), Brocade = MCT (Multi Chassis Trunking) usw. usw.
Damit kann man dann 2 Switches für eine Link Aggreagtion zusammenführen. Auch hier "sieht" das Endgerät dann aus .ad / LACP Sicht wieder nur ein Gerät obwohl es physisch 2 sind.
Ursprünglich kam das Verfahren von Nortel ! und nannte sich Split Multi-Link Trunking (SMLT) http://en.wikipedia.org/wiki/Split_multi-link_trunking
Nortel hat das also federführend angestossen.
Wenn du also Glück hast supporten deine beiden Nortel Gurken diese Option b.) und du kannst das so dann problemlos lösen. Hier hilft wie immer ein Blick ins Handbuch der Switches !
Stackbar sind sie vermutlich nicht, oder ?
Leider hast du keinen Modell Namen hier angegeben und zwingst uns so mal wieder zum raten
Der IEEE Standard 802.3ad / LACP supportet offiziell so ein Splitting auf unterschiedliche HW generell nicht, sondern lässt einen Trunk immer nur auf einem physischen Gerät zu.
Die o.a. genannten Hersteller Verfahren sind heute aber mehr oder weniger Standard bei allen besseren Switch Herstellern.
Wenn deine Nortel Gurken wider Erwarten allerdings keins der genannten Verfahren oder Techniken supporten dann hast du keinerlei Chance das sinnvoll umzusetzen.
Es spielt übrigens keine Rolle ob du LACP Trunks oder Active-Active machst. letzterer ist ein statischer Trunk ohne LACP und birgt erhebliche Risiken wie Loops usw. so das du davon besser die Finger lassen solltest !
Deine Verfahrensweise generell den Standard LACP einzusetzen ist schon genau richtig und sollte man in einem heterogenen Umfeld auch IMMER machen wenn möglich.
Grundlegende Erklärungen zu LACP findest du z.B. auch hier:
Netzwerk Management Server mit Raspberry Pi
Es handelt sich um das "Nortel Layer2-3 GbE Switch Module(Copper)".
Welches Automodell benutzt du denn ?? Na das hab ich doch gesagt das mit den 4 Reifen und der Windschutzscheibe....Du erkennst die sinnfreie Antwort, oder ??
Diese Nortel Module basieren ja auf einer ganz bestimmten Hardware bzw. auf einem ganz bestimmten Modell !
Ziel der Frage war es DAS rauszubekommen, damit man mal in den Featureset bzw. das Handbuch sehen kann um zu sehen ob du Glück hast und dieses Feature auf dieser Plattform supportet ist
Wenn ich mich also auf eines dieser Nortel-Switchmodule einlogge, so finde ich leider auch nichts, dass auf Multi-Level-Trunking deutet. Schade, wahrscheinlich können die das nicht, nehme ich an?
Das wird dann vermutlich leider so sein...solltest du aber mit dem Nortel Helpdesk nochmal genau und wasserdicht abklären, denn dein Design ist ja ein Klassiker und heutige embeddete Module fast aller Hersteller supporten sowas problemlos !Active-Active ist ein statischer Trunk, d.h. diese Seite macht ein einfach ein Balancing ohne darauf zu achten ob z.B. ein Brigdging über diese Ports gemacht wird. Wenn die andere Seite also der switch unintelligent ist und z.B. kein STP kann kann sowas ganz einfach passieren.
NetIO und iPerf zeigen auch niemals ob das funktioniert ! Link Aggregation ist immer ein Hashing Verfahren bei dem aus den letzten 4 Bits der Mac Adresse (oder IP) ein Hash berechnent wird der auf den physischen Link zeigt der für diese Übertragung verwendet wird.
Physisch wird ein Flow sei es jetzt Mac oder IP basiert also immer nur auf einem einzelnen Link übertragen.
Nur einzig die Verteilung der Macs oder IPs entscheidet dann über eine Verteilung der Auslastung.
Durch das Hashing und die nicht homogene Verteilung der Adressen ist das Balancing also niemals fifty fifty sondern in der Regel erheblich schlechter.
Besser Hersteller fügen in die Hash Berechnung dann noch den TCP oder UDP Port mit ein um das granularer zu machen.
NetIO und iPerf bringen so gar nichts, denn du kannst die Verteilung eben damit nicht beobachten und siehst nur den Durchsatz des einzelnen Flows. Der kann aber ja niemals höher sein als einer der am Trunk beteiligten Links, da er ja nur über einen einzigen singulären Link übertragen wird !!
Wenn dann musst du das mit der Linkauslastung ansehen ob es wirklich ein Balancing gibt.
Das kann man z.B. grafisch sehen auf dem Switch:
- SNMP auf dem Switch aktivieren mit der Read Only Community "Public"
- STG 1.4.5 Grapher runterladen und 2mal (einen Prozess pro Link) starten: http://leonidvm.chat.ru
- IP Switch eingeben und OID auf 1.3.6.1.2.1.2.2.1.10.(Port-A) auf dem einen einstellen. OID auf 1.3.6.1.2.1.2.2.1.10.(Port-B) auf dem anderen einstellen
- Traffic anstoßen
- Auslastung der beiden Links beobachten...
Nee, ist nicht hilfreich, denn das zeigt nur die Firmware Version. Wichtig wäre zu wissen auf welcher Modell HW Basis diese Module beruhen.
Aber das wird wohl nur Nortel / Avaya dir benatworten können ?!
Wichtig wäre auch mal zu wissen ob ggf. eine aktuellere Firmware Version existiert und ob diese ggf. dieses MLT Feature supportet ?!
Normalerweise müssen solch geclusterte Switches beide aktiv ihre Mac Forwarding Database sharen. Klar denn jeder Switch muss ja auf einem gemeinsamen LAG die Pärchen kennen um auch ein Failover zu machen. Das geht immer über eine aktive Session zwischen den Switches. MLT usw. muss also zwingend dediziert konfiguriert werden zwischen den Switches. Nur einen gleichen LACP Key zu nehmen wird ja niemals reichen wenn die beiden Switches sich nicht kennen.
Wenn keiner vom anderen weiss ist es ihnen ja schnurz wer welchen Key nutzt. Ob gleich oder nicht ist ja nur lokal relevant.
Deine oben zitierten Dokumente sagen zudem absolut gar nichts zu der MLT Thematik aus, so das davon auszugehen ist das sie es de facto NICHT supporten.
Das sind ganz normale Standard Features die da sind.
Nur mal als Beispoiel wie andere es machen mit diesen Funktionen, damit du mal siehst was Konfig technisch dahinter steht:
Cisco:
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-se ...
Brocade:
http://www.brocade.com/downloads/documents/html_product_manuals/FI_ICX6 ...
Da ist also schon ne aktive Kommunikation zw. den Switches.
Noch einfacher wärs ja wenn sie wenigstens HW Stackbar wären, dann würde ein simples Kapel reichen und der Thema wär erledigt...
Aber um ganz sicher zu gehen was die HW kann solltest du die Nortel-, oder da die ja seit langem pleite sind die Avaya Hotline anrufen. Avaya ist ja der Nachfolger und verwaltet die Nortel Leichen....
Aber das wird wohl nur Nortel / Avaya dir benatworten können ?!
Wichtig wäre auch mal zu wissen ob ggf. eine aktuellere Firmware Version existiert und ob diese ggf. dieses MLT Feature supportet ?!
Normalerweise müssen solch geclusterte Switches beide aktiv ihre Mac Forwarding Database sharen. Klar denn jeder Switch muss ja auf einem gemeinsamen LAG die Pärchen kennen um auch ein Failover zu machen. Das geht immer über eine aktive Session zwischen den Switches. MLT usw. muss also zwingend dediziert konfiguriert werden zwischen den Switches. Nur einen gleichen LACP Key zu nehmen wird ja niemals reichen wenn die beiden Switches sich nicht kennen.
Wenn keiner vom anderen weiss ist es ihnen ja schnurz wer welchen Key nutzt. Ob gleich oder nicht ist ja nur lokal relevant.
Deine oben zitierten Dokumente sagen zudem absolut gar nichts zu der MLT Thematik aus, so das davon auszugehen ist das sie es de facto NICHT supporten.
Das sind ganz normale Standard Features die da sind.
Nur mal als Beispoiel wie andere es machen mit diesen Funktionen, damit du mal siehst was Konfig technisch dahinter steht:
Cisco:
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-se ...
Brocade:
http://www.brocade.com/downloads/documents/html_product_manuals/FI_ICX6 ...
Da ist also schon ne aktive Kommunikation zw. den Switches.
Noch einfacher wärs ja wenn sie wenigstens HW Stackbar wären, dann würde ein simples Kapel reichen und der Thema wär erledigt...
Aber um ganz sicher zu gehen was die HW kann solltest du die Nortel-, oder da die ja seit langem pleite sind die Avaya Hotline anrufen. Avaya ist ja der Nachfolger und verwaltet die Nortel Leichen....
Deine ursprüngliche Anforderung war absolut legitim und das ist auch heutzutage State of the Art das so umzusetzen !
In der Beziehung hast du also alles absolut richtig gemacht.
Dein Problem ist deine (sorry) müllige Switchhardware, die einfach solche banalen Anforderungen nicht supportet. Verwunderlich heutzutage aber Nortel oder besser Avaya sind ja eher für VoIP bekannt als für innivative Switch Hardware und Netzwerk Lösungen.
Kann aber auch sein das deine dortige HW einfach zu alt ist.
Sinnvoll kannst du es also nicht lösen, denn das wäre dein ursprünglicher Vorschlag. Da du keinerlei Möglichkeit hast den Traffic sinnvoll auf beide Switches redundant zu verteilen mit Redundanz wie du es ja vorhattest, kannst du es nur dediziert pro Switch tun, also quasi eine billige Allerwelts Konfig mit einer festen Bindung der NICs auf einem Switch.
Nachteil ist dann die starre Zuordung und das völlige Fehlen einer sinnvollen Redundanz und Skalierbarkeit die die erste Lösung ja geliefert hätte.
Aber es ist halt nun mal so wenn man einen Dacia Logan hat kann man keine 280 fahren auf der Autobahn.
Sinnvoll wäre nur wenn du über eine aktuelle neue Switch HW nachdenkst ?!
In der Beziehung hast du also alles absolut richtig gemacht.
Dein Problem ist deine (sorry) müllige Switchhardware, die einfach solche banalen Anforderungen nicht supportet. Verwunderlich heutzutage aber Nortel oder besser Avaya sind ja eher für VoIP bekannt als für innivative Switch Hardware und Netzwerk Lösungen.
Kann aber auch sein das deine dortige HW einfach zu alt ist.
Sinnvoll kannst du es also nicht lösen, denn das wäre dein ursprünglicher Vorschlag. Da du keinerlei Möglichkeit hast den Traffic sinnvoll auf beide Switches redundant zu verteilen mit Redundanz wie du es ja vorhattest, kannst du es nur dediziert pro Switch tun, also quasi eine billige Allerwelts Konfig mit einer festen Bindung der NICs auf einem Switch.
Nachteil ist dann die starre Zuordung und das völlige Fehlen einer sinnvollen Redundanz und Skalierbarkeit die die erste Lösung ja geliefert hätte.
Aber es ist halt nun mal so wenn man einen Dacia Logan hat kann man keine 280 fahren auf der Autobahn.
Sinnvoll wäre nur wenn du über eine aktuelle neue Switch HW nachdenkst ?!
Mein Chef würd mich niederboxen, wenn ich ihm nun damit komme
Komische Einstellung....??! Es dient der Betreibssicherheit seiner Server die laufen müssen damit ER Geld verdient und es dem Umsatz sichert !!!Er müsste also ein essentielles Interesse daran haben das zu lösen.... Oder betreibt er nur ne Würstchenbude ?
DU solltest ihn als kompetenter EDVler auch ja entsprechend beraten. genau dafür hat er dich doch auch eingestellt, oder ?!
Sehr komische Firma in der du da arbeitest....sorry ?!