Operating System - HP-UX
1827459 Members
4063 Online
109965 Solutions
New Discussion

Re: MC Serviceguard question i.e file system names

 
Rudy Smith_2
Occasional Advisor

MC Serviceguard question i.e file system names

I have a quick question. I have two servers that I plan on putting into a serviceguard cluster. I have just noticed that both servers have file systems with identical names ex. server one has d001 and server two has d001. In our desired configuration both servers will be active concurrently with server a failing over to server b and server b failing over to server a. In a failover situation how do i avoid problems with the identical file system naming?
5 REPLIES 5
Ivan Krastev
Honored Contributor

Re: MC Serviceguard question i.e file system names

Both systems has the /etc, /usr, /tmp ... but this is not a problem.

What is your shared volume group configuration and mountpoints ?

regards,
ivan
Matti_Kurkela
Honored Contributor

Re: MC Serviceguard question i.e file system names

If the mount points can have different paths, e.g. /package1/d001 and /package2/d001, there is no problem.

If both packages contain a filesystem that must be mounted at /d001, those two packages cannot run together on the same node. In a two-node cluster, this is a big problem.

If you have this problem, you must reconfigure one of your application packages to use a different path.

A lot of the work in setting up a reliable HA cluster goes to _planning_ a configuration for the cluster and the applications within it. You cannot just take two stand-alone servers, sprinkle some ServiceGuard fairy dust on them and make them a cluster.

MK
MK
Eric SAUBIGNAC
Honored Contributor

Re: MC Serviceguard question i.e file system names

Bonjour,

Some of my clients have this kind of configuration : same mount points between a production server and a dev server. Application on production server is supposed to fail to dev server, dev application is not.

What I am used to do is to have a package for dev application, even if it is not supposed to failover. This way, I can relie on control file logic to unmount dev filesystems before starting production package on the dev server.

Of course doing this way leads me to make some modifications outside the normal "customer defined functions" area of the package control script. Typically, I add a call to a function of my own, like "StopDevPackage", just at the very beginning of treatment of package startup (if [[ $1 = "start" ]] ...)

I guess that HP will not support such modifications, but it works pretty well.

The supported way will be to reconfigure dev application so that mount points differ from production, but sometimes it is not possible :-(

Eric
Rita C Workman
Honored Contributor

Re: MC Serviceguard question i.e file system names

Hello Rudy,

On a 2 node cluster running active/active with same fs name - here's a couple scenarios and comments and you see if any fit. Eric mentions one method.

#1 Active Prod/Active Dev
Prod fails over to Dev box. With same mountpoints. This option says you failover and ONE pkg (Prod) gets to keep running.
You must halt Dev before Prod pkg takes off. At top of your pkg.cntl file in your PROD pkg put the following:
/usr/bin/cmhaltpkg -n $(/usr/bin/uname -n) dev-pkg-name
This checks that if Dev pkg is running on THIS box...halt it. Then it will proceed start continue and start up Prod pkg.
And this should be fully supported.

#2 Active Prod/Active Dev
Your mountpoints are the same.
This option lets you failover both pkgs to one box and both keep running.
Change one them!. Remember a mountpoint is just something you "hang" your data on. See if it is realistic to change d001 on the Dev box to dv001.
You'd might have to adjust some variable contstants. The dba's could hit the database environment &/or maybe you need to look at some /etc/profile or user account .profile. But do it once and your done.

Hope these help you,
Rgrds,
Rita
Rudy Smith_2
Occasional Advisor

Re: MC Serviceguard question i.e file system names

Thanks for all the comments. My question has been answered.