QuicksearchDisclaimerThe individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
|
Memory prices for SPARC Servers.Wednesday, October 29. 2008Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
While I tend to agree with high-end and midragne systems when it comes to low-end I don't agree as in most cases it's all about price/performance and technology being good enough - and x86 is good enough I don't see much memory failures in x86.
Hmmm ... iīm not sure if the M3000 is really a low end system. You have to take into consideration, that this system has the performace of roughly a 6-proc V1280. And that was a midrange server not so long a go used for larger ERP systems. Those customers have the same availability expectations for the M3000 as they had for the V1280.
But if I'm running a distributed app in a fail-over cloud then I'd prefer the cheapest server/memory combination because I'm fault tolerant. This holds true for Oracle's RAC for example.
I think it would be good to give the customer the choice - super-memory or market-memory. Don't you agree?
Oracle RAC is a bad example - the licensing and maintenance costs will dwarf the hardware.
This machine is not a like-for-like competitor for x86, and should not be compared to them. It is an enterprise server with RAS capability beyond the venerable E450 and E250, which should be still running in ten years' time. As a complement to the M4000/5000 and the CMT series it absolutely hits the sweet spot. I predict these machines will sell very, very well.
As Dustan stated before: RAC isnīt a good example. You pay over 40.000 for RAC per core just to ensure the availability of the database.
And i do not agree with you about the memory: If we put el-cheapo memory in the system and it fails, itīs Sun fault not the decision of the customer to use el-cheapo memory.
You may buy el-cheapo memory. SUN must not sell them, because there are a lot of shops, which sell memory for SUN servers.
SUN gives you the option to buy best quality memory. We had the opportunity to have a replacement memory producer near out site, so we used that memory, but it should be available at per mail order too.
Offtopic: Jörg, "actual" heißt "wirklich", "aktuell" heißt "current". Les ich öfter mal bei dir.
You've hit on one of my all-time favorite pressure points.
I understand that the quality control, etc., is remarkably rigorous, but can you tell me anything in the entire selection process (including the extended, torture-test burnin) that Kingston (for example) does not do to their server memory? And even though the selection of the pieces is this thorough, seriously, what's the margin on that stuff? When the commodity memory pieces cost (on average) 4x less, can you honestly tell me that the extraordinary cost increase is due purely to that selection process? I'm all about virtualization and consolidation, but until onboard system deduplication becomes a reality, this is the area where customers will complain first, especially when the barebones system costs 20k, and the memory for it is about 150k. Dear system vendors -- if you really want us to sell your hardware, make the price reasonably competitive with our other open-systems brethren.
I can tell that to you honestly. As a colleague told me "We would like to make them cheaper, but we canīt". The top quality memory chips are extremly expensive (sorry, but iīm not allowed to write exact numbers here).
Think alone about the sizes of banks in x86 and in SPARC. In some systems we use 8 modules interleaved and all have to have similar timings within a really narrow margin (e.g. you can buy 2-modules sets even for enthusiast pc). And this timing characteristics doesnīt have to change over time to ensure long-term stability and the possibility to exchange a single module without running into timing issues even after years. Itīs like with flying. The business- and first class ticket prices pay for the economy ultra cheap tickets (or the 19 Euro Tickets payed by the people needing a flight on short notice). The TFT-display purchaser pays for all the panels with too much defects. The cheap desktop cpus are payed by the high end server CPUs. The el-cheapo memory prices are payed by the companies buying ram chips for their server memory modules. Classic yield/price-management .... There are many obvious and not so obvious cost items associated at building long-time stable and extreme quality memory modules ...
Try as hard as one might, the days of the big iron are clearly at an end.
And it shows in both Sun's stock price and the sales numbers. People bought CMT systems because those were the cheapest SPARC systems available and offered an almost sane price/performance ratio (with lots of loving, and NOT out of the box). No matter how good, no matter how how high quality, no matter how RAS, it's really over. I used to love coming to work and working with big iron systems, but now, when I have to pay out of my own pocket, I'll be honest, I don't give a rat's ass about all that stuff. If I need RAS, I'll use the free operating systems out there, like Solaris, and the free clustering software, like Sun cluster, and be done with it! So what if the piece of crap, cheapo RAM in the i86pc server dies? Just take the whole damn server out of the rack, and through the window and into the container he goes! By the time even cheapo RAM dies, the whole system isn't even worth fixing any more, and the new system costs as much as the price of memory would! And since I have clusters, no downtime, ergo perfect RAS! It's over. Really, it is. Big iron is holding out in special shops. But most shops aren't special, they are run-'o'-the mill. That's why Sun is writing big bold red numbers. The company hasn't figured it out yet.
Not everybody has this "doesnīt matter when our central instance comes down" attitude ... and this is the reason why people still buy big iron. And you donīt have an idea, where the red numbers came from ...
What, you mean me? Surely you jest!
No siree Bob! I solve my RAS and redundancy problems with software - via clusters and grid engines, and well thought out architecture, not by throwing money out of the window for overpriced supercomputers! Trust me, I wasn't born yesterday. It's going to be hard to sell that overpriced supercomputer/mainframe iron when I can achieve the same level of high availability with clustering and grid engine on cheap-ass i86pc hardware. Generic hardware, not even Sun hardware!
When all you have is a hammer, all problems look like nails. Then all your problems look like nails, all you know is a hammer.
There are many workloads not grid-able. And not everybody can afford or want to afford the downtime of an cluster failover. Not every problem works with the web semantics of stateless shared nothing. |
+1The LKSF bookThe book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0Contact
Networking xing.com My photos Buttons![]() This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Germany License
![]() ![]() ![]() Blog AdministrationDonateOkay, okay ... as several people have asked for it ... but you know my opinion.
|