RE: High Availability Options
- From: Michael Dinh <mdinh@xxxxxxxxx>
- To: "'david.robillard@xxxxxxxxx'" <david.robillard@xxxxxxxxx>
- Date: Mon, 25 Oct 2010 10:58:17 -0700
I am going to pitch to management VCS with CFS as a the first solution because
with already have VCS in place with Solaris Containers.
Alternatively, deploying Oracle RAC inside Oracle Solaris Containers is the
next available solution.
Then there's also Oracle RAC on Oracle VM Server for SPARC as last alternative.
http://mdinh.wordpress.com/2010/10/18/oracle-rac-on-oracle-vm-server-for-sparc/
References all those who are interested and thanks for your contribution.
Veritas CFS Proves that Fast Failover Minus High Costs, Complexity and
Uncertainty is Attainable
By Jerome M. Wendt on June 8, 2010
http://symantec.dciginc.com/2010/06/veritas-cfs-proves-fast-failover-attainable.html
To RAC or Not to RAC? Veritas Cluster File System Responds "No RAC Needed"
By Jerome M. Wendt on June 17, 2010
http://symantec.dciginc.com/2010/06/to-rac-or-not-to-rac-cfs.html
Best practices for deploying Oracle RAC inside Oracle Solaris Containers
An Oracle White Paper September 2010
http://www.oracle.com/technetwork/articles/systems-hardware-architecture/deploying-rac-in-containers-168438.pdf
Implementing the Right High Availability and Disaster Recovery Plan for Your
Business
Date: August 2010 Author: Mark Peters, Senior Analyst
http://eval.symantec.com/mktginfo/enterprise/white_papers/b-esg_brief_implementing_the_right_ha_and_disaster_recovery_plan_WP.en-us.pdf
Veritas Storage Foundation Cluster File System
http://www.symantec.com/business/storage-foundation-cluster-file-system
Oracle Maximum Availability Architecture - MAA
http://www.oracle.com/goto/maa
Michael Dinh
NOTICE OF CONFIDENTIALITY - This material is intended for the use of the
individual or entity to which it is addressed, and may contain information that
is privileged, confidential and exempt from disclosure under applicable laws.
BE FURTHER ADVISED THAT THIS EMAIL MAY CONTAIN PROTECTED HEALTH INFORMATION
(PHI). BY ACCEPTING THIS MESSAGE, YOU ACKNOWLEDGE THE FOREGOING, AND AGREE AS
FOLLOWS: YOU AGREE TO NOT DISCLOSE TO ANY THIRD PARTY ANY PHI CONTAINED HEREIN,
EXCEPT AS EXPRESSLY PERMITTED AND ONLY TO THE EXTENT NECESSARY TO PERFORM YOUR
OBLIGATIONS RELATING TO THE RECEIPT OF THIS MESSAGE. If the reader of this
email (and attachments) is not the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited. Please notify the sender of the error and delete the
e-mail you received. Thank you.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of David Robillard
Sent: Sunday, October 24, 2010 11:08 AM
To: Michael Dinh
Cc: oracle-l mailing list; John Thompson
Subject: Re: High Availability Options
Hello Michael,
> On Wed, Oct 20, 2010 at 12:12 PM, Michael Dinh <mdinh@xxxxxxxxx> wrote:
> I am curious as to what options are available for HA and what you are using.
>
> I have the following list:
>
> Veritas Cluster Server
> Oracle RAC
I've used both products and several other clustering technologies in
the past. I prefer Oracle Clusterware (CRS) + Oracle Automatic Storage
Management (ASM) over Veritas Cluster Server (VCS) + Veritas Volume
Manager (VxVM).
Was it because it was on old versions of VCS and VxVM? Maybe. It was
back in 2001 on a simple two-node cluster running on Solaris 9 SPARC
on Sun Enterprise 450 machines. The storage was provided several
bricks of StorageTek T3 units (they're horrible, just horrible) all
connected by a pair of Brocade switches. It was rather fragile and we
did experience problems with VCS (not to mention the T3s).
I've also worked with Sun Cluster 3 + Solaris Disk Suite (i.e. Sun
Volume Manger) on Solaris 9 SPARC in 2004 on several Sun Fire E25K
domains with storage on EMC Symmetrix DMX connected by McData
directors. That setup was very solid. But with that kind of very
expensive equipement, one would assume that since it comes with very
long architecture, setup, testing and QA phases (not to mention all
the politics involved!) before it's rolled out to production.
Now I've just started (~6 months) working on a two-node cluster with
CRS + ASM 11gR2 on RedHat Linux 5 x86 64 bit running on Sun X4170
machines with storage provided by a clustered Sun Unified 7410 unit
connected by iSCSI over a pair of stacked Cisco 3750 dedicated to the
iSCSI traffic. It's still in the testing phase right now, so only time
will tell if we hit some major road blocks.
So, which is better? As always, it depends.
On the volume manager side, IMHO, ASM is quite a lot easier and faster
to implement and manage than VxVM. If you're familiar with Sun Volume
Manger (or Disk Suite) ASM is as easy. Plus it's stable, well
documented, has been designed from the ground up to work with Oracle
databases and is well supported by Oracle (no chance of finger
pointing between Oracle and Symantec). You do have a little learning
curve of course, but nothing scary, especially since you have so many
tools to manage it (i.e. asmcmd, sqlplus, EM and ASMCA). Should you
decide to use ASM, I strongly suggest to stay away from ASMLib and use
udev instead.
On the cluster software side, CRS is a piece of cake to setup,
especially if you have prior clustering experience. It has the same
advantages as ASM. Stable, supported, documented and no finger
pointing.
But as John Thompson already said in this thread, it does take wide
range of skill sets to implement and manage any clustered solutions
(UNIX admin, network admin, storage admin and DBA). So if you don't
have them all, make sure you have good friends around and good
communication between the required teams.
Most important I think: leverage what you already know. If your team
has been working with Solaris and fibre channel, then don't move to
RedHat on iSCSI for example.
> VMware VMotion
Do not confuse VMware vMotion [1] with VMware HA [2].
VMware vMotion is used to *manually* migrate VM from one ESX host to
another while the VM is running. It is *not* an HA solution in the
sense that if one ESX host fails, the VM running on that ESX host will
experience down time. You should see vMotion as a tool to help system
administrators manually manage the load on the ESX hosts and perform
hardware maintenance during normal business hours. It's a complement
to the HA solution.
VMware's HA solution is called, well, VMware HA :)
Personally, I wouldn't use ESX as my production platform for Oracle
databases. YMMV.
> Ideally, we want to stick with Solaris.
I believe Solaris on SPARC is a tier one platform for Oracle
databases. Plus Solaris is now owned by Oracle, so it makes perfect
sense to keep it especially if your team is already comfortable with
it. But I don't think Solaris x86 is a tier one platform for Oracle
databases. That means software releases, patches, community and
overall support is not as good. I wouldn't use it for Oracle databases
until (if ever?) it becomes a tier one platform.
HTH,
[1] http://www.vmware.com/products/vmotion/
[2] http://www.vmware.com/products/high-availability/
Good luck and have fun,
David
--
http://ca.linkedin.com/in/davidrobillard
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
