ServiceGuuard and shared disks

[MicheleQ]

I all,

I have a cluster configured on my network with this hw:
2 Proliant dl 380 G4;
1 MSA 500

and these softwares:
OS: Linux RedHat Ent. 4 ES - 2.6.9-34.ELsmp
Cluster: serviceguard-A.11.16.07-0

I installed Serviceguard with only one package that manage both httpd and mysql. These two services have a dedicated partition on the MSA.

Below the ‘df’ of the active node:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/cciss/c0d0p3 32890776 11539908 19680108 37% /
/dev/cciss/c0d0p1 101086 12315 83552 13% /boot
none 517312 0 517312 0% /dev/shm
/dev/mapper/vg01-lvol0
414913512 12802064 381035072 4% /mnt/shared/mysql
/dev/mapper/vg02-lvol0
7224824 89360 6768464 2% /mnt/shared/httpd

I installed this cluster almost 2 year ago and it has always worked fine but some day ago I realized that I have the shared disks mounted also on the stand-by machine!!
It’s really strange…I was also able to write from the stand-by server on the shared partitions.

I did an umount of both partitions to re-establish the normal condition, but I’m little bit worried, it isn’t normal this behaviour…

[Ivan Ferreira]

>>> shared disks mounted also on the stand-by machine!!

Unless you are using some cluster file system, this is not a normal behaviour.

>>> strangeâ ¦I was also able to write from the stand-by server on the shared partitions.

If is not a cluster file system, this will produce data corruption, as the metadata information is not coordinated betwen the servers.

If is not a cluster file system, for example, ext3, then you should run fsck as soon as possible on the shared disks.

You can check the file system type using the "mount" command without arguments.

[skt_skt]

even though thte fsck is going to be run from the standby bt node , the disk in the same as on primary.

I would recommend to be on a "ready to restore" before doing this change.

[Serviceguard for Linux]

Did you implement the exclusive activation feature? What you have seen can happen if you did not implement that and someone manually mounted the file systems. It could have also happened if you did not set up LVM to prevent automatic VG activation.

[Matti_Kurkela]

Check the /etc/fstab in both of your cluster nodes. Normally, any ServiceGuard package disks should not be mentioned in /etc/fstab at all... or if they are, they definitely should have the "noauto" mount option.

If some (non-ServiceGuard) "user-friendly" GUI tool was used to prepare the package LVs, it may have automatically added the LVs to /etc/fstab, which would have caused the stand-by system to mount them automatically when it was booted.

In HP-UX, the LVM has a built-in feature that identifies the volume groups belonging to ServiceGuard packages: the HP-UX kernel will refuse to activate the volume groups unless the cluster daemons are active and can positively confirm the VG is not activated elsewhere.

In Linux, there is no such kernel-level mechanism. Originally there was no mechanism in Linux SG that could prevent the activation of the volume groups. The exclusive activation feature was implemented in version 11.16.xx, and works by using the "LVM tags" feature of the 2.6 kernel series. Of course, as it isn't a kernel-level feature, it's not too tough to override it if someone specifically chooses to do so.

MK