Part 1 | Part 2 | Part 3
As more corporations move to centralize their data to permit users to work effectively from home and other remote locations, the concept of maintaining file servers around the network has diminished. That is not to say, however, that simply moving the same servers from branch offices into the data center is the way forward. This three-part series will take a look at how to reduce the Windows server count by using networked storage and leveraging that same storage for structured or database applications.
Why make the move?
While Windows-based file servers are great for offices that have a limited amount of flat file, unstructured data storage requirements, they just aren't scalable for enterprise data centers.
The move to remote working and an ever more mobile workforce has reduced the benefit of maintaining distributed file servers in branch offices. Corporate network communications teams prefer to implement VPN concentrators -- or at least their Internet points of presence -- into as few locations as possible. Thus, having users traverse the internal network looking for files in smaller offices makes little practical sense.
 |
|
|
|
|
There is an unstoppable trend toward more collaborative work using such technologies as Microsoft SharePoint and Exchange Server, which further erode the practicality of distributed file servers.
|
|
|
|
|
|
|
|
|
|
Furthermore, there is an unstoppable trend toward more collaborative work using such technologies as Microsoft SharePoint and Exchange Server, which further erode the practicality of distributed file servers.
Since many remote servers are being consolidated and rationalized into central locations, it makes sense to host unstructured data on platforms that are more capable of managing that data. Windows file servers are restricted in the performance they can deliver to large numbers of clients, and though Windows Server 2008 has made great strides in capacity and performance, a network-optimized platform specifically designed to serve up files is far more capable than a Windows server is.
In the vast majority of cases, corporations have deployed storage area networks (SANs) into their data centers to provide high-performance, high-capacity storage for their database applications (Exchange Server, SQL Server, Oracle, etc.). Leveraging space on these platforms for unstructured data makes a great deal of sense, since all of the expensive investment in SAN fabric has or is being made. When compared to the costs of implementation, infrastructure and support, the cost to implement a number of extra disks to meet file serving requirements is very low.
The questions, of course, are:
How do you migrate all the data from one place to another?
How do users access information in a secure manner on a storage platform that isn't actually a Windows server?
The simple answer is that the storage controllers contain software that physically join the Active Directory domain and take part in network security in exactly the same manner as any Windows-based server would. Permissions may be assigned to shares, folders and files on the system using Computer Manager for the shares and Windows Explorer for the file-level permissions.
Once the storage forms part of the domain, the matter of getting the data off the old disks and onto the new ones can commence. This is not as large a job as you might think given the maximum size of the data currently residing on file servers. You can either restore files from a backup, replicate them using the SAN vendor's replication and migration technologies or simply copy them from the old source to the new. Since the storage is an Active Directory-aware platform, the permissions can be maintained as the information is migrated.
But, moving all of the information is only half the story. Administrators need to make sure users can still find their documents, presentations and spreadsheets on the network. Part of the migration project should pay attention to how users are accessing information on the old server(s). It is easy to substitute one network for another in the logon scripts, changing the net use lines from \\oldserver\share to \\newplatform\share name inside a Group Policy by changing the file located here:
Default Domain GPO → User Configuration → Windows Settings → Scripts → Logon.
That procedure will cover the usual 80% of users, but there will be the inevitable 10% who have departmental-level mappings or some other officially sanctioned route. The last 10% will be the most difficult -- there are bound to be a number of users who have found a share or place they "like" on the network. They have manually either mapped a drive to it or alternatively dragged a shortcut of the folder or share to their desktop (or somewhere equally useful to them). For these users it is appropriate to use DNS redirection to direct any lookups that request the old server name to the network name of the new storage platform.
The only problem that might present itself here is if the old file server is not being retired or has a dual role -- perhaps remaining on the network as a domain controller in the branch office. This would preclude the use of any redirection, so admins should remove the write access to the old shares, rather than removing the shares and then placing a "readme" file to direct those few stragglers that were not managed by Group Policies and other redirection methodologies.
One final consideration: If an organization is employing a solution such as Varonis DatAdvantage, it should simply run simulations on the existing shares to see who would be affected by removing or otherwise changing those share locations. Using such software guarantees that all users can be migrated without any issues. That way, administrators can try to correct any anomalies before they attempt a migration.
The next two parts in this series will discuss migrating and managing structured data, as well as the differences in backup and restoration procedures once information has been centralized onto a networked storage platform.
MAKING THE MOVE FROM DAS TO SAN and NAS
Part 1: Why make the move?
Part 2: Migrating structured data
Part 3: Backup and recovery procedures
|
| Mark Arnold, MCSE+M, Microsoft MVP, is principal consultant with LMA Consulting LLC, a private messaging and storage consultancy based in Philadelphia. Mark assists customers in designs of SAN-based Exchange Server implementations. He has been a Microsoft MVP in the Exchange discipline since 2001, contributes to various Microsoft-focused technology Web sites and can be found in the Exchange newsgroups and other Exchange forums. |
|
