March 14, 2011 at 10:52 am
I have been tasked with moving our SQL server estate onto new 64bit SQL 2008 Virtual servers on a VM base. Each Virtual server will be attached to our SAN that i will have no control over. Do i ask for multiple LUNs pretending that there is a C:(OS), E:(temp), F:(Data) and G:(log) disk structure or do I just present a very big space as a single C: drive and let it go. We are consolidating lots of old physical servers onto fewer (more powerful) virtual servers (according to the VM and SAN administrators)
I have been searching the internet for comment / advice and at the moment I can boil most of what I have read down to
1. Configure your SAN properly
2. Don't overallocate shared resource
all advice, experience and opinion gratefully received and read
March 14, 2011 at 1:20 pm
Martin Stephenson (3/14/2011)
Do i ask for multiple LUNs pretending that there is a C:\ (OS), E:\ (temp), F:\ (Data) and G:\ (log) disk structure or do I just present a very big space as a single C:\ drive and let it go.
Its depends on a lot of factors...
What type of SAN is it? If your SAN does virtualized peer storage (Bing EqualLogic) then a single C:\ will be fine and will save you a ton of research and decisioning. If you are using a SAN where you're managing physical spindles (i.e. spindles are not virtualized in the SAN) and you are forced to worry about spindle-isolation then you should seriously consider having separate volumes with dedicated spindles behind them for OS, tempdb, data and logs with appropriate RAID levels for each.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 15, 2011 at 9:26 am
HP EVA 4400, which gives us virtualised storage, my take on this is that it makes my life easier.
I am tempted to create an OS drive and a Data drive to help me manage things and protect the OS because developers and application administrators have been known to fill every available byte given to them with very important data that stops the databases from working due to having no space.
March 15, 2011 at 9:39 am
Martin Stephenson (3/15/2011)
HP EVA 4400, which gives us virtualised storage, my take on this is that it makes my life easier.I am tempted to create an OS drive and a Data drive to help me manage things and protect the OS because developers and application administrators have been known to fill every available byte given to them with very important data that stops the databases from working due to having no space.
I am big fan of virtualized storage when the system does not require the granularity of control isolated spindles offers. Having an OS volume separate from a Data volume to protect against drive fill-ups is definitely a good call.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 15, 2011 at 2:38 pm
have a look at http://sqlblog.com/blogs/jonathan_kehayias/archive/2010/11/22/virtualizing-sql-on-vmware-reference-list.aspx
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
May 20, 2015 at 9:29 am
You might also consider a separate volume for your temp Db and log files. :w00t:
May 20, 2015 at 9:54 am
Martin Stephenson (3/14/2011)
I have been tasked with moving our SQL server estate onto new 64bit SQL 2008 Virtual servers on a VM base. Each Virtual server will be attached to our SAN that i will have no control over. Do i ask for multiple LUNs pretending that there is a C:(OS), E:(temp), F:(Data) and G:(log) disk structure or do I just present a very big space as a single C: drive and let it go. We are consolidating lots of old physical servers onto fewer (more powerful) virtual servers (according to the VM and SAN administrators)I have been searching the internet for comment / advice and at the moment I can boil most of what I have read down to
1. Configure your SAN properly
2. Don't overallocate shared resource
all advice, experience and opinion gratefully received and read
It all depends on whether the SQL server data volumes will be VMware virtual disks or Raw Device Mappings presented to the VM.
Virtual disks act as separate entities and can be pinned to separate ESX data stores, the problem is that these data stores usually service virtual disks from lots of other virtual machines of possibly differing types (exchange server, file server, application server, etc). Virtual disks are flat files and do have their limitations especially when hit with random I\O workloads.
Be mindful of presenting too many virtual disks, as these disk require a virtual disk controller, this itself is a software representation of a physical disk controller and runs as a software process on the host server. All of this takes valuable CPU time and RAM resources from the host.
Raw device mappings are straight to the storage layer and are managed by the storage layer itself, not the software disk controller. They'll generally handle random I\O a little better but even so, with any virtualisation exercise you need to account for the fact there will be an overhead over the physical equivalent.
Remember, virtualisation is a consolidation technique not a performance technique, when done properly you can attain sensible performance levels. Get it wrong and you'll have even more smoke to cloud your vision when attempting to troubleshoot
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply