Oracle VM 3.1 Disaster Recovery (HA)

On this scenario we will talk about how to implement HA (High Availability) for OVM 3.1 between a Primary Site (Production) and a Secondary Site (DR) located at 800 km away. On this post we will only talk about the storage replication part and how to make it work when a failover is required (I will not cover the Database replication side (Using Data Guard).

clip_image002

Please note that the Oracle VM Manager should be installed on both sites with the same UUID using the “./runInstaller.sh –uuid <uuid>” command. The UUID for the Oracle VM manager could be found in the configuration file of the OVM manager.

$ cat /u01/app/oracle/ovm-manager-3/.config | grep -i uuid

 

The Preparation

1) Identify the source LUN in the production OVM Manager we want to HUR to the DR site. (360060e8005449c000000449c00004606)

clip_image004

2) Present the LUN to the DR site.

Also specify the HUR source LUN (360060e8005449c000000449c00004606) and HUR target LUN (You will get the LUN ID from the SAN Engineers when they present the LUN to the DR site).

Ask the San Engineers to activate the HUR process.

 

The Failover

In the event of a primary site failure, DR procedures will be kicked off as shown below.

clip_image006

1) Production site is down, the storage replication synchronization between the production site and the DR site would have to be stopped.

2) Since these are block devices, there will be an OCFS2 filesystem on the devices. You will not be able to present the replicated repositories to the OVM servers at the DR site because of the cluster ID tamped into the repositories. This will cause mounting of the OCFS2 filesystems at the DR site to fail.

“mount.ocfs2: Cluster name is invalid while trying to join the group”

3) Find the former cluster ID stamped on the replicated repository.

We know what the target LUN ID should be (When the SAN Engineers presented the LUN to the DR site) eg 360060e8005458e000000458e00004075

clip_image008

Find the former cluster ID stamped on the replicated repository. (360060e8005458e000000458e00004075)

clip_image010

Cluster ID = 16a67562c33aa4fe

clip_image012

clip_image014

4) Find the new OCFS2 cluster ID at DR site.

clip_image016

5) Change the clusterID of the replicated repository (360060e8005458e000000458e00004075)

$ tunefs.ocfs2 –update-cluster-stack /dev/sde (360060e8005458e000000458e00004075)

clip_image018

Run fsck.ocfs2 /dev/sde

clip_image020

Y to continue.

clip_image022

Y

clip_image024

6) Check that cluster ID is already updated.

clip_image026

7) Repositories before refresh ( service ovmm stop / start)

clip_image028

8) After repositories refresh ( service ovmm stop / start)

Log onto DR OVM Manager. (console)

clip_image030

clip_image032

9) You should now see a VM under the unassigned Virtual Machines tag.

clip_image034

10) Edit VM and replace network adapter.

clip_image036

11) Migrate VM to a host.

clip_image037

12) Start VM.

13) Configure MAC address and ip address. (VM OS)

Edit /etc/sysconfig/network-scripts/ifcfg-eth0

clip_image038

Get new MAC address from DR OVM Manager.

clip_image040

Update /etc/sysconfig/network-scripts/ifcfg-eth0 with the new MAC address.

clip_image041

14) Service network restart.

Regards,

Francisco Munoz Alvarez

About these ads

Oracle ACE Director and President of LAOUC, NZOUG and CLOUG. Organizer of LA and APAC OTN Tours,

Posted in Cloud, General, OVM, Virtualization

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: