Storage Management Strategies for the CIO
Planning for any form of centralized storage can be a daunting task, either you are in a position where you have to deploy it immediately and end up with a tangled mess of files, folders and connections, or you are in a protracted four-year planning cycle where every potential issue has an associated taxonomy diagram.
Following are some
Requires Free Membership to View
NAS planning basics, starting with location. Make sure you've identified and
visited in person where you are going to physically house the device, make sure the location has
adequate power, cooling and network access and be sure you have the physical room to install an uninterruptible power supply (UPS) along with your NAS device. Often times some
branch office NAS devices will end up in the maintenance closet, along with high humidity, dust,
poor power supply and a network cable that doubles as a mop hanger. While not high on most
engineers list of to-dos, the lack of power, cooling and access can turn even the best-planned
implementation into an expensive nightmare.
Power is one of the most basic needs of a NAS system. If you are not locating your NAS device in a colocation facility or data center, be sure you pay careful attention to the power requirements for your device when configured with its maximum load of disk -- this is key. Your system will grow, and if you plan ahead for supporting the maximum electrical capacity of your chosen device, you will save yourself the potential for downtime and costly construction. Planning for a UPS that can support your NAS for 10 minutes longer than it takes for it to shutdown is also a good idea. It's important that you plan for brownouts and surges, and upgrade your UPS when you add shelves to your NAS system.
 |
||||
|
|
|||
|
||||
Be sure you have adequate network bandwidth for your proposed usage. Flip back to the tip on interconnects for a good rule of thumb when sizing network bandwidth. If you have a hub-and-spoke style WAN layout, consider using compression and WAN acceleration devices that will reduce the impact file traffic will have when coming from your branch offices back to your central location. Depending on the device you've purchased, you may need more than one port and IP address. Some NAS devices aggregate multiple network connections to offer higher performance, so plan contiguous ports on your network switch for this type of expansion to reduce complexity and to ensure an easy bandwidth upgrade path.
Planning for storage allocation at the onset may cause planning paralysis. Do not, under any but the most extreme circumstances, preallocate all of your disks the instant your NAS arrives, especially if it is your first implementation of centralized storage. You will be tempted to carve it up and give all the business units or departments their share right up front and then forget about it, but this will lead to under-allocation. Under-allocation with no free disks mean your users will get a dreaded "out of disk space" error. While you will have the technical ability to expand the volume you've created, you will have no disk to expand it to. So if marketing has a big ad blitz going on, you are going to be their least favorite person. Over-allocation is a little more difficult to deal with because while expanding volumes is technically possible, most common file systems will not let you shrink them. So, if you've given 100 GB to accounting and it only uses 4 GB , you will have to copy that 4 GB off the volume, destroy the volume, recreate a smaller volume and then copy the data back and reattach it to the server.
Thin provisioning, which I covered in the RFP tip, will help with this problem.
About the author: Tory Skyers is a senior systems engineer for Prudential Fox & Roach Realtors, an independently owned and operated member of The Prudential Real Estate Affiliates Inc. He frequently speaks at conferences such as Storage Decisions and also contributes regularly to SearchStorage.com's blog called Storage Soup.
Go back to the beginning of the NAS handbook.
This was first published in April 2008
Join the conversationComment
Share
Comments
Results
Contribute to the conversation