Question SG

[brian_31]

Hi Team:

We are currently in 11.0 running SG on nclass. We have currently made 3 applications highly available.(in one package). Now we want to split up an application and make it a seperate package. The question would be
1. Does it require a Seperate Disk? or a seperate volume group would do? We have sufficient disk space.

2. Do i have to go back to the application to make sure they install the product to the new directory?(pointing to the new vol. group)

3. What are the other factors to be considered?

Please advise.
Thanks
Brian.

[Rich Wright]

You need.
Separate disks and VG for each package. Or have duplicates on all nodes.
Each package has to have its own IP number.
Carefully examine all relationships between the applications.
Carefully examine all failover senarios.

[Robert Gamble]

1. Not necessarily. You could have a separate package that would dependant on the other package already being up and running. Tricky to set up, but possible. Packages require sharable disks for 2 reasons:(1) lock disk (2) application disk use. In the MC/SG class we had packages that were nothing more than an xclock process running.

2.If you go the separate disks route, then yes.

3.For more robust package availibilty, I would recommend making the packages independant.

HTH, Good Luck!

[Jeff Schussele]

HI Brian,

First I like to say you're doing the right thing. But you should take it a step further. You should make all apps separate pkgs. Reason - why take all apps down to do maint on just one? I believe the only time to "gang up" apps in a single pkg is when they are tightly tied together & one would die if the other goes down.

Now for your queries:

1) Yes, because you can't have multiple VGs on a single disk or LUN. And ALL pkgs have to have separate VGs.

2) Don't think so - just back 'em up redo the VGs & have them mount to the original dirs...i.e just make the old dirs the new mount points. As long as the path remains the same, the app shouldn't care

3) A) will need new virtual IPs for the new pkg(s).
B) Should be able to use the existing startup/shutdown.monitoring scripts. Just remove from old pkg & use in new pkg.

HTH,
Jeff

[brian_31]

Hi Team:
Truly Brilliant stuff. Thanks Gurus. But what do you mean by LUN? Also jeff, i did not understand your explanation for point no.2. Also please point to the right sites as i have to do this development work. We will also consider jeff's idea of extending this to all packages. Makes sense but looks like more $$$ as each one would require seperate disks(as i understood from the discussion).Is it 'coz of lock disk?

Thanks
Brian.

[John Poff]

Hello,

1. No, you don't have to have a filesystem/VG for each package, but it is usually easier that way. If you have a package that runs as a part of another package, and the filesystem(s) it uses are part of the other package, you can run it without any filesystems/VG. You just have to be careful about checking in your package control script to make sure the filesystems you need are mounted before starting the package. I've done it before, but I suggest taking a good look at how each of your applications depend on each other before doing it.

2. If you decided to give each package a separate FS/VG, yes.

3. The smaller packages that depend on a main one can be started and stopped within the main package control script. Again, it depends on what you are trying to do and how much the applications depend on each other.

As for the IP addresses, you don't have to have one with each package. Again, it depends on the application going into the package. If it is an Oracle database, I would use a package IP address.

Another thing to consider is that one application may require another one to be running also, so you'll have to work out those relationships in your packages through your control scripts, so that you don't get one package running when another one fails, and the first one depends on the second one.

Fun, isn't it?

JP

[Jeff Schussele]

Hi (again) Brian,

A LUN (Logical Unit Number) & is a subdivision of a larger storage device. Typically a RAID array will be "sliced" up into multiple LUNs *almost* always smaller than disk capacities. Sometimes a LUN can be mult drives chained together to a capacity larger than the disks themselves. But the point is that the OS sees a LUN as a distinct disk. It knows not just how it's formed...it thinks it's a disk.

Now let's say that the app exists now at /opt/app. What you can do is backup that dir & the tree on down, delete the files in it & all subdirs. Create the new VG/LV/FS & mount this new structure right to /opt/app. Then restore the data back to it & the app should be none the wiser.

What JP states, while fundamentally correct, is not the way I would do it. I want to have separate VGs & I want MC/SG to mount/unmount them as the pkg comes up/goes down. I also like to have a virtual IP whether I *need* it or not. It's an easy way to check, from anywhere on the network & w/o logging into the server, if the pkg is up or down. Just ping the virtual IP & if it responds you know the pkg has not come down. Now...whether the app is running (properly) or not is entirely up to the monitoring mechanism employed. If you don't monitor it properly, the app could be in severe distress & the pkg may not go down & the virtual IP would still be available. Proper execution of monitoring is key to HA.

My original point was if these are distinct & separate pkgs & are not tightly integrated to the point where pkg B can't run w/o pkg A being up, then sep pkgs is the way to go.

Rgds,
Jeff

[Steve Post]

From what I know you can have a package set up without an ip address. You can have a package set up without a volume group. But you have to think about the limitation this gives you.

IF you have pkg1 hold the disks for pkg2, it should be fine. BUT the two packages are pretty much linked. So pkg 2 is almost like a subset of pkg1. If pkg1 goes down, pkg2 does too. If pkg1 fails over, pkg2 dies. Pkg2 can't start (and will bombout), until pkg1 is up and on the same node as pkg2. It's like stand on a rug and pulling the end of the rug real hard.

Now about the ip address. If your application does not use one, you don't need it in the package. I made up a test package 3 weeks ago to start work with MC/Service guard. It did not need an ip address. So I did not add one.
This was after I submitted MY question on the forum. ^_^
Hope this helps.
steve

[Jeff Schussele]

Brian,

I'm a dummy....
What I meant in my last paragraph was....separate apps.....If app B can't run w/o app A being up....

Jeff

[brian_31]

Hi Team:

Thanks so much. Sorry for catching with this little late. I am still not fully clear on certail aspects..
1. For creating a new logical volume, do i require a disk(or may be for lock disk).
2. we have 3 products/applications which are going to be highly available(currently all in one pkg.) We are planning to seperate one product as a seperate package and also dedicate a lan card for that product.

What would be the conclusion? Please advise.

Thanks
Brian.

[A. Clay Stephenson]

To merely create a new logical volume, you do not need a new physical disk. If you need a new volume group then you will need new disks or LUNS because a disk can be a member of but one volume group.