Here is my two cents, based on my experience:
* Database and EM and Server on seperate boxes
* Server/EM should be 64-bit, 8GB of RAM, 4-cores
* Database should be 64-bit, 8GB, 8-cores (though keep in mind SQL licensing costs here)
* Virtual is OK, but physical rocks. Don't virtualize your DB!!!
Why such beefy requirements? Because Control-M is a chatty app, and you get a lot of users logged in you can really start putting a load on the system.
Ok. Following are my server specs(that server hold the entire product: DBS and components):
-Windows 2008 Server R2(Virtualized server)
- 2.5 Intel processor(4 cores)
- 8GB RAM
- 80GB HArd Disk
- MS SQL Server 2008
- Virtual memory is set to 3X the physical memory
- Control-M V7 Installed
Do you think those specs are good or should i increase them?(i feel the server is running slow and most of the time the processor is on 100% and the memory is 75%)
DB, Server and EM on the same machine -- that's too much for a production environment. How many jobs a day are you sending through it?
We have around 470 jobs per day in the EM(80 of them are ciclic, executing each 2 min). I dont know if having all components in the same machine is too much load for the server, but the BMC Certified Engineer that migrated our CTM version to V7 told us that there were no problem having all the components and DB in the same machine.
Note: in a near future, we'll have like 1600 jobs in the production environment.
Hardware is not as important as design of your solution.
IF possible, get replicated SAN storage (between your disaster recovery and primary sites), present as F or some other drive.
Build two-node Microsoft cluster and install MS SQL 2008 R2 (cluster install, DBs on SAN drive, descriptive, virtual sql hostname, like controlmvir)
Install Control-M in the same resource group as SQL but with different IP and virtual host, bmc-control-m, for example. Follow Control-M cluster install guide for Windows. Install will ask which hostname (cluster hostname) to bind to. Also, Gateway needs to be added manually at the end of install as cluster generic app with bmc-control-m parameter (to reference your virtual control-m server) - don't use physical hostname for/as gateway name.
Set cluster resource dependencies as you see fit - for example, don't let Agent restart bring your control-m server down and up every time you do it (affect option).
Like Rob said, do NOT run MS SQL db in Vmware.
As far as hardware is concerned, get TWO identical HP blades with two sockets, six or more cores, 32GB of RAM each (since you are planning to run all Agent CMs from one box - don't really recommend it) because MS SQL likes to cache DB; you can restrict what physical CPUs/Cores SQL uses. The same goes for RAM - give it half but not all. SQL licen$ing comes into play as well - if you have two non-clustered boxes with SQL, you will have to BUY two MS SQL 2008 licenses, which could be pricey if you are not using CAL licenses and are paying per socket, or worse, cores! MS SQL is not free and is not included with Control-M.
That's it. Test your fail-over several times to make sure things fail over properly. I have been using MS cluster Control-M solution since 6.2.01 came out. Works great. Our workload is the same as yours about 2,000 job in production, with many cyclic jobs.