After you go through the purchasing and deployment process to implement your new storage area network (SAN), you'll need to migrate all of your data to the new platform and switch off the old file servers or arrange some downtime to remove those redundant direct-attached disks.
When migrating your data from direct-attached storage (DAS) to SAN, consider the following: how to move the data from file servers; how to move your database-type information; and whether to go to that final mile and host operating systems on the SAN, so your servers don't need any local disks at all.
Moving the data from file servers is perhaps the easiest task to manage, but it takes the longest. Historically, Fibre Channel (FC) has been the de facto SAN connection, but many small and midsized businesses (SMBs) opt for an iSCSI-based solution that connects to the network over Ethernet and effectively joins the domain for security purposes. This allows you to create shares on the SAN just as you'd create a share by using your workstation Computer Management snap-in to create remote shares on a Windows-based server.
Before moving anything, see what users are mapping to over and above the drive letters that you've assigned through policies or login scripts. If you're lucky, you're in a business where the users are given everything they need and never go searching for other secret places to stash their files. Once all of your users are logged off the affected systems, change the share permissions so that they either have no access -- or at best read-only access. Then, use Robocopy to move the files from the server to the SAN. Re-mapping the login scripts will allow your users to carry on working the next day as if nothing had happened. The shares will all look the same and the permissions they had when the files were on the server will be the same when the files are on the SAN.
Database servers are a little bit more complex, and can be time-consuming because of the preparatory steps that you need to take. Depending on the type of SAN you are deploying, connecting the server to the storage network is a matter of additional Ethernet ports or FC host bus adapters (HBA). How the servers and the SAN are physically connected doesn't matter for this article. However, the way that all the storage on the network is presented to the server does. Each SAN vendor does it a little differently, but the bottom line is that either the reseller will have taught you how to create and configure logical unit numbers (LUNs), or they'll have done an initial setup for you. Setting up LUNs doesn't take long and can be as quick as half a dozen clicks through a browser interface. Once created, the server will automatically pick them up in the Disk Management snap-in. All you need to do is to give them a drive letter and format them.
The next step is to research the best or supported way to move a database from one drive letter to another. In the case of Microsoft Exchange and SQL databases, this can be done from either the command line or from the graphical user interface. After the migration of the information, you'll need to schedule additional downtime to decommission the unused local disks from the server.
For Web servers and other applications that don't actually have any data that's kept on local disks, booting the server from networked storage could be a good option for you. "Boot from SAN" is a term that might strike fear in many people, but it's really nothing to be afraid of. There are two very good reasons for looking at this particular technology. First, an operating system and application rarely need more than 30 GB of space to run. Disks from server vendors these days are up to four or five times that size. That's a lot of wasted space that you really can't use for anything else. Second, leaving disks in the server to generate heat when there's more than enough space in the SAN, isn't particularly ecological. iSCSI and FC networks are far quicker and more resilient than they were some years ago, so the FUD -- fear, uncertainty and doubt -- around booting from the SAN is now simply irrelevant. Moving from local disks to a SAN is not a complex operation either. DDChanger is an application that will take the operating system on local disks and push it up to a bootable LUN on the server.
About the author: Mark Arnold, MCSE+M, Microsoft MVP, is Principal Consultant with LMA Consulting LLC, a Philadelphia, PA-based private messaging and storage consultancy. Mark assists customers in designs of SAN-based Exchange implementations. You can contact him at mark.arnold@msexchange.me.uk.
