Loading ...
Sorry, an error occurred while loading the content.

RE: [Control-X] Control-M Distributed Architecture Business models

Expand Messages
  • Tom.Westbrook
    From a purely admin perspective, the fewer software installations the better, also the fewer CM Server databases the better. From a business perspective, it
    Message 1 of 5 , Dec 1, 2003
    • 0 Attachment
      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

      -----Original Message-----
      From: Steele [mailto:slwhyte@...]
      Sent: Sunday, November 30, 2003 4:59 PM
      To: Control-X@yahoogroups.com
      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

      migrating to

      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
      machine

      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 ...

      Steele



      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/
    • Steele
      Tom, 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
      Message 2 of 5 , Dec 1, 2003
      • 0 Attachment
        Tom,

        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)
      • Tully Krastins
        Steele, I can appreciate your struggle and recognize your goals as noble! Your first two goals are what they are. Perspective determines each! ;-) Your third
        Message 3 of 5 , Dec 2, 2003
        • 0 Attachment
          Steele,

          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
          time).

          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!

          HTH.
          Tully

          -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
          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:

          > Tom,
          >
          > 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/
          >
        • Steele
          Tully, Firstly thank you very much for your detailed response … it is much appreciated. Yes … it s a challenge … but one I am more than willing to
          Message 4 of 5 , Dec 3, 2003
          • 0 Attachment
            Tully,

            Firstly thank you very much for your detailed response … it is much
            appreciated.

            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
            standards.

            1. Standard build comprising – 500 Mb Data / 250 Mb Log / 250 Mb
            Tempdb
            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)
          Your message has been successfully submitted and would be delivered to recipients shortly.