- Storage Spaces in Windows 10
- Deploy Storage Spaces Direct
- Before you start
- Step 1: Deploy Windows Server
- Step 1.1: Install the operating system
- Step 1.2: Connect to the servers
- Step 1.3: Join the domain and add domain accounts
- Step 1.4: Install roles and features
- Step 2: Configure the network
- Step 3: Configure Storage Spaces Direct
- Step 3.1: Clean drives
- Step 3.2: Validate the cluster
- Step 3.3: Create the cluster
- Step 3.4: Configure a cluster witness
- Step 3.5: Enable Storage Spaces Direct
- Step 3.6: Create volumes
- Step 3.7: Optionally enable the CSV cache
- Step 3.8: Deploy virtual machines for hyper-converged deployments
- Step 4: Deploy Scale-Out File Server for converged solutions
- Step 4.1: Create the Scale-Out File Server role
- To create a Scale-Out File Server role by using Server Manager
- To create a Scale-Out File Server role by using Windows PowerShell
- Step 4.2: Create file shares
- Step 4.3 Enable Kerberos constrained delegation
- Next steps
Storage Spaces in Windows 10
Storage Spaces helps protect your data from drive failures and extend storage over time as you add drives to your PC. You can use Storage Spaces to group two or more drives together in a storage pool and then use capacity from that pool to create virtual drives called storage spaces. These storage spaces typically store two copies of your data so if one of your drives fails, you still have an intact copy of your data. If you run low on capacity, just add more drives to the storage pool.
You need at least two extra drives (in addition to the drive where Windows is installed). These drives can be internal or external hard drives, or solid state drives. You can use a variety of types of drives with Storage Spaces, including USB, SATA, and SAS drives.
Add or connect the drives that you want to group together with Storage Spaces.
Go to the taskbar, type Storage Spaces in the search box, and select Storage Spaces from the list of search results.
Select Create a new pool and storage space.
Select the drives you want to add to the new storage space, and then select Create pool.
Give the drive a name and letter, and then choose a layout. Two-way mirror, Three-way mirror, and Parity can help protect the files in the storage space from drive failure.
Enter the maximum size the storage space can reach, and then select Create storage space.
Simple spaces are designed for increased performance, but don’t protect your files from drive failure. They’re best for temporary data (such as video rendering files), image editor scratch files, and intermediary compiler object files. Simple spaces require at least two drives to be useful.
Mirror spaces are designed for increased performance and protect your files from drive failure by keeping multiple copies. Two-way mirror spaces make two copies of your files and can tolerate one drive failure, while three-way mirror spaces can tolerate two drive failures. Mirror spaces are good for storing a broad range of data, from a general-purpose file share to a VHD library. When a mirror space is formatted with the Resilient File System (ReFS), Windows will automatically maintain your data integrity, which makes your files even more resilient to drive failure. Two-way mirror spaces require at least two drives, and three-way mirror spaces require at least five.
Parity spaces are designed for storage efficiency and protect your files from drive failure by keeping multiple copies. Parity spaces are best for archival data and streaming media, like music and videos. This storage layout requires at least three drives to protect you from a single drive failure and at least seven drives to protect you from two drive failures.
After you upgrade to Windows 10, we recommend that you upgrade your existing pools. With an upgraded pool, you can optimize drive usage and remove drives from pools without affecting the pool’s protection from drive failure.
Note: Upgraded pools aren’t compatible with previous versions of Windows.
When you add new drives to an existing pool, it’s a good idea to optimize drive usage. This will move some of your data to the newly added drive to make the best use of the pool’s capacity. It’ll happen by default when you add a new drive to an upgraded pool in Windows 10—you’ll see a check box for Optimize to spread existing data across all drives selected when you add the drive. However, if you cleared that check box or added drives before upgrading a pool, you’ll need to manually optimize drive usage. To do so, type Storage Spaces in the search box on the taskbar, select Storage Spaces from the list of search results, and then select Optimize drive usage.
If you created a pool in Windows 10 or upgraded an existing pool, you’ll be able to remove a drive from it. The data stored on that drive will be moved to other drives in the pool, and you’ll be free to use the drive for something else.
Go to the taskbar, type Storage Spaces in the search box, and select Storage Spaces from the list of search results.
Select Change settings > Physical drives to see all the drives in your pool.
Find the drive you want to remove and select Prepare for removal > Prepare for removal. Leave your PC plugged in until the drive is ready to be removed. This could take several hours, depending on how much data you have stored there.
(Optional) To speed up drive preparation, prevent your PC from going to sleep. Type Power and sleep in the search box on the taskbar, then select Power & sleep settings. Under When plugged in, PC goes to sleep after, select Never.
When the drive is listed as Ready to remove, select Remove > Remove drive. Now, you can disconnect the drive from your PC.
Note: If you run into problems when you try to prepare the drive for removal, it might be because you don’t have enough free space in the pool to store all the data from the drive you want to remove. Try adding a new drive to the pool that’s as large as the drive you plan to remove and then try again.
Deploy Storage Spaces Direct
Applies to: Windows Server 2019, Windows Server 2016
This topic provides step-by-step instructions to deploy Storage Spaces Direct on Windows Server. To deploy Storage Spaces Direct as part of Azure Stack HCI, see What is the deployment process for Azure Stack HCI?
Looking to acquire hyperconverged infrastructure? Microsoft recommends purchasing a validated hardware/software Azure Stack HCI solution from our partners. These solutions are designed, assembled, and validated against our reference architecture to ensure compatibility and reliability, so you get up and running quickly. To peruse a catalog of hardware/software solutions that work with Azure Stack HCI, see the Azure Stack HCI Catalog.
You can use Hyper-V virtual machines, including in Microsoft Azure, to evaluate Storage Spaces Direct without hardware. You may also want to review the handy Windows Server rapid lab deployment scripts, which we use for training purposes.
Before you start
Review the Storage Spaces Direct hardware requirements and skim this document to familiarize yourself with the overall approach and important notes associated with some steps.
Gather the following information:
Deployment option. Storage Spaces Direct supports two deployment options: hyper-converged and converged, also known as disaggregated. Familiarize yourself with the advantages of each to decide which is right for you. Steps 1-3 below apply to both deployment options. Step 4 is only needed for converged deployment.
Server names. Get familiar with your organization’s naming policies for computers, files, paths, and other resources. You’ll need to provision several servers, each with unique names.
Domain name. Get familiar with your organization’s policies for domain naming and domain joining. You’ll be joining the servers to your domain, and you’ll need to specify the domain name.
RDMA networking. There are two types of RDMA protocols: iWarp and RoCE. Note which one your network adapters use, and if RoCE, also note the version (v1 or v2). For RoCE, also note the model of your top-of-rack switch.
VLAN ID. Note the VLAN ID to be used for management OS network adapters on the servers, if any. You should be able to obtain this from your network administrator.
Step 1: Deploy Windows Server
Step 1.1: Install the operating system
The first step is to install Windows Server on every server that will be in the cluster. Storage Spaces Direct requires Windows Server Datacenter Edition. You can use the Server Core installation option, or Server with Desktop Experience.
When you install Windows Server using the Setup wizard, you can choose between Windows Server (referring to Server Core) and Windows Server (Server with Desktop Experience), which is the equivalent of the Full installation option available in Windows Server 2012 R2. If you don’t choose, you’ll get the Server Core installation option. For more information, see Install Server Core.
Step 1.2: Connect to the servers
This guide focuses the Server Core installation option and deploying/managing remotely from a separate management system, which must have:
- A version of Windows Server or Windows 10 at least as new as the servers it’s managing, and with the latest updates
- Network connectivity to the servers it’s managing
- Joined to the same domain or a fully trusted domain
- Remote Server Administration Tools (RSAT) and PowerShell modules for Hyper-V and Failover Clustering. RSAT tools and PowerShell modules are available on Windows Server and can be installed without installing other features. You can also install the Remote Server Administration Tools on a Windows 10 management PC.
On the Management system install the Failover Cluster and Hyper-V management tools. This can be done through Server Manager using the Add Roles and Features wizard. On the Features page, select Remote Server Administration Tools, and then select the tools to install.
Enter the PS session and use either the server name or the IP address of the node you want to connect to. You’ll be prompted for a password after you execute this command, enter the administrator password you specified when setting up Windows.
Here’s an example of doing the same thing in a way that is more useful in scripts, in case you need to do this more than once:
If you’re deploying remotely from a management system, you might get an error like WinRM cannot process the request. To fix this, use Windows PowerShell to add each server to the Trusted Hosts list on your management computer:
Set-Item WSMAN:\Localhost\Client\TrustedHosts -Value Server01 -Force
Note: the trusted hosts list supports wildcards, like Server* .
To view your Trusted Hosts list, type Get-Item WSMAN:\Localhost\Client\TrustedHosts .
To empty the list, type Clear-Item WSMAN:\Localhost\Client\TrustedHost .
Step 1.3: Join the domain and add domain accounts
So far you’ve configured the individual servers with the local administrator account, \Administrator .
To manage Storage Spaces Direct, you’ll need to join the servers to a domain and use an Active Directory Domain Services domain account that is in the Administrators group on every server.
From the management system, open a PowerShell console with Administrator privileges. Use Enter-PSSession to connect to each server and run the following cmdlet, substituting your own computer name, domain name, and domain credentials:
If your storage administrator account isn’t a member of the Domain Admins group, add your storage administrator account to the local Administrators group on each node — or better yet, add the group you use for storage administrators. You can use the following command (or write a Windows PowerShell function to do so — see Use PowerShell to Add Domain Users to a Local Group for more info):
Step 1.4: Install roles and features
The next step is to install server roles on every server. You can do this by using Windows Admin Center, Server Manager), or PowerShell. Here are the roles to install:
- Failover Clustering
- Hyper-V
- File Server (if you want to host any file shares, such as for a converged deployment)
- Data-Center-Bridging (if you’re using RoCEv2 instead of iWARP network adapters)
- RSAT-Clustering-PowerShell
- Hyper-V-PowerShell
To install via PowerShell, use the Install-WindowsFeature cmdlet. You can use it on a single server like this:
To run the command on all servers in the cluster as the same time, use this little bit of script, modifying the list of variables at the beginning of the script to fit your environment.
Step 2: Configure the network
If you’re deploying Storage Spaces Direct inside virtual machines, skip this section.
Storage Spaces Direct requires high-bandwidth, low-latency networking between servers in the cluster. At least 10 GbE networking is required and remote direct memory access (RDMA) is recommended. You can use either iWARP or RoCE as long as it has the Windows Server logo that matches your operating system version, but iWARP is usually easier to set up.
Depending on your networking equipment, and especially with RoCE v2, some configuration of the top-of-rack switch may be required. Correct switch configuration is important to ensure reliability and performance of Storage Spaces Direct.
Windows Server 2016 introduced switch-embedded teaming (SET) within the Hyper-V virtual switch. This allows the same physical NIC ports to be used for all network traffic while using RDMA, reducing the number of physical NIC ports required. Switch-embedded teaming is recommended for Storage Spaces Direct.
Switched or switchless node interconnects
- Switched: Network switches must be properly configured to handle the bandwidth and networking type. If using RDMA that implements the RoCE protocol, network device and switch configuration is even more important.
- Switchless: Nodes can be interconnected using direct connections, avoiding using a switch. It is required that every node have a direct connection with every other node of the cluster.
For instructions to set up networking for Storage Spaces Direct, see the Windows Server 2016 and 2019 RDMA Deployment Guide.
Step 3: Configure Storage Spaces Direct
The following steps are done on a management system that is the same version as the servers being configured. The following steps should NOT be run remotely using a PowerShell session, but instead run in a local PowerShell session on the management system, with administrative permissions.
Step 3.1: Clean drives
Before you enable Storage Spaces Direct, ensure your drives are empty: no old partitions or other data. Run the following script, substituting your computer names, to remove all any old partitions or other data.
This script will permanently remove any data on any drives other than the operating system boot drive!
The output will look like this, where Count is the number of drives of each model in each server:
Step 3.2: Validate the cluster
In this step, you’ll run the cluster validation tool to ensure that the server nodes are configured correctly to create a cluster using Storage Spaces Direct. When cluster validation ( Test-Cluster ) is run before the cluster is created, it runs the tests that verify that the configuration appears suitable to successfully function as a failover cluster. The example directly below uses the -Include parameter, and then the specific categories of tests are specified. This ensures that the Storage Spaces Direct specific tests are included in the validation.
Use the following PowerShell command to validate a set of servers for use as a Storage Spaces Direct cluster.
Step 3.3: Create the cluster
In this step, you’ll create a cluster with the nodes that you have validated for cluster creation in the preceding step using the following PowerShell cmdlet.
When creating the cluster, you’ll get a warning that states — «There were issues while creating the clustered role that may prevent it from starting. For more information, view the report file below.» You can safely ignore this warning. It’s due to no disks being available for the cluster quorum. Its recommended that a file share witness or cloud witness is configured after creating the cluster.
If the servers are using static IP addresses, modify the following command to reflect the static IP address by adding the following parameter and specifying the IP address:–StaticAddress . In the following command the ClusterName placeholder should be replaced with a netbios name that is unique and 15 characters or less.
After the cluster is created, it can take time for DNS entry for the cluster name to be replicated. The time is dependent on the environment and DNS replication configuration. If resolving the cluster isn’t successful, in most cases you can be successful with using the machine name of a node that is an active member of the cluster may be used instead of the cluster name.
Step 3.4: Configure a cluster witness
We recommend that you configure a witness for the cluster, so clusters with three or more servers can withstand two servers failing or being offline. A two-server deployment requires a cluster witness, otherwise either server going offline causes the other to become unavailable as well. With these systems, you can use a file share as a witness, or use cloud witness.
For more info, see the following topics:
Step 3.5: Enable Storage Spaces Direct
After creating the cluster, use the Enable-ClusterStorageSpacesDirect PowerShell cmdlet, which will put the storage system into the Storage Spaces Direct mode and do the following automatically:
Create a pool: Creates a single large pool that has a name like «S2D on Cluster1».
Configures the Storage Spaces Direct caches: If there is more than one media (drive) type available for Storage Spaces Direct use, it enables the fastest as cache devices (read and write in most cases)
Tiers: Creates two tiers as default tiers. One is called «Capacity» and the other called «Performance». The cmdlet analyzes the devices and configures each tier with the mix of device types and resiliency.
From the management system, in a PowerShell command windows opened with Administrator privileges, initiate the following command. The cluster name is the name of the cluster that you created in the previous steps. If this command is run locally on one of the nodes, the -CimSession parameter is not necessary.
To enable Storage Spaces Direct using the above command, you can also use the node name instead of the cluster name. Using the node name may be more reliable due to DNS replication delays that may occur with the newly created cluster name.
When this command is finished, which may take several minutes, the system will be ready for volumes to be created.
Step 3.6: Create volumes
We recommend using the New-Volume cmdlet as it provides the fastest and most straightforward experience. This single cmdlet automatically creates the virtual disk, partitions and formats it, creates the volume with matching name, and adds it to cluster shared volumes – all in one easy step.
Step 3.7: Optionally enable the CSV cache
You can optionally enable the cluster shared volume (CSV) cache to use system memory (RAM) as a write-through block-level cache of read operations that aren’t already cached by the Windows cache manager. This can improve performance for applications such as Hyper-V. The CSV cache can boost the performance of read requests and is also useful for Scale-Out File Server scenarios.
Enabling the CSV cache reduces the amount of memory available to run VMs on a hyper-converged cluster, so you’ll have to balance storage performance with memory available to VHDs.
To set the size of the CSV cache, open a PowerShell session on the management system with an account that has administrator permissions on the storage cluster, and then use this script, changing the $ClusterName and $CSVCacheSize variables as appropriate (this example sets a 2 GB CSV cache per server):
Step 3.8: Deploy virtual machines for hyper-converged deployments
If you’re deploying a hyper-converged cluster, the last step is to provision virtual machines on the Storage Spaces Direct cluster.
The virtual machine’s files should be stored on the systems CSV namespace (example: c:\ClusterStorage\Volume1) just like clustered VMs on failover clusters.
You can use in-box tools or other tools to manage the storage and virtual machines, such as System Center Virtual Machine Manager.
Step 4: Deploy Scale-Out File Server for converged solutions
If you’re deploying a converged solution, the next step is to create a Scale-Out File Server instance and setup some file shares. If you’re deploying a hyper-converged cluster — you’re finished and don’t need this section.
Step 4.1: Create the Scale-Out File Server role
The next step in setting up the cluster services for your file server is creating the clustered file server role, which is when you create the Scale-Out File Server instance on which your continuously available file shares are hosted.
To create a Scale-Out File Server role by using Server Manager
In Failover Cluster Manager, select the cluster, go to Roles, and then click Configure Role….
The High Availability Wizard appears.
On the Select Role page, click File Server.
On the File Server Type page, click Scale-Out File Server for application data.
On the Client Access Point page, type a name for the Scale-Out File Server.
Verify that the role was successfully set up by going to Roles and confirming that the Status column shows Running next to the clustered file server role you created, as shown in Figure 1.
Figure 1 Failover Cluster Manager showing the Scale-Out File Server with the Running status
After creating the clustered role, there might be some network propagation delays that could prevent you from creating file shares on it for a few minutes, or potentially longer.
To create a Scale-Out File Server role by using Windows PowerShell
In a Windows PowerShell session that’s connected to the file server cluster, enter the following commands to create the Scale-Out File Server role, changing FSCLUSTER to match the name of your cluster, and SOFS to match the name you want to give the Scale-Out File Server role:
After creating the clustered role, there might be some network propagation delays that could prevent you from creating file shares on it for a few minutes, or potentially longer. If the SOFS role fails immediately and won’t start, it might be because the cluster’s computer object doesn’t have permission to create a computer account for the SOFS role. For help with that, see this blog post: Scale-Out File Server Role Fails To Start With Event IDs 1205, 1069, and 1194.
Step 4.2: Create file shares
After you’ve created your virtual disks and added them to CSVs, it’s time to create file shares on them — one file share per CSV per virtual disk. System Center Virtual Machine Manager (VMM) is probably the handiest way to do this because it handles permissions for you, but if you don’t have it in your environment, you can use Windows PowerShell to partially automate the deployment.
Use the scripts included in the SMB Share Configuration for Hyper-V Workloads script, which partially automates the process of creating groups and shares. It’s written for Hyper-V workloads, so if you’re deploying other workloads, you might have to modify the settings or perform additional steps after you create the shares. For example, if you’re using Microsoft SQL Server, the SQL Server service account must be granted full control on the share and the file system.
You’ll have to update the group membership when you add cluster nodes unless you use System Center Virtual Machine Manager to create your shares.
To create file shares by using PowerShell scripts, do the following:
Download the scripts included in SMB Share Configuration for Hyper-V Workloads to one of the nodes of the file server cluster.
Open a Windows PowerShell session with Domain Administrator credentials on the management system, and then use the following script to create an Active Directory group for the Hyper-V computer objects, changing the values for the variables as appropriate for your environment:
Open a Windows PowerShell session with Administrator credentials on one of the storage nodes, and then use the following script to create shares for each CSV and grant administrative permissions for the shares to the Domain Admins group and the compute cluster.
Step 4.3 Enable Kerberos constrained delegation
To setup Kerberos constrained delegation for remote scenario management and increased Live Migration security, from one of the storage cluster nodes, use the KCDSetup.ps1 script included in SMB Share Configuration for Hyper-V Workloads. Here’s a little wrapper for the script:
Next steps
After deploying your clustered file server, we recommend testing the performance of your solution using synthetic workloads prior to bringing up any real workloads. This lets you confirm that the solution is performing properly and work out any lingering issues before adding the complexity of workloads. For more info, see Test Storage Spaces Performance Using Synthetic Workloads.