3. In a robust environment where we're talking about of 10,000 or more
logged in users of a business system, e-commerce, and the like, you start
getting into a server farm of iseries.
Maybe my customers are different, or I haven't asked them *exactly* what
they user their different boxes for, but I just don't think an iSeries
server farm would be necessary. This is yet another advantage of an iSeries
in that you can expand your hardware by either adding RAM/DASD to an
existing machine or just upgrade machines - no need for a server farm to
facilitate thousands of users. I would even go as far to say (and sys
admins correct me if I am wrong), but we have "virtualized" server farms
*inside a single iSeries by nature of the way the OS was written. I can
split up hardware to be allocated to specific duties and give priorities of
execution to different jobs all the way down to how big of a timeslice a job
should get once it's turn comes in the round-robin processing execution
scenario.
A database server has to have the state stored in it, and you have to get
to the right database server, unless you can keep multiple database servers
synched in real time. Which we need to do anyway for high availability, but
there's a differnce between high availability synching for failover and
keeping multiple production systems in synch, such as two or n way synching
between the databases to start with instead of one way to the high
availability backup server.
I still get the feeling this approach is designing a system based on how a
Windows sys admin would approach the situation. Many iSeries shops take the
two machine approach - one for the actively running jobs and one for
hot-swap-failover in case the main one goes down. Eliminates a bunch of
complexity because then you don't need to be concerned about the things you
brought up. Again, let's use the strengths of the iSeries.
Aaron Bartell
http://mowyourlawn.com
midrange.com
