AutoSys Workload Automation

Hi Experts,

We are planning to create full disaster recovery AE solution using oracle RAC,

1. We will create primary and shadow scheduler in DC supported by oracle RAC and will be in HA mode

2. Scheduler in DR will be using same oracle RAC instance

Question 1: I have doubt on scheduler role, which is in DR, what should be the role of DR scheduler, When I have to support agents in DC from DR, when DC AE solution shutdown.

Question 2: When we have to configure our agents to report two managers, in which scenario this configuration is required.

Regards,

Ritu

DR Scheduler will be Primary as it appears to be a standalone (non-HA) configuration. You need to be very wary of the DR and Prod (DC) sharing the databases, because at any given point in time, there can only be one Primary Scheduler running. As long as DR Scheduler doesn't beat DC Primary to it, it is okay, but still risky business. Ensure the DC Primary is completely shutdown before bringing DR Scheduler up, but in case of a true/real DR situation, this could be challenging.

As for the Agent communication with DR scheduler, the default WAAE compatibility mode allows the System Agent to serve any Scheduler dynamically. So, one need not worry about additional Agent configuration. You need to ensure the firewall rules allow for DR to Agent communication, though.

From the doco:

Lock the Scheduling Managers Defined on the Agent

A scheduling manager can send a message to the agent to add its connection properties dynamically to the agentparm.txt file. You can configure the agent to lock the scheduling managers that are defined in its agentparm.txt file and prevent any new scheduling manager additions.

Follow these steps:

1. Change to the agent installation directory.
2. Stop the agent.
3. Open the agentparm.txt file.

4. Set the following parameter:

   communication.manager.dynamic.modifications.lock=true

5. Save and close the agentparm.txt file.
6. Start the agent.
   The agent does not allow the addition of any new scheduling managers. Existing scheduling managers that are defined on the agent are not affected.

Hope this helps.

I'm curious to see how people handle this in the real world.

Cheers,

Chandru

Chandru.Venkataraman, thanks for input :-).

so if DR scheduler is going to be primary, in that case

1. do i need to have same host name of DR scheduler and DC scheduler machine, is it required ? , because i want to understand how installer will work, and what all pre-requisites needs to done before installation.

2. and as per your input, at the time of DR scheduler machine installation, primary scheduler required to be shutdown, is it a correct statement ?

Thanks.

Yes, Primary and Shadow Scheduler and App server services need to be shutdown before installing DR scheduler because when you share the same database, existing connection pool from DC scheduler/application server could impede the installation. You need to use the same instance name. Same host-name isn't required. During the install, it is preferable NOT to select Start Scheduler, Application Server after installation, as you might end up starting DR scheduler after the install completes.   Again, sharing live database is definitely not recommended. I have come across sites where a hot backup or dataguard replication of the production DB is used on the DR side.

Cheers,

Chandru

Thanks once again Chandru.Venkataraman   :-)

Yes, you are right about live database sharing. i am not good in oracle, i think DB team will be using oracle dataguard configuration for replication.

i hope,  i am good to go from here. if i am missing something or i have to take care of any other configuration, i would request other people to comment.

Regards,

Ritu

I wonder what are you trying to achieve by configuring the same database to the DR server. All your jobs, machine definitions, global variables, info on external instances etc.. exist on your database. Since you already have a Workload Automation HA configured there is an automatic failover if the primary scheduler goes down.

And in terms of DR planning, if you lose your database then it is a single point of failure as the DR scheduler does not have a database to come online.

As suggested by Chandru,  it is better to have a replicated database on your DR site which can be configured for your DR scheduler.