bigbiff
Goto Top

Kann eine Netzwerkarte automatisch die Aufgaben einer zweiten übernehmen?

1 Server, 2 Netzwerkkarten, 2 Switches

Hallo!

Mein Problem ist ein bischen größer, aber vielleicht gibt es jemanden der mir trotzdem weiterhelfen kann.

Ich habe einen Server auf dem Windows Server 2003 läuft und in dem zwei Netzwerkkarten eingebaut sind. Jede der beiden Netzwerkkarten ist auf einem anderen Switch angeschlossen und die Switches besitzen auch untereinander eine Verbindung. Diese Core Switches sind mit dem restlichen Netzwerk verbunden bzw. noch mit weiteren Servern. Bricht nun, aus welchen Gründen auch immer, die Verbindung einer der beiden Netzwerkkarten zum jeweiligen Switch zusammen, übernimmt die zweite Netzwerkarte über den zweiten Switch den Traffik problemlos. ABER nur wenn beide Switches noch online sind.
Folgendes Problem:
Bricht einer der beiden Switches völlig zusammen, "Stromstecker ziehen" (also kein Datenaustausch mehr zwischen den beiden Switches) bricht für kurze Zeit das Netzwerk zusammen. Das möchte ich gerne vermeiden, oder der Traffik sollte genauso problemlos vom anderen Switch( bzw Netzwerkkarte) übernommen werden.

Kann mir vielleicht jemand helfen?
Bin für alle gedanklichen Anregungen dankbar.

Vielen Dank im Voraus

Big Biff

Content-ID: 33117

Url: https://administrator.de/forum/kann-eine-netzwerkarte-automatisch-die-aufgaben-einer-zweiten-uebernehmen-33117.html

Ausgedruckt am: 23.12.2024 um 06:12 Uhr

Rafiki
Rafiki 23.05.2006 um 19:21:39 Uhr
Goto Top
So weit ich das weiß benötigst du dafür zwei Switches mit MLT Multi Link Trunk. Cisco hat dafür einen anderen Namen. Ein einfacher ?dummer? Switch für EUR 100 kann kein MLT.

Ein Beispiel, da ich diese Geräte kenne und selber einsetzte, wäre der Nortel Ethernet Routing Switch 5510, für ca. EUR 2000 je Gerät.

Siehe Bild auf Seite 5 vom PDF ?Product Brief 5510?: Ein Server wird mittels Multi Link Trunk MLT an zwei unterschiedliche Geräte, die zu einem Stack (Stapel) verbunden sind, angeschlossen.
www.nortel.com/products/02/bstk/switches/baystack_5510/collateral/nn104742-082604.pdf

Leider sind die Verbindungskabel innerhalb eines Stacks sehr kurz (30cm). Das bedeutet der Stack ist auf ein Raum begrenzt.

Gruß Rafiki
bigbiff
bigbiff 24.05.2006 um 08:34:45 Uhr
Goto Top
Hallo Rafiki!

Danke für deine schnelle Antwort!

Ich arbeite allerdings mit Broadcom NetXtreme Gigabit Switches (BCM570x series).
Netzwerk Topologie 2 und eingestelltem "Smart Load Balancing" in der Teaming Mode Comparision.

genaue Infos: http://www.broadcom.com/collateral/wp/570X-WP100-R.pdf

Hoffe du kannst damit was anfangen.

Besten Dank!

Big Biff
aqui
aqui 24.05.2006 um 12:37:36 Uhr
Goto Top
Ein Trunk nützt dir gar nichts, denn der schafft immer nur Redundanz durch multiple Ports zu einem einzigen Switch und kann nicht auf 2 Switches gesplittet werden ! Trunking (oder Etherchannel wie Cisco es nennt..) dient auch primär der Durchsatzerhöhung bei der Anbindung von Servern und nicht der Redundanz...
Im Serverbereich gibt es eine Menge an Redundanzmeachnismen um so etwas abzufangen spezielle Switches benötigt man dafür nicht unbedingt. Ein klassiche Hochverfügbarkeitslösung ist aber nur in Verbindung mit den Switches zu realisieren.
Fangen wir da einmal an: Die Switches müssen in einem "Hot Standby" Verfahren mit VRRP oder VRRP-E laufen sofern deine Server mehrere Segmente (VLANs) bedienen müssen. Dies dient dazu um dein Gateway Problem zu lösen, sollte einer der Core Switches ausfallen.
Hast du allerdings ein "flaches" Layer 2 Netzwerk ohne VLANs benötigst du diesen Mechanismus nicht. Du musst dann lediglich dafür soregn, das deine Core switches immer redundant an die Access Switches angebunden sind ! Das setzt natürlich zwingend den Einsatz ein Spanning Tree Protokoll voraus sei es STP oder das modernere RSTP.
Im Server selber ist das einfachste man schaltet eine Karte in den Standby Mode. Mit guten Karten ala Intel, Broadcom etc. ist das einfach über die Treiberkonfig oder ein Zusatzprogramm machbar. Der Server aktiviert dann augenblicklich die redundante Karte sollte bei der primären der physische Link ausfallen.
Der Betrieb mit 2 aktiven Karten kann etwas "tricky" sein allerdings ist das abhängig vom Betriebssystem. Ein Unix Server den du z.B. nur per FTP oder HTTP betreibst hat dann 2 unterschiedliche IP Adressen und kann auch über die angesprochen werden. Mit einem DNS Load Balancing bekommst du problemlos eine transparente Redundanz für die Benutzer hin.
Bei Windows ist das nicht mehr ganz so einfach, da dessen Resourcen dynamisch nun synchron von beiden IP Adressen im Netz gebroadcastet werden, was meist Probleme verursacht auf der Clientseite. Eine Linksteuerung wie o.a. beschrieben ist wesentlich problemloser zu handeln. Wichtig ist nur darauf zu achten das die MAC Adressen unterschiedlich sind (ist aber wahrscheinlich bei 2 separaten Karten..) sonst hast du im Netzwerk wieder Probleme mit doppelten MACs und das geht gar nicht sofern es ein Layer 2 Szenario ohne VLANs ist !
Will man beide Adapter mit unterschiedlichen Netzadressen betreiben kann man diese Adapter in unterschiedliche IP Segmente bringt und dann wieder mit VLANs arbeitet, was dann aber ein VRRP Szenario wie oben bei den Switches voraussetzt entsprechende VLAN Fähigkeit der Switches sowieso...
So oder so kannst du dann aber einen Core Switch komplett ausschalten (oder ausfallen lassen..) ohne das es zu einem Verbindungsverlust mit dem Server kommt. Ein gängiges Verfahren für hochverfügbare Server....
bigbiff
bigbiff 24.05.2006 um 13:49:50 Uhr
Goto Top
Hallo aqui!

Es ist ein VLAN mit einem Layer 2 Szenario. Der Server hat zwei Netzwerkkarten, mit je einer MAC-Addresse, aber nur eine IP.

Da liegt das Problem. Greift ein Client auf den Server zu, verwendet er einen bestimmten Switch, ergo eine bestimmte Netzwerkkarte. Die Mac-Addresse dieser Netzwerkkarte wird folglich gespeichert. Geht jetzt die Verbindung zwischen Server(Netzwerkkarte A) und Switch A, down (Switch ist noch online), tauschen die Switches diese Information aus und Switch B übernimmt die Verbindung auf Netzwerkkarte B des Servers (Zeitaufwand für diese Operation ca. 50 ms). Stirbt ein Switch völlig, findet der Informationsaustausch zwischen den Beiden nicht statt. -> Verbindung tot.

Da das Netzwerk entsprwechend groß ist kommt es zu einem crash.

Meine eigentliche Frage ist nun, kann man die Verbindung am Server auf die andere Netzwerkkarte legen (remind gespeicherte MAC-Addresse).

Besten Dank

Big Biff
aqui
aqui 26.05.2006 um 23:00:20 Uhr
Goto Top
Hallo Big Biff !

Nein, deine Annahme ist falsch das sich die Switches aktiv austauschen. Das können sie nicht denn es gibt kein Protokoll das dies regelt. Du schreibst du hast lediglich ein Layer 2 Szenario dann basiert bei dir alles auf MAC Adressen die ein Switch passiv in seiner CAM Table verwaltet.
Da liegt aber auch dein Problem, denn du benutzt eine problematische Konfiguration mit einer IP Adresse die 2 MACs besitzt:
Ein Endgerät schickt vor jedem Verbindungsaufbau ein ARP Request Packet (Adress Resolution Protokoll) als Broadcast ins gesamte Netz das die Switches auf alle Ports replizieren müssen (..ist ja ein Broadcast) denn der Client möchte gerne die MAC zur IP Adresse wissen. Nun nimmt das Unglück seinen Lauf..... Da du 2 unterschiedliche MACs auf einer IP Adresse sitzen hast (so schreibst du es für die Server Konfig) gehts nach dem Motto "first come first serve" also je nachdem welcher ARP Reply schneller ist landet im ARP Cache deines Clients. Danach geschieht dann der Verbindungsaufbau.
Fällt nun der Switch aus auf dessen Port die MAC Adresse liegt mit der der Client kommuniziert merkt der das erstmal nicht, denn der denkt das sein ARP Cache ok ist und versucht verzweifelt diese MAC zu erreichen. Irgendwann macht er vielleicht einen neuen ARP Request oder auch nicht, das ist von seinem TCP/IP Stack abhängig wie der auf sowas reagiert. Bei vielen Clients timen diese Verbindungen aus oder der User rebootet den Client frustiert, was dann natürlich den ARP Cache löscht und letztlich das Problem fixt.
Mit deiner Konfig kommst du aus der Zwickmühle nicht raus.
Du solltest die Adapter in ein sogen. Active - Standby Szenario nehmen. D.h. ein Link ist aktiv und der andere nur Standby. Beide sharen eine IP und MAC. Fällt der Aktive aus übernimmt sofort der Standby Link mit den gleichen Daten. Damit hast du dann ein sub second Failover sofern dein Servertreiber das fix handeln kann face-wink
Nachteil: Damit verlierst du die Load Sharing Möglichkeit, denn es ist ja nur ein Link aktiv.
Willst du beide Links aktiv haben musst du beiden auch jeweils eine unterschiedliche IP Host Adresse geben und unterschiedliche MACs. Über ein DNS Round Robin musst du nun dafür sorgen, das die Clients auf diese Adapter verteilt werden, bzw. im Failoverfalle auf den jeweils aktiven Port per DNS geschaltet werden. Das erfordert aber meist einen Loadbalancer oder eine extra SW Lösung im DNS.
Der Aufwand von ersterer Variante ist ungleich geringer und störungsärmer... Wenn du die Server mit GiG Karten anbindest sollte der LB Nachteil verschmerzbar sein.
bigbiff
bigbiff 30.05.2006 um 10:01:57 Uhr
Goto Top
Hallo Aqui!

Das hat mir sehr weitergeholfen! Allerdings, habe ich das Problem, dass beide Links aktiv sein müssen. Der Edge-Switch eines Clients verwendet einen bestimmten Core-Switch.
Pro Abteilung 1 Edge-Switch.

Abteilung 1 -> Core-Switch 1
Abteilung 2 -> Core-Switch 2
Abteilung 3 -> Core-Switch 1
Abteilung 4 -> Core-Switch 2 .......

Würde ich nun deinen Rat befolgen (DNS Round Robin, Loadbalancer,...) müsste ich die gesamte Netzwerkstruktur ändern (über 300 Clients, dutzende Server).

Ich habe vor kurzem eine eigene kleine Theorie aufgestellt. Du hast Recht, wegen dem Datenaustausch zwischen den Switches. Allerdings glaube ich, dass bei Ausfall eines Links zwischen Server und Core-Switch, die neue Verbindung, die automatisch erstellt wird, nicht wie ich vorher angenommen habe, neu über
Edge-Switch -> Core-Switch 2 (ersatz) -> Server
erstellt wird, sondern wie folgt:
Edge-Switch -> Core-Switch 1 (missing Link) -> Core-Switch 2 (ersatz) -> Server.
Wenn ich recht habe, würde es den Totalausfall erklären, wenn ein Switch völlig wegfällt.

Besten Dank!

Big Biff
aqui
aqui 31.05.2006 um 11:26:44 Uhr
Goto Top
Ja klar der Sprung auf eine L3 Infrastruktur würde das natürlich bedeuten. War hier auch nur primär als Beschreibung deiner beiden Möglichkeiten gedacht...
Dein Problem ist das die Edge Switches scheinbar nicht redundant an die Core Switches angebunden sind wenn ich die o.a. Liste richtig interpretiere.
In einem klassischen redundanten Netzwerk ist genau das aber immer der Fall und ausserdem haben die Core Switches natürlich noch einen Link zwischen sich selbst. STP oder RSTP sorgt dann wieder für redundante eindeutige Wege.
Was bleibt ist aber dein ARP Cache Problem bei den Clients bzw. Server bei zwei unterschiedlichen MACs pro Link. Fällt nun der Link eines Servers weg auf dem der Client aktiv arbeitet hat er ja immer noch dessen MAC im ARP Cache bzw. auch der Server. Beide Endgeräte müssen zwangsläufig im V-Fall neu arpen wenn ihre aktive MAC wegbricht.
Das wird in so einer Konstellation immer der Fall sein. Du bist dann immer auf Gedeih und Verderb auf die Funktionalität bzw. das verhalten deines TCP Stacks in Bezug auf ARPs angewiesen, wie der sich in so einem Falle verhält. Die Switchinfrastruktur hat da eher an zweiter Stelle mit zu tun sofern sie dann auch redundant ausgelegt ist.
Das ist erst anders wenn du mit active-standby arbeitest, da die MAC dann immer eindeutig ist. Das ist bei dir ja aber nicht gewollt.
bigbiff
bigbiff 31.05.2006 um 12:31:51 Uhr
Goto Top
Die Edge-Switches sind redundant an die Cores angebunden, bevorzugen aber beim Erstellen einer Verbindung einen der Beiden.

Wenn ich das ändern würde, sodass sich die Edge-Switches per Load Balancing einen passenden Switch wählen, wäre das Problem aber immer noch das gleiche.

Wenn sich eine Verbindung über einen Core-Switch aufgebaut hat und genau dieser ausfällt(im Sinne von kein Saft mehr) hat er ja immer noch das selbe Problem ???

Ich habe mit Hilfe eines kleinen Testaufbaus außerdem herausgefunden, dass wenn ich den Link zwischen den Core-Switches weglasse, das ganze funktioniert. Also Stecker raus, ca. 2 Ping Wartezeit, Verbindung über den anderen Core steht.
Mit dem Link zwischen den Cores, "Request timed out", für den Rest seines Leben.

Vielen Dank für deine bisherige Hilfe!

Big Biff
aqui
aqui 31.05.2006 um 13:28:05 Uhr
Goto Top
Der Switch selbst "bevorzugt" nichts. Das Protokoll was dafür sorgt ist ein Spanning Tree Protokoll. Also entweder Standard Spanning Tree 802.1d oder rapid Spanning Tree 802.1w. Heutzutage nimmt man meist RSTP 802.1w wegen der schnelleren Konvergenzzeiten von Teils unter einer Sek. BPDU Packete sorgen dann dafür das in einem redundanten Netz mehrere Ports in den Blocking Mode gehen um so Loops zu verhindern. Normalerweise konfiguriert man STP über Priorities so das man fest vorgibt wer Root Bridge ist und wer nicht. Man muss es aber nicht, dann tritt allerdings der Fall ein das auch Edge Switches zu Root Bridges werden können und das kann im Link Fehler Fall fatal sein denn dann tritt ein STP Recalculation Vorgang ein. Bei Standard STP ist es umso schlimmer, da der aktiv dann eine neue Topologie errechnet und auch aktive Links vorübergehend in den Blocking State gehen. Dieser Zusatnd kann bis zu mehreren Minuten dauern.
Ich nehme mal an das das bei dir der Fall ist denn wenn man ein STP Netzwerk sauber customized dann passiert so etwas nicht. Das Ziehen deines Links zwischen den Core Switches ist auch ein sicheres Anzeichen dafür, denn das sollte eigentlich keinen Einfluss haben.
Heute nimmt man deshalb auch RSTP den RSTP macht diese Kalkulation der Redundanz schon vorher und bestimmt feste Redundanzlinks. Kann also folglich schneller umschalten und wieder zurück (Sofern man Draft 4 vom RSTP implementiert hat...)
Du solltest in deiner Netzwerk Konstellation unbedingt dafür sorgen das deine Core Switches (bzw. einer davon) immer Root Bridge ist und im V-Falle dann der andere.
Das ist einfach zu bewerkstelligen indem du dir die STP Topologie einmal ansiehst. Je nach Switch geht das mit dem "show stp" Kommando oder über einen Menüpunkt.
Was du machst ist die Bridge Priority der Core Switches über die Konfig hochzusetzen, das die im STP Prozess immer Root Bridges sind. Alternativ geht das auch über die Priority der Links und zwar einsetig auf der Core switch Seite. Das ist aber letztlich etwas mehr Konfig Aufwand.
In so einem Szenario sollte eigentlich alles so klappen wie wenn du deinen Core Switch Link ziehst face-wink
bigbiff
bigbiff 09.06.2006 um 09:55:12 Uhr
Goto Top
Hallo Aqui!

Habe jetzt endlich eine Lösung fürs Problem: EAPS.
Funktioniert einwandfrei und ich kann endlich den Stromstecker vom Switch rausziehen
ohne das was draufgeht (Umschaltzeiten unter 1 Ping).

Danke für deine Hilfe

MfG
Big Biff