Amazon FSx for NetApp ONTAP によるマルチプロトコルワークロードの実現

このブログは2021年11月23日に Henry Axelrod (Partner Solution Architect) と Eric Yuen (Senior Partner Solution Architect) によって執筆された内容を日本語化した物です。原文はこちらを参照して下さい。

エンタープライズ環境では、Linux と Windows の両方のワークロードが同じデータにアクセスする必要があることが一般的です。例えば、電子設計自動化（EDA）やメディアとエンターテインメントのワークロードでは、Windows ユーザーが Linux コンピュートインスタンスによって生成されたデータにアクセスすることがよくあります。このようなデータへの同時アクセスには、マルチプロトコルアクセスが必要です。Linux のワークロードには NFS、Windows のワークロードには SMB が必要です。マルチプロトコル共有ストレージは、Linux と Windows の両方で同じデータセットを表示し、各オペレーティングシステムがネイティブのファイルプロトコルでデータにアクセスできるようにします。

Amazon FSx for NetApp ONTAP の発表により、AWS は Linux、Windows、macOS のワークロードに、ONTAP の人気の高いデータ管理機能を備えたフルマネージド共有ストレージへのマルチプロトコルによる同時アクセスを提供することができます。FSx for ONTAP を使用すると、Linux と Windows のワークロードが同じデータを共有していなくても、単一のサービスまたはファイルシステムに統合することができます。これにより、環境のオーバーヘッドと複雑さを軽減し、データの複数コピーを回避してコストを削減し、既存のマルチプロトコルのワークロードを AWS に移行することが可能になります。

このブログでは、AWS マネジメントコンソールと NetApp ONTAP CLI の両方を使用して、同じ FSx for ONTAP ボリュームへのマルチプロトコルアクセスをセットアップする方法を紹介します。

ソリューション概要

• 認証と認可の概念
• 環境設定
• Active Directory（AD）のセットアップ
• FSx for ONTAP のセットアップ
• ONTAP CLI を使用したネームマッピングの設定
• Windows および Linux インスタンスからのデータアクセス

認証と認可の概念

マルチプロトコルのデータアクセスには、ユーザー・アイデンティティ・マッピングとセキュリティスタイルという重要なコンセプトがあります。

ユーザー・アイデンティティ・マッピング

ユーザー・アイデンティティ・マッピングとは、Linux ユーザーと Windows ユーザー、またはその逆をマッピングすることです。組織は通常、AD やその他の LDAP（Lightweight Directory Access Protocol）などの ID プロバイダーでユーザー ID を管理し、多くのシステムで共有される資格情報を管理します。Linux と Windows はどちらも、ユーザー名を基礎となる ID に変換します。Linux の場合、これはユーザー識別子（UID）であり、Windows の場合、これはセキュリティ識別子（SID）です。

各 FSx for ONTAP ファイルシステムは、1つまたは複数のストレージ仮想マシン（SVM）を持つことができます。SVM は、クライアントアクセス用のエンドポイントを持つ仮想ファイルサーバです。各 SVM は、個別の AD または他の認証構成を持つことができます。この構成は、SVM がどのようにユーザーを認証するかを決定し、Linux と Windows の識別子間のユニークなユーザーマッピングを含むことができます。この例については、このブログの後半で紹介する予定です。

セキュリティスタイル

セキュリティスタイルは、特定の ONTAP ボリュームのアクセス制御をどのように処理するかを決定します。FSx for ONTAP は、 NTFS、 UNIX、Mixed（デフォルトは UNIX）を含む、ONTAP がサポートするすべてのセキュリティスタイルをサポートします。特定の環境に最適なセキュリティスタイルは、パーミッションの管理方法によって異なりますが、 Windows と Linux の同時アクセスには、どのセキュリティスタイルも使用することもできます。Windows へのアクセスが必要な場合は、NTFS を推奨します。Mixed セキュリティスタイルは、一般に、同じボリューム上で複数のタイプのパーミッションを管理する必要がある高度なユースケースにのみ推奨されます。個々のファイルまたはディレクトリは、一度に1種類のセキュリティスタイルしか使用しないため、あるボリュームでは、ディレクトリ1が UNIX パーミッションを使用し、ディレクトリ2が NTFS パーミッションを使用している場合があります。

図1：セキュリティスタイル

注：セキュリティスタイルは、SVM とボリュームレベルの両方で設定することができます。SVM レベルの設定は、ルートボリュームに設定され、その SVM 下のボリュームは、独自の明示的な設定がない限り、その設定を引き継ぎます。

環境設定

本ブログの環境は、FSx for ONTAP ファイルシステム、AWS Managed Microsoft Active Directory（AD）、Windows 2019 Amazon EC2 インスタンス、Amazon Linux 2 EC2 インスタンスで構成されています（図1）。認証には Active Directory（AD）を使用し、AD に SVM が1台参加しています。すべてのリソースは、単一の Amazon Virtual Private Cloud（VPC）に存在します。

注：別の VPC、クラウド、またはオンプレミスにリソースがある場合、AWS Transit Gateway を使用してこれらのリソースを接続し、マルチプロトコルのリソースアクセスを可能にすることができます。

このブログでは、Amazon FSx コンソールと NetApp ONTAP CLI を使用しています。ONTAP CLI にアクセスするには、FSx for ONTAP ファイルシステム管理エンドポイント（後述）に SSH でアクセスする必要があります。

図2：Amazon FSx for NetApp ONTAP ファイルシステム (ハイレベルアーキテクチャ)

ファイルシステムのプロトコルやお好みのファイルパーミッション管理スタイルに合わせて、どのセキュリティスタイルを使用するかを決定する必要があります。次の表は、これらの入力に基づいてどのセキュリティスタイルを使用するか、また、Linux（UNIX）と Windows の間でどのようにユーザーをマッピングするかを示しています。

このブログでは、NTFS セキュリティスタイルを使用し、NTFS ACL を使用してファイル・パーミッションを管理し、Linux LDAPユーザー属性uid、uidNumber、およびgidNumberを AD の Windows ユーザーにマッピングしています。このブログの後半で、この設定方法を紹介します。

図3：ファイルシステムのネームマッピングの概要

Active Directory のセットアップ

このブログでは、ユーザー（ Windows と Linux の両方）の管理に AWS Managed Microsoft AD を使用していますが、独自の AD ソリューションも同様に動作します。AWS Managed Microsoft AD の設定について詳しくは、AWS ドキュメントを参照してください。

Active Directory で、ユーザー（名前 “Bob” ）を追加します。このユーザーは、Linux と Windows のクライアントからのアクセスをテストするためのものです。Active Directory Users and Computers の Attribute Editor を使用して、このユーザーに以下の属性を設定します。

uid: bob
uidNumber: 10001
gidNumber: 20001

注：uidNumberとgidNumberは、お使いの環境に依存します。これらの数値は、他のユーザーと衝突せず、お使いの環境のオペレーティングシステムのバージョンでサポートされる最大値以下であれば、どのような値でもかまいません。

図4：Active Directory ユーザ属性

また、アクセス制限をテストするために、2番目のユーザー “Mary” を作成します。

uid: mary
uidNumber: 10002
gidNumber: 20001

FSx for ONTAP のセットアップ

Amazon FSx コンソールで、Amazon FSx for NetApp ONTAP を選択します。

図5：Amazon FSx コンソール内の Amazon FSx ファイルシステムオプション 

SVM を Active Directory に参加させるオプションはスタンダード作成でしか利用できないため、スタンダード作成でファイルシステムを作成します。

図6：FSx for NetApp ONTAP ファイルシステム作成方法

セキュリティと暗号化 で、パスワードを指定します。このブログの後半で、FSx for ONTAPファイルシステムにログインするために使用します。

図7： セキュリティと暗号化

基本的なファイルシステムの詳細を指定した後、デフォルトのストレージ仮想マシン設定を設定します。名前をつけ、オプションでパスワードを指定します（このブログではSVMのパスワードは必要ありません）。次に、Active Directory への参加を選択します。これはこのセットアップで重要な点です。ここで、AD構成に関連するDNSアドレスを指定します。

Active Directoryの構成では、ファイルシステムに参加するドメインコントローラ（DC）とOUに対応する組織単位（OU）を指定します。これらの値の詳細については、AWSドキュメントを参照してください。

図 8： Active Directory SVM 設定

デフォルトのボリューム設定で、ボリューム名（ここでは “volmulti” を使用）、ジャンクションパス（/volmulti）、サイズ（10 GiB）を指定します。

図9： ボリューム設定

概要ページですべての設定を確認し、作成を選択します。

図10： Amazon FSx コンソールファイルシステム概要

ファイルシステムの作成には 30～40 分かかることがあります。作成が完了したら、ONTAP CLI を使用してネームマッピングの構成に進みます。

ONTAP CLI を使用したネームマッピングの設定

残りの設定作業は、ONTAP CLI を使用します。ONTAP CLI にアクセスするには、ユーザー名として “fsxadmin”、ファイルシステム作成時に定義したパスワードを使用して、FSx for ONTAP ファイルシステムの管理 IP に SSH でアクセスします。ファイルシステムの管理IPを取得するには、AWS ドキュメントを参照してください。

SSH fsxadmin@<management-IP-address>

Linux の UID を Active Directory の有効なユーザーにマッピングするために、まず LDAP の設定を追加します。

注：ONTAP 上の Linux UID を解決する方法は、LDAP、NIS、ローカルユーザーなど複数あります。ここでは AD のプロパティを使用しますが、環境に最適な方法を利用することができます。

vserver services name-service ldap client create コマンド（ここに記載）を実行し、LDAP クライアント設定を SVM と関連付けます。SVM は SVM 作成時に提供された AD クレデンシャルを使用して、LDAP ルックアップのために AD に接続します。使用する関連パラメータは以下の通りです。

vserver は、LDAP コンフィギュレーションを作成する SVM を指定します。
client-config は LDAP クライアント設定の名前で、ここでは “ad” と呼んでいます。
ad-domain は、AD サーバーのドメイン（ontapdemo.local）です。
base-dn はベースの識別名（DN）、SVM がユーザーを検索するポイントです。これは、作成時に SVM に設定した OU と DC の値から OU=Computers を除いたものです。
schema は SVM が LDAP の問い合わせを行う際に使用するスキーマテンプレートを指定します。ここでは AD-IDMU を使用しています。

これらのコマンドの詳細については、NetApp のドキュメントに記載されています。

FsxIdxxxxxxxxxxxxxxxxx::> vserver services name-service ldap client create -vserver mysvm -client-config ad -ad-domain ontapdemo.local -base-dn "OU=ontapdemo,DC=ontapdemo,DC=local" -schema AD-IDMU

次のコマンドでは、SVM との関連付けのために、前のステップで設定した client-config 名が必要です。

FsxIdxxxxxxxxxxxxx::> vserver services name-service ldap create -vserver mysvm -client-config ad

次に、ネームサービスとして LDAP を追加します。

FsxIdxxxxxxxxxxxxx::> vserver services name-service ns-switch modify -vserver mysvm -database passwd,group -sources files,ldap

次に、任意の Linux ユーザー名を、NetBIOS ドメイン名形式である domain\username と同じユーザー名に関連付けるネーム・マッピングを設定します。Linux と Windows のユーザー間の変換には、ここで必要な任意の正規表現を使用することができます。この場合、ドメイン名は ontapdemo なので、Linux のユーザー名を ontapdemo\username に変換しています。

FsxIdxxxxxxxxxxxxx::> vserver name-mapping create -vserver mysvm -direction UNIX-win -position 1 -pattern (.+) -replacement ontapdemo\\\1

最後に、作成した FSx for ONTAP ボリュームに Windows がアクセスできるように、CIFS（SMB）共有を設定します。NFS エクスポートは、Linux アクセス用にボリュームが作成されたときに、FSx for ONTAP によって自動的に構成されます。以下のコマンドでファイルシステムを作成する際に提供されたジャンクションパスを使用します。share-name には、好きな名前を使用することができます。

FsxIdxxxxxxxxxxxxx::> vserver cifs share create -share-name volmulti -path /volmulti -vserver mysvm

これで、ファイルシステムは Windows と Linux の両方からアクセスできるようになり、SVM には Active Directory のユーザーを Linux のユーザーにマッピングする方法が備わっています。

マルチプロトコルのデータアクセス

Windows と Linux の両方のユーザーに対して、データアクセスを許可（および制限）できることを確認したいと思います。Active Directory で作成したファイルアクセスを許可するユーザー（ontapdemo\bob）で Windows システムにログインし、ファイルエクスプローラで \\mysvm.ontapdemo.local\volmulti に移動します。

図11： SMB 共有

次に、test.txt というファイルを作成し、その中にいくつかのデータを保存します。

図12：データアクセステスト用テキストファイル

“bob” だけがこのファイルにアクセスできるようにしたいので、Windows の NTFS ACL を更新して “bob” だけにフルアクセス権限を与えます。

図13：ファイル NTFS ACL

Linux インスタンスでは、AWS ドキュメントを参照して AD ドメインに参加することができます。ただし、もう一歩踏み込んで、sssd.conf ファイルで ldap_id_mapping = False を設定する必要があります。これにより、System Security Services Daemon (SSSD) から生成される uidNumber ではなく、users プロパティに設定した uidNumber を使用できるようになります。ドメインに参加した後、以下のコマンドを実行してこの変更を行います。

[ec2-user]$ sudo sed -i 's/ldap_id_mapping = True/ldap_id_mapping = False/I' /etc/sssd/sssd.conf

[ec2-user]$ sudo sss_cache -E

[ec2-user]$ sudo systemctl restart sssd.service

次に、Linuxシステムに “bob” としてログインし、FSx for ONTAP ボリュームを /mnt/volmulti にマウントします。

[bob]$sudo mkdir /mnt/volmulti

[bob]$sudo mount -t nfs mysvm.ontapdemo.local:/volmulti /mnt/volmulti

bob が正しい UID を持っていることを確認します。

[bob]$ id

uid=10001(bob) gid=20001(FSXUser) groups=20001(FSXUser)

次に、作成されたファイルの内容を Windows システムから読み込むと、”bob” がファイルの所有者として表示されていることが確認できます。

[bob]$ cat /mnt/volmulti/test.txt

Here is my multiprotocol file

[bob]$ ls -o test.txt

-rwxrwxrwx 1 bob 27 Aug 18 21:34 test.txt

[bob]$ ls -on test.txt

-rwxrwxrwx 1 10001 27 Aug 18 21:34 test.txt

ユーザーのアクセスを制限できることを確認するため、次に Linux システムに “Mary” としてログインし、NTFS ACL に基づき Linux 上でファイルにアクセスできないことを確認します。

[mary]$ id

uid=10002(mary) gid=20002(Users) groups=20002(Users)

[mary]$ cat /mnt/volmulti/test.txt

cat: /mnt/volmulti/test.txt: Permission denied

root 権限を使用しても、ファイルにアクセスすることはできません。これは、root でさえ、デフォルトの ONTAP 設定に基づいて有効な Windows ユーザーにマップされ、ONTAP は追加のセキュリティのためにユーザーに基づいて NTFS 権限を評価するためです。

[mary]$ sudo cat /mnt/volmulti/test.txt

cat: /mnt/volmulti/test.txt: Permission denied

“bob” によるマルチプロトコルでのアクセスを確認し、”mary” も（”root” も）ファイルにアクセスできないことを確認しました。

クリーンアップ

このブログの手順に従ってテストを行い、その環境が不要になった場合は、デプロイされたリソースを必ずクリーンアップしてください。このブログの一部として、Amazon FSx for NetApp ONTAP ファイルシステム、AWS Managed Microsoft Active Directory ドメイン、および 2 つの Amazon EC2 インスタンスを作成した可能性があります。EC2 インスタンスを削除するには、EC2 コンソールを使用することができます。Amazon FSx for NetApp ONTAP ファイルシステムを削除するには、FSx コンソールを使用することができます。AWS Managed Microsoft Active Directory ドメインを削除するには、Directory Service コンソールを使用することができます。

まとめ

このブログでは、Amazon FSx for NetApp ONTAP を使用してネイティブマルチプロトコルのワークロードを有効にする方法を説明しました。AWS Managed AD サービスを使用して、Linux と Windows の両方の Amazon EC2 インスタンスが同じ FSx for ONTAP ボリュームとデータにアクセスできるようにする方法と、Active Directory を使用して Linux とWindows 間でパーミッションを伝搬させる方法を示しました。他にも多くのユースケースがあり、セルフマネジメントの Active Directory セットアップや他のディレクトリサービスを使用している場合でも、同じ基本的な手順が適用されます。また、正しいセキュリティスタイル（NTFS、UNIX、または Mixed）を選択できるように、アクセスをどのように管理したいかを考慮することも重要です。

この機能により、NFS と SMB 用に別々のストレージを維持する必要がなく、環境を簡素化することができます。ソリューション間でデータを複製する方法を考えたり、特定のデータを移動またはコピーするための複雑なワークフローロジックを構築したりする必要がなくなります。また、Amazon FSx for NetApp ONTAP に組み込まれたコスト最適化機能に加えて、データを2つの異なる場所にコピーすることを回避できるため、コスト削減にもつながります。

ネイティブマルチプロトコルワークロードの有効化に関するこのブログポストをお読みいただきありがとうございます。コメントや質問があれば、遠慮なくコメント欄に記入してください。