I was recently asked to pull the performance metrics for a new SQL cluster at work. In an effort to finally get back to blogging, I thought I’d share my results and how someone else may be able to look at their clusters for ways to improve. I should start by saying that although this analysis was performed on a two-node Windows Server Failover Cluster using Windows Server 2008 R2 x64 (WSFC, formerly MSCS) and SQL Server 2008, SQL-specific metrics are not pulled. Rather, I looked at the Big Four: CPU, Memory, Disk, and Network. The second node in the cluster, Node B, was analyzed because the application using the first node was not in production yet, so we knew that node would barely be utilized.
Using Microsoft System Center Operations Manager (a behemoth in its own right!), I was able to pull the previous six days’ worth of performance data. What I included in my analysis were graphs of performance for seven days, an explanation of what the data was measuring, and somewhat of an average baseline against which to measure.
The original work was presented in PowerPoint. I’ve taken screenshots of the presentation and included them here.
At a minimum, you’ll want to perform regular backups of your vCenter, Update Manager, and System databases. You don’t have to be a DBA to perform simple backups. You don’t need to know T-SQL or database programming to perform these steps. There’s an easy wizard that walks you through a standard Windows Next-Next-Finish set up.
There are a couple things to note in the walkthrough below. We’re using SQL Server 2008 Enterprise Edition 64-bit on a 64-bit Windows Server 2008 SP2 Enterprise Edition. The SQL server is also a virtual machine in a vSphere 4.1 environment.
Hopefully you’ll never have a disaster hit your datacenter, but if you do, this guide can show you how to restore your vCenter database to your latest backup. Your vCenter database holds all the information you see in the vSphere Client and more. Although your VMs will still run your ESXi hosts without vCenter and its associated database, you lose a lot of enterprise functionality.
In my testing, I found the SQL server to which you recover can have a different name. I did not change the name of my vCenter server. All machines involved had different IP addresses and resided in a different domain. All domain service accounts were recreated in the test domain. I’m leaning towards the possibility that the vCenter server can have a different name, as well.
A highly secured Windows installation can make your SQL installation fail
There are some highly modified default installations of both Windows desktops and servers that certain institutions use to increase the security of their networks. These versions of Windows are focused on security and are locked down from the ground up, which is a good thing. But all these security settings can give an IT guy headaches if you’re trying to get things accomplished. One such feature can make your SQL install fail. I happened to come across this recently in a test lab.
If you’re driving along with a standard SQL install, everything will be going fine until, towards the end of the installation process, you see the gem below. And SQL installs take a little time to complete. Having to reinstall can be a real pain.