Your new network appliance kit has arrived in the data centre. You have ONTAP installed, configured your required parameters on the filer, and are ready to start allocating storage. Though it might appear a simple task to just start creating your volumes and share them out to your servers, one has to carefully plan and consider a few very important aspects before deploying storage to applications. This article describes the most important factors to consider in sizing and deploying volumes on a Netapp Filer.
The usual questions that a storage administrator faces before creating and deploying volumes are,
- Should I create one big volume using all my disks or should create smaller volumes as and when required?
- How big should be my raid groups? What problems would I face, if I have a huge raid group?
- How many hot spare should I have on the system?
- Can I have my data on the root volume or should it be separated?
Determining the right answers to these questions, would help in planning your storage for availability and performance.
One can create a volume from anything between 2 disks to the maximum size supported by the filer and ONTAP. A storage administrator can either opt to create one big volume using multiple disks and then divide it for various applications/shares using qtrees, or can create smaller sized volumes and then provide each application with one volume. The factors a storage administrator would have to consider before choosing one of the two strategies above are:
Business requirements for separation
This should be the first aspect that should be considered. Data that needs to reside on two different volumes, for business reasons, should be deployed on two different volumes. For example, a company might require a database and an application to reside on two different volumes, completely separated from each other.
Backups on a Filer are usually performed by volume. If there is a requirement to backup the filer by volume, then the size of the volume could play a major part in determining the time taken for backups. In such a scenario, volumes of more than 500GB are highly unadvisable. One should also take into consideration the time taken to recover a volume from these backups, in the rare chance of a double disk failure. Large volumes account for longer restore times and hence longer down time.
As snapshots on the filer are done by volume, volumes with similar snapshot schedules can be grouped in one volume while those with different snapshot schedules have to be deployed in different volumes.
If there is a requirement to snapmirror data by volumes, then it is easier to have to multiple smaller volumes than one big volume. This would reduce the time taken to update the mirror when a full copy/restore is required. This would also be the case if one intends to do a volume copy.
Once you have arrived at the correct strategy to determine the size of your volumes, choosing the correct raid group size for the volume would be the next step in planning your storage deployment. Though the size of the raid group would very much depend on the size of the volume one intends to create, it would also depend on the size of the disks cost, and reconstruction times - the last factor being the most important.
Netapp uses RAID-4 for its data protection, which means one drive is used for parity in every raid group. For example, a raid group size of 8 would mean 7 disks are used for data and 1 disk for parity. Having a smaller raid group would mean that, in the event of a disk failure data can be reconstructed at a much faster time. The smaller the reconstruct time, the better as another disk failure during this time would mean a complete loss of data. This luxury though comes at a price, as one disk an every raid group would be used for parity.
Depending upon the reconstruction times you can afford and the cost you can afford a decision on the raid group size can be made. Raid group sizes of greater than 8 are usually not recommended by Netapp. Netapp have recently introduced RAID-DP, which Raid-4 with two parity disks. RAID-DP can be used if a high availability is required, but that would be at the cost of two disks being used for parity rather than one.
It is always preferred to separate the root volume from the data volumes on the filer. For optimal management, it is better to restrict the root volume to just 2 disks (minimum required for a RAID-4 parity group). This enables faster reconstruction times in case of a disk failure on the root volume.
Hot spares on a Netapp filer come at the price of not being able to use them as data disks. Though it might be technically sufficient to have just one hot spare disk on the entire system, one should to have the correct number of spares to increase availability from the filer. The following guidelines can be taken into account when designating hotspares,
- Have at least one hot spare for every disk of a different size on your filer. Remember that a hotspare disk of 72GB cannot replace a failed drive of 144GB. Though a spare disk of 144GB CAN replace a failed drive of 72GB, only 72GB on the 144GB would be used.
- To increase availability, a hot spare disk for every 14-20 disks would be recommended.
- Do not create volumes before they are required.
Having the disk as just spare disks increases the availability of your filer. One can always add disks into existing volumes or create new volumes without disrupting the filer.
Although these recommendations and guidelines would suite most environments, planning decisions might differ from environment to environment basing on Filer hardware, ONTAP and business requirements. Considering the above mentioned parameters like Volume size, raid group size, hot spares and root volume size would definitely help you plan a better deployment.
Find your next job with techworld jobs