Datacentre architecture - scheduling, monitoring & auditing

This is the second part of building a private cloud SQL Server infrastructure. The first part was the SQL Server design where there were separate VMs for each SQL Server component (database engine, SSIS, SSAS and SSRS). We then need to make some other architectural decisions.

The organisation used BMC's Control-M as its scheduler of choice (mainframe systems used this). But we still had other jobs that were run under the SQL Server Agent. To keep everything in its silo, we decided to have SQL Servers with no user databases that were just used to run the jobs on the different database servers. This meant that the build for the database engine did not start the SQL Server Agent and that no jobs could be on the servers, only on the scheduling SQL Server. Control-M was also installed on this server to make sure that the whole environment complied to the internal regulations as much as we could. This is a lot more work than you think and getting jobs running across servers was not easy.

Quest Foglight was the database monitoring tool that had been chosen, so we needed to build a monitoring server just for Quest and then install the Quest client components as part of the database engine build.

Finally there was a requirement for auditing, across all database platforms (DB2, Oracle, Sybase etc and SQL Server), IBM Guardium was the product that had been chosen. Therefore we need a VM (or more) for Guardium.

It ended up as abig infrastructure and there were just as many other servers as there were straight database engine servers.