Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsCloudflare-Server: Ice Lake-SP fliegt wegen Energieverbrauch raus
Es gibt so gut wie keine Software die tatsächlich aus technischen Gründen nur auf Intel funktioniert und nur einige wenige Hersteller, die aus reiner Idiotie heraus ihre Software nur für Intel freigeben.
Äh, ... nö.
Als Idiotie würde ich millionenschwere Investtionsvorhaben nun nicht unbedingt bezeichnen, die sich auf darauf verlassen müssen, dass das alles läuft und zu den Vorschriften und Zertifizierungen passt.
Und die eben auf speziell angepasste Software setzen, die ihre eigenen tiefen Routinen mitbringt.
Da muss AMD halt noch das drumherum für die Prozesse mit auf die Beine stellen bzw. konsolidieren.
Und AMD ist vielleicht x86, nur steckt der Teufel, wie üblich, im Detail.
Das dauert alles.
Die werfen wir hinterher dann auch raus bzw. stecken diese ja während der Migration in ihrem eigenen "alten" Cluster, vMotion geht ja auch über Cluster hinweg.
fdsonne schrieb:
Also eigentlich nur homogene Server Cluster fahren. Aus diversen Gründen.
Aufgrund der Baselines sowieso. Wenn wir Beispielsweise ein Cluster aus 4 oder 5 Hosts haben werden erstmal 2 neue Server dazu gehangen und ein neues Cluster aufgebaut, dann nach und nach Maschinen abziehen bis der erste alte Host keine VMs mehr hat und der nächste Server rein usw.
fdsonne schrieb:
Man kann nur noch "leere" Hosts in ein Cluster schieben. Fällt mir immer dann auf die Füße, wenn ich verschiedene Themen konsolidieren muss - unterbrechungsfrei natürlich 😂
Richtig, das ist mit der genannten Vorgehensweise recht problemlos. Da unser Storage aber extern per RDMA/RoCE hängt könnte man auch einfach vorher die Maschinen ent-registrieren und auf dem neuen wieder registrieren, vMotion wäre im Grunde gar nicht nötig. Ist aber die Lösung bei der man trotzdem irgendwie weniger Schweißperlen auf der Stirn hat und die Maschinen keine Sekunde offline sind.
fdsonne schrieb:
Echt? Das kostet phasenweise schon merklich Performance...
Ja, wegen der absoluten Unberechenbarkeit was die Performance angeht - die GHz Berechnung im vSphere hat dann zusätzlich zu kämpfen. Sizing macht dann keinen Spaß mehr und die CPUs mit vielen Kernen haben sowieso keinen all zu hohen Boost (hängen bei Nutzung vieler Kerne dann schnell im TDP Limit und takten nur noch ein paar MHz zusätzlich hoch).
fdsonne schrieb:
Bei mir hier ist die avg. CPU Load im Schnitt im Cluster und Host bei vielleicht 10-30%. Da ist ultra viel Luft für hohen Boosttakt.
Gerade wenn so viel Luft nach oben ist wäre der Base ja fast ausreichend. Die meisten Anwendungen die wir einsetzen profitieren eher von mehr Kernen als vom Takt weil sie eher durch viele User (mit jeweils eigenen Prozessen) als durch wirklich hohe Last ausgelastet werden. Einzig beim SQL Server legst du dann mehr Geld für die Cores hin (sofern man nicht nach Clients lizenziert).
fdsonne schrieb:
Und einige der Workloads profitieren davon auch extrem. Bzw. was heist extrem, sie skalieren mit dem Takt annähernd 1:1. Man bekommt halt damit eine gewisse Unberechenbarkeit, weil das mal so und mal so vom Speed ausschaut.
Das ist die Abwägung, sicherlich bekommt man hier und da dann mehr Performance raus aber am meisten hat bei uns der All-Flash Storage gebracht und genug RAM um Abfragen am besten gar nicht mehr von der Platte auszuführen.
Du hast völlig recht. Das haben mittlerweile auch viele verstanden. Aber dann kommen immer wieder die Nörgler (nicht du) von wegen "Faulheit, will man nicht, bla...."
Die meisten von denen haben noch nie einen Server aus der nähe gesehen geschweige denn verstehen sie, dass man nicht mal eben 50, 100, 1000 Server auf einen Schlag austauschen kann. Zumal das Ergebnis ungewiss ist.
Das ist in fast allen Fällen schlicht falsch.
Die meiste Software mit solchen Limitierungen ist gar nicht wirklich auf Intel optimiert. Da ist es einfach nur ne künstliche Limitierung. Sieht man schon daran dass die Software völlig problemfrei und performant auf AMD läuft sobald man die Sperre entfernt bzw. dem OS eine andere CPU vorgaukelt.
Andere Software hat zwar tatsächlich Optimierungen aber die kommen schlicht von entsprechenden Compiler settings. Da steckt in der Regel keine manuelle Arbeit drin.
Es wäre für den Hersteller ein leichtes auch Amd binaries anzubieten.... Sie wollen bloß nicht.
Selbst die Intel optimierten Binaries laufen in der Regel auch auf aktuellen AMD CPUs da die Hersteller ihre Software für alle Intel CPUs der letzten 10 Jahre freigeben und eine 10 Jahre alte Intel CPU nix kann was ein aktueller Epyc nicht auch könnte.
In ganz ganz wenigen Fällen (Virtualisierung z.b.) gibt es tatsächlich technische Gründe bei denen es wirklich ein wenig Aufwand wäre die Software auch für Amd freizugeben (hauptsächlich zusätzlicher Testaufwand).
@KurzGedacht : Glaub’ mir, ich wollte das auch nicht wirklich glauben. Ich musste mich eines besseren belehren lassen.
Einer unserer DEV hat mich mal an die Hand genommen und mir meine doofen / ketzerischen Fragen beantwortet.
Tja, so ist’s.
Immerhin: Es wird ja mittlerweile auch mit den anderen CPUs getestet, bis diese Projekte allerdings durch sind, … das dauert.
Und es muss sich unterm Strich rechnen.
Auch das scheint - ebenfalls mittlerweile - gegeben.
