Capordiaファイルを役割と所有者で分類する
処理に必要な入力、中間ファイル、保持すべき結果を分けてください。入力はリポジトリやアーカイブから取得でき、一時ファイルは再作成でき、結果には永続的な保存先が必要です。さらに4つ目の分類として、実行を再開するための状態があります。再開ポイントは、元の入力とも最終結果とも混同されません。
各分類について、所有者と保持ルールを定めてください。キャッシュの削除を承認できるのは誰か。結果が利用可能であることを確認するのは誰か。作業が中断した場合に欠けるファイルはどれか。これらの答えを、採用した保存先とともにプロジェクト資料に記載してください。カタログはGPUを説明するものですが、ディスク容量、クォータ、保持の条件は、実際に提供される範囲について確認する必要があります。
初期アーカイブだけでなく、ストレージのピークを計算する
実行中の最大ボリュームを見積もってください。展開されたイメージ、作業コピー、複数のバージョンは、受け取ったアーカイブより多くの容量を占めることがあります。正しい計算は、同時に存在する要素を合計します。排他的なフェーズを合計してはいけませんし、処理がまだ出力を生成している間にエクスポートを準備できることも忘れてはいけません。
10進GBを用いた架空の例です。あるチームが、420 GBの展開済みファイルを準備する間、180 GBのアーカイブを保持します。さらに120 GBの一時ファイル、60 GBの出力、24 GBの再開ポイントを3つ見込みます。すべてが同時に存在する場合、ピークは180 + 420 + 120 + 60 + 72 = 852 GBとなります。内部マージンを20%とすると、必要量は1,022.4 GBになります。このプロジェクト上の想定は、いかなるプランにも含まれる容量ではありません。
| カテゴリ | 計算 | ボリューム |
|---|---|---|
| 保持される入力アーカイブ | 1 × 180 GB | 180 GB |
| 展開された入力 | 1 × 420 GB | 420 GB |
| ピーク時の一時ファイル | 作業上の想定 | 120 GB |
| 準備中の出力 | 作業上の想定 | 60 GB |
| 再開ポイント | 3 × 24 GB | 72 GB |
| マージン前の合計 | 5つのカテゴリの合計 | 852 GB |
一連の実行を開始する前に使用可能な場所を確認する
プロジェクトを実際に受け入れるファイルシステムの空き容量を確認し、書き込み権限と想定される最大ファイルサイズも確認してください。非常に多くの小さなファイルを扱う場合は、システムがinodeを使用しているならinodeの可用性も確認してください。GNU dfは利用可能なブロックとinodeを区別します。バイト単位の容量指標だけでは、ファイル作成が失敗するすべての原因を要約できません。
LinuxとGNUツールが利用可能な場合、以下のコマンドでカレントディレクトリを読み取り専用で確認できます。確認した時刻とパスを記録してください。これらの確認はストレージ速度を測定するものではなく、領域の予約でもありません。さらにクォータが適用される場合もあります。準備完了と判断する前に、その範囲を確認してください。
df -B1 --output=source,size,used,avail,pcent,target .
df -i .チームが再確認できる名前と状態を整える
出力には、バッチと処理バージョンを識別できる名前を付けてください。進行中のファイルと検証済みの成果物を分けてください。納品フォルダーでは、承認された結果と同名の部分的なコピーを混在させてはいけません。台帳には、データ自体を含めずに、バッチID、コードバージョン、場所、検証状態を対応付けることができます。
長時間の計算では、アプリケーションが生成できる再開ポイントを定義し、それらを読み取れることを確認してください。保存された状態とともに必要なパラメーターを保持してください。コピー中にプロセスがまだファイルへ書き込んでいる場合、アプリケーションに用意された仕組みがなければ、そのコピーを一貫した状態とみなさないでください。確定して識別されたバックアップを優先し、その名前を次の作業を準備する担当者に伝えてください。
転送と成果物の利用を別々に確認する
最終日の前に、最初の成果物を最終的な保存先へ転送してください。期待されるファイルの一覧とサイズを比較し、手順で定めている場合はハッシュ値も比較します。GNU の SHA-2 ツールはファイルのハッシュ値を計算し検証します。マニフェストは完成したファイルと一致している必要があり、出所が明らかな状態で保管してください。マニフェストだけでは内容の業務上の品質は保証されません。
整合性の確認後、成果物を保存先から実際に使用するアプリケーションで開いてください。要素数、形式、外部依存関係を確認します。完全にコピーされたアーカイブでも、最初からファイルが欠けていることがあります。したがって受領担当者は、コピーが期待されたパッケージと一致していること、そのパッケージが次の工程で実際に使えることという、2つの別個の点を確認する必要があります。
sha256sum --check MANIFEST.sha256期間終了前に保存の可否を決める
852 GB の例では、独立したコピーを確認した後に作業用アーカイブを削除すれば、余裕を見る前の必要量は 672 GB まで下がります。この削減は、アーカイブの復元が可能であり、かつ後続の工程がその場での保持を求めない場合にのみ有効です。判断はデータの所有者が行うもので、空き容量の不足に気づいた担当者がその場で決めてよいものではありません。
よくある誤りは、すべてのバージョンを無制限に保持すること、保存先の権限を最後にまとめてテストすること、同じ場所にあるコピーを退避手段として数えることです。保持する一覧、エクスポートの担当者、その最終確認を定めてください。3日、7日、30日のいずれでも、計算にかかる時間と回収にかかる時間は同じ計画の一部です。
判断のための質問
一時ファイルはすべて保持すべきですか？
必ずしもそうではありません。アプリケーションが再生成できるものを特定し、その容量を再生成のコストと時間と比較してください。検証済みの再開に必要な要素は保持します。まだ使用中のファイルや不可欠な状態の削除は、クリーンアップ規則の対象外とすべきです。
正しいハッシュ値だけでエクスポートを受け入れてよいですか？
ハッシュ値は期待値との一致を検証します。さらに、マニフェストが正しいファイルを対象としていること、成果物が依存関係を含めて開けることを確認する必要があります。したがって受け入れは、パッケージの整合性と保存先からの機能確認を組み合わせて行います。
GPU メモリは不足したディスク容量の代わりになりますか？
いいえ。VRAM はカード上の計算で使用するデータを保持するもので、ファイルの保存先やレンタル期間終了後の保管の代わりにはなりません。GPU メモリ、システムメモリ、ストレージはそれぞれ別に記載してください。