Virtualization, what to expect

  • Right now we have an OK sized database, it's about 200GB of warehouse data, and 20GB of OLTP type data. We are running it on a dual CPU Xeon CPU with 4 cores each with a pretty basic storage setup due to limited funds... we have two array controllers one for the system and data and one for the logs... the data controller has two arrays... a RAID1 for the system and a RAID1+0 for the data and the other controller is RAID1+0 each controller has six 147GB drives on them.. pretty basic setup with 12GB of RAM and SQL Server 2008 Standard. This has worked out OK for us so far... but we are now doing system upgrades and moving anything we can to a virtualized environment.

    We currently are using ESXi hosts with failover / redundancy with two shared storage systems (HP P2000's) all through redundant fiber channel connections.

    We never looked at virtualizing SQL Server but with the cost of SQL Server 2012 being so high per core now, we are thinking it might be time.

    Our system would have all the data stored on the shared storage, and broken up into logical arrays one for the OS storage, one for the data storage one for the log storage, and one for tempdb. We wanted to dedicate 32GB of RAM to this system, which is a big increase over our current 12GB... but when it comes down to processor setup, not sure what to do, since we have a minimum 4 core purchase for 2012 standard, we assumed set up 4 virtual processors (our host will be a 2 CPU system with 6 cores on each CPU as the base setup right now and have 64GB to 128 GB of RAM total).

    Are there any considerations we need to take into account for this type of setup? We are a little lost on the disk setup, as there are multiple layers to get to the physical media, you have the ESX Drive storage, the storage array setup, the host setup, then the physical disk... We always did our disks as 64K sectors to match up with the page size (and with the offset in older windows to make it align right) but not sure what you have to do in this type of setup...

    any suggestions or things to look into before we decide on this route?

  • Hi,

    there are a number of things to consider when going virtual with SQL Server and if this is new

    territory you should consider training.

    I went down this route a couple of years ago and did some online training with Brent Ozar, it made

    all the difference in the world. It will give you more confidence when making decisions.

    Check out:

    http://www.brentozar.com/services-we-provide/training-videos-online/virtualization-sans-and-hardware-for-sql-server/

    One of my favourite links, how to know when vmware is making your SQL Server slow:

    http://www.sqlskills.com/blogs/jonathan/querying-the-vmware-vcenter-database-vcdb-for-performance-and-configuration-information/

  • You havent mentioned about DR?

    Some good things

    Recovery in terms of complete windows server will be so easy in virtualization.

    Regards
    Durai Nagarajan

  • I'd agree training can be important and Brent is great. Relatively few hours with his company might save you a lot of headaches later and teach you some things.

    In terms of the storage, if you are separating, make sure it's really separate at the SAN level. To often people put disks in a pool and then carve up the pool, saying these are separate LUNs, but the same physical drives. That can work, but it can be an issue as well. Your workload will matter, but I'd look for physical separation.

    In terms of the virtualization, it sounds like you're OK, with more RAM and depending on what your other hosts do, the CPUs might be fine. However, you'll only know from testing your workload. You could do a restore on the virtual and replay some traces to see what happens in terms of performance. We did a similar upgrade here, moving SQLServerCentral from a dedicated box to a shared, virtual environment, but with more resources allocated. It worked, and continues to work, well.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply