Hmmm, I'm not sure the arguments stand up. HotMail and Google operate such data centres using commodity components and make a point of ensuring that can all be done with a minimum number of system administrators.
Google have actually published on this topic (ACM Queue) and name heat vs CPU cycles as a number one consideration which they believe is best solved by the likes of Niagara. The reasoning for this includes density of CPU packing versus space and power consumed. They also expect to have components fail and just swap them out as and when leaving their software to work around the failure in the meantime. And Google aren't the only people that see this as the guys over at Ning have also been concerned with the heat issues (see Jonathan Schwartz's weblog). I'd also note that the below concentrates on achieving resilience at hardware level and talks very little about what goes on in the software layers, nor does it talk about maintaining persistent state and/or scaling that. Many a website is achieving scale and resilience using a smart caching layer on top of commodity boxes with a simple 2-node cluster for the database. In fact there are several commercial software products out there vying for this sector along with the financial and other high-load/demand sectors. I'm dubious re: the N+1 machines argument too - I'm going to need N machines to handle my load anyway and if each box costs me less than $2K having a single extra machine for each pool isn't hurting me that much. In fact of course, I'd have a couple of spare machines per pool. I might even share some of those machines across pools because I'll have done some failure analysis and figured how many simultaneous failures I want to tolerate and where it's gonna have most impact. The one more box argument is also dubious - let's say I have a big SMP box that now has no spare CPU slots and my load increases - what do I do now? I have no space, I'll be buying another box. Is the SMP box with all it's CPU's, cooling etc any smaller than an equivalent bunch of blades? SMP boxes are good for certain kinds of workload but they are a poor investment for other kinds of load in terms of the acceleration they give you versus the cost of all the CPU's. I can't be sure but the stuff described below sounds like SMP with a slightly better bus - not sure that's gonna cut it. Figure they'll have a niche but I don't think it's world-domination, paradigm shifting stuff. Most times, custom hardware gets beat out by generic hardware with smarter software. Coincidentally, Schwartz is on about that stuff on his blog right now. Dan. Gervas Douglas wrote: > << With the increasingly common use of distributed software components > in service-oriented architectures (SOA), it has become essential that > the underlying hardware for such applications have a high degree of > redundancy. The reason for this is simple: if a hardware platform > hosting a critical service fails, the entire enterprise application > may be severely degraded, or even fail completely. Currently, the best > way to avoid this problem is to implement at least two redundant > servers, each running a separate instance of a software service. > Depending upon the criticality of the service, more than two copies > may need to be running. > > Further complicating the situation is the issue of component > isolation. Real-world experience with SOA-based applications has > proven that while failed hardware will cause components to stop > working, the converse is also true. Sometimes software components > behave badly and effectively render the hardware useless. We have all > seen hung networks and pegged CPUs that were eventually traced to a > misbehaving software component. When applications are truly > business-critical it is often wise to isolate services onto their own > hardware. > > Finally, transaction volumes and total system loads must be taken into > consideration. The larger the expected loads, the more primary and > backup hardware that is needed. Designing software services that run > in an active-active, load-balancing configuration on separate servers > gives us a way to make the "backup" servers help with handling larger > system loads. > > There is a hidden danger in this strategy. If the periodic "high > watermark" load presented to the application needs both servers to > maintain acceptable performance levels or response times, then we have > effectively lost redundancy. This leads to the common strategy of > using N+1 servers for each component—N servers to handle the > high-watermark load and one additional server to provide coverage for > a failure of a server in the "N" pool. > > The bottom-line: Implementing redundant, isolated hardware in > sufficient quantity to cover expected system loads can require a lot > of hardware. A typical enterprise data center is proof—rows of 1U, 2U, > and 4U servers neatly tucked into 7- or 9-foot racks. > > Fortunately, all of these commodity servers are inexpensive—aren't they? > > Individually, commodity hardware servers are reasonably inexpensive. > Adding "one more box" to the enterprise data center, though, involves > finding rack space, consideration of power and cooling capacity of the > center, adding copper and/or optical data cabling, and adding a KVM > port. It further involves provisioning the server with appropriate OS > and application software loads, and also generally requires adding a > software management agent to the server to enable the server to be > monitored from an enterprise systems management console. The ongoing > care and feeding of a few dozen servers can stress one systems > administrator. What happens when the data center houses hundreds or > thousands of servers?>> > > You can read this at: > > http://www.adtmag.com/article.aspx?id=18852 > > Gervas > > > > > > > > > > Yahoo! Groups Links > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Check out the new improvements in Yahoo! Groups email. http://us.click.yahoo.com/6pRQfA/fOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
