Announcement

Collapse
No announcement yet.

Building SQL Server 2008 enterprise cluster for DB Engine and the An

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Building SQL Server 2008 enterprise cluster for DB Engine and the An

    Hi Everyone,

    I am now in the process of building SQL Server 2008 Enterprise failover cluster for use with 3rd party server monitoring application (which also do some OLAP analysis for trends).

    Since this project will be using SQL Server 2008 Enterprise over Windows Server 2008 failover cluster, I wonder do I have to separate the DB engine instance and the OLAP component or just make it as single instance altogether ?

    Any other suggestion and idea in tweaking and performance tuning of this failover clustering on top of VMware ESX will be greatly appreciated.

    Thanks.

  • #2
    Re: Building SQL Server 2008 enterprise cluster for DB Engine and the An

    I see no reason why you can't have it as a single instance unless you have to separate tempdb usage. If both sides of your app are going to use tempdb intensely, and you may need to ensure that they're on separate disks, then you'll want to separate them. Other than that though, there's not much reason to separate them onto separate instances. Having separate instances only complicates your scenario.

    As for ESX... well, that really depends on why you're choosing to make this virtual. It's difficult to say what it'll take to optimize this scenario because there are a lot of factors involved. Generally speaking though, make sure your SQL boxes are physically on different drives. Also, make sure that your separation of of data and log files isn't just logical, but enforce that across to the physical data layer as well. So what I mean by that is this...

    Let's say you have a D and E drive on the ESX server. And you have a single instance of SQL and you want to separate data and log files inside the VM. So you create a VM and put the main VM file on D, and you then create a disk file for the data files and put that on D as well. Then you need to create another disk file and attach it to the VM, only this one will physically be created on E. This way your I/O is physically separated onto different spindles still. The most common mistake I see is ESX admins creating 2 disk files (for data and logs), but putting them physically on the same drive. This does nothing for you.
    Sean McCown, SQL Server MVP

    See my FREE SQL Server training videos at:
    http://www.MidnightDBA.com

    Blog Author of:
    Database Underground -- http://infoworld.com/blogs/sean-mccown
    DBA Rant http://dbarant.blogspot.com

    Comment


    • #3
      Re: Building SQL Server 2008 enterprise cluster for DB Engine and the An

      Originally posted by MidnightDBA View Post
      I see no reason why you can't have it as a single instance unless you have to separate tempdb usage. If both sides of your app are going to use tempdb intensely, and you may need to ensure that they're on separate disks, then you'll want to separate them. Other than that though, there's not much reason to separate them onto separate instances. Having separate instances only complicates your scenario.

      As for ESX... well, that really depends on why you're choosing to make this virtual. It's difficult to say what it'll take to optimize this scenario because there are a lot of factors involved. Generally speaking though, make sure your SQL boxes are physically on different drives. Also, make sure that your separation of of data and log files isn't just logical, but enforce that across to the physical data layer as well. So what I mean by that is this...

      Let's say you have a D and E drive on the ESX server. And you have a single instance of SQL and you want to separate data and log files inside the VM. So you create a VM and put the main VM file on D, and you then create a disk file for the data files and put that on D as well. Then you need to create another disk file and attach it to the VM, only this one will physically be created on E. This way your I/O is physically separated onto different spindles still. The most common mistake I see is ESX admins creating 2 disk files (for data and logs), but putting them physically on the same drive. This does nothing for you.

      Many thanks for the reply man,

      so in this case it seems that the SQL Clustering across two different subnet will not be supported until DENALI is finally around.

      Comment

      Working...
      X