1. Server Upgrade HA/DR Integration
Presented by:
Tony Barnes
&
Arash K. Ardestani
April-May
2014

2. Intoructions
Add Into information here

3. About this session
The goal of this session is to give the LIS administrators an over view of the LIS systems that reside under HA cluster support. In the following slides we will review the general elements of each cluster and how they interact with each other. We will also look at some of risks and limitations of the cluster and how to minimize the impact of those risks and limitations.

4. Resources of Cluster - Dedicated
A Typical SCC cluster consists of two AIX hosts AKA nodes.
By default each node has a few resources for itself:
Its own network port/adapter – dedicated ports
Its own permanent IP address – AKA persistent address
Its own AIX operating system
Its own dedicated disks and devices such as Tape, CD, etc…

5. Resources of Cluster - Shared
Based on the purpose of the cluster the two nodes share sets of resources – meaning they both can see them simultaneously:
Multiple sets of disks drives – Shared storage
Note: A special disk is used as a communication interfaces among nodes
Multiple sets of IP addresses – Service IP addresses
Set of policies that define and govern the roles and responsibilities of the nodes within the cluster

7. Resource Groups & Policies
A collection of resources of a node (IP, Disk, devices) and their responsibilities
Example: Data volumes, filesystems, scripts, printing, etc…
Policy:
A set of rules & regulations that exactly define the behavior of a resource group
Policies are broken down into two major sets:
Events:
An event is a set of conditions that result in a particular set of actions
Actions:
A set of one or more procedures that are performed based on a particular set of events

8. Resource Groups & Policies
Computer Repair Department (Software tech, hardware tech, manager)
Policy:
Find and fix problems with computers
Events:
If a problem is found on a computer – determine if HW or SW problem
Actions:
Manager makes a ticket and sends it to proper tech for evaluation and repair

10. Resource Group: Policy: MAIN Application Functions
AUX Application Functions
Policy:
MAIN node starts, runs, and controls the MAIN application functions
AUX node starts, runs, and controls the AUX application functions
MAIN ask for health of AUX and AUX ask for health of MAIN
Events:
If MAIN does not get a response from AUX within 60 seconds
Actions:
Then MAIN take over AUX – Start, run, and control those function of AUX node

12. Policy:
MAIN node starts, runs, and controls the MAIN application functions
AUX node starts, runs, and controls the AUX application functions
MAIN ask for health of AUX and AUX ask for health of MAIN
Events:
If AUX does not get a response from MAIN within 60 seconds
Actions:
Then AUX take over MAIN – Start, run, and control those function of MAIN node

14. Important Considerations
A cluster solution does not translate to 100% uptime for users
The goal is to minimize the downtime and the manual efforts to recover from
single points of failure.
As with any technology a cluster needs to be maintained and tested.
The initial design and implementation of a solution sets the tone for later
Understand the purpose of the cluster and adjust your expectations
Have redundancy for everything you possibly can – have backup plan
A cluster is as robust as the infrastructure it is running on!!!

15. Limitations of Cluster
A cluster cannot undo or correct a human mistake
The proper resources must exist to build the cluster on top
There are conditions that cause the cluster to break
A broken system with cluster is much hard to fix
There is still a short downtime when a failover event occurs
There are some applications that do not play well with cluster

16. Beyond HA Cluster
More often now we have a big question on the table:
What happens if all nodes of the cluster are not available or able to work?
This simply translates to complete downtime and cluster cannot do anything to help you!!!
So what can you do to protect yourself against such disaster?
The answer is simply “Have a disaster recovery solution”

17. Types of Disaster Recovery
Cold DR:
A set of servers are secured for the critical applications. The cold DR solution is never read to be used. It is an empty shell waiting to be installed when a disaster is declared.
Method of recovery: Usually from backup tapes or backup server
Warm DR:
A set of servers are secured, installed, and maintained ready to be used when a disaster is declared.
Method of recovery: Usually direct data replication in real time

18. Warm or Cold?
With the cost of hardware steadily and rapidly declining, more than ever organizations are interested in a disaster recovery solution. Ultimately the decision of which DR solution is the right one for you comes from the two important factors: RTO : Recovery Time Objective In simple terms RTO determines how long it will take to have a working system Simply DOWNTIME! RPO : Recovery Point Objective How close to 100% is the data that you will recover and have to work with Simply Data Loss! Here is a chart from an expert….

20. How to find RTO/RPO?
Figure out what it will cost when you lose LIS system for 1 hour
Figure out how long can you be without the LAB system and still survive
Figure out how much data can you lose and still survive
Know the limitations of applications that you are using
Know the limitations of the infrastructure that you have in place
Know the limitations of the staff and other dependents departments

21. What we offer…
Over the past few years we have designed and tested quite a few different
DR solutions that fit the needs of most of our clients still within affordable rate.
The design is based on these elements:
Add a third system in the DR data center
Repeat system profiles from MAIN/AUX on DR
SAN-2-SAN replication from MAIN/AUX to DR
Use DNS to connect all the LAB devices to LIS systems