Re: Hot Swap iSeries applications

May be too late...

But I think "This technology just does not exist" is not correct.

IBM i does support clustering...but the key is that your application must
support it also. The term for this is "application resiliency". I'm not
sure if a 5250 application can be made resilient, but for instance
I'm pretty sure that SAP on the IBM i can be run in a clustered mode.

Take a look here
http://www.redbooks.ibm.com/redbooks/pdfs/sg247405.pdf
http://www.redbooks.ibm.com/redbooks/pdfs/sg247994.pdf



On Mon, Dec 22, 2014 at 5:52 PM, Graap, Kenneth <
Kenneth.Graap@xxxxxxxxxxxxx> wrote:

Thanx everyone for your input ...



Here is how I explained things to our CIO:


I have carefully researched the idea of configuring our iSeries servers
using direct attached clients (Telnet for example) so that in the event
that the primary server unexpectedly stopped functioning (crashed) all
processing would automatically be transferred over to the secondary system
without the end user ever knowing anything happened.

This technology just does not exist. It may exist in a load balanced web
environments, but not in server environments like we use for CIS and most
likely even SAP.

An example that was shared with me during my research was... Let's say
you directly attached to Windows Server A, you open up a CMD window and
type DIR C: and hit enter.

<CMD window picture showing a DIR C: command>
[cid:image001.png@01D01B7D.35E1D940]

While doing this, Server A crashes. I can't think of any scenario where
this window would remain open and the DIR C: command would automatically
continue running on Server B? This CMD window is unique to the server it
was opened on.

This is similar to having a Telnet Session connected to the iSeries.
Let's say it is connected to our Production iSeries server. An Interactive
Job has been started that defines how this session interacts with the
server. There are pieces of this job residing in RAM. Temporary job
structures such at Open Data Paths, memory pool allocation, etc. all being
maintained by the Operating System on the Production server.

These are not just database connections. These are job support functions
that define a job to the server before it ever accesses the database. This
"job" is unique to this server.

Now our Production iSeries server crashes. What are our options?

In our case, we are mirroring a set of disk attached to the Production
Server called an Independent Auxiliary Storage Pool (iASP). Another copy
of this storage pool is being maintained in "near real time" to another
server, our DR iSeries. These two servers are clustered together so if one
"disappears" a process could be started. This process is currently manual
but it could be automated through cluster commands. The process prepares
the copy of the iASP so it becomes the Primary copy and is made available
on the DR iSeries Server and an IP interface card is varied on with the
same IP address.

This is GREAT! We don't have to restore anything!

BUT ... It does take 20 - 45 minutes to attach the iASP and the direct
attached client jobs (TELNET) would have to be recreated on the DR Server.
In other words the user would have to sign in again. Also, any jobs
running in background (batch jobs) would have to be restarted too because
like interactive jobs, the OS maintains these job structures in RAM too.

We are journaling our data files and using commitment control so any
transaction that didn't finish prior to the crash will be backed out in
order to guarantee the integrity of the data. A minuscule amount of data
may need to be reentered too because the mirroring of data is being done
asynchronously due to the distance our DR location is from our source
system. Also any interrupted batch jobs will need to be restarted... but
this is so much better than having to wait while we reboot a system after a
crash or recover a whole system from tape at a DR site (which use to take
3-5 days)!

What we have configured is the best that is available today.




Reply or Forwarded mail from: Kenneth E Graap



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Thursday, December 18, 2014 4:05 AM
To: Midrange Systems Technical Discussion
Subject: Re: Hot Swap iSeries applications




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.