Azure Managed Lustre で Azure Blob Storage を使用する
Azure Managed Lustre は Azure Blob Storage と統合され、BLOB コンテナーからファイル システムにデータをインポートするプロセスを簡略化します。 ファイル システムから長期ストレージ用の BLOB コンテナーにデータをエクスポートすることもできます。 この記事では、Azure Managed Lustre ファイル システムと BLOB 統合を使用するための概念について説明します。
互換性のある BLOB コンテナーに必要な要件と構成については、BLOB 統合の前提条件に関するセクションを参照してください。
BLOB 統合の概要
クラスターの作成時に BLOB 統合を構成できます。また、クラスターの作成後はいつでもインポート ジョブを作成できます。 データがインポートされたら、他のファイル システム データと同様にデータを操作できます。 新しいファイルが作成されるか、ファイル システムで既存のファイルが変更されると、クライアントで Lustre CLI コマンドを実行するか、エクスポート ジョブを使用してデータをエクスポートすることで、これらのファイルをストレージ アカウントにエクスポートし直すことができます。
BLOB コンテナーから Azure Managed Lustre ファイル システムにデータをインポートすると、ファイル名 (名前空間) とメタデータのみが Lustre 名前空間にインポートされます。 BLOB の実際の内容は、クライアントが最初にアクセスしたときにインポートされます。 Lustre 階層ストレージ管理 (HSM) 機能が BLOB の内容をファイル システム内の対応するファイルに取り込む間に、データに最初にアクセスする際に若干の遅延が発生します。
sudo 機能を備えたマウントされたクライアントから Lustre の lfs hsm_restore コマンドを使用して、BLOB の内容をプリフェッチできます。 詳細については、「Blob Storage からデータを復元する」を参照してください。
Azure Managed Lustre は、階層型名前空間が有効になっているストレージ アカウントと、非階層型またはフラットな名前空間を持つストレージ アカウントと連携します。 次の小さな違いが適用されます。
- 階層型名前空間が有効になっているストレージ アカウントの場合、Azure Managed Lustre は BLOB ヘッダーから POSIX 属性を読み取ります。
- 階層型名前空間が 有効になっていない ストレージ アカウントの場合、Azure Managed Lustre は BLOB メタデータから POSIX 属性を読み取ります。 メタデータを保持するために、BLOB コンテナーの内容と同じ名前の別の空のファイルが作成されます。 このファイルは、Azure Managed Lustre ファイル システム内の実際のデータ ディレクトリの兄弟です。
Blob Storage からのインポート
クラスターの作成時に Blob Storage との統合を構成できます。また、クラスターの作成後にいつでもインポート ジョブを作成できます。
BLOB コンテナーの要件
クラスターの作成時に BLOB 統合を構成する場合は、インポートするコンテナーとログ コンテナーという 2 つの個別の BLOB コンテナーを識別する必要があります。 インポートするコンテナーには、Azure Managed Lustre ファイル システムにインポートするデータが含まれています。 ログ コンテナーは、インポート ジョブのログを格納するために使用されます。 これら 2 つのコンテナーは、同じストレージ アカウントに存在する必要があります。 BLOB コンテナーの要件の詳細については、BLOB 統合の前提条件に関するページを参照してください。
プレフィックスのインポート
BLOB コンテナーからデータをインポートする場合は、必要に応じて 1 つ以上のプレフィックスを指定して、Azure Managed Lustre ファイル システムにインポートされたデータをフィルター処理できます。 プレフィックスの 1 つに一致する BLOB コンテナー内のファイル名は、ファイル システムのメタデータ レコードに追加されます。 クライアントが最初にファイルにアクセスすると、その内容が BLOB コンテナーから取得され、ファイル システムに格納されます。
Azure portal で、クラスターの作成時に [詳細設定] タブの [プレフィックスのインポート] フィールドを使用して、BLOB コンテナーからインポートするデータを指定します。 これらのフィールドは、初期インポート ジョブにのみ適用されます。 クラスターの作成後にインポート プレフィックスを変更することはできません。
インポート ジョブの場合は、ジョブの作成時にインポート プレフィックスを指定できます。 Azure portal から、[プレフィックスのインポート] フィールドにインポート プレフィックスを指定できます。 REST API を使用してインポート ジョブを作成するときに、インポート プレフィックスを指定することもできます。
インポート プレフィックスを指定する場合は、次の点に注意してください。
- 既定のインポート プレフィックスは .
/この既定の動作では、BLOB コンテナー全体の内容がインポートされます。 - 複数のプレフィックスを指定する場合、プレフィックスは重複しない必要があります。 たとえば、指定
/dataした場合、/data2プレフィックスが重複しているため、インポート ジョブは失敗します。 - BLOB コンテナーが階層型名前空間が有効になっているストレージ アカウント内にある場合は、プレフィックスをファイル パスと考えることができます。 パスの下の項目は、Azure Managed Lustre ファイル システムに含まれています。
- BLOB コンテナーが非階層 (またはフラット) 名前空間を持つストレージ アカウント内にある場合、インポート プレフィックスは、BLOB 名の先頭と比較される検索文字列と考えることができます。 コンテナー内の BLOB の名前がインポート プレフィックスとして指定した文字列で始まる場合、そのファイルはファイル システムでアクセス可能になります。 Lustre は階層ファイル システムであり
/、Blob 名の文字は Lustre に格納されるとディレクトリ区切り記号になります。
競合解決モード
BLOB コンテナーからデータをインポートする場合は、BLOB コンテナーとファイル システムの間の競合を処理する方法を指定できます。 このオプションは、既存のクラスターに対して実行されるインポート ジョブにのみ適用されます。 次の表に、使用可能な競合解決モードとその説明を示します。
| モード | 説明 |
|---|---|
fail |
競合が検出された場合、インポート ジョブはすぐに失敗し、エラーが発生します。 |
skip |
競合が検出された場合、インポート ジョブはファイルをスキップします。 |
overwrite-dirty |
インポート ジョブは、競合するパスを評価して、削除して再インポートする必要があるかどうかを確認します。 詳細については、「上書きダーティ モード」を参照してください。 |
overwrite-always |
インポート ジョブは競合するパスを評価し、ダーティな場合は常に削除/再インポートし、クリーンな場合はリリースします。 詳細については、上書き常モードに関するページを参照してください。 |
上書きダーティ モード
このモードでは overwrite-dirty 、競合するパスを評価して、削除して再インポートする必要があるかどうかを確認します。 大まかに言うと、 overwrite-dirty モードは HSM の状態をチェックします。 HSM の状態が Clean および Archived の場合、Lustre が認識できる限りデータが BLOB コンテナーと同期している場合は、必要に応じて属性のみが更新されます。 それ以外の場合、ファイルは削除され、BLOB コンテナーから再インポートされます。
HSM の状態を確認しても、Lustre 内のファイルが BLOB コンテナー内のファイルと一致することは保証されません。 Lustre 内のファイルが可能な限り BLOB コンテナー内のファイルと一致することを確認する必要がある場合は、モードを使用します overwrite-always 。
常に上書きモード
モードは overwrite-always 競合するパスを評価し、ダーティな場合は常に削除/再インポートし、クリーンな場合はリリースします。 このモードは、ファイル システムが常に BLOB コンテナーと同期していることを確認する場合に便利です。 また、以前に復元されたすべてのファイルは最初のアクセス時に解放または削除/再インポートされるため、最もコストの高いオプションでもあります。
エラー許容度
BLOB コンテナーからデータをインポートする場合は、エラー許容度を指定できます。 エラー許容レベルは、インポート プロセス中に発生した一時的なエラー (オペレーティング システム エラーやネットワークの中断など) をインポート ジョブが処理する方法を決定します。 このコンテキストのエラーは、競合解決モードによって処理されるファイルの競合を指さないことに注意してください。
インポート ジョブでは、次のエラー許容オプションを使用できます。
- エラー を許可しない (既定): インポート中にエラーが発生した場合、インポート ジョブはすぐに失敗します。 これが既定の動作です。
- エラーを許可する: エラーが発生し、エラーがログに記録された場合、インポート ジョブは続行されます。 インポート ジョブが完了したら、ログ コンテナーでエラーを表示できます。
BLOB インポート ジョブに関する考慮事項
次の項目は、BLOB コンテナーからデータをインポートするときに考慮する必要があります。
- 一度に実行できるインポートまたはエクスポート アクションは 1 つだけです。 たとえば、インポート ジョブが進行中の場合、別のインポート ジョブを開始しようとするとエラーが返されます。
- インポート ジョブは取り消すことができます。 既存のクラスターで開始されたインポート ジョブ、またはクラスターの作成時に開始されたインポート ジョブを取り消すことができます。
- クラスターのデプロイは、対応するインポート ジョブが完了する前に正常に返される可能性があります。 インポート ジョブはバックグラウンドで引き続き実行されます。 インポート ジョブの進行状況は、次の方法で監視できます。
- Azure portal: Azure portal にインポート ジョブの状態が表示されます。 ファイル システムに移動し、[BLOB 統合] を選択してインポート ジョブの状態を表示します。
- ルート ディレクトリ内の Lustre ファイル: インポート時に
/lustre/IMPORT_<state>.<timestamp_start>Lustre ルート ディレクトリに類似した名前のファイルが作成されます。 プレースホルダーは<state>、インポートの進行に合って変更されます。 インポート ジョブが正常に完了すると、ファイルが削除されます。
- 完了したインポート ジョブの詳細を表示するには、ログ コンテナーを確認します。 ログ コンテナーには、インポート 中に発生したエラーや競合など、インポート ジョブのログが含まれます。
- 何らかの理由でインポート ジョブが失敗した場合、インポートされたファイルの数や競合の数など、インポート ジョブに関する完全な統計情報がない可能性があります。
Blob Storage からデータを復元する
既定では、対応するファイルがクライアントから初めてアクセスされるときに、BLOB の内容がファイル システムにインポートされます。 特定のワークロードやシナリオでは、最初にアクセスする前に BLOB コンテナーからデータを復元することをお勧めします。 BLOB の内容をプリフェッチして、インポート後に BLOB に初めてアクセスするときの初期遅延を回避できます。 BLOB の内容をプリフェッチするには、sudo 機能を備えたマウントされたクライアントから Lustre の lfs hsm_restore コマンドを使用できます。 次のコマンドは、BLOB の内容をファイル システムにプリフェッチします。
nohup find local/directory -type f -print0 | xargs -0 -n 1 sudo lfs hsm_restore &
このコマンドは、復元要求を非同期的に処理するようにメタデータ サーバーに指示します。 コマンド ラインは復元の完了を待ちません。つまり、コマンド ラインはメタデータ サーバーで復元のために多数のエントリをキューに入れる可能性があります。 この方法では、メタデータ サーバーが過剰になり、復元のパフォーマンスが低下する可能性があります。
この潜在的なパフォーマンスの問題を回避するには、パスを確認し、指定したサイズのバッチで復元要求を発行する基本的なスクリプトを作成します。 適切なパフォーマンスを実現し、メタデータ サーバーの負荷を抑えるために、1,000 ~ 5,000 の要求の任意の場所でバッチ サイズを使用することをお勧めします。
例: バッチ復元スクリプトを作成する
次の例は、BLOB コンテナーからデータをバッチで復元するスクリプトを作成する方法を示しています。 次の内容を含む file_restorer.bash という名前のファイルを作成します。
#!/bin/bash
set -feu
set -o pipefail
main()
{
if [ $# -lt 2 ]; then
echo "$0 <path_to_fully_restore> <max_restores_at_a_time>"
echo "Missing parameters"
exit 1
fi
local RESTORE_PATH=$1
local MAX_RESTORES=$2
local FILES_LIST="/tmp/files_to_restore"
find "$RESTORE_PATH" -type f > "$FILES_LIST"
local TOTAL_FILES
TOTAL_FILES=$(wc -l "$FILES_LIST")
local RESTORE_TOTAL=0
local RESTORE_COUNT=0
while IFS="" read -r p || [ -n "$p" ]; do
printf '%s\n' "$p"
lfs hsm_restore "$p"
((RESTORE_COUNT++)) || true
((RESTORE_TOTAL++)) || true
if (( RESTORE_COUNT >= MAX_RESTORES )); then
while true; do
local STATE
STATE=$(lfs hsm_state "$p")
RELEASED=') released exists archived'
if ! [[ $STATE =~ $RELEASED ]]; then
echo "Restored $RESTORE_TOTAL / $TOTAL_FILES"
break
fi
sleep 0.2
done
RESTORE_COUNT=0
fi
done < "$FILES_LIST"
}
main "$@"
次の例は、サンプル出力と共にスクリプトを実行する方法を示しています。
root@vm:~# time ~azureuser/file_restorer.bash /lustre/client/ 5000
Finding all files to restore beneath: /lustre/client/
Found 78100 to restore
Initiating restores in batches of 5000...
Restored 5000 / 78100
Restored 10000 / 78100
Restored 15000 / 78100
Restored 20000 / 78100
Restored 25000 / 78100
Restored 30000 / 78100
Restored 35000 / 78100
Restored 40000 / 78100
Restored 45000 / 78100
Restored 50000 / 78100
Restored 55000 / 78100
Restored 60000 / 78100
Restored 65000 / 78100
Restored 70000 / 78100
Restored 75000 / 78100
Restored 78100 / 78100
real 6m59.633s
user 1m20.273s
sys 0m37.960s
Note
現時点では、Azure Managed Lustre は最大スループットレートが約 7.5GiB/秒で Blob Storage からデータを復元します。
エクスポート ジョブを使用して Blob Storage にデータをエクスポートする
エクスポート ジョブを作成することで、Azure Managed Lustre ファイル システムから Azure Blob Storage の長期ストレージにデータをコピーできます。
エクスポート ジョブ中にエクスポートされるファイルはどれですか?
Azure Managed Lustre システムからファイルをエクスポートする場合、ファイル システムの作成時に指定した BLOB コンテナーにすべてのファイルがコピーされるわけではありません。 エクスポート ジョブには、次の規則が適用されます。
- エクスポート ジョブは、新しいファイルまたは内容が変更されたファイルのみをコピーします。 ファイル システムの作成時に BLOB コンテナーからインポートしたファイルが変更されていない場合、エクスポート ジョブはファイルをエクスポートしません。
- メタデータが変更されたファイルはエクスポートされません。 メタデータの変更には、所有者、アクセス許可、拡張属性、名前の変更 (名前の変更) が含まれます。
- Azure Managed Lustre ファイル システムで削除されたファイルは、エクスポート ジョブ中に元の BLOB コンテナーでは削除されません。 エクスポート ジョブでは、BLOB コンテナー内のファイルは削除されません。
アクティブ・ファイル・システムでのエクスポート・ジョブの実行
アクティブなファイル システムでは、エクスポート ジョブ中にファイルを変更すると、エラー状態になることがあります。 このエラー状態により、ファイル システム内のすべてのデータを Blob Storage にエクスポートできないことがわかります。 このような場合は、新しいエクスポート ジョブを作成してエクスポートを再試行できます。 新しいジョブは、前のジョブでコピーされなかったファイルのみをコピーします。
アクティビティが多いファイル システムでは、ファイルが頻繁に変更されるため、再試行が複数回失敗する可能性があります。 ファイルが Blob Storage に正常にエクスポートされたことを確認するには、対応する BLOB のタイムスタンプを確認します。 ジョブが完了したら、デプロイ時に構成されたログ コンテナーを表示して、エクスポート ジョブに関する詳細情報を表示することもできます。 ログ コンテナーは、失敗したファイルと失敗した理由に関する診断情報を提供します。
クラスターの使用停止を準備していて、Blob Storage への最終的なエクスポートを実行する場合は、エクスポート ジョブを開始する前にすべての I/O アクティビティが停止していることを確認する必要があります。 この方法は、ファイル システムアクティビティによるエラーを回避することで、すべてのデータがエクスポートされることを保証するのに役立ちます。
エクスポートされたファイルのメタデータ
ファイルが Azure Managed Lustre ファイル システムから BLOB コンテナーにエクスポートされると、追加のメタデータが保存され、ファイル システムへの内容の再インポートが簡略化されます。
次の表に、BLOB メタデータにキーと値のペアとして保存される Lustre ファイル システムの POSIX 属性を示します。
| POSIX 属性 | Type |
|---|---|
owner |
int |
group |
int |
permissions |
8 進数または rwxrwxrwx 形式。スティッキー ビットがサポートされています |
ディレクトリ属性は空の BLOB に保存されます。 この BLOB はディレクトリ パスと同じ名前を持ち、BLOB メタデータ hdi_isfolder : trueに次のキーと値のペアが含まれています。
コンテナーを使用して新しい Lustre クラスターをハイドレートする前に、POSIX 属性を手動で変更できます。 前に説明したキーと値のペアを使用して、BLOB メタデータを編集または追加します。
エクスポート ジョブに関する考慮事項
エクスポート ジョブを使用してデータをエクスポートする場合は、次の点を考慮する必要があります。
- 一度に実行できるインポートまたはエクスポート アクションは 1 つだけです。 たとえば、エクスポート ジョブが進行中の場合、別のエクスポート ジョブを開始しようとするとエラーが返されます。
AzCopy または Storage Explorer を使用して Lustre BLOB コンテナーをコピーする
AzCopy または Storage Explorer を使用して、Lustre が使用する BLOB コンテナーを移動またはコピーできます。
AzCopy の場合は、次のフラグを追加してディレクトリ属性を含めることができます。
--include-directory-stub
このフラグを含めると、転送中にディレクトリ POSIX 属性が保持されます (例: owner, group、 permissions. このフラグを指定せずにストレージ コンテナーで使用 azcopy する場合、またはフラグを設定した false場合、データとディレクトリは転送に含まれますが、ディレクトリは POSIX 属性を保持しません。
Storage Explorer では、[設定] で [転送] を選択し、[ディレクトリ スタブを含める] チェック ボックスをオンにすることで、このフラグを有効にすることができます。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示