opinions on serviceguard & omniback II

[Philip J. Priest_1]

I have a dba that is asking me to make omniback fault tolerant. The way i see this is, I have another cell manager and in 2 years that ive worked with it. It has never given me any problems.

Now in this new service guard enviroment, hes asking me to service guard omniback.

give me opinions pro & con.

Phil

[Ashwani Kashyap]

Omniback works fine in Service guard environment . Nothing different from any other service guard environment . Actually it helps .

If you don't want it in MCSG as you saidyours is pretty stable , then put the databse of that DBA in an MCSG environment , which should be more available .

[Joaquin Gil de Vergara]

Phil

In the Admin manual you have the complete procedure to do this.

Good Luck!

[Stefan Farrelly · Accepted solution]

We run it like this, works fine.

pros:
- now fault tolerant against hardware failure of a server

cons:
- takes some work to install, setup and test (on both nodes)
- have to use shareable diskspace (so that the db is available in the event of a failover)
- have to update both nodes with Omniback patches in future (instead of one node)

[Rita C Workman]

Maybe others know better ways..but..
MC/SG controls 'packages' that can be moved and run on any server, since you move the data and software as 'a package'.
Omniback on the other hand is generally owned by the server it is running on. So when the box goes down...so does the software associated with it.
Now what you might do is consider this in your Failover Plan. Also you would need your failover box to also have all the licensing and OBII setup as the regular box. That also means that the failover box has physical access to the tape library drives too. In our case we split the drives between 2 servers.
You then must decide how and what you want OBII to be on this failover box. Do you just want to continue doing backups going forward - or - do want to rebuild everything OBII on this box (from tape). Since failover is usually a temporary thing..you may just want to do backups going forward till everything is restored back to the primary.
My point being...discuss what is truly expected in the event of a complete failover, and go from there. And be realistic.

Just my thoughts,
Rita

[A. Clay Stephenson]

The procedure is completed documented in the 'Administrator's Guide' and works quite well. In practice if your OB2 LVOL's are mirrored then that is proably good enough especially if they are backed up via conventional backups (fbackup, tar, cpio) while OB2 is shutdown. In that case, moving OB2 to another server is very easy.

The main advantage of using OB2 under MC/SG is the rolling upgrade which would allow you to upgrade an OS while backups continue on the other node.

[Hai Nguyen_1]

Phil,

I think the answer depends on your MC/SG configuration as well. For example, in mine, I did not configure it into MC/SG. I have a two-node cluster. The primary node, by default, has all the packages up and running on it whereas the secondary node is sitting there idle. Therefore I attach the LTO 2/20 library to the secondary node and put the Cell Manager onto this node as well in order to give it something to do daily.

Hai