In my thinking, a lot depends upon how well the target server/tributary/consolidator workflow software can multithread in that loosely-coupled framework.
Note that I'm *not* particularly knowledgable, all right? But I'm tossing out my opinions anyway, perhaps I'll get some laughs. A mainframe's CPU power, IMHO (I'm not a zSeries guy, so my opinion comes from Appendix A of the now-ancient "Linux for the S/390" redbook; most of my _real_ mainframe experience is on ancient Sperry 1100/80s and the like) is a compromise between single-thread performance and reliability, so, really, a zSeries with a plethora of CPs may *not* be the best way to do some of the work... though the I/O bandwidth and I/O connectivity may make BFI (Big Iron) a good partner for the smaller boxes, especially for tasks that have to be single-threaded (like row insertions into a database). It really *DOES* depend upon the kind of workload. If you need reliable single-thread performance with non-stop and hot serviceability, then, yeah, a farm of zBoxes would likely be a good start, but, really, since google is NOT a critical application that requires ultimate reliability (IOW the end users will drive any retries) this one "compromise" in CPU throughput for reliability is not as necessary, so throwing money at the switch infrastructure would likely pay off. The nice thing about using cheap "trailing edge" technology for such a farm is that, whilst running Linux, the machines are doing a competent job, able to intercommunicate, and must have the ability to deploy and go live in a very short period of time. (I'd love to see how they manage replacement of a server and how they provision it.) Best of all, you upgrade your equipment incrementally, so, in effect, with the right software, it scales in fairly small increments. Granted, almost all of TCO is in labor rather than capital equipment, so... Heck, I figure a tech refresh can be done a little bit at a time w/o any perceptible impact, just like painting a bridge. As soon as you get to the far end of the farm you're ready to start over at the near end... With a good switch infrastructure and algorithms suited to multithreading in a loosely coupled infrastructure... and with the application specialization that the servers *must* have... Of course google also must come up against the "expense" of operating *any* database, especially w/ the spiders, given the sheer quantity of row insertions they have to do. Right there that must hammer the database engines almost flat... especially since that's a single-thread operation. Needless to say, it'd be entertaining to see how they handle some of the "regular" operations within their farms. Of course, using "disposable" servers, perhaps it'd be difficult to deal with a TCO where they are looking at labor costs, and the costs to toss a server and slap a new one in its place, plug it in, and hit the power button, must be pretty low. The reason we've evolved a "disposable" economy, I am told, came about during the Second World War, where it was discovered that tossing a "bad part" was cheaper than trying to fix it in the field-- and, sometimes, it was cheaper to melt the damn thing down and make a new one from scratch on an assembly line rather than dealing w/ P/D and then repairing it where the economy of scale can't play a part. (sighs) I gotta stop wearing my "Stand Up Philosopher" hat... -------------------- John R. Campbell, Speaker to Machines (GNUrd) (813) 356-5322 (t/l 697) Adsumo ergo raptus sum MacOS X: Because making Unix user-friendly was easier than debugging Windows. Red Hat Certified Engineer (#803004680310286) IBM Certified: IBM AIX 4.3 System Administration, System Support http://packrat.tpausf.usfl.ibm.com/~soupjrc/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
