Unfortunately, storage consolidation isn't as simple as buying a large, enterprise-class storage array and migrating applications to the new platform. In a nutshell, a consolidation project follows the three Ps: process, procedure and policy. Whether a consolidation project involves DAS, SAN or NAS, there's a commonality to the approaches in addition to the expected differences.
There are multiple options, protocols and architectures that may be employed to achieve a consolidated storage infrastructure, but we'll use a Fibre Channel (FC) SAN as the option of choice. While not all-inclusive, some of the top items to consider before embarking on a consolidation project include the following:
Tiered storage. It's best to implement a tiered storage infrastructure while consolidating. Much work is required to implement a tiered storage architecture, such as classifying data and understanding the value of data over time. But having the infrastructure in place early on--even if some educated guesses are
Common data protection. It's much more straightforward to create and manage a common data protection scheme for operational and disaster recovery (DR) purposes and for a consolidated storage environment vs. a distributed one. Consider moving large backup jobs to the storage network rather than running them on the LAN. It may also be the perfect opportunity to integrate a disk-based backup architecture. For DR, consider creating a storage tier that seamlessly supports replication to a remote site. In any case, having centralized control and management will simplify and streamline the processes.
High availability. Availability becomes a greater concern because storage consolidation is akin to putting "more eggs in one basket." The storage network should keep running in the event of a minor malfunction such as a host bus adapter (HBA) or cable failure. Techniques such as dual HBAs with multipathing software, dual fabrics and resilient connectivity paths should be implemented if they weren't previously used in the decentralized environment. For areas outside the storage infrastructure, consider server clustering.
Interoperability. Whether consolidating with new equipment or incorporating existing assets, interoperability issues always arise. For example, your FC fabric may be based on the latest and greatest technology, but those two-year-old HBAs in your application servers are no longer supported or need a major microcode/firmware upgrade. Operating system support, especially for older servers handcuffed by legacy application requirements, can also be an issue. Getting an upfront and detailed inventory of the current environment will save a lot of time, as well as avoid aggravation during and after migration to the consolidated infrastructure.
Multiprotocol. You should plan for multiprotocol storage connectivity now. For a consolidated storage infrastructure, this is one of those rare opportunities where you're working with a relatively clean slate, so take full advantage of it. If FICON or iSCSI may be a requirement in the future, ensure that your product selection can accommodate and support multiple protocols. It's even more important to understand the application requirements and performance characteristics of each of the protocols used. For example, FC is supported at multiple speeds today (1Gb, 2Gb and 4Gb), but future speeds (10Gb) may require different products/connectivity options.
Director switches. Think about scalability and cost-effective port density for the new, consolidated storage network. Historically, the fewer the ports on a single FC switch, the more inter-switch links (ISLs) are required to scale the fabric. Newer, director-level switches have impressive port counts--many in the hundreds on a single device. While still maintaining dual fabrics in alignment with the high-availability objectives in a consolidated SAN (many director-level switches also support separate logically segregated fabrics), port density should be a serious consideration to avoid wasting ISLs on interconnectivity.
That doesn't mean a core/edge architecture can't be used to ensure the most cost-efficient use of each port, but the total number of ports dedicated to connectivity, rather than fabric expansion, will make the fabric more cost-effective in the long run. The icing on the cake is that more of these director-level switches allow scaling when needed by adding ports via new blades without interrupting fabric services.
This was first published in April 2005