AWSにおけるファイル共有について紹介します
はじめに
ファイルサーバとは、サーバ自身が保管しているファイルをネットワーク経由で複数のクライアントからアクセスできるようにする機能（ファイル共有機能）を有するサーバです。ファイル共有を実現する仕組み・プロトコルのうち、代表的なものは以下のようなものがあります。Network File System
Network File System (NFS) は、主にLinux/UNIXで利用されているファイル共有のプロトコルです。Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), CentOS, Ubuntuなど主要なLinuxディストリビューションに標準搭載されています。
Server Message Block
Server Message Block (SMB) は、主にWindowsで利用されているファイル共有のプロトコルです。歴史的経緯でCommon Internet File System (CIFS) と呼ばれることもあります。
クライアント用OSのWindows 8.1, 10、サーバ用OSのWindows Server 2016, 2016 R2, 2019に標準搭載されています。
オンプレミス時代のファイルサーバ
まず、オンプレミス時代のファイルサーバについて振り返ってみましょう。ファイル共有機能はOS標準機能に含まれており、PRIMERGYなど汎用的なIAサーバをファイルサーバとして気軽に利用することができます。
一方で利用者の増加や利用業務の拡大に伴い、ハード障害/業務アプリバグ/マルウェアから大切な業務データを守るバックアップ、利用者増加による性能キャパシティ管理、保管データ増加による容量キャパシティ管理などファイルサーバの運用業務や管理業務の重要度は高まっていきます。
これらの運用業務/管理業務をサポートする機能を有したETERNUS NR1000F seriesなどファイルサーバに特化した専用のアプライアンス製品が様々なベンダーから販売されています。専用アプライアンス製品はNFSとSMBの両方に対応している製品が多く、LinuxシステムとWindowsシステムで共通の業務データをファイル共有することが容易であるため、多数の業務システムを持つエンタープライズ企業のお客様では汎用IAサーバよりも専用アプライアンス製品を利用するプロジェクトが多く見られました。
クラウド時代のファイルサーバ
次に、Amazon Web Services (AWS)におけるファイルサーバについて考えてみましょう。オンプレミスの場合と同様、汎用的な仮想サーバであるEC2インスタンスをファイルサーバとして利用することができます。しかし、専用アプライアンス製品がサポートしていたバックアップ、性能/容量キャパシティ管理などの運用業務/管理業務の自動化や運用設計はシステム管理者が自身で作り込む必要があります。いわゆるIaaSではなく、ファイル共有のPaaSを利用する選択肢も挙げられます。
執筆(2020年3月)時点でAWSが提供するファイル共有PaaSは以下のようなものがあります。
Amazon Elastic File System
Amazon Elastic File System (EFS)は、NFS v4.0/v4.1でアクセス可能なファイル共有PaaSです。完全マネージド型のサービスであり、サーバやストレージの管理はAWS側で実施してくれます。
確保した容量ではなく、実際に使用した容量に応じた従量課金体系であり、ストレージ容量もペタバイトスケールまでAWS側が拡張してくれるため、容量キャパシティ管理の煩わしさから解放されます。
使用容量に比例したベースライン性能とバーストクレジットに応じたバースト性能を標準で備えており、必要に応じてプロビジョンドスループット(有償)を選択できるため、高い性能を求められるプロジェクトでも検討に値するPaaSです。
データは複数AZに跨がって複製して保管され、ハードウェア障害への対策が行われています。
他にAWS Backupと連携したスケジューリングバックアップ、AWS KMSと連携した保管データの暗号化、EFS マウントヘルパーを用いた伝送データの暗号化などエンタープライズ企業のお客様に求められる機能を有しています。
ただし、SMBでのアクセスはサポートされない（マニュアルに明記あり）ため、Windowsシステムからの利用には難があります。
Amazon FSx for Windows File Server
Amazon FSx for Windows File Server (FSx)は、SMB v2.0 - v3.1.1でアクセス可能なファイル共有PaaSです。EFSと同様に完全マネージド型のサービスであり、サーバやストレージの管理はAWS側で実施してくれます。
EFS同様、使用容量に応じた従量課金体系であり、単体のファイルシステムで64TByteまでAWS側が拡張してくれます。
（64TByte以上はWindows ServerのDFSと組み合わせた作り込みになります）
データは単一AZの複数ノードに跨がって複製して保管され、ハードウェア障害への対策が行われています。
他にスケジューリングバックアップ、AWS KMSと連携した保管データの暗号化、SMB Kerberosセッションキーを用いた伝送データの暗号化などの機能を有しています。
ただし、週次でメンテナンス（メンテナンスウィンドウは指定可能）が入るおそれがあるため、24時間365日稼働が前提のシステムでは利用に留意が必要です。
システム構築の例
AWSが提供するファイル共有PaaSには、NFSでアクセス可能なEFS と、SMBでアクセス可能なFSxの２つがあります。しかし、執筆(2020年3月)時点において、EFSとFSxはそれぞれ独立したPaaSであり、NFS/SMBの両方でアクセス可能なファイル共有PaaSはAWSではサービス提供されていません。
ファイルサーバ専用アプライアンス製品を介してLinuxサーバとWindowsサーバでファイル共有している業務システムをAWSへ移行する場合、NFS/SMBの両方に対応したファイルサーバをどのように作り込むか検討しなければなりません。
本稿では、2つの構成パターンを紹介します。
パターンA：Winows EC2+EBSのパターン
WindowsのEC2インスタンスおよびEBSボリュームをプロビジョニングし、NFS/SMBの両方でアクセス可能なファイルサーバとして構築するパターンです。Windows Serverの規定のファイル共有プロトコルはSMBですが、NFSサーバの役割を追加することができます。
パターンAの場合、クライアントからNFS/SMBのリクエスト/レスポンスへの対応（いわゆるNASヘッド）はEC2インスタンス、共有するファイルの格納先（共有ストレージ）は
EBSボリュームが担います。NASヘッドの冗長化はWindows Server Failover Clustering (WSFC)、共有ストレージの冗長化はCluster Shared Volume (CSV)で行います。
パターンAのシステム概念図は以下の通りです。
パターンB：Linux EC2+EFSのパターン
LinuxのEC2インスタンスとEFSファイルシステムをプロビジョニングし、NFS/SMBの両方でアクセス可能なファイルサーバとして構築するパターンです。
LinuxのEC2インスタンスとEFSファイルシステムをプロビジョニングします。EC2インスタンスからEFSファイルシステムをマウントし、さらにEC2インスタンスでSMB/NFSのデーモンを構築します。
パターンBの場合、NASヘッドパターンA同様にEC2インスタンスが担いますが、共有ストレージはEFSが担います。このため、NASヘッドの冗長化はクラスタリングソフトウェアが別途必要ですが、共有ストレージの冗長化はEFSに任せられます。
パターンBのシステム概念図は以下の通りです。
おわりに
AWSにおいてSMB/NFSの両方でアクセス可能なファイルサーバを構築する方法についてご紹介してきましたが、いかがでしたでしょうか。最後に、今回ご紹介した２つのパターンを比較します。
| パターンA | パターンB | |
| NFSでのアクセス | ○ アクセス可 | ○ アクセス可 |
| SMBでのアクセス | ○ アクセス可 | ○ アクセス可 |
| NASヘッドの冗長化 | △利用者の作り込み | △利用者の作り込み |
| 共有ストレージの冗長化 | △利用者の作り込み | ○EFSが担保 |
| 自動バックアップ | △利用者の作り込み | ○AWS Backupを利用可能 |
最後までお読みいただき、ありがとうございました。
