SCOM Server Consolidation
Hello,
In this moment my SCOM Environment is realized by virtual servers: one RMS Server ( 8GB RAM ) , one SQL Server (8GB RAM )that keeps beside OperationsManager and DataWarehouse a lot of other Databases and a Reporting Server. There is the plan
to consolidate all SCOM to a single 16GB Server Quad Core CPU. There are around 150Agents .
What is your opinion about this? What would be the best order to migrate the DB and the RMS role.
Best regards,
May 11th, 2011 11:20am
I guess thats possible. I am guessing you have a reason to either move to a single physical box or getting rid of the two virtual machines (and at the same time have a physical available to take the load).
I would try to move all SQL roles first (follow the tecnet articles on this and make sure you read very well first!). Next you could install the management server on this machine. Transfer the RMS role. Perhaps install other things like web console perhaps
dashboarding software or third party monitoring tools on top of SCOM. Re-target all agents to the new box of course if you plan on removing the virtual management server completely (if you keep it than you could bring it down to 4 GB ram and point all agents
to it). I guess that would do it.Bob Cornelissen - BICTT (My BICTT Blog)
Free Windows Admin Tool Kit Click here and download it now
May 11th, 2011 11:41am
Hi,
Thank you for your opinion.
I have 2 reasons:
- have the environment monitored from a place not stored on the Hyper-V infrastructure that it monitors
- not have another 17 database in the same instance with SCOM DB writing data on the same disk (this was implemented before I took the administration of SCOM from this company)
I will try to keep the Reporting and have one MS on Server the Hyper-V with failover to RMS for the agents and Gateways (this will depend more or les by the customer, I will try to explain him the benefits)
Also I will limit the SQL Memory to 8 or 10GB on the Physical Server otherwise it will use all the memory.
PS: before doing it.. i will do a checklist trough a test environment.
May 11th, 2011 2:20pm
Hi
I think your plan is sound - unless you have a lot of reporting requirements then I suspect there won't be any issues with having reporting services on the same SQL server and it will help with SQL licensing (ideally OpsMgr needs its own SQL Reporting Services
instance due to the way it changes SQL Reporting Services security model).
Configure the agents to use the Secondary Management Server as their primary to keep load off the RMS will help further.
General reccomendations are here:
http://technet.microsoft.com/en-us/library/bb735402.aspx
As for order of moving the components - it doesn't really make any difference though my preference would be the same as Bob - to move SQL database first. I'd personally not use the technet article for moving the databases as it does have some "nuances"
(like doing a backup before stopping the services and deleting the databases before you know the move has completed). I'd follow Kevin Holmans article for this:
http://blogs.technet.com/b/kevinholman/archive/2010/08/26/moving-the-operations-database-my-experience.aspx
http://blogs.technet.com/b/kevinholman/archive/2010/08/25/moving-the-data-warehouse-database-and-reporting-server-to-new-hardware-my-experience.aspx
Good Luck
Graham
View OpsMgr tips and tricks at
http://systemcentersolutions.wordpress.com/
Free Windows Admin Tool Kit Click here and download it now
May 11th, 2011 2:50pm
Thank you also.. I have seen that with the delete od the DB... but I would not have done that
:))
In general I read Kevin`s Blog and also the one from Marnix Wolf but.. appears that I missed those ones or I did not remember
them!
So... in general make a plan keep in mind the article, start SQL move with Opsmgr then DW then RMS.. and with some luck.. all should be ok.
Now I wait for the final GO from the client J
May 11th, 2011 3:48pm
Thats it Adrian. Good luck!Bob Cornelissen - BICTT (My BICTT Blog)
Free Windows Admin Tool Kit Click here and download it now
May 12th, 2011 3:38am