Database/FS pkg

[Roger Baptiste]

hi,

I have a raw-volume database and a bunch of user filesystems which is used by user application to access the database and one floating IP address aliases to the database name. I need to package these two. I have two options:
1) Create two packages:
One package for the database with
the floating IP for the database alias.
and
One package for the app filesystems
without any IP.

OR


2) Create one package containing both the
database VG's(raw lvs) and user
filesystem VGs with the floating IP.


I am leaning towards Option 1, since i would like to keep database package separate and since database is raw lv , whereas app is filesystem LV. The only thing to be aware here is , if database package fails-over, the application package should also failover. But that's something i can set up manually.

How do folks who have similar setup implement it up? (i.e packaging a raw lv database and user filesystems with one floating IP).


thanks

[Michele (Mike) Alberton]

Hi !

in our previous implementation we used a Sybase 11.x DB using raw volume groups, packed together with our application VGs on the same package with a floating IP. It has been working fine for years :-).

We put the first cluster lock on the sybase VG and the rest seems pretty standard to me.

Cheers

Mike

[Charles McCary]

Raj,

I've seen it done both ways and I've done it both ways. I personally like option 1 because it gives you more flexibility in the end. If for some reason there is a need to run the packages on seperate boxes in the future (cpu, memory resources for example), then you're already good to go. Also, you can always go back and add a floating IP to the second package if you need to later.

C

[Darrell Allen]

Hi Raj,

If you have 2 packages that always need to run on the same system, then basically they are acting as 1 package, right? If you are having to manually set up something to get the app package to follow the database package, seems like you're doing what ServiceGuard could be doing for you and is designed to do.

I'd go with option 2. Seems to me that would eliminate a potential point of failure for the apps.

Darrell

[jd-gt]

I would setup 1 package with services. One for the IP, one for the database, one for the filesystems and one for the apps. Monitor the services and if the database fails over, then so do the rest of the services.

Something to think about.

[Roger Baptiste]

Thanks for the responses, which seemed even-stevens. I guess, it is a matter of exploring options and applying as it fits the requirements. I am preferring option1 because auto failover is not a necessity in my case and also how often do we have "only" one package failing and failingover to the other node. Most of the time, it's a node failure, which would carry all the packages across.


Jd-gt, can you elaborate on what you meant by setting up separate packages for IP, app, services.. ?

[Roger Baptiste]

Hi,

A related question:

With 11.09 OPS serviceG version can we add a new non-ops package when the cluster is up and running?
Product: (B5161EA A.11.09 ServiceGuard OPS Edition Bundle)


I read in one of the archived posts that, it is NOT possible to do this on 11.09, but the newer version Mc-SG OPS11.11 allows it .

Can somebody pls confirm. (O/S is 11.00)
thanks

[Roger Baptiste]

Responding to my own query, the man pages confirm that 11.09 OPS version needs the cluster to be down for adding packages.

[jd-gt]

You can really setup anything to run under a package. Once the package is defined and you create your custom scripts. Those scripts can do anything you can control via a script. So, If you want control via a package you could split each of the functions out into a package. However there is work involved here. If you want failover, then stopping and starting packages independently means remembering to issue the cmmodpkg -e command.
Really I see service guard as a frame work or an outline. Adhere to certain rules, then your imagination and the OS are the limits!

Hope my insight helps!

[Mladen Despic]

Raj,

We've had a similar dilemma with our 2-node cluster. Since the high availability of the database is the primary reason that we have the cluster, we have decided to create separate packages. This makes the failover process less risky for the database package. (If you have them in the same package, and if, for example, a filesystem fails to mount, your database may not start up on the second node.)

To force packageB to "follow" packageA, we are using HA Monitors. The disadvantage is that you have to purchase a separate product (unless you are already using it). But it makes even more sense if you intend to use it for monitoring other resources anyway. The advantage is SIMPLICITY (although you may need the latest patches). You just configure the package config file (for your second package) with something like this:

RESOURCE_NAME /cluster/package/package_status/
RESOURCE_POLLING_INTERVAL 60
RESOURCE_START AUTOMATIC
RESOURCE_UP_VALUE = UP

Barring the product bugs (i.e. lack of patches) this works quite well