Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
You should also consider any added functionality you may want from the storage – for example, the ability to take snapshot backups, to clone systems for testing, or to virtualise or abstract from underlying RAID groups to avoid the creation of silos of unused capacity. Business drivers such as a requirement to reduce power and cooling to meet green targets may also be important.
Given these factors and the storage systems proposed by the vendors there will be a 'most appropriate' choice of disk type for you.
- To give you some general guidance regarding disk choice:
- The size of hard disks now available means that the number of spindles required for Exchange and SQL systems is typically determined by performance. You are likely to need to buy additional spindles over and above that required for capacity to get sufficient performance.
- Generally Exchange and SQL systems have random rather than sequential disk access profiles and require relatively low latency of response from the disk. As the number of Input-Output operations per second (IOPS) increases so does the latency of response from the disk. Fibre Channel (FC) and Serial Attached SCSI (SAS) disks deliver significantly more IOPS than Fibre Attached Technology Adapted (FATA) or Serial Advanced Technology Attachment (SATA) for the same latency penalty. As a rough guide a FC 15,000 rpm drive is likely to deliver IOPS around 4.5 times greater than a SATA 7,200 drive for the same latency penalty of 20 milliseconds; the 'rule-of-thumb' maximum for Exchange and SQL systems.
To find the right choice for you I suggest you ask the vendors to do the work. Specify your requirements to the vendors and ask them to size and underwrite a solution to meet those requirements. Something along the lines of, "the system must meet the capacity, availability and performance needs of our Exchange and SQL systems and must be sized to meet those needs over a three year lifetime". It's deliberately a high-level statement – the key is to ensure the vendor explains to you all the assumptions made and the sizing inputs used and is clear about the points at which they suggest capacity is added, and the associated costs, to give the lifespan you need.
The sizing exercise should include the following:
- An analysis of the current performance and capacity requirements of your Exchange and SQL systems. Performance counters can be measured in both Exchange and SQL systems and vendor-specific sizing tools used to define 'current state' needs.
- An analysis of the future performance and capacity requirements of your Exchange and SQL systems. This should account for predicted growth rates and the adoption of new functionality, e.g. BlackBerry devices, additional databases.
This was first published in May 2009