FSx for Windows File Serverのストレージタイプ (SSD/HDD) を変更する

FSx for Windows File Serverには「HDD」と「SSD」の2種類のストレージタイプがありますが、構築後にストレージタイプを変更したくなった場合の手順を解説します。

青柳英明

2021.03.02

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

みなさん、こんにちは！
AWS事業本部の青柳＠福岡オフィスです。

FSx for Windows File Server では、従来はストレージタイプとして「SSD」のみが利用可能でしたが、2020年3月のアップデートで「HDD」も利用できるようになりました。

コストとパフォーマンスを天秤にかけてSSDまたはHDDを選択できるようになった訳ですが、運用開始後にストレージタイプを「HDDからSSDへ」あるいは「SSDからHDDへ」変更したくなる場合もあるかと思います。

今回は、FSx for Windows File Serverのストレージタイプを変更する方法について解説したいと思います。

既存のファイルシステムの変更には未対応 (バックアップからの再作成が必要)

「ストレージ容量」や「スループット容量」の変更と同様に、ストレージタイプの変更もマネジメントコンソールから行えるのだろうと思ったのですが、

よくある質問 - Amazon FSx for Windows File Server | AWS

Q: ファイルシステムのストレージタイプ (SSD/HDD) を変更できますか?

A: 既存のファイルシステムのストレージタイプを変更することはできませんが、バックアップを作成して、そのバックアップを別のストレージタイプの新しいファイルシステムに復元できます。

既存のファイルシステムをそのまま利用しつつストレージタイプを変更することはできず、バックアップから新しいファイルシステムを再作成することで実現できるということです。

ということで、実際に試してみました。

「DNSエイリアス」機能を上手く使おう！

ストレージタイプの変更方法としては、前述の「よくある質問」に書かれている通り、以下の作業を行うだけです。

既存のファイルシステムのバックアップを取得する
バックアップから新しいファイルシステムを作成する (この時「ストレージタイプ」を元のタイプから変更する)

ただし、新しいファイルシステムを作成するということは「DNS名やIPアドレスが変わってしまう」ということであるため、クライアント側で参照先パスの変更などを行う必要があり、影響が大きくなってしまいます。

この問題は、FSx for Windows File Serverの「DNSエイリアス」機能を使うことで解決できます。

AWSドキュメントでの「DNSエイリアス」機能の説明や上記のブログ記事を読むと、DNSエイリアス機能は「オンプレミスからFSx for Windows File Serverへの移行」の際に使うものだというイメージを受けるかもしれません。

実は、FSx for Windows File Serverのファイルシステム間の移行の場合にも使うことができるのです。

この機能を上手く使うことで、クライアント側への影響を最低限に抑えつつ、ストレージタイプの変更を行うことが可能です。

※ もし、現在ファイルシステムでDNSエイリアス機能を使っていないという場合には、DNSエイリアス機能を使うように設定変更するタイミングでクライアント側の参照先パス変更が発生していまいます。
それでは意味が無い？ごもっともです・・・
ということで、FSx for Windows File Serverファイルシステムの導入時には、たとえオンプレミスからの移行ではなかったとしてもDNSエイリアスを設定しておくことをお勧めします。

ストレージタイプ変更の流れ

「DNSエイリアス」機能を使うことを前提にすると、ストレージタイプを変更するための作業は以下のような流れになります。

※ ファイルシステムには既に「DNSエイリアス」が設定されているものとします。設定手順については前述のブログ記事を参照してください。

(任意) 作業中のクライアントからのアクセスを抑止するために、セキュリティグループの設定を変更する。
既存のファイルシステムのバックアップを取得する。
バックアップから新しいファイルシステムを作成する。(この時「ストレージタイプ」を元のタイプから変更する)
(任意) 新しいファイルシステムが問題なく使用可能か、管理者の端末等からテストする。
既存ファイルシステムからDNSエイリアスに関わる設定を全て削除する。
新しいファイルシステムにDNSエイリアスを設定する。(既存ファイルシステムで使っていたものと同じ名前を設定する)
(任意) セキュリティグループの設定を元に戻し、クライアントからのアクセスを許可する。

順に手順を説明していきます。

1. (任意) 作業中のクライアントからのアクセスを抑止するために、セキュリティグループの設定を変更する

もし移行作業中にエンドユーザーがクライアントからアクセスしてファイルの作成/変更/削除などを行ってしまうと、移行元と移行先のファイルシステムの整合性が取れなくなってしまいます。

なお、FSx for Windows File Serverのマネジメントコンソール上では、ファイルシステムに設定されているセキュリティグループを別のセキュリティグループに変更することはできません。
もし変更したい場合は、ファイルシステムに紐づいている各ENIにアタッチされているセキュリティグループを変更することになります。

作業が煩雑になるため、ファイルシステムに設定されているセキュリティグループのインバウンドルールを編集した方がよいでしょう。

2. 既存のファイルシステムのバックアップを取得する

ファイルシステムのバックアップは、特別な手順はありません。
対象のファイルシステムを選択して、「アクション」プルダウンから「バックアップを作成」を選択して行ってください。

FSx for Windows File Serverのバックアップについては、下記ブログ記事で詳しく解説されていますので、参考にしてください。

3. バックアップから新しいファイルシステムを作成する

取得したバックアップを選択して「バックアップを復元」をクリックします。

ファイルシステムを新規作成する時と同じような画面になりますので、設定を入力していきます。

今回の作業の目的である「ストレージタイプ」を変更します。
この例では、元のファイルシステムのストレージタイプが「HDD」でしたので、「SSD」に変更しています。

その他の設定項目については、以下のようになります。

デプロイタイプ：リストア時には変更できません (元の設定を維持します)
ストレージ容量：リストア時には変更できません (変更したい場合は、リストア後に改めて変更します)
スループット容量：リストア時に任意に設定できます

また、ファイルシステム名 (Nameタグの値) は任意で設定できますが、識別のために一時的な名前を設定するとよいでしょう。(移行が完了した後に、元のファイルシステムと同じ名前に変更することもできます)

VPC、セキュリティグループ、サブネットの設定を行います。(特に理由が無ければ元のファイルシステムと同じ設定にします)

Active Directoryの設定は、「Managed Microsoft Active Directory」と「自己管理型Active Directory」の間で変更することはできません。
念のため、使用するディレクトリの選択などが元のファイルシステムと同じ設定になっていることを確認しましょう。

「アクセス - オプション」を展開して、DNSエイリアスの設定を確認します。
元のファイルシステムで設定したDNSエイリアスの設定が入力されていると思います。

現時点では、元のファイルシステムにDNSエイリアスが設定されているため、新しいファイルシステムに同じDNSエイリアスを設定すると、設定が競合してしまいます。

一旦、DNSエイリアスの設定をクリアしておきます。(ファイルシステム作成後にDNSエイリアスの移行を行います)

そのまま設定を進めて「ファイルシステムを作成」を実行し、作成が完了するのを待ちます。

4. (任意) 新しいファイルシステムが問題なく使用可能か、管理者の端末等からテストする

DNSエイリアスの切替を行う前に、バックアップから復元した新しいファイルシステムが問題なく使用可能か確認しておくとよいでしょう。

ファイルシステムに設定されているセキュリティグループで、検証に使う管理者の端末等からのアクセスを許可します。

また、DNSエイリアスの設定前ですので、デフォルトのDNS名 (amznfsx～) を使ってアクセスする必要があります。

5. 既存ファイルシステムからDNSエイリアスに関わる設定を全て削除する

ここからの作業は、ファイルシステムに統合されているActive Directoryドメインに対して、PowerShellのコマンドレットを実行することにより行います。

DNSサーバーからCNAMEレコードを削除する

DNSエイリアスにfileserver1.private.example.comというDNS名を登録した場合、以下のようにコマンドレットを実行します。

PS> $Alias = "fileserver1.private.example.com"
PS> $AliasHost=$Alias.Split('.')[0]
PS> $ZoneName=((Get-WmiObject Win32_ComputerSystem).Domain)
PS> $DnsServerComputerName = (Resolve-DnsName $ZoneName -Type NS | Where Type -eq 'A' | Select -ExpandProperty Name)[0]

CNAMEレコードを削除するコマンドレットを実行すると、確認を求められるので「Y」を入力して削除します。

PS> Remove-DnsServerResourceRecord -Name $AliasHost -ComputerName $DnsServerComputerName -RRType CNAME -ZoneName $ZoneName
確認
win-6ah76vol51b.private.example.com サーバー上のゾーン private.example.com から、タイプ CNAME の、fileserver1
という名前で設定されている DNS リソース レコードが削除されます。続行しますか?
[Y] はい(Y)  [N] いいえ(N)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): y

レコードが削除されたことを確認します。

DNSサーバーが複数ある場合は、DNSサーバー間でレプリケーションが行われるのに時間がかかるので、少し待ってから確認した方がよいでしょう。
また、DNSリゾルバキャッシュが残っている可能性があるため、キャッシュを削除します。

PS> ipconfig /flushdns
Windows IP 構成
DNS リゾルバー キャッシュは正常にフラッシュされました。

PS> nslookup fileserver1.private.example.com
サーバー:  private.example.com
Address:  172.16.64.50

*** private.example.com が fileserver1.private.example.com を見つけられません: Non-existent domain

サービスプリンシパル名(SPN)を削除する

例として、以下のように設定されているものとします。

DNSエイリアス： fileserver1.private.example.com
元のファイルシステムのDNS名： amznfsxzxinups6.private.example.com

PS> $Alias = "fileserver1.private.example.com"
PS> $OldFSxDnsName = "amznfsxzxinups6.private.example.com"
PS> $OldFileSystemHost = (Resolve-DnsName $OldFSxDnsName | Where Type -eq 'A')[0].Name.Split(".")[0]
PS> $OldFSxAdComputer = (Get-AdComputer -Identity $OldFileSystemHost)

まず、現在登録されているSPNを確認します。

PS> SetSpn /L $OldFSxAdComputer.Name
次の項目に登録されている CN=amznfsxzxinups6,OU=FSx,OU=AWS Reserved,DC=private,DC=example,DC=com:
        HOST/fileserver1.private.example.com
        HOST/fileserver1
        MSClusterVirtualServer/fileserver1
        MSClusterVirtualServer/fileserver1.private.example.com
        MSServerClusterMgmtAPI/fileserver1
        MSServerClusterMgmtAPI/fileserver1.private.example.com
        MSServerClusterMgmtAPI/amznfsxzxinups6.private.example.com
        MSServerClusterMgmtAPI/amznfsxzxinups6
        MSClusterVirtualServer/amznfsxzxinups6.private.example.com
        MSClusterVirtualServer/amznfsxzxinups6
        HOST/amznfsxzxinups6.private.example.com
        HOST/amznfsxzxinups6

SetSPN /Dコマンドを実行してSPNを削除します。

AWSドキュメントの手順では、HOST/で始まるSPNのエントリのみを削除していますが、MSServerClusterMgmtAPI/およびMSClusterVirtualServer/で始まるSPNも削除する必要があるようです。
(これらが残っていると、新しいファイルシステムの名前でSPNを登録する時にエラーとなりました)

PS> SetSPN /D ("HOST/" + ${Alias}) ${OldFSxAdComputer}.Name
PS> SetSPN /D ("HOST/" + ${Alias}.Split(".")[0]) ${OldFSxAdComputer}.Name
PS> SetSPN /D ("MSServerClusterMgmtAPI/" + ${Alias}) ${OldFSxAdComputer}.Name
PS> SetSPN /D ("MSServerClusterMgmtAPI/" + ${Alias}.Split(".")[0]) ${OldFSxAdComputer}.Name
PS> SetSPN /D ("MSClusterVirtualServer/" + ${Alias}) ${OldFSxAdComputer}.Name
PS> SetSPN /D ("MSClusterVirtualServer/" + ${Alias}.Split(".")[0]) ${OldFSxAdComputer}.Name

SPNが削除されたことを確認します。(DNSエイリアスに設定した「fileserver1」という名前のエントリが残っていないこと)

PS> SetSpn /L $OldFSxAdComputer.Name
次の項目に登録されている CN=amznfsxzxinups6,OU=FSx,OU=AWS Reserved,DC=private,DC=example,DC=com:
        MSServerClusterMgmtAPI/amznfsxzxinups6.private.example.com
        MSServerClusterMgmtAPI/amznfsxzxinups6
        MSClusterVirtualServer/amznfsxzxinups6.private.example.com
        MSClusterVirtualServer/amznfsxzxinups6
        HOST/amznfsxzxinups6.private.example.com
        HOST/amznfsxzxinups6

DNSエイリアスの設定を削除する

マネジメントコンソールから、DNSエイリアスの設定を削除します。

6. 新しいファイルシステムにDNSエイリアスを設定する

DNSエイリアスを設定する

マネジメントコンソールから、新しいファイルシステムにDNSエイリアスを設定します。

元のファイルシステムに設定されていたDNSエイリアスと同じエイリアスを指定して、「関連付け」をクリックします。

関連付けが完了したことを確認します。

サービスプリンシパル名(SPN)を設定する

例として、以下のように設定されているものとします。

DNSエイリアス： fileserver1.private.example.com
新しいファイルシステムのDNS名： amznfsxepquoiv6.private.example.com

$Alias = "fileserver1.private.example.com"
$NewFSxDnsName = "amznfsxepquoiv6.private.example.com"
$NewFileSystemHost = (Resolve-DnsName $NewFSxDnsName | Where Type -eq 'A')[0].Name.Split(".")[0]
$NewFSxAdComputer = (Get-AdComputer -Identity $NewFileSystemHost)

Set-AdComputerコマンドレットおよびSetSPN /Sコマンドを実行して、SPNを設定します。

Set-AdComputer -Identity $NewFSxAdComputer -Add @{"msDS-AdditionalDnsHostname"="$Alias"}
SetSpn /S ("HOST/" + $Alias.Split('.')[0]) $NewFSxAdComputer.Name
SetSpn /S ("HOST/" + $Alias) $NewFSxAdComputer.Name

SPNが設定されたことを確認します。

PS> SetSpn /L $NewFSxAdComputer.Name
次の項目に登録されている CN=amznfsxepquoiv6,OU=FSx,OU=AWS Reserved,DC=private,DC=example,DC=com:
        MSServerClusterMgmtAPI/fileserver1.private.example.com
        MSServerClusterMgmtAPI/FILESERVER1
        MSClusterVirtualServer/fileserver1.private.example.com
        MSClusterVirtualServer/FILESERVER1
        HOST/fileserver1.private.example.com
        HOST/FILESERVER1
        MSServerClusterMgmtAPI/amznfsxepquoiv6.private.example.com
        MSServerClusterMgmtAPI/amznfsxepquoiv6
        MSClusterVirtualServer/amznfsxepquoiv6.private.example.com
        MSClusterVirtualServer/amznfsxepquoiv6
        HOST/amznfsxepquoiv6.private.example.com
        HOST/amznfsxepquoiv6

DNSサーバーへCNAMEレコードを作成する

PS> $Alias = "fileserver1.private.example.com"
PS> $NewFSxDnsName = "amznfsxepquoiv6.private.example.com"
PS> $AliasHost=$Alias.Split('.')[0]
PS> $ZoneName=((Get-WmiObject Win32_ComputerSystem).Domain)
PS> $DnsServerComputerName = (Resolve-DnsName $ZoneName -Type NS | Where Type -eq 'A' | Select -ExpandProperty Name)[0]

PS> Add-DnsServerResourceRecordCName -Name $AliasHost -ComputerName $DnsServerComputerName -HostNameAlias $NewFSxDnsName -ZoneName $ZoneName

レコードが作成されたことを確認します。

DNSサーバーが複数ある場合は、DNSサーバー間でレプリケーションが行われるのに時間がかかるので、少し待ってから確認した方がよいでしょう。

PS> nslookup fileserver1.private.example.com
サーバー:  private.example.com
Address:  172.16.64.50

名前:    amznfsxepquoiv6.private.example.com
Address:  172.16.128.46
Aliases:  fileserver1.private.example.com

これで、DNSエイリアスに関わる全ての設定が、元のファイルシステムから新しいファイルシステムに切り替わりました。

7. (任意) セキュリティグループの設定を元に戻し、クライアントからのアクセスを許可する

作業前にセキュリティグループの設定を一時的に変更した場合、元に戻します。

以上で、ファイルシステムのバックアップとリストアを使用した「ストレージタイプ」の変更が行えました。

制約事項 (「SSD」から「HDD」への変更時)

ストレージタイプを「SSD」から「HDD」へ変更する場合は、以下の制約事項があります。

ストレージ容量が「2000 GiB」以上でなければならない
- HDDタイプの最低ストレージ容量が2000 GiBであるためです。2000 GiB未満のSSDは、事前にストレージ容量を2000 GiB以上に変更してから、ストレージタイプの変更を行いましょう。
デプロイタイプが「マルチAZ」または「シングルAZ 2」でなければならない
- 「シングルAZ 1」はHDDに対応していません。デプロイタイプを変更する手段も無いため、新規にファイルシステムを作成してデータ移行する等の手段を検討してください。

おわりに

バックアップとリストアを伴うために時間と手間が多少必要で、クライアントからの利用も一時できなくなりますが、ファイルシステムのストレージタイプを変更することができました。

FSx for Windows File Serverを利用開始した後に、

HDDで始めたが、より高いパフォーマンスが必要になった
SSDで始めたが、パフォーマンスを抑えてでもコストを下げたい

などの要望が生じた場合は、ストレージタイプの変更を検討してみてもよいのではないでしょうか。

FSx for Windows File Serverのストレージタイプ (SSD/HDD) を変更する

既存のファイルシステムの変更には未対応 (バックアップからの再作成が必要)

「DNSエイリアス」機能を上手く使おう！

ストレージタイプ変更の流れ

1. (任意) 作業中のクライアントからのアクセスを抑止するために、セキュリティグループの設定を変更する

2. 既存のファイルシステムのバックアップを取得する

3. バックアップから新しいファイルシステムを作成する

4. (任意) 新しいファイルシステムが問題なく使用可能か、管理者の端末等からテストする

5. 既存ファイルシステムからDNSエイリアスに関わる設定を全て削除する

DNSサーバーからCNAMEレコードを削除する

サービスプリンシパル名(SPN)を削除する

DNSエイリアスの設定を削除する

6. 新しいファイルシステムにDNSエイリアスを設定する

DNSエイリアスを設定する

サービスプリンシパル名(SPN)を設定する

DNSサーバーへCNAMEレコードを作成する

7. (任意) セキュリティグループの設定を元に戻し、クライアントからのアクセスを許可する

制約事項 (「SSD」から「HDD」への変更時)

おわりに

イベント

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

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

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

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

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

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

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

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

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

FSx for Windows File Serverのストレージタイプ (SSD/HDD) を変更する

既存のファイルシステムの変更には未対応 (バックアップからの再作成が必要)

「DNSエイリアス」機能を上手く使おう！

ストレージタイプ変更の流れ

1. (任意) 作業中のクライアントからのアクセスを抑止するために、セキュリティグループの設定を変更する

2. 既存のファイルシステムのバックアップを取得する

3. バックアップから新しいファイルシステムを作成する

4. (任意) 新しいファイルシステムが問題なく使用可能か、管理者の端末等からテストする

5. 既存ファイルシステムからDNSエイリアスに関わる設定を全て削除する

DNSサーバーからCNAMEレコードを削除する

サービスプリンシパル名(SPN)を削除する

DNSエイリアスの設定を削除する

6. 新しいファイルシステムにDNSエイリアスを設定する

DNSエイリアスを設定する

サービスプリンシパル名(SPN)を設定する

DNSサーバーへCNAMEレコードを作成する

7. (任意) セキュリティグループの設定を元に戻し、クライアントからのアクセスを許可する

制約事項 (「SSD」から「HDD」への変更時)

おわりに

イベント

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

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

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜フィンテック / リテール 業界案件特集〜 を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

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

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

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

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

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

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

関連記事

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

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

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

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

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

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