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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].