Best Practice Guide
Windows File Server on Simplivity OmniStack systems
Page 1 of 14
www.SimpliVity.com
Best Practice Guide
Table of Contents
Overview.................................................................................................................................................................................... 3
Introduction................................................................................................................................................................... 3
Windows File Server ..................................................................................................................................................... 3
Windows Clients............................................................................................................................................................ 3
W
indows File Server Considerations......................................................................................................................................... 4
Windows File Server Clustering (MSCS) vs. SimpliVity HA........................................................................................... 4
Windows VM Disk Filesystem Choice........................................................................................................................... 5
Windows Block Size.............................................................................................................................................. 5
Visual Representation................................................................................................................................................................. 6
Features and Considerations..................................................................................................................................................... 6
Data Protection............................................................................................................................................................. 6
Backups and Restores........................................................................................................................................... 6
File Level Restore.................................................................................................................................................. 6
Windows Shadow Copies..................................................................................................................................... 7
Data at Rest Encryption........................................................................................................................................ 7
In-VM Encryption.................................................................................................................................................. 7
BitLocker............................................................................................................................................................... 8
Microsoft Encrypted File System.......................................................................................................................... 8
Data Efficiency Features................................................................................................................................................ 8
Compression......................................................................................................................................................... 8
Deduplication....................................................................................................................................................... 8
Windows Server Deduplication............................................................................................................................ 9
Disk Defragmentation................................................................................................................................................... 9
Other Feature Considerations................................................................................................................................................... 9
Calculating maximum file server capacity................................................................................................................................ 10
Migrating from Non Simplivity Solutions................................................................................................................................. 12
Migrating from existing VMware-based solution............................................................................................... 12
Migrating from large existing filesystems, such as NetApp filers....................................................................... 12
References................................................................................................................................................................................ 14
Page 2 of 14
www.SimpliVity.com
Best Practice Guide
Overview
This document provides technical details, benefits and best practices for implementing a Windows File Server on
Simplivity OmniStack systems.
Purpose and intended use: This paper is intended for IT professionals who are looking to deploy Windows File Server on
SimpliVity OmniStack systems. This paper outlines general practices and guidelines for Windows File Server deployment
on SimpliVity’s virtualized platform.
Introduction
SimpliVity OmniStack and its foundational Data Virtualization Platform provide excellent performance and efficiency to
host virtual machines and their data, providing best-in-class file services. OmniStack does not directly provide file services. Instead, a Windows File Server can be created as a virtual server on an OmniStack system to provide file share
access to clients.
Windows File Server
Microsoft’s implementation of Quota Management, Group Policies and Storage Reports along with Windows features as
Access Control Lists provides rich integration into the Microsoft Ecosystem and makes it operationally and commercially
possible at scale.
Windows Clients
Microsoft recommends using Windows Server 2012 R2 for clients running Windows 7, 8 and 10. Windows Server with File
Server implementation provides best compatibility and functionality for Windows Clients.
Page 3 of 14
www.SimpliVity.com
Best Practice Guide
About SimpliVity
SimpliVity’s hyperconverged infrastructure solution transforms the data center by virtualizing data and incorporating
all IT infrastructure and data services below the hypervisor into commodity x86 building blocks. With 3X total cost of
ownership (TCO) reduction, SimpliVity OmniStack software-defined hyperconverged infrastructure delivers the best
of both worlds: the enterprise-class performance, protection and resiliency that today’s organizations require, with
the cloud economics businesses demand.
Designed to work with any hypervisor or industry-standard x86 server platform, the SimpliVity solution provides a
single, shared resource pool across the entire IT stack, eliminating point products and inefficient siloed IT architectures. The solution is distinguished from other converged infrastructure solutions by three unique attributes: accelerated data efficiency, built-in data protection functionality and global unified management capabilities.
•Accelerated Data Efficiency: OmniStack performs inline data deduplication, compression and optimization on all data
at inception across all phases of the data lifecycle, all handled with fine data granularity of just 4KB-8KB. On average,
SimpliVity customers achieve 40:1 data efficiency while simultaneously increasing application performance.
•Built-In Data Protection: OmniStack includes native data protection functionality, enabling business continuity and
disaster recovery for critical applications and data, while eliminating the need for special-purpose backup and recovery hardware or software. OmniStack’s inherent data efficiencies minimize I/O and WAN traffic, reducing backup and
restore times from hours to minutes.
•Global Unified Management: OmniStack’s VM-centric approach to management eliminates manually intensive,
error-prone administrative tasks. System administrators are no longer required to manage LUNs and volumes; instead,
they can manage all resources and workloads centrally, using familiar interfaces such as VMware vCenter and VMware
vRealize Automation.
Windows File Server Considerations
This section discusses design practices for creating a Windows File Server on SimpliVity Omnistack system. High
Availability and File System requirements for the file server are discussed here.
Windows File Server Clustering (MSCS) vs. SimpliVity HA
1.Customers use File Server clusters to provide high availability. File Server clustering is not required on a SimpliVity solution as each component is highly available, and in the event an entire OmniCube node fails the functionality in vSphere
HA will automatically failover.
2.To use a Windows File Server Cluster the Cluster Shared Volume (CSV) guest filesystem type needs to be used.
However, this cannot be created on a SimpliVity solution natively since we do not present block storage to guests.
3.Another reason customers use File Server clusters is to reduce risk when patching the Windows environment. By taking
a SimpliVity backup prior to performing patches, recovery from a failed upgrade is simple and quick.
4.Scaling out the file server environment is done typically by having multiple File Servers, each with their own volumes
and shares, which then share hardware so that the loss of one file server does not reduce availability of the solution.
This is what SimpliVity offers, in a different form without the complexity of Microsoft clustering.
Note: Natively in Windows there is no ability to take a standard file share and spread it across multiple Windows
machines. A technology called Scale-Out File Server was added in 2012R2 but is only designed for application shares,
not end-user file accessi.
Page 4 of 14
www.SimpliVity.com
Best Practice Guide
Microsoft DFS is a great way of managing large scale-out Windows file server environment but most customers will
not have put in the required DFS layer prior to the demand. The result in lack of infrastructure planning would end up
resulting in a large scale remapping of data. See the Microsoft documentation on DFS for more information.
https://technet.microsoft.com/en-us/library/cc757042(v=ws.10).aspx
Windows VM Disk Filesystem Choice
When creating a Windows VM to host Windows File Services there are multiple options inside the guest for the file
system that could be used to host user data.
Windows supports several filesystems including FAT (and derivatives), NTFS, Cluster Shared Volumes (CSV) and Resilient File System (ReFS). NTFS is the Microsoft default and generally well suited to file serving.
1.FAT is unsuitable for most customers due to lack of Access Control List support.
2.ReFS is also not suitable for most customers due to a very large block size (64KB). While a large block size is not inherently a problem, a 1 byte file in ReFS consumes a full 64KB cluster from the guest perspective and there is no ‘MFT’
space that can be used to mitigate this space consumption. The OmniStack software will apply compression and deduplication to minimise space consumption, but it will create challenges for free space management inside the guest.
Note that currently SimpliVity’s single file restore capability does not support ReFS.
3.Cluster Shared Volumes cannot be created on SimpliVity storage as a Cluster Shared disk is not currently supported
over NFS and requires block storage, either iSCSI or VMFS ii. See below for recommendations on Clustering for
availability.
4.NTFS disks work well for the Windows File Server use case and are the default from Microsoft. A best practice recommendation from SimpliVity is to ensure that at least an 8KB cluster size is used on formatting as this improves performance. Unlike ReFS (see 2. above), very small files are also efficiently stored from a guest space usage perspective iii.
Windows Block Size
1.8K is the recommended size in a file-serving environment
2.Other NTFS cluster sizes are supported, but using larger cluster sizes doesn’t generally provide additional benefit
unless it is clear that the majority of files are significantly larger.
3.NTFS reserves 12.5% of space for the Master File Table to reduce file system fragmentation, in a SimpliVity solution
data fragmentation is less of a concern since de-duplicated storage arrays are fragmented by design and use this fact
as part of the fundamental design of the system.
Page 5 of 14
www.SimpliVity.com
Best Practice Guide
Visual Representation
The following diagram shows how clients access shares on a file server created on Simplivity Omnistack.
Clients access \\FileServerVM\Central
C: Boot
VMDK
Windows Server VM FileServerVM
with share central
Windows VM Directory
OmniStack Node
D:
Large VMDK
containing
NTFS data
shared as Central
Features and Considerations
Simplivity and Windows provide several features that provide data protection and data efficiency. This section
discusses how those Simplivity features perform in conjunction with Windows File Server.
Data Protection
Backups and Restores
SimpliVity backups provide an easy capability to restore virtual machines and individual files as an administrator
function. If a Virus or ‘Crypto Locker’ destroys a significant amount of data in a Windows file server, then the VMware
administrator can simply restore from the most recent ‘clean’ backup, which will likely be easy to determine since the
act of changing a lot of files will cause backups to grow significantly. To aid recovery of non-corrupted files or analysis
by specialists a backup or clone can be taken of the VM so that any changes, such as the restore, do not cause data to
be lost. Regular backups should be taken of the file server VM with appropriate retention policies.
File Level Restore
When individual files need restoring an administrator can also perform that action using the SimpliVity Restore Files/
Folders wizard iv.
Page 6 of 14
www.SimpliVity.com
Best Practice Guide
Windows Shadow Copies
•If a customer wants the end user to perform restores. This can be accomplished in Windows by utilizing Shadow Copies,
a feature that is built into Windows. This allows the user to right-click and use the Previous Versions tab from within Windows Explorer. Avoid the use of volume mount points in NTFS if shadow copies are to be used as they are unsupported
by Microsoft v. Volume mount points do not really add significant value in a non-SAN environment.
•Shadow Copies can be enabled as part of an existing NTFS volume and will share space with the existing files. While this
is the default, the best practice from Microsoft is to put Shadow Copies on a separate volume. The best way to achieve
this is to create a separate hard disk inside VMware for the File Server, then use that separate disk.
•When sizing consider how much data will change and the balance between SimpliVity backups vs. Shadow Copy backups. Always use SimpliVity backups since they allow for whole machine restores, but consider that even once a Shadow
Copy backup expires the data will still exist in a SimpliVity backup so will consume space.
Data at Rest Encryption
As drives leave data centers for repair, retirement, relocation or maintenance, the data stored on them is most vulnerable to being lost or stolen.
SimpliVity addresses this problem by adding self-encrypting drives (SEDs) to select OmniCube models. With selfencrypting drives, data stored on physical media is protected against loss or theft. Encryption keys are securely
stored on each node, and access requires an administrator password.
The self-encrypted drives in select OmniCube CN-3400s use the Advanced Encryption Standard (AES) encryption
algorithm recommended by the National Institute of Standards and Technology (NIST), and are approved for Federal
Information Processing Standard (FIPS) 140-2 Level 2 usage, including sensitive or classified national security data.
Local key management, and an embedded encryption key on the drive itself, renders its data unreadable should
unauthorized users come into possession of a SED that has been removed from the data center.
Data at Rest Encryption preserves deduplication and compression features of the Omnistack Platform.
In-VM Encryption
•In-VM encryption on a SimpliVity solution will not be able to compress the data or gain any benefit from ‘ingest’
deduplication.
•If the encryption option chosen uses an external key server then care must be taken to ensure that any attempt to
restore from a backup also includes access to the appropriate key, either by a manual by-pass or via keeping keys
available for ‘old’ machines in perpetuity.
•Standard Microsoft and VMware restrictions should be observed for placing encrypted data in a virtualized environment. The SimpliVity Single File Restore should be assumed to be non-functional with encrypted backups.
SimpliVity has partnerships with encryption vendors who can provide a comprehensive encryption solution for an
entire environment, including file servers running on SimpliVity OmniCube. For more details see the whitepapers on
the SimpliVity website vi:
1.SimpliVity OmniStack with the HyTrust Platformvii
2.SimpliVity OmniStack with Vormetric Transparent Encryptionviii
Page 7 of 14
www.SimpliVity.com
Best Practice Guide
BitLocker
BitLocker style encryption, while supported in VMware, cannot use the Trusted Platform Module (TPM) and requires
that the boot drive remain unencrypted ix. Since the boot drive is unencrypted any data volumes will not be unlocked
automatically at the time Windows boots. This means the administrator would need to log into the machine and manually unlock the volume, so this is probably not a suitable solution x.
There are workarounds but may not be unsupported by Microsoft and/or VMware.
Microsoft Encrypted File System
Microsoft Encrypted File System (EFS) can be used but care should be taken for sizing since there will be no deduplication or compression of data ingested.
Customers who already use EFS should be aware of how to manage and use the solution.
Note: For Windows 2012R2 and Windows 2016, it appears that EFS is no longer being recommended to customers or
discussed in material, this guides to avoid its use in new deployments.
Data Efficiency Features
Compression
Most of the files stored inside a Windows file server share are likely to be Office documents and PDF documents.
With more recent file formats, these files are pre-compressed by the client but do so with a lower level of compression than SimpliVity can achieve from the same file. Simplivity does not recommend switching to the older file formats since this would involve significant retraining of users for little gain, approximately 1-2% at best. Although the
files are “pre-compressed”, they do actually compress by an additional 5-10%.
Example: A 998KB word document file shrinks to approximately 823KB when saved as a .docx file, whereas the same
.docx saved as a .doc and then compressed consumes approximately 807KB.
Deduplication
Given that the documents are pre-compressed, they also do not show high rates of deduplication. For example, a
Word document has a single character changed, on saving a completely new file is created that does not de-duplicate against the original.
One common source of duplicates in a shared file server environment are where a user make copies of documents,
prior to creating yet another version to edit. For example, an original document ‘Master Presentation.pptx’ might be
copied by a user into their home directory and another copy created from it that is edited.
Another source of duplicates is error recovery files - these files are usually hidden and deleted automatically but will
sometimes stay behind especially if the application crashes and the error recovery feature does not clean up the files.
Page 8 of 14
www.SimpliVity.com
Best Practice Guide
A brief example of approximately 6GB of data extracted from an example internal file server:
Simulated Data Dedupe:
Interestingly, from this dataset, the amount of duplicates with a refcnt (reference count) of ‘2’ contains almost all the
duplicates. That suggests that there are duplicate files in the dataset, something that is confirmed by performing a
duplicate file check on the dataset. The duplicates in this case were mostly error recovery files (PowerPoint temporary
files starting with ~$)
Windows Server Deduplication
Windows Server 2012 introduced a deduplication feature that allows you to enable deduplication at the drive level. It is not
recommended to turn on this feature for drives on OmniStack systems as windows deduplication is done at 32-128K, which
would leave large compressed chunks post process and no further efficiency would be obtained from the Omnistack system. Simplivity Omnistack system should handle deduplication independently to maximize efficiency.
Windows Disk Defragmentation
•Do not use defragmentation tools inside the guests.
•Running defragmentation will potentially cause Shadow Copy Backups to be deleted by Windows, if used.
•It will cause lots of unnecessary read operations. Windows does not have any concept of placement inside the OmniStack Object Store, so reading and re-writing a guest file system block will, at best, be a ‘no operation’ as we discard the
new (duplicate) copy of the same block we already have on disk.
Other Feature Considerations
There are other features that organizations commonly used in a file server environment for security or data consolidation. Some of those features and their impacts are discussed in this section.
Page 9 of 14
www.SimpliVity.com
Best Practice Guide
Calculating maximum file server capacity
The maximum amount of file system data that can be created inside a capacity of largest single file server can be
calculated using the following variables:
•Minimum amount of free space on the SimpliVity solution to ensure maximum performance. This is currently
recommended to be 30%.
•Space set aside for SimpliVity local and remote backups. See the backup section for recommendations. For this sizing
calculation an arbitrary 10% is used.
•Space set aside for Shadow Copy (VSS) backups. See the backup section for recommendations. For this sizing calculation an arbitrary 10% is used, can be set to 0 if VSS backups are not used.
•Free space inside Windows NTFS. While there is no recommended amount from Microsoft, running out of space will
cause client issues so a sensible buffer of at least 5% should be used.
•Deduplication and compression. As observed, these are typically 10% each for typical office document environments.
In addition there is the space needed for a copy of Windows along with service packs, patches and the like. A safe
assumption allowing for future changes from Microsoft is 100GiB, though again this is an arbitrary amount.
Using the following key, the calculation is as follows:
A*(1-(B+C+D+E-(F*G-1)))-H
Notation
Meaning
A
SimpliVity Usable Space (in GB)
B
SimpliVity recommended minimum free space after deployment (as a factor)
C
Space set aside for SimpliVity local/remote backups (as a factor)
D
Space allocated in NTFS for VSS backups (as a factor)
E
NTFS free space to avoid full filesystems (as a factor)
F
Dedupe ration (e.g. 1.5 for 1.5:1)
G
Compression ration (e.g. 1.5 for 1.5:1)
H
Windows binaries / patches and other overheads (in GB)
For a single CN1200 node the maximum that can be supported is:
A=2458, B=0.30, C=0.10, D=0.10, E=0.05, F=1.1, G=1.1, H=100
= 2458*(1-(0.30+0.10+0.10+0.5-(1.1*1.1-1)))-100
= 1522 GB
Page 10 of 14
www.SimpliVity.com
Best Practice Guide
The following table shows all current node sizes using the above formula:
Model
Usable Space
Maximum File Server Content
CN1200
2,458
1,522
CN2400
4,813
3,076
CN3400
1,210
8,618
CN5400
15,872
10,376
For two nodes in a HA pair the above numbers stay the same. (See Figure 1 and 2)
When adding additional nodes, consideration needs to be made for how much space is available on each node.
Assuming the solution was built using one of the configurations above and is now full then adding a third node will
result in no additional space, also the 2nd node is not running user services, simply acting as an HA partner for node
1. (See Figure 3)
Node 1
FILE SERVER 1
100% FULL
Figure 1. A single node space usage
Node 1
Node 2
FILE SERVER 1
100% FULL
FILE SERVER 1 HA
COPY
100% FULL
Figure 2. A HA pair space usage
Node 1
Node 2
Node 3
FILE SERVER 1
100% FULL
FILE SERVER 1 HA
COPY
100% FULL
Empty, no space on
nodes 1 or 2 to store
HA sync copy of VM.
Figure 3. When adding a third node, no space on either node 1 or 2 will be available
To work around this the best solution is to add a forth node (Node 4) so that Node 3 then has space.
Page 11 of 14
www.SimpliVity.com
Best Practice Guide
Alternatively, when planning the design each VM could be reduced by half to allow for space to be available. For example
in Figure 4:
Node 1
Node 2
Node 3
FILE SERVER 1
50% FULL
VM 2
50% FULL
VM 3
50% FULL
VM 3 HA COPY
50% FULL
FILE SERVER 1 HA
COPY
50% FULL
VM 2 HA COPY
50% FULL
Figure 4. Layout for a 3 node configuration
In this configuration there are now 3 VMs, at least one of them being a File Server. The largest file server is now half of what
could be achieved using one or two nodes as shown in the following table:
Model
Usable Space in GB
Maximum File Server Content
(Half of one node)
CN1200
2,458
761
CN2400
4,813
1,538
CN3400
13,210
4,309
CN5400
15,872
5,188
Obviously in the three node configuration above there is still significant amounts of space available for other virtual machines.
Migrating from Non Simplivity Solutions
Migrating from existing VMware-based solution
Check that the guest VM will fit on the machine, and then perform a storage VMotion.,If the existing filesystem format
inside the guest VM is 4K then consideration should be given to doing a ‘V2V’ migration to change the filesystem
block size.
Migrating from large existing filesystems, such as NetApp filers,
Migration can be performed using standard tools such as robocopy / SecureCopy xi, and this is an area where SimpliVity
partners can add value.
One potential issue is going to be around the amount of data being migrated. For example, if the customer already
uses a non-Microsoft file server solution then the amount of data in a single filesystem or share may be significant,
30-40TB or even larger.
Page 12 of 14
www.SimpliVity.com
Best Practice Guide
While it might seem easy to just take a single large share and copy it to a VM on node 1, and another large share and
put on a different node, this would likely cause existing documents such as spreadsheets with embedded links to
become unusable without modification.
For example, consider a customer with 5TB in \\Filer\CommonDocs and 10TB in \\Filer\CustomerProjects. After
the split there are two VMs called ‘Filer’ and ‘Filer2’ and the original device is turned off. Now documents live in
\\Filer\CommonDocs and \\Filer2\CustomerProjects. Any documents with links to \\Filer\CustomerProjects no longer
work properly, and tools to find and correct the embedded links are expensive.
See the capacity section for guidance about how to think about sizing for large VMs in a SimpliVity Windows file
server solution.
Note: If the size of a single file server solution is larger than will fit on a single node then care should be taken since
splitting a single large file server into multiple smaller VMs is not trivial. Solutions for this include using Microsoft DFS
to present a scale-out style namespace of shares back to client machines, but management of these types of environments typically involves special tools and so should only be considered if the customer already has expertise in this
space. One company with a very well respected DFS management and migration tool is Data Dynamics xii (formally
StorageX, from NuView).
Page 13 of 14
www.SimpliVity.com
Best Practice Guide
References
i
Microsoft Scale-out File Server: https://technet.microsoft.com/en-us/library/hh831349.aspx
VMware support statement on Microsoft clustering requirements:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1037959
ii iii iv NTFS small file storage:
https://technet.microsoft.com/en-us/library/cc781134%28v=ws.10%29.aspx (search for ‘Small Files’).
YouTube video showing the SimpliVity single file restore, from 2014:
https://www.youtube.com/watch?v=lnFKrmEVdcs
Shadow copy best practices:
https://technet.microsoft.com/en-us/library/cc753975.aspx
(search for ‘Do not enable shadow copies on volumes that use mount points’)
v
vi
impliVity white papers:
S
https://www.simplivity.com/resources/papers-reports/
vii
impliVity OmniStack with the HyTrust Platform:
S
https://www.simplivity.com/wp-content/uploads/omnistack-hytrust-platform-white-paper-20151221.pdf
viii
impliVity OmniStack with Vormetric Transparent Encryption:
S
https://www.simplivity.com/wp-content/uploads/omnistack-vormetric-transparent-encryption-white-paper-21051221.pdf
ix
nencrypted boot drive in VMware:
U
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2036142
Automatic unlock of encrypted NTFS drives:
https://technet.microsoft.com/en-us/library/hh831507.aspx
(search for question ‘Why am I unable to automatically unlock my drive?’)
x
xi
ecure Copy:
S
http://software.dell.com/products/secure-copy/
(ScriptLogic was purchased by Dell)
xii
ata Dynamics StorageX:
D
http://www.datadynamicsinc.com/products/storagex-platform/dfs-management/
For more information, visit:
www.simplivity.com
® 2016, SimpliVity. All rights reserved. Information described herein is furnished for informational use only, is subject to change without notice. SimpliVity, the SimpliVity logo,
OmniCube, OmniStack, and Data Virtualization Platform are trademarks or registered trademarks of SimpliVity Corporation in the United States and certain other countries. All
other trademarks are the property of their respective owners.
J771-WFS-Best Practice-EN-0416
Page 14 of 14
www.SimpliVity.com