File Server improvements from Windows Server 2003 to Windows Server 2008 R2. 8 items for 8 years…
Introduction
The File Server team often talks to customers about file server migration and file server consolidation projects. Many times, these are customers running Windows Server 2003 that can point to a number of issues they wanted fixed. In most cases, those issues have been identified and corrected in Windows Server 2008 and Windows Server 2008 R2. Here are 8 of these issues (just to name a few) from recent conversations with customers:
1. CHKDSK Time
Windows Server 2003 problem:
- CHKDSK took hours or even days for a large volume with millions of files
Windows Server 2008 R2 facts:
- The time it takes to CHKDSK a volume is not proportional to the size of the volume, but to the number of files on the volume
- While it’s true that Windows Server 2003 was known for long CHKDSK times, this has changed dramatically in Windows Server 2008 and even further in Windows Server 2008 R2
- Windows Server 2008 and Windows Server 2008 R2 do more checking with the volume online, making an offline CHKDSK a rare occurrence
- In the rare case when offline checking does occur, CHKDSK in Windows Server 2008 and Windows Server 2008 R2 happens much faster
A recent white paper published by the Storage and File System team at Microsoft (which owns NTFS) mentioned a couple of interesting data points:
- A volume with 10 million files runs CHKDSK in around 7 minutes (this was done with a 15TB volume, but the size is really not important)
- A volume with 100 million files runs CHKDSK in about 2 hours
Related Links:
- White paper on CHKDSK at https://www.microsoft.com/downloads/en/details.aspx?FamilyID=35a658cb-5dc7-4c46-b54c-8f3089ac097a
- Details on self-healing NTFS at https://technet.microsoft.com/en-us/library/cc771388(WS.10).aspx
- What’s new in Windows Server 2008 R2 NTFS at https://technet.microsoft.com/en-us/library/ff383236(WS.10).aspx
2. File Server Scalability
Windows Server 2003 problem:
- A single Windows Server file server did not scale. Windows Server could not scale beyond a few thousand users
Windows Server 2008 R2 facts:
- A single Windows Server 2008 R2 server can scale to tens of thousands of users with the right configuration
- We demonstrated a single file server configuration with 192 disks and 10GbE network interfaces hosting over 23,000 users using the File Server Capacity Tool (FSCT) HomeFolders workload
Related Links:
- FSCT Results: See https://blogs.technet.com/b/josebda/archive/2011/04/08/fsct-test-results-detail-the-performance-of-windows-server-2008-r2-file-server-configurations-23-000-users-with-192-spindles.aspx
- Case study for a set of file server clusters serving 50,000 users with over 100TB of data: https://www.microsoft.com/casestudies/Case_Study_Detail.aspx?casestudyid=4000004946
- Details on FSCT can be found at https://blogs.technet.com/b/josebda/archive/2009/09/16/file-server-capacity-tool-fsct-1-0-available-for-download.aspx
3. Failover Cluster Setup
Windows Server 2003 problem:
- Failover Clustering for File Services on Windows Server was too hard to configure
Windows Server 2008 R2 facts:
- Failover Clustering was redesigned in Windows Server 2008 to provide a much simpler configuration experience
- Failover Clustering now includes a validation tool to check your servers before you create the cluster, pinpointing any issues for easy troubleshooting
- Windows Storage Server 2008 R2 introduced a wizard to further simplify the configuration of a two-node file server, which can be done by connecting to just one of the cluster nodes
Related Links:
- Details on Windows Storage Server R2 two-node cluster setup, starting on slide 37 from https://www.msteched.com/2010/NorthAmerica/WSV323
- Step-by-step for creating a two-node File Server Cluster: https://technet.microsoft.com/en-us/library/cc731844(WS.10).aspx
- Failover Clustering Validation described at: https://technet.microsoft.com/en-us/library/cc732035(WS.10).aspx
4. Shares Per File Server
Windows Server 2003 problem:
- Windows Server could only handle around 65,000 shares on a server
- Windows Server could only handle around 1,600 shares (which were each a cluster resource) in a failover cluster - https://technet.microsoft.com/en-us/library/cc780150(WS.10).aspx
Windows Server 2008 R2 facts:
- With the introduction of SMB2 in Windows Server 2008, a single file server can host over 4 billion shares
- With Windows Server 2008, the cluster model was changed to use one resource per file server instead of one resource per share. That limit of 1,674 shares no longer applies
Related Links:
- For the new SMB2 limits in shares and users, see slide 24 at https://www.snia.org/images/tutorial_docs/Networking/JimPinkerton-SMB2_Big_Improvements_Remote_FS_Protocol-v3.pdf
5. Encrypted Files
Windows Server 2003 problem:
- Encryption using the NTFS Encrypted File System (EFS) did not travel with the files when they were copied
Windows Server 2008 R2 facts:
- Windows Server 2008 introduced Active Directory Rights Management Services (AD RMS), which provides encryption that stays with the files as they are transferred
- Windows Server 2008 R2 File Classification Infrastructure (FCI) facilitates the classification of files and makes it easy to apply RMS to sensitive documents based on classification rules
Related Links:
- Details on AD RMS can be found at https://technet.microsoft.com/en-us/library/cc771627.aspx
- Learn how to combine AD RMS and FCI at https://blogs.technet.com/b/filecab/archive/2010/01/31/using-file-classification-infrastructure-fci-and-ad-rms-to-automatically-protect-sensitive-information.aspx
6. Large File Transfers on High Latency Networks
Windows Server 2003 problem:
- Copying a large file took a long time, especially on a network with high latency
Windows Server 2008 R2 facts:
- Windows Server 2008 introduced SMB2, which can handle asynchronous communications and compounding of requests to improve performance
- For instance, a file copy that used to take one minute in a network with 200ms round trip time (RTT) can be completed in less than 10 seconds in the same network
- Other experiments show that a transfer of around 10GB of data over a WAN (76ms RTT, 1 gigabit) went from around 6 hours down to around 8 minutes. Yep, that’s around 45 times faster
- Windows Server 2008 R2 introduced SMB 2.1 with support for large MTUs, which further improves file copy performance
Related Links:
- Read more about SMB2 at https://blogs.technet.com/b/josebda/archive/2008/12/09/smb2-a-complete-redesign-of-the-main-remote-file-protocol-for-windows.aspx
- Read more about performance improvements in SMB2 at https://blogs.technet.com/b/josebda/archive/2008/11/11/file-server-performance-improvements-with-the-smb2-protocol-in-windows-server-2008.aspx
- More examples of SMB2 performance improvements in slide 7 from https://www.snia.org/images/tutorial_docs/Networking/JimPinkerton-SMB2_Big_Improvements_Remote_FS_Protocol-v3.pdf
- For details on Large MTU support in SMB 2.1, see slide 16 at https://www.snia.org/events/storage-developer2009/presentations/tuesday/DavidKruse_SMBv21.pdf
7. Transferring Lots of Small Files
Windows Server 2003 problem:
- Copying lots of small files took a long time. ROBOCOPY was a nice file copy tool, but it was a downloadable tool, not part of Windows
Windows Server 2008 R2 facts:
- File copy tools usually perform copies one file at a time, synchronously. These single-threaded copy tools will be slow, even with SMB2, especially when copying lots of small files
- ROBOCOPY is a robust, multi-threaded, command-line copy tool that is included with Windows 7 and Windows Server 2008 R2
- Windows Server 2008 R2 ROBOCOPY with the multi-thread option can be up to 22 times faster when copying a large number of small files over a high-latency WAN connection
Related Links:
- For details on ROBOCOPY multi-threaded performance, see slide 49 at https://www.msteched.com/2010/NorthAmerica/WSV323
- For details on ROBOCOPY options, see https://technet.microsoft.com/en-us/library/cc733145(WS.10).aspx
8. Caching in the Branch
Windows Server 2003 problem:
- SMB was inefficient for branch access to shares in the main office and many decided to deploy a WAN acceleration device for the branch office
- When using a WAN acceleration device in the branch, you had to give up on SMB signing
Windows Server 2008 R2 facts:
- For starters, SMB2 is much more efficient in Windows Server 2008 and Windows Server 2008 R2
- On top of that, the new BranchCache feature in Windows Server 2008 R2 allows for caching in the branch, even without a dedicated WAN acceleration device
- With BranchCache, you can have both SMB2 signing and acceleration in the branch office, if necessary
Related Links:
- For details on BranchCache, see https://technet.microsoft.com/en-us/network/dd425028.aspx
- For details on SMB2 Signing, see https://blogs.technet.com/b/josebda/archive/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2.aspx
Conclusion
If you have a Windows Server 2003 File Server still around, I cannot stress enough how much you’re missing. The Windows Server team has worked hard in the last 8 years to fix these and many other issues (including the work in the recently released Service Pack 1). I hope the 8 items listed here can entice you to consider an upgrade to Windows Server 2008 R2 or Windows Storage Server 2008 R2.
If you compare Windows Server to NAS appliances running other operating systems, make sure you use Windows Server 2008 R2 (or Windows Storage Server 2008 R2) in a similar configuration (similar number of disk spindles, similar types of disks, similar RAID configuration, similar networking speeds, etc.). You want to make sure you have the latest Windows on both sides, so they can negotiate up to SMB 2.1 and you can get the full benefits mentioned. You’ll find that Windows Server 2008 R2 with SMB 2.1 can deliver industry-leading file server capabilities and performance.
Get started right now by downloading an evaluation version of Windows Server 2008 R2 with Service Pack 1 from https://technet.microsoft.com/en-us/evalcenter/dd459137.aspx