Intel brengt Xeons met achttien cores uit

Intel heeft de E7-8800 v3- en 4800 v3-series van Xeon-processors aangekondigd. De chips zijn op de Haswell EX-architectuur gebaseerd en bevatten tot aan 18 cores. De Xeons zijn bedoeld voor zware realtime werklasten, zoals analyse-berekeningen op grote datasets.

De nieuwe Xeon-generatie bestaat uit acht modellen in de E7-8800 v3-reeks en vier chips van de E7-4800 v3-lijn. De hoeveelheid L3-cache bedraagt van 20MB bij de eenvoudigste Xeon E7 v3 tot 45MB bij de krachtigere varianten. De hoeveelheid cores loopt van 4 tot en met 18 cores. Dankzij de ondersteuning van 1,5TB per socket die de chips bieden kunnen bijvoorbeeld 8-socketsystemen met het maximum van 12TB ddr3- of ddr4-geheugen overweg.

Intel richt zich met de chips op toepassingen voor in-memory computing, oftewel zware rekentaken die op datasets in het geheugen worden losgelaten. Hierbij moet onder andere de functionaliteit Transactional Synchronization Extensions van Haswell efficiëntieverbeteringen bieden door onnodige dynamische synchronisatie in het gedeelde geheugen te voorkomen. Volgens Intel bedraagt de gemiddelde prestatiewinst van de V3-serie zo'n 40 procent ten opzichte van de Xeon E7 v2-modellen, die overigens met maximaal 15 cores uitgerust waren.

Processor	Cores / Threads	Corekloksn. (Base / Turbo)	AVX Corekloksn. (Base / Turbo)	LLC Cache	Qpi	Tdp	Prijs (in $)
E7-8890 v3	18/36	2,5 GHz / 3,3 GHz	2,1GHz / 3,2GHz	45MB	9,6 GT/s	165 W	$7175
E7-8880 v3	18/36	2,3GHz / 3,1GHz	1,9 GHz / 3,1 GHz	45MB	9,6 GT/s	150W	$5896
E7-8870 v3	18/36	2,1GHz / 2,9GHz	1,8 GHz / 2,9 GHz	45MB	9,6 GT/s	140W	$4672
E7-8860 v3	16/32	2,2 GHz / 3,2 GHz	1,9 GHz / 3,2 GHz	40MB	9,6 GT/s	140W	$4060
E7-4850 v3	14/28	2,2 GHz / 2,8 GHz	1,9 GHz / 2,8 GHz	35MB	8 GT/s	115W	$3004
E7-4830 v3	12/24	2,1GHz / 2,7GHz	1,8 GHz / 2,7 GHz	30MB	8 GT/s	115W	$2196
E7-4820 v3	10/20	1,9GHz	1,6GHz	25MB	6,4 GT/s	115W	$1502
E7-4809 v3	8/16	2,0GHz	1,8 GHz / -	20MB	6,4 GT/s	115W	$1224
E7-8893 v3	4/8	3,2 GHz / 3,5 GHz	2,8 GHz / 3,3 GHz	45MB	9,6 GT/s	140W	$6841
E7-8891 v3	10/20	2,8 GHz / 3,5 GHz	2,4 GHz / 3,4 GHz	45MB	9,6 GT/s	165W	$6841
E7-8880L v3	18/36	2,0 GHz / 2,8 GHz	1,6 GHz / 2,8 GHz	45MB	9,6 GT/s	115W	$6026
E7-8867 v3	16/32	2,5 GHz / 3,3 GHz	2,2 GHz / 3,2 GHz	45MB	9,6 GT/s	165W	$4672

Reacties (36)

Umbrah 6 mei 2015 16:48

Dus in de meest complexe vorm, hebben we het over een 8-socket systeem met 8 NUMA-nodes, met 144 cores met in totaal 288 threads hieroverheen. "Gelukkig" maar over 8 sockets, want Windows heeft een harde limiet van 64 sockets met 320 processors. Licenties kunnen iets anders betekenen, maar dat is ook hoe enterprise linux "werkt". Ik ben stiekem wel benieuwd naar taskmgr.exe's UI in een oude windows versie, toen je nog afzonderlijke balkjes had in Performance! Server 2008R2/Windows 7 zijn de laatste versies die dat nog hadden. 288 balkjes...

Ik denk dat het probleem tegelijk aangeeft in welke niche dit zit: heel veel software is niet NUMA-bewust; of erger; gelicenseert per core. Thermisch zal een dergelijke machine uiteraard extreem zijn, maar dit soort cores zul je dan voornamelijk tegen komen in machines die 'toch' al met MPI-achtige toepassingen werken, of voornamelijk Hyper-V stijl zaken benaderen... provisioning onbeperkt zolang het maar binnen de NUMA-node blijft... En omdat het tweakers is/blijft:

Draait het ook crysis?

Edit: een mooie screenshot - http://superuser.com/ques...rs-does-windows-8-support -- overigens ook een héél mooi probleem in die taskmgr grafiek: "slechts" 44GB van de 1TB geheugen in gebruik maar wel consistent hoge CPU load. Veel taken van deze 8x10koppers met HT zitten richting capaciteit; maar geheugen wordt amper gebruikt. Het punt is dat elke NUMA node hier (geloof ik) nog steeds vier modules wil, met acht NUMA nodes, dus 32 geheugen modules minimaal om alleen al te KUNNEN booten. Je >KUNT< niet minder geheugen in deze beestjes krijgen in veel gevallen om te besparen. Aangezien het ECC+Registered is zul je moeite moeten doen om minder dan 16G per module te vinden; sterker nog: de prijs per gig neemt als je naar 32gig per module gaat eigenlijk amper toe. 32G modules zijn niet zo verschikkelijk bijzonder (OEM prijs zit rond de $400 voor 32gig/module; 16 zit rond de $190)... een 1TB geheugenmachine is niet zo bijzonder namelijk (dat, en 'op de groei' horen veel managers vaak).

offtopic:
Kom ik aan met een specialisme in software die per 4 cores gelicensed wordt...

[Reactie gewijzigd door Umbrah op 26 juli 2024 04:35]

deadinspace @Umbrah • 6 mei 2015 19:18

"Gelukkig" maar over 8 sockets, want Windows heeft een harde limiet van 64 sockets met 320 processors. Licenties kunnen iets anders betekenen, maar dat is ook hoe enterprise linux "werkt".

Ik weet niet waar je dat vandaan haalt, maar Linux ondersteunt aanzienlijk meer dan dat

Het maximaal aantal cores is op dit moment beperkt tot 8192, zie config NR_CPUS:

int "Maximum number of CPUs" if SMP && !MAXSMP
range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64

(grappig genoeg is de documentatie eronder out of sync met de werkelijke opties)

En het aantal NUMA nodes (≈sockets) is beperkt tot 2¹⁰=1024, zie config NODES_SHIFT:

int "Maximum NUMA Nodes (as a power of 2)" if !MAXSMP
range 1 10

(Het aantal ondersteunde NUMA nodes is 2^NODES_SHIFT)

Er zijn ook daadwerkelijk systemen die met zoveel CPUs draaien, zie bijvoorbeeld de SGI UV 2000 serie:

A choice of unmodified SUSE® Linux® Enterprise Server or Red Hat® Enterprise Linux operating systems...

Min/Max Cores (Threads) 32/2048 (4096)

Het kan wel zijn dat een Linux distributie (standaard) minder cores/sockets ondersteunt; dat is omdat omdat support voor grote hoeveelheden CPUs ook kosten met zich meebrengt, zoals een vast stukje geheugen per ondersteunde CPU (zie bv de docentatie bij NR_CPUS boven).

Zo ondersteunt Debian 8 (welke ik draai) standaard "maar" 512 CPUs:

% grep NR_CPUS /boot/config-3.16.0-4-amd64
CONFIG_NR_CPUS=512

[Reactie gewijzigd door deadinspace op 26 juli 2024 04:35]

Alfa1970 @deadinspace • 6 mei 2015 21:50

(grappig genoeg is de documentatie eronder out of sync met de werkelijke opties)

Ik vind dat helemaal niet grappig, wie moet ik nu geloven?
De documentatie of een willekeurig iemand anders die beweert dat de documentatie niet klopt.

Ik vindt het extreem slecht dat de documentatie niet klopt. Waar kan ik een klacht indienen?

deadinspace @Alfa1970 • 7 mei 2015 00:21

Ik vind dat helemaal niet grappig, wie moet ik nu geloven? De documentatie of een willekeurig iemand anders die beweert dat de documentatie niet klopt.

Je kunt het gewoon zelf bekijken in de relevante configuratie van de Linux kernel source, waar ik in mijn vorige post ook al naar linkte en gedeeltelijk quootte. Hier is het volledige relevante stuk:

config NR_CPUS
int "Maximum number of CPUs" if SMP && !MAXSMP
range 2 8 if SMP && X86_32 && !X86_BIGSMP
range 2 512 if SMP && !MAXSMP && !CPUMASK_OFFSTACK
range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64
default "1" if !SMP
default "8192" if MAXSMP
default "32" if SMP && X86_BIGSMP
default "8" if SMP
---help---
This allows you to specify the maximum number of CPUs which this kernel will support. If CPUMASK_OFFSTACK is enabled, the maximum supported value is 4096, otherwise the maximum value is 512. The minimum value which makes sense is 2.

This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image.

Zoals je kunt zien is het werkelijke maximum in de configuratie onder de juiste voorwaarden 8192 ("range 2 8192 if ..."), maar rept de documentatie eronder over 4096.

Als je zoekt kun je ook de commit vinden waarin deze inconsistentie is ontstaan:

x86/cpu: Increase max CPU count to 8192

The MAXSMP option is intended to enable silly large numbers of CPUs for testing purposes. The current value of 4096 isn't very silly any longer as there are actual SGI machines that approach 6096 CPUs when taking HT into account.

Increase the value to a nice round 8192 to account for this and allow for short term future increases.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Cc: prarit@redhat.com
Cc: Russ Anderson <rja@sgi.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/...ansolo.jdub.homelinux.org
( Tweaked it so that MAXSMP simply sets the maximum of the normal range. )
Signed-off-by: Ingo Molnar <mingo@kernel.org>

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f03e428..805469a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -826,9 +826,9 @@ config NR_CPUS
. int "Maximum number of CPUs" if SMP && !MAXSMP
. range 2 8 if SMP && X86_32 && !X86_BIGSMP
. range 2 512 if SMP && !MAXSMP && !CPUMASK_OFFSTACK
- range 2 4096 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64
+ range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64
. default "1" if !SMP
- default "4096" if MAXSMP
+ default "8192" if MAXSMP
. default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000)
. default "8" if SMP
. ---help---

Ook interessant om te zien dat dat maximum een tamelijk arbitraire waarde is, en geen fundamenteel maximum. Er zijn machines met meer CPUs dus eh ja, dan verhogen we de grens maar zodat we dat ook testen

Ik vindt het extreem slecht dat de documentatie niet klopt.

Het is verre van ideaal, maar het is de realiteit dat software en documentatie vaak out of sync raken. Ik zie het in mijn dagelijkse leven vaak genoeg. Daarom vond ik het wel grappig het ook hier te zien.

Dit is trouwens tamelijk onschuldig, aangezien het sowieso alleen mensen treft die kernels compilen die (mogelijk) op supercomputers met zulke hoeveelheden CPUs moeten draaien. Met andere woorden: distributie-bouwers en beheerders van dergelijke supercomputers.

Waar kan ik een klacht indienen?

Josh Boyer <jwboyer@redhat.com> is de auteur van de patch die de inconsistentie heeft geïntroduceerd, bij hem melden geeft waarschijnlijk het snelste resultaat. Anders de Linux kernel bugtracker, of misschien via de bugtracker van je favoriete distributie.

Maar ik raad je dan wel aan wat vriendelijker te zijn dan in je post waar ik op reageer

Nog beter is om meteen een patch mee te sturen, zoiets bijvoorbeeld:

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 226d569..6aaf38a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -855,7 +855,7 @@ config NR_CPUS
---help---
This allows you to specify the maximum number of CPUs which this
kernel will support. If CPUMASK_OFFSTACK is enabled, the maximum
- supported value is 4096, otherwise the maximum value is 512. The
+ supported value is 8192, otherwise the maximum value is 512. The
minimum value which makes sense is 2.

This is purely to save memory - each supported CPU adds

(je moet dan wel even mijn post quoten en de patch daaruit kopiëren, want Tweakers eet allemaal relevante whitespace op)

[Reactie gewijzigd door deadinspace op 26 juli 2024 04:35]

Alfa1970 @deadinspace • 7 mei 2015 12:22

Om te kunnen kijken in de Kernel Source, moet ik weten welke files ik moet downloaden.
Moet ik weten in welke specifieke file deze specifieke functie zit.
En dan moet ik het ook nog begrijpen wat er staat.

Terwijl dit kan worden samen gevat in één enkel regeltje in de handleiding onder supported hardware die makkelijk te begrijpen valt voor iedereen, zelfs als je geen C/C++ guru bent.

Maximum Supported CPU's: 8192.

Dat is duidelijk, en op een logisch te beredeneren manier uit te vinden.
Kernel broncode doorploegen is niet de meest logische manier om iets te weten te komen, als je uberhaupt als begrijpt wat er in staat.

Ik waardeer je uitleg enorm, maar ik zou liever zien dat de documentatie wordt gecorrigeerd.

Feitelijk zou deze situatie nooit mogen bestaan.

Als een project goed wordt geleid dan wordt ten eerste de (ontwerp) documentatie geschreven, en wordt daarna pas aan de hand daarvan de implementatie gedaan.

deadinspace @Alfa1970 • 7 mei 2015 14:59

Om te kunnen kijken in de Kernel Source, moet ik weten welke files ik moet downloaden.
Moet ik weten in welke specifieke file deze specifieke functie zit.
En dan moet ik het ook nog begrijpen wat er staat.

Dat klopt, maar nu praat je als eindgebruiker. De Linux kernel source code en diens documentatie (waar ik het over had) is geen product voor eindgebruikers; het is een product dat door OS-distributeurs (zoals Debian, Ubuntu, Red Hat, en Google/Android) wordt gebruikt om een OS te maken voor eindgebruikers.

Dat betekent dat de configuratie en bijbehorende documentatie die ik quootte gebruikt wordt door OS-distributeurs, beheerders van supercomputers, en enthousiastelingen die het leuk vinden zelf hun kernel te compilen. Dat zijn mensen die wel weten (of kunnen leren) waar ze moeten kijken en hoe dat te begrijpen.

Hoeveel CPUs het resulterende OS ondersteunt hangt af van de keuzes van de OS-distributeurs; met welke configuratie zij hun kernel compilen. En dit zou dan in de documentatie van het resulterende OS opgenomen moeten worden.

Zoals ik bijvoorbeeld al aangaf ondersteunt Debian (8.0, op x86-64) 512 cores, minder dan Linux' maximum van 8192. Dit zou dan in Debians documentatie moeten staan (waar ik het overigens niet kon vinden), niet in de Linux kernel source documentatie.

Terwijl dit kan worden samen gevat in één enkel regeltje in de handleiding onder supported hardware die makkelijk te begrijpen valt voor iedereen, zelfs als je geen C/C++ guru bent.

Maximum Supported CPU's: 8192.

Zo eenvoudig is het nooit. Het maximum hangt bijvoorbeeld af van de CPU-architectuur. Op x86-64 is het 8192, maar voor bijvoorbeeld arm, mips, ppc en zelfs i386 zal het een andere waarde zijn. Volgensmij is het bv significant lager op i386 en arm.

Als een project goed wordt geleid dan wordt ten eerste de (ontwerp) documentatie geschreven, en wordt daarna pas aan de hand daarvan de implementatie gedaan.

Dat is jouw mening, geen feit.

De realiteit is dat maar weinig projecten strict volgens dat model (grofweg: het waterfall model) werken. Linux (de kernel) doet dat zeer zeker niet; linux kernel development is een veel dynamischer en vloeiender proces waar partijen zelf kunnen werken aan wat zij belangrijk achten in plaats van aan een arbitraire beslissing die iemand vijf jaar geleden maakte.

Bijvoorbeeld, IBM denkt "Ja, dat Linux is leuk, maar het draait niet zo efficient op systemen met meer dan 32 CPUs, en dat willen onze klanten wel". Dus IBM betaalt een paar dozijn developers om aan de Linux kernel te werken, en een paar jaar later schaalt Linux veel beter op grote hardware. (Dit is vrijwel letterlijk een jaar of 10-15 geleden gebeurd)

En die werkwijze heeft toch wel enig effect, want Linux schaalt tegenwoordig uitstekend en is zeer populair op zowel kleine hardware als routers en smartphones (75%) als op supercomputers (97% van de top-500)

En ja, dat er dan in de (hoogst technische) kernel souce documentatie een getal wordt vergeten te updaten van 4096 naar 8192 omdat het niet 5 jaar geleden in steen gebeiteld was... Ik neem het wel voor lief. En ik stuur wel een patch.

Alfa1970 @deadinspace • 8 mei 2015 00:33

Dus je kan er vanuit gaan dat de documentatie nooit op orde is?
Lekker product. Maar inderdaad, mijn persoonlijke mening.

Ik zie namelijk niet in waarom je niet éérst de documentatie aan kan passen alvorens de implementatie aan te passen.

Dat hangt helemaal niet af van een beslissing die iemand 5 jaar geleden heeft gemaakt, maar van de beslissing die je hier en nu maakt.

Het voorbeeld van IBM dat je noemt is een design beslissing van IBM om een branch te maken. Alvorens die branch wordt gemaakt, nemen ze de documentatie, passe die aan aan het nieuwe plan en implementeren vervolgens dat plan.

Als later blijkt dat het handig voor iedereen is, voeg je de branches weer samen, en is iedereen weer blij...
Maar gedurende al die tijd is de documentatie van elke branch op orde.
Zoals het in mijn opinie zou moeten zijn.

[Reactie gewijzigd door Alfa1970 op 26 juli 2024 04:35]

trogdor @Alfa1970 • 7 mei 2015 14:51

Het waterval model is al een tijdje niet meer in gebruik. Gelukkig maar.

PolarBear @Umbrah • 6 mei 2015 16:51

Je kan in Windows al tijden in de Taskmanager grafiekjes per core of overall kiezen.

Wouter Tinus @Umbrah • 6 mei 2015 18:39

Dus in de meest complexe vorm, hebben we het over een 8-socket systeem met 8 NUMA-nodes

Deze Xeons kunnen tot en met 8 sockets glueless werken, maar met een custom chipset kunnen ze verder doorschalen naar 16 sockets. Dan krijg je bijvoorbeeld een HP Superdome X of een Bull S6000.

Op papier wordt ook 32 sockets ondersteund, maar hoewel in ieder geval HP dat in theorie aankan met zijn chipset, is er (nog) niemand die zo'n maximale configuratie openlijk aanbiedt

. De markt voor dit soort monsters is dan ook behoorlijk klein en wordt gedomineerd door IBM (Power/z-series) en in mindere mate door SPARC van Oracle/Fujitsu.

[Reactie gewijzigd door Wouter Tinus op 26 juli 2024 04:35]

rudinie 6 mei 2015 16:47

Intel heeft op zijn site ook Xeon E5 v3 staan met 18 cores:
http://ark.intel.com/prod...699-v3-45M-Cache-2_30-GHz voor de "normale" dual socket systemen. Hoewel het Q3 2014 aangekondigd is zijn ze nog niet verkrijgbaar voor zover ik weet.

PuzzleSolver @rudinie • 6 mei 2015 16:54

Die staat gewoon in pricewatch

http://tweakers.net/categ...BkWWKOklW0koWZoYVSbG1tLQA

Dat is de vorige serie en die had ook al een 18 core.

Headline had ook moeten zijn:

Intel brengt opnieuw Xeons met maximaal achttien cores uit

Subigo @rudinie • 7 mei 2015 07:14

Deze zijn wel degelijk beschikbaar. Wij hebben momenteel 3 IBM/Lenovo X3650M5 servers met ieders 2 x een Intel E5 2699v3 en 512 GB Mem.
Prachtige machines en we besparen een hoop aan licenties. (VMware, 2012r2 datacenter, veeam, trend Micro zijn allemaal op een per CPU licentie)

player-x 6 mei 2015 16:52

Damn....., en ik wilde een server quad 18 core CPU opstelling, zou wonderen doen voor mijn video encoding tijden, maar $30.000 is net over mijn budget.

Helaas, dergelijke opstellingen zijn meer van wegen de prijs, meer geschikt voor bedrijven die een flink aantal VM's willen draaien op een enkele machine, en met een TDP van 165W of te wel 9W per core, valt het energie verbruik behoorlijk mee.

mocem @player-x • 6 mei 2015 17:21

Xeon Phi dan niet een goed idee?

player-x @mocem • 6 mei 2015 17:35

Die draait alleen op een speciale OS, iig de huidige, of dat voor de nieuwe ook geld is nog onbekend.

batjes @player-x • 6 mei 2015 17:46

Er zijn gewoon Xeon Phi drivers voor Windows en Linux.

player-x @batjes • 6 mei 2015 18:15

Ja, om de Xeon Phi OS aan te spreken, maar zolang er geen encoder is die daadwerkelijk op de Xeon Phi kan draaien, maakt dat encoding op een Phi een leuke snelle mogelijkheid, .............. in theorie!

analog_ @player-x • 6 mei 2015 21:08

Als je dat bedrag aan hardware uitgeeft (per node) doe je ook niet moeilijk om zelf software te schrijven. De kans dat dit ooit Windows ziet is volgens mij ook betrekkelijk klein, tenzij er een budget opgemaakt moet worden. Hetzelfde zie je bij infiniband in hpc, allemaal customware.

Genicus 6 mei 2015 21:37

Hmm, toevallig vorige week nog een presentatie gekregen over software defined infrastructure. Perfecte CPUs om in een Lenovo System x3950 X6 te stoppen en je datacenter op te virtualiseren!

MAX3400 @Genicus • 6 mei 2015 22:21

Perfecte CPUs om in een Lenovo System x3950 X6 te stoppen en je datacenter op te virtualiseren!

Dat is dan ook de reden dat Lenovo/IBM juist adverteert met de aangekondigde Xeons en op hun product-page ook al spreekt over Intel Xeon processors E7-8800 v3 series up to 3.2 GHz, 1600 MHz memory access (DDR3) and up to 1866 MHz (DDR4) memory access, 144 cores per chassis, supports up to 12.0 TB memory using 192x64 GB LRDIMMs.

Vergeet dan alleen niet dat 1 enkel x3950 systeem tot wel 11.2kW aan stroom kan vereisen. Dat is evenveel als 8 redundant uitgevoerde Dell R720's die op vol vermogen staan te ratelen; elke Dell kan 2x 8 cores voorzien middels 2 Xeon-sockets en 768GB RAM voorzien.

Iets zegt met dat in dit voorbeeld je een betere oplossing kan realiseren met 8 Dell's (kostentechnisch) dan met een afgeslankte x3950. En vergeet niet; als 1 Dell uitfikt, kan je die vervangen en je omgeving blijft relatief netjes doordraaien. Als 1 x3950 uitfikt, heb je waarschijnlijk geen hot-spare / spare in het rack hangen.

Genicus @MAX3400 • 6 mei 2015 22:46

Laat me duidelijk zijn, ik ben het 100% met je eens, maar wil je ook wel vertellen wat de presentator er verder over te vertellen had.

We hebben dat redundantieprobleem ook tijdens de pauze voorgelegd. Hij vertelde ons echter dat dit niet is om een klein datacenter op te laten draaien. Hij gaf de 12 TB RAM dan ook aan, als je dan verschillende van zo een toestellen (zeg nu maar een standaard rack vol), dan kan je daar een flink datacenter op draaien.
Tijdens de presentatie dan weer moet je daarbij volgens hem dan ook een totaalrekening maken van alles dat je in een datacenter aantreft waarin je kan besparen met deze methodologie, zoals netwerk (je hebt minder switches en routers nodig omdat die toch in software draaien, en kan je core consolideren met verschillende andere lagen), je kan dingen als vSAN gebruiken en je SANs buitengooien, koeling van de zaal moet ook niet zo stevig zijn, ...

Ik moet ook wel bijzeggen dat het een presentatie was over hoe Lenovo de toekomst van datacentra ziet. Dus daarom vandaag nog allemaal niet toepasbaar, wel logische opvolgingen en je ziet het er ook zo wel naar evolueren en dus hun toekomstvisie, niet zozeer werkelijkheid.

Arjenc 7 mei 2015 13:49

Bovenstaande tabel is ook in een 'meer grafisch' plaatje samen te vatten met een onder verdeling in:
- basic
- standard
- advanced

http://hothardware.com/ga...e=big_xeon-models.jpg&p=1

Deze is afkomstig vanuit dit artiekel (bron vermelding zullen we maar zeggen):
http://hothardware.com/re...mily-of-processors?page=1

Ashketchum22 6 mei 2015 16:41

Daar kan je een behoorlijk virtueel parkje op draaien met 18 cores... Je betaalt ook gelijk de hoofdprijs

maar ach

Niemand_Anders @Ashketchum22 • 6 mei 2015 16:49

Voor virtualisatie zijn de E5 Xeon's beter geschikt. De E5-2699 is bijvoorbeeld ook een 18-core. Alleen staat er in de pricewatch ook een 16-core (E5-1698 V3) voor ongeveer 2000 euro, wat de helft is van de 18 core processor. Daarbij kun je het geheugen ook gemakkelijker over 16 cores verdelen dan over 18 cores..

Er is ook nog een E5-4600 serie te koop, maar deze processors worden bijna uitsltuitend door OEM's geleverd..

MAX3400 @Ashketchum22 • 6 mei 2015 16:51

Juist niet. De schaalbaarheid van je hosts wordt dus aanzienlijk beperkt door de investering die je wil doen. Ook 20 VM's draaien op 1 nieuwe Xeon, kan rare dingen opleveren als je zaken als NUMA aanzet op je hypervisor.

Verder lijkt het me echt slimmer om 4 Xeons per host te plaatsen voor een totaal van 16 cores dan 1 Xeon met 16 cores; ook je on-die cache is bij 4 Xeons aanzienlijk meer/groter.

Elk nadeel heeft zijn voordeel

aadje93 @Ashketchum22 • 6 mei 2015 16:50

ik denk dat 4 servers met quad cores meer kosten dan die ene 18 core cpu, ook stukken makkelijker dat het op 1 machine draait, de VM's hebben dan super snelle connectie (immers rammn snelheid)

PcDealer @aadje93 • 6 mei 2015 21:55

Maar toch is een 4 server virtualisatie omgeving robuuster dan een 1 server omgeving. Als een host uitvalt, heb je nog drie alternatieven.

aadje93 @PcDealer • 7 mei 2015 10:26

True, maar waar ik op doelde was dat die VM's dedicated draaien op 4 machines, die uiteraard ook redundant moeten zijn, terwijl het op 1 machine vaak goedkoper is (immers meer vm's in een rack)