Wir verwenden derzeit „Link Status Only“ für unsere NIC-Teams auf unseren VM-Hosts, sind aber kürzlich auf ein Problem gestoßen, bei dem einer unserer beiden Switches einen Speicherfehler hatte und den Datenverkehr nicht mehr weiterleitete. Alle unsere VM-Hosts fielen aus und die meisten Gäste (die diesen Pfad bereits verwendet hatten) reagierten ebenfalls nicht mehr, bis wir diesen Switch manuell abschalteten.
In der Linux-Bonding-Umgebung können Sie arp_intervals als weitere Möglichkeit zum Erkennen des Verbindungsstatus verwenden, in VMWare gibt es jedoch nur Beacon Probing. BP ist nicht dasselbe wie arp_interval, da Sie keinen Host zum Testen der Konnektivität auswählen und außerdem drei oder mehr Schnittstellen benötigen, um dies zu tun.
Alle unsere VM-Hosts verfügen über vier NICs, sodass die Anforderung von drei NICs kein allzu großes Problem darstellen sollte. Während in der Dokumentation jedoch nur angegeben wird, dass mindestens drei separate physische NICs (pNICs) erforderlich sind, verfügt jedes Beispiel auch über drei separate physische Switches, und es wird nicht angegeben, ob dies ebenfalls eine Anforderung ist. Als ich nach der Antwort darauf gesucht habe, stieß ich aufDasBlog, in dem es heißt:
„Verwenden Sie Beacon Probing nicht, wenn mehr als ein pNIC im vSwitch mit demselben pSwitch verbunden ist. Dies könnte dazu führen, dass dieselbe MAC-Adresse auf zwei oder mehr Ports des pSwitch angezeigt wird, was „eine sehr schlechte Sache“ ist.“
Wir haben in unserer Konfiguration keine drei Switches, die dieses Problem noch verschärfen würden. Bei einigen meiner vorläufigen Tests traten unerklärliche Link-Flapping-Probleme auf, die möglicherweise damit zusammenhängen, dass die Switches an denselben Switch angeschlossen waren.
Sind also auch drei separate physische Switches eine Voraussetzung für die Beacon-Prüfung? Bin ich für meine Konfiguration nur auf den Link-Status beschränkt? Und, halb rhetorisch, warum haben sie arp_interval nicht als Option in ihrem NIC-Teaming?
Antwort1
Beim Beacon-Probing wird empfohlen, mindestens 3 pNICs zu verwenden, da der Beacon so am besten funktioniert. ESXi sendet ein Broadcast-Paket aus den physischen NIC-Karten. Die anderen pNICs innerhalb desselben vSwitches warten dann, ob sie die Pakete von den anderen pNICs empfangen. Wenn die pNIC den Broadcast nicht empfängt, geht ESXi davon aus, dass es sich um einen Downlink handelt.
Alle 3 pNICs an denselben Switch anzuschließen und Beacon Probing zu verwenden, ist eine Verschwendung von Ressourcen, wenn der Linkstatus funktionieren würde, weil es einfacher ist. Ist der Link ein- oder ausgeschaltet? Konfigurationsprobleme (STP oder Portblöcke) werden beim Linkstatus nicht angezeigt.
Die Absicht und das Design der Beacon-Prüfung bestand darin, die pNICs an verschiedene pSwitches anzuschließen, da sie zum „Testen“ nachgelagerter Switches verwendet wurde; Switches, die über die Switches hinausgehen, an die die pNICs angeschlossen waren. BP kann feststellen, ob beispielsweise der 3. pSwitch nachgelagert zum iSCSI-SAN ausgefallen ist. Der Link-Status erkennt dies nicht, BP jedoch schon. Dann kann der ESXi-Server bestimmen, was er tun möchte. Der Link-Status würde weiterhin versuchen, Pakete an das SAN zu senden, auch wenn es nicht verfügbar ist.