RE: [Control-X] Control-M Distributed Architecture Business models
- From a purely admin perspective, the fewer software installations the better, also the fewer CM Server databases the better.
From a business perspective, it probably doesn't matter how businesses are spread across various software components so long as the jobs run (clients will be happy if their jobs run fine--they won't care about the ControlM infrastructure very much), so I'd go with #2.
We tend to install CM Servers based more on geography and criticality of applications than what businesses might be run on them. E.g. product distribution gets one CM Server per distribution center (critical and geographic), but management reporting jobs are run on various agents on various platforms from a single CM Server (less critical stuff & mostly needed at HQ). We use job/table naming to distinguish between various businesses & companies.
Just my 2 cents
From: Steele [mailto:slwhyte@...]
Sent: Sunday, November 30, 2003 4:59 PM
Subject: [Control-X] Control-M Distributed Architecture Business models
We are currently on an old version of Control-M
ECS500 & Ctm Svr 2.2.4
EM 6.1.02.04 & Ctm Svr 6.1.01.04.
Prior to performing a full migration we are examing various
strategies for distributing and managing the environment. 2 models we
are considering are;
1. Business specific model
- 1 x Control-M/EM Server
- 1 or 2 (2nd for redundancy) Control-M Server(s) per business group
2. Enterprise Model
- 1 or more Control-M/EM Servers
- Dedicated Control-M Servers with multiple business's on the same
There are pros and cons for both methods ... but I am curious as to
what the larger organisations have adopted and based upon previous
experinces what you would prefer.
Alternatively ... you may have another model in mind.
Any input welcome ... thanks in advance ...
Control-X email list does not tolerate spam. For more information http://s390.8m.com/controlm.html DO NOT Spam this list or any members. To unsubscribe go to http://groups.yahoo.com/group/Control-X and click on User Center. Not affiliated with BMC Software.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Thank you very much for your response ... it is appreciated as any
input is better than none at all.
I can see merit in both models and I totally agree when you say the
less Control-M Servers the better. That is certainly my
preference ... we have a large organisation with many servers and I
am attempting to ensure that future growth (looming large very soon)
can be managed in a way that it does not require 6 Control-M
Technical Support Administrators.
My major goals are nothing new to the IT industry but one I feel is
not adopted enough.
1. Minimal Admin
2. Ease of use
3. Enable future growth WITHOUT having to do rework.
Easier said than done and only through proper planning we will
achieve it. This will make it easier for myself and the company.
In any case I will have to learn from prior experiences and bite the
bullet very soon.
For what its worth ... your input was worth at least $1. ... ;o)
I can appreciate your struggle and recognize your goals as noble! Your first
two goals are what they are. Perspective determines each! ;-)
Your third goal is the tricky one. Seems to me that predicting future growth
to avoid rework and still sizing processors to the satisfaction of
management is close to impossible. (Been there, failed more than once!!)
Since you are migrating, you already have a portfolio of lessons learned -
which is what prompted the question to the group.
I recently migrated a client from 5.X to 6.X and used that as the
opportunity to implement some best practices they had omitted initially. We
implemented a stronger naming convention, included resources for server and
application in each job, improved iterative streams with the use of dummy
jobs and did a general clean-up.
I also looked into reorganizing the processing into a business unit model
with 3 servers instead of a single centralized server.
Since the naming convention included identifying the business unit, there
was really no advantage for operators with the multiple servers. It may, in
fact, make it a bit more confusing for them.
The only real advantage I could identify - germane to this client's needs -
revolved around the new day processing. They had new day starting at 07:00
AM. One of the business units had critical processing right out the chute at
07:00 that needed to be completed as early as possible. Because of the new
day processing, a job targeted for 07:00 often wouldn't start until 07:06 or
later, and there would be a two (or more) minute lag between dependency
resolution and subsequent job start. This business unit would have been
better served if it was on it's own server (or if new day was at some other
Like you, I wanted to keep things as simple as possible. Introducing
multiple servers and multiple databases was not keeping things uncomplicated
from an administrative perspective. What I did was move the New Day
processing to 06:30 while maintaining the 07:00 start for all jobs, giving
the new day processing a half hour window to do it's thing. I also moved
many of the cleanup jobs to other, quieter times (like between 4:30 and
06:00 AM for this shop). Lastly, I introduced the User Daily concept. Using
the User Daily to bring jobs into the AJF at a later time reduced the New
Day load significantly - to where I'm confident that even unanticipated
growth will not affect the critical morning jobs adversely.
Just some thoughts!
Tully Krastins (703) 754-0495 office
CEO/Principal Consultant (703) 753-0117 office fax
Avots International, Inc. (703) 628-0007 mobile/vmail/page
27022 Gum Spring Rd <tullyk@...> email
Chantilly, VA 20152
Consulting expertise for meaningful workload management solutions.
on 12/1/03 5:48 PM, Steele at slwhyte@... wrote:
> Thank you very much for your response ... it is appreciated as any
> input is better than none at all.
> I can see merit in both models and I totally agree when you say the
> less Control-M Servers the better. That is certainly my
> preference ... we have a large organisation with many servers and I
> am attempting to ensure that future growth (looming large very soon)
> can be managed in a way that it does not require 6 Control-M
> Technical Support Administrators.
> My major goals are nothing new to the IT industry but one I feel is
> not adopted enough.
> 1. Minimal Admin
> 2. Ease of use
> 3. Enable future growth WITHOUT having to do rework.
> Easier said than done and only through proper planning we will
> achieve it. This will make it easier for myself and the company.
> In any case I will have to learn from prior experiences and bite the
> bullet very soon.
> For what its worth ... your input was worth at least $1. ... ;o)
> Control-X email list does not tolerate spam. For more information
> http://s390.8m.com/controlm.html DO NOT Spam this list or any members. To
> unsubscribe go to http://groups.yahoo.com/group/Control-X and click on User
> Center. Not affiliated with BMC Software.
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Firstly thank you very much for your detailed response it is much
Yes it's a challenge but one I am more than willing to tackle.
Whether I come out on top is another issue! ;o)
Initial investigations are leading me to believe that I may be able
to use a combination of Business and Enterprise models. While this
may sound strange it may be much easier from an administration
perspective. Eg: Small business groups with no predicted growth are
implemented on an enterprise or communal server. Large business
groups that have the capital, require large volumes of data or
predict considerable growth can use their own server's.
As for the Database sizing I have overcome that issue by adopting 2
1. Standard build comprising 500 Mb Data / 250 Mb Log / 250 Mb
2. Extraordinary large builds 1 GB Data / 500 Mb Log / 500 Mb Tempdb
The large Log & Temp db's (1/2 of the Data component) are to cater
for issues we have experienced in the past and to counteract a
response from BMC stating that those files aren't large enough. As
Disk space is cheap it shouldn't be an issue.
Standards are a way of life and we have implemented many couldn't
and shouldn't operate without them.
As for the New Day process I have inherited a time of 15:00 while
that may sound strange to many it enables the business to correct any
problems from the night before in a timely manner and verify that the
new schedule is accurate before going home of an evening. The only
obstacle to using this method is getting the User's head around what
they regard as a 24 hour period and what Control-M perceives. A minor
issue in the scheme of things.
Like you we use the User Daily process extensively to manage the
scheduling of our batch.
Sounds like there are still a few of us that like getting it right
the first time or at least try to ;o)