Showing posts with label IOPS. Show all posts
Showing posts with label IOPS. Show all posts

Thursday 24 February 2011

Virtualising SharePoint 2010

Overview:  I was reading Michael Noel's article on "Going Virtual with SharePoint 2010", it is a good read and is very useful in pointing out how to virtualise.  My key point here would be don't virtualise SQL Server you just won't get the IOPS to make it worthwhile.

Nearly 2 years ago I was speaking to the lead architect for a big FTSE 100 enterprise who heavily use SharePoint 2007 at the time.  His key message was don't virtualise the WFE's, I disagreed with him which apparently wasn't a good idea but outside of his single point his claims were not worth accepting.  His key point was you will get a 10-15% (a guess) performance increase using physical over VMWare on the same hardware.  Michael Noel states "Generally, the virtualization overhead required to run virtual servers is only 5 percent".  I can't see any discernable degradation but there will be some performance hit by using a hypervisor.  His farm was rather large but I feel he just didn't trust virtualisation.  Today it's pretty main stream to put you WFE's and application servers on a VM platform.  Especially if it's done correctly as outlined in Michael's article the minor pass thru resource lost is easily made up for with flexibility that VM's offer you namely:
  • Hardware become cheaper you can easily up size you VM's on new hardware with more resources as time move on, you don't need to add more servers to the farm.  I have had several clients start with a part of there business using SharePoint, it's much easier to setup a resilient infrastructure that can be moved over servers using VMotion and upgrade the hardware. 
  • Additional servers are easy to add to the farm as you simply add a new VM onto your hardware.  This is pretty minor but you don't need to do purchasing and the hard yards associate with hardware additions.  If the company has the resources (CPU, memory and disk) it simple to request more VMs or additional resources to existing VM's.  With the cost of hardware halving every 18 months it's a no brainer if your organisation can move to virtualised servers.
  • Disaster recovery is only improved, you may have a bit backup for DR but being able to pull down machines and move them is always useful.
Preferences:
I use HyperV at home as I have only 2 servers and my technet licences give it to me for free.  I merely spin up machines and install the roles I require.  I even VM my AD & SQL box for development. 
On production environments it is HyperV or VMWare for me. It comes down to you engineers experience and preference.  If it is a greenfield project and licencing costs are not a concern I lead my clients to VMWare as I know it better and know it performs and is maintainable.  Saying that I have setup farms using HyperV, this is generally for smaller institutions and it works brilliantly.
Tip: Separate physical network cards for each VM & don't put SQL on a VM.
Tip: Follow Michael Noel's article when virtualising your SharePoint farm and get a virtualisation expert to help you do the setup.


References:
http://www.sharepointproconnections.com/article/sharepoint/Going-Virtual-with-SharePoint-2010.aspx
http://blog.sharepointsite.co.uk/2010/12/sharepoint-2010-boundries-and.html

Wednesday 15 December 2010

SharePoint 2010 boundries and thresholds

I attended a suguk.org event in London about a week ago.  John Timney did the 1st presentation session and asked a couple of questions on SharePoint limits.  I didn't know the answers, tried to think back to MOSS and what I'd seen previously.  The simplest question that I should know the answer to:

Qu: What is the maximum content database size supported by SharePoint 2010?
Ans: Microsoft supports Content databases up to 200GB in size.  In MOSS it was 100GB.  It is fairly common to see content databases considerably bigger than 100GB in MOSS that work.   The issue is how long does it take to perform operations on these content DB's such as backups moving content db's.  If you have a dedicated SAN, there is no reason not to go to much larger content databases however, they are not supported by MS.

More info on SharePoint's boundaries and thresholds from MS

Qu: What I/O speed does MS recommend for your SharePoint 2010 SQL database?
Ans:  I/O operations per second (IOPS).  The faster that SQL can handle request, results in faster return time and reduced que requests, so pretty important and a fairly common bottleneck.  This is often a reason why people choose not to virtualise SQL Server, it I/O intensive in SharePoint and really important to be fast.  Tip: Ensure VM's are thick provisioned for SQL Server. 

To determine you IOPS  use SQLIO Disk Subsystem Benchmark Tool (http://go.microsoft.com/fwlink/?LinkID=105586).

I guest the answer is as fast as possible but you can determine your IOPS requirement using the tool and you usage.  I go with ldf files on the fastest disk on the TempDB followed by ldf files for the content dbs on spinning disks.

Update 09/06/2011
Qu: Should I using seperate disks for mdf (data files) & ldf (transaction logs)?
Ans:  On small SQL server farms ensure that the transaction logs are stored on a different physical drive to the content databases as this will reduce contention and increate performance signigicantly.  Larger SQL instances like SANS have multiple disks so there is no need to seperate the files as this is already done by the nuber of disk readers.  You can also check the performance of a drive by watching the "disk seconds per read/write counters" which should be less than 20ms.  If the disk seconde per read/write is approachiing 20ms consider improving the disk speed or increasing the number of read points.
Update 22/08/2012 - Bigger architectures may use SSD/Flash memory as opposed to disks.  The IOPS are hugely improve as the is no disk search time.  http://technet.microsoft.com/en-us/library/cc298801.aspx#Section1_5a

Qu: What is the default SQL Server database growth setting sizes?
Ans: SQL Server 2008 will grow data files by 1MB and transaction logs by 10% increments.  I would start with an initial content database size of 100MB(adjust according to your anticipated demand) and autogrowth to be 50MB (adjust according to your system).  This general prinipal will result in the growth to the db's being infrequent so the associated performance hit is reduced, unused space being optimised as the percentage growth in the transaction log has huge incremental hit that are generally never reached after initial growth and less fragmented databases results in faster performance. 

More Info:
Summary of limits and thresholds
http://blah.winsmarts.com/2010-5-How_big_can_my_SharePoint_2010_installation_be.aspx
SQL Checklist for SharePoint 2013