Difference between revisions of "NetApp Volume"
(→Naming Volumes) |
(→What are Volumes?) |
||
| Line 3: | Line 3: | ||
The best way to think of a NetApp volume is to imagine a folder in Windows. All of the disk/RAID configuration is already taken care of, your partitions are set, and you're ready to start laying down some data. Rather than just throwing files around all over the place, you use Volumes (like folders) to sort your data. The big difference between a traditional folder and a volume is that a volume has a set size. Imagine if you went into a folder's properties and said "you can't be over 50 GB", that's what a volume is like. Not only do we say that the volume can't be over 50 GB, we actually fix its size at 50 GB. When you start talking about enterprise storage, you realize that you are able to thin-provision just about everything if you wanted to. '''NEVER THIN-PROVISION VOLUMES'''. Volumes should always be set to '''RESERVE''' their full space upon creation. | The best way to think of a NetApp volume is to imagine a folder in Windows. All of the disk/RAID configuration is already taken care of, your partitions are set, and you're ready to start laying down some data. Rather than just throwing files around all over the place, you use Volumes (like folders) to sort your data. The big difference between a traditional folder and a volume is that a volume has a set size. Imagine if you went into a folder's properties and said "you can't be over 50 GB", that's what a volume is like. Not only do we say that the volume can't be over 50 GB, we actually fix its size at 50 GB. When you start talking about enterprise storage, you realize that you are able to thin-provision just about everything if you wanted to. '''NEVER THIN-PROVISION VOLUMES'''. Volumes should always be set to '''RESERVE''' their full space upon creation. | ||
| − | If you mess up volume thin-provisioning, you can take an entire aggregate down with you. If you mess up thin-provisioning inside of a volume, then only that volume is affected. | + | If you mess up volume thin-provisioning, you can take an '''entire aggregate''' down with you. If you mess up thin-provisioning inside of a volume, then only that volume is affected. |
== Naming Volumes == | == Naming Volumes == | ||
Revision as of 00:22, 30 October 2011
What are Volumes?
The best way to think of a NetApp volume is to imagine a folder in Windows. All of the disk/RAID configuration is already taken care of, your partitions are set, and you're ready to start laying down some data. Rather than just throwing files around all over the place, you use Volumes (like folders) to sort your data. The big difference between a traditional folder and a volume is that a volume has a set size. Imagine if you went into a folder's properties and said "you can't be over 50 GB", that's what a volume is like. Not only do we say that the volume can't be over 50 GB, we actually fix its size at 50 GB. When you start talking about enterprise storage, you realize that you are able to thin-provision just about everything if you wanted to. NEVER THIN-PROVISION VOLUMES. Volumes should always be set to RESERVE their full space upon creation.
If you mess up volume thin-provisioning, you can take an entire aggregate down with you. If you mess up thin-provisioning inside of a volume, then only that volume is affected.
Naming Volumes
Volume naming is something very dear to my heart. Please, standardize your volume names and realize that we will be using these volume names in conversation, so make them readable. Here are some CIO standards:
For SQL or Exchange, you need 2-3 volumes. Use the volume name suffixed by SQL, Logs, or SnapInfo. If you're talking about Exchange or a non-SQL app, suffix the first volume with DB. For example:
PandoraSQL, PandoraLogs, PandoraSnapInfo
ExchDB, ExchLogs
For SnapVaulted volumes, you add sv_ to the original volume's name. Example:
sv_PandoraSQL
