HP demonstreert 32-way Itanium server

HP geeft deze week op de Gartner Group Data Center Conference een demonstratie van de nieuwste, op de Itanium processor gebaseerde, Superdome server. Dit demo-systeem bevat 32 Itanium processoren en zal op drie partities simultaan Windows, Linux en HP-UX draaien. De huidige Superdome systemen draaien op HP RISC processoren met als besturingssysteem HP-UX. Het bedrijf wil halverwege volgend jaar een 64-way Superdome uitbrengen die tot 16 partities kan bevatten, aldus Vish Mulchand, marketing manager voor de high-end markt. Het demo model is vanwege de grootte uitgerust met 'slechts' 32 CPU's. HP is al sinds vorig jaar van plan om over te stappen op de Itanium en de ondersteuning van de 64-bit's architectuur door Microsoft's .Net speelt daarin ook een rol:

HP last year said it was going to migrate its hardware onto Itanium, and Superdome will be part of that move. Added incentive comes from Microsoft Corp., which said its .Net initiative will support 64-bit computing. The Redmond, Wash., software maker recently released Candidate 2 of the .Net beta, Mulchand said.

The upgraded Superdome server will ship with the latest technology from both Microsoft and Intel, said Lorraine Bartlett, Windows-Itanium marketing manager for HP's Industry Standard Server unit.

Reacties (39)

[Verwijderd]

Wat is eigenlijk de markt voor dit soort super-bakken? Waar worden deze toegepast?

[Verwijderd]

Waarschijnlijk als web/database server.. maar waarom je daarvoor 32 Itaniums voor nodig zou hebben? (zijn ze zo sloom dan? )

[burne]

Webservers zijn network-bound en database-servers zijn I/O-bound. Met andere woorden: webservers hebben meer aan een snellere netwerk-link en database-servers hebben meer aan een snellere storage. Beiden schieten niets op met snellere CPU's. Die staan alleen maar dubbel zo snel te wachten op netwerk of I/O.

[Venator]

Even verder denken: Wat gebeurt er tijdens een SSL verbinding? Wat gebeurt er als je in een database queries, berekeningen en mutaties gaat uitvoeren., Of transacties? Denk je niet dat CPU kracht hier wel een rol gaat spelen als je tienduizenden transacties per seconde moet gaan verwerken?
Even een voorbeeld: In Shell (jawel, het unix pretpark) voeren ze verschillende grote databases met gegevens over materialen, grondstoffen, de eigenschappen er van, allerlei verzamelde waardes etc. Wat denk je dat er gebeurt als er wereldwijd 10000 mensen tegelijkertijd in die database wroeten, berekeningen maken, data verplaatsen en wijzigen? Bij een processingpower tekort kakt de hele performance in en verschijnen er timeouts. De resultaten zijn immers niet op tijd "af" om terug te sturen etc. Je moet dus langer wachten op je data, of het lukt domweg gewoon niet vanwege timeout settings van de clients (in geval van webservers die alleen ssl connecties maken bij bv een bank, simpel voorbeeldje).
Vergeet ook niet dat dit allemaal Enterprise-class spul is, als je dit thuis hebt staan dan hoop ik voor je dat je een paar vrienden hebt bij de NUON

[burne]

Het uitvoeren van een query op een database kost nauwelijks CPU-power. SSL al helemaal niet, dat besteed je uit aan een FEP. Het aantal instructies wat je uit moet voeren voor een query in verhouding tot het aantal bytes wat je moet verplaatsen is laag. Een matrix-vermenigvuldiging heeft precies het omgekeerde. Weinig bytes I/O, veel CPU-instructies. Waar zou een 32 CPU machine goed in zijn, denk je? Hard rekenen, en bytes lezen van de CPU ernaast, en niet in gigabytes over een netwerk stampen of terabytes uit een storage array lezen.

De router waar tweakers aan hangt is een Juniper M20. Daar gaat dus 20 Gigabit per seconde doorheen, als het moet. Dat ding heeft een pentium-2 333 als CPU. Waarvan de load altijd beneden de 5 procent ligt. Oudere routing-engines moeten het doen met een pentium 233 MMX. Terwijl zo'n ding wel 2.5 gigabyte per seconde versleept. Voor veel I/O heb je helemaal geen zware CPU nodig. Laat staan 32 stuks.

[burne]

Clusters zijn sterk in dingen die goed te verdelen zijn over individuele systemen. Web is daar een mooi voorbeeld van. Ga eens naar [url="http://www.ibm.com."]www.ibm.com.[/url] Je wordt al heel snel geredirect naar iets van www-117.ibm.com. Da's een van de servers waar hun cluster uit bestaat. De rest van je sessie handel met die doos af, en www-1 tot en met www-116 hoeven daar verder niets van te weten.

Dozen met veel CPU's zijn sterk in dingen waarbij ze van elkaar moeten weten wat de vorige stap in de berekening was. Weersimulaties zijn het klassieke voorbeeld. Iedere cel in de berekening wordt beinvloed door het weer in de omringende cellen. Iedere cel moet dus weten wat er in andere cellen gebeurd is. Als je dat met een cluster zou doen, zou die verzuipen in het uitwisselen van informatie over die andere cellen, en niet toekomen aan rekenwerk.

[mjtdevries]

Tijdens een SSL verbinding gebeurd er niet zoveel waar je CPU voor belast wordt. Daar koop je namelijk aparte SSL hardware voor.

Wat betreft die Shell database. Kan jij uit de eerste hand bevestigen dat de CPU's de bottleneck zijn? Het is meestal juist geheugen en disk performance waardoor je bij queries moet wachten.

Hoewel met 256GB geheugen en 32GB peak I/O je wel zodanig veel capaciteit hebt dat een paar extra processors ook wel nuttig zijn :-)

Maar data wharehousing kan wel veel CPU kosten.

Overigens kan je natuurlijk ook op de site kijken waarvoor deze machines bedoeld zijn: "consolidation, mainframe re-hosting, key business applications (ERP, billing, financial, HR, etc), data warehousing or technical computing."

[Verwijderd]

idd, ik zat me ook al af te vragen wat het grote voordeel tov. een cluster is.. alleen de pure cpu snelheid eigenlijk, maar dat kan je al heel goed via een cluster bereiken.. misschien toch prijs? (minder computers = minder overbodige hardware per cpu)

[Venator]

Yep, dat is het principe van load balancing, wat je dus met een cluster kan doen. Maar met een database is vaak weer een centrale database in het spel. Die kan dan mooi draaien op een een 32 way machientje . Of weer een cluster van dit soort spul, of van 15000 Athlons, zoals bij Google, wat JFK net al zei. Mogelijkheden zat dus, het is maar net wat je eisen zijn en hoe de kosten opwegen tegen de baten met de aanschaf van dit soort servers.

[burne]

Hoewel met 256GB geheugen en 32GB peak I/O je wel zodanig veel capaciteit hebt dat een paar extra processors ook wel nuttig zijn :-)

Reken mee: 32 Itaniums op 800MHz verzetten 32GB peak. 1 Pentium 233 MMX verzet 5GB sustained. (in een M40)

Zie je het verschil tussen CPU-power en I/O power?

[Verwijderd]

Wat betreft die Shell database. Kan jij uit de eerste hand bevestigen dat de CPU's de bottleneck zijn? Het is meestal juist geheugen en disk performance waardoor je bij queries moet wachten.

Ja de CPU's zijn de bottleneck bij ons datawarehouseje. Die 900 GB (Oracle) database moet namelijk elke nacht fraudeberekeningen enzo uitvoeren, en overdag wordt er securitisation gedraaid (ook rekenen) ,dat vreet processortijd. Dus het ligt er inderdaad maar net aan wat je db precies uitvreet.

[Ronald]

SSL-hardware zit op een pci bus waarvan de access time honderden en honderden cpu cycles is. Al die cycles kun je besteden aan software SSL. Het is de vraag of met huidige cpu power hardware ssl (door de ENORME) latency nog nuttig is. Daarnaast krijg je van een hardware SSL op 33mhz 32bit pci nooit meer dan 50Mbyte/s vanwege bandbreedte beperking van de PCI bus.

Zoek je maar te pletter op Linux-kernel mailling list. Dit is een ruwe quote van mensen die aan de crypto API en linus zelf.

[vandijk]

Grappig dat je NUON noemt, die hebben namelijk een stuk of 5 Superdomes staan voor hun SAP systemen. Daar komen dan voornamelijk de rekeningen uit die samen gesteld worden op basis van duizenden records met gebruiksgegevens, klantgegevens etc. Onderandere 1 record per 5 minuten voor elk van de ongeveer 10.000 zakelijke klanten.
Particulieren zitten in een ander systeem waar minder geavanceerde rekenmethoden gebruikt worden.

Dit was dus een reactie op Venator

[Verwijderd]

databases zijn bijna altijd IO bound. Ga maar na, een zoekopdracht op een harde schijf kost milliseconden (Acces time) en is dus een factor 100.000 trager dan een zoekactie in geheugen. Dat betekent dat een processorin de orde van 10.000.000 kloktikken (7ms t.o.v. 0.5 ns bij 2GHz) staat te wachten op data.
Alleen als de database volledig gecached kan worden (of in ieder geval het relevante gedeelte) kan een database processor-bound worden.
Dit is de reden waarom een EJB-applicatieserver dataacces zoveel sneller kan maken, data wordt in principe gecached in entitybeans, zodat een zoekopdracht een geheugenopdracht wordt i.p.v. een schijfopdracht.

[Femme]

Webservers zijn network-bound

Dat geldt alleen voor statische contentservers. Dynamische contentservers zijn CPU-bound mits zijn in een geoptimaliseerde omgeving zijn geplaatst (bijv.: als de latency naar de databaseserver enorm hoog is zal daar een bottleneck ontstaan). Het enige wat wij (Tweakers.net) boeiend vinden voor onze webservers is een zo snel mogelijke processor (en natuurlijk voldoende geheugen en stabiele hardware).

en database-servers zijn I/O-bound. Met andere woorden: webservers hebben meer aan een snellere netwerk-link en database-servers hebben meer aan een snellere storage. Beiden schieten niets op met snellere CPU's. Die staan alleen maar dubbel zo snel te wachten op netwerk of I/O.

Een goed geoptimaliseerde database server met optimale verhoudingen tussen database omvang, geheugencapaciteit- en performance en storage performance is voor de totale belasting die het systeem kan verwerken CPU-bound. Op een optimaal geconfigureerd systeem zal de belasting kunnen stijgen tot het moment dat de processors bijna volledig belast worden. Alleen bij een systeem die hele zware queries draait (die niet 'snel' gemaakt kunnen worden met betere indexering, betere configuratie van de database buffering en caching of een situatie waarin een databaseserver gewoon erg lompe ongeoptimaliseerde queries draait zal de performance zwaar I/O-bound zijn.

Het uitvoeren van een query op een database kost nauwelijks CPU-power.

Een heleboel queries tegelijkertijd uitvoeren kost wel veel CPU-power. De database server van Tweakers.net doet overdag zo'n 400-600 queries per seconde met een CPU belasting van ongeveer 50 tot 66 procent.

De router waar tweakers aan hangt is een Juniper M20. Daar gaat dus 20 Gigabit per seconde doorheen, als het moet. Dat ding heeft een pentium-2 333 als CPU. Waarvan de load altijd beneden de 5 procent ligt. Oudere routing-engines moeten het doen met een pentium 233 MMX. Terwijl zo'n ding wel 2.5 gigabyte per seconde versleept.

Volgens mij wordt het daadwerkelijke routeren gedaan door de 'Internet Processor ASICs' van de Juniper. Een PII kan dat onmogelijk in z'n eentje doen, al was het maar omdat-ie daar niet genoeg bandbreedte voor heeft.

[Femme]

Databases zijn bijna altijd IO bound. Ga maar na, een zoekopdracht op een harde schijf kost milliseconden (Acces time) en is dus een factor 100.000 trager dan een zoekactie in geheugen.

Daarom moet je ervoor zorgen dat-ie niet eerst de data van de harde schijf moet halen maar alle veel gebruikte data al in de disk cache of de buffers van de database-server heeft. Op een lomp geconfigureerde server met een database van 10GB, 32MB RAM, een lomp geconfigureerde database-server die geconfigureerd is om maar 4MB RAM te gebruiken en geen indexes kent, en applicatiesoftware die uitermate lompe queries op de dbserver afvuurt zul je inderdaad heel waarschijnlijk een hele grote bottleneck in je I/O hebben. De kunst is om het hele zaakje in een optimale gebalanceerde omgeving te laten draaien en dan zul je uiteindelijk veel minder ofhankelijk zijn van I/O bottlenecks.

Ik kan bijv. de performance van t.net dbserver helemaal onderuit halen door één index weg te halen. En dan is één zo'n index maar één van de vele honderden punten waarop de database hardware- en softwareomgeving geoptimaliseerd kan worden.

Ik heb buiten Tweakers.net geen ervaring met databases in het bedrijfsleven, maar ik neem aan dat men daar ook pogingen doet om het geheel een beetje te optimaliseren (ipv alleen maar dure hardware en software kopen).

[mjtdevries]

Zie jij het verschil tussen routers en servers?

Appels en peren weet je wel?

Reken maar dat als je database met gemak in het geheugen past dat de CPU een stuk zwaarder belast wordt.

[Verwijderd]

Als web server? Zo'n ding hang je niet even in een rackje volgens mij bij Trueserver.

[ninjazx9r98]

http://www.hp.com/products1/servers/scalableservers/superdome/index.ht ml
De Superdome IS een rack.
'enige' wat je nodig hebt is een flinke airco, krachtstroom en wat vierkante meters ( plus een zak met geld uiteraard ;-)

[Verwijderd]

Er is wel wat vermogen nodig om een goeie WEB/Database te maken. Als je kijkt dat google 15000 Athlons wil gaan kopen voor hun search engine. Je moet niet vergeten dat deze word gebouwd om honderden mensen tegelijk aan te kunnen

[Verwijderd]

probeer eens meerdere duizenden

maar ipv van 50 athlons dit ding neerzetten...

hmm

met goede loadbalancing winnen die athlonnetjes het denk ik..

[Verwijderd]

juist omdat google extreem paralelliseerbaar is kunnen ze het doen met 15000 goedkope Athlons. Dat is peanuts (ook qua kosten). Met 15000 goedkope Athlons kun je honderdduizenden requests tegelijk verwerken. Moet je nagaan wat voor reclame inkomsten je daarop kan pakken!

[Verwijderd]

Wat is eigenlijk de markt voor dit soort super-bakken? Waar worden deze toegepast?

Ik was vorige week in het datacenter van een mobiele telefonie aanbieder en daar hadden ze er 3 staan. Eén er van stond er voor billing, de andere 2 weet ik niet.

Overigens waren dit ook 32-way Itaniums, dus schijnbaar heeft HP ze ook al voor deze presentatie uitgeleverd. Ze waren trouwens wel spik-splinter nieuw.

[styno]

Bijvoorbeeld de telecom bedrijven gebruiken dit soort systemen om al de gesprekken van hun klanten in bij te houden voor het factureren.

Dit gebeurt in 'realtime', wat wil zeggen dat zodra jij een nummer intoetst en verbinding krijgt, de database al bezig is met de facturering.

Het gaat hierbij over gigantische databases (250+ tabellen) met veel 'berekeningen' op de tabellen.

[Verwijderd]

Ze zijn het interessantst voor rekenintensieve klussen die niet gedaan kunnen worden door superclusters. Dus berekeningen die wel paralelliseerbaar zijn, maar waarbij te grote paralellisatie te veel overhead genereert.
Denk aan eindige elementen methoden, nummerieke oplossingen voor vloeistof of morphologie berekeningen (rijkswaterstaat, Delft Hydraulics), berekeningen aan luchtweerstand voor auto's en vliegtuigen, optimalisaties van chipontwerp, kortom het echt zware rekenwerk.

[MaxxBass]

Grote databases, Cytrix/Terminalservers, SAP, BAAN, mainframes....tal van mogelijkheden...

[Verwijderd]

ja okej

maar let er dan wel ff op dat hoe groter je database. hoe meer clock cycles je er voor nodig hebt um helemaal te doorzoeken. daar heb je dus processor kracht voor nodig. en als een heleboel mensen tegelijk querys uitvoeren. op bijvoorbeeeld google waar een enorme database aan hangt heb je dus flink veel cpu power nodig

[Venator]

Size does not always matter Als je rekenintensieve bewerkingen gaat uitvoeren (bijvoorbeeld kansberekening met een 1000-tal factoren) met een redelijke verscheidenheid aan input, dan zal deze toepassing ook meer van de cpupower gaan vragen. In dit geval van Google is het meer het aantal simultane zoekacties wat cpustress opleverd. Google streeft er na om zo snel mogelijk reslutaten te geven, dus zullen ze ook moet investeren om de zoekacties en andere databasebewerkingen zo snel mogelijk te laten uitvoeren.

[CumpsD]

"demo-systeem bevat 32 Itanium processoren en zal op drie partities simultaan Windows, Linux en HP-UX draaien"

Wat is het nut precies van 3 os'en simultaan te draaien? =) is het niet handiger 1 os te draaien hebben die gewoon alles gebruikt dan te verdelen of 3?

[Behota]

Ik durf het niet met zekerheid te zeggen, maar misschien om de verschillende kwaliteiten elk os te showen op een multi-Itanium platform?

In dat geval is het minder belangrijk of het nu om de power gaat van 10 cpu's of 30 of meer, toch?

[Bryne]

Op een systeem als een Superdome draaien meestal meerdere applicaties. Verschillende applicaties zouden wel eens verschillende Operating Systems nodig kunnen hebben. Een Superdome (maar ook 'midrange' servers van HP en haar concurrenten) kennen daarom hardware-partitionering. Dat betekent, dat alle resources opgedeeld worden: processor, geheugen, IO etc. en niet alleen opslag, zoals in onze PC. Hierdoor kunnen dus verschillende OSen naast elkaar draaien. In dit demosysteem is het HP natuurlijk vooral te doen om te laten zien, dat de Itanium drie totaal verschillende OSen ondersteunt...

[Verwijderd]

Dit demo-systeem bevat 32 Itanium processoren en zal op drie partities simultaan Windows, Linux en HP-UX draaien.

en wat als 1 van de 3 vastloopt/moet rebooten/gehackt wordt ? ......

[ninjazx9r98]

Dan draait de rest gewoon door.

[Sphinix]

Ik zou graag foto's willen zien van deze SupaSpitBak... Iemand??

[Motormouz]

Voor de luiaards onder ons:

http://www.hp.com/products1/servers/scalableservers/superdome/index.ht ml

Niet dat er veel te zien is...

[CRiMiNaL]

Zijn die dingen nou niet bij uitermate geschikt voor Distributed Computing ....

Wh33l, wat jij zegt is natuurlijjk ook weer niet helemaal waar. Met data management ben je altijd nog afhankelijk van I/O ... en dan te bedenken dat er mayb SCA inzit .. dus die snelheid haal je er nog niet compleet uit.

[Verwijderd]

reactie op CRiMiNaL:

nee dat zal ik ook helemaal niet ontkennen.

mijn stelling had helemaal niks te maken met wat nou het meeste invloed heeft op de snelheid van een database.

het enige wat ik aan het verdedigen was is het feit dat cpu power wel degelijk belangerijk is voor grote databases. natuurlijk weet ik ook wel dat de cpu niet de bepaalende factor is voor de performance. het ging mij alleen om het feit dat meer en snellere cpu's weldegelijk invloed hebben op de performance van een database

[Verwijderd]

Deze server is niks kwa rekenkracht ten opzichte van de sun 15000K Fireserver
In dit bakkie kunnen 165 processoren geïnstalleerd worde. Het gaat hier om de Sun UltraSparc 3
900 Mhz. Je kan 586 GB RAM-geheugen inbouwen.
En met de aanwezige schijfcontrollers kan je terabytes aan schijfruimte kwijt.
Op dit ding draait trouwens Sun Solaris 8

[MpDay]

...32 CPU's eh?...

Hmm, DivX coderen? ...binnen 5 minuten.