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 ファイル システムにインポートされるデータをフィルター処理できます。 プレフィックスのいずれかに一致する BLOB コンテナー内のファイル名は、ファイル システム内のメタデータ レコードに追加されます。 クライアントが最初にファイルにアクセスすると、その内容が BLOB コンテナーから取得され、ファイル システムに保存されます。
Azure portal で、クラスターの作成時に [詳細設定] タブの [インポート プレフィックス] フィールドを使用して、BLOB コンテナーからインポートするデータを指定します。 これらのフィールドは、初期インポート ジョブにのみ適用されます。 クラスターの作成後にインポート プレフィックスを変更することはできません。
インポート ジョブの場合は、ジョブの作成時にインポート プレフィックスを指定できます。 Azure portal から、[インポート プレフィックス] フィールドにインポート プレフィックスを指定できます。 REST API を使用してインポート ジョブを作成するときに、インポート プレフィックスを指定することもできます。
インポート プレフィックスを指定するときは、次の点に注意してください。
- 既定のインポート プレフィックスは
/です。 この既定の動作では、BLOB コンテナー全体の内容がインポートされます。 - 複数のプレフィックスを指定する場合、プレフィックスは重複しないようにする必要があります。 たとえば、
/dataと/data2を指定した場合、プレフィックスが重複しているため、インポート ジョブは失敗します。 - BLOB コンテナーが階層型名前空間が有効になっているストレージ アカウント内にある場合、プレフィックスをファイル パスとして考えることができます。 パスの下の項目は、Azure Managed Lustre ファイル システムに含まれています。
- BLOB コンテナーが非階層 (またはフラット) 名前空間を持つストレージ アカウント内にある場合、インポート プレフィックスは、BLOB 名の先頭と比較される検索文字列と考えることができます。 コンテナー内の BLOB の名前がインポート プレフィックスとして指定した文字列で始まる場合、そのファイルはファイル システムでアクセス可能になります。 Lustre は階層ファイル システムであり、BLOB 名の
/文字は Lustre に格納されるとディレクトリ区切り記号になります。
競合解決モード
BLOB コンテナーからデータをインポートするときに、BLOB コンテナーとファイル システム間の競合を処理する方法を指定できます。 このオプションは、既存のクラスターに対して実行されるインポート ジョブにのみ適用されます。 次の表は、使用可能な競合解決モードとその説明を示しています。
| Mode | 説明 |
|---|---|
fail |
競合が検出された場合、インポート ジョブはすぐに失敗し、エラーが発生します。 |
skip |
競合が検出された場合、インポート ジョブはファイルをスキップします。 |
overwrite-dirty |
インポート ジョブは競合するパスを評価し、削除して再インポートする必要があるかどうかを確認します。 詳細については、「overwrite-dirty モード」を参照してください。 |
overwrite-always |
インポート ジョブは競合するパスを評価し、ダーティな場合は常に削除/再インポートし、クリーンな場合は解放します。 詳細については、「overwrite-always モード」を参照してください。 |
Overwrite-dirty モード
overwrite-dirty モードは競合するパスを評価し、削除して再インポートする必要があるかどうかを確認します。 大まかに言うと、overwrite-dirty モードは HSM の状態をチェックします。 HSM の状態が Clean と Archived の場合、そのデータは Lustre が認識する限り BLOB コンテナーと同期されており、必要な場合にのみ属性が更新されます。 それ以外の場合、ファイルは削除され、BLOB コンテナーから再インポートされます。
HSM の状態をチェックしても、Lustre 内のファイルが BLOB コンテナー内のファイルと一致することは保証されません。 Lustre 内のファイルが BLOB コンテナー内のファイルと可能な限り一致するようにする必要がある場合は、overwrite-always モードを使用します。
Overwrite-always モード
overwrite-always モードは競合するパスを評価し、ダーティな場合は常に削除/再インポートし、クリーンな場合は解放します。 このモードは、ファイル システムが常に BLOB コンテナーと同期していることを確認したい場合に便利です。 また、これは最もコストのかかるオプションでもあります。以前に復元されたすべてのファイルは、最初のアクセス時に解放されるか、削除/再インポートされるからです。
エラー許容度
BLOB コンテナーからデータをインポートするときに、エラー許容度を指定できます。 エラー許容レベルは、オペレーティング システム エラーやネットワークの中断など、インポート プロセス中に発生する一時的なエラーをインポート ジョブが処理する方法を決定します。 このコンテキストのエラーは、競合解決モードによって処理されるファイルの競合を指すものではないことに注意することが重要です。
インポート ジョブでは、次のエラー許容オプションを使用できます。
- エラーを許可しない (既定): インポート中にエラーが発生した場合、インポート ジョブは直ちに失敗します。 この動作が既定です。
- エラーの許可: エラーが発生した場合でもインポート ジョブは続行され、エラーがログに記録されます。 インポート ジョブが完了すると、ログ コンテナーでエラーを表示できます。
BLOB インポート ジョブに関する考慮事項
BLOB コンテナーからデータをインポートするときには、次の項目を考慮することが重要です。
- 一度に実行できるインポートまたはエクスポート アクションは 1 つだけです。 たとえば、インポート ジョブが進行中の場合、別のインポート ジョブを開始しようとするとエラーが返されます。
- インポート ジョブはキャンセルできます。 既存のクラスターで開始されたインポート ジョブ、またはクラスターの作成中に開始されたインポート ジョブをキャンセルできます。
- 対応するインポート ジョブが完了する前に、クラスターのデプロイが正常に戻る場合があります。 インポート ジョブはバックグラウンドで引き続き実行されます。 インポート ジョブの進行状況は、次の方法で監視できます。
- Azure portal: Azure portal にインポート ジョブの状態が表示されます。 ファイル システムに移動し、[BLOB 統合] を選択してインポート ジョブの状態を表示します。
- ルート ディレクトリの Lustre ファイル: インポート中に、Lustre ルート ディレクトリに
/lustre/IMPORT_<state>.<timestamp_start>のような名前のファイルが作成されます。 インポートの進行に応じて<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
注
現時点では、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 名は、特定の 名前付け規則に準拠している必要があります。つまり、許容される BLOB 名は、許容される POSIX ファイル名とは若干異なります。 エクスポート プロセスでは、BLOB へのエクスポート時に正しくエスケープすることで、ファイル名内の特殊文字が保持されます。 ただし、BLOB 名の最大長を超えるファイル名など、BLOB の名前付け規則に違反するファイル名は、そのファイルをエクスポートしようとするとエラーになります。
アクティブなファイル システムでエクスポート ジョブを実行する
アクティブなファイル システムでは、エクスポート ジョブ中にファイルが変更されると、エラー状態になる可能性があります。 このエラー状態は、ファイル システム内のすべてのデータを Blob Storage にエクスポートできなかったことを示します。 このような場合は、新しいエクスポート ジョブを作成することでエクスポートを再試行できます。 新しいジョブでは、前のジョブでコピーされなかったファイルのみがコピーされます。
アクティビティが多いファイル システムでは、ファイルが頻繁に変更されるため、再試行が複数回失敗する可能性があります。 ファイルが Blob Storage に正常にエクスポートされたことを確認するには、対応する BLOB のタイムスタンプを確認します。 ジョブが完了したら、デプロイ時に構成されたログ コンテナーを表示して、エクスポート ジョブの詳細情報を確認することもできます。 ログ コンテナーは、どのファイルが失敗したか、またその理由に関する診断情報を提供します。
クラスターの使用を停止する準備をしていて、Blob Storage への最終エクスポートを実行する場合は、エクスポート ジョブを開始する前に、すべての I/O アクティビティが停止していることを確認する必要があります。 このアプローチは、ファイル システム アクティビティによるエラーを回避することで、すべてのデータがエクスポートされることを保証するのに役立ちます。
エクスポートされたファイルのメタデータ
ファイルが Azure Managed Lustre ファイル システムから BLOB コンテナーにエクスポートされると、追加のメタデータが保存され、ファイル システムへのコンテンツの再インポートが簡素化されます。
次の表は、BLOB メタデータにキーと値のペアとして保存される Lustre ファイル システムの POSIX 属性を示しています。
| POSIX 属性 | タイプ |
|---|---|
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 で、[設定] でこのフラグを有効にするには、[転送] を選択し、[ディレクトリ スタブを含める] のチェック ボックスをオンにします。
