Table of Contents
- FSCT Test System Components
- Test Results
- Configuration & Preparation
- Test Assessment
What is FSCT?
FSCT (File Server Capacity Tools) was developed by Microsoft to provide accurate and detailed results when testing file server capacity and identifying performance bottlenecks. For the Morro system, we can use it to simulate multiple users accessing shares at the same time and identify how many users we can handle under different hardware configurations.
FSCT Test System Components
CacheDrive G80 Pro
Morro Data SKU: G8022P1 with 4TB SSD Cache, 8GB DRAM
Configuration & Preparation
There are three types of physical computer components in an FSCT test configuration: the controller, the server, and the clients. In the case of an Active Directory environment, we also need a domain controller.
|The controller is used to synchronize test activity and collect test data.|
The controller must be running on a Microsoft Windows operating system.
|The server is responsible for sharing files, and it is the server’s performance that is tested during an FSCT run phase. ||Multiple client computers are required to generate a workload sufficient to saturate the server’s capacity. Clients can simulate one or more users on the same computer. The total number of users should represent the expected load on the server when testing for capacity planning. |
The G80 acts as a file server and joins with the controller and clients on Active Directory. Every client accesses files on the G80 via SMB protocol with multiple users.
Figure 1. Network Configuration
- Workload: HomeFolders (FSCT default workload)
- Duration: 90 seconds
- Volume number: 1
- User number step: 100
- Command: FSCT run controller /server G80 /password password /volumes \\G80\fsroot1 /clients Client1,Client2,Client3 /min_users 100 /max_users 1000 /step 100 /duration 900 /workload HomeFolders
The CacheDrive is not a Windows system, so we only can run FSCT in ADS mode. Therefore, the Morro server (CacheDrive), the controller (Windows Server), and the clients (Windows) all need to join ADS.
FSCT will access the CacheDrive from the clients using the designated number of users. If ADS mode is not used, one would need to create hundreds or thousands of user accounts on both the CacheDrive and the Windows clients. In ADS mode, FSCT has tools to create large numbers of ADS users.
On clients, we need to enable the “Remote Registry” service and disable the firewall. Otherwise, the controller cannot collect the performance counter data from the clients.
Download and uncompress the FSCT package, then copy it to “C:\” on the DC, controller, and clients.
Prepare Domain Controller
Run the following command at the domain controller command prompt to prepare the DC.
fsct prepare dc /users <number of users> /password <password> /clients <client1,client2,...>
Figure 2. Prepare Domain Controller
FSCT will create the number of AD users specified in the command. The user names will be “client name-x”, with “x” starting at 1. The password for all users will be the same.
Note: “Win2016-1” is my client computer name.
Run the following command on the controller to prepare theserver.
fsct prepare server /clients <client1,client2,...> /password <password> /users <number of users> /domain <domain name> /volumes \\<server name>\<share> /workload <workload name> /create_only_fileset
Figure 3. Prepare Server
FSCT will create a home folder (including sub-folders and files) for every user. The subfolders and files are dependent on the file “Fileset.xml” for the workload (see the Workload section below). The share name on CacheDrive must be “fsrootx”, where “x” is a number like 1, 2 ...
Note: “Win2016-1” is the client computer name.
Running below command on the controller to prepare server.
fsct prepare controller
FSCT will remove the “result” folder on the controller. “result” contains the test result for the
Run the following command on the clients to prepare the clients.
fsct prepare client /server <server name> /password <password> /users <number of users> /domain <domain name> /server_ip <server IP address>
Figure 4. Prepare Clients
FSCT will add "server_ip server_name" and “server_ip server_nameux” (x is number from 1 to the total users' number) to the “hosts” file. Every user will connect the corresponding server name. For example, the user “Win2016-u1” will log in to the server "V200-610u1". “V200-610” is the example hostname of the DUT CacheDrive.
Run the following command on clients first:
fsct run client /controller <controller name> /server <server name> /password <password>
Then run the following command on the controller:
fsct run controller /server <server name> /password <server password> /volumes \\<server name>\<share> /clients <client1,client2,...> /min_users <minusers> /max_users <maxusers> /step <usersstep> /duration <duration> /workload <workload name>
The FSCT Workload defines what kind of information is stored on and transferred between the server and the clients, which operations are performed on the file set, how many iterations of each test will be run, and what thresholds are used to determine that the test has finished.
FSCT includes a default workload – “HomeFolders”. For a workload, there are 3 main files:
Contain configuration details for the scenarios that will be run during the test, commands defining warm-up routines, commands defining how the cache will be used during the test, and a list of files that will be used during each scenario.
Contain the names of performance counters to be collected and the interval at which they will be collected on the Server and on all Clients. This file can be edited to add or remove performance counters collected.
Contain details about the files, destination path, and source path that will be created on the server for use by clients during the test. This directory may contain additional files that represent subsets of the file set. They are used if a scenario DLL should use only part of the file set.
From the above table, for the workload “HomeFolders”, 331 scenarios will be run in one hour. So for 100 users and the duration set to 900s (15 minutes), 8275 scenarios will be performed. This matches the real testing result (Figure 7).
Note: 331 = 15+150+40+7+15+50+15+5+15+7+7+5
8275 = 331 * 100 / 4
Figure 7. Controller Running FSCT for 100 users and 900 seconds
Figure 8. Part of the “perf.txt” File
The Morro Data CacheDrive is not a Windows system, so FSCT cannot collect the resources data such as CPU and memory usage from the performance counters for the CacheDrive.
Figure 9. Part of the “fileset.xml” File and the corresponding folder view on MCM > Files
Part of the file “fileset.xml” about the fileset “static” is shown as an example. For the workload “HomeFolders”, the file“fileset.xml” defines 3 filesets: “static”, “new”, and “volatile”, so FSCT will create these 3 folders for each user in the share.
We can specify the minimum and maximum number of users and a step-for-one test. This tells FSCT to run a number of iterations starting with the minimum number of users, and then adding the steps for the next iteration until it reaches the maximum number of users in the last run.
Duration defines how long one iteration will run. FSCT recommends a duration of 10 minutes to 15 minutes (600 seconds to 900 seconds). If the time is too short, the results will have higher variance, and if the run time is too long, the workload may run out of files and start to report errors.
FSCT collects data (such as CPU and memory usage) from the Windows Performance counter, but our CacheDrive is not a Windows system, so FSCT will not be able to get the data. During the testing, please monitor the CPU and memory usage from the Morro Audit -> Device -> STATUS -> CPU/Memory Usage page to identify which resource will be exhausted first.
We can find the test result of FSCT on the controller below path:
- After a test has finished, we need to wait until all requests in the `req_queue` have been completed before we can perform the next test.
- After a test has been finished, we need to clean the controller and clients with the following commands:
fsct cleanup controller /backup <backup directory>
fsct cleanup client /users <number of users>
- To make sure the test result is accurate, we should create a new share and run “Prepare server” again on the controller to prepare files on the CacheDrive every time before testing. We did not delete the old share, so the new share will do file deduplication. The purpose of utilizing file deduplication is to more accurately test the SMB handling capability of the server which is the purpose of the FSCT test.
- From the test results in the Test Results section, we show that CacheDrive G80 Pro is capable of supporting up to 1800 simultaneous users running the FSCT test. This shows that CacheDrive is efficient in handling the SMB interface. In real use scenarios, actual performance will depend on the applications used and the number of files simultaneously opened by the users.
- The FSCT test focuses on SMB performance. For this reason, we configured the CacheDrive share to remove the following computing components of CacheDrive from this FSCT test:
- File upload to cloud (by making the files always deduped)
- Simultaneous file downsync from the cloud to the CacheDrive (by using a single CacheDrive in the system)
- The size of DRAM in a CacheDrive will affect the maximum number of simultaneous users in the FSCT test as each additional user would consume some memory resources. From the results of the current test, we recommend a CacheDrive, whether VM or physical appliance, to have at least 8GB of DRAM in a multiuser environment.