Monday, September 23, 2013

Distributed AD

Distributed AD

Distributed AD is a parallel processing feature that can reduce downtime by efficiently utilizing all the available resources on a shared application file system. AD Administration and Auto Patch run on the primary node and direct workers running on that node and other nodes in the system. The AD Controller utility controls and monitors the actions of the workers that you specify.
This parallel processing makes use of managers, which direct the actions of worker processes. The manager assigns each worker a processing job and monitors its progress. When a worker completes a job, the manager assigns it another until all jobs are complete. AD Administration and AutoPatch can be directed to distribute processing tasks across multiple remote machines in a multi-node system. This type of parallel processing operation is called Distributed AD. It further reduces the time to complete a maintenance task by utilizing the processing capabilities of all of the nodes in the system.
Distributed AD can only be used on systems that are using a Shared application Tier File System to ensure that files are maintained in a single, centralized location.



Using Distributed AD:

Start AutoPatch or AD Controller with Distributed AD worker options
On one of your shared application tier file system nodes, start your AutoPatch or AD Administration session with the following command line options:

localworkers= workers=For example, to run an AutoPatch session with a total of eight workers (three workers on the local node and five workers on a remote node):

$ adpatch workers=8 localworkers=3 Start AD Controller on remote node(s)
On each of the additional shared application tier file system nodes, start an AD Controller session with the additional distributed command line option:

$ adctrl distributed=yAfter providing basic information, AD Controller will prompt for the worker number(s) to be started. For example, to start workers 4 through 8 on a second node, enter “4 5 6 7 8″ or “4-8″.



The following is an example of starting a three-node session with a total of five workers:

Node 1:
$ adpatch localworkers=3 workers=5Node 2:
$ adctrl distributed=y
Enter the worker range: 4Node 3:
$ adctrl distributed=y
Enter the worker range: 5

During execution of AutoPatch or AD Administration, you can start a normal AD Controller session (without distributed=y) from any of the nodes in the shared application tier file system environment to perform any of the standard AD Controller operations. All of the standard AD Controller options have the same effect on both local and non-local workers, with the following exception:

option 6: Tell manager to start a worker that has shutdown this option will always result in a worker being started on the same node that the AutoPatch or AD Administration utility is running on. This means that if an AutoPatch worker exited on a distributed node, choosing this option will start the worker on the node that is currently running AutoPatch, rather than the node that was originally running the worker.

AD Controller Log Files

The log file created by AD Controller is created on whichever node the AD Controller session is started. This is to prevent file locking issues on certain platforms. It is therefore recommended that the AD Controller log file include the name of the node from which the AD Controller session is being invoked.
Managing Distributed Workers and Nodes

If a worker has exited on a distributed node 
Make sure that the worker is not running. 
Start AD Controller on the same distributed node using: 
$ adctrl distributed=y force_restart=yEnter the worker number(s) to start when prompted. AD Controller will start those workers and then exit. 

No comments:

Post a Comment