Ich möchte unser TS833XU-RP mit zwei separaten Switches verbinden, um im Falle eines Ausfalls eines Switches ein Failover zu ermöglichen.
In einem Testszenario habe ich einen Active/Backup-Trunk erstellt, dabei sind jedoch einige Fragen aufgetaucht:
Ist es möglich, den Netzwerkadapter zu entfernen, von dem der Trunk seine MAC-Adresse erhalten hat – kann ich die MAC-Adresse des Trunks ändern oder muss ich den gesamten Trunk löschen? (Wenn ich mit der Maus über die Abwählen-Schaltfläche fahre, erscheint folgende Meldung: „Sie können den Adapter nicht abwählen. Die MAC-Adresse des Adapters wird derzeit vom Port-Trunking-Port verwendet.“)
Wie kann ich ein „primäres“ Interface für einen Trunk auswählen, das nach einer Wiederherstellung als aktives Interface verwendet wird? (Im Testaufbau blieb das zuletzt aktive Interface aktiv.)
Kann ich einen Active/Backup-Trunk über zwei LACP-Trunks erstellen?
Ein Trunk ist eigentlich nicht dafür gedacht, zwischen zwei verschiedenen Switches verwendet zu werden. Es wäre besser, einfach zwei separate Netzwerkverbindungen zu nutzen und dem QNAP die Entscheidung zu überlassen, welche Verbindung am schnellsten/optimal ist. Trunking ist eigentlich dafür gedacht, mehrere Ports zu kombinieren, um die Geschwindigkeit der Verbindung zu erhöhen – also zwei 1-Gbit-Ports für eine 2-Gbit-Verbindung, zwei 2,5-Gbit-Ports ergeben 5 Gbit usw. Ja, man kann Dinge so einrichten, dass man eine Ausfallsicherheit hat usw., aber das ist eigentlich nicht dafür ausgelegt, über zwei Switches hinweg gemacht zu werden. Ich habe das so noch nie gesehen.
Um auf deine Fragen zu antworten – ich glaube nicht, dass du die MAC-Adresse des Trunks ändern kannst. Warum möchtest du das tun?
Zu Frage 2: Ich glaube nicht, dass du auswählen kannst, welcher Port primär und welcher sekundär ist. Das wird alles vom Protokoll geregelt.
Zu Frage 3: Ich habe noch nie die Möglichkeit gesehen, Trunks von Trunks zu erstellen. Das ergibt keinen Sinn. Ein Trunk ist bereits ein gekapselter Tunnel, bei dem der Datenverkehr auf beide Verbindungen aufgeteilt wird. Was wäre der Zweck, einen „Trunk eines Trunks“ zu erstellen? Der Trunk hat bereits Redundanz eingebaut. Ich werde mal versuchen, einen Trunk-Port zu einem anderen Trunk auf einem meiner Ciscos hinzuzufügen…
Hallo NA9D,
vielen Dank für deine Antwort.
Meiner Meinung nach ist ein Active/Passive-Trunk dafür ausgelegt, den passiven Port zu aktivieren, wenn der Switch am aktiven Port ausfällt (oder während eines Firmware-Upgrades neu startet). In diesem Fall sollte der passive Port besser nicht mit demselben Switch verbunden werden.
Um meine Fragen etwas zu präzisieren:
Zu Frage 1: Wenn ich einen Active/Passive-Trunk über eine 1 Gbit- und eine 10 Gbit-Schnittstelle erstelle und später Geld für zusätzliche 10Gbit-Schnittstellen ausgebe, würde ich dazu tendieren, die 1 Gbit-Schnittstelle aus dem Trunk zu entfernen, damit die Failover-Verbindung definitiv über die 10 Gbit-Schnittstelle läuft.
Zu Frage 2: Ja, scheint bei einem QNAP durch das Protokoll geregelt zu sein. (Oder ich habe die entsprechenden Einstellungen übersehen.) Unter Linux ist es kein Problem, ein primäres Interface für ein Active/Passive-Bond festzulegen… Das hat den Vorteil, dass ich festlege, welcher Netzwerkswitch den „normalen“ Traffic übernimmt.
Zu Frage 3: Meiner Meinung nach hat ein Trunk aus Trunks den Vorteil, (zwei) (LACP-)Trunks zur Bandbreitenaggregation zu erstellen, jeden mit einem separaten (ToR-)Switch zu verbinden und sie dann in einem Active/Passive-Trunk für höhere Verfügbarkeit zusammenzufassen. (Wir nutzen diese Konfiguration auf mehreren Linux-Hosts und auch auf unserem NetApp.)
Netzwerkswitches (wie deine Ciscos) verwenden STP oder SPB, um die Redundanz der Inter-Switch-Verbindungen zu verwalten.
Es scheint in deinem Fall einfacher zu sein, einfach eine 10-Gbit-Verbindung und eine 1-Gbit-Backup-Verbindung zu haben. Verzichte auf Trunking. Habe einfach zwei Verbindungen und zwei IPs. Ein Trunk würde die Sache wohl vereinfachen, da du nur eine einzige IP hättest.
Ich weiß nicht, ob QNAP den Typ von Trunk unterstützt, den du machen möchtest…
Hallo zusammen! Ich bin neu hier und auch neu beim Wechsel zu QNAP, aber eigentlich kein wirklicher Wechsel. Bedeutet „Trunk“ in der QNAP-Welt ein LAG/LACP? Also das Kombinieren von zwei oder mehr Ports, damit sie wie ein einziger funktionieren. Ich habe „Trunks“ immer als eine Möglichkeit verstanden, alle VLANs über einen Port zu übertragen.
Ich bin hier, weil ich eine Möglichkeit suche, Trunks (alle VLANs über einen Port) auf dem QSW-M3216R-8S8T einzurichten und habe diesen Beitrag gelesen. Sorry fürs Kapern, ich versuche nur, mich mit der QNAP-Terminologie vertraut zu machen.
Ja, ich verstehe die Verwirrung. In der Cisco-Terminologie ist ein Trunk-Port ein Port, auf dem mehrere VLANs über einen einzelnen Port gekapselt werden. Ein Port-Channel ist ein LAG (Link Aggregation Group). In der QNAP-Welt sind Trunks LAGs.
Verstanden! Vielen Dank für die Klarstellung. Meine nächste Frage ist also: Kann QNAP „Trunk-Ports“ im Sinne von Cisco unterstützen? Ich habe große Schwierigkeiten, dazu etwas zu finden.
Ich bin mir nicht ganz sicher, was du hier versuchst und warum du mehrere VLANs zum QNAP senden möchtest. Wahrscheinlich wäre VLAN-Routing für dich die bessere Lösung.
Möglicherweise kannst du einige Trunk-Ports über die Virtual Switch-Funktion des QNAP einrichten, aber da bin ich mir nicht sicher.
Der QSW wird mit (4) HPE e920 Blades in einem EL8000 verbunden. Jede der Blades wird Oracle Linux mit K8s und VMs ausführen. Die Segmentierung erfolgt in VLANs für bestimmte Workloads. Daher müssen die vier „Hosts“ alle VLANs über die Uplinks für den Nord/Süd-Verkehr sehen können.
Moment mal – Sprichst du hier von einem QNAP NAS oder einem QNAP Switch?
Falls du von einem QNAP Switch sprichst, solltest du wahrscheinlich einen neuen Thread starten. Ich habe keine Kenntnisse darüber, was QNAP Switches können. Ich nehme aber an, dass sie Trunks unterstützen.
Alles, was ich bisher gesagt habe, bezieht sich auf QNAP NAS.
Frage: 2 Wie kann ich eine „primäre“ Schnittstelle für einen Trunk auswählen, die nach der Wiederherstellung die aktive Schnittstelle wird? (Im Testaufbau blieb die zuletzt aktive Schnittstelle aktiv) Antwort:
Ich freue mich, Ihnen mitteilen zu können, dass unser Entwicklungsteam die Überprüfung abgeschlossen hat. Es ist möglich, eine primäre Schnittstelle festzulegen.
Allerdings erlauben nur die Modi active_back, balance-tlb und balance-alb die manuelle Festlegung der primären Schnittstelle.
Bezüglich Ihrer Frage 3: „Kann ich einen Active/Backup-Trunk über zwei LACP-Trunks erstellen?“
Um Ihre Anfrage besser zu verstehen und eine präzise Empfehlung geben zu können, könnten Sie bitte weitere Details zu Ihrer geplanten Konfiguration mitteilen?
Was ist der genaue Anwendungsfall oder das Szenario, das Sie erreichen möchten?
Gibt es eine bestimmte Anforderung an Failover oder Redundanz, die diese Konfiguration notwendig macht?
Ihre Informationen helfen uns dabei, zu beurteilen, ob diese Art der Konfiguration möglich ist und Ihnen die passendste Lösung zu empfehlen.
Ich möchte zwei Schnittstellen (eth0 und eth1) für Bandbreitenaggregation in einem LACP-Kanal (bond0) zu switch1 bündeln
und zwei weitere Schnittstellen (eth2 und eth3) in einem zweiten Trunk (bond1) zu switch2
(beide Switches sind „Standalone“ – kein Stack, kein MLAG usw.)
Nun möchte ich bond0 und bond1 zu einem aktiven/passiven Trunk bond2 für Redundanz hinzufügen, sodass, wenn switch1 offline geht, bond2 bond1 als aktiven Port setzt
Vielen Dank für die ausführliche Erklärung und das Diagramm – das hilft sehr, um Ihre gewünschte Konfiguration zu verstehen.
Wir haben dieses Setup mit unserem technischen Team überprüft, und leider wird die von Ihnen angestrebte Konfiguration – das Verschachteln von Bonding-Interfaces (d. h. das Kombinieren von bond0 und bond1 zu einem übergeordneten bond2) – nicht unterstützt. Dies liegt an einer Einschränkung des Linux-Bonding-Treibers, der Bonding innerhalb eines anderen Bonds (verschachteltes Bonding) nicht erlaubt. Daher unterstützt auch unser QNAP-System diese Konfiguration nicht.
Wir verstehen Ihr Ziel, eine hohe Verfügbarkeit zu erreichen und Dienstausfälle zu minimieren, und schätzen Ihr Engagement bei der Entwicklung einer widerstandsfähigen Netzwerkarchitektur sehr. Auch wenn verschachteltes Bonding nicht möglich ist.
Bei QNAP arbeiten wir kontinuierlich daran, unsere Produkte zu verbessern und Funktionen bereitzustellen, die den Erwartungen unserer Kunden entsprechen. Wir werden Ihren Vorschlag unserem Entwicklungsteam zur Bewertung weiterleiten. Nach einer gründlichen Machbarkeitsstudie wird dieser für eine mögliche Aufnahme in zukünftige Updates in Betracht gezogen.
Wir schätzen Ihr Feedback sehr – es hilft uns, uns weiterzuentwickeln und Ihre Bedürfnisse besser zu erfüllen.
