ESX / ESXi - Hilfethread

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@therealJMC
Okay, dann will ich dem mal eine Chance geben. Danke für die Beratung :)

@all
Wie kann man eigentlich beim ESXi die .vmdk Dateien sichern bzw. wie sichert ihr eure VMs?

Grüße

Mit VDR... Bzw. mit VDP. Letzteres benötigt aber zwingend ein vCenter...
VCB würde ich persönlich nicht mehr nutzen, wenn es Alternativen gibt, einfach weil es A) nicht dedublizieren kann, und B) weil es nicht in die VM rein sehen kann und somit die vmdk Files nicht geshrinkt werden können. -> Es benötigt also extrem viel Platz. Unter Umständen genau so viel wie die Quell VM. Dazu kommt C) keine Versionierung ;)
 
A) Das ist richtig
B) Also meine Backups sind nicht so groß wie die Quelle. 2GBsparse gibts zwar nicht mehr, nutzt man aber z.B. NFS sind die Backups auch Thin Provisioned möglich
C) Wie meinst du? Ghettovcb hat seit Jahren schon die Möglichkeit vorzugeben wieviele Backups vorbehalten werden sollen und löscht dann (nach! erfolgreichem Backup) die alten

;)
 
Erstell dir mal ne vmdk mit beispielsweise 100GB. Deinem Gast OS bindest du den Spaß dann ein, und danach machst du nen VCB Abzug. -> das Backup der 100GB vmdk ist wenige MB groß.
Dann füllst du diese vmdk mal Randvoll mit Daten (egal was), löscht diese danach wieder und machst nochmals einen VCB Abzug -> das Backup der 100GB vmdk ist ~100GB groß ;) Und das obwohl in der vmdk keine Daten drin liegen!!

Thema Versionierung, ja Möglichkeiten einfach mehrere Stände im ganzen aufzuheben gibt es sicher. GhettoVCB ist ja im Grunde nur ein "Aufsatz" auf das orginale VCB seitens VMware... Das Problem ist, du hast sagen wir 7 Tagenstände von einer Woche und diese belegen auch 7x ihren Platz. Nutzt du nun beispielsweise VDR oder VDP werden A) nur die geänderten Daten selbst gebackupt, sprich man macht somit jeweils ne inkr. bzw. diff. Sicherung zum letzten Stand und B) wird dazu noch der Spaß dedubliziert im Zielstorage. (ohne Zutun des NAS) VCB sichert immer Voll und ich meine mit VCB kann man das nicht verdrehen. Wobei es bei Windows VMs da wohl ne Möglichkeit gibt in Richtung inkrementelle Sicherung. Aber nicht bei Linux/Unix ;)
 
Mein Gott danke fdsonne: Mit der Rechten Maustaste auf eine der iSCSI Disk unter Speicheradapter\Geräte klicken, dann kann man die Pfadverwaltung aufrufen.

Für uns ist das Richtige "Zuletzt verwendet", dann bleibt es nach einem Failover auf dem neuen Pfad und erst wenn dieser ausfällt schwenkt er wieder auf den anderen Pfad um.

Bei "Fest" würde er sobald der feste Pfad wieder verfügbar ist auf diesen umschwenken, das würde sich z.B. bei einer 10Gbit(fest) 1Gbit(Backup) Konfiguration anbieten.

Funktionieren tut das Ganze ganz gut, wir hatten zwar noch nie den Fall, dass es im laufenden Realbetrieb umschwenken musste aber ich weiss, das es funktioniert.
Beim Updaten der Flare Software des EMC-SANs wird immer ein SP nach dem anderen geupdated und dabei kommt es immer zu einem Failover, die VMs bekommen davon fast nichts mit.
Kommt aber auch auf die laufenden Dienste und Prozesse an, wenn die Toleranzen sehr gering sind kann es dort kurz zu einem Timeout kommen.
 
Zuletzt bearbeitet:
@fdsonne:
Das ist richtig - wobei das bei mir sowohl privat als auch im Büro keine große Rolle spielt, da - bis auf wenige Ausnahmen - nur die Betriebssysteme (mit recht wenig Footprint) als vmdk vorliegen. Der Rest ist RDM. Und unter Windows haben wir im vorherigen Job (ohne RDM) vor dem wöchentlichen Backup getriggert ein Clean der vmdk laufen lassen, ich hab mich gerade schon fast dusselig gesucht nach dem Link (war kein vmware binary afair) weil es ja mit den vmware Tools nicht geht. Das Teil hat das aber angetriggert und eigentlich auch zuverlässig gemacht.

Thema Versionierung: Klar, Dedup gibts halt nicht - das ist schon richtig. Wobei wir aber auch nur einmal in der Woche ne Sicherung der VMs fahren, das tägliche Backup wird über Retrospect gemacht. Die Sicherung der VMs dient nur dazu im Fall der Fälle (was eher richtung Disaster geht...) schnell die Maschine im Groben wieder laufenzuhaben (sprich mit der richtigen Config ohne mit Retrospect da erst von zu booten etc...) und sich nen Stand zum testen in die Workstation zu ziehen um da Upgrades o.ä. zu testen. Als einzige tägliche Datensicherung ist VCB imho sehr nutzlos, da geb ich dir recht. Wobei ich mir VDP letztes Jahr (oder eher vorletztes Jahr?) angeguckt hab und auf Anhieb nicht so wirklich davon begeistert war. Übrigens weiterer Nachteil von ghettovcb im Cluster Betrieb: Out-of-the-Box gibts keine Möglichkeit zu sagen "sicher mir alles was hier läuft" - mit ein bisschen gescripte gehts, bin momentan (um den weniger Erfahrenen Kollegen entgegenzukommen) auf MKSBackup als "Trigger" für Ghettovcb umgestiegen - auch ganz nett.
 
Beim VDP weis ich es nicht genau, aber VDR lässt zumindest bequem Sicherungsaufgaben eintakten und dort kannst du sagen, Host komplett. Sprich alles was geht...

Macht in der Praxis aber weniger Sinn. ;) Weil einfach VDR leider gewisse Größenbeschränkungen hat. 2x1TB Backupziele sind das max. pro Appliance. Mehr geht zwar, aber ab 1TB gehts massivst mit der Performance in den Keller. Was wohl durch die Dedublizierung zu einem Großteil her kommt.


Was halt bei uns in der Umgebung zum Problem bei VCB geworden ist, wir fahren ca. 50:50 mit Linux:Windows Gast VMs. Und dazu sind es aktuell grob 200 VMs. Beim VCB Backup muss halt immer gerade bei den Linuxen eben ein Vollbackup gezogen werden. Bei mehreren TB reinen Daten ist es nun so, das eben die Datenmenge zu groß wird um ein Backup wärend eines 12h Zeitfensters zu tätigen.
Bevor wir auf VDR umgestiegen sind, liefen die Backups via VCB. Und da waren täglich ~18-20h Sicherungszeit sowie 5 Tage die Woche durchgängig Daten am Schreiben :fresse: Und es lief so langsam an die Kapazitätsgrenzen, was die Performance angelangte. Der Umstieg auf VDR hat da deutlichst Besserung gebracht. Vor allem der reine Platzbedarf ist deutlichst geschrumpft.



PS: was mir gerade aufgefallen ist, ggf. wäre es für euch @all interessant.
Es geht nun schon mit der Standard Lizenz für 5.1 ESXi Storage vMotion ;)
Beim 5.0er Host war dies definitiv noch ein Enterprise only Feature. Und beim 4.xer ebenso...
 
Mit VDR... Bzw. mit VDP. Letzteres benötigt aber zwingend ein vCenter...
VCB würde ich persönlich nicht mehr nutzen, wenn es Alternativen gibt, einfach weil es A) nicht dedublizieren kann, und B) weil es nicht in die VM rein sehen kann und somit die vmdk Files nicht geshrinkt werden können. -> Es benötigt also extrem viel Platz. Unter Umständen genau so viel wie die Quell VM. Dazu kommt C) keine Versionierung ;)

Danke.
Und wie empfiehlst du dann die VMs zu sichern? Gibts da ne gute kostenlose Variante!?

Grüße
 
Neja das größte Problem ist, das VDR eigentlich "nur" lizensiert ist, wenn man ne ESXi Lizenz hat ;)
Laufen tut es aber auch mit der Kostenfreien Lizenz...

Aber das ist bei VCB im Grunde ebenso ;)
 
Ich hab mal zwei ESXi Laienfragen.

Am MB gibt es 2 Gigabit Netzwerkkarten, ferner steckt noch eine 4-fach Gigabit Karte drinne.

In vSphere hab ich die Karten so aufgeteilt:
Anhang anzeigen 220813

Jetzt möchte ich an vSwitch1 das ESXi Management zusätzlich als standby, falls die onboard-nics ausfallen, hinzufügen.
Ist das möglich und wie füge ich das Management zu?

Der Server hängt an einem LevelOne GSW-2476 dran, welcher Trunking kann.
Ich möchte vmnic4 und 5 bündeln, um den Durchsatz zu steigern.
Genügt es, wenn ich beim vSwitch0/Nic-Gruppierung /Lastausgleich auf "Anhand des IP-Hashes routen" umstelle?
Oder muss ich noch was beachten/umstellen?
Anhang anzeigen 220816
Klar ist, dass ich am LevelOne diese zwei Ports zu einem Trunk verbinden muss.
Anhang anzeigen 220817

@layerbreak
das kannst du dir sparen... Wenn du die OnBoard NICs ausschließen willst, nutz doch einfach für den vSwitch1 eine der beiden OnBoard NICs und gib stattdessen dem vSwitch0 eine NIC der Zusteckkarten...
Somit hast du dort eine Redundanz. Switchseitig musst du dort auch gar nix konfigurieren... Das lüppt auch ohne. ;)

Danke @fdsonne.
Eigentlich will ich nicht die Onboard Nics ausschliessen, sondern die ManagementConsole redundant haben - falls mal die beiden OnBoard Nics ausfallen. Und da vSwitch1 auch ins lokale Netz zeigt, dachte ich, dass es sich so anbietet.

Was mir aber viel wichtiger ist, ist meine zweite Frage, ob ich so wie ich es beschrieben habe, die Nic-DurchsatzLeistung verdoppeln kann?
 
Für was willst du die Management Console doppeln? Das ist nur ein Stück Software... Wichtig ist eher, das du die NICs doppelst um eben eine Redundanz zu haben. Ob das hingegen Sinn macht, wenn man alles an einem einzigen Switch klemmt, ist zwar fraglich, aber sei es drum.

Ansonsten, es ist fast egal, was du dort beim Lastenausgleich einträgst, hat der ESXi mehrere physische NICs am vSwitch, so kann er auch mehrere NICs nutzen, und tut dies auch...
Du kannst aber an der Stelle einfach mal rumspielen. Im Grunde müsste die default Einstellung aber ausreichend sein.

Wichtig ist zu wissen, per default bekommen VMkernel Ports den Haken gesetzt, die vSwitch Settings zu überschreiben und definieren dort eigene Werte. Das solltest du anpassen...

PS: was du auch machen kannst, du packst alle 6 NICs direkt an einen vSwitch und legst alle Portgruppen für VMs in diesem Switch an. Um eine Trennung zu wahren für die verschiedenen Netze arbeitest du einfach mit VLANs an den 6 Switchports sowie an den Portgruppen für VMs (auch für die VMkernel Port(s))
Somit hast du im maximalen 6x1GBit bereit und keine Beschränkungen mehr.
 
Ich glaub er dachte an direktes Nic-Teaming/Trunking im "klassichen" Sinne wie es bei Physikalischen Servern üblich ist (meldet sich dann unter Windows bei Intel z.B. als seperate NIC) - darum die Frage nach der Konfiguration am Switch ;)
 
Ich hab mal zwei ESXi Laienfragen.

Am MB gibt es 2 Gigabit Netzwerkkarten, ferner steckt noch eine 4-fach Gigabit Karte drinne.

In vSphere hab ich die Karten so aufgeteilt:
Anhang anzeigen 220813

Jetzt möchte ich an vSwitch1 das ESXi Management zusätzlich als standby, falls die onboard-nics ausfallen, hinzufügen.
Ist das möglich und wie füge ich das Management zu?

Der Server hängt an einem LevelOne GSW-2476 dran, welcher Trunking kann.
Ich möchte vmnic4 und 5 bündeln, um den Durchsatz zu steigern.
Genügt es, wenn ich beim vSwitch0/Nic-Gruppierung /Lastausgleich auf "Anhand des IP-Hashes routen" umstelle?
Oder muss ich noch was beachten/umstellen?
Anhang anzeigen 220816
Klar ist, dass ich am LevelOne diese zwei Ports zu einem Trunk verbinden muss.
Anhang anzeigen 220817

@layerbreak
das kannst du dir sparen... Wenn du die OnBoard NICs ausschließen willst, nutz doch einfach für den vSwitch1 eine der beiden OnBoard NICs und gib stattdessen dem vSwitch0 eine NIC der Zusteckkarten...
Somit hast du dort eine Redundanz. Switchseitig musst du dort auch gar nix konfigurieren... Das lüppt auch ohne. ;)

Für was willst du die Management Console doppeln? Das ist nur ein Stück Software... Wichtig ist eher, das du die NICs doppelst um eben eine Redundanz zu haben. Ob das hingegen Sinn macht, wenn man alles an einem einzigen Switch klemmt, ist zwar fraglich, aber sei es drum.

Ok, dann vergessen wir die Redundanz der ManagementConsole.
vSwitch0 ist doch schon mit zwei Nics ausgestattet.

Ansonsten, es ist fast egal, was du dort beim Lastenausgleich einträgst, hat der ESXi mehrere physische NICs am vSwitch, so kann er auch mehrere NICs nutzen, und tut dies auch...
Du kannst aber an der Stelle einfach mal rumspielen. Im Grunde müsste die default Einstellung aber ausreichend sein.

Wichtig ist zu wissen, per default bekommen VMkernel Ports den Haken gesetzt, die vSwitch Settings zu überschreiben und definieren dort eigene Werte. Das solltest du anpassen...

PS: was du auch machen kannst, du packst alle 6 NICs direkt an einen vSwitch und legst alle Portgruppen für VMs in diesem Switch an. Um eine Trennung zu wahren für die verschiedenen Netze arbeitest du einfach mit VLANs an den 6 Switchports sowie an den Portgruppen für VMs (auch für die VMkernel Port(s))
Somit hast du im maximalen 6x1GBit bereit und keine Beschränkungen mehr.

Nene, die zusätzliche nic-Karte ist nur für UTM (früher astaro) drinne. Um grössst mögliche Sicherheit zu haben, habe ich die Konfiguration so gewählt.
Auch noch mit VLAN rumspielen, lieber nicht. Ferner habe ich hier manche PCs, die gar nicht die Möglichkeit haben VLAN zu konfigurieren.

Ich glaub er dachte an direktes Nic-Teaming/Trunking im "klassichen" Sinne wie es bei Physikalischen Servern üblich ist (meldet sich dann unter Windows bei Intel z.B. als seperate NIC) - darum die Frage nach der Konfiguration am Switch ;)

Yep, genau so war es gemeint.

Die VM Ripley ist mit einer vmxnet3 ausgestattet. Also ist IMHO die realen Nics der Flaschenhals beim Durchsatz.
Ich möchte jetzt, dass mehrere PCs auf diese VM zugreifen können, ohne dass es zu Rucklern kommt.
Ferner ist meine Maschine mit einem Intel ET DualPort ausgestattet, Diese habe ich zu einer Gruppe zusammen gefasst, da diese Maschine hauptsächlich die VM füllt.
Im nächsten Schritt baue ich mir einen zweiten Server auf, der als Backup Maschine dienen soll. Damit das Backup schneller abläuft und abgeschlossen wird hätte ich gerne die Verdoppelung.

Mehr als Gigabit-Verdoppelung geht nicht, da der LevelOne Dies max kann. Wenn ich mehr haben will, brauche ich andere Hardware.
 
Ich glaub er dachte an direktes Nic-Teaming/Trunking im "klassichen" Sinne wie es bei Physikalischen Servern üblich ist (meldet sich dann unter Windows bei Intel z.B. als seperate NIC) - darum die Frage nach der Konfiguration am Switch ;)

Nur ist es eben nicht nötig... Es geht auch ohne... Vorteil, wenn der Switch das nicht kann ;)

Ok, dann vergessen wir die Redundanz der ManagementConsole.
vSwitch0 ist doch schon mit zwei Nics ausgestattet.
Wie gesagt, bestenfalls noch anstatt der beiden NICs der OnBoard Lösung eine von OnBoard und eine von ner Steckkarte zusammen nutzen. Das umgeht den Umstand eines möglichen Ausfallens des OnBoard Controllers und somit vollständige nichterreichbarkeit des ESX Servers. Das kannst dir aber auch sparen, wenn die beiden OnBoard NICs schon über zwei Controller angebunden sind ;) -> je nach Board muss das aber nicht so sein.

Nene, die zusätzliche nic-Karte ist nur für UTM (früher astaro) drinne. Um grössst mögliche Sicherheit zu haben, habe ich die Konfiguration so gewählt.
Auch noch mit VLAN rumspielen, lieber nicht. Ferner habe ich hier manche PCs, die gar nicht die Möglichkeit haben VLAN zu konfigurieren.
Du solltest dich denke ich mal etwas mit Netzwerktechnik beschäftigen ;)
Du brauchst schlicht keine Funktionen an den PCs. Da du einfach die Ports der PCs wie du es jetzt auch schon machst einfach untagged in das jeweilige VLAN packst. Außer beim ESX Server werden die VLANs tagget auf dessen Uplink Ports gelegt um die Trennung zu wahren.

Die VM Ripley ist mit einer vmxnet3 ausgestattet. Also ist IMHO die realen Nics der Flaschenhals beim Durchsatz.
Ich möchte jetzt, dass mehrere PCs auf diese VM zugreifen können, ohne dass es zu Rucklern kommt.
Ferner ist meine Maschine mit einem Intel ET DualPort ausgestattet, Diese habe ich zu einer Gruppe zusammen gefasst, da diese Maschine hauptsächlich die VM füllt.
Im nächsten Schritt baue ich mir einen zweiten Server auf, der als Backup Maschine dienen soll. Damit das Backup schneller abläuft und abgeschlossen wird hätte ich gerne die Verdoppelung.

Mehr als Gigabit-Verdoppelung geht nicht, da der LevelOne Dies max kann. Wenn ich mehr haben will, brauche ich andere Hardware.

Auch hier musst du dich Informieren ;)
Ein Teaming auf beiden Seiten (sprich dein PC sowie der Server) benötigt immernoch zwei gleichzeitige Connections mindestens um mehr wie 1GBit/s Speed zu bekommen.
Ferner solltest du auch auf jedenfall prüfen, ob überhaupt 1GBit ein Flaschenhals sind...
Eine Verdopplung im normalen Single Client zu Host Betrieb wirst du zu 99% nicht erreichen.

Und wie ich oben schon sagte, der ESX nutzt auch so schon alle NICs, die ihm im jeweiligen vSwitch zugewiesen sind. Wenn also die Clients dort in Summe mehr wie 1GBit/s Traffic erzeugen, lagert der ESXi das auf mehrere NICs um. Auch ohne dedizierte Switch Konfig und Teaming/Trunking/LACP ;)
 
@fdsonne, danke dass du mir antwortest.

Aber das ist das Problem von solchen Hobby-Admins wie mir. Wir können alles und können doch nichts. :heul: und das stört die spezialisierten Fachleute.
Es ist sicherlich gut gemeint von dir, wenn du mir schreibst
Nur ist es eben nicht nötig... Es geht auch ohne... Vorteil, wenn der Switch das nicht kann ;)
Du solltest dich denke ich mal etwas mit Netzwerktechnik beschäftigen ;)
solche Antworten bekommt man in Foren wie Openindiana, Astaro, Linux usw. ständig, mein Beruf ist aber ein anderer und ich kann mir nicht alles Fachwissen aneignen - mir fehlt aber auch die nötige Zeit hierzu.
Ich hab einen Freund, der arbeitet bei einem DAX Unternehmen als Admin, also dachte ich mir mal früher, super dann kannst ja Paul mal zu einem Problem fragen, der weis dann das ganz sicher. Immer bekam ich zur Antwort "keine Ahnung kenn ich mich nicht aus, musst du dich selber einlesen", ich kann dir aber immer weiterhelfen, wenn du weltweit in ein SAP-System einen Drucker einbinden willst. Da kenn ich mich richtig gut aus, aber beim Rest überhaupt nicht.

Auch hier musst du dich Informieren
Ein Teaming auf beiden Seiten (sprich dein PC sowie der Server) benötigt immernoch zwei gleichzeitige Connections mindestens um mehr wie 1GBit/s Speed zu bekommen.
Ferner solltest du auch auf jedenfall prüfen, ob überhaupt 1GBit ein Flaschenhals sind...
Eine Verdopplung im normalen Single Client zu Host Betrieb wirst du zu 99% nicht erreichen.

Und wie ich oben schon sagte, der ESX nutzt auch so schon alle NICs, die ihm im jeweiligen vSwitch zugewiesen sind. Wenn also die Clients dort in Summe mehr wie 1GBit/s Traffic erzeugen, lagert der ESXi das auf mehrere NICs um. Auch ohne dedizierte Switch Konfig und Teaming/Trunking/LACP

Dann versteh ich dich richtig, dass Teaming total unnötig ist?
 
Das müsste der neuste Download sein gibt halt schon paar Patches für 5.1
 
Kann jemand den Link zu der aktuellsten ESXi 5.1 Version posten? Bei mir ist momentan die Version 5.1.0-799733 drauf. In einem der Screenshots hier, hatte ich bereits die -914609 gesehen. Komme im Homepagedschungel von Vmware nicht zurecht.

Unter folgendem Link ist noch die erste 5.1.0 zu finden. https://my.vmware.com/de/group/vmware/evalcenter?p=free-esxi5

Wenn du meinen Screenshot meinst.
Ich nehm immer den Link hier:
VMWare Patch Download

914609 ist das Patch vom 20.12.12
 
solche Antworten bekommt man in Foren wie Openindiana, Astaro, Linux usw. ständig, mein Beruf ist aber ein anderer und ich kann mir nicht alles Fachwissen aneignen - mir fehlt aber auch die nötige Zeit hierzu.
Ich hab einen Freund, der arbeitet bei einem DAX Unternehmen als Admin, also dachte ich mir mal früher, super dann kannst ja Paul mal zu einem Problem fragen, der weis dann das ganz sicher. Immer bekam ich zur Antwort "keine Ahnung kenn ich mich nicht aus, musst du dich selber einlesen", ich kann dir aber immer weiterhelfen, wenn du weltweit in ein SAP-System einen Drucker einbinden willst. Da kenn ich mich richtig gut aus, aber beim Rest überhaupt nicht.

Ist ja kein Ding ;) Dafür sind wir hier im Forum ;)
Das mit dem Lesen war übrigens primär auf die VLAN Konfig bezogen, weil du eben nicht die PCs konfigurieren musst, wenn du die VLANs jeweils immer untagged auf die Ports des Switches packst. Außer deben beim ESX, der ja wie angesprochen die Geschichten dann via tagging in die VLANs über alle seine Uplinks einsortiert.

PS: es "stört" übrigens auch nicht. Es ist nur immer etwas hinderlich, wenn die Leute versuchen die "Welt zu beherschen", man dann aber im Gespräch merkt, das die Basics schon etwas holprig kommen :fresse:
Deswegen nutze ich gern den Hinweis, sich dort dann etwas näher mit zu beschäftigen. Macht viele Sachen auch viel einfacher zu verstehen ;)

Thema Teaming, ja scheinbar muss das nicht mehr gemacht werden. Also unsere ESXi Server quatschen ohne dedizierte Switch Konfig über alle Adapter. Und das nicht zu knapp ;)
Nur eben mit den Settings am vSwitch des ESX Hosts definierst du noch, anhand welcher Parameter da die Verteilung erfolgt. Mit Ausnahme der vierten Option mit der festgelegten Reihenfolge muss eigentlich alles dreies eine Lastverteilung zulassen.
 
Ist ja kein Ding ;) Dafür sind wir hier im Forum ;)
Das mit dem Lesen war übrigens primär auf die VLAN Konfig bezogen, weil du eben nicht die PCs konfigurieren musst, wenn du die VLANs jeweils immer untagged auf die Ports des Switches packst. Außer deben beim ESX, der ja wie angesprochen die Geschichten dann via tagging in die VLANs über alle seine Uplinks einsortiert.

Ich finde jetzt leider den verda... Link nicht mehr. Es ging speziell um ESXi und VLAN. Kann mich noch daran erinnern, dass sich VLAN über jede einzelne Hardware konfigurieren lässt, über den Sender und Empfänger oder als drittes einer Mischung aus den ersten Beiden.
Also hatte ich mich daran versucht - bis ich auf kein Gerät mehr zugreifen konnte. Es half nur noch eine Neuinstall von ESXi und ein Factory-Reset des Switches. Dieses Chaos wollte ich jetzt gerne vermeiden.

PS: es "stört" übrigens auch nicht. Es ist nur immer etwas hinderlich, wenn die Leute versuchen die "Welt zu beherschen", man dann aber im Gespräch merkt, das die Basics schon etwas holprig kommen :fresse:
Deswegen nutze ich gern den Hinweis, sich dort dann etwas näher mit zu beschäftigen. Macht viele Sachen auch viel einfacher zu verstehen ;)

Hast ja im Grunde Recht, aber wo fangen die Basics an und wo hören sie auf?

Thema Teaming, ja scheinbar muss das nicht mehr gemacht werden. Also unsere ESXi Server quatschen ohne dedizierte Switch Konfig über alle Adapter. Und das nicht zu knapp ;)
Nur eben mit den Settings am vSwitch des ESX Hosts definierst du noch, anhand welcher Parameter da die Verteilung erfolgt. Mit Ausnahme der vierten Option mit der festgelegten Reihenfolge muss eigentlich alles dreies eine Lastverteilung zulassen.

Meinst du die einstellmöglichkeiten bei "Nic-Gruppierung/Lastausgleich"?

Ich hatte es so verstanden, dass ich mehrere Nics bündeln kann um den Durchsatz zu verdoppeln, wenn ich z.B. eine/mehrere Dateien auf die VM schaufeln will.
Also ging ich davon aus, an meiner Maschine die beiden Nics per Teaming zu koppeln, so wie @therealJMC geschrieben hatte, dem Switch mitteilen muss, dass z.B. Port1+2 (ESXi) und Port 16+17 (meinPC) zusammengehören. Zu guter letzt ESXi klar machen muss, dass vmnic4 und vmnic5 die Daten zusammen "verarbeitet".
Ich würde gerne beim Kopieren von 70-80 MiB/s auf 140-160 MiB/s kommen.
 
@therealJMC:
Und das Intel Board von dir in deiner Sig werde ich mir heute Abend auch noch mal ansehen. Wird dieses Borad komplett vom ESX unterstützt?
Hast du VT-d auch schon getestet?

hab gerade 5.1 auf einen USB-Stick am DQ77MK installiert.
Der rote LAN-Adapter wird nicht erkannt, der untere geht. Mehr kann ich noch nicht dazu sagen :d

Momentan zickt das Board rum, mag nicht vom USB-Stick booten, es sei denn ich wähl ihn übers Bootmenü.
Jetzt muss ich erstmal auf Festplatten warten, weil außer dem 9650SE und dem USB-Stick steckt noch nix im PC.
 
Ich hatte es so verstanden, dass ich mehrere Nics bündeln kann um den Durchsatz zu verdoppeln, wenn ich z.B. eine/mehrere Dateien auf die VM schaufeln will.
Also ging ich davon aus, an meiner Maschine die beiden Nics per Teaming zu koppeln, so wie @therealJMC geschrieben hatte, dem Switch mitteilen muss, dass z.B. Port1+2 (ESXi) und Port 16+17 (meinPC) zusammengehören. Zu guter letzt ESXi klar machen muss, dass vmnic4 und vmnic5 die Daten zusammen "verarbeitet".
Ich würde gerne beim Kopieren von 70-80 MiB/s auf 140-160 MiB/s kommen.
Wenn Du von einer Maschine einen Kopiervorgang anschmeißt, wird sich da null komma gar nix ändern. Teaming bringt nur etwas bei mehreren gleichzeitigen Datentransfers, aber nicht bei einem einzigen.

Außerdem ist mit 70-80 MB/s ja noch nicht mal eine 1 Gbit/s-Leitung ausgelastet, wie TCM schon geschrieben hat, real kommen über Gigabit maximal 110 MB/s. Somit limitiert da entweder die Quelle oder das Ziel, aber nicht das Netzwerk.
 
Ich finde jetzt leider den verda... Link nicht mehr. Es ging speziell um ESXi und VLAN. Kann mich noch daran erinnern, dass sich VLAN über jede einzelne Hardware konfigurieren lässt, über den Sender und Empfänger oder als drittes einer Mischung aus den ersten Beiden.
Also hatte ich mich daran versucht - bis ich auf kein Gerät mehr zugreifen konnte. Es half nur noch eine Neuinstall von ESXi und ein Factory-Reset des Switches. Dieses Chaos wollte ich jetzt gerne vermeiden.

Dann war an der Konfig grundsätzlich was falsch... Und wenn du dazu den ESX neu installieren musst (wie auch immer man den so zersägen kann :fresse:) muss es gar richtig fatal falsch gewesen sein.
Im Grunde ist es aber ganz einfach. Du musst dir das so vorstellen. Du hast ne Haustür, da steht ne Nummer drüber... Per default hat ein 24 Port Switch beispielsweise also 24 Haustüren. Jede trägt dabei die Nummer 1 (also VLAN 1)
Das bedeutet soviel wie, egal durch welche Tür du gehst, also welchen Port du nutzt, du landest immer im Netz 1 (VLAN 1)

Nun gehst du einher und sagst beispielsweise, Haustür 1 (Port 1 am Switch) bekommt anstatt Nummer 1 (VLAN 1) nun die Nummer 10 (VLAN 10). Gehst du nun durch die Haustür, befindest du dich aber im Netz 10 und kannst somit nicht mit dem Netz 1 aus den anderen Ports/Türen kommunizieren. Zumindest nicht direkt.
Das umkonfigurieren des Ports beschreibt dabei aber immer das untagget Verhalten. Sprich jeglicher Traffic, der nicht markiert ist (sprich getagget ist), landet automatisch in dem VLAN, wo der Port drin ist.

Nun besteht noch die Möglichkeit einen Port zu taggen. Heist soviel wie, du hast immernoch den Port/den Türrahmen, aber es gibt nun in diesem Türrahmen mehrere Klappen mit jeweils anderen Nummern. Nun klemmst den ESX dann an diesen Port und sagst ihm, das eine Portgruppe für VMs mit der VLAN ID 10 getagget wird, und beispielsweise eine weitere mit der VLAN ID 100, sowie eine dritte beispielsweise wird ohne tag durch die NIC gelassen.
Der Switch macht nun folgendes. Der untagged Traffic der dritten Portgruppe läuft in das VLAN, was das default VLAN des Ports (untagged) ist. IdR die 1, wenn nicht umkonfiguriert.
Der tagged Traffic von VLAN 10 läuft dabei durch die selbe Tür, geht aber in die Klappe mit Nummer 10, der Traffic von VLAN 100 geht dabei in die Klappe mit Nummer 100.

Somit trennst du grundsätzlich physikalisch die Netze. VLANs auf einem Switch verhalten sich wie physisch getrennte Switchtechnik, nur das es eben alles auf einem Stück Hardware läuft.

Mit VLANs zu arbeiten macht beispielsweise dann Sinn, wenn du mehr als einen Port am Host benötigst um direkt dort Gerätschaften anzuklemmen. Sprich sagen wir du baust ne DMZ und willst dort zwei Gerätschaften anstecken. Wie eben beispielsweise nen Router sowie eine weitere physische Servermaschine. Somit wäre zur Verbindung dessen mit dem Host direkt ein kleiner 5 Port Switch notwendig. Mit VLANs kannst du drei Ports eines vorhandenen Switch nehmen und trennst dennoch sauber zwischen DMZ LAN und dem Rest...



Ich hatte es so verstanden, dass ich mehrere Nics bündeln kann um den Durchsatz zu verdoppeln, wenn ich z.B. eine/mehrere Dateien auf die VM schaufeln will.
Also ging ich davon aus, an meiner Maschine die beiden Nics per Teaming zu koppeln, so wie @therealJMC geschrieben hatte, dem Switch mitteilen muss, dass z.B. Port1+2 (ESXi) und Port 16+17 (meinPC) zusammengehören. Zu guter letzt ESXi klar machen muss, dass vmnic4 und vmnic5 die Daten zusammen "verarbeitet".
Ich würde gerne beim Kopieren von 70-80 MiB/s auf 140-160 MiB/s kommen.

Wie gesagt, das ist so ne Sache. Du benötigst so oder so zwei gleichzeitige Transfers um 2x1GBit LACP auch nur im Ansatz auszufahren. Von einem einzigen Host zu einem einzigen Client bzw. umgekehrt besteht auch weiterhin diese Limitierung.
Was mich aber wundert. Wenn du heute 70-80MB/sec hast, hast du wohl ein ganz anderes Problem ;) 1GBit LAN geht bis theoretisch 125MB/sec. Und praktisch bei guter Hardware habe ich schon 115-120MB/sec gesehen...
 
Zuletzt bearbeitet:
hab gerade 5.1 auf einen USB-Stick am DQ77MK installiert.
Der rote LAN-Adapter wird nicht erkannt, der untere geht. Mehr kann ich noch nicht dazu sagen :d

Momentan zickt das Board rum, mag nicht vom USB-Stick booten, es sei denn ich wähl ihn übers Bootmenü.
Jetzt muss ich erstmal auf Festplatten warten, weil außer dem 9650SE und dem USB-Stick steckt noch nix im PC.

Aktuellstes BIOS drauf? Hab mit USB Boot auf 2 Kisten im Büro kein Problem...

Das mit der 2. NIC (die auch für rKVM benutzt wird) hab ich ja vermutet, den Treiber kann man aber afair nachrüsten oder vorher ins ISO basteln glaub ich
 
Dann war an der Konfig grundsätzlich was falsch... Und wenn du dazu den ESX neu installieren musst (wie auch immer man den so zersägen kann :fresse:) muss es gar richtig fatal falsch gewesen sein.
[snip]

Richtig, war es. Ich bin nicht mehr auf die ManagementConsole gekommen.
Das Prinzip von VLAN hab ich jetzt so im Groben verstanden. Danke für die Erklärung.

Wie gesagt, das ist so ne Sache. Du benötigst so oder so zwei gleichzeitige Transfers um 2x1GBit LACP auch nur im Ansatz auszufahren. Von einem einzigen Host zu einem einzigen Client bzw. umgekehrt besteht auch weiterhin diese Limitierung.
Was mich aber wundert. Wenn du heute 70-80MB/sec hast, hast du wohl ein ganz anderes Problem ;) 1GBit LAN geht bis theoretisch 125MB/sec. Und praktisch bei guter Hardware habe ich schon 115-120MB/sec gesehen...

Ich geh jetzt mal davon aus, dass Server-seitig kein Problem besteht.
An meiner Kiste bremst vermutlich die HD das Ganze aus, denn wenn ich zwei verschiedene Kopiervorgänge auf zwei verschiedenen HDs anstoße komme ich bei dem 1. auf 55,4 MiB/s und beim 2. auf 63,4 MiB/s - gibt in Summe 118,8 MiB/s.
Wobei beim 1. lauter kleinere Dateien (4-8GB) sind und beim 2. eine Grosse mit 24 GB.

Ich frag jetzt nochmals doof.
Du schreibst oben LACP.
Bei meinem LevelOne kann ich Trunks einstellen "This page enables you to configure trunks on the Switch."
Aber auch LACP "This page enables you to configure LACP on all or some ports. LACP (IEEE 802.3ad Link Aggregation Protocol) provides a way to set up aggregation automatically between switches."
Dort kann ich Ports auswählen und denen einen KeyValue "(0..255, 0 means autogenerated key)" vergeben.
Muss ich anstatt Trunks dann LACP nehmen?

Langsam wirds mir peinlich - mein fehlendes Wissen. :wall:
 
Das Problem mit den Begrifflichkeiten ist, die Hersteller verwenden unterschiedliche Bezeichnungen.

LACP ist im Grunde das was du suchst... Sozusagen eine Portbündlung. Nur kann es passieren, das andere Hersteller es anders schimpfen :(
Ist etwas undurchsichtig das ganze...
Link Aggregation
Scheint so, als meint dein Switch die Portbündlung mit LACP.
Trunk scheint eher in Verbindund mit VLANs zu kommen...

Für gewöhnlich definierst du eine Portgruppe am Switch und diese Portgruppe teilst du Ports zu. Das gleiche machst du dann am anderen Ende (sprich Client)


PS: noch was anderes, eventuell macht es dennoch Sinn, dem Switch zu sagen, das er die Ports für den ESX via LACP Bündeln soll. Einfach aus dem Grund. Der ESX Server macht die Lastverteilung ggf. nur über mehrere VMs hinweg. Wenn es aber alles auf ein und die selbe Ziel VM geht, was ja so sein soll, wenn ich dich richtig verstehe, greift eventuell die Lastverteilung auf ESX Ebene nicht... Es sei denn, du gibst der VM zwei vNICs und verteilst die Last über zwei Transfers auf zwei virtuelle Netzwerkkarten (zwei IPs)
Somit hättest du auch gleich zwei gleichzeitige Verbindungen...
 
Wie gesagt, das ist so ne Sache. Du benötigst so oder so zwei gleichzeitige Transfers um 2x1GBit LACP auch nur im Ansatz auszufahren. Von einem einzigen Host zu einem einzigen Client bzw. umgekehrt besteht auch weiterhin diese Limitierung.

Das stimmt so ohne weiteres aber nicht für das was er eigentlich vorhatte: Teaming/Bonding/Trunking - ich hatte auf meiner alten Workstation ne Intel Dualport geteamt und von einem Server (ebenfalls geteamt) auf ein RAID10 (mit schnellen SAS HDDs, später ein RAID1 mit SSDs) regelmäßig recht große Daten gezogen. Da war deutlich mehr als die ~125MB drin die theoretisch möglich wären über 1Gbit - es waren halt 2 gebündelte Gbit Kanäle. Das braucht also bei entsprechendem Client nicht zwangsweise auch 2 Verbindungen. Und die hätte er ja auch wenn er seinen PC mit 2 NICs ebenfalls Teamen kann. Das seine HDD limitiert ist ja was anderes ;)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh