Heißt das im Klartext ich müsste um iSCSI nach VMWare Denke korrekt zu betreiben mehrere VMKernel Ports für iSCSI erstellen mit jeweils unterschiedlichen IPs und jeweils an nur eine NIC gebunden?
Was bringt mir das gegenüber der alten Variante mit nur einem VMKernel Port mit mehreren zugewiesenen aktiven NICs für Vorteile?
Ja es scheint so, das VMware will, das man dort mit mehreren IPs arbeitet. Aber das hat wohl auch triviale Gründe, so bekommst du nämlich die Limitierung auf Ethernet Ebene schön umschifft. Wenn jeder Host mit zwei IPs von zwei Kernel Ports arbeitet, so hast du zumindest Switchseitig am Host erstmal kein Problem das ganze zu Bündeln. Der ESXi scheint wenn ich das richtig sehe beide Kernelports zu nutzen.
Was der Host nämlich selbst nicht kann, er spricht bei mehreren zugewiesenen NICs pro Portgruppe bzw. pro Kernelport immer nur mit einer NIC. Es gibt zwar ne Redundanz, wenn ein Link wegfällt, springt ein anderer ein, aber du bekommst kein Load Balancing auf der Ebene hin -> dafür müssen deine Switches die Kanäle bündeln können. Je nach Switch und Modell ist das aber gewissen Limitierungen in der Anzahl unterlegen
Simple Accessswitches können oft nur 4-8 dieser "Teams" bilden. Was halt sehr sehr wenig ist, wenn man da mit mehreren Hosts kommt. Zumindest für iSCSI unterbindest du den Spaß nämlich damit ziemlich simpel, indem einfach über mehrere IPs gesprochen wird. Das Storage sollte das ganze dann natürlich ebenso irgendwie können. -> je nachdem, was man dort verbaut hat.
Und das dürfte dann auch schon der Unterschied zur alten Lösung sein. AKtuell kannst du, soweit ich das bis jetzt im Einsatz hatte eben nur immer eine physische NIC angehangen im Kernelport für iSCSI nutzen. Für eine zweite NIC benötigt es dann einen zweiten Kernelport. Beide müssen dann im iSCSI Menü gekoppelt werden. Früher gingen wenn ich das recht in Erinnerung habe ein Kernelport auch mit mehreren NICs -> aber eben der Limitierung auf den Speed von einem Link, wenn man Switchseitig dort keine Teams bilden konnte.
Danke
Heißt das, dass es früher(ESXi3/4??) so war, das eine VM max soviele
Cores per Socket haben konnte wie der Host und nun kann ich alle Cores aller Sockets (des Hosts) auf beliebig viele vSockets im GuestOS verteilen?
Nein
Es gab wenn man so will eine derartige Einschränkung im Grunde nicht... Was es aber gab, je nach Version und Lizenz waren gewisse Limitierungen in der Anzahl der vCPUs gegeben. So konnte beispielsweise die ESXi 4.1er Version als Hypervisor mit freiem Key nur vier vCPUs pro VM. Egal ob da nun zwei Cores + SMT, vier Cores oder weit mehr wie vier Cores (+ SMT) drin steckten. Pro VM war das Limit bei vier und nicht mehr. Die nächst höhere Standard Edition konnte meine ich dann acht. Was aber definitiv Versionsunabhängig beschränkt war, man konnte nie mehr vCPUs (oder vCores) einer einzigen VM zuweisen, als physisch in Summe vorhanden waren. Sprich du kannst nicht acht vCPUs zuweisen, wenn nur ein Quadcore ohne SMT im Host tuckert.
Was noch zu erwähnen wäre, erst seit dem 4.1er bekommt man offiziell in der GUI die Möglichkeit überhaupt auf vCore Ebene da rumzustellen. Bis 3.5 gab es glaube ich nur vCPUs (keine Möglichkeit auf die Cores zu gehen). In der 4.0 ging es via händischem Editieren der VMX Files. Das vorhandene Limit auf die vCPUs bleibt aber bestehen. Im Hypervisor 4.1 ist es egal ob du 4x vCPU oder 1x vCPU zu 4x Cores zuweist, mehr ist nicht...
Was die Speedunterschiede angeht, es gibt Leistungsunterschiede zwischen vCPUs und vCores. Unabhängig der Anzahl. Man sollte tunlichst vermeiden mehr vCPUs einer VM zuzuordnen, wie man physische CPUs im Host stecken hat, einfach weil es ein wenig Performance kostet. Auch sollte man vermeiden mehr vCores einer VM zu geben, als eine physische CPU bereit stellen kann, die im Host steckt. Macht man das, bedeutet es gleichsam, das der Host in die NUMA Node Problematik gezwungen wird, nämlich das die Berechnungen auf mehrere physische CPUs verteilt werden. Cachezugriffe gehen dann über den im Vergleich extrem lahmen "Bus".
Was die vCPUs generell angeht, hier ist weniger oftmals einfach mehr. Zu viele virtuelle CPUs bzw. Cores zugewiesen kann sich schnell negativ auswirken. Da die VMs bei erzeugender Last vereinfacht gesagt warten, bis die physischen Einheiten frei sind. Ne VM mit einer vCPU und nur einen vCore muss weit weniger lange warten, bis die Ressourcen mal "frei" sind, als wenn viele VMs jeweils immer die ganze CPU zugewiesen bekommen haben. Der Grund liegt hier eher am Gastbetriebssystem als am Host selbst. Hintergrundanwendungen verlangen immer mal wieder (wenn auch wenig) Rechenzeit von der CPU. VMs, die gänzlich schlafen, hat es im Grunde eher selten bis nie. Um so mehr hier gewartet werden muss, desto mehr Performance lässt man liegen, obwohl die VMs im Grunde die ihr zugewiesenen vCPUs gar nicht voll auslasten