News AMD-Epyc-Prozessoren: Alle Wege führen nach Rome

[DonL_]

@xexex
Es dürften sich doch aber mit weiterer Verbreitung, so etwas wie basic Workarounds/Einstellungen für VM und Terminalserver herausstellen, die dann nur noch individuell auf den einzelnen Kunden angepasst werden müssen oder übersehe ich da jetzt etwas?
Ich bestreite nicht, dass das im Moment sehr neu ist, aber mit fortschreitender Praxis wird doch eine gewisse Standardisierung eintreten, bezogen auf die Anwendungsfälle und wie stelle ich einen Epyc 1 Sockel mit 16,24,32 Kerne oder ein 2 Socket System mit bis zu 64 Kerne ein.

 

[Volkimann]

Bisher haben ich vor allem von mir gesprochen, der in einem Systemhaus sitzt und darüber entscheidet ob wir etwas ruhigen Gewissens verkaufen können.... Genau hier endet eigentlich die Überlegung, da ich häufig nicht mal genau weiß welche Applikationen der Kunde derzeit einsetzt und definitiv nicht wissen kann welche er in der Zukunft einsetzen wollen wird.

Also anstatt dein Gewissen zu beruhigen, indem du dir Informationen etc beschaffst, und du nicht nach den Anwendungsgebieten der Kundschaft dich erkundigst, wird einfach weiterhin stumpf Intel verkauft. Auch auf die Gefahr hin das durch Meltdown/Spectre Patches (und was da noch vielleicht in Zukunft auf Intel und deren Kunden zukommt) die Leistung entsprechend einbricht. Aber hey, kann man eben noch mehr Server zur Kompensation verkaufen.

Also "Was der Bauer nicht kennt, das frisst er nicht".

 

[modena.ch]

@YforU

Aber ich kann dem Hypervisor meine Preferencen ja mitteilen.
Dem kann ich ja auch sagen dass er z.B. nur physische Kerne verwenden soll.
Blöd gesagt schau ich mir an was an Software bei mir im Betrieb läuft.
Setze bei Latenzabhängigen bzw Node abhägingen auf ein CCX bzw DIE und den Rest lasst ich
Hypervisor default machen. So extrem viel unterschiedliche Software wird ja kaum auf demselben
Server laufen.

Er hatte ja grad das Problem der zu geringen Speicherbandbreite auf
einem Socket. Wenn ich das nicht will, muss ich voll bestücken.
Egal ob die Module dann zukünftig nicht mehr zu gebrauchen sind
oder egal ob es mehr Verbrauch ergibt. Und ich mein 16x 8 GB
Module werden heut und morgen nicht zu wenig Ram für so einen
2 Socket Server sein.

 

[xexex]

Es dürfte doch aber mit weiterer Verbreitung, so etwas wie basic Workarounds/Einstellungen für VM und Terminalserver herausstellen, die dann nur noch individuell auf en einzelnen Kunden angepasst werden müssen oder übersehe ich da jetzt etwas?

Im Grunde genommen müsste AMD zu Microsoft und VMware gehen, denen Geld oder Entwickler zuschieben und zusehen, dass deren Scheduler mit dem Aufbau der CPUs besser zurecht kommen. Der EPYC und Threadripper sind nun aber seit über einem Jahr auf dem Markt, spezielle Optimierungen oder einfache Konfigurationsoptionen sind meines Wissens bisher Mangelware.

Der zweite und fast noch wichtigere Schritt ist an die großen Softwarehersteller heranzutreten. Erst wenn in jeder beschissenen Serveranwendung explizit eine Intel oder AMD CPU empfohlen wird, ist man halbwegs fein raus. Hier ist weniger Microsoft ein Problemkind, aber schaue dir mal die unzähligen Softwarehäuser an, die selbst in 10 Jahren weder eine AMD CPU haben werden, noch Lust haben irgendwelche Tests oder Optimierungen dafür durchzuführen.

Ich habe schon Ping Pong mit Entwicklern gespielt zu jedem möglichen Thema, von OS Unterstützung über den Einsatz von SSDs bis zum Adobe Reader. Glaube mir, am Ende verkaufst du dem Kunden lieber ein Raid aus SAS HDDs statt einer PCIe SSD, nur damit du deine Ruhe hast und der Kunde die "Schuld" einzig an den Applikationssoftwareentwickler schieben kann.

Wenn dann bei so einem Anforderungsprofil steht, der Kunde braucht drei getrennte Server mit einer Xeon XY CPU, einem SAS Raid und 8 Platten im Raid 10 Verbund und du mit einem EPYC Server stehst mit 64 Kernen und einer dicken PCIe SSD, hast du das wesentlich bessere Angebot, schneidest dir aber doppelt ins eigene Fleisch. Weniger Umsatz, weniger Gewinn, eigenes Risiko wenn was nicht funktioniert, egal ob es an der Hardware liegt oder nicht.

 

[Simon]

Dein Hauptproblem hast du ja selbst erkannt: Windows
Dein anderes Problem heißt wohl: Java EE. Das ist zwar nach wie vor der einzige "offizielle" Standard im Java Server Umfeld, aber seit Jahren rücken immer mehr und mehr Firmen davon ab. Die Entwicklung geht zu langsam voran (das ändert sich jetzt hoffentlich mit Jakarta EE), Enterprise Betrieb ist zu teuer, alles zu umständlich, etc..

Das ist nicht mein Hauptproblem, sondern gelebte Realität bei einem Großteil der Systemlandschaft bei Kunden - ob mir das persönlich gefällt oder nicht interessiert da wenig. Und nicht jedes Unternehmen kann sich nun einmal erlauben, mal eben die komplette OS/Middleware/Application/Datenbank-Plattform auszutauschen wie die tägliche Unterhose.

Viele Java Software Häuser bieten nun auch großflächig Produkte auf Spring Basis an - seit ein paar Jahren sprießen im Java Umfeld aber immer mehr solche Frameworks aus dem Boden, die sich auf 1-2 Bereiche spezialisieren und dadurch dann eben extrem einfach zu handhaben und sehr performant sind. Oder man baut kunterbunte Microservices mit Node, Ruby, Python (und Java).

Ja, herzlichen Glückwunsch. Und wer gibt mir die Garantie, dass diese Sprößlinge in fünf bis zehn Jahren noch existieren und ich nicht irgendwann ins offene Messer laufe, weil ich auf ein kurzlebiges Pferd gesetzt habe? Mag ja vielleicht heute geil sein, wenn der Trend nicht mehr hip ist, steigen viele Anbieter wieder aus und der Markt konzentriert sich dann auf wenige Anbieter, die dann den Markt unter sich aufteilen und dementsprechend Preise aufrufen können, die eigentlich niemand mehr bezahlen will, aber letztlich erst einmal dazu gezwungen wird.

Ich kenne reichlich Systeme, die auf Kubernetes, OpenShift, Spring, etc. aufsetzen.
Und natürlich gibt's von diesen Softwares auch jeweils eine Enterprise Edition und/oder anderweitigen kostenpflichtigen Enterprise Support. Lizenzen wo man pro Kern bezahlt wären mir dort jetzt auf Anhieb nicht bekannt. Vielleicht gibt's was wo man "pro Installation" bezahlt, aber das ist dann ja auch eher ein Argument für mehr Kerne oder mehr-Sockel Systeme.

Geld verschenken tut niemand freiwillig. Sobald die Firmen merken, dass plötzlich die Kunden anfangen, nur noch dicke 8-Socket-Server mit 8 x 28 Kernen hinzustellen (oder meinetwegen "nur" 2 x 64 Kerne mit Rome), wird gerne auch mal das Lizenzmodell geändert. Falls nicht sowieso alles irgendwann als jährliche "Subscription" läuft.

Die Zeit, wo man eine Lizenz kauft und dann 10 Jahre nutzt, geht vielerorts zu neige.

Unter Linux hat man halt eher die Wahl: Hole ich mir die System-, Netzwerk-, etc.-Admins ins Haus und arbeite mit kostenlosen Produkten. Oder miete ich SaaS- oder sonstige Cloud-Produkte, wo die Administration ein externer Dienstleister übernimmt.

In der heutigen Zeit teure Personalressourcen (Spezialisten) in der IT anzustellen ist auf Dauer gefährlich. Geht es der Wirtschaft mal wieder kacke, bekomme ich die Leute nicht los (zumindest in größeren Unternehmen wird das bei entsprechender Betriebszugehörigkeit und oder anderer Faktoren wie soziale Gründe und Betrieb kann das langwierig sein). Behindert einen im Zweifelsfall auch bei der Entwicklung. Werden neue Skills gefordert, muss ich entweder den 50-jährigen Mokel, der seit 20 Jahren das gleiche macht, noch mal auf irgendetwas neues schulen oder ich kaufe mir das Know-How bedarfsgerecht ein. Ist ohne Frage aber auch eine Philosophiefrage, die jeder für sich entscheiden muss. Gibt für beides gute Gründe dafür und dagegen.

Im Endeffekt ist es natürlich immer eine Geldfrage. Mit genug Geld kriegt man auch das passende Personal und/oder kann sich direkt bei Amazon AWS im großen Stil einmieten und kriegt alles erdenkliche fertig eingerichtet frei Haus.

Letztlich ne Wahl zwischen Pest und Cholera. Ich bin kein Gegner der Cloud (im Gegenteil) aber das Risiko, sich dort noch weiter von einem Unternehmen wie Amazon abhängig zu machen, die - bei entsprechender Marktdurchdringung - irgendwann die Preise nach oben drehen oder die Produkte ständig ändern oder schlicht abkündigen (wie z.B. mit der Treuhand Azure Cloud gerade geschehen), sieht man doch als Kunde ziemlich alt aus. Nur eins ist noch schlimmer: Miese Software mit Personal erschlagen. Das führt heute jedes Unternehmen mittelfristig in den sicheren Tod.

 

[fdsonne]

Epyc lässt man standard mäßig ebenfalls im UMA Mode laufen.

Epyc ist doch NUMA only...

Leider wird bei TR/Epyc das nur bedingt richtig verstanden, weil alle Welt davon auszugehen scheint, dass der UMA Mode die bessere Basis ist - ist er aber nicht. Die richtige Basis wäre der NUMA Mode mit NUMA aware Software. -> denn das ist am schnellsten und funktioniert auch am Besten. Da aber NUMA aware Software lange nicht die Regel ist, verlierst du mit Epyc in manchen Fällen einfach Performance die in einer Konstellation ohne 4-8x NUMA Nodes eben nicht in der Form liegen bleibt. -> was am Ende eben einer der Gründe ist, warum Epyc zwar gut, aber eben nicht über jeden Zweifel erhaben ist

Beide Virtualisierer die ich gut kenne und für die ich zertifiziert bin (ESX und Hyper-V), werden eine VM zunächst immer auf einem NUMA Node halten, damit erreicht eine EPYC CPU aber nur einen Bruchteil vom möglichen Speicherdurchsatz. Was du also brauchst ist eine Applikation die NUMA Aware ist und Fummelei in deinem Virtualisierungshost, damit er die vCPUs aufteilt auf verschiedene Kerne aufteilt. Dann kannst du aber nur hoffen, dass die Applikationsthreads unabhängig voneinander arbeiten wie bei einem SQL Server. Hast du stattdessen einen Terminal Server unter Windows, willst du ja nicht, dass die Threads von Kern zu Kern geschaltet werden.

Reich doch die NUMA charakteristik in die VM? Bei NUMA aware Software oder Konstellationen welche problemlos auf Nodes verteilbar sind (Terminal Server bspw. -> Multithreading = Multiple Threads with Multiple Applications) geht das auch mit Eypc 1a.
Was auf Blech funktioniert, funktioniert auch in VM - per ESXi geht das - und sollte natürlich auch getätigt werden, wenn man so eine Konstellation fährt. Dann gibst du der VM eben 2P/xC als vCPUs oder 4P/xC mit und der Hypervisor teilt das entsprechend in Hardware auf die bestehenden NUMA Nodes. Das ist weniger das Problem bei Epyc.

Das Problem bei Epyc ist die starre und breite Verteilung. Hat dein Host 512GB RAM und du fährst ein 2P Epyc System, ist die maximale RAM Menge pro VM für eine non NUMA aware Software auf 1/8tel des Gesamtspeichers begrenzt. Also 32GB im Max. Eine Exchange VM (nicht NUMA aware! -> Multithreading = Multiple Threads with Single Application) bei >32GB verliert damit Performance und erzeugt massiv IF-Traffic, der für das System und alle anderen VMs eben weitere Nachteile bringt durch hohe Belastung in der Fabric.
Zusätzlich zu diesem Problem kommt das gleiche bei der Zuweisung der vCPUs zum tragen. 8x NUMA Nodes = maximal 8C/16T per NUMA Node per VM bei non NUMA aware Software oder alternativ eben massiv IF Traffic.

Die Teilbestückung ist bei Servern recht häufig da man eben keine kleinen Module verbauen will denn die sind später oft völlig nutzlos. Hinzu kommt das je nach Einsatzzweck und CPU die Bandbreite nicht benötigt wird. Weniger aktive Speicherkanäle und Module heißt auch weniger Verlustleistung. Das trifft vor allen die kleineren Epycs. Bei 16C mit 4 DIEs (Interconnects + IMCs) wird proportional betrachtet viel Energie für Interconnects und IMCs verheizt.

Zum ersten, Teilbestückung oder Bestückung entgegen der vorhandenen Channel kommt doch meist bei Servern ohne RAM Größenanforderungen zum tragen...
Den Epyc zwingst du damit halt über die IF zu sprechen - Latenz, Bandbreitengrenzen, ggf. Einschränkungen in der nutzbaren PCIe Performance usw. usf.

PS: zum Verbrauchsanteil der Fabric bei AMD gibts bei anandtech nen Artikel zu - ein Epyc versäuft fast 50% seines Energieverbrauchs für die Fabric In deren Fall war das glaube ich aber ein 32C 7601er

 

[xexex]

Geld verschenken tut niemand freiwillig. Sobald die Firmen merken, dass plötzlich die Kunden anfangen, nur noch dicke 8-Socket-Server mit 8 x 28 Kernen hinzustellen (oder meinetwegen "nur" 2 x 64 Kerne mit Rome), wird gerne auch mal das Lizenzmodell geändert. Falls nicht sowieso alles irgendwann als jährliche "Subscription" läuft.

Schon lange her geschehen. Oracle und Microsoft berechnen seit gut drei Jahren alles nur noch per Kern. EPYC hätte vor 5 Jahren rocken können, als für MS oder Oracle SQL noch Lizenzen pro Sockel üblich waren.

Eine Windows Server 2016 Lizenz gilt nur für 16 Kerne, für weitere Kerne sind zusätzliche Lizenzen nötig. Kostet der Datacenter Server noch knapp 3000€ für 16 Kerne, werden bei Oracle für so viele Kerne 6 stellige Summen fällig.

https://www.software-express.de/lizenzierung/oracle-database-server-11g-editionsvergleich/

16 Kerne kosten in diesem Fall schlappe 272.000€, eine Frage nach 64 Kernen stellt sich hier so ziemlich niemand und der Preisunterschied für eine Intel CPU ist absolut irrelevant, solange die Intel CPUs mehr "Bums" pro Kern liefern.

Was auf Blech funktioniert, funktioniert auch in VM - per ESXi geht das - und sollte natürlich auch getätigt werden, wenn man so eine Konstellation fährt. Dann gibst du der VM eben 2P/xC als vCPUs oder 4P/xC mit und der Hypervisor teilt das entsprechend in Hardware auf die bestehenden NUMA Nodes. Das ist weniger das Problem bei Epyc.

Mir ist ehrlich gesagt kein einfacher Weg bekannt wie ich sowas überhaupt unter ESXi realisieren könnte ohne jeder einzelnen VM feste Kerne zuweisen zu müssen, unter Hyper-V kann ich zumindest etwas gegensteuern jedoch sind die Optimierungen hier recht beschränkt.

Unter Hyper-V kann ich zum Beispiel sagen, verteile jeweils zwei vCPUs auf einem NUMA Node, so eine Einstellung kenne ich von ESXi nicht. Hier kann ich nur eine VM auf eine bestimmte NUMA Node pinnen und auch nur wenn das nicht in einem Cluster ist.

 

[YforU]

Zum ersten, Teilbestückung oder Bestückung entgegen der vorhandenen Channel kommt doch meist bei Servern ohne RAM Größenanforderungen zum tragen...

Ist oft der Fall ja. Allerdings sind Server aufgrund der Virtualisierung nicht mehr so statisch wie früher. Der effektive Verwendungszweck kann sich über die Laufzeit teilweise mehrfach ändern. Runterfahren, zusätzlichen RAM rein, hochfahren und VMs verschieben

Den Epyc zwingst du damit halt über die IF zu sprechen - Latenz, Bandbreitengrenzen, ggf. Einschränkungen in der nutzbaren PCIe Performance usw. usf.

Genau und deshalb gibt es bei Epyc nur zwei sinnvolle Varianten. SC pro DIE auf dem MCM oder DC. Alles andere ist totaler Mist da die Performance der Nodes dann nicht mehr konsistent ist.

PS: zum Verbrauchsanteil der Fabric bei AMD gibts bei anandtech nen Artikel zu - ein Epyc versäuft fast 50% seines Energieverbrauchs für die Fabric In deren Fall war das glaube ich aber ein 32C 7601er

Ist wirklich heftig. Beim 32C aber kein Problem (bezogen auf Perf/Watt) und bei 24C gehts auch noch. Drunter wirds bezogen auf TCO langsam uninteressant denn der Energiebedarf für Fabric und IMCs nimmt nicht ab. Die kleinen Skylake-SP (Silver/Gold) sind deutlich genügsamer. Das macht es für AMD recht schwierig mit Epyc für Server in kleinen und mittleren Unternehmen attraktiv zu sein.

@YforU
Aber ich kann dem Hypervisor meine Preferencen ja mitteilen
...

Hat fdsonne gut erklärt:
https://www.computerbase.de/forum/t...-wege-fuehren-nach-rome.1824693/post-21735173

Und ich mein 16x 8GB Module werden heut und morgen nicht zu wenig Ram für so einen 2 Socket Server sein.

Kleiner als 16GB verbauen wir nicht mehr. 8GB DDR4 ECC Module enden früher oder später genauso wie die älteren 4GB DDR3 ECC Module. Im Regal. Auf einem aktuellen 2S System (selbst mit "kleineren" CPUs) bekommt man derart viel unter (VMs) das auch 128GB limitieren.

 

[benneq]

Ja, herzlichen Glückwunsch. Und wer gibt mir die Garantie, dass diese Sprößlinge in fünf bis zehn Jahren noch existieren und ich nicht irgendwann ins offene Messer laufe, weil ich auf ein kurzlebiges Pferd gesetzt habe? Mag ja vielleicht heute geil sein, wenn der Trend nicht mehr hip ist, steigen viele Anbieter wieder aus und der Markt konzentriert sich dann auf wenige Anbieter, die dann den Markt unter sich aufteilen und dementsprechend Preise aufrufen können, die eigentlich niemand mehr bezahlen will, aber letztlich erst einmal dazu gezwungen wird.

Deswegen bauen die hippen Newcomer ja Microservices. Falls die Technologie wirklich mal komplett verschwindet, sind die Applikationen so klein, dass man sie mit 2-4 Leuten innerhalb von 1-4 Wochen komplett neu programmieren kann. Da ist dann wegwerfen und komplett neu schreiben kein riesiges finanzielles Risiko mehr.
Netflix betreibt z.B. über 1000 verschiedene solcher Mini Applikationen in den verschiedensten Sprachen (und die dann natürlich jeweils x mal redundant) auf den Servern, die meines Wissens nach bei Amazon gehostet sind.
In so einem Umfeld ist es wesentlich einfacher einzusteigen, weil man jeweils in seinem kleinen Kosmos leben kann. Dafür braucht man dann halt eine ziemlich komplexe Infrastruktur. Und genau das stellt z.B. Amazon AWS bereit, sodass man sich da auch keine Gedanken mehr drum machen muss.

Man muss sich nur zu helfen wissen. Für so ziemlich jedes Problem gibt's eine Lösung. In diesem Fall bricht man halt mit den traditionellen Infrastrukturen und schafft sich dadurch mehr Freiheiten und gleichzeitig natürlich auch wieder neue Probleme, die es so früher nicht gab - wie z.B. Eventually Consistency.

Das funktioniert natürlich nicht für Legacy Projekte. Aber da sitzt man im Normalfall ja eh auf seiner Oracle DB fest und/oder hat Probleme noch Corba Entwickler zu finden

 

[Justuz]

Ich würde mir an eurer Stelle nicht die kosten von amd für die an und abreise zahlen lassen. Stichwort unbefangen
Wieviel zahlt amd eigentlich ? Die Exakten kosten? Oder kommt da noch ein obulus für die "mühe" drauf?
Ich sehe so etwas sehr kritisch, für mich kann ein Reporter nicht frei und unabhängig berichten der geld von den Firmen annihmt über die er Berichtet.

Nicht das es soweit kommt wie bei Obama der immer bestimmte Reporter mit der Air Force One hat mitfliegen lassen, komischerweise haben genau diese Reporter die immer mitfliegen durften, sehr Obama freundlich berichtet.

 

[Taron]

Aber muss das denn wirklich sein? Solch ein Kindergarten ist doch unseriös.

Powerpoints mit Herabwertung / Schlechtreden gewisser Konkurrenzprodukte ("glued together") sind es aber auch. Da nimmt sich keiner der IT-Riesen was, egal ob GPU, CPU, Smart Devices, OS...

 

[smalM]

Und natürlich gibt's von diesen Softwares auch jeweils eine Enterprise Edition und/oder anderweitigen kostenpflichtigen Enterprise Support. Lizenzen wo man pro Kern bezahlt wären mir dort jetzt auf Anhieb nicht bekannt. Vielleicht gibt's was wo man "pro Installation" bezahlt, aber das ist dann ja auch eher ein Argument für mehr Kerne oder mehr-Sockel Systeme.

Im Enterprise-Bereich ist die Lizenzierung pro Kern völlig üblich, normalerweise ein Grundbetrag und dann jährliche "Wartungsgebühren". Bei uns kommt deshalb seit Jahren POWER zum Einsatz, spart mit den haufenweise Threads mehrere 10000€ an Lizenzgebühren.

 

[SaschaHa]

In welchem Verhältnis steht eigentlich für gewöhnlich der Stromverbrauch im Bezug auf die Transistor-Größe? Bei gleichem Takt und gleicher Architektur versteht sich?

7 nm sollen bei TSMC gegenüber 12 / 16 nm ja eine Steigerung um den Faktor 2,7 bei der Transistorzahl pro Fläche bewirken. Skaliert der Stromverbrauch nun eher proportional zur Fläche oder proportional zur Länge der Transistoren, wenn man von einer etwa gleich guten Qualität der Fertigung ausgeht?

Proportional zur Fläche würde ja bedeuten, dass die 7 nm bis zu 2,7 mal Energie-effizienter sein könnten, proportional zur Länge wäre ja immerhin noch ein Faktor von rund 1,64, also der Wurzel von 2,7.

Kennt sich diesbezüglich jemand aus? Erfahrungsgemäß würde ich auf den Längen-Bezug tippen. Macht für mich auch mehr Sinn, da sich für die "Welle" meines Wissens nach effektiv ja nur die Strecke ändert

 

[schmalband]

Gründe?

Die Auswahl. Es gibt keine AMD CPUs für die Blades.
Ich brauche ein Blech, RAM und ein CNA, sonst nichts.
Im Chassis oder hinter dem passthrough Modulen des Chassis ist ein FC-SAN über FCoE verbunden. Ich Boote sogar den ESXi über FCoE aus'm SAN.

Darunter hänge ich seit ein paar Jahren Dell SC Storage. Zwei Mal pro Standort die Kombi jeweils mit VLT und VLTi. Spine-Leaf.

Macht weniger als 5 kWh für beide Serverräume und eine außerordentliche geringe Komplexität.

Wenn ich höre... DB Server Systeme von MS oder Oracle und so viele Kerne, dann muss ich immer an pubertierende Kids denken die keine Ahnung haben.
Es kostet sehr viel Geld die Server zu lizenzieren und ein modernes Datenbank System auf SSDs mit in Memory Technik und mehr als 8 Kerne... Selten oder eben Blödsinn.

Auch Windows Server, Hyper-V usw... Werden immer teurer mit der Anzahl der Kerne und nicht unbedingt effizienter. Geld, Geld, Geld...

X-Core Multiprozessor ist immer schneller und effizienter als die gleiche vermeintliche Core-Anzahl um den HT-Faktor multipliziert. HT bringt in der Praxis nicht wirklich viel.

Ich fahre pro Blade-Blech 50 VMs auf 2*10 Kerne. Wenn Mal Lastspitzen kommen, dann würde ein höherer Takt mehr bringen als mehr Kerne. Natürlich sollte der Cache nicht zu klein sein, dass bringt bei Intel sehr viel.
Wenn alle Systeme gebootet sind und keine Windows Updates vom SCCM verteilt werden, dann reichen um Mittel 15% der Summe der CPU Nennleistung.

Je nach Gesamtkalkulation würde ich dann eher auf 4+Sockel Systeme gucken als auf einem weiteren Host, wenn mehr ran muss.
Die Komplexität bleibt unverändert und die Leistungsaufnahme und der Kühlungsaufwand ist anders als bei einem weiteren Blech.

Ich Falle des Poweredge MX7000 mit den neuen Switches oder in Kombi mit den F10 S4148U ist bei gleichbleibender Leistungsaufnahme und Kühlung eine Steigerung von mindestens 100% möglich zu den Xeon V2/3 und es sind nur eine handvoll Kabel verbaut. Frischluftkühlung ist bei entsprechender Räumlichkeit kein Problem.

Ich persönlich mag FCoE sehr, das ist in Europa eher selten, Deutschland sehr sehr selten.

Ich muss in Europa, Osteuropa, China und USA die Datacenter betreiben und habe mit den Blades gute Erfahrungen.

GPU-Lastiges VDI (CAD usw...) schiebe ich auch seit Jahren in Chassis... Rennt direkt im SAN per FCoE und senkt ebenfalls die Komplexität....
https://www.amulethotkey.com/products/remote-workstation/blade-workstation/

 

[ThePowerOfDream]

Hallo @ all,
Nun ich weiß nicht welcher Teufel mich geritten hat, aber ich sagte AMD. Nachdem ich die Gründe umständlich von DE -> Frau übersetzt hatte, kriegt sie Zockerlust und schmeißt kurz AMD-Aktien für 4500€ per Mausklick in ihr Portfolio. Danach telefoniert sie mit ihrem Vater, und der schmeißt kurzerhand, ohne irgendwelche Rückfragen an seinen Investmentberater oder dergleichen, kurz 70.000€ in den Pott.

Hätteste mal lieber vor 10 Jahren und noch länger zum Kurs von unter 2$ machen sollen. Ich habe damals meine ganze Lebensversicherung da rein gesteckt und habe diese Heute mehr als zufrieden stellend wieder zurück.

 

[fdsonne]

Mir ist ehrlich gesagt kein einfacher Weg bekannt wie ich sowas überhaupt unter ESXi realisieren könnte ohne jeder einzelnen VM feste Kerne zuweisen zu müssen, unter Hyper-V kann ich zumindest etwas gegensteuern jedoch sind die Optimierungen hier recht beschränkt.

Stichwort vNUMA. Seit 5.0 gibts das, wenn mich nicht alles täuscht. Musst du dich mal einlesen. Im Zweifel hast du bei entsprechender Config sogar automatisch die Themen schon aktiv, ggf. einfach mal durchprüfen.
Größer 8vCPUs ist es per default aktiv, wenn HotAdd für vCPUs/vMem nicht aktiv. Du musst aber in die advanced Config der VMs.

Ansonsten ist es immer eine gute Anlaufstelle beim Ressourcenzuweisen eben direkt richtig zu zuweisen. Hast du ne 2P Kiste drunter würde ICH den kleinen VMs idR 1P/1-6C vCPUs zuweisen. Das "zwingt" (außer bei explizit gesetztem Pinning) quasi zur Nutzung eines Single NUMA Nodes. Bei 2P/1-4C vCPUs wäre es sinnig, vNUMA zu aktivieren. Größer 8vCPUs ist es schon aktiv wie gesagt.

Auch sollte man dazu noch erwähnen, dass beim ESXi der NUMA Scheduler eine Art Home Node per VM nutzt. Der physische NUMA Node, der für eine VM verwendet wird, sollte halt den Ressourcenbedarf auch abdecken können. Es ist also sehr wichtig, dies in der Hardware sicher zu stellen -> was mMn eines der größten Probleme von Epyc als Hypervisor Backend ist. Ich kann nicht einfach die zu erwartende RAM Menge Total nehmen und in den Host stecken und dann damit glücklich werden, sondern ich muss zusehen, die größten VMs nicht mehr RAM zugewiesen bekommen, wie im Zweifel der Single NUMA Node bereit stellt.
Brauch ich total um die 200GB gesponnen, habe aber eine VM mit 64GB vMem Bedarf, hat der Epyc Server Ausbau minimum 1TB sau teuren Speichern der dann zu 4/5tel brach liegen wird... -> wirtschaftlich völliger Stumpfsinn.

Wo Epyc funktioniert ist bspw. bei nem vServer Cloud Provider der max. 8x vCPUs anbietet und beim RAM auch entsprechend unter dem Limit fungiert. Da sehen die VMs von der Config her sehr ähnlich aus - und bei mehr Bedarf wird einfach mehr zugesteckt und gut ist. Die meisten Firmen intern werden da aber eher einen Mix aus wenigen übergroßen VMs + ne Menge kleine haben, was ein großes Ungleichgewicht erzeugt und bei Epyc dann das abfedern der großen VMs recht teuer wird.

Kleiner als 16GB verbauen wir nicht mehr.

Ich versuche wenn möglich auf 32GB, besser 64GB Module zu gehen und mir für die Zukunft die Option zur Aufrüstung offen zu halten. Da bis dato immer irgendwann der RAM zum Problem wird - weniger direkt die CPU. Wir fahren hier ganz klassisch 10-16C 2P Systeme mit 256GB (für kleine Nodes) bis rauf zu 1,5TB. Da fängt so ein Server mal schlapp 100+ VMs ein und das Anforderungsprofil geht auch völlig quer Beet.

Für die meisten Leute ist das aber gar nicht greifbar, weil man sich als Otto Normalo gar nicht vorstellt, was da alles für Probleme und Fallstricke bei zu beachten sind. Am Ende paar Euro gespart ist nur solange überhaupt was wert vor dem Finanzer wie die Stundenabrechnung nicht durch vermeidbaren Mehraufwand in sonstweder Form diese wieder wegfrisst oder gar weit übertrifft.

Wenn alle Systeme gebootet sind und keine Windows Updates vom SCCM verteilt werden, dann reichen um Mittel 15% der Summe der CPU Nennleistung.

Das ist ein Punkt der idR nie erwähnt wird, aber um so wichtiger ist. Im Mittel ist die avg. CPU Auslastung auf den Hypervisoren sehr sehr gering. IdR. sinds halt dann die unwissenden, die meinen da wären immer hohe 70-90% CPU Last und deswegen brauch es Rome mit 2x64C physisch usw. Pustekuchen...
15% habe ich zwar nicht mehr nur, aber über 30 bin ich avg. auch nicht

 

[Sithys]

Für Epic hat es nicht gereicht, aber einen Threadripper 2990WX ist doch schon mal ein Anfang! Go AMD Go!

 

[schmalband]

Das ist ein Punkt der idR nie erwähnt wird, aber um so wichtiger ist. Im Mittel ist die avg. CPU Auslastung auf den Hypervisoren sehr sehr gering. IdR. sinds halt dann die unwissenden, die meinen da wären immer hohe 70-90% CPU Last und deswegen brauch es Rome mit 2x64C physisch usw. Pustekuchen...
15% habe ich zwar nicht mehr nur, aber über 30 bin ich avg. auch nicht

Ich sag ja im Mittel.
Die Spitzen gehen ständig auf 50+ oder noch deutlich mehr. Sind aber immer nur Spitzen.

Selbst wenn ich auf mehrere VMs, zig Gigabyte mit 7Zip, gleichzeitig was packe... Komme ich nicht auf 100% oder in die Nähe.

Mein kleinster Standort hat knapp 60 Server VMs und ich bekomme dort die Xeon E-5 V3 nur gelangweilt. Dafür verbrate ich zwei M630 mit jeweils 170 Watt.

 

[fdsonne]

170W bei zwei Servern mit Storage? geht doch noch...

Aber was macht ihr, damit du da ständig hohe Peaks hast?
Peaks hab ich nach Windows Updates, wenn die TIWorker.exe loslegt - aber ansonsten?
-> gerade mal bei einem Cluster mit 2 Hosts nachgesehen.
- 129VMs
- 2x10C v3 Xeons, 768GB pro Host auf zwei Hosts
- avg. CPU Load ~20%, Peaks gegen 30-35%, selten mal 50%+. Co-Stop Counter von Strich 0ms, Memory Usage grob 600GB total
- vCPU zu physical Core Verhältnis von 8/1
- Verbrauch ~250-270W pro Server total, OHNE! Storage -> da stecken nur 2x SD Cards für den ESXi drin

 

[schmalband]

Nur die beiden Blades.
M630,RAM, CPUs und CNA, sonst nichts.

Storage ist da nicht einberechnet.

2x 170 Watt ist nicht viel, aber die Last ist ja im Mittel eher gering. Selbst wenn die Last im Mittel bei 70% wäre, wäre die Leistungsaufnahme ungefähr gleich.

Ich bin auf Effizienz aus und geringe Komplexität und wenig Kabel bei geringsten Latenzen.

Was die Spitzen verursacht ist unterschiedlich, meistens sind die Spitzen nur Sekunden oder Sekundenbruchteile, daher zählen die nicht wirklich.