AWS Storage Gateway (Volume Gateway) with Windows Server Failover Clustering in AWS

Scenario:
If you are implementing Windows Server Failover Clustering (WSFC) in AWS cloud then you may be thinking how to get the shared storage for the Windows Failover Cluster because as far as I know natively there is no service called “shared storage (SAN/NAS)” that we can simply use with WSFC. Elastic Block Storage (EBS) volumes attached with WSFC nodes obviously can’t be used for this purpose. Many times customer ask about having shared storage for WSFC until they research about this topic in detail.

I’m consolidating this topic to clear the confusion around shared storage in AWS cloud and different options of shared storage that one may choose based on feasibility.

Below are 4 different possible options that can help you if you are really looking for shared storage solution in AWS cloud for Windows Server Failover Clustering. This blog post is about how to use AWS Storage Gateway (Volume Gateway) for shared storage with Windows Server Failover Clustering.

1. Build iSCSI Server on Windows EC2 Instance:
Build iSCSI Target Server on EC2 Instance with use EBS Volumes as iSCSI disk with WSFC nodes. You can deploy this in HA scenario as well to have highly available iSCSI storage service.

2. Build Windows 2016 Storage Spaces Direct (S2D) on Windows EC2 Instance:
Build Windows Server 2016 Storage Spaces Direct (S2D) solution on EC2 Windows Instances. This is a native storage virtualization (Virtual SAN) solution from Microsoft that runs on Windows Server 2016 and uses Windows Failover Clustering underlying to function.

3. AWS Storage (Cached Volume Gateway) on EC2:
Use AWS Storage Gateway (Cached Volume Gateway) as iSCSI Target and use EBS volumes as iSCSI disk with WSFC nodes.

4.Third party Virtual SAN solution from AWS Marketplace:
Deploy third party Virtual SAN solutions from AWS Marketplace like NetApp or StarWind Virtual SAN.

In this blog post I will would be discussing about using AWS Storage (Cached Volume Gateway) on EC2 with Windows Server Failover Clustering running on AWS EC2 instance.

High Level steps for lab setup:
1. Deploy AWS Storage Gateway (Cached Volume Gateway) as EC2 Appliance.
2. Configure and Activate the Gateway.
3. Configure the local disks (EBS volumes) for Caching and Uploader Buffer.
4. Create iSCSI volumes and configure iSCSI Target on AWS Storage Gateway.
5. Enable iSCSI Initiator and connect iSCSI volumes (created in step 4) on the EC2 Windows instances that will be acting as WSFC nodes.
6. Run the cluster validation and see if the iSCSI disks are passing storage validation tests.
7.Add the iSCSI volumes as Clustered Disks in Windows Server Failover Clustering (WSFC).
8.Add Clustered Disk to Clustered Shared Volumes (CSV)

Before we proceed further with deployment of AWS Storage Gateway, let’s first get the high level overview of AWS Storage Gateway:

What is AWS Storage Gateway ?
AWS Storage Gateway is one of the managed storage service in AWS cloud. This is basically hybrid storage service that helps us seamlessly connecting workloads running On-premises datacenters with AWS cloud storage using industry standard storage protocal. So I would say that this storage service is kind of an extension or storage layer between on-premises storage and AWS cloud-based storage. There are different use cases of AWS Storage Gateway and it has rich integration with Simple Storage Service (S3), it also backs up data to S3 as EBS snapshot.
The AWS Storage Gateway is deployed as an appliance in Windows Hyper-V, Vmware ESXi virtualization environments and as AWS EC2 Instance as well.

AWS Storage Gateway Types:
There are three different types of Storage Gateways are currently offered as below based on different use case. I will not be explaining each of the Storage Gateway in very detail, our focus in this blog post is focused on “Volume Gateway”.

1. File Gateway : Using file gateway we can store and retrieve files from Simple Storage Service (S3) using SMB, NFS protocols and files stored can also be accessed by different AWS services. We can also use native S3 capabilities like cross-region replication and versioning etc. File Gateway can be deployed as EC2 Instance and on-premises as well.

2. Volume Gateway: Volume Gateway provides EBS storage as iSCSI volumes that we can use with our on-premises infrastructure as well as cloud. Volume Gateway has two types:

Cached Volume Gateway: Stores data in Amazon S3 and retains low-latency access to frequently accessed data. Cached Volume Gateway can be deployed on EC2 instance as well as on-premises.

Stored Volume Gateway: Store complete data locally and makes an asynchronous copy of  the data in S3 and point-in-time EBS snapshots. This way it provides durable and cost effective offsite backups that we can always recover based on the different scenarios. Stored Volume Gateway can’t be deployed as EC2 Instance, So this is only for on-premises scenario.

3. Tape Gateway: This helps archiving data from on-premises or cloud to Amazon GLACIER or DEEP_ARCHIVE storage. Tape Gateway can be deployed on-premises as a VM or hardware appliance, or in AWS as an EC2 instance. We can integrate Tape Gateway with existing backup solution.

Now let’s go ahead and start the deployment of AWS Storage Gateway (Volume Gateway):

1. Deploy AWS Storage Gateway (Cached Volume Gateway) as EC2 Appliance:

–Navigate to Storage Gateway Service in AWS Console, Click on the “Get Started” to proceed.



–Select the Volume Gateway and then select “Cached Volumes”. I’m selecting “Cached Volumes” here because this is the only volume gateway type that can be deployed as EC2 appliance, my Windows Cluster is running on EC2 where I will be using this volume as iSCSI disks as shared volume.



–Click on “Next” and choose “Amazon EC2”, then click on “Launch with AWS Marketplace”



–Once you click on “Launch with AWS Marketplace” it will redirect you to AWS Marketplace to subscribe this solution.



–Click on “Continue to subscribe” to proceed further.


–Review the details and click on “Continue to configuration”, then click on “Continue to Launch”.


–Now I selected “Launch through EC2” and desired VPC.



–Finally click on “Launch” button.


–Once you click on “Launch” button it will take you to EC2 instance launch wizard page.


–Selected desired configuration as per your environment. I’m deploying this Storage Gateway appliance in same VPC network as my application workload.
 

–Apart from Root volume, I have added two more EBS volumes (each 150 GB) and those EBS volumes would be used as Cache and Upload Buffer respectively.


–It creates a Security Group that allows required ports for SSH, iSCSI, HTTP. I have allowed all the inbound traffic from my default Security Group which is being used by Windows instances to avoid any communication issues within my lab instances.



–Now provide key pair and click on the launch button to start the deployment of Storage Gateway EC2 Appliance.




–And it’s being launched now.


–I have my Storage Gateway appliance launched successfully and both status checks are passed.


2. Configure and Activate the Gateway
–Now I’m back to the Storage Gateway service console and perform further configuration of the Storage Gateway. I selected service endpoint as “Public”, if you don’t want your Storage Gateway to communicate over Internet then you can choose VPC and you would have to setup VPC endpoint for this to make it work.



–Provide Gateway IP address and Click on “Connect to Gateway”.


–Select desired Time Zone and name your Gateway as per your wish and Click on “Active Gateway”.


–The Storage Gateway is now active and loading up the local disks (EBS volumes) attached to it.

3. Configure the local disks (EBS volumes) for Caching and Uploader Buffer.
–Both EBS Volumes attached to gateway appliance are local disks and they are not allocated yet.


–So we have two EBS volumes attached to this Storage Gateway appliance as local disks, One of the EBS volume would be used as “Cached volume” and other one as “Upload Buffer” as allocated below.


–So now we have our Storage Gateway running successfully with local disks configured.

4. Create iSCSI volumes and configure iSCSI Target on AWS Storage Gateway
–The next step would be create the required iSCSI volumes and configure iSCSI Target on this appliance.
–Click on “Create Volume” and specify the size of the volume along with iSCSI Target server name.




–I skipped CHAP Authentication for now, if you would like to have this configured for security reason you can go ahead.




–I created another 50 GB iSCSI volume.


–Now we have successfully created two “Cached” iSCSI volumes.
Vol-0000xxxx8 – 50 GB
Vol-0d75xxxx0 – 100 GB



5. Enable iSCSI Initiator and connect iSCSI volumes (created in step 4) on the EC2 Windows instances that will be acting as WSFC nodes.

–I have 2 Node Windows 2016 Cluster running on EC2 Instance.



–If you look at the WSFC console, I don’t have any Clustered Disk added to my cluster at the moment.



–By default, iSCSI Initiator service will in stopped state. To start this service, Open iSCSI Initiator and click on “Yes”.





–Once the iSCSI service is running, you can see the IQN of this iSCSI Initiator from its properties.


–Enter the IP Address Storage Gateway in the “Target” tab of the iSCSI Initiator properties and Click on “Quick Connect” to connect this WSFC node to iSCSI Target Server which is our Storage Gateway.



–It will show you both IQN of the iSCSI Target Server, Click on “Connect” button to connect them.



–If you see below screenshot, both iSCSI Target Servers are connected successfully.


–If you look at the Storage Gateway Console, you will see both iSCSI Initiators connected.


–Now if you look at the Disk Management console on the WSFC node, you would see two disk connected. These are 2 iSCSI disks presented from the Windows Cluster node from Storage Gateway which is acting as iSCSI Target Server.


–Bring both disks online and Initialize them as GPT or MBR.





–Create the volume and format them as NTFS.


–If you look at the Device Manager console, these two disks will be showing as “Amazon Storage Gateway SCSI Disk Device”.


Note: Repeat the Step 5 for all the nodes that are part of WSFC.

6.Run the cluster validation and see if the iSCSI disks are passing storage validation tests
–Now we will run the Windows Cluster Validation to see if these 2 iSCSI disks are being recognized and its passing the storage validation tests.



–Click on “Next” button to proceed further. Select “Run only tests I select”.


–I’m selecting only “Storage” test.




–I don’t see any errors in the disk validation for the cluster.

7. Add the iSCSI volumes as Clustered Disks in Windows Server Failover Clustering (WSFC).
–Now go the WSFC console and add both the disks to cluster.





–Both of the iSCSI disks are added as Clustered disk to Windows Cluster. These disks are accessible on both of the cluster nodes and are treated as shared storage LUN at the moment.



–If you see these disk volumes from explorer, it would be showing like this.


8. Add Clustered Disk to Clustered Shared Volumes (CSV)
–If want to add the cluster disk as CSV then right click on the Disk and click on “Add to Cluster Shared Volumes”.


–I added my both cluster disks as CSV volumes.




–Cluster Shared Volumes are mounted under “C:\ClusterStorage” path by default.

Important Note:
While this seems to fulfil the shared storage requirement for Windows Cluster, I see single point of failure because the Storage Gateway Appliance sitting on EC2 instance doesn’t have redundancy if anything happens with the appliance then it would bring the whole Windows Cluster down.

Please refer following documentation about AWS Storage Gateway Performance:
Storage Gateway Performance:
https://docs.aws.amazon.com/storagegateway/latest/userguide/Performance.html

1 thought on “AWS Storage Gateway (Volume Gateway) with Windows Server Failover Clustering in AWS”

Leave a Reply

Your email address will not be published. Required fields are marked *