Autosys 4.5 and ServiceGuard

[Francis Noël]

Hi all

The shop will be migrating from Autosys 3.4 to Autosys 4.5 pretty soon and the servers wiil be on HP-900s. Database is Oracle 10g and we intend to run Autosys' web interface package. Preliminary tests are over and we are moving towards production systems.

Has anyone encapsulated autosys 4.5 in a ServiceGuard package ? I got the database down but the app part I'm not too sure about... it seems to need entries in inetd and so on.

Any pointers before I cass CA's support ?

Thanks !

[Mel Burslan]

We run autosys here as well although I am not involved in the management of those servers. But according to what my colleague here, who is involved in the administration of autosys production servers told me, it has its own redundancy when running in a dual server configuration and does not jive well with serviceguard. This is not my first hand experience and the autosys application admins are not very unix oriented people and moreover, extremely skiddish trying new things. So take my words with a grain of salt. But again, autosys, like any other CA product, is geared more towards the Windoze machines. So, I wouldn't be surprised if it did not run well under unix, let alone serviceguard.

HTH

[Matthew Ghofrani]

We run AutoSys ver 4.0 with Oracle in a ServiceGuard env on HP9000 rp8400 servers implementing both physical and virtual partitions today with no issue. As a matter of fact ServiceGuard cares less on what the service is. Are you apprehensive about the web package part of it?

Matthew From Boston

[Francis Noël]

Thank you for your input.

My aprehensions are that when encapsulating Autosys ( Web server and all ) in a SG package I might leave out some stuff it needs to work.

I am not an Autosys expert and I do not know if the installer places stuff outside of its /opt/CA install directory.
I understand it does some modifications to inetd.conf that would need to be taken care of, there might be other system files affected.

I know eTrust does not support being installed on NFS so I'm weary of other gotchas.

[Francis Noël]

I had a chat with the good people over at CA's support center and apparently it can be done.

Seems everything goes under /opt/CA and you need a few entries in /etc/services and inetd.conf.

Apparently Autosys itself and the web services can take it but eTrust Acces Control cant. I'm told this subproduct is linked against local data(bases) and uses hooks into the OS for process management and so on. CA is not sure how it would deal with being spawned on a different host.

I have to re-evaluate our need for that subproduct and I'll see from there.

Stay tuned :)

[Dave Hutton]

I'm pretty sure you can SG 4.5, personally I've never tried.

But I have used what is built into Autosys is the ability to use Duel Event processor/Shadow event processor.

Basically two servers, two databases and a 3rd machine that acts as the dibbs server. Basically a server that is aware of both servers and is what says who gets to do what. Its actually pretty easy to set up, a few lines in the config.XXX file after you have the software installed on both servers.

That may be an alternative if you SG isn't a requirement.

[unixdaddy]

We have autosys 4.5 running on HPUX 11.00 in a serviceguard environment (active/passive). we simply installed autosys in the shared storage. we also use the autosys web interface, we choose to run install this on each node and access it via the real IP address of the server. on the failover node the web instance just sits there doing nothing, when we failover I and instruct our guys to point the web browsers at the failiover nodes ip address. There is some work you need to do around remote command service, then you can actually see your autosys instance from either node no matter which one has the autosys instance running.

The key for us is tha when you setup the autosys jobs you must setup the jobs with the right permissions, so we set them up with the owner parameter poing to root@ i.e. root@blogs then updated /etc/hosts with floating ip pointing at blogs, as catch all we setup the autosys job permissions on the job so that the job could be run by any root user (in other words have matching users on both boxes and set the autosys jobs with permission for that username from any machine), so when it failover i can run the same jobs, as that user exists on that failover node and the jobs point to the floating ip (via /etc/hosts). you also have to do some work with autosys_secure command. if you don't do the above things when you failover you can't edit or execute jobs.

I have full documentation on how i did it and the failover tests we ran. I can be more detailed about what needs to be done on monday as I'm not in the office at the moment.

[Francis Noël]

Music to my ears Darren.
I'm looking forward to those details but you've already put me on the right track here.
Thanks you for your time !

Oh and have a good Monday/Week.

[Francis Noël]

Clustering Autosys has been put on hold.

I'll get back to it someday.
Thanks to all who commented.