Hi all,
I'm in the early stages of designing a highly available Oracle Database cluster. The plan is to have a Solaris SPARC S7 server at each of two physical sites. Although these sites are physically separate, they are fairly close together and connected by redundant 40 GBps private network links and can therefore be considered part of the same LAN. We also have clustered SAN storage available to us, meaning that the same LUNs/volumes can be seen (using iSCSI) by servers at either site, but due to problems with outages when patching said storage, I am now looking to avoid using this and have each of the S7 servers use its own local disk storage. What I would like to achieve is:
- Run our Oracle databases with high availability and DR, so that if one site fails, the service can fail over to the other site
- Use local disk storage if possible, rather than SAN storage
- Automate the failover when failures are detected without manual intervention.
- Keep the cost down as much as possible. Although we have money available to buy hardware and software licensing, this isn't infinite so I'm looking to avoid paying for elaborate software licensing any more than I have to. There are a few constants that cannot change, namely our Oracle database licensing. This is because we have previously invested heavily in perpetual CPU-based licences for both Oracle DB and Active Data Guard. I therefore need a solution that will make use of these and not cost us anything additional in terms of licensing for them.
Before explaining anything further I should perhaps get directly to my question which is: "Can Oracle Solaris Cluster be installed INSIDE a [kernel] zone, or does it need to be installed directly on the physical host?"
The S7 chips contain many more cores than we have licences for, so I want [need?] to use Solaris zones to run our Oracle databases in, because zones are a recognised way to cap CPU core usage in accordance with Oracle's partitioning policy which states:
"Approved hard partitioning technologies include: Physical Domains (also known as PDomains, Dynamic Domains, or Dynamic System Domains), Solaris Zones (also known as Solaris Containers, capped Zones/Containers only)"
This is how we are restricting core usage on our current SPARC servers in order to comply with our Oracle licensing. We run the databases in kernel zones and they work very well (we've had better experience with kernel zones than non-kernel zones).
For 1) above, I believe we will need some flavour of Oracle Solaris Cluster to replicate the data between the two servers. I found this document on host-based data replication which seems as though it will satisfy requirement 2 above. It states:
"Host-based data replication uses software to replicate disk volumes between geographically dispersed clusters in real time. Remote mirror replication enables data from the master volume of the primary cluster to be replicated to the master volume of the geographically dispersed secondary cluster. A remote mirror bitmap tracks differences between the master volume on the primary disk and the master volume on the secondary disk. An example of host-based replication software used for replication between clusters, or between a cluster and a host that is not in a cluster, is the Availability Suite feature of Oracle Solaris. Host-based data replication is a less expensive data replication solution because it uses host resources, rather than special storage arrays."
... so it looks like I also need to use Oracle Solaris Availability Suite too. Is this a separately licensable product or is it covered by Oracle Solaris Cluster? The article goes on to say:
"To see an example of host-based replication that does not use the Oracle Solaris Cluster Geographic Edition framework, see Appendix A, Deployment Example: Configuring Host-Based Data Replication Between Clusters With Availability Suite Software."
... so I presume that I do not need to use Geographic Edition to achieve my aims.
With regard to 3) above, I found the Oracle Solaris Cluster 4.3 FAQ document which suggests that I'll need an Oracle Solaris Cluster Agent. It states:
"An Oracle Solaris Cluster agent is a ksh script, a C program, or a binary that manages the availability of an application. The agent starts, stops, and monitors the health of the application, and it takes corrective action to regain application availability upon failure. Applications do not need to be modified to benefit from the enhanced availability offered by the Oracle Solaris Cluster agent. Applications can run either directly on Oracle Solaris on a physical system, in Oracle VM Server for SPARC, in dynamic domains, or within Oracle Solaris Zones."
The same document also says that Oracle Solaris Cluster "supports applications controlled by the Service Management Facility feature of Oracle Solaris and deployed in Oracle Solaris Zones." so from this I infer that the answer to my question above is that it IS possible to install Oracle Solaris Cluster inside a [kernel] zone, but to be honest I'm looking for a little more reassurance than this throw-away comment in a FAQ document!
My tentative plan is therefore as follows:
- Install 2 x physical SPARC S7 servers, at site A and site B. Their purpose is simply to host the zones.
- Create kernel zones on them in which to run our Oracle databases. Dedicate a certain number of cores to the zone in order to comply with our Oracle core-based database licensing.
- Use host-based data replication to replicate the zone's disks/ZFS data sets from kernel zone A (at site A) to kernel zone B (at site B).
- Install Oracle Solaris Cluster (non Geographic) inside the zones, so that it can manage resources, detect failures etc.
- Use the Oracle Availability Suite component of Solaris Cluster to create resource groups etc. and manage TCP/IP replication between the zones at the two sites
- Use an Oracle Solaris Cluster Agent for Oracle Database to automate the failover in case anything goes wrong.
Can anyone confirm that all my assumptions here are correct and that the design is feasible? I'm having to put this together as a proposal before we purchase, so I don't have the equipment to play about with and test this stuff. Alternatively I'm open to any suggestions as to different ways to accomplish this within the constraints I've outlined above.
Thanks for any input.
Stuart