Hi,

Picking up again from a recent post of mine - can you please clarify for me
what would be the "recommended" configuration for 24x7 if I have multiple servers
on which I wish to run multiple jobs asynchronously - most servers do not have webserver capability.

I would like one central server to act as a master scheduling and job/queue/logs monitoring console.

I currently have the 24x7 agent installed as an NT service (not distributed server enabled) using a specially
set up admin user account on each of the "remote" servers.

I also have a "master Server"/console server with full 24x7 installed - also running as an NT service to
ensure it is started automatically with the server independent of user
logon. This installation does have "distributed server" enabled.

How do I modify this configuration/architecture to ensure that I can submit/monitor/control jobs on all of the
remote servers and also runa and monitor/control jobs on the console server itself ?

Thanks,

Jim

On the computer which you call "master Server"/console server (for clarity let's call it as "central server") run 24x7 GUI and setup an agent profile (Tools/Remote Agents menu) for every other server running 24x7 agent or scheduler in the server mode. Give each profile some unique name (for example, you can use computer names for profile names).

Schedule all your jobs on the central server. In job properties for every job select which agent should run that job. Optionally specify "backup" agents that can run the job in case if the primary agent is not available.

Depending on the number of jobs that can run concurrently at any given point in time, number of independent job streams, and also some other factors specific to your business requirements configure several job queues (Tools/Job Queues menu). In any case try to keep the number of queues less then 10. If jobs take a long time to run, for example 30+ minutes and do not have to run in a certain sequence, you can set them to run asynchronous and also set them to run detached. This way they will not block their queues while running. Be aware that if you set a lot of script jobs to run asynchronous/not-detached they will put a lot of "pressure" on the scheduling engine because of the internal communication calls and in turn may severally affect the overall performance and system stability.

Finally assign different jobs to different job queues to allow concurrency.

: Hi,

: Picking up again from a recent post of mine - can you please clarify for me
: what would be the "recommended" configuration for 24x7 if I have
: multiple servers
: on which I wish to run multiple jobs asynchronously - most servers do not
: have webserver capability.

: I would like one central server to act as a master scheduling and
: job/queue/logs monitoring console.

: I currently have the 24x7 agent installed as an NT service (not distributed
: server enabled) using a specially
: set up admin user account on each of the "remote" servers.

: I also have a "master Server"/console server with full 24x7
: installed - also running as an NT service to
: ensure it is started automatically with the server independent of user
: logon. This installation does have "distributed server" enabled.

: How do I modify this configuration/architecture to ensure that I can
: submit/monitor/control jobs on all of the
: remote servers and also runa and monitor/control jobs on the console server
: itself ?

: Thanks,

: Jim

Hi Again,

Thanks for the response - most of which I think I understand ;)

While I go away and reread the 24x7 documentation on Queues and Jobs can you please clarify the
"running as service/not running as service/distributed server mode" settings should be for the
remote and central servers ?

I am also still a little unclear about what level of local/remote job/que monitoring and control I will have ?

The primary use for the job scheduling in my environment is to schedule the same set of jobs, most of which
can be run synchronously, to run on a whole set of remote servers so what would be the best way to enable
submission of the same job(s) to run across a whole set of remote servers ? from what has been said to date it
looks like a very labour intensive activity to set up - unless I am missing something obvious ?

Thanks again,

Jim

: On the computer which you call "master Server"/console server (for
: clarity let's call it as "central server") run 24x7 GUI and
: setup an agent profile (Tools/Remote Agents menu) for every other server
: running 24x7 agent or scheduler in the server mode. Give each profile some
: unique name (for example, you can use computer names for profile names).

: Schedule all your jobs on the central server. In job properties for every job
: select which agent should run that job. Optionally specify
: "backup" agents that can run the job in case if the primary
: agent is not available.

: Depending on the number of jobs that can run concurrently at any given point
: in time, number of independent job streams, and also some other factors
: specific to your business requirements configure several job queues
: (Tools/Job Queues menu). In any case try to keep the number of queues less
: then 10. If jobs take a long time to run, for example 30+ minutes and do
: not have to run in a certain sequence, you can set them to run
: asynchronous and also set them to run detached. This way they will not
: block their queues while running. Be aware that if you set a lot of script
: jobs to run asynchronous/not-detached they will put a lot of
: "pressure" on the scheduling engine because of the internal
: communication calls and in turn may severally affect the overall
: performance and system stability.

: Finally assign different jobs to different job queues to allow concurrency.

If you need to run exactly the same set of jobs on every server then I think you picked the implementation method. People often confuse centralized job monitoring with centralized job scheduling which is not necessary the same.

Below I will show 2 examples that can hopefully help you to understanding the difference.
Perhaps you have 100 servers that should run same 10 jobs 10 times each every day. Therefore together you need to run 100x10x10 = 10000 jobs daily. Of course you can put all your eggs in one basket and pick server A as the central server and create 10 "remote" jobs for the rest 99 servers and another 10 jobs for the server A. Now imaging how much work you are going create for the server A to run 10000 jobs daily with all these remote communications, notifications, etc… etc…. running as well. The system is not going to be very stable, will most likely bring the entire server down or slow down it tremendously and also will make it hard to really monitor it. All jobs logs will be automatically available on central server A. However you should realize that if something happens to server A or network communications, all your other server will do nothing.

You can also pick another method. Create 10 "master" jobs on the server A and then create an extra job "Copy Them" which with a push of a Run Now button can copy the entire job database file to the rest 99 servers and restart the scheduler on them or use on-line job replication methods (JAL script with RemoteCopyJobxxx commands). This extra job will be run manually once in a blue moon or maybe once a year after you make changes in the job settings, or perhaps develop a new job. If something happens to server A, your business is not completely dead as the remaining 99 servers will continue running their jobs. As you can see you only create and maintain 10 jobs which should be very labor intensive and can be done in a short period of time.

Now the interesting part, in the second scenario you can also have 1 central place to monitor all servers. 2 most common methods are:
1. Use central database (Oracle, DB2, whatever) for job event logging
2. Make each scheduler/server to ship main schedule log file schedule.log to server A or some other common place on the network and schedule periodic run of HTMLGen utility to produce consolidated HTML log files containing records from all servers.

Talking about central job/queue monitoring using graphical monitors, I have to say that everything is possible, but this is really not needed because there is very little value in doing that. You can argue if you want, but I know for a fact that people play with it for a few days then they get busy doing something else, as a result they pick configurations that do not do them any good and also not very flexible and resilient to individual parts failures from a global system point of view.

And last if you want the scheduler to be accessible over the network enable distributed server mode. You don't need to do this if you run agents, because agents automatically run in the server mode regardless of the settings on the Network page.

: Hi Again,

: Thanks for the response - most of which I think I understand ;)

: While I go away and reread the 24x7 documentation on Queues and Jobs can you
: please clarify the
: "running as service/not running as service/distributed server mode"
: settings should be for the
: remote and central servers ?

: I am also still a little unclear about what level of local/remote job/que
: monitoring and control I will have ?

: The primary use for the job scheduling in my environment is to schedule the
: same set of jobs, most of which
: can be run synchronously, to run on a whole set of remote servers so what
: would be the best way to enable
: submission of the same job(s) to run across a whole set of remote servers ?
: from what has been said to date it
: looks like a very labour intensive activity to set up - unless I am missing
: something obvious ?

: Thanks again,

: Jim

Correction, In "As you can see you only create and maintain 10 jobs which should be very labor intensive" i really meant
"As you can see you only create and maintain 10 jobs which should NOT be very labor intensive." Sorry about that mistake.

: If you need to run exactly the same set of jobs on every server then I think
: you picked the implementation method. People often confuse centralized job
: monitoring with centralized job scheduling which is not necessary the
: same.

: Below I will show 2 examples that can hopefully help you to understanding the
: difference.
: Perhaps you have 100 servers that should run same 10 jobs 10 times each every
: day. Therefore together you need to run 100x10x10 = 10000 jobs daily. Of
: course you can put all your eggs in one basket and pick server A as the
: central server and create 10 "remote" jobs for the rest 99
: servers and another 10 jobs for the server A. Now imaging how much work
: you are going create for the server A to run 10000 jobs daily with all
: these remote communications, notifications, etc… etc…. running as well.
: The system is not going to be very stable, will most likely bring the
: entire server down or slow down it tremendously and also will make it hard
: to really monitor it. All jobs logs will be automatically available on
: central server A. However you should realize that if something happens to
: server A or network communications, all your other server will do nothing.

: You can also pick another method. Create 10 "master" jobs on the
: server A and then create an extra job "Copy Them" which with a
: push of a Run Now button can copy the entire job database file to the rest
: 99 servers and restart the scheduler on them or use on-line job
: replication methods (JAL script with RemoteCopyJobxxx commands). This
: extra job will be run manually once in a blue moon or maybe once a year
: after you make changes in the job settings, or perhaps develop a new job.
: If something happens to server A, your business is not completely dead as
: the remaining 99 servers will continue running their jobs. As you can see
: you only create and maintain 10 jobs which should be very labor intensive
: and can be done in a short period of time.

: Now the interesting part, in the second scenario you can also have 1 central
: place to monitor all servers. 2 most common methods are: 1. Use central
: database (Oracle, DB2, whatever) for job event logging
: 2. Make each scheduler/server to ship main schedule log file schedule.log to
: server A or some other common place on the network and schedule periodic
: run of HTMLGen utility to produce consolidated HTML log files containing
: records from all servers.

: Talking about central job/queue monitoring using graphical monitors, I have
: to say that everything is possible, but this is really not needed because
: there is very little value in doing that. You can argue if you want, but I
: know for a fact that people play with it for a few days then they get busy
: doing something else, as a result they pick configurations that do not do
: them any good and also not very flexible and resilient to individual parts
: failures from a global system point of view.

: And last if you want the scheduler to be accessible over the network enable
: distributed server mode. You don't need to do this if you run agents,
: because agents automatically run in the server mode regardless of the
: settings on the Network page.

Hi Again - thanks for your detailed and considered response :) While I try to
digest the implications can you give me some info. about the HTMLGen utility -
I don't think I've come across it before ?

Jim

: If you need to run exactly the same set of jobs on every server then I think
: you picked the implementation method. People often confuse centralized job
: monitoring with centralized job scheduling which is not necessary the
: same.

: Below I will show 2 examples that can hopefully help you to understanding the
: difference.
: Perhaps you have 100 servers that should run same 10 jobs 10 times each every
: day. Therefore together you need to run 100x10x10 = 10000 jobs daily. Of
: course you can put all your eggs in one basket and pick server A as the
: central server and create 10 "remote" jobs for the rest 99
: servers and another 10 jobs for the server A. Now imaging how much work
: you are going create for the server A to run 10000 jobs daily with all
: these remote communications, notifications, etc… etc…. running as well.
: The system is not going to be very stable, will most likely bring the
: entire server down or slow down it tremendously and also will make it hard
: to really monitor it. All jobs logs will be automatically available on
: central server A. However you should realize that if something happens to
: server A or network communications, all your other server will do nothing.

: You can also pick another method. Create 10 "master" jobs on the
: server A and then create an extra job "Copy Them" which with a
: push of a Run Now button can copy the entire job database file to the rest
: 99 servers and restart the scheduler on them or use on-line job
: replication methods (JAL script with RemoteCopyJobxxx commands). This
: extra job will be run manually once in a blue moon or maybe once a year
: after you make changes in the job settings, or perhaps develop a new job.
: If something happens to server A, your business is not completely dead as
: the remaining 99 servers will continue running their jobs. As you can see
: you only create and maintain 10 jobs which should be very labor intensive
: and can be done in a short period of time.

: Now the interesting part, in the second scenario you can also have 1 central
: place to monitor all servers. 2 most common methods are: 1. Use central
: database (Oracle, DB2, whatever) for job event logging
: 2. Make each scheduler/server to ship main schedule log file schedule.log to
: server A or some other common place on the network and schedule periodic
: run of HTMLGen utility to produce consolidated HTML log files containing
: records from all servers.

: Talking about central job/queue monitoring using graphical monitors, I have
: to say that everything is possible, but this is really not needed because
: there is very little value in doing that. You can argue if you want, but I
: know for a fact that people play with it for a few days then they get busy
: doing something else, as a result they pick configurations that do not do
: them any good and also not very flexible and resilient to individual parts
: failures from a global system point of view.

: And last if you want the scheduler to be accessible over the network enable
: distributed server mode. You don't need to do this if you run agents,
: because agents automatically run in the server mode regardless of the
: settings on the Network page.

HTMLGen.exe is used internally by 24x7 to generate HTML log files. By default it generates logs using data from the local log file and also using local computer name in the "agent name" column. But it can be scheduled to run as a command line job with parameters to produce logs from multiple files (from multiple computers). For description of supported command line parameters run HTMLGen from the command line.

Here is an example command to produce single consolidated logs from different computers with an index by processing date. Note that in this example all logs are copied to single "c:\logs\input" directory and each log caries name of the originating computer.

htmlgen * c:\logs\input dd-mm-yyyy c:\wwwroot\logs\24x7

The resulting log is created or updated in the c:\wwwroot\logs\24x7 directory which can be accessed through IT department web server from virtually any computer in your company by typing in the browser address bar something like the following
\logs\24x7\index.htm

: Hi Again - thanks for your detailed and considered response :) While I try to
: digest the implications can you give me some info. about the HTMLGen utility
: -
: I don't think I've come across it before ?

: Jim

Thanks for the HTMLGEN info - I have been thinking about your last post
regarding job submissions across multiple servers and I can appreciate wher you
are coming from - still not sure about it though, need to think some more.

However how do I handle the centralised control of these distributed jobs now ?

Jim

: HTMLGen.exe is used internally by 24x7 to generate HTML log files. By default
: it generates logs using data from the local log file and also using local
: computer name in the "agent name" column. But it can be
: scheduled to run as a command line job with parameters to produce logs
: from multiple files (from multiple computers). For description of
: supported command line parameters run HTMLGen from the command line.

: Here is an example command to produce single consolidated logs from different
: computers with an index by processing date. Note that in this example all
: logs are copied to single "c:\logs\input" directory and each log
: caries name of the originating computer.

: htmlgen * c:\logs\input dd-mm-yyyy c:\wwwroot\logs\24x7

: The resulting log is created or updated in the c:\wwwroot\logs\24x7 directory
: which can be accessed through IT department web server from virtually any
: computer in your company by typing in the browser address bar something
: like the following
: \logs\24x7\index.htm

In case if you run old version of 24x7 and your htmlgen doesn't support batch log processing you can download the most recent version of HTMLGen here
http:\\www.softtreetech.com\24x7\extras\htmlgen.exe

: HTMLGen.exe is used internally by 24x7 to generate HTML log files. By default
: it generates logs using data from the local log file and also using local
: computer name in the "agent name" column. But it can be
: scheduled to run as a command line job with parameters to produce logs
: from multiple files (from multiple computers). For description of
: supported command line parameters run HTMLGen from the command line.

: Here is an example command to produce single consolidated logs from different
: computers with an index by processing date. Note that in this example all
: logs are copied to single "c:\logs\input" directory and each log
: caries name of the originating computer.

: htmlgen * c:\logs\input dd-mm-yyyy c:\wwwroot\logs\24x7

: The resulting log is created or updated in the c:\wwwroot\logs\24x7 directory
: which can be accessed through IT department web server from virtually any
: computer in your company by typing in the browser address bar something
: like the following
: \logs\24x7\index.htm

If you find out in the central log that something went wrong on computer XYZ and the problem is with the job, start 24x7 Remote Control on your workstation connect to computer XYZ and do something to that job. If you run a complicated script job maybe you will need to fix it. Whether you fix it yourself or some developer works on it, it is going to happen locally on your/developers computer and only after all changes and testing you will deploy the job where needed.

In most cases problems are caused by some third factors, files are locked or not created on time and cannot be copied, databases are not available during cold backup and so on. So whether you have a central scheduling server or multiple does not make any difference because most problems will be outside of the scheduler/agent control.

: Thanks for the HTMLGEN info - I have been thinking about your last post
: regarding job submissions across multiple servers and I can appreciate wher
: you
: are coming from - still not sure about it though, need to think some more.

: However how do I handle the centralised control of these distributed jobs now
: ?

: Jim