Azure Managed Lustre ファイル システムの前提条件

この記事では、Azure Managed Lustre ファイル システムを作成する前に構成する必要がある前提条件について説明します。

• ネットワークの前提条件
• BLOB 統合の 前提条件 (省略可能)

ネットワーク前提条件

Azure Managed Lustre ファイル システムは、仮想ネットワーク サブネット内に存在します。 このサブネットは Lustre Management Service (MGS) を含んでおり、仮想 Lustre クラスターとのすべてのクライアント対話を処理します。

ファイル システムを作成した後で、あるネットワークまたはサブネットから別のネットワークまたはサブネットにファイル システムを移動することはできません。

Azure Managed Lustre は IPv4 アドレスのみを受け入れます。 IPv6 はサポートされていません。

ネットワーク サイズの要件

必要なサブネットのサイズは、作成するファイル システムのサイズによって異なります。 次の表に、さまざまなサイズの Azure Managed Lustre ファイル システムの最小サブネット サイズの大まかな見積もりを示します。

ストレージ容量	推奨される CIDR プレフィックス値
4 TiB から 16 TiB	/27 以上
20 TiB から 40 TiB	/26 以上
44 TiB から 92 TiB	/25 以上
96 TiB から 196 TiB	/24 以上
200 TiB から 400 TiB	/23 以上

その他のネットワーク サイズに関する考慮事項

仮想ネットワークとサブネットを計画するときは、Azure Managed Lustre サブネットまたは仮想ネットワーク内で検索する他のサービスの要件を考慮してください。

Azure Managed Lustre ファイル システムで Azure Kubernetes Service (AKS) クラスターを使用している場合は、ファイル システムと同じサブネット内に AKS クラスターを見つけることができます。 この場合、Lustre ファイル システムのアドレス空間に加えて、AKS のノードとポッド用に十分な IP アドレスを用意する必要があります。 仮想ネットワーク内で複数の AKS クラスターを使用する場合は、すべてのクラスター内のすべてのリソースに対して、仮想ネットワークに十分な容量があることを確認してください。 Azure Managed Lustre と AKS のネットワーク戦略の詳細については、AKS サブネット アクセスに関するページを参照してください。

別のリソースを使用してコンピューティング VM を同じ仮想ネットワークでホストする場合は、Azure Managed Lustre システムの仮想ネットワークとサブネットを作成する前に、そのプロセスの要件を確認してください。 同じサブネット内で複数のクラスターを計画する場合は、すべてのクラスターの合計要件に対応できる十分な大きさのアドレス空間を使用する必要があります。

サブネットのアクセスとアクセス許可

既定では、Azure Managed Lustre を有効にするために特に変更を行う必要はありません。 お使いの環境に制限付きネットワークやセキュリティ ポリシーが含まれている場合は、次のガイダンスを考慮する必要があります。

アクセスの種類	必要なネットワーク設定
DNS アクセス	既定の Azure ベースの DNS サーバーを使用します。
ホスト間のアクセス	Azure Managed Lustre サブネット内でホスト間の受信と送信のアクセスを許可します。 たとえば、クラスターの展開には TCP ポート 22 (SSH) へのアクセスが必要です。
Azure クラウド サービスへのアクセス	Azure Managed Lustre ファイル システムがファイル システム サブネット内から Azure クラウド サービスにアクセスすることを許可するように、ネットワーク セキュリティ グループを構成します。 次のプロパティを持つ送信セキュリティ規則を追加します。 - ポート:任意 - プロトコル:任意 - ソース:仮想ネットワーク - 送信先:"AzureCloud" サービス タグ - アクション: 許可 注: Azure クラウド サービスを構成すると、Azure Queue サービスの必要な構成も有効になります。 詳細については、「仮想ネットワーク サービス タグ」を参照してください。
Lustre ネットワーク ポート アクセス	ネットワーク セキュリティ グループは、ポート 988 と、ポート 1019 から 1023 で受信および送信アクセスを許可する必要があります。 他のサービスは、Lustre クライアントでこれらのポートを予約したり使用したりすることはできません。 既定の規則の 65000 AllowVnetInBound と 65000 AllowVnetOutBound は、この要件を満たしています。

Azure Managed Lustre ファイル システムのネットワーク セキュリティ グループの構成に関する詳細なガイダンスについては、「ネットワーク セキュリティ グループを作成して構成する」を参照してください。

既知の制限事項

Azure Managed Lustre ファイル システムの仮想ネットワーク設定には、次の既知の制限事項が適用されます。

• Azure Managed Lustre リソースと Azure NetApp Files リソースは、サブネットを共有できません。 Azure NetApp Files サービスを使用する場合は、Azure Managed Lustre ファイル システムを別のサブネットに作成する必要があります。 現在、または以前に Azure NetApp Files リソースが含まれているサブネットに Azure Managed Lustre ファイル システムを作成しようとすると、デプロイは失敗します。
• クライアントでデーモンを ypbind 使用してネットワーク インフォメーション サービス (NIS) バインディング情報を維持する場合は、ポート 988 が ypbind 予約されていないことを確認する必要があります。 ypbind が予約するポートを手動で調整するか、システムのスタートアップ インフラストラクチャが ypbind を開始する前に Lustre クライアントのマウントを開始するようにします。

Note

Azure Managed Lustre ファイル システムを作成すると、いくつかの新しいネットワーク インターフェイスがファイル システムのリソース グループに表示されます。 それらの名前は amlfs- で始まり、-snic で終わります。 これらのインターフェイスの設定は変更しないでください。 具体的には、[高速ネットワーク] 設定では既定値の [有効] のままにしておきます。 これらのネットワーク インターフェイスで高速ネットワークを無効にすると、ファイル システムのパフォーマンスが低下します。

BLOB 統合の前提条件 (省略可能)

Azure Managed Lustre ファイル システムを Azure Blob Storage と統合する予定の場合は、ファイル システムを作成する前に、次の前提条件を満たしてください。

BLOB 統合の詳細については、「Azure Managed Lustre ファイル システムで Azure Blob Storage を使用する」を参照してください。

Azure Managed Lustre は、階層型名前空間が有効になっているストレージ アカウントと、非階層型またはフラットな名前空間を持つストレージ アカウントと連携します。 次の小さな違いが適用されます。

• 階層型名前空間が有効になっているストレージ アカウントの場合、Azure Managed Lustre は BLOB ヘッダーから POSIX 属性を読み取ります。
• 階層型名前空間が 有効になっていない ストレージ アカウントの場合、Azure Managed Lustre は BLOB メタデータから POSIX 属性を読み取ります。 メタデータを保持するために、BLOB コンテナーの内容と同じ名前の別の空のファイルが作成されます。 このファイルは、Azure Managed Lustre ファイル システム内の実際のデータ ディレクトリの兄弟です。

Azure Blob Storage を Azure Managed Lustre ファイル システムと統合するには、ファイル システムを作成する前に、次のリソースを作成または構成する必要があります。

• ストレージ アカウント
• BLOB コンテナー

ストレージ アカウント

ストレージ アカウントを作成するか、既存のストレージ アカウントを使用する必要があります。 ストレージ アカウントには次の設定が必要です。

• アカウントの種類 - 互換性のあるストレージ アカウントの種類。 詳細については、「サポートされているストレージ アカウントの種類」を参照してください。
• アクセス ロール - Azure Managed Lustre システムがデータを変更することを許可するロールの割り当て。 詳細については、「必要なアクセス ロール」を参照してください。
• アクセス キー - ストレージ アカウントでは、ストレージ アカウント キーのアクセス設定が [有効] に設定されている必要があります。

サポートされるストレージ アカウントの種類

Azure Managed Lustre ファイル システムでは、次のストレージ アカウントの種類を使用できます。

ストレージ アカウントの種類	冗長性
Standard	ローカル冗長ストレージ (LRS)、geo 冗長ストレージ (GRS) ゾーン冗長ストレージ (ZRS)、読み取りアクセス geo 冗長ストレージ (RAGRS)、geo ゾーン冗長ストレージ (GZRS)、読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS)
Premium - ブロック BLOB	LRS、ZRS

ストレージ アカウントの種類の詳細については、「ストレージ アカウントの種類」を参照してください。

BLOB 統合のアクセス ロール

Azure Managed Lustre では、ストレージ アカウントにアクセスするための認可が必要です。 Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、ファイル システムに Blob Storage へのアクセス権を付与します。

ストレージ アカウントの所有者は、ファイル システムを作成する前に、以下のロールを追加する必要があります。

• Storage Account Contributor
• ストレージ BLOB データ共同作成者

重要

Azure Managed Lustre ファイル システムを作成する前に、これらのロールを追加する必要があります。 ファイル システムが BLOB コンテナーにアクセスできない場合、ファイル システムの作成は失敗します。 ファイル システムが作成される前に実行された検証では、コンテナー アクセス許可の問題を検出できません。 ロール設定が Azure 環境に反映されるまでに最大 5 分かかることがあります。

サービス プリンシパル HPC Cache リソース プロバイダーのロールを追加するには、以下の手順に従います。

1. ストレージ アカウントに移動し、左側のナビゲーション ウィンドウで [アクセス制御 (IAM)] を選択します。
2. [追加]>[ロールの割り当ての追加] を選択して、[ロールの割り当ての追加] ページを開きます。
3. ロールを割り当てます。
4. HPC Cache リソースプロバイダー をそのロールに追加します。

   ヒント

   HPC Cache リソース プロバイダーが見つからない場合は、代わりに storagecache を検索してください。 storagecache リソース プロバイダー は、製品が一般提供される前のサービス プリンシパル名です。

5. 手順 3 と 4 を繰り返して、各ロールを追加します。

詳細な手順については、「Azure portal を使用して Azure ロールを割り当てる」を参照してください。

BLOB コンテナー

同じストレージ アカウント内に、次の目的で使用される 2 つの個別の BLOB コンテナーが必要です。

• データ コンテナー:Azure Managed Lustre ファイル システムで使用するファイルを格納するストレージ アカウント内の BLOB コンテナー。
• ログ コンテナー:ストレージ アカウント内のインポート/エクスポート ログ用の 2 番目のコンテナー。 ログは、データ コンテナーとは別のコンテナーに格納する必要があります。

Note

後でクライアントからファイル システムにファイルを追加できます。 ただし、ファイル システムの作成後に元の BLOB コンテナーに追加されたファイルは、インポート ジョブを作成する場合を除き、Azure Managed Lustre ファイル システムにインポートされません。

プライベート エンドポイント (オプション)

BLOB のセットアップでプライベート エンドポイントを使用している場合、Azure Managed Lustre が SA 名を解決できるようにするには、新しいエンドポイントの作成時にプライベート エンドポイント設定 の [プライベート DNS ゾーン との統合] を有効にする必要があります。

• プライベート DNS ゾーンと統合する: [はい] に設定する必要があります。

次のステップ

• Azure portal で Azure Managed Lustre ファイル システムを作成する