Intel NIC Teaming installieren und konfigurieren um die Ausfallsicherheit der Netzwerkanbindung zu erhöhen
Den folgenen Artikel widme ich meinen sehr lieben Kollegen.
Aber auch wer ein größeres Grid mit vielen Usern betreibt, und hohen Wert auf Ausfall Sicherheit des Netzwerkes legt, ist hier richtig.
Auf Servern die hochverfügbar sein sollen ist neben redundanter Stromversorgung und redundanten Datenträgern auch eine duale Netzwerk Anbindung erwünscht.
Die redundante Netzwerk Verbindung ist heute Thema dieses Artikels.
Die Anforderung an die Verfügbarkeit bestimmt dabei die Wahl der Mittel
FALL1:
Man will sich gegen den Ausfall eines Server NICs (Netzwerkports) oder eines Verkabelungsweges absichern. Hier reichen 2 NICs, 2 Kabelwege und ein konfigurierbarer Switch/Router. Der Switch/Router muss entsprechend konfigurierbar sein, denn was man im Ethernet nie darf sind Loops (Schleifen) stecken.Neben dem Ausfall eines NICs darf also auch eine Strecke zum Switch ausfallen. (Zum Beispiel durch Umpatchen oder Wartung)
Die Verkablung ist dabei Y-förmig auf 2 entsprechend konfigurierte Swichtports. Aber, dieser Aufwand rechtfertigt sich eigentlich nur auf innerbetrieblichen Wegen wenn 2 unterschiedliche Trassen zum Einsatz kommen, oder wenn aktive Verlängerungen mit hohem Ausfallsrisiko zum Einsatz kommen. Wesentlich praxistauglicher ist Fall 2, da auch 2 unterschiedliche Switche im Weg verwendet werden. Und was zuerst ausfällt oder in Wartung genomen werden muss ist meist der Switch.
FALL2:
Will man das Szenario (wie oben) erweitern das auch ein Switch/Router ausfallen darf (zum Beispiel zu Switch/Router Wartungszwecken) so braucht man 2 geeignete Switches/Router. Diese Geräte müssen das Spanning Tree Protokoll unterstützen, welches auch aktiviert und konfiguriert werden muß. Dies macht Sinn wenn man zum Beispiel von den "lokalen" 2 Routingfähigen Switches einen abgesetzten Standort redundant anbinden will.
Oder man betreibt 2 Netzwerkwege unterschiedlicher Geschwindigkeit- ein Schnelles für den Normalfall und ein Langsames als Havarie. Sowas ist bereits in kleineren Firmen sinnvoll wenn man essentiell auf Internet angewiesen ist, und mittels Internet Anschluss über Kabel als Standard, und Funkverbindug als Backup/Havarie solche Ausfälle abdeckt.
Auch denkbar ist der Einsatz einer Flatrate gebundenen primären Verbindung, und ein temporärer Havarie Fallback auf eine kostenintensivere Verbindung.
In beiden Fällen ist das Ziel der Hochverfügbarkeit des Netzwerks eine automatische Umschaltung von Switch und Routingwegen ohne fühlbare Unterbrechung für die laufenden Applikationen. Dieses können alle Arten von hochverfügbaren Serverdienste sein, wie zum Beispiel ein großer Webshop. Sobald essentiell Geld am Ausfall des Dienstes hängt, wird man sich über Verfügbarkeit Gedanken machen müssen.
Beim NIC Teaming agieren beide (oder mehrere) Netzwerkports mit der gleichen MAC Adresse, wie wenn es ein Port wäre der aber an 2 Switchports gleichzeitig angeschlossen wäre.Das ist natürlich im Ethernet so ein verbotener Zustand da alle Routen wegen der eindeutigen Adressierung "unique" sein müssen. Kreise, sogenannte Loops, zu stecken führt zu schweren Fehlern. Damit das doch geht müssen Netzwerktreiber des Servers, wie auch alle Beteiligten Switche/Router entsprechende Zusatzprotokolle können, und auch richig konfiguriert sein.
Technisch gesehen gibt es dafür verschiedene Modi zur Lastverteilung (Loadbalancer), Bandbreitenaddition oder Ausfallsicherheit.
Thema in diesem Artikel ist nur die Ausfallsicherheit.
Schauen wir uns nun die Installation eines Windows Servers an:
Fangen wir dabei aus der Blickrichtung des anzuschliessenden Servers an:
Dieser braucht zunächst 2 Netzwerkbuchsen die mittels erweiterten Netzwerktreibern Teaming fähig sind. Dabei ist entscheidend das der Treiber der Karten Teams unterstützt, weil er die Funktionalität herstellt. (Es ist also keine Hardware Funktion!)
Ich werde dies am Beispiel von teamingfähigen Intel I-210 oder I-350 Server Adaptern erklären. Denn nicht alle Netzwerkkarten sind Teamingfähig! Der Treiberhersteller, in diesem Falle also Intel, bestimmt was er im Team einzubinden erlaubt. Im Falle von Intel muss mindestens einer der verwendeten Ports im Team aus der Inter Server NIC Sparte kommen.
Ich will das nicht als Werbung für diese Adapter verstanden sehen, aber ohne eine Festlegung wird die folgende Erklärung blumig und unpräzise.
Und da diese Anleitung primär für meine Kollegen gedacht ist verwende ich die Modelle die wir im Einsatz haben.
Sieht man sich Intel I210 oder I350 NICs an, so gibt es die mit 2 oder 4 Ports, in verschiedenen Geschwindigkeiten und Verkabelungs Ausführungen. Da meine Verkablung nur im Rack bis zu den 2 Switchen geht, wähle ich die günstige T-Variante mit KAT Kabeln.
Optimierung der Wärmelast und Ausfallsicherheit der NICS:
Bei den Intel I350 Nics kommt jeweils ein Chip für 2 Ports zum Einsatz.
Folglich haben wir einen Totalausfall beider Ports wenn der Chip einer 2-Port Karte ausfällt.
Früher hat man deswegen 2 einzelne Adapter genommen, das ist sicherer, braucht aber mehr Slots im Server, was heute oft am Platz scheitert. Alternative kann man einen 4-Port Adapter nehmen, wenn man eh 2 Teams braucht. In diesem Falle gilt es die Teams günstig einzurichten damit Wärmelast und Ausfallsicherheit optimiert sind.
- Also je eine aktive Leitung pro Chip, und Primäre und Sekundäre Buchse nie auf dem gleichen Chip.
Installation:
Die folgenden Arbeiten sollten NIE remote über Netzwerk durchgeführt werden.
Es kommt zu Unterbrechung des Netzwerkzuganges bei Treiberinstallation sowie Utility Konfiguration. Wenn man das remote machen will, so braucht man eine externe KVM (Konsole) die Maus, Tastatur und Bildschirmausgabe separat überträgt. Sowas bekommt man zum Beispiel von Hetzer temporär.
Zunächst als Administrator am Windows Server anmelden. Sicher ist dafür den eingebauten "Administrator" zu nutzen, denn der hat die Berechtigung.
INSTALLATION des Treibers:
Wired Driver V27.2 x64.exe installieren - Öffnen als Administrator
Treiber für Netzwerkanschlüse installiern oder aktualisieren: OK
Nach Fertigstellung mit "Schliessen" benden.
Nun "Wired PROSet V27.2x64.exe" installieren:
Wichtig ist "Intel Erweiterte Netzwerkleistungen" zu aktivieren.
Ausserdem soll die Desktop Verknüpfung erstellt werden und Adapter Config Utility gestartet.
Die 27.2 Version hackt manchmal bei der Installation, dann muss man die wiederholen.
Nach dem 2. Installationsschritt des ProSet Adapter Configuration Utilities, öffnet sich eine Konfigurations Oberfläche (wenn man das Häckchen in der Installation gesetzt hatte). Ansonsten startet man über den Programmaufruf (z.bsp Desktop Icon)
Konfiguration:
Wenn einem die resultierende MAC gleichgültig wäre und man nur 2 Buchsen hat, könnte man schnell und einfach zum Ziel kommen.
Aber die Erfahrung hat gezeigt das die NIC (Netzwerkbuchse) Nummerierung in Hardware, Intel Treiber und Windows leider dem Zufallsprinzip folgt.
In der Folge waren nicht die gewünschten Buchsen zum Team zusammengeschalten, was erstmal ne Fehlersuche beim Einbau zu Folge hatte.
Zudem habe ich 4-6 Ports pro Server (für 2-3 Teams) im Einsatz, und wünsche das die Buchsen an gleicher Einbaustelle auch an jeden Server die gleiche Bedeutung haben. Auch ist keinerlei Wärme und Ausfall Optimierung möglich wenn man nicht gezielt die Buchsen zum Service zuordnet.
In meinem Anwendungsfall ist der Rechner unter der 1. MAC im Netzwerk eingetragen, was für DHCP Zuordnung und Netzwerk Security von Belang ist. Daher muss auch das Team diese MAC tragen. Also muss ich zwingend zuerst die MAC jeder Buchse identifizieren, bevor ich diese konfiguriere.
Dies geht wie in folgenden Bildern gezeigt. Der besseren Übersichtlichkeit habe ich einen Testrechner mit nur 2 NICs hergenommen
Dies macht man Pro NIC.
Nun weiss ich das Adapter 1 die gewünschte MAC hat.
Ich wähle also den ersten Adapter an, und gehe auf Netzwerk/Gruppenbildung.
Witzigerweise kann eine Gruppe auch nur einen Adapter in der Konfiguration enthalten, was ich mir zur eindeutigen Zuordnung in 2 Schritten zu Nutze mache. Ich wähle also Adapter 1 aus, dann gehe ich auf Gruppe erstellen.
Nun kommt die Warnung das das Team nur einen Adapter enthält, die wir bestätigen.
Nun wird gefragt in welchem Modus man das Team beteiben will. Im Gelben Feld darunter werden die Modi erklärt.
Ich gebe zunächte den gewünschten Teamnamen ein: "NIC TEAM1-2" wobei ich 1-2 zur Identifizierung der Netzwerk Adapter Hardware nutze.
Ich wähle den Betriebsmodus aus: SFT- Switch Fehlertolleranz, und klicke weiter.
Nun wird der primäre Adapter des Teams abgefragt- ich wähle NIC1.
und schliesse den Vorgang ab.
Je nach Intel ProSet Version und Windows Version, kann nun eine Fehlermeldung kommen, die zu ignorieren ist.
Offenbar checkt Proset nicht das es selber soeben die Hardware Liste unter Windows geändert hat. Peinlich.
Nun haben wir aber das erste Team mit einem Adapter erstellt.
Jetzt müssen wir den 2. NIC im Team einbinden.
Das mache ich indem ich auf "Mitglieder ändern" gehe.
Nun wähle ich den 2. NIC hinzu. und sage Änderungen übernehmen.
Nun zeigt sich folgendes Bild:
Wan noch fehlt ist den Adapter 2 als Sekundären Adapter auszuwählen, was ich nun mache. Dann drücke ich "Änderungen übernehmen".
Übrigens beachte man die grüne Markierung. Ich habe diese Konfiguration ohne angestecktes Netzwerkkabel gemacht, was sich dringend empfielt um die Switche nicht zu verwirren. Maximal kann bei der Aktion 1 Kabel in einem Adapter stecken!
Ab jetzt wäre der Rechner prinzipiell Einsatzbereit. Es müsste pro NIC auf einen anderen Switch/Router gesteckt werden, und beide Switche/Router auf Spanning Tree Protokoll korrekt konfiguriert sein.
An dieser Stelle richten wir nun unser Augenmerk auf das Kästchen "Gruppeneinstellungen" rechts daneben.
Darin geht es um die Konfiguration des Verhaltens im Störungsfall eines Weges. Prinzipiell sind die Voreinstellungen schon super, aber man sollte zumindest wissen was einstellt ist, um seinen Nutzungsfall besser zu unterstützen.
(Wenn man rechts einen der Parameter einstellt kann man unten im gelben Fenster eine gute Beschreibung lesen.)
Als Wichtig erachte ich den Paramater "Failback zulassen". Normalerweise läuft im von mir eingestellten SFT Modus die Strecke über den Weg1 der als "Primärer Adapter" eingestellt ist. Im Fehlerfall wird dann auf die Sekundären Adapter (Weg2) umgeschalten.
Nun kann es nach einem ersten Fehler zu folgenden Fällen kommen:
1. Fällt nun der aktive Sekundäre Weg2 aus und ist Failback abgeschalten, so fällt die gesamte Strecke aus.
Dabei ist es egal ob der Primäre Weg1 mittlerweile wieder geht, denn es wird nicht mehr automatisch zurück geschalten.
Dies hat sichtbar einen Nachteil wenn man erwartet das das System sich automatisch selbstheilend verhält.
So eine Einstellung macht nur Sinn wenn man ständig die Wege überwacht, und sehr schnell manuelle Eingriffe in den Weg vornimmt.
2. Ist der ausgefallene Weg1 nach einem Aussfall wieder betriebsfähig kann hier ein automatisches Failback auch Probleme bereiten. Denn nun wird (obwohl die Verbindung über Weg2 Fehlerfrei ist), bei Einstellung "primärer Adapter", zurückgeschalten auf Weg1.
Wenn aber zum Beispiel der Primäre Weg1 hohe zufällige Fehlerraten aufweist und immer wieder zusammenbricht kann das zu einer sich aufschwingenden hin und her Schalterei führen, was unter Umständen zum Ausfall der Datenverbindung trotz funktionierenden Backup Weg2 führt.
Beides Verhalten sind also nicht optimal.
Was man einstellt hängt aber auch davon ab ob beide Wege die gleiche Qualität und Datenrate aufweisen.
Ist eine Leitung besser, die andere nur ein schlechterer Notfallweg ( Kosten, Datenrate, Latenz, Verfügbarkeit) so würde ich ein automatisches Fallback auf jeden Fall aktivieren und den "Primären Adapter" festlegen.
Sind beide Wege gleichwertig, dann würde ich empfehlen die Einstellungen von Primären und Sekundären Adapter zu entfernen.
Das beschreibt Intel zwar nicht explizit so, aber ich würde es so verstehen, das dann erst im jeweiligen Fehlerfall auf die jeweils andere Leitung umgeschalten wird, und diese dann genutzt wird bis diese auch ausfällt. In diesem Falle wäre dann die Einstellung: Keine primären und sekundären Adapter definieren. Der Paramater automatisches Failback hat dann laut Beschreibung keine Funktion.
Dieses halte ich aus Erfahrung für das beste Systemverhalten bei gleichwertigen Verbindungen.
Egal was man macht: Danach ist ein Test angebracht ob das System sich wie gewünscht verhält!
Nun widmen wir uns dem Feld "Gruppeneinstellungen"
Unter lokal verwaltete Adresse könne man dem Adapter Team eine selbst zu wählende MAC Adresse spendieren. Das würde ich aber nur bei Hardwareersatz im Fehlerfall machen, wenn Installation, Lizenz oder die Umgebung identische MACs erfordern.
Aktivierungsverzögerung beschreibt das Zeitverhalten im Adapter Umschaltverhalten. Aus Anwendungssicht sind prinzipiell sind schnelle Umschaltungen erwünscht, damit die Anwendung den Leitungsausfall nicht mitbekommt.
Aber die Switche/Router müssen in dieser Zeit reagieren können. Deren Aufgabe besteht den dahinter liegenden Routern mitzuteilen das ab sofort die Team MAC Adresse über einen anderen Weg anzusprechen ist. Das dauert etwas Zeit.
Ich empfehle da Tests!
Prüfzeit: Das gibt das Testintervall an (auf physical Layer1 , soweit ich es verstanden habe) und somit auch die maximale Zeit bis der Ausfall einer Verbindung bemerkt wird. Nach dieser Zeit fängt dann das System zu schalten an. Es kommt also noch die Schaltzeit dazu bis die Verbindung wieder steht.
Beide Zeiten zusammen geben also die maximale Daten Unterbrechungs Zeit an.
Diese Zeit sollten Client-Server Verbindungen oder Datenbank Verbindungen überstehen. TEST!
Verbindungsüberwachung in der Funktion verbirgt sich eine Prüfzeit einer Verbindung auf Layer3. Also IP basiernde Prüfung zu einer eingetragen fernen IP Adresse.
Ansonsten gilt das zu "Prüfzeit" gesagte.
Überprüfung der Einstellungen in Windows:
Schaun wir uns unter Windows nun die Anzeige der Adapter in der Netzwerkeinstellung an:
Wie wir sehen hat Windows nun 3 Adapter eingetragen, obwohl nur 2 NICs eingebaut sind.
Der 3. Adapter ist nun das virtuelle Team. Nur dieser Team Adapter hat IP Settigns für IPV4 und evt IPV6.
Wir erkennen ihn an dem kürzeren Namen den wir in der Konfiguration vergeben haben, hier: "NIC TEAM 1-2"
Ich öffne nun dessen Eigenschaften:
Im Gegensatz dazu sind die 2 echten NICs nun deutlich anders in den Eintragungen:
Wie wir sehen steht hier nun als wichtigster Eintrag der "Intel Advanced Network Services Protokoll" drin, und keinerlei IPv4 oder IPV6
Und nicht das Testen auf allen OSI-Layern vor der Inbetriebnahme vergessen!!!
Den folgenen Artikel widme ich meinen sehr lieben Kollegen.
Aber auch wer ein größeres Grid mit vielen Usern betreibt, und hohen Wert auf Ausfall Sicherheit des Netzwerkes legt, ist hier richtig.
Auf Servern die hochverfügbar sein sollen ist neben redundanter Stromversorgung und redundanten Datenträgern auch eine duale Netzwerk Anbindung erwünscht.
Die redundante Netzwerk Verbindung ist heute Thema dieses Artikels.
Die Anforderung an die Verfügbarkeit bestimmt dabei die Wahl der Mittel
FALL1:
Man will sich gegen den Ausfall eines Server NICs (Netzwerkports) oder eines Verkabelungsweges absichern. Hier reichen 2 NICs, 2 Kabelwege und ein konfigurierbarer Switch/Router. Der Switch/Router muss entsprechend konfigurierbar sein, denn was man im Ethernet nie darf sind Loops (Schleifen) stecken.Neben dem Ausfall eines NICs darf also auch eine Strecke zum Switch ausfallen. (Zum Beispiel durch Umpatchen oder Wartung)
Die Verkablung ist dabei Y-förmig auf 2 entsprechend konfigurierte Swichtports. Aber, dieser Aufwand rechtfertigt sich eigentlich nur auf innerbetrieblichen Wegen wenn 2 unterschiedliche Trassen zum Einsatz kommen, oder wenn aktive Verlängerungen mit hohem Ausfallsrisiko zum Einsatz kommen. Wesentlich praxistauglicher ist Fall 2, da auch 2 unterschiedliche Switche im Weg verwendet werden. Und was zuerst ausfällt oder in Wartung genomen werden muss ist meist der Switch.
FALL2:
Will man das Szenario (wie oben) erweitern das auch ein Switch/Router ausfallen darf (zum Beispiel zu Switch/Router Wartungszwecken) so braucht man 2 geeignete Switches/Router. Diese Geräte müssen das Spanning Tree Protokoll unterstützen, welches auch aktiviert und konfiguriert werden muß. Dies macht Sinn wenn man zum Beispiel von den "lokalen" 2 Routingfähigen Switches einen abgesetzten Standort redundant anbinden will.
Oder man betreibt 2 Netzwerkwege unterschiedlicher Geschwindigkeit- ein Schnelles für den Normalfall und ein Langsames als Havarie. Sowas ist bereits in kleineren Firmen sinnvoll wenn man essentiell auf Internet angewiesen ist, und mittels Internet Anschluss über Kabel als Standard, und Funkverbindug als Backup/Havarie solche Ausfälle abdeckt.
Auch denkbar ist der Einsatz einer Flatrate gebundenen primären Verbindung, und ein temporärer Havarie Fallback auf eine kostenintensivere Verbindung.
In beiden Fällen ist das Ziel der Hochverfügbarkeit des Netzwerks eine automatische Umschaltung von Switch und Routingwegen ohne fühlbare Unterbrechung für die laufenden Applikationen. Dieses können alle Arten von hochverfügbaren Serverdienste sein, wie zum Beispiel ein großer Webshop. Sobald essentiell Geld am Ausfall des Dienstes hängt, wird man sich über Verfügbarkeit Gedanken machen müssen.
Beim NIC Teaming agieren beide (oder mehrere) Netzwerkports mit der gleichen MAC Adresse, wie wenn es ein Port wäre der aber an 2 Switchports gleichzeitig angeschlossen wäre.Das ist natürlich im Ethernet so ein verbotener Zustand da alle Routen wegen der eindeutigen Adressierung "unique" sein müssen. Kreise, sogenannte Loops, zu stecken führt zu schweren Fehlern. Damit das doch geht müssen Netzwerktreiber des Servers, wie auch alle Beteiligten Switche/Router entsprechende Zusatzprotokolle können, und auch richig konfiguriert sein.
Technisch gesehen gibt es dafür verschiedene Modi zur Lastverteilung (Loadbalancer), Bandbreitenaddition oder Ausfallsicherheit.
Thema in diesem Artikel ist nur die Ausfallsicherheit.
Schauen wir uns nun die Installation eines Windows Servers an:
Fangen wir dabei aus der Blickrichtung des anzuschliessenden Servers an:
Dieser braucht zunächst 2 Netzwerkbuchsen die mittels erweiterten Netzwerktreibern Teaming fähig sind. Dabei ist entscheidend das der Treiber der Karten Teams unterstützt, weil er die Funktionalität herstellt. (Es ist also keine Hardware Funktion!)
Ich werde dies am Beispiel von teamingfähigen Intel I-210 oder I-350 Server Adaptern erklären. Denn nicht alle Netzwerkkarten sind Teamingfähig! Der Treiberhersteller, in diesem Falle also Intel, bestimmt was er im Team einzubinden erlaubt. Im Falle von Intel muss mindestens einer der verwendeten Ports im Team aus der Inter Server NIC Sparte kommen.
Ich will das nicht als Werbung für diese Adapter verstanden sehen, aber ohne eine Festlegung wird die folgende Erklärung blumig und unpräzise.
Und da diese Anleitung primär für meine Kollegen gedacht ist verwende ich die Modelle die wir im Einsatz haben.
Sieht man sich Intel I210 oder I350 NICs an, so gibt es die mit 2 oder 4 Ports, in verschiedenen Geschwindigkeiten und Verkabelungs Ausführungen. Da meine Verkablung nur im Rack bis zu den 2 Switchen geht, wähle ich die günstige T-Variante mit KAT Kabeln.
Optimierung der Wärmelast und Ausfallsicherheit der NICS:
Bei den Intel I350 Nics kommt jeweils ein Chip für 2 Ports zum Einsatz.
Folglich haben wir einen Totalausfall beider Ports wenn der Chip einer 2-Port Karte ausfällt.
Früher hat man deswegen 2 einzelne Adapter genommen, das ist sicherer, braucht aber mehr Slots im Server, was heute oft am Platz scheitert. Alternative kann man einen 4-Port Adapter nehmen, wenn man eh 2 Teams braucht. In diesem Falle gilt es die Teams günstig einzurichten damit Wärmelast und Ausfallsicherheit optimiert sind.
- Also je eine aktive Leitung pro Chip, und Primäre und Sekundäre Buchse nie auf dem gleichen Chip.
Installation:
Die folgenden Arbeiten sollten NIE remote über Netzwerk durchgeführt werden.
Es kommt zu Unterbrechung des Netzwerkzuganges bei Treiberinstallation sowie Utility Konfiguration. Wenn man das remote machen will, so braucht man eine externe KVM (Konsole) die Maus, Tastatur und Bildschirmausgabe separat überträgt. Sowas bekommt man zum Beispiel von Hetzer temporär.
Zunächst als Administrator am Windows Server anmelden. Sicher ist dafür den eingebauten "Administrator" zu nutzen, denn der hat die Berechtigung.
INSTALLATION des Treibers:
Wired Driver V27.2 x64.exe installieren - Öffnen als Administrator
Treiber für Netzwerkanschlüse installiern oder aktualisieren: OK
Nach Fertigstellung mit "Schliessen" benden.
Nun "Wired PROSet V27.2x64.exe" installieren:
Wichtig ist "Intel Erweiterte Netzwerkleistungen" zu aktivieren.
Ausserdem soll die Desktop Verknüpfung erstellt werden und Adapter Config Utility gestartet.
Die 27.2 Version hackt manchmal bei der Installation, dann muss man die wiederholen.
Nach dem 2. Installationsschritt des ProSet Adapter Configuration Utilities, öffnet sich eine Konfigurations Oberfläche (wenn man das Häckchen in der Installation gesetzt hatte). Ansonsten startet man über den Programmaufruf (z.bsp Desktop Icon)
Konfiguration:
Wenn einem die resultierende MAC gleichgültig wäre und man nur 2 Buchsen hat, könnte man schnell und einfach zum Ziel kommen.
Aber die Erfahrung hat gezeigt das die NIC (Netzwerkbuchse) Nummerierung in Hardware, Intel Treiber und Windows leider dem Zufallsprinzip folgt.
In der Folge waren nicht die gewünschten Buchsen zum Team zusammengeschalten, was erstmal ne Fehlersuche beim Einbau zu Folge hatte.
Zudem habe ich 4-6 Ports pro Server (für 2-3 Teams) im Einsatz, und wünsche das die Buchsen an gleicher Einbaustelle auch an jeden Server die gleiche Bedeutung haben. Auch ist keinerlei Wärme und Ausfall Optimierung möglich wenn man nicht gezielt die Buchsen zum Service zuordnet.
In meinem Anwendungsfall ist der Rechner unter der 1. MAC im Netzwerk eingetragen, was für DHCP Zuordnung und Netzwerk Security von Belang ist. Daher muss auch das Team diese MAC tragen. Also muss ich zwingend zuerst die MAC jeder Buchse identifizieren, bevor ich diese konfiguriere.
Dies geht wie in folgenden Bildern gezeigt. Der besseren Übersichtlichkeit habe ich einen Testrechner mit nur 2 NICs hergenommen
Dies macht man Pro NIC.
Nun weiss ich das Adapter 1 die gewünschte MAC hat.
Ich wähle also den ersten Adapter an, und gehe auf Netzwerk/Gruppenbildung.
Witzigerweise kann eine Gruppe auch nur einen Adapter in der Konfiguration enthalten, was ich mir zur eindeutigen Zuordnung in 2 Schritten zu Nutze mache. Ich wähle also Adapter 1 aus, dann gehe ich auf Gruppe erstellen.
Nun kommt die Warnung das das Team nur einen Adapter enthält, die wir bestätigen.
Nun wird gefragt in welchem Modus man das Team beteiben will. Im Gelben Feld darunter werden die Modi erklärt.
Ich gebe zunächte den gewünschten Teamnamen ein: "NIC TEAM1-2" wobei ich 1-2 zur Identifizierung der Netzwerk Adapter Hardware nutze.
Ich wähle den Betriebsmodus aus: SFT- Switch Fehlertolleranz, und klicke weiter.
Nun wird der primäre Adapter des Teams abgefragt- ich wähle NIC1.
und schliesse den Vorgang ab.
Je nach Intel ProSet Version und Windows Version, kann nun eine Fehlermeldung kommen, die zu ignorieren ist.
Offenbar checkt Proset nicht das es selber soeben die Hardware Liste unter Windows geändert hat. Peinlich.
Nun haben wir aber das erste Team mit einem Adapter erstellt.
Jetzt müssen wir den 2. NIC im Team einbinden.
Das mache ich indem ich auf "Mitglieder ändern" gehe.
Nun wähle ich den 2. NIC hinzu. und sage Änderungen übernehmen.
Nun zeigt sich folgendes Bild:
Wan noch fehlt ist den Adapter 2 als Sekundären Adapter auszuwählen, was ich nun mache. Dann drücke ich "Änderungen übernehmen".
Übrigens beachte man die grüne Markierung. Ich habe diese Konfiguration ohne angestecktes Netzwerkkabel gemacht, was sich dringend empfielt um die Switche nicht zu verwirren. Maximal kann bei der Aktion 1 Kabel in einem Adapter stecken!
Ab jetzt wäre der Rechner prinzipiell Einsatzbereit. Es müsste pro NIC auf einen anderen Switch/Router gesteckt werden, und beide Switche/Router auf Spanning Tree Protokoll korrekt konfiguriert sein.
An dieser Stelle richten wir nun unser Augenmerk auf das Kästchen "Gruppeneinstellungen" rechts daneben.
Darin geht es um die Konfiguration des Verhaltens im Störungsfall eines Weges. Prinzipiell sind die Voreinstellungen schon super, aber man sollte zumindest wissen was einstellt ist, um seinen Nutzungsfall besser zu unterstützen.
(Wenn man rechts einen der Parameter einstellt kann man unten im gelben Fenster eine gute Beschreibung lesen.)
Als Wichtig erachte ich den Paramater "Failback zulassen". Normalerweise läuft im von mir eingestellten SFT Modus die Strecke über den Weg1 der als "Primärer Adapter" eingestellt ist. Im Fehlerfall wird dann auf die Sekundären Adapter (Weg2) umgeschalten.
Nun kann es nach einem ersten Fehler zu folgenden Fällen kommen:
1. Fällt nun der aktive Sekundäre Weg2 aus und ist Failback abgeschalten, so fällt die gesamte Strecke aus.
Dabei ist es egal ob der Primäre Weg1 mittlerweile wieder geht, denn es wird nicht mehr automatisch zurück geschalten.
Dies hat sichtbar einen Nachteil wenn man erwartet das das System sich automatisch selbstheilend verhält.
So eine Einstellung macht nur Sinn wenn man ständig die Wege überwacht, und sehr schnell manuelle Eingriffe in den Weg vornimmt.
2. Ist der ausgefallene Weg1 nach einem Aussfall wieder betriebsfähig kann hier ein automatisches Failback auch Probleme bereiten. Denn nun wird (obwohl die Verbindung über Weg2 Fehlerfrei ist), bei Einstellung "primärer Adapter", zurückgeschalten auf Weg1.
Wenn aber zum Beispiel der Primäre Weg1 hohe zufällige Fehlerraten aufweist und immer wieder zusammenbricht kann das zu einer sich aufschwingenden hin und her Schalterei führen, was unter Umständen zum Ausfall der Datenverbindung trotz funktionierenden Backup Weg2 führt.
Beides Verhalten sind also nicht optimal.
Was man einstellt hängt aber auch davon ab ob beide Wege die gleiche Qualität und Datenrate aufweisen.
Ist eine Leitung besser, die andere nur ein schlechterer Notfallweg ( Kosten, Datenrate, Latenz, Verfügbarkeit) so würde ich ein automatisches Fallback auf jeden Fall aktivieren und den "Primären Adapter" festlegen.
Sind beide Wege gleichwertig, dann würde ich empfehlen die Einstellungen von Primären und Sekundären Adapter zu entfernen.
Das beschreibt Intel zwar nicht explizit so, aber ich würde es so verstehen, das dann erst im jeweiligen Fehlerfall auf die jeweils andere Leitung umgeschalten wird, und diese dann genutzt wird bis diese auch ausfällt. In diesem Falle wäre dann die Einstellung: Keine primären und sekundären Adapter definieren. Der Paramater automatisches Failback hat dann laut Beschreibung keine Funktion.
Dieses halte ich aus Erfahrung für das beste Systemverhalten bei gleichwertigen Verbindungen.
Egal was man macht: Danach ist ein Test angebracht ob das System sich wie gewünscht verhält!
Nun widmen wir uns dem Feld "Gruppeneinstellungen"
Unter lokal verwaltete Adresse könne man dem Adapter Team eine selbst zu wählende MAC Adresse spendieren. Das würde ich aber nur bei Hardwareersatz im Fehlerfall machen, wenn Installation, Lizenz oder die Umgebung identische MACs erfordern.
Aktivierungsverzögerung beschreibt das Zeitverhalten im Adapter Umschaltverhalten. Aus Anwendungssicht sind prinzipiell sind schnelle Umschaltungen erwünscht, damit die Anwendung den Leitungsausfall nicht mitbekommt.
Aber die Switche/Router müssen in dieser Zeit reagieren können. Deren Aufgabe besteht den dahinter liegenden Routern mitzuteilen das ab sofort die Team MAC Adresse über einen anderen Weg anzusprechen ist. Das dauert etwas Zeit.
Ich empfehle da Tests!
Prüfzeit: Das gibt das Testintervall an (auf physical Layer1 , soweit ich es verstanden habe) und somit auch die maximale Zeit bis der Ausfall einer Verbindung bemerkt wird. Nach dieser Zeit fängt dann das System zu schalten an. Es kommt also noch die Schaltzeit dazu bis die Verbindung wieder steht.
Beide Zeiten zusammen geben also die maximale Daten Unterbrechungs Zeit an.
Diese Zeit sollten Client-Server Verbindungen oder Datenbank Verbindungen überstehen. TEST!
Verbindungsüberwachung in der Funktion verbirgt sich eine Prüfzeit einer Verbindung auf Layer3. Also IP basiernde Prüfung zu einer eingetragen fernen IP Adresse.
Ansonsten gilt das zu "Prüfzeit" gesagte.
Überprüfung der Einstellungen in Windows:
Schaun wir uns unter Windows nun die Anzeige der Adapter in der Netzwerkeinstellung an:
Wie wir sehen hat Windows nun 3 Adapter eingetragen, obwohl nur 2 NICs eingebaut sind.
Der 3. Adapter ist nun das virtuelle Team. Nur dieser Team Adapter hat IP Settigns für IPV4 und evt IPV6.
Wir erkennen ihn an dem kürzeren Namen den wir in der Konfiguration vergeben haben, hier: "NIC TEAM 1-2"
Ich öffne nun dessen Eigenschaften:
Im Gegensatz dazu sind die 2 echten NICs nun deutlich anders in den Eintragungen:
Wie wir sehen steht hier nun als wichtigster Eintrag der "Intel Advanced Network Services Protokoll" drin, und keinerlei IPv4 oder IPV6
Und nicht das Testen auf allen OSI-Layern vor der Inbetriebnahme vergessen!!!