killtec
Goto Top

ESXi-Server NIC Trunking vs. Einzeln

Hallo,
wir haben bei uns mehrere Server (ESXi) wo jeweils die einzelnen NICS separat auf den Switch gehen. Ich habe mich nun gefragt, ob es sinnvoll ist (aus Performancegründen) die NIC's als Trunk zum Switch zu packen und alle vserver auf einen Virtuellen Switch zu packen. Kann hierzu jemand etwas sagen, hat jemand Erfahrungswerte?

ESXi-Version: 5.0
Gast-OS: Windows 2008R2, Linux

Gruß

Content-Key: 283571

Url: https://administrator.de/contentid/283571

Printed on: April 18, 2024 at 00:04 o'clock

Member: aqui
aqui Sep 22, 2015 at 11:23:10 (UTC)
Goto Top
Einzeln ohne eine Aggregation Techknik oder Separation in VLANs wäre tödlich, denn es droht immer ein L2 Loop.
Ein Trunking oder Lonk Aggregation mit 802.3ad und LACP ist also immer der richtige Weg.
http://rickardnobel.se/lacp-and-esxi-5-1/
Member: clSchak
clSchak Sep 22, 2015 at 11:30:51 (UTC)
Goto Top
Hallo

@aqui du verwechselst da etwas, bei VMWare hast du zwar eine vSwitch aber dem ist egal mit wie vielen Ports du wohin gehst, unser Server "hängen" auch mit 4+ Ports am Switch ohne das LACP oder ähnliches eingestellt - ist ja keine Connect von Switch zu Switch im eigentlichen Sinne.

@killtec LACP, Trunk oder ähnliches kannst überall machen, außer bei iSCSI da sollte man das lassen damit die Vorteile von MPIO greifen können.

Gruß
@clSchak
Member: killtec
killtec Sep 22, 2015 at 11:41:02 (UTC)
Goto Top
Hi,
also gedacht ist halt die jetzt vier separaten vSwitche, die einzeln via 1GBit Link auf den Switch gehen in ein vSwitch zu packen und das mit einem 4Gbit LACP zum Normalen Switch zu machen.
Das Einzigste, was via iSCSI ist, wäre der Zugriff auf ein Backupnas von einem einzelnen Server, ggf, noch zwei Admin-PC's. Siehe dazu:
ISCSI Volume NTFS-Formatiert - was geht

Gruß
Member: SlainteMhath
SlainteMhath Sep 22, 2015 at 11:45:44 (UTC)
Goto Top
Moin,

vier separaten vSwitche, die einzeln via 1GBit Link auf den Switch gehen
Also das ist schon mal die schlechteste Konfig von allen. Hier hast du weder Redundanz noch Lastverteilung.
Pack alle VMs und alle Uplinks auf einen vSwitch, dann passt es. LACP Trunks würde ich perönlich nicht konfigurieren.

lg,
Slainte
Member: catachan
catachan Sep 22, 2015 at 11:51:55 (UTC)
Goto Top
Hi

@aqui
wir haben bei uns mehrere Server (ESXi) wo jeweils die einzelnen NICS separat auf den Switch gehen

In diesem Fall kümmert sich VMware auf dem vSwitch um das richtige Load balancing und um eine Loop freie Topologie

LG
Member: killtec
killtec Sep 22, 2015 at 12:38:08 (UTC)
Goto Top
Hi,
Also im Moment haben wir das so (1 JPG sagt Mehr als 1000 Docs :D ):
0f870e9b43226426e67250bb6c81be7a

Diese 4-5 Adapter dachte ich als LCAP auf den Switch laufen zu lassen. Also ein VSwitch und dann die Physischen Adapter auch auf einen VSwitch. Hoffe ich drücke mich richtig aus face-smile -> VMWare macht das Balanching dann wirklich selbst? Gibt es da keine Loops?

Will das jetzt nicht einfach so testen, ist nen Produktivsystem....

Gruß
Member: SlainteMhath
SlainteMhath Sep 22, 2015 at 12:46:12 (UTC)
Goto Top
Jo, genau so isses Mist.

So muss das:

325fdf76ab53c8c4e539136ebf330fde
Member: killtec
killtec Sep 22, 2015 at 12:55:27 (UTC)
Goto Top
OK, und du hast deine vmnics nicht als Trunk gemacht?
Member: aqui
aqui Sep 22, 2015 at 13:05:20 (UTC)
Goto Top
du verwechselst da etwas, bei VMWare hast du zwar eine vSwitch aber dem ist egal mit wie vielen Ports du wohin gehst,
Sorry aber kann ich mir nicht wirklich vorstellen.
Es ist unmöglich das man den vSwitch einfach so ohne jegliche Konfig parallel iirgendwo raufsteckt. Jeder Laie weiss das das im Ethernet nicht geht und man so einen Loop hat.
Gut wenn der STP aktiviert hat dann geht das und dann blockt er halt von 4 Ports 3 wieder und gut iss. Aber genau DAS will man ja nicht.
Wenn also eine Bündelung mit 802.33ad / LACP dann muss das auch auf einem vSwitch und auf der HW Intrafstruktur aktiviert sein.
Anders kann es nicht gehen...oder wäre ein netztechnisches Wunder face-wink
In diesem Fall kümmert sich VMware auf dem vSwitch um das richtige Load balancing und um eine Loop freie Topologie
Das mag sein aber ganz sicher nicht von ganz allein, denn wie sollte das gehen ?
Member: SlainteMhath
SlainteMhath Sep 22, 2015 at 13:20:09 (UTC)
Goto Top
OK, und du hast deine vmnics nicht als Trunk gemacht?
Genau.

@aqui
Sorry aber kann ich mir nicht wirklich vorstellen.
Es ist unmöglich das man den vSwitch einfach so ohne jegliche Konfig parallel iirgendwo raufsteckt.
Das sind bei den vSwitches keine "normalen" Switchports sondern dedizierte Uplinks über die VMWare in der default Einstellung MVs im "Round Robin" mit dem phys. Switch verbindet. Ein loop kann da nicht entstehen.
Member: aqui
aqui Sep 22, 2015 at 13:25:09 (UTC)
Goto Top
Das weiss der externe Switch aber nicht und loopt oder versucht es. Wie verhindert der vSwitch das ?
Member: killtec
killtec Sep 22, 2015 at 13:39:58 (UTC)
Goto Top
Werde das nachher mal zuhause nachstellen und testen...
Member: SlainteMhath
SlainteMhath Sep 22, 2015 at 13:42:14 (UTC)
Goto Top
Zitat von @aqui:

Das weiss der externe Switch aber nicht und loopt oder versucht es. Wie verhindert der vSwitch das ?
Der vSwitch forwarded grundsätzlich nicht zwischen den Uplinks,/vNICs sondern nur zwischen Uplinks und VMs
Member: aqui
aqui Sep 22, 2015 at 15:03:53 (UTC)
Goto Top
Der vSwitch forwarded grundsätzlich nicht zwischen den Uplinks,/vNICs sondern nur zwischen Uplinks und VMs
Mmmmhhh, wie kann er denn aber eine bidirektionale Layer 2 Kommunikation im Ethernet leisten ? Das wäre ja dann technisch unmöglich wenn das nur eine Einbahnstrasse ist.
Mitglied: 108012
108012 Sep 22, 2015 at 16:02:36 (UTC)
Goto Top
...oder wäre ein netztechnisches Wunder
Und so etwas gibt es eben nicht!

Ein LAG (LACP) ist immer eine zwei seitige Sache, also eine Sache mit zwei Enden
und das LACP konfiguriert dann auf beiden Seiten automatisch die LAG.

Das sind bei den vSwitches keine "normalen" Switchports sondern dedizierte
Uplinks über die VMWare
Richtig nur muss trotz alle dem dann dort auf beiden Seiten des LAGs mittels
LACP ausgehandelt werden was, wer, wo, mit wem und wie weiterleitet.

in der default Einstellung MVs im "Round Robin" mit dem phys. Switch verbindet.
Macht @Dani auch so bei sich im Betrieb hat sie hier mal geschrieben und sogar
mittels statischem LAG und iSCSI, aber dann ist eben kein LACP mit im Spiel und
man muss wirklich aufpassen das auf beiden Seiten des LAGs alles genau gleich
konfiguriert wird sonst wird es nichts mit dem LAG.

Werde das nachher mal zuhause nachstellen und testen...
Wären denn eventuell noch PCI/PCIe Slots frei und man sollte eventuell
auch einmal eine 10 GBit/s Dual Port Karte mit ins Auge fassen?
Ist jetzt nicht böse gemeint nur wenn es der Performancesteigerung
dienen soll ist das auch eine Sache die recht schnell sehr gute Ergebnisse
liefern könnte.

Gruß
Dobby
Member: killtec
killtec Sep 22, 2015 at 16:17:56 (UTC)
Goto Top
Hi, habe das mal "nachgestellt"
Allerdings ohne 10G Karte... Hat der Switch nicht und der Server auch nicht.
Ein Loop wurde nicht erkannt... (Nichts in den Switch logs eingetragen).
In dem Produktivsystem klappt das auch nicht mit der 10 Gig Karte. Die Performance soll auf den Uplinkstrecken laufen... U.A. Wegen Backups auf dem iSCSI Ziel...

Gruß
Member: aqui
aqui Sep 22, 2015 updated at 17:22:02 (UTC)
Goto Top
Allerdings ohne 10G Karte... Hat der Switch nicht und der Server auch nicht.
Macht nix mit 1G oder 100Mbit gehts ja auch face-wink
Ein Loop wurde nicht erkannt...
Rennt auf den vSwitches oder deinem externen evtl. Spanning Tree per Default ? Das wäre dann eine Erklärung.
Mach mal ein "show spanning tree" auf dem externen ob du einen Bridge Neighbor siehst ! Würde dann für STP sprechen...

Wichtig ist das die Ports des vSwitch die über unterschiedliche physische NICs auf einen externen Switch gehen in der gleichen Layer 2 Broadcast Domain, sprich VLAN liegen müssen und einen Loop zu provozieren.
In getrennten passiert das logischerweise nicht.
Der Switch muss dann Broad- oder Multicast Pakete zwingend forwarden auf allen Ports was ein sofortiges Looping auslöst. Es sei denn....
einer der Switches sei es vSwitch oder der Externe spricht Spanning Tree !
Oder es reicht auch wenn der externe Switch Spanning Tree spricht und der vSwitch Spanning Tree BPDU Paket "durchschleift" so das sie am externen Switch dann wieder ankommen und der sein Ports in Blocking setzt.
Nur so kann man ja einen Loop vermeiden.
Man müsste das auch sehen wenn man mal einen Wireshark an den ESXi mit vSwitch hängt. Dort müssten dann STP BPDU Frames zu sehen sein....
Vermutlich passiert das bei allen Unwissenden die parallele Links stecken. Die merken dann nur an schlechter Perfmance da immer n-1 Links in Blocking gehen.
Wenn aber vSwitch und externer Switch keinerlei Loop Protection haben sei es STP oder ähnliches muss es ja zwangsweise zum Loop kommen.

Will man also mehrere Links am vSwitch parallel nutzen auf einen externen Switch, was ja durchaus sehr viel Sinn macht wenn man multiple NICs mit einer 4er Karte oder sowas im Server hat, muss man also eine Art von Aggregation machen.
Wie Kollege @108012 oben richtig sagt ist das immer eine zweisetige Angelegenheit, sonst klappt das nicht.
Da geht dann nur statische Aggregation oder immer besser die mit LACP.
Beide basieren auf dem 802.3ad Balancing Algorithmus also dem XOR Link Hashing auf Basis der letzen 4 Bit der Mac oder IP Adresse. Bessere Switches hashen noch den Port mit dazu damit sie granularer werden in der Verteilung der Layer 2 Sessions über die Links.
Letzteres ist auch immer der Nachteil von Link Aggregation, da ein Balancing nie homogen ist aufgrund der nicht homogenen Verteilung der Macs oder IPs.
Besser ist denn da doch immer noch die "Fat Pipe" mit 10 oder 40G face-wink
Member: Th0mKa
Th0mKa Sep 22, 2015 at 19:59:43 (UTC)
Goto Top
Zitat von @aqui:

Das mag sein aber ganz sicher nicht von ganz allein, denn wie sollte das gehen ?

Moin,

das geht und zwar fuer den Anwender wirklich "von ganz allein". Man kann z.B. die Nutzung der NICs anhand des IP Hashes konfigurieren, dafuer muss an den phyhsischen Switches nix konfiguriert werden. Bei Ausfall einer NIC wird dann halt neu gewuerfelt...

VG,

Thomas
Mitglied: 108012
108012 Sep 22, 2015 at 22:10:52 (UTC)
Goto Top
das geht und zwar fuer den Anwender wirklich "von ganz allein". Man kann z.B. die
Nutzung der NICs anhand des IP Hashes konfigurieren, dafuer muss an den
phyhsischen Switches nix konfiguriert werden. Bei Ausfall einer NIC wird
dann halt neu gewuerfelt...
Das wäre natürlich eine Erklärung, aber die NICs müssen wenn man am Switch LAG
(LACP) einstellt doch auch via LACP angebunden werden, sicher wenn das dann intern
anders gehandhabt wird ist das ja auch eine ganz andere Sache.

Gruß
Dobby
Member: sk
sk Sep 22, 2015 updated at 23:45:12 (UTC)
Goto Top
@aqui&Dobby: Ihr könnt den anderen ruhig glauben. Auch bei uns funktioniert das so. Gänzlich ohne Teaming/Link Aggregation und STP. Da loopt nichts und es geht auch kein Port auf blocking. Entsprechend konfiguriert kümmert sich vmware um das Loadbalancing und das Failover. Unser vmware-Spezi hatte mir vor Jahren bei der Ersteinrichtung auch die Konfigurationsmöglichkeiten und deren Vor- und Nachteile erläutert. Gemerkt hab ich es mir leider nicht. Meine Zuständigkeit hört (zumindest in diesem Fall) bei den aktiven Netzkomponenten auf. face-wink

Gruß
sk
Member: Th0mKa
Th0mKa Sep 23, 2015 at 06:35:11 (UTC)
Goto Top
Zitat von @108012:

Das wäre natürlich eine Erklärung, aber die NICs müssen wenn man am Switch LAG
(LACP) einstellt doch auch via LACP angebunden werden, sicher wenn das dann intern
anders gehandhabt wird ist das ja auch eine ganz andere Sache.


Man stellt am Switch kein LACP ein, es werden ganz normale Access Ports benutzt.

VG,

Thomas
Member: SlainteMhath
SlainteMhath Sep 23, 2015 at 06:47:04 (UTC)
Goto Top
Um das ganze mal abzukürzen... Hier liegt das PDF von Vmware zum Thema "VMware Virtual Networking Concepts" - da lässt sich (ab Seite 4) alles nachlesen.

Zusammengefasst:
- Multiple phys. Uplink pro vSwitch
- kein STP nötig
- kein LACP nötig
Member: killtec
killtec Sep 23, 2015 at 06:57:49 (UTC)
Goto Top
Hi,
also kann demnach auch durchaus eine ungerade Zahl von Links auf einem vSwitch "gesteckt" werden ohne ein LACP zu nutzen, richtig?
Das ist aber dann eine Spezielle VMWare Funktion oder?

Gruß
Member: SlainteMhath
SlainteMhath Sep 23, 2015 at 07:07:54 (UTC)
Goto Top
also kann demnach auch durchaus eine ungerade Zahl von Links auf einem vSwitch "gesteckt" werden ohne ein LACP zu nutzen, richtig?
Gerade, ungerade, völlig egal.

Das ist aber dann eine Spezielle VMWare Funktion oder?
Wenn du willst, ja.
Member: aqui
aqui Sep 23, 2015 updated at 08:14:48 (UTC)
Goto Top
das geht und zwar fuer den Anwender wirklich "von ganz allein". Man kann z.B. die Nutzung der NICs anhand des IP Hashes konfigurieren, dafuer muss an den phyhsischen Switches nix konfiguriert werden.
OK, das mag ja stimmen aber man muss ja immer auch die andere Seite sprich den externen Switch betrachten.
Der weiss ja gar nichts von den ominösen Algorythmen und Zaubereinen die der vSwitch da vollführt.
Wenn dort 2 oder 4 parallele Links gesteckt sind, dann forwardet der alles auch dahin solange das in einer L2 Domain ist. Er muss ja davon ausgehen das da auch 2 oder 4 einzelne Endgeräte dran sind.

Der vSwitch kann ja dedizierte Mac Pärchen verteilen...keine Frage aaaaber...
Was passiert mit inbound Broad- und Multicasts und vor allen Dingen mit STP Paketen die der externen Switch an diese Ports flutet ?? Wie verhält sich der vSwitch da ?? Droppt der die ?? Kann er ja nicht....
Spannend die Frage was mit STP Paketen passiert ?
Wenn er die durchschleift, dann gehen alle parallelen Ports am externen Switch in Blocking.
So würde dann wieder ein Schuh draus das der vSwitch "das von alleine" kann. Anders nicht.
Hilft wohl nix.... muss man wohl mal die VmWare Spezifikation zum vSwitch lesen...

Die Doku hier:
http://www.admin-magazin.de/Das-Heft/2010/05/Redundante-Netzanbindung-m ...
Ist da aber ganz klar und eindeutig: (Zitat):
In der Regel entscheidet man sich, zumindest auf einem virtuellen Switch zwei physische Netzwerkadapter zusammenzufassen. VMware nennt dies NIC Teaming. Bei der IEEE ist der geläufige Begriff Link Aggregation, definiert in der IEEE 802.1ax (früher 802.3ad). Neben VMware nutzen auch die meisten anderen Hersteller eigene Marketingbegriffe, um Link Aggregation zu beschreiben. Üblich sind zum Beispiel die Bezeichnungen Etherchannel, Trunking, Bündelung, Teaming oder Port Aggregation.

Link Aggregation bezeichnet die parallele Bündelung von mehreren Netzwerkadaptern zu einem logischen Kanal. Diese Technik bietet zwei wesentliche Vorteile gegenüber der klassischen Verkabelung mit einem Netzwerkkabel: höhere Verfügbarkeit und höhere Übertragungsgeschwindigkeiten. Solange zumindest ein physischer Link vorhanden ist, bleibt die Verbindung bestehen, nur die zur Verfügung stehende Bandbreite verringert sich.


Es ist ausschliesslich von Link Aggregation die Redebei Verwendung paralleler NICs ! Eine Option die einfaches paralleles Zusammenstecken auf einem externen Switch beschreibt existiert ja de facto nicht !
Das wäre auch sehr verwunderlich, denn es würde sämtlichen Ethernet Konventionen widersprechen.

Den Schluss den man dann daraus ziehen kann ist das Admins die ohne Konfig einfach so mal parallele Links zusammenstecken dann vom Spanning Tree "gerettet" werden der ihnen alle Links bis auf einen wieder abschaltet (Blocking) um so ein Looping zu verhindern.
Member: Th0mKa
Th0mKa Sep 23, 2015 at 09:00:13 (UTC)
Goto Top
Zitat von @aqui:

Den Schluss den man dann daraus ziehen kann ist das Admins die ohne Konfig einfach so mal parallele Links zusammenstecken dann vom Spanning > Tree "gerettet" werden der ihnen alle Links bis auf einen wieder abschaltet (Blocking) um so ein Looping zu verhindern.

Nein, die werden nicht vom STP gerettet weil STP nicht notwendig ist. Im von SlainteMhath verlinkten Dokument kannst du auf Seite 5 lesen warum es nicht notwendig ist. Und ja, wenn man moechte kann man natuerlich LACP verwenden - macht aber fuer kleinere Installationen keinen Sinn weil es das Setup unnoetig verkompliziert.
Member: aqui
aqui Sep 23, 2015 updated at 16:15:53 (UTC)
Goto Top
OK, das Dokument klärt das ! Ein zusätzlicher Anruf bei einem VmWare Profi beim Hersteller selber erklärte dann den Rest.
Des Rätsels Lösung ist das der vSwitch kein "richtiger" Switch ist bzw. nicht als solcher funktioniert.
Inbound Broad- und Multicast Traffic wird nicht wieder an diese Ports geforwardet. Letztlich funktionieren diese Ports quasi wie ein PVLAN oder isolated VLAN auf einem "richtigen" Switch..
Zusätzlich kommt hinzu das der vSwitch eine dedizierte Zuweisung der VMs auf die Ausgangsports NICs macht.
Aus Sicht eines externen Switches sieht es dann so aus als ob diese Ports quasi die Endgeräte Ports sind so als wenn die VMs physisch daran angeschlossen sind.
Werden mehrere VMs gemappt ist das so wie ein kleiner 5 Port Dummswitch der da angeschlossen ist.
OK so wird ein Schuh draus.....

Damit ist aber auch klar das es mit dieser einfachen und normalen Vorgehensweise des VM Mappings am vSwitch keinerlei Link Aggregation gibt. Eine VM kann immer nur starr ihren zugewiesen Port nutzen.
OK, bei wenigen VMs auf einem Host ist das dann sicher egal aber hat man mehrere VMs auf wenigen NIC Ports ist ein Balancing mit 802.3ad (oder .ax) und LACP (oder ohne LACP mit statischen Trunks) in jedem Falle vorzuziehen !

Auf alle Fälle hat die gute Diskussion hier mal gezeigt das ein vSwitch nicht wie ein "richtiger" Switch agiert !!
Dank auch des guten Dokument URL vom Kollegen @SlainteMhath
Case closed...
Mitglied: 108012
108012 Sep 23, 2015 at 16:36:40 (UTC)
Goto Top
Ich hätte aber noch zwei Fragen dazu.

1.- Wenn man nun eine Intel Quad Port Server NIC nimmt und ein an einem
verwalteten Switch ein LAG (LACP) damit bildet und dann erst einen vSwitch
auf dem Hypervisor anlegt und diesem vSwitch dann an 4 vPorts 4 VMs zuweist
und auf der anderen Seite nur diesen "einen Adapter" mit einer IP Adresse, sollte
das doch auch funktionieren oder etwa nicht?

2.- Wenn man 4 Intel Quad Port Server NICs im Server eingebaut hat und auch wieder ein
LAG anlegt was eventuell statisch ist und via Round Robin die Verteilung vornehmen soll.
Und dann lege ich 4 vSwitches intern an und weise dann je einem vSwitch eine Karte zu
bzw. ein Interface zu und auf der anderen Seite lege ich dann also 4 vSwitche an und
weise dann jeder VM einen eigenen vSwitch zu, sollte das nicht auch funktionieren?

Sicherlich braucht es intern kein LAG und kein LACP, nur wenn ich nun einmal via LAG
sei es nun dynamisch über LACP oder statisch die Daten verteilen will, kann man dann
nicht vorher ein LAG aufsetzen und dann trotzdem dem vSwitch zuweisen?

Gruß
Dobby
Member: aqui
aqui Sep 23, 2015 updated at 17:06:57 (UTC)
Goto Top
1.)
Nein, das funktioniert de facto nicht. Du hast ja kein 802.3ad / LACP auf dem vSwitch eingerichtet ! Jedenfalls hast du das nicht geschrieben oben ?!
Musst du aber machen damit der Trunk aktiv wird.
Ohne LACP Polling beiseitig wird der externe Switch den LAG nicht aufbauen und den auf "shutdown" setzen ! Wie du selber immer richtig sagst: Link Aggregation ist immer eine zweiseitige Angelegenheit !!! face-smile
802.3ad / LACP MUSS also zwingend auch auf der vSwitch Seite aktiviert sein, dann klappt es natürlich.
Minimal aber ein statisches Trunking / LAG auf dem vSwitch. Analog dann auch statisches Trunking auf dem externen Switch.
So klappt das und wäre der richtige Weg für ein Load Balancing.
OK, wenn du eine Quad Karte hast mit 4 VMs musst du das nicht. Denn dann kann jede VM einen Port haben. Hast du aber 8 oder 16 VMs ist eine Link Aggregation Konfig erheblich besser als ein NIC Sharing, da die Traffic Verteilung so homogener ist.
2.)
und via Round Robin die Verteilung vornehmen soll.
Das ist technisch unmöglich. Es gibt keinen Standard der Round Robin kann ! Trunking bzw. Link Aggregation funktioniert immer nur mit Hashing ! Das ist vom IEEE 802.3ad bzw. .ax Standard zwingend so vorgegeben.
Das was du mit der VM zu vSwitch zu NIC Zuweisung beschreibst macht VmWare schon von sich aus. Das ist das was nicht switchkonform" ist verglichen zu normalen Switches. Eine VM bekommt einen dedizierten vSwitchport der wieder dediziert einem NIC Port zugewiesen wird.
Die VM "sieht" einzig nur diesen Port und NIC. Das ist das was mit PVLAN und Isolated VLAN gemeint ist auf "normalen" Switches.
Fakt ist: Für Trunking bzw. Link Aggregation MUSS beidseitig 802.3ad / ax mit oder ohne LACP aktiviert sein sprich vSwitch UND externer Switch müssen das konfiguriert haben.

Sicherlich braucht es intern kein LAG und kein LACP
Doch ! Wenn damit nach außen kommuniziert wird.
Einer VM mehrere virtuelle NICs zuzuweisen die dann per LAG auf den vSwitch zu legen ist völliger Unsinn, das ist richtig.
Die virtuellen Links intern arbeiten mit Systemgeschwindigkeit, da gibt es keine Infrastruktur bestimmten Speeds wie im Ethernet. Folglich ist es völlig sinnfrei vNICs auf den VMs zu aggregieren, das meintest du vermutlich und hättest damit Recht.
Member: Th0mKa
Th0mKa Sep 23, 2015 at 18:12:56 (UTC)
Goto Top
Zitat von @108012:

Ich hätte aber noch zwei Fragen dazu.

1.- Wenn man nun eine Intel Quad Port Server NIC nimmt und ein an einem
verwalteten Switch ein LAG (LACP) damit bildet und dann erst einen vSwitch
auf dem Hypervisor anlegt und diesem vSwitch dann an 4 vPorts 4 VMs zuweist
und auf der anderen Seite nur diesen "einen Adapter" mit einer IP Adresse, sollte
das doch auch funktionieren oder etwa nicht?

Ja, das funktioniert. Aber normalerweise haben die NICs auf ESXi Seite keine IP, die wird ja erst in der VM vergeben.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&am ...


2.- Wenn man 4 Intel Quad Port Server NICs im Server eingebaut hat und auch wieder ein
LAG anlegt was eventuell statisch ist und via Round Robin die Verteilung vornehmen soll.
Und dann lege ich 4 vSwitches intern an und weise dann je einem vSwitch eine Karte zu
bzw. ein Interface zu und auf der anderen Seite lege ich dann also 4 vSwitche an und
weise dann jeder VM einen eigenen vSwitch zu, sollte das nicht auch funktionieren?

Ja, wenn ich dich richtig verstanden habe sollte das auch funktionieren, ob das so ueberhaupt sinnvoll ist steht nochnmal auf einem anderen Blatt. Allerdings sollte man bei diesem Bandbreitenbedarf doch ueber 10G nachdenken, das haette dann noch andere Vorteile.

VG,

Thomas
Mitglied: 108012
108012 Sep 23, 2015 at 18:51:55 (UTC)
Goto Top
alles klar danke @aqui und danke Thomas, es war ja auch nur des Verständnisses halber
die Frage ob sich das überhaupt so realisieren ist.

Gruß
Dobby
Member: killtec
killtec Sep 24, 2015 at 06:55:27 (UTC)
Goto Top
HI,
also Zusammengefasst kann man sagen, dass ein LCAP / Aggregation besser ist, das aber dann jedoch nur mit "geraden" Nic Zahlen, also 2,4, usw.

Danke für eure zahlreichen Infos und die super Diskussion face-smile

Gruß
Member: aqui
aqui Sep 24, 2015 updated at 07:15:14 (UTC)
Goto Top
M.E. ist das abhängig von der Anzahl der VMs und vorhandenen physischen NICs. Geht das auf, dann bringt vermutlich eine Link Aggregation nicht viel, denn so kann man ja jeder VM dediziert eine NIC zuweisen.
Die Aggregation macht dann Sinn wenn es mehr VMs als physische NICs gibt und verbessert sich im Nutzen und Sinnhaftigkeit immer mehr je größer das Delta zwischen VMs und physischen NICs wird oder ist.

Kollege tkr104 hat aber letztlich recht, denn durch das Hashing hat man bei der Aggregation immer einen Nachteil das die Homogenität der Auslastung paralleler Links anbetrifft. Letztlich ist die "Fat Pipe" dort immer besser und vorteilhafter.
Für den der kein 10G zur Verfügung hat und nur multiple 1G ist dann aber Link Aggreagtion immer noch die beste Lösung.
Danke für eure zahlreichen Infos und die super Diskussion
Dem schliess ich mich an ! Bringt eben was wenn man von jedem Fachgebiet gute Inputs bekommt !