• Soren Nielsen (1/4/2012)


    Hi all

    I'm looking for some feed back in regards to the below mentioned challenges. In our organisation we have over the last 5 years mainly done scale up, i.e. tried to host as many DB's as possible on large clustered instances (SQL 2005 EE).

    With a new IT manager this strategy have changed slightly into a combined scale up / scale out approach based on scale up on large VM-ware ESX hosts and scale out via more SQL instances on VM's as we have had before. The strategy is to have the entire datacenter in VM-Ware.

    So I'm challenged with building the SQL template servers for this new infrastructure, so logically I'm looking into standardization as much as possible.

    A bit background info:

    We are a medium sized business with 450 users and around 200 servers in total including all test, acceptance test and production systems. The number of SQL instances we have is around 20, hosting around 150 databases, with the biggest being around 230 GB.

    The hardware:

    12 * 3GHz Xeon CPU's

    100 GB of memory

    Disk platform:

    IBM V7000 SAN

    Tier1 and Tier2 storage is identically duplicated at our DR site. Tier 1 storage has 150 spindles (560 GB), but not dedicated to SQL alone, thus shared with file servers and exchange. Tier 2 storage has 60 spindles (1.8 TB), mainly used for non critical production systems as well as acceptance test and test systems.

    As of what I know now our SQL platform will be hosted on 4 servers of the above mentioed hardware, and have their storage in the tier 1 storage. The LUN presented to the VM-Ware hosts would have a size of 500GB to 1TB

    Until now we have split tempdb, data and log files on our large database clusters as per Microsoft recomendations. Even though they were seperate LUN's inside the same SAN storage disk pool. For the disk layout in the new platform I was initially in favor of

    a simpler setup with only a single drive, since all logical drives inside the VM is residing inside the same LUN. Or does it still make sense to split tempdb, data and log? I have seen statements on the later arguing that Windows will be able to perform parrallel disk access in case of multiple drive usage at the host level. But is this really the case?

    I know this is a slightly religious discussion, but I of cause also don't want to create a foundation that are bad from the outset. On the other hand if there is no performance benefit, I would like to avoid the additional management and space loss with the three drive letter allocation per instance.

    So what's your take on this what would you do?

    Best regards

    Søren Udsen Nielsen

    Ok, you've got 4 large esx boxes, and a large shared pool disks (Raid 10, I hope!)

    What number of IOPS do you require for all your sql servers? Can the ESX boxes handle the io with fewer HBA's?

    As for splitting the files across multiple drives, I'd recommend putting your tempdb (both data and log) on a seperate volume. If you need to add another tier of storage that is SSD based, you can easily move tempdb to the faster tier.