マルチ AZ の FSx for Windows File Server で手動フェールオーバーを試してみた（が観測できなかった）

コンバンハ、千葉（幸）です。

FSx for Windows File Server （以下 FSx ）では以下のデプロイメントタイプがあります。

• シングル AZ 1（旧世代）
• シングル AZ 2
• マルチ AZ

マルチ AZ タイプでは、優先ファイルシステムが利用不可の状態になるとスタンバイファイルシステムに自動的にフェールオーバーされ、復旧時に自動的にフェールバックされます。

手動でのフェールオーバーテストを実施する手段として、「スループット容量」の変更が挙げられています。

You can test failover your Multi-AZ file system by modifying its throughput capacity. When you modify your file system's throughput capacity, Amazon FSx switches out the file system's file server.

• Availability and Durability: Single-AZ and Multi-AZ File Systems - Amazon FSx for Windows File Server

上記の操作を実行した時に、マネジメントコンソールや AWS CLI でどのように見えるかを確認したかったため、実際に試してみました。

先にまとめ

• マネジメントコンソールや AWS CLI で確認できる範囲で、以下の切り替わりは観測できなかった
  • 優先サブネット
  • 優先ファイルサーバー IP
• フェールオーバーテストを実施したい際はそれを踏まえよう

まずは FSx ファイルシステムを用意します

手動フェールオーバーを試す環境を用意します。今回は、以下ワークショップを利用しました。

以下を含む環境一式を構築できる CloudFormation テンプレートが提供されています。

• マルチ AZ FSx ファイルシステム
• AWS Managed Microsoft AD
• クライアント EC2

出来上がったのがこちらです

ファイルシステムの詳細画面では、優先ファイルサーバー IP アドレスや、優先サブネット / スタンバイサブネットが確認できます。

せっかくなので、ネットワークインターフェースの詳細を確認します。

一つのネットワークインターフェースにつき、二つの IP アドレスが払い出されています。

今回は以下の構成となっていました。

• 優先サブネット ENI
  • プライマリ：173.31.1.61
  • セカンダリ：173.31.1.16
• スタンバイサブネット ENI
  • プライマリ：173.31.2.216
  • セカンダリ：173.31.2.69

名前解決

テンプレートにより一緒に作成された EC2 インスタンスから FSX ファイルシステムの DNS 名を名前解決すると、各 ENI のセカンダリ IP アドレスが返却されます。

C:\Users\admin>nslookup amznfsxuboybgdv.example.com
Server:  example.com
Address:  173.31.0.10

Name:    amznfsxuboybgdv.example.com
Addresses:  173.31.1.16
          173.31.2.69

優先サブネットの IP が優先度高く返却される、というわけでなく、何度か打鍵するとラウンドロビンで返却されました。

C:\Users\admin>nslookup amznfsxuboybgdv.example.com
Server:  win-fqlodlpstdt.example.com
Address:  173.31.0.10

Name:    amznfsxuboybgdv.example.com
Addresses:  173.31.2.69
          173.31.1.16

手動でのスループット容量の変更

早速操作を試してみます。

今回は 32 MB/ 秒 → 8 MB/ 秒に変更を試みました。

更新処理に入ったことを確認できます。

ファイルシステムの詳細を AWS CLI で確認すると以下の結果が得られました。

• describe-file-systems — AWS CLI 2.1.31 Command Reference

コンソールと同じように、優先サブネットや優先ファイルサーバーの IP アドレスが確認できます。

% aws fsx describe-file-systems
{
    "FileSystems": [
        {
            "OwnerId": "012345678910",
            "CreationTime": "2021-02-17T18:28:40.061000+09:00",
            "FileSystemId": "fs-0c01a39c147d81660",
            "FileSystemType": "WINDOWS",
            "Lifecycle": "AVAILABLE",
            "StorageCapacity": 5120,
            "StorageType": "HDD",
            "VpcId": "vpc-0c4d76fed65c41477",
            "SubnetIds": [
                "subnet-0dceba9dc65a52fbd",
                "subnet-0e42142fe9238b4ab"
            ],
            "NetworkInterfaceIds": [
                "eni-0e337244bf47dc334",
                "eni-08afcdaeeb18ffa8e"
            ],
            "DNSName": "amznfsxuboybgdv.example.com",
            "KmsKeyId": "arn:aws:kms:ap-northeast-1:012345678910:key/bdc277a3-4568-43b8-9dde-fe3ab019b304",
            "ResourceARN": "arn:aws:fsx:ap-northeast-1:012345678910:file-system/fs-0c01a39c147d81660",
            "Tags": [
                {
                    "Key": "aws:cloudformation:stack-name",
                    "Value": "fsx-windows-workshop"
                },
                {
                    "Key": "aws:cloudformation:logical-id",
                    "Value": "WindowsFileSystem"
                },
                {
                    "Key": "aws:cloudformation:stack-id",
                    "Value": "arn:aws:cloudformation:ap-northeast-1:012345678910:stack/fsx-windows-workshop/8b82c470-70fa-11eb-a124-0607e8709c52"
                },
                {
                    "Key": "Name",
                    "Value": "MAZ"
                }
            ],
            "WindowsConfiguration": {
                "ActiveDirectoryId": "d-95671cd029",
                "DeploymentType": "MULTI_AZ_1",
                "RemoteAdministrationEndpoint": "amznfsxvynumjse.example.com",
                "PreferredSubnetId": "subnet-0dceba9dc65a52fbd",
                "PreferredFileServerIp": "173.31.1.16",
                "ThroughputCapacity": 32,
                "WeeklyMaintenanceStartTime": "4:19:30",
                "DailyAutomaticBackupStartTime": "17:00",
                "AutomaticBackupRetentionDays": 7,
                "CopyTagsToBackups": false
            },
            "AdministrativeActions": [
                {
                    "AdministrativeActionType": "FILE_SYSTEM_UPDATE",
                    "RequestTime": "2021-02-17T19:14:36.114000+09:00",
                    "Status": "IN_PROGRESS",
                    "TargetFileSystemValues": {
                        "WindowsConfiguration": {
                            "ThroughputCapacity": 8
                        }
                    }
                }
            ]
        }
    ]
}

25分程度で更新が完了しました。

優先サブネットや IP アドレスは変更前のものと変わっていません。

% aws fsx describe-file-systems | jq  '.FileSystems[] | .WindowsConfiguration,.AdministrativeActions[]'
{
  "ActiveDirectoryId": "d-95671cd029",
  "DeploymentType": "MULTI_AZ_1",
  "RemoteAdministrationEndpoint": "amznfsxvynumjse.example.com",
  "PreferredSubnetId": "subnet-0dceba9dc65a52fbd",
  "PreferredFileServerIp": "173.31.1.16",
  "ThroughputCapacity": 8,
  "WeeklyMaintenanceStartTime": "4:19:30",
  "DailyAutomaticBackupStartTime": "17:00",
  "AutomaticBackupRetentionDays": 7,
  "CopyTagsToBackups": false
}
{
  "AdministrativeActionType": "FILE_SYSTEM_UPDATE",
  "RequestTime": "2021-02-17T19:14:36.114000+09:00",
  "Status": "COMPLETED",
  "TargetFileSystemValues": {
    "WindowsConfiguration": {
      "ThroughputCapacity": 8
    }
  }
}

スクリーンショットを撮り忘れましたが、コンソール上でも変化は見受けられませんでした。

10 秒ごとに describe してみた

うっかり見逃してしまったのかな？と考え、以下のコマンドで 10 秒ごとに結果を出力してみました。

while true; do date; aws fsx describe-file-systems | jq  '.FileSystems[] | .WindowsConfiguration,.AdministrativeActions[0]' ; sleep 10s ; done

今回はスループット容量を 8 MB / 秒 → 16 MB / 秒に変更してみます。

以下のような結果が 10 秒ごとにターミナルに出力されていきます。

2021年 2月17日 水曜日 20時21分46秒 JST
{
  "ActiveDirectoryId": "d-95671cd029",
  "DeploymentType": "MULTI_AZ_1",
  "RemoteAdministrationEndpoint": "amznfsxvynumjse.example.com",
  "PreferredSubnetId": "subnet-0dceba9dc65a52fbd",
  "PreferredFileServerIp": "173.31.1.16",
  "ThroughputCapacity": 8,
  "WeeklyMaintenanceStartTime": "4:19:30",
  "DailyAutomaticBackupStartTime": "17:00",
  "AutomaticBackupRetentionDays": 7,
  "CopyTagsToBackups": false
}
{
  "AdministrativeActionType": "FILE_SYSTEM_UPDATE",
  "RequestTime": "2021-02-17T19:55:48.755000+09:00",
  "Status": "IN_PROGRESS",
  "TargetFileSystemValues": {
    "WindowsConfiguration": {
      "ThroughputCapacity": 16
    }
  }
}

25分程度で処理が完了しました。出力された結果を全て確認しましたが、優先サブネットと優先 IP アドレスは常に同じものが表示されていました。

2021年 2月17日 水曜日 20時21分57秒 JST
{
  "ActiveDirectoryId": "d-95671cd029",
  "DeploymentType": "MULTI_AZ_1",
  "RemoteAdministrationEndpoint": "amznfsxvynumjse.example.com",
  "PreferredSubnetId": "subnet-0dceba9dc65a52fbd",
  "PreferredFileServerIp": "173.31.1.16",
  "ThroughputCapacity": 16,
  "WeeklyMaintenanceStartTime": "4:19:30",
  "DailyAutomaticBackupStartTime": "17:00",
  "AutomaticBackupRetentionDays": 7,
  "CopyTagsToBackups": false
}
{
  "AdministrativeActionType": "FILE_SYSTEM_UPDATE",
  "RequestTime": "2021-02-17T19:55:48.755000+09:00",
  "Status": "COMPLETED",
  "TargetFileSystemValues": {
    "WindowsConfiguration": {
      "ThroughputCapacity": 16
    }
  }
}

てっきり上記のパラメータが変動するのかな？と考えていたのですが、そうではないようです。

具体的に何かしらのテストがしたかった訳でなく、単なる興味で試してみただけなので、ひとまずはこの辺りで切り上げることにしました。

終わりに

マルチ AZ の FSx のフェールオーバーを試してみました。

同じくマルチ AZ という考え方を持つ RDS では手動でフェールオーバーを発生させプライマリのサブネットを変更させることができます。 フェールオーバー時の挙動を試す、という観点でテスト項目に組み込んだことがありました。 FSx でも同じような考え方だろうと捉えていたのですが、異なるようです。

試行回数が2回なので、今回とは異なり 切り替わりが確認できるケースもあるかもしれません。ただ、少なくとも「当然起こるもの」として捉えてはいけないということを学びました。できないことがわかったので、一つ賢くなりました。

「挙動が見てみたいからテストしてみるか」と考えていた方の参考になれば幸いです。

以上、千葉（幸）がお送りしました。