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

マルチ AZ の FSx のフェールオーバーテストを考えていた方達へ。

千葉幸宏（チバユキ）

2021.03.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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

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 アドレスや、優先サブネット / スタンバイサブネットが確認できます。

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

Amazon_FSx

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

FSxENI

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

優先サブネット 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/ 秒に変更を試みました。

Amazon_FSx-3556872

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

Amazon_FSx-3557464

ファイルシステムの詳細を 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回なので、今回とは異なり切り替わりが確認できるケースもあるかもしれません。ただ、少なくとも「当然起こるもの」として捉えてはいけないということを学びました。できないことがわかったので、一つ賢くなりました。

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

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

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

先にまとめ

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

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

名前解決

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

10 秒ごとに describe してみた

終わりに

イベント

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【4/18リモート】クラスメソッドのフリーランスエンジニア会社説明会〜AWS/システムアーキテクト/Android案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/19（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

EVENT【4/30（火）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/9（木）】組織的なクラウド統制はじめの一歩

EVENT【4/24（水）リモート】会社員からフリーランスエンジニアへ、変化の時の体験談 [パネルトーク] フリーランストーク#10

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

先にまとめ

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

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

名前解決

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

10 秒ごとに describe してみた

終わりに

イベント

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【4/18リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜AWS/システムアーキテクト/Android案件特集〜 を開催します

EVENT【5/10（金） 名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/19（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

EVENT【4/30（火）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/9（木）】組織的なクラウド統制 はじめの一歩

EVENT【4/24（水）リモート】会社員からフリーランスエンジニアへ、変化の時の体験談 [パネルトーク] フリーランストーク#10

関連記事

Amazon FSx for NetApp ONTAPをTerraformで構築してみた

[アップデート] Amazon FSx for Windows File ServerのIOPSが最大400,000まで引き上げられました

[レポート] クラウドの効率性、俊敏性、イノベーションをAWSで構築する #STG103 #AWSreInvent

[アップデート] #VMwareExplore2023 VMware Cloud on AWSに関する発表まとめ

EVENT【4/18リモート】クラスメソッドのフリーランスエンジニア会社説明会〜AWS/システムアーキテクト/Android案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【5/9（木）】組織的なクラウド統制はじめの一歩