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 クラウド サービスへのアクセス | Azure Managed Lustre ファイル システムがファイル システム サブネット内から Azure クラウド サービスにアクセスできるように、ネットワーク セキュリティ グループを構成します。 次のプロパティを使用して送信セキュリティ規則を追加します。 - ポート: 任意 - プロトコル: 任意 - ソース: Virtual Network - 宛先: "AzureCloud" サービス タグ - アクション: 許可 注: Azure クラウド サービスを構成すると、Azure Queue サービスの必要な構成も有効になります。 詳細については、「仮想ネットワーク サービス タグ」を参照してください。 |
| Lustre ネットワーク ポート アクセス | ネットワーク セキュリティ グループは、ポート 988 とポート 1019 から 1023 で受信および送信アクセスを許可する必要があります。 既定の規則 65000 AllowVnetInBound であり、この要件を 65000 AllowVnetOutBound 満たしています。 |
既知の制限事項
Azure Managed Lustre ファイル システムの仮想ネットワーク サブネットには、次の制限が適用されます。
- Azure Managed Lustre と Azure NetApp Files リソースはサブネットを共有できません。 Azure NetApp Files サービスを使用する場合は、別のサブネットに Azure Managed Lustre ファイル システムを作成する必要があります。 リソースを現在含んでいるサブネットまたは以前に含まれていたサブネットに Azure Managed Lustre ファイル システムを作成しようとすると、デプロイは失敗 Azure NetApp Filesします。
注意
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 ファイル システムと統合するには、ファイル システムを作成する前に、次のリソースを作成または構成する必要があります。
ストレージ アカウント
ストレージ アカウントを作成するか、既存のストレージ アカウントを使用する必要があります。 ストレージ アカウントには、次の設定が必要です。
- アカウントの種類 - 互換性のあるストレージ アカウントの種類。 詳細については、「 サポートされているストレージ アカウントの種類」を参照してください。
- アクセス ロール - 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 ストレージへのアクセス権を付与します。
ストレージ アカウント所有者は、ファイル システムを作成する前に、次のロールを追加する必要があります。
重要
Azure Managed Lustre ファイル システムを作成する前に、これらのロールを追加する必要があります。 ファイル システムが BLOB コンテナーにアクセスできない場合、ファイル システムの作成は失敗します。 ファイル システムが作成される前に実行された検証では、コンテナー アクセス許可の問題を検出できません。 ロール設定が Azure 環境に反映されるまでに最大 5 分かかる場合があります。
リソース プロバイダー HPC Cacheサービス プリンシパルのロールを追加するには、次の手順に従います。
- ストレージ アカウントに移動し、左側のナビゲーション ウィンドウで [アクセス制御 (IAM)] を選択します。
- [追加][ロールの割り当ての追加] の順に選択して、[ロールの割り当ての追加] ページを開きます。
- ロールを割り当てます。
- リソース プロバイダー HPC Cacheそのロールに追加します。
ヒント
HPC Cache リソース プロバイダーが見つからない場合は、代わりに storagecache を検索してください。 storagecache リソース プロバイダー は、製品の一般提供前のサービス プリンシパル名でした。
- 手順 3 と 4 を繰り返して、各ロールを追加します。
詳細な手順については、「Azure portal を使用して Azure ロールを割り当てる」を参照してください。
BLOB コンテナー
同じストレージ アカウントには、次の目的で使用される 2 つの個別の BLOB コンテナーが必要です。
- データ コンテナー: Azure Managed Lustre ファイル システムで使用するファイルを含むストレージ アカウント内の BLOB コンテナー。
- ログ コンテナー: ストレージ アカウント内のインポート/エクスポート ログ用の 2 つ目のコンテナー。 ログは、データ コンテナーとは異なるコンテナーに格納する必要があります。
注意
後でクライアントからファイル システムにファイルを追加できます。 ただし、ファイル システムの作成後に元の BLOB コンテナーに追加されたファイルは、 インポート ジョブを作成しない限り、Azure Managed Lustre ファイル システムにインポートされません。
プライベート エンドポイント (省略可能)
BLOB のセットアップでプライベート エンドポイントを使用している場合、Azure Managed Lustre で SA 名を解決できるようにするには、新しいエンドポイントの作成時にプライベート エンドポイント設定 [ プライベート DNS ゾーンと統合 する] を有効にする必要があります。
- [プライベート DNS ゾーンと統合する]: [はい] に設定する必要があります。
![エンドポイントのセットアップ プロセスの [DNS] タブを示すスクリーンショット。](media/prerequisites/blob-endpoints-dns-settings.png)
次の手順
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示