Completing the Pod
I've tentatively decided (more input would be welcome!) to use an APC NetShelter VX 42U Enclosure with APC Smart-UPS RT 3000VA RM and power distribution. Let's consider a client currently running its e-commerce operations on a Windows 2000 load-balanced cluster of 16 Dell 1650 machines.At a list price of $8,020 this rack includes a generator compatible UPS offering somewhat more than 4 hours of run-time during external power failures for all the gear in the box - including up to two T2000 processors and two paired sets of 8 to 14 disk JBODs. In other words an overkill power rack, but one that solves the housing, wiring, monitoring, and UPS problems in one shot. On the downside it does require a 208 volt input, but that's not such a big deal even if we will sometimes want to stick this thing into an otherwise unmodified office or warehouse environment.
I've also added two Linksys 10/100/1000 Model SR2024 24 port switchs at $479 each.
The router issue is unsettled. Talkback contributer Arnout Groen suggested an F5 Big IP (http://www.f5.com/products/bigip/)) but their website was so filled with marketing speak that I couldn't find a technical reason to consider the product.
Ideally this function should be filled by two routers from different manufacturers that can operate in a load balancing mode for failover but not fall to the same external attack - but that ideal may not achievable given the dampening effect Cisco's market dominance has had on both competition and innovation in this market.
Thus there are many pod applications where the router function could be handled by nothing more than a pair of Linksys or Netgear xDSL routers at less than $200 each -and very little to be gained from more expensive gear until you get to stuff like 3com's 5680 (3C13758) dual T3 routers. These are nice -despite the fact that the software does lots of stuff I don't want done- but cost $5,150 each.
Bottom line: in the real world I'd probably call Avaya and sell the extra cost as setting up for an eventual transfer of the organizational telecom budget to IT - but in the blogging world it should be obvious that I just don't know enough and need help.
However, with two of the 3Coms the total pod cost before processor and storage comes to about $19,500. That's a lot, but everything except the casing is redundant and we're ready to run just about any network for more than four hours after an external power failure.
As a result the price range, at list, for the completed pod with three years of prepaid, two hour on-site, support runs from about $28,000 with a single four core, 8GB, processor and four 73GB internal disks to about $112,000 for a unit with dual 1.2Ghz, 32GB, T2000 processors and dual 1144GB (net 570GB) FC JBODS.
Applying the Pod
With that in mind lets consider an imaginary but quite representative client currently running its e-commerce operations on a Windows 2000 load balanced cluster of 16 Dell 1650 machines. These started out, when the system was first installed in 2002, as dual 1.4Ghz Pentiums but were upgraded to 2.4Ghz in 2004. Today they're facing pressure to refresh the hardware and upgrade from Windows 2000.
Their volume data suggests that the average browser session lasts a bit over six minutes, requires that the system serves an average of two static and eleven generated pages to each user, that the high water mark on concurrent active sessions is approaching 6,000, that around 14% of tire kickers run a shopping cart, and that a bit less than one quarter of one percent of sessions lead to a purchase during that same session.
Doubling everything, this means we need to configure for about 12,000 concurrent browser sessions and about 100 completed transactions per minute.
The nearest thing to a third party benchmark we have for this kind of thing is probably SpecWeb 2005. This provides a measure of concurrent sessions with a heavily interactive workload and timing constraints. Unfortunately there are two big problems: first there there are no recorded Wintel results against which to compare their alternatives; and, secondly, we've no good means of comparing benchmark complexity against what's needed here.
It's that second question that's really interesting. We know what the existing system does - what we don't know is what it really should do. The reason for that is simple: the company has an eight year history with e-commerce, but it hasn't been central to the business and the continual daily presures of keeping IT going have created barriers, both within IT and among user management, to considering any changes.
As a result, the system today is pretty much what it started out to be in 1998 and the most striking thing about it is what they don't know. For example, they don't know if faster page loads would result in more customer completions; they don't know whether switching to an encrypted mode server when the customer first accesses a shopping cart would result in more sales than the present process in which they switch to encrypted communication only for the cash transaction itself; and, they have never explored the extent to which, if at all, their own processing resources can substitute for on-line charge authorization by their card processor - by, for example, trusting repeat customers enough to collect and batch relevant transactions directly to the issuers involved.
Similarly, they know that most of their dollar volume represents repeat business but they've never considered the option of going to a portal format to facilitate communication between customers. More interestingly ideas like using the e-commerce site to guarantee stock in the store nearest the customer have never even been raised, let alone explored.
As a result the current hardware/software change opportunity is as much about setting a foundation for future change, or future stability if they merely update what they have in place, as it is about processing cost, performance, and reliability.
In response we need to establish, and later sell to the customer, two quite distinct goals for our proposed solution:
- it has to achieve and maintain stability right out of the box; and,
- it has to provide a low risk means of experimentation.
To do it the suggested pod configuration relies on an all Sun, all Java, software load. That gives us access to a supported identity management solution, a widely used and supported e-commerce infrastructure and development system, and Sun's Java system portal server for later experimentation.
Sizing is a problem: disk requirements are relatively minor but we don't really understand the transaction burden. On the SpecWeb2005 benchmark the Niagara T2000 runs around 14,000 sessions using this same software but the transaction mix there is much more complex and dynamic than what we're facing here.
In a real world case like this the right answer is simply to try it - and then size the machine according to its actual operation with the customer's workload. My guess is that a single 1.2Ghz, 16GB T2000 would handle this with ease and that the "right" configuration for our pod would therefore consists of two mid range 16GB, 1Ghz servers at about $18,000 each inclusive of four 73GB internal disks. That way one could handle page services and analysis, the other would do database and transactions work, and you'd have capacity for failover and continued operation, although at reduced service rates, if a hardware failure occurred.
By way of comparison a four core, 2.8Ghz, Dell 2850 LAMP solution using Suse Linux with Apache/Tomcat maxed out at 4,880 sessions on the SpecWeb2005 benchmark. To meet future needs, therefore, they'll need to upgrade to four Dell 2850s, each with two dual core (shared socket) 2.8Ghz Xeons, 8GB of RAM, and a price tag of $14,449. Note that the memory requirement rules out Windows Web edition, requiring a matching upgrade Windows/XP 2003 Server x64 Enterprise edition and Microsoft SQL Server 2005X64 Standard at another $12,000.
Thus the basic cost of the upgrade in place would come to about $70,000 - without the rack, UPS, or network gear, much of which, of course, they could hope to salvage from the existing implementation.
Since our completed pod comes in at about $58,000 it would seem to be cheaper as well as much more of a tightly integrated all-in-one solution.
However, it's all the stuff the customer doesn't know that will determine whether doing anything different here makes sense - and that's what I want to talk about tomorrow.