Easing the migration from DAS to SAN

Posted on October 01, 2001


An efficient and inexpensive method of making the transition from direct-attached storage to a storage area network relies on host-based mirroring and storage virtualization.


The reasons for moving from direct-attached storage (DAS) to a storage area network (SAN) are compelling. While effective for managing storage at the departmental level, DAS cannot accommodate the increasing enterprise-level need for scalability and flexibility to share excess storage capacity-outside of the particular server to which the storage is attached. In addition, DAS configurations are subject to frequent performance lags, due to inadequate caching and other performance bottlenecks in typical SCSI controller architectures.

By moving storage to a SAN, administrators have the means and the bandwidth to share and allocate storage to a much larger audience on the network. Most SAN technologies also pave the way for flexible, seamless growth in the future-a significant consideration for most companies, given the rapid growth being forecast for storage requirements.

However, companies considering the deployment of SAN-based storage are often stalled by the perceived challenge of moving from DAS to SANs. One of their chief concerns is potential disruption of business-critical applications. What's needed is a simple and effective mechanism that keeps downtime to a minimum and provides a safe path back to DAS should problems occur during SAN deployment, while at the same time providing scalability for future growth.

This article will explore a relatively simple solution: host-based mirroring, which offers a painless way to migrate from DAS to a fully redundant SAN infrastructure with the ability to expand centralized storage easily to meet future storage requirements.

Traditional methods inadequate

Typically, companies have turned to conventional backup-and-restore solutions during the migration to a SAN, but this has some drawbacks:

  • The backup operation on servers with large amounts of storage often negatively impacts application performance and may lead to downtime;
  • The "restore" operation to the new SAN storage, even if perfect, means more downtime for the application servers; and
  • Completely removing local storage and replacing it with a SAN is an "all-or-nothing" approach; if problems arise, it's impossible to revert back to local storage on-the-fly while the glitches are being worked out.

The key to painless SAN migration is actually relatively simple and may come as a surprise to many companies.

Almost all application servers considered for SAN attachment already provide some form of software-based mirroring (RAID 1) built into the operating system or available as relatively inexpensive unbundled software. Host-based mirroring can be used to seamlessly migrate the data from local storage to the SAN, while simultaneously providing a simple and effective fallback position in the event of a misstep.

Step 1: Install the SAN
A company migrating to a SAN must first implement the SAN infrastructure, which includes switches, storage resources, and Fibre Channel host bus adapters (HBAs). These steps can be accomplished without impact on the application servers right up to where the servers have to be attached to the new storage.

Each application server must then be shut down long enough to install a Fibre Channel HBA-a process that generally requires 30 minutes of downtime per server. A company planning to provide redundant connections to the SAN for maximum uptime should consider installing both HBAs at once, even if the second interface won't be used until later. This will prevent later disruption to the application servers.

Figure 1: In the first step of migrating to a SAN, the original storage (mirror source) remains on the application server and is mirrored over to the SAN to create the secondary copy (mirror target).
Click here to enlarge image

Once the application servers are connected to the SAN, a LUN equal in size to the local-attached storage is served up to the application server, and a mirror is created between the local storage and the SAN storage. At this point, there will be some performance degradation while the mirror is created, but scheduling the operation during off-peak hours can minimize the impact.

In this method (see Figure 1), the original storage (mirror source) remains on the application server and is mirrored over to the SAN to create the secondary copy (mirror target). The primary-secondary relationship is largely governed by the mirroring software, which will automatically configure the mirror source as the primary.

Step 2: Move primary storage to the SAN
The next step (shown in Figure 2) relies on the mirroring software's ability to change the primary-secondary relationship so that I/O requests from the application servers are satisfied from the SAN rather than from local storage.

Network administrators reverse the roles of the mirrored source and target so that the SAN disks now act as primary storage, and the locally attached storage becomes secondary.

Figure 2: The second step in migrating to a SAN relies on the mirroring software's ability to change the primary/secondary relationship so that I/O requests from the applications servers are satisfied from the SAN, rather than from local storage.
Click here to enlarge image

Performance is the big win here. With the SAN storage being used as the primary I/O source, many applications will get a performance boost, which may offset some of the initial SAN implementation costs by delaying the need for application server performance upgrades. The performance spike is attributable to the ability of Fibre Channel-based storage to provide better performance than comparable SCSI storage because it can handle more drives without slowdown. In addition, typical SAN-based storage solutions offer larger caches and other performance-enhancing features.

Step 3: Break the server bond
The next step is to eliminate locally attached storage altogether (see Figure 3) by mirroring data, either between two separate SAN storage arrays or within the same array.

The most logical point at which to undertake this step is when the application servers need more storage. Instead of compounding the problems of direct-attached storage on the application server, simply add more storage to the SAN.

Once the new storage is in place, administrators redirect the secondary half of the mirrors to the new SAN storage and remove the locally attached storage.

Figure 3: The last step in SAN migration eliminates locally attached storage by mirroring data either between two separate SAN storage arrays or within the same array.
Click here to enlarge image

At this point, the servers have become diskless, making future upgrades easier: All that is required is to simply bring on a new server and allocate the storage from the old server to the new one. This process eliminates the need to spend hours doing a backup and restore of data as part of the new server deployment.

The only downside to the process outlined so far is that in most scenarios, all of the storage that was directly attached to the application servers is now useless or will require expensive bridging hardware to migrate it to the SAN. Storage virtualization technology now offers a solution to this problem. Companies can leverage virtualization to directly attach those devices to a network storage pool and use the capacity for future storage needs.

Implementing storage virtualization technologies, in some instances, is as simple as adding one or more virtualization appliances with virtualization software to the SAN. This procedure allows a company to consolidate storage hardware from multiple vendors into a networked storage pool, making storage capacity and data accessible as needed.

With a virtualization scheme in place, adding new application servers and storage may no longer require the use of proprietary, costly, high-performance storage. Primary volumes, for example, might be allocated from high-performance arrays. But secondary volumes could reside on low-cost EIDE/ATA arrays or JBOD arrays, dramatically reducing the overall cost for mirroring data on the SAN. Additionally, the flexibility to leverage existing storage assets and mix-and-match different types of storage within the SAN-while maintaining a common management interface-allows maximum return on investment and ensures that future investments are cost-effective.

By upgrading the SAN to include storage virtualization, it's also possible to centralize and simplify the administration of a combined storage pool and to eliminate single points of failure and performance bottlenecks.

Whether or not virtualization is part of the SAN migration strategy, host-based mirroring offers a viable and simple path for migration from DAS to a high-performance, scalable, and stable SAN infrastructure. Best of all, most companies already have this capability in-house and can start making the transition to more-flexible, scalable, efficient storage right away.

Nik Simpson is product marketing manager at DataCore Software (www.datacore.com) in Ft. Lauderdale, FL. He can be reached at nik.simpson@datacore.com.


Benefits of host-based mirroring

The benefits of migrating from direct-attached storage to a storage area network (SAN) through host-based mirroring are immediate and, in most cases, quantifiable. Here's a look at some of the most important advantages:

  • Simple, painless migration. The application downtime required to add the server to the SAN is measured in the length of time it takes to install a Fibre Channel interface on each host. Many environments allow the mirrored devices to be set up while the applications are running.
  • Familiar working environment. The scenario relies on familiar, locally attached storage to service its primary I/O needs, providing a safety net in the early stages of the migration.
  • Enhanced availability. With data mirrored to the SAN, storage and host bus adapters on the application servers and on the SAN no longer represent single points of failure.
  • Disaster tolerance. Since SAN-based storage can be located in another building or even in another town, catastrophic failure of local storage will not cause long-term downtime for applications. A contingency server at the remote site could be used to restore application services from the latest copy of the data on the SAN.
  • Entry-level pricing and investment protection. This approach allows very high availability with a minimal SAN infrastructure, while maximizing the use of existing storage on the application servers.
  • Fallback position. If problems occur during migration, the application server can be detached from the SAN and can continue to function normally on its locally attached storage.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.

InfoStor Article Categories:

SAN - Storage Area Network   Disk Arrays
NAS - Network Attached Storage   Storage Blogs
Storage Management   Archived Issues
Backup and Recovery   Data Storage Archives