Suggestion on running critical Oracle DBs on OVM


Login or Register to Reply

 
Thread Tools Search this Thread
# 1  
Suggestion on running critical Oracle DBs on OVM

Hello,
We have few critical databases running on T series servers. Setup consists of LDOMS and zonemanager running on them and databases are running on their zones. We want to get away from this setup and looking for alternate solution to run our Oracle databases.
One option is OVM from Oracle. Theoretically it looks very much possible to keep VM Manager as Linux VM and our VM can be Solaris based, where databases will be sitting. There is some dependency for few DBs and application, which wouldn't allow us to use anything other than Solaris OS.
I worked on OVM few years back in its initial days. But it was not very mature at that time and even for migration from one hardware to another, it used to stuck and later we gave up. It might have matured by now.
If anybody have experience in similar setup, please suggest how it is behaving with you.
Thanks
# 2  
Hi,

You may want to consider RHEV, we are currently running (Evaluating) Solaris 11.4 on it and at the moment it all seems very stable. Our current setup sounds similar in that we have a number (4) of T series running LDOMS with 11.3 with the remainder of the T series (6) still being Solaris 10 with 8, 9 and 10 zones on them.

These are all T5's and to be honest with you there doesn't seem to be the appetite to upgrade to later SPARC technology, so there is a major push to put as much as is possible into migrating to x86 VM's. OVM was considered but it was thought that as we were already running a number of legacy VM Ware VM's and there was a push on for moving them to RHEV we'd move the solaris stuff that way if we could.

I'd say that if you already have a virtualisation platform in use, then trying to fit in with that is the way to go - but if you don't then evaluating OVM would be the way to go. There are any number of suitable options out there just now, choosing one that you are happy with and that is fit for purpose is worth the effort and the time required to evaluate.

Regards

Gull04
This User Gave Thanks to gull04 For This Post:
# 3  
Thanks for reply.
We do have large VMWare setup, but database guys wants to remain on Sparc hardware. I didn't got chance to look at RHEV, will read about that in detail.
In our setup, we have 4+4 zones (running Oracle DB on them) at one location and 4+4 zones at another datacenter. That means, local-redundancy and geo-redundancy.
I am trying to understand, if your setup can fit in my requirement. Is RHEV is manager and that is managing clusters running Solaris 11.4 ?
# 4  
Hi,

If you're staying on SPARC then you're staying with OVM, there are a number of options - I would have liked to stay with our current setup. While we don't run clustered for our critical apps, we do have a hot DR site with matching kit with a dual 40Gb pipe between the two sites storage is replicated using Metro Mirror or Global Mirror.

We are currently running OVM 3.5 which is very stable, our zones (about 100 - haven't counted them) are both branded and lightweight. We have a large number of Oracle instances on Solaris, these cover Oracle 7.3.4 all the way up to Oracle 12. Where we have a zone we use a single SAN LUN, this make or DR easy with cross site replication to the DR site. Where we have an LDOM, the disks are all replicated to the other site - in general we keep the Oracle ASM disks as seperate LUN's. All of our Solaris DR is scripted and even on our LDOM's we can have a full failover to a DR system in 15 minutes from the go instruction.

The setup we use is a little unorthodox, but suffice to say that until DR is implemented the the target LDOM doesn't exist as when we implement a DR we use the same hostname and the same IP Addresses at the remote site ove stretched VLAN's at layer 2.

The RHEV managed systems are Solaris x86 so not really relevant in this context, I don't believe that there is a version of RHEV that will handle SPARC - happy to be advised otherwise folks.

Regards

Gull04
This User Gave Thanks to gull04 For This Post:
# 5  
Have you considered, if you can, to run only zones on bare metal sparc or x86 ?
If you have no regulative demands regarding running single kernel, you would have zero virtualization overhead with good separation.

Altho oracle VM is fine, removing entire stack above your hardware will offer better performance, less bugs and (possibly) easier administration.
Also, as i recall, on SPARC servers you can hard partition your zones regarding licensing, but you should double check that Smilie

As for geo / DR stuff, depends... What kind of tech are you using now - synchronous asynchronous and on what level (storage, database log shipping, zfs utilities etc.)

Regards
Peasant.
# 6  
Gull04 - that looks nice setup. For this setup, DB guys don't want to go away from Sparc. But during discussion with my manager, I suggested if can make another environment of RHEV, which can host application VMs. Currently we have large VMWare setup. Management's main focus will still remain on cost of ownership (in comparison to VMWare, which is pretty expensive), if they would allow to keep some components on RHEV Smilie

Peasant - We have zones also, but to keep it more robust and fault tolerant, LDOM was setup long back. In comparison to zones, LDOM administration is complex, if we want to add/remove/edit any resource. Local redundancy (all in Seattle) are having LUNs shared among servers. Geo Redundancy (Seattle and Phoenix) are having redundancy on DB level only. For DR site also, replication is setup on DB level only.
# 7  
Hi Solaris_1977,

As Peasant says you can cap the cpu on zones, to limit licence costs - this model is not accepted for VM Ware. The full CPU count is licensed for each Oracle Instance (we know this from experience and it was a real ouch moment!), so when we were audited about six months into a project - there was a serious headless chicken moment due to the increase in costs.

Running zoned multiple instances of Oracle inside an LDOM means that without capping at a zone level, each instance has to be licensed for the whole LDOM capping the zones means you can control the licensing costs better.

If you have the databases covered with log shipping for Geo resilience and Clusters for Local resilience I don't really see how you could improve much on that. Unless of course someone wants to add a zero to your budget to get that extra point 9 uptime.

The Oracle license model is difficult to understand some times in my experience, looking at the oracle site for any length of time and you seem to find contradictory information - so I just leave all that to the Architects now and they tell me what I have to build for them.

Regards

Gull04

Last edited by gull04; 01-09-2019 at 05:06 AM.. Reason: Minor Correction
This User Gave Thanks to gull04 For This Post:
Login or Register to Reply

|
Thread Tools Search this Thread
Search this Thread:
Advanced Search

More UNIX and Linux Forum Topics You Might Find Helpful
OVM Server for SPARC ... Need Your Help Guys !
Mack1982
I have two SPARC T4-2 servers: - Oracle Solaris 11.1 Installed. - Oracle VM Server for SPARC 3.0 software Installed. - Shared LUN provisioned to both servers from Clariion CX4 storage box (shared LUN to be used for the Live Migration of the VMs). - Oracle VM Agent 3.2.1 for SPARC installed. ...... Solaris
14
Solaris
Oracle/Xen/OVM/OCFS2/Multipath/SAN Problems
pludi
Setup: Multiple Virtual Machines running OEL5 / Oracle RDBMS 11.2 OVM 2 / Xen 3.4.0 Cluster consisting of 3 Machines Shared SAN Storage synced with OCFS2 SAN connected with 4GB FC on 4 Paths per LUN SAN target are 2 EMC Clariion mirroring each other The problems we're facing are that...... Emergency UNIX and Linux Support
6
Emergency UNIX and Linux Support