RE: iSeries TCO v NT server farm

>And of course if you're upgrading that setup, you need to have 
>TWO backup machines so that you're still HA. 

If you want to have HA while you are upgrading, then yes, but on iSeries
this is no different. If you want HA while you're upgrading one of your
iSeries boxes you need 3 boxes. With extremely rare exceptions the risk
analysis will result in just two boxes with the understanding that when
I take one box offline I'm exposed -- again, this is no different than
iSeries.  

>And if these are web applications, you have to get Enterprise edition.

NO! You are confusing Per Processor licensing and Enterprise Edition. In
all but the most simple apps you want the Per Processor license for SQL
Server, yes. Without it you need to license each remote machine -- with
it, you can connect as many machines as you want. But that's _not_ the
same as Enterprise Edition. EE buys you access to up to 64Gig of memory
(or 512Gig w/64-bit), access to 32 processors in a machine (64 w/64bit),
etc. But you can run with standard just fine -- and standard costs
~4500.

>Especially in Walden's mythical model where each application is
self-contained 
>on a single box.  Because that means each box has its own copy of SQL
Server 
>(which is doubled for HA).  So if you have, say, 10 little HA
applications, then 
>you're talking 20 servers, 2 upgrade servers, and maybe $800K PER
YEAR... just 
>for database access.

I like my mythos! But you're all messed up here. First, why are you
insisting on putting each application on a separate machine? Are you
saying that Order Entry needs one machine, AP another, GL another,
warehouse management yet another? Yikes? Who sold you that line of bull.
The only reason you'd need to move onto multiple machines is for
performance -- and it takes a lot to kill a machine. Second, no, my
model do NOT assume that each app is self-contained on a box. Perhaps a
picture is in order here. Hmmmm... ASCII art...

Ignoring fault-tollerance for a moment, conceptually we're looking at:

 +-------+                +----------+
 |Web Svr| <--Network-->  |SQL Server|
 +-------+                +----------+

With me so far? OK, in this model, again ignoring fault tollerance, you
can load many "applications" on the web server, and they can talk to
one, or many databases on the SQLServer (a database is SQL-speak is
roughlt the same thing as a library on the iSeries.) Want, Finance,
Warehouse, Sales/OE, call center, and CRM on that one web server, no
problem! In this model I'd need two servers (I guess I could use one,
but let's go with two) a copy of Windows 2003 Web edition (~$500), a
copy of Windows 2003 Standard (~800) and a copy of SQL Server w/a
processor license (~4500) so we're looking at $5000 in software plus two
boxes -- go visit www.dell.com to price out the hardware. And all the
data can be on that one SQL server -- again, no problem. 

OK, but this thread is about fault tollerance, so let's address that.
Let's address it in two parts. The first is the web server side. There's
no reason you can't load those applications on two web servers, call
them A and B, and have both web servers service the enterprise. 

 +-------+                 |
 | Web A | <--Ethernet---> |               +----------+
 |+-------+                | <--Network--> |SQL Server|
 +| Web B | <--Ethernet--> |               +----------+
  +-------+                |

OK, in this setup, either of the two web servers could fail, and your
users would NEVER KNOW! The other web server would pick up the slack.
This is one of the few nice things about the statelessness of HTTP.
Granted, session state would need to be shared between both servers, but
I've done this in .NET, and I'm sure it's possible in Java. Now, this
adds $500 for the second license of Windows, and the cost of a second
server. However, the servers might each be a little less expensive now
since you can spread the load across two. Granted, a single server needs
to be able to handle the total workload in case of a failer, but it's
probably acceptable to have decreased performance in the case of a
server failure. 

Now, on to SQLServer. Obviously we need a picture like this

 +-------+                 |                 +------------+
 | Web A | <--Ethernet---> | <--Network----> |SQL Server 1|
 |+-------+                |                +------------+| 
 +| Web B | <--Ethernet--> | <--Network---> |SQL Server 2|+
  +-------+                |                +------------+  

Now, we've added cost again, yes, another $4500 for the second sql
server license, $800 for windows and the cost of a second server, and we
need to replicate data between the two systems. 

How do we do that and what does that cost? Well, that's a big question,
and it really comes down to how much downtime are you willing to accept,
if any. If you want the same level of HA you'd get with an iSeries
solution then you can either roll your own log shipping (just like
rolling your own remote journaling solution) or if you like your hair,
you can buy a simple solution, like the neverfail solution -- aroud 5K
if I recall correctly. Now, in this situation there would be a small
outage while the second server came online on a server failure. But this
is no different than any of the iSeries HA solutions, I don't know of
any that will preserve my green-screen application in mid-transaction on
a failover.

If you want to spend more, you can look at something like Marathon's
Ftvirtual server which makes the two sql server machine look like a
single machine to the network and results in zero downtime on failover
-- that is, no loss of contivity, even for a second, and no loss of
in-transaction applications.

So, while you'd like us to believe we're spending 800,000 per year, it's
truly a fraction of that. You're looking at 4 servers, and two copies of
sqlserver standard, so that's something like 16,000 to 30,000 depending
on your level of failover risk, and that's over the life of the system,
not per year -- unless of course, you're buying new hardware and
software every year. Do you buy a new iSeries every year?

Now, before you reply with something like "bet you need more that two
servers for performance reasons" or "but you need super big servers, not
small ones" I'll say this, you may indeed -- then again you may not. And
it's not really possible for us to debate that without knowing specific
details and specific requirements of specific applications. 

Hopefully I've cleared up a thing or two about my mythical world. <G>

-Walden

------------
Walden H Leverich III
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
 Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)