Testing/Validating Sun Cluster Veritas migration procedures tonight - W00t!

In the annals of nerddom, I suppose it's not all that, but nonetheless it's sweet like a Georgia peach!

We are using veritas mirroring instead of EMC's SRDF to be more friendly to Sun Cluster.

I'm really enjoying the opportunity to be able to build the LUNs, SAN Zones, and do the Unix/Veritas too...it's really great to work for a smaller company and be working with all layers of the process.

I'll report results tomorrow. :)

Veritas blues. Mirroring inside of Sun Cluster

Doing some testing of procedures to move a production Sun Cluster
between a DMX4 and a VMAX.

On paper it looked simple enough, but in practice...

So, got all my exactly same drives built on the vmax via Symconsole,
zones created, and verified my test cluster could fail both ways
successfully.

First major hurtle was: how to tell veritas to mirror a volume on two
disks to a mirror set of disks on vmax. I never did get the vxmirror
to work, but did finally get vxassist to go.

# /usr/VRTS/bin/vxassist -g diskgroup mirror volumename

So simple, and since it was limited to using only Luns that had been
added to that disk group, it somehow magically passed the right syntax
to vxassist, the mirroring commenced.

I'll dial back in later tonight and see how it went.

Sent from my iPhone

ssh and sun cluster switching

Having trouble with switching between Sun Cluster 3.2 nodes?

Check that your /.ssh/authorized_keys file contains the current id_rsa.pub file of the other node.

Just had that issue...the cluster would fail one way, but not fail back. Resync'ed both nodes and did a

#> svcadm restart ssh

#> clrg switch -n nodename cluster-resource-group

and all is well, I'm failing successfully both ways...

What I learned today.

When restoring a flar to a "test" cluster node that had been
repurposed for this or that other testing environment use, please
remember the following:

Having an NFS flar restore using an OS DVD and having it read the VTOC
from the disk; remember that the vtoc it reads probably isn't the one
you had when it was a cluster node. Hope you had the original cluster
design worksheets.

Also, Sun Cluster 3.2u1 loses its mind if you restore your flar to the
other c#t#d# disk even though the install media is kind enough to
automatically fix your vfstab for you. Always restore to the original
c#t#d# disk.

Just trust me on this one... :)

It's been a long day.

Sent from my iPhone

showrev -p is bothersome.

To make it easier to read, try:

showrev -p | nawk '{print $1, $2}'

This should be your comprehensive patch and revision list without all
the output clutter.

Sent from my iPhone

Other patchadd Return Codes

For other return codes from patchadd.
http://www.sins.com.au/unix/solaris_patch_return_codes.html

Sent from my iPhone

Solaris 10 EIS patches - patchadd error

Was getting the following error any patch attempted under /var/tmp/10/ with the ./install_all_patches script.

[...]
Checking installed patches...

Executing prepatch script...

Verifying sufficient filesystem capacity (dry run method)...

Patch 119254-72 failed to install due to a failure produced by pkgadd.

This appears to be an attempt to install the same architecture and
version of a package which is already installed. This installation
will attempt to overwrite this package.

From the generated log file:

[...]
/var/tmp/10/10_Recommended/patches/119254-72/SUNWinstall-patch-utils-root/install/checkinstall: /var/tmp/10/10_Recommended/patches/119254-72/SUNWinstall-patch-utils-root/install/checkinstall: cannot open


pkgadd: ERROR: checkinstall script did not complete successfully


Dryrun complete.


No changes were made to the system.

Now, what it looks like is that checkinstall cannot be opened...but it's really saying something that checkinstall script itself is trying to open is failing.

The resolution was:

Somehow, the ".." directory under 10_Recommended directory had 700 permissions...changed it to 755 and the EIS patches installed perfectly.

Arcanum sought! :)

-highprotein