|Top three storage consolidation lessons|
While not specific to consolidation, it's important to note that the implementation of an enterprise storage management team will have a cultural effect on your staff. For example, your server team will no longer own the storage attached to their servers (e.g., DAS), and must learn to deal with the new kid on the block--the enterprise storage management team. Similarly, the network team may take issue with not managing all networks, including the storage network. These are significant issues that need to be addressed up front.
Policy planning. Prior to beginning a consolidation effort, policy issues must be addressed. Hand in hand with the justification for the enterprise storage management team is the requirement for strategic and tactical storage policies, along with associated standard operating procedures. One of the more obvious areas is specific to storage provisioning. Assuming the consolidated storage infrastructure is implemented, the next steps are allocating and provisioning storage to the servers and applications that require it. Naming conventions, allocation processes, data protection and documentation are just a few of the tasks related to storage provisioning. "Winging it" at this critical juncture of the consolidation project isn't acceptable. Having policies and procedures in place will make the multiple decisions required in a complex task such as storage provisioning much more straightforward.
Data migration. One consolidation task is to have the consolidated storage infrastructure built and ready to go. A totally different task is to get your application data migrated. Beyond just considering the pure volume of data to be migrated, take a look at some other important items that need to be considered and weighed, such as the number of files (e.g., many small files could make the migration take much longer, depending upon the approach), the different migration options (tape, network, mirror) and the data migration windows. The initial location of the servers and storage is also a major consideration, and often dramatically pares down the available migration options. Conducting dry runs to benchmark how long a data migration may take is strongly recommended; all too often, the data transfer spreadsheets you create are more theoretical than practical.
Risk mitigation. Even the most detailed and well-thought-out storage consolidation projects are full of hidden perils. What if a data migration hiccups in the last minutes of a five-hour data transfer? What if the application testing team finds some post-migration issue that isn't remotely related to the new storage infrastructure? What if the I/O performance in the consolidated environment is taking a beating due to multiple, disparate standalone applications simultaneously hitting the shared, consolidated storage infrastructure? It's important to have Plan B and Plan C ready so you can respond to those "keep our fingers crossed it never happens" scenarios.
Change control. Don't underestimate the level of participation required for storage consolidation. While it may be obvious that internal change-control processes and policies must be strictly adhered to, the number of coordination touch-points for storage consolidation activities is usually higher than for other change activities. For example, a consolidation effort may include the application owner; database, server and network administrators; the enterprise management storage team; and probably the data center manager and a project/program manager or two. Depending upon the activity, storage vendor product engineers may also be part of the equation. Proactive coordination is critical to success.
Unique issues with DAS, SAN and NAS
There are also specific issues that are dependent upon the current state of the storage being consolidated. For example, DAS doesn't require external HBAs, as the storage is internal to the server. If your consolidation project includes many DAS servers and applications, then it's important to determine if those servers have I/O backplane slots for the appropriate number of HBAs. In addition, it's best to standardize on a small number of HBA products--possibly by operating system and/or server type. In a multipathed, high-availability, dual-HBA environment, the cost of these HBAs can have a big impact on the consolidation project budget if a significant number of HBAs are required.
Compared to consolidating DAS, SAN environments offer different challenges. There's a high probability that the consolidated environment won't be new, as the goal is often to utilize as much existing SAN hardware and software as possible. Tough decisions need to be made, such as whether the fabrics should be merged or if it's better to create a totally new fabric.
It may also be necessary to decide if HBAs should be standardized or if old ones should be "grandfathered in" for the sake of capital cost (give operational and management costs due consideration when tackling this issue). And if your SAN comprises a multitude of arrays from different vendors, it's a perfect time to start planning for a tiered storage environment.
Consolidating NAS can range from buying larger filers to moving toward NAS gateways that can use the consolidated SAN infrastructure for its storage requirements. It may also be a good time to take a serious look at iSCSI, depending on the block- or file-based requirements of your specific applications. Give careful consideration to the storage services you're using on the new consolidated storage infrastructure and see if you can leverage some of the same software in your NAS environment, rather than having separate sets of software for each environment.
Other issues to consider include the opportunity to revisit storage virtualization strategies, the pros and cons of doing server and storage consolidation at the same time, and understanding what applications/environments may not benefit from consolidation.
The cost savings of storage consolidation can result in a fairly rapid return on investment. But a lot of upfront work is required to ensure a successful deployment that reaps the benefits of these activities.
This was first published in April 2005