One of the requirements is that SCOM R2 runs its databases on SQL Server 2008 or higher. Many times however, people run SCOM R2 based on SQL Server 2005. Which is OK on itself, but a show stopper when migrating to OM12 RTM.
So I have given it good thoughts. And came to these conclusions:
There is another caveat to reckon with:
- Many times these SQL 2005 servers are running Windows 2003 server as well which isn’t supported by OM12 either. This introduces new challenges:
- Updating Windows 2003 Server to Windows Server 2008 R2 isn’t possible, only like this: W2K03 > W2K08 > W2K08 R2. This is a scenario you don’t want to go into, at least I don’t. It’s too prone to error.
- Some times these servers run a x86 version of the OS and SQL. However, x64 is the way to go these days. The time x64 was unreliable is long gone. And there isn’t an upgrade path from x86 to x64.
Other things which come into play and require serious thinking and answers are:
- Many times these SQL 2005 servers are physical entities. Which means they’re there for some years now. Is it really worth it to use this hardware again (think about support contracts and the like) or is this THE time to replace them;
- With OM12 the RMS is gone, so that SPOF is taken care of. But what about SQL server? When you run it now as a single server it’s a SPOF. Perhaps there were good reasons for it when SCOM was installed, but do those same reasons still apply today? Or has monitoring become more business critical, thus requiring a High Availability solution like a SQL Cluster?
- Don’t decide this yourself. Involve management into it and let them make a (written) statement. This way is has been given proper attention.
- Don’t decide this yourself. Involve management into it and let them make a (written) statement. This way is has been given proper attention.
- When SCOM was installed, virtualization was only starting. Now it’s much more common. Perhaps you can virtualize your SQL server for OM12? Of course, proper investigation is required, like:
- What does Microsoft say about it?
- What does your SAN administrators tell you about the IO and so on?
- What does your Hyper-V (duh!) administrators tell you about the performance of their VI?
- How many Objects are you going to monitor with OM12?
- And so on…
So based on these questions above, many times simply (NOT!) upgrading your current SQL 2005 Server to SQL Server 2008 (or higher) isn’t the way to go. Instead, another scenario comes into play, one where a NEW SQL server (or cluster!) is provided and uses as the new SQL server for your current SCOM R2 environment, thus paving the way to an upgrade to OM12 RTM.
And seriously, even when you don’t want to upgrade your SCOM R2 environment to OM12 but start fresh, there are still some good reasons to move to SQL 2008 (or higher), like better performance and the lot.
Therefore in a new series of postings I will take you all by the hand and move SCOM R2 databases from a SQL 2005 Server to SQL Server 2008 R2. So stay tuned!
No comments:
Post a Comment