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

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

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

ネットワーク前提条件

Azure マネージド 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 クラウド サービスにアクセスできるように、ネットワーク セキュリティ グループを構成します。 次のプロパティを使用して送信セキュリティ規則を追加します。 - ポート: 任意 - プロトコル: 任意 - ソース: 仮想ネットワーク - Destination: "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) バインディング情報を維持する場合は、 ypbind がポート 988 を予約していないことを確認する必要があります。 ypbind予約するポートを手動で調整するか、システムスタートアップインフラストラクチャがypbindを開始する前に Lustre クライアントマウントを開始するようにすることができます。

Note

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

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 システムがデータを変更できるようにするロールの割り当て。 詳細については、「 必要なアクセス ロール」を参照してください。
• アクセス キー - ストレージ アカウントには、ストレージ アカウント キーのアクセス設定が Enabled に設定されている必要があります。

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

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 Account Contributor
• ストレージ BLOB データ共同作成者

重要

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

サービス プリンシパルのロールをHPC キャッシュ リソース プロバイダー 追加するには次の手順に従います。

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

   ヒント

   HPC キャッシュ リソース プロバイダーが見つからない場合は、代わりに 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 ゾーンと統合する: Yesに設定する必要があります。

次のステップ

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