AdvLab2: Multi-Region Amazon FSx

Author: Dean Suzuki (Last Updated: 6/10/20)

(6/10/20): Incorporated feedback from Caio Ribeiro Cesar

Abstract

In this lab, you will setup a multi-region Amazon FSx for Windows File Server architecture. Customers that need to have a copy of their data in another AWS Region for disaster recovery requirements or simply want to move data between regions have requested this architecture. As background, Amazon FSx for Windows File Server has multiple tiers of resiliency. Within an AWS Region, customers can choose between a single-AZ (availability zone) and a multi-AZ architecture. Within a single AZ, Amazon FSx replicates the data so that multiple copies exist in the availability zone for high availability. If you select Multi-AZ, then Amazon FSx will do a synchronous block level replication of the data to another availability zone. Image 1 - Multi-AZ File System Architecture: Client connections from Multi-Az and Onpremises through Direct Connect or VPN connecting to the Primary FSx File Server Elastic Network Interface. This primary file server replicates data synchronously to the standby file server

Image 2 - Multi-AZ File System Architecture: Multi-AZ file systems automatically fail over from the preferred file server to the standby file server if any of the following conditions occur: due to an Availability Zone outage, the preferred file server becomes unavailable, or the preferred file server undergoes planned maintenance. In such scenarios, Amazon FSx will automatically fail over to the standby, so that you can maintain operations without losing any data. Failover typically takes less than 30 seconds. The DNS name remains unchanged, making replication and failover transparent, even during planned maintenance windows.

Image 3 - Multi-AZ File System Architecture: Failback to the original Multi-AZ configuration also completes in less than 30 seconds, and only occurs once the file server in the preferred subnet is fully recovered.

Some customers need to have a copy of their data also in another AWS region for disaster recovery purposes. In this hands-on lab, you will use AWS DataSync to replicate Amazon FSx data to another region.

Thus far, you have been working in the N. Virginia region (us-east-1). In this lab, you will be setting up Amazon FSx for Windows File Server in the Oregon region (us-west-2). You will use AWS DataSync to replicate the Amazon FSx data from the N. Virginia region (source) to the Oregon region (target).

Prerequisites

This lab relies upon the resources created in some of the prior labs (https://aws-labs.net):

  • Building the network

  • Deploying Active Directory

  • Administering AD

  • Building file servers

Table of Information

During the lab, you will reuse certain information so the instructions suggest that you record these items down into a notepad file. We have summarized the items below. You can copy the headers into your notepad file to start.

Source FSx File System IP address:
Source FSx File System DNS name:
Source FSx security group id:
Oregon VPC ID:
Destination FSx File System IP address:
Destination FSx File System DNS name:
Destination FSx security group id:
DataSync Agent Public IP address:

Step 1: Record source Amazon FSx details and update security group

You need to record some information on the Amazon FSx file system in the source region (N. Virginia) and update the security group to allow the DataSync agent to communicate with it.

  1. In the AWS console, go to FSx.

  2. Make sure that you are in Virginia region (us-east-1).

  3. In the left hand navigation, select File systems.

  4. Select the Projects file system.

  5. In the Network & security tab, copy the DNS name of the files system and store it in the notepad as the Source Amazon FSx DNS name.

  6. Copy the Preferred File Server IP address and store it in a notepad file as the Source Amazon FSx IP address. You will use this information later.

  7. Look for the Network interface under Preferred subnet.

  8. Click the eni-### hyperlink.

  9. In the Details pane of the network interface, look for Security groups and click the default link.

  10. In the bottom menu, select Inbound tab and press Edit.

  11. Press Add Rule,

    a. For Type, All traffic.

    b. For source, 10.0.0.0/8.

    c. Press Save.

This will allow other hosts in our 10.0.0.0 network to communicate with the Amazon FSx file system.

Step 2: Establish Network Connectivity between AWS regions.

The next step is to establish the network infrastructure (a VPC) in the Oregon region and enable network connectivity between the VPC in the Oregon region and the VPC in the N. Virginia region.

Step 2a: Setting up the Virtual Private Cloud (VPC) in Oregon region.

In this section, you will create a VPC in the Oregon region.

  1. In the AWS console, go to VPC.

  2. Switch regions to the Oregon region by going to the upper right corner and selecting Oregon from the drop down list.

  3. Click “VPC

  4. Press the Create VPC button.

  5. In Create VPC screen, enter the following:

    a. Name tag: DR-VPC

    b. IPv4 CIDR block: 10.1.0.0/16

    c. IPv6 CIDR block: No IPv6 CIDR block

    d. Tenancy: Default

  6. Then, press Create button. Then, press Close button.

  7. Select the VPC that you just created. Go to the Description tab in the bottom half of the screen. Copy the VPC ID of your new VPC to a notepad file. You will need it later.

  8. Select Subnets on the left navigation menu.

  9. Press Create subnet button.

  10. On the Create subnet screen, enter the following;

    a. Name tag: Private Subnet 1

    b. VPC: <Select the VPC that you just created. The name and VPC ID should match>

    c. Availability Zone: us-west-2a

    d. IPv4 CIDR block: 10.1.1.0/24

    e. Private subnet’s IPv4 CIDR: 10.1.2.0/24

  11. Press Create. Then, press Close.

You now have a network infrastructure (VPC) with one private subnet in Oregon region.

Step 2b: Setup network peering between AWS Regions

In this section, you will establish network connectivity between the two regions (Virginia and Oregon). Inter-region network connectivity can be done in multiple ways (e.g. using Transit Gateway or VPC Peering). In this lab, you will use VPC peering for simplicity. However in production environments, if you have multiple VPC’s and need to connect them together, you should consider using the new Transit Gateway service.

  1. In the AWS console, go to VPC.

  2. Switch regions to the N. Virginia region by going to the upper right corner and selecting N. Virginia from the drop down list.

  3. In the left menu, select Peering Connections.

  4. Press Create Peering Connection button.

  5. On the Create Peering connection screen, enter:

    a. Peering connection name tag: Oregon-Virginia-Peering

    b. VPC (Requester): <Select the WinVPC-VPCStack that you created earlier>

    c. Region: Another region and select the US West (Oregon) in the dropdown.

    d. VPC (Accepter): <Paste the VPC ID of the VPC that you created in Oregon>

  6. Click Create Peering Connection. Press OK.

  7. Next, you need to accept the peering request in Oregon. Switch regions to the Oregon region by going to the upper right corner and selecting Oregon from the drop down list.

  8. In Oregon region on the Peering Connection section, select the VPC Peering request and go to Action menu. Select Accept Request. Press Yes, Accept. Press Close.

  9. You will see the VPC Peering status as “Active”

Step 2c: Setup network routing between AWS Regions.

Now you have established network connectivity between both regions. You will update the route tables so that network traffic can route between regions.

  1. In the AWS console, go to VPC.

  2. Switch to the Oregon region

  3. In the left hand navigation in the Select a VPC field, select the DR-VPC that you created earlier. This filters the view to show the objects in this VPC.

  4. In the left hand navigation, select Route Tables.

  5. Select the Route table and in the bottom of the screen, click on the Routes tab.

  6. Press Edit routes.

  7. Press Add route.

  8. On the Edit routes screen, enter:

    a. Destination: 10.0.0.0/16

    b. Target: Peering Connection and then select your peering connection, pcx-###.

  9. Press Save routes. Press Close.

This enables the resources in Oregon to know how to route packets to the resources in Virginia. Next, you will repeat the process and update the route tables in Virginia.

  1. In the AWS console, go to VPC.

  2. Switch regions to the N. Virginia region by going to the upper right corner and selecting N. Virginia from the drop down list.

  3. In the left hand navigation in the Select a VPC field, select the WinVPC-VPCStack that you created earlier. This filters the view to only show the objects in this VPC

  4. In the left hand menu, select Route Tables.

  5. Select the Private subnet 1A Route table and in the bottom of the screen, click on the Routes tab.

  6. Press Edit routes.

  7. Press Add route.

  8. On the Edit routes screen, enter:

    a. Destination: 10.1.0.0/16

    b. Target: Peering Connection and then the peering connection pcx-###.

  9. Press Save routes. Press Close.

  10. Repeat the process for Private subnet2A

  11. Select the Private subnet 2A Route table and in the bottom of the screen, click on the Routes tab.

  12. Press Edit routes.

  13. Press Add route.

  14. On the Edit routes screen, enter:

    a. Destination: 10.1.0.0/16

    b. Target: Peering Connection and then the peering connection, pcx-###.

  15. Press Save routes. Press Close.

Congratulations. You have established network connectivity between AWS Regions (N. Virginia and Oregon).

Step 3: Create Amazon FSx File System in Oregon

Next, you will create an Amazon FSx file system in Oregon to host the DR copy of the Amazon FSx file system in Virginia.

  1. In the AWS console, go to FSx.

  2. Make sure that you are in Oregon region.

  3. Press Create file system.

  4. Select Amazon FSx for Windows File Server. Press Next.

  5. On the Create file system screen, enter:

    a. File system name: Projects-DR

    b. Deployment type: Single-AZ. Note in production environments, you may want to use a Multi-AZ deployment. However, for the lab purposes, we are recommending Single-AZ since it takes less time to setup. A Multi-AZ deployment could take up to two times longer to setup.

    c. Storage capacity: 32 GB

    d. Select Recommended throughput capacity.

  6. VPC: DR-VPC

  7. VPC Security Group: <leave default>. Record the last four characters of the security group as Oregon-FSx-SG in your notepad file. You will need to update it later.

  8. Subnet: Private subnet 1

  9. For Windows authentication: Self-managed Microsoft Active Directory. Note: You will be leveraging the AWS Managed Microsoft Active Directory in the N. Virginia region.

  10. Fully qualified domain name: corp.example.com

  11. DNS server IP addresses:

    a. Open another tab and go to the Directory Service.

    b. Change region to N. Virginia

    c. Select the hyperlink for the AWS Managed Microsoft.

    d. Copy the two DNS addresses that are listed for the AWS Managed Microsoft AD to your notepad file.

    e. Go back to Amazon FSx tab and enter the DNS IP addresses.

  12. Service account username: Admin. Note in a production environment, you would create a service account specifically for this Amazon FSx access. For simplicity in the lab, we are going to use the Admin account.

  13. Service account password: <Enter the password that you specified when you created the AWS Managed Microsoft AD>

  14. Delegated file system administrators group: AWS Delegated FSx Administrators. Note: This value should be set to AWS Delegated FSx Administrators if you are using AWS Managed Microsoft AD. If you are using your own AD, then specify the group that you have delegated File System administrator’s access in your source region.

  15. Use the defaults for the remaining entries.

  16. Press Next.

  17. Press Create file system.

  18. While the file system is being created, open a new tab and go to the EC2 console. In the left hand navigation, go to Security Groups.

  19. Make sure that you are in the Oregon region.

  20. Look for the security group (recorded in your notes earlier). Click it. Go to the Inbound rules tab. Press Edit inbound rules.

  21. Press Add rule

  22. For Type, select All traffic.

  23. For Source field, enter 10.0.0.0/8. This will allow hosts in the 10.0.0.0/16 (Virginia) and 10.1.0.0/16 (Oregon) to access the Amazon FSx file system.

  24. Press Save rules.

It will take about 20 minutes to create the new file system. During this time, AWS is creating the Windows servers to support the file system, joining them to the domain, and allocating the storage. This is the good time to take a break. When the file system is ready, you will see the status as Available. 25. Once the file system is created, click the Projects-DR hyperlink. Copy the DNS name and IP address of the Amazon FSx file system in Oregon to your notepad file.

Step 4: Setup AWS DataSync to replicate the data

Now, you will setup AWS DataSync to replicate the data from the Projects file system in N. Virginia region to the Oregon region.

Step 4a: Load the DataSync agent

The first step is to install the DataSync agent in the source region to monitor the source file system so that DataSync knows what to replicate to the destination.

When using DataSync, the best practice is to place the DataSync agent as close to the source system as possible.

  1. In the AWS console, go to EC2.

  2. Make sure that you are in N. Virginia region.

  3. Go to the page (link). On the web page, look for the table, DataSync AMIs by AWS Region. In the table, look for the us-east-1 entry, and click Launch instance.

  4. On the Instance type, select t3.large. Press Next.

  5. On Configure Instance Details screen, enter:

    a. Network: WinVPC-VPCStack

    b. Subnet: Public subnet 1. The DataSync agent will communicate with the AWS DataSync public endpoint. Note in a production environment, you would typically install the DataSync Agent in a private subnet. However to simplify the lab configuration, we are creating it in the public subnet.

    c. Auto-assign Pubic IP: “Use subnet settings (Enable)

    d. Press Next.

  6. On the Add Storage screen, press Next.

  7. On the Add Tags screen, press Add Tag

    a. For Key: Name

    b. For Value: DataSync-Agent

    c. Press Next.

  8. On the Configure Security Group screen, enter

    a. Assign a security group: Create a new security group

    b. Security group name: DataSync-Agent-SG

    c. Description: DataSync-Agent-SG

    d. Press Add rule.

    e. For Type, select HTTP

    f. For Source, enter 0.0.0.0/0

    g. For the SSH rule, update the Source to: 10.0.0.0/16

    h. Press Review and Launch.

  9. Press Launch.

  10. For Keypair, select Choose an existing key pair and specify WinLab-KeyPair.

  11. Click Launch Instances.

  12. Click View Instances.

Wait for the DataSync-Agent instance to become available and it passes the two status checks. 13. Select the DataSync-Agent instance and go to the Description area below. Look for the IPv4 Public IP address of the server and copy it to notepad.

Step 4b: Activate the DataSync Agent

When you use AWS DataSync, the other best practice is to activate the agent in the destination region. So the first best practice is to install the agent as close to the source as possible. Then, you activate the agent in the destination region. You are going to do the activation in this step.

  1. In the AWS console, go to DataSync.

  2. Make sure that you are in Oregon region. It is critical that you select the Destination region for this step.

  3. Press Get Started.

  4. For Service endpoint, select Public service endpoints in US West (Oregon)

  5. In the agent address, enter the public IP address of the DataSync agent that you just created.

  6. Press Get key.

  7. Your browser will communicate with the agent over the public IP address. Once communication is established, DataSync will generate an activation key.

  8. Scroll down and press Create agent.

Congratulations. You installed and activated the DataSync agent.

Step 4c: Create DataSync task to replicate the data

Now, you will create the task of replicating the data from the source location (Amazon FSx in N. Virginia) to the destination location (Amazon FSx in Oregon).

The AWS DataSync agent locally calculates the checksum of every file in the source file system and the destination and compares them. DataSync uses this information to determine what files have changed and to only replicate the files that have changed in the source to the target. If the DataSync agent node fails, then you can create a new Agent node. The new DataSync Agent will re-calculate the checksums on the source and destination and determine what files have changed and should be replicated.

  1. Select Create task.
  2. For source location options, select Create a new location

  3. For location type, select Server Message Block (SMB)

  4. For Agents, select the agent that you just installed.

  5. For SMB Server, enter the Amazon FSx Preferred IP address of Amazon FSx system in N. Virginia that you recorded earlier into the SMB Server field.

  6. For the Share name, enter share.

  7. Under User settings for User, enter admin.

  8. For Password, enter the password that you supplied when you created the AWS Managed Microsoft AD. Note: In a production environment, you would normally create a DataSync agent service account. For lab purposes, we are simplifying the steps by choosing the admin account.

  9. For domain, enter corp.example.com

  10. Press Next.

  11. For Configure destination location, select Create a new location.

  12. For Location Type: Amazon FSx for Window File Server

  13. For FSx file system: Projects-DR

  14. For share name: share

  15. Under User settings, for user: admin

    a. For password, enter the password for your AWS Managed Microsoft AD

    b. For domain, corp.example.com

    c. Press Next.

  16. For task name: DataSync-Virginia-to-Oregon-FSX

  17. For Verify data, select Verify only the data transferred. This reduces the amount of time that the DataSync task runs.

  18. For Schedule, set Frequency to Hourly

  19. Press Next.

  20. Review the settings. Press Create task.

Step 4: Test the replication

  1. In the N. Virginia region, login to the AD Management Server that you created in the “Administering AD” lab.

  2. On the AD Management Server, open a Windows explorer window.

  3. Enter \\ and paste the DNS name of the FSx file system in N. Virginia (e.g. \\amznfsxnxbgmemt.corp.example.com) Press Enter.

  4. There should be a share created called share.

  5. Create some files in this share.

  6. Open another Explorer window.

  7. Enter \\ and paste the DNS name of the FSx file system in Oregon (e.g. \\amznfsx7vpryyov.corp.example.com).

Now, you have two Explorer windows. One shows the files in the Amazon FSx file system in Virginia (source) and one window showing the files in the Amazon FSx file system in Oregon (destination).

Next, we are going to force DataSync to replicate the data. In the Oregon region, go to DataSync console.

  1. Press Start button and then Start again.

  2. This will start the replication task (or you can wait until the task runs hourly).

  3. Check the History tab to see a history of the replication task executions.

After a while, you should see your files appearing in the target Amazon FSx file system in Oregon.

Congratulations!

You have setup AWS DataSync to replicate the contents of the Amazon FSx file system in the source AWS region (N. Virginia) to the target region (Oregon) and have setup a Multi-Region Amazon FSx architecture. In the lab, we manually initiated DataSync to replicate the data. In a production environment, you would setup DataSync to replicate the data on a scheduled basis. During the replication, DataSync examines the source files and only copies the files that have changed.