Oracle Hierarchical Storage Manager and StorageTek QFS Software (Oracle HSM) の配備は、基本的に非常に単純なプロセスです。ソフトウェアパッケージをインストールし、いくつかの構成ファイルを編集し、いくつかのコマンドを実行したあと、新しいファイルシステムをマウントして使用します。ただし、Oracle HSM には広範なオプションやチューニングパラメータが用意されています。これらの追加機能を使用すると、ほとんどの特殊なニーズに対応することができます。ただし、不要な機能によって配備が複雑化するため、結果として得られるソリューションの満足度が低下する原因になります。
したがってこのドキュメントでは、詳細なソリューション要件に厳密に従った Oracle HSM 配備の手順について説明しています。基本的な QFS および Oracle HSM ファイルシステムの作業、インストール、および構成から開始します。これらのファイルシステムは、単独ですべての要件を満たすか、より特殊なソリューションのための基礎となっています。基本機能の配備が完了したら、次に特定の環境や特殊なビジネスニーズをサポートする追加機能を構成する手順に進みます。次の中核となるタスクを実行します。
要件に合わせてハードウェアとオペレーティングシステムソフトウェアを構成します。
必要となる基本 QFS ファイルシステムまたは Oracle HSM ファイルシステム、あるいはその両方を構成し、可能なかぎりデフォルトを使用します。
要件を満たすための追加の Oracle HSM 機能をすべて構成します。
完成した構成のバックアップを取り、テスト用や本番用として引き渡します。
計画プロセスと配備プロセス全体を通して、QFS および Oracle HSM の設計は、パフォーマンスの最適化、データ保護、およびアーカイブ処理の複雑性が単純な UNIX ファイルシステムインタフェースの背後に隠されています。ユーザー、アプリケーション、およびほとんどの場合、管理者は、ディスクアレイとテープライブラリの混合に実装され、完全に最適化された Oracle HSM アーカイブ処理システムを、単一のローカルディスク上にある通常の UFS ファイルシステムと同様に取り扱うことができるべきです。Oracle HSM ソフトウェアは、インストールして構成したあとは、データとストレージリソースを可能なかぎりもっとも効率的かつ信頼できる方法で自動的に管理するはずであり、人間の介入は最小限で済みます。したがって、ファイルシステムやストレージリソースを極端に複雑に実装したり、過度に細かく管理すると、Oracle HSM 配備の重要な目標が損なわれ、パフォーマンスや容量の利用率、データ保護などに悪影響を及ぼすことがあります。
この概要の残りの部分では、QFS ファイルシステムおよび Oracle HSM アーカイブファイルシステムの概要について簡単に説明します。この情報を大まかに把握するだけでも、後続の各構成手順の目的を理解しやすくなります。
QFS ファイルシステムを使用すると、完全に最適化されたカスタムストレージソリューションと標準の UNIX インタフェースとを組み合わせることができます。これらは内部的に、厳格かつ高度に特殊化されることの多いパフォーマンス要件を満たせるように、物理ストレージデバイスを管理します。しかし、これ自体は外部ユーザー、アプリケーション、およびオペレーティングシステムに対しては通常の UNIX ファイルシステムとして提示されます。したがって、特殊なパフォーマンス要件やデータ保護要件を複雑な各種ストレージハードウェアを使用して実現すると同時に、既存のアプリケーションやビジネスプロセスとの単純な統合を保証することができます。
QFS ファイルシステムは、中核となる QFS ボリュームマネージャーを使用して独自の物理ストレージを管理します。QFS software は、標準インタフェースと完全な互換性のある高度に最適化された論理デバイスに標準の物理ストレージデバイスを編成します。その特殊な機能やカスタマイズはこのソフトウェアによってカプセル化されるため、オペレーティングシステムやアプリケーションからは見えないままになります。後者に対し、QFS software は、標準の Solaris デバイスドライバ経由で単一ディスクのように入出力要求を処理する論理ファミリセットデバイスを提供します。この標準準拠とチューニングのしやすさの組み合わせこそが、QFS とその他の UNIX ファイルシステムとの違いです。
このセクションの残りの部分では、まず QFS のデフォルトおよび入出力パフォーマンスのチューニングについて簡単に説明したあと、作成するファイルシステムの入出力動作を制御するために使用できる各コアツールについて説明します。
柔軟なディスク割り当て単位と論理デバイスタイプを使用すると、読み取り/書き込みのサイズをファイルのサイズに一致させることができます。
ストライプ化とラウンドロビン式のファイル割り当て方式を使用すると、ファイル入出力とデバイスとの相互作用の方法を制御できます。
完全に構成可能なストレージ割り当てと組み込みボリューム管理を使用すると、ファイルシステムとベースとなる物理ストレージとの相互作用の方法を制御できます。
汎用および高性能ファイルシステムの選択により、データおよびメタデータ入出力を別のデバイスで実行するためのオプションが提供されます。
ディスクの入出力 (I/O) には、CPU 負荷の高いオペレーティングシステム要求と、時間のかかる機械的なプロセスが伴います。したがって、入出力パフォーマンスチューニングは、ある特定のデータ量を転送する際の入出力関連のシステムオーバーヘッドを最小化しつつ、機械的な作業量を必要最小限に抑えることに重点が置かれます。つまり、データ転送あたりの個別入出力の数 (CPU が実行する操作の数) を減らすとともに、各入出力の間のシーキング (読み取り/書き込みヘッドの再配置) を最小限に抑えます。したがって、入出力チューニングの基本目的は次のようになります。
平均ファイルサイズで割り切れるブロックの単位での、データの読み取りおよび書き込み。
大きなデータブロックの読み取りおよび書き込み。
ベースとなるメディアの 512 バイトセクター境界に整列する単位でのブロックの書き込み。これにより、ディスクコントローラが新しいデータを書き込む前に、既存データの読み取りと変更が不要になります。
小さい入出力のキャッシュ内でのキュー、および大きい単位にまとめられた入出力のディスクへの書き込み。
Oracle HSM のデフォルト設定を使用すると、大部分の汎用ファイルシステムで典型的なさまざまなアプリケーションや使用パターンで、全体的に最良のパフォーマンスが得られます。ただし、必要であればアプリケーションから生成される入出力のタイプに応じてデフォルト動作を調整できます。連続する読み取りまたは書き込みの最小サイズを指定できます。ファイルがデバイスに格納される方法を最適化できます。一般的な使用または高いパフォーマンスのために最適化されたファイルシステムを選択できます。
ファイルシステムは、均一サイズのブロックの単位でディスクストレージを割り当てます。このサイズ、つまりディスク割り当て単位 (DAU) によって、書き込まれるデータ量に関係なく、各入出力操作で消費される連続した領域の最小量と、ある特定のサイズのファイル転送に最低限必要な入出力操作の回数が決まります。ブロックサイズがファイルの平均サイズに比べて大きすぎると、ディスク領域が無駄になります。ブロックサイズが小さすぎると、各ファイル転送でより多くの入出力操作が必要となり、パフォーマンスが低下します。したがって、入出力のパフォーマンスやストレージの効率が最大になるのは、ファイルサイズが基本ブロックサイズの偶数倍になっている場合です。
このため、QFS software は構成可能な DAU サイズの範囲をサポートしています。QFS ファイルシステムを作成する場合は、まずアクセスおよび格納する必要のあるデータファイルの平均サイズを確認します。次に平均ファイルサイズをもっとも均等に分割する DAU を指定します。
まず、使用するデータにもっとも適した QFS デバイスタイプを選択します。次の 3 つのタイプがあります。
md デバイス
mr デバイス
gXXX ストライプ化グループデバイス (ここで、XXX は [0-127] の範囲の整数)。
ファイルシステムに主に小さいファイルが含まれる、または小さいファイルと大きいファイルが混在する場合、通常 md デバイスが最適な選択肢です。md デバイスタイプでは柔軟なデュアル割り当てスキームが使用されます。ファイルシステムではファイルをデバイスに書き込む際に、最初の 8 つの書き込みに 4K バイトの小さい DAU を使用します。その後、ユーザーが選択した大きな DAU (16、32、または 64K バイト) を使用して残りのデータをすべて書き込みます。したがって、小さいファイルは適切な小さいブロックで書き込まれ、大きいファイルはその平均サイズに応じて調整された大きいブロックで書き込まれます。
ファイルシステムに主に大きなファイルが含まれる場合、均一サイズのファイルが含まれる場合、または大きなファイルと均一サイズのファイルが含まれる場合、mr デバイスが最適な選択肢となる場合があります。mr デバイスタイプでは、[8-65528]K バイトの範囲内で 8K バイトの増分値で調整可能な DAU が使用されます。ファイルは大きな均一ブロックで書き込まれ、平均的なファイルサイズにきわめて近くなるため、読み取り/変更/書き込みのオーバーヘッドが最小限に抑えられ、パフォーマンスが最大化されます。
ストライプ化グループは最大 128 個のデバイスをまとめたものであり、単一の論理デバイスとして扱われます。ストライプ化グループでは mr デバイスタイプの場合と同じく、[8-65528]K バイトの範囲内で 8K バイトの増分値で調整可能な DAU が使用されます。ファイルシステムは、ディスクごとに 1 DAU ずつ、ストライプ化グループのメンバーにデータを並列的に書き込みます。したがって、書き込み合計量が非常に大きくなる可能性があります。このため、きわめて大きなデータファイルを処理する必要のあるアプリケーションで、ストライプ化グループが役に立つ可能性があります。
デフォルトでは、非共有の QFS ファイルシステムでストライプ化割り当てが使用され、共有ファイルシステムではラウンドロビン式割り当てが使用されます。ただし、必要であれば割り当てを変更できます。どちらの方法も状況によっては利点があります。
ストライプ化割り当てが指定された場合、ファイルシステムは、使用可能なすべてのデバイス上で並列的に領域を割り当てます。ファイルシステムはデータファイルを複数のセグメントに分割し、各デバイスにセグメントを 1 つずつ書き込みます。各セグメントのサイズは、ストライプ幅 (各デバイスに書き込まれる DAU の数) × ファミリセット内のデバイス数によって決まります。デバイスは md ディスクデバイス、mr ディスクデバイス、ストライプ化グループのいずれかになります。
一般に、ストライプ化によってパフォーマンスが向上しますが、これは、ファイルシステムが複数のファイルセグメントを順番にではなく同時に読み取るためです。複数の入出力操作が異なるデバイス上で並列して発生するため、デバイス当たりのシークオーバーヘッドが低減します。
ただし、ストライプ化割り当てでは、複数のファイルへの書き込みが一度に行われると、非常に多くのシーキングが発生する可能性があります。過剰なシーキングが発生するとパフォーマンスが大幅に低下する可能性があるため、複数ファイルへの同時入出力が予想される場合には、ラウンドロビン式割り当てを検討してください。
ラウンドロビン方式割り当てが指定された場合、ファイルシステムはストレージ領域を一度に 1 ファイル、一度に 1 デバイスずつ順次割り当てます。ファイルシステムは、使用可能な領域がある最初のデバイスにファイルを書き込みます。ファイルがデバイス上の残りの領域よりも大きい場合、ファイルシステムはその余剰分を、使用可能な領域のある次のデバイスに書き込みます。ファイルシステムは後続のファイルごとに、次に使用可能なデバイスへと移動し、このプロセスを繰り返します。ファイルシステムは、使用可能な最後のデバイスを使い終わると、また最初のデバイスに戻ります。デバイスは md ディスクデバイス、mr ディスクデバイス、ストライプ化グループのいずれかになります。
アプリケーションが複数ファイルへの入出力を同時に実行する場合、ラウンドロビン式割り当てを使用するとパフォーマンスが改善される可能性があります。またこれは、QFS 共有ファイルシステムのデフォルトでもあります (共有ファイルシステムの詳細については、Oracle HSM ソフトウェアを使用した複数のホストからのファイルシステムへのアクセスおよび mount_samfs のマニュアルページを参照)。
1 つのデバイスや 1 つのデバイスの一部のみを対象とする UNIX ファイルシステムとは異なり、QFS ファイルシステムは独自にボリュームを管理します。各ファイルシステムは、物理ストレージを提供する各デバイス間の関係を内部的に処理したあと、そのストレージを単一のファミリセットとしてオペレーティングシステムに提供します。入出力要求はほかの UNIX ファイルシステムと同じく、標準の Solaris デバイスドライバインタフェース経由で行われます。
QFS ファイルシステムには次の 2 つのタイプがあります。それぞれには独自の利点があります。
ms ファイルシステムQFS ms ファイルシステムは実装がもっとも簡単であり、一般用途の大部分に適しています。これらは同じ二重割り当て (md ディスクデバイス) のファイルデータとともにファイルシステムメタデータを格納します。この方法は、ハードウェア構成を簡略化し、ほとんどのニーズを満たします。
ma ファイルシステム{ENT:QFS }ma ファイルシステムは、要求の多いアプリケーションでデータ転送速度を改善できます。これらのファイルシステムは、メタデータおよびデータを専用のデバイスに別個に格納します。メタデータは mm デバイスに保持され、データは一連の md ディスクデバイス、mr ディスクデバイス、またはストライプ化グループに保持されます。その結果、メタデータの更新はユーザーおよびアプリケーションの入出力と競合せず、デバイス構成は 2 つの異なる種類の入出力ワークロードに対応する必要はありません。たとえば、RAID-10 ミラー化ディスクにはメタデータを配置して冗長性や読み取り速度を改善させ、領域の使用効率の高い RAID-5 ディスクアレイにデータを保持できます。
アーカイブファイルシステムは、1 つ以上の QFS ma または ms タイプのファイルシステムをアーカイブストレージおよび Oracle Hierarchical Storage Manager software と組み合わせます。Oracle HSM software は、ファイルシステムのディスクキャッシュからセカンダリディスクストレージまたはリムーバブルメディア、あるいはその両方にファイルをコピーします。ファイルシステムの中核となる部分としてコピーを管理します。したがって、ファイルシステムは、継続的なデータ保護機能、およびディスクまたはソリッドステートメディアに格納するとコストがかかりすぎる可能性がある大規模ファイルを柔軟かつ効率的に格納する機能の両方を提供します。
Oracle HSM ファイルシステムを適切に構成すると、別のバックアップアプリケーションを使用しなくても継続的なデータ保護を実現できます。ソフトウェアは、ファイルが作成または変更されると、ユーザー定義ポリシーに指定されているとおりに、ファイルデータを自動的にコピーします。ローカルとリモートの両方のリソースを使用して、ディスクとテープメディアを含めて最大 4 つのコピーを維持できます。ファイルシステムのメタデータには、ファイルとそのすべてのコピーの場所が記録されます。ソフトウェアには、コピーをすばやく検索するための各種ツールが用意されています。このため、ファイルが失われたり破損したりしても、アーカイブからすぐに回復できます。しかも、バックアップコピーは標準の POSIX 準拠 tar (テープアーカイブ) 形式で保存されるため、Oracle HSM software を使用できない場合でもデータを回復できます。Oracle HSM は、入出力エラーを動的に検出して回復することによって、ファイルシステムメタデータの整合性を常に維持します。このため、時間のかかる整合性チェックを実行せずにファイルシステムのバックアップを実行できます。これは、何十万個ものファイルやペタバイトのデータが格納されている場合の重要な考慮事項になります。ファイルシステムのメタデータが別のデバイスに格納されており、データストレージディスクのみが問題になっている場合は、交換ディスク上でファイルシステムが構成された時点で回復が完了します。故障したディスク上にあったファイルがユーザーから要求された場合、Oracle HSM が自動的にそのバックアップコピーをテープから交換ディスクにステージングします。メタデータも失われていた場合、管理者は samfsrestore コマンドを使用して samfsdump バックアップファイルからそのメタデータを復元できます。メタデータの復元が完了すると、ユーザーからの要求に応じて再度テープからファイルを復元できるようになります。ディスクへのファイルの復元は要求に応じてのみ実行されるため、回復プロセスではネットワーク帯域幅を効率的に使用し、通常動作への影響も最小限に抑えられます。
Oracle HSM ファイルシステムはこのように、高パフォーマンスなプライマリディスクまたはソリッドステートメディア上のファイルと低コストでより高密度なセカンダリディスク、テープ、または光メディア上のファイルを同時に管理できる能力を備えているため、きわめて大きいファイルや使用頻度の低いファイルの経済的な格納には最適です。衛星画像や映像ファイルなど、順次アクセス方式の非常に大きなデータファイルは、磁気テープにのみ格納できます。ユーザーやアプリケーションがファイルにアクセスすると、選択されたファイル構成に応じて、ファイルシステムは自動的にファイルを元のディスクにステージングする、ファイルをテープからメモリー内に直接読み取ります。主に履歴や法令準拠を目的として保存されるレコードは、ファイル保存期間中のある時点で、ユーザーのアクセスパターンやコスト制約にもっとも適したメディアを使用して、階層的に格納できます。まず、ユーザーがときどきファイルにアクセスする場合は、低コストのセカンダリディスクデバイスにアーカイブできます。要求の減少に応じて、テープや光メディア上にのみコピーを維持します。しかし、法的証拠開示や規制プロセスへの対応などのためにデータが必要になった場合は、その場所に最初から存在していたように最小限の遅延で、必要な情報がファイルシステムによって自動的にプライマリディスクにステージングされます。法律および規制のために使用する場合、WORM に対応した Oracle HSM ファイルシステムを使用できます。WORM 対応のファイルシステムでは、デフォルトおよびカスタマイズ可能なファイル保持期間、データとパスの不変性、および WORM 設定のサブディレクトリの継承がサポートされます。手動または自動、あるいはその両方のメディア検証を使用すると、長期間のデータの整合性をモニターできます。
アーカイブファイルシステムを管理および保守する基本的な Oracle HSM プロセスとして、次の 4 つがあります。
アーカイブ処理では、アクティブファイルのコピーの格納場所として予約されたアーカイブメディアにファイルシステム内のファイルをコピーします。アーカイブメディアには、磁気テープカートリッジなどのリムーバブルメディアボリュームや、磁気ディスクまたはソリッドステートストレージデバイス上に存在している 1 つ以上のファイルシステムを含めることができます。アーカイブファイルコピーは、アクティブファイルのバックアップ冗長性または非アクティブファイルの長期保存、あるいはその両方の何らかの組み合わせを提供することができます。
Oracle HSM アーカイブファイルシステムでは、アクティブなオンラインファイル、アーカイブコピー、および関連ストレージリソースが、単一の論理リソースであるアーカイブセットを形成します。アーカイブファイルシステム内のどのアクティブファイルも、属しているアーカイブセットは 1 つだけです。各アーカイブセットには、各ファイルの最大 4 つのアーカイブコピーと、そのアーカイブセットのアーカイブ処理を制御するポリシーを含めることができます。
アーカイブ処理は UNIX デーモン (サービス) の sam-archiverd によって管理されます。このデーモンは、アーカイブアクティビティーをスケジュールし、必要なタスクを実行するプロセス (archiver、sam-arfind、および sam-arcopy) を呼び出します。
archiver プロセスは、編集可能な構成ファイル archiver.cmd 内のアーカイブポリシーを読み取り、残りのアーカイブ処理を指示に従って設定します。このファイル内のディレクティブは、アーカイブ処理の全般的な動作を制御し、アーカイブセットをファイルシステム別に定義し、作成するコピーの数やそれぞれが使用するアーカイブメディアを指定します。
次に、sam-archiverd デーモンは現在マウントされているファイルシステムごとに sam-arfind プロセスを起動します。sam-arfind プロセスは割り当てられたファイルシステムをスキャンし、新しいファイル、変更済みのファイル、名前が変更されたファイル、および再アーカイブまたはアーカイブ解除する必要のあるファイルの有無を調べます。このプロセスはデフォルトでファイルやディレクトリへの変更を継続的にスキャンするため、それによって全体のパフォーマンスが最大になります。ただし、たとえば古い StorageTek Storage Archive Manager 実装との互換性を維持する必要がある場合は、archiver.cmd ファイル内のアーカイブセット規則を編集し、いずれかの方法のうち 1 つを使用するスキャンをスケジュールすることもできます (詳細は、sam-archiverd のマニュアルページを参照)。
sam-arfind は、候補ファイルを特定し終わると、そのファイルのアーカイブポリシーを定義したアーカイブセットを特定します。sam-arfind プロセスは、ファイルの属性と各アーカイブセットに定義された選択条件を比較してアーカイブセットを特定します。これらの条件には次の 1 つ以上のファイル属性が含まれます。
ファイルへのディレクトリパス、およびオプションで 1 つ以上の候補ファイル名に一致する正規表現
1 つ以上の候補ファイルの所有者に一致する、指定されたユーザー名
ファイルに関連付けられたグループに一致する、指定されたグループ名
候補ファイルのサイズに等しいかそれより小さい、指定された最小ファイルサイズ
候補ファイルのサイズと等しいかそれより大きい、指定された最大ファイルサイズ。
正しいアーカイブセットと対応するアーカイブパラメータが特定されると、sam-arfind は、ファイルのアーカイブ経過時間が、アーカイブセットに指定されたしきい値以上になっているかどうかをチェックします。ファイルのアーカイブ経過時間とは、ファイルの作成、最後の変更 (デフォルト)、あるいは最後のアクセス以降に経過した秒数のことです。アーカイブ経過時間がポリシーに指定された経過時間の条件を満たす場合、sam-arfind はそのファイルをアーカイブセットのアーカイブ要求キューに追加し、優先順位を割り当てます。優先順位は、アーカイブセットに指定された規則、およびすでに存在しているアーカイブコピーの数、ファイルのサイズ、すべての未処理のオペレータ要求、アーカイブコピーの作成に依存するその他のすべての操作などの要因にも基づきます。
sam-arfind は、アーカイブが必要なファイルを特定して優先順位を付け、それらを各アーカイブセットのアーカイブ要求へ追加したあと、sam-archiverd デーモンに要求を返します。デーモンは各アーカイブ要求を合成します。これによってデータファイルがデータファイル内に配置され、メディアが効率的に活用され、ファイルがリムーバブルメディアに効率的に書き込まれ、あとでリムーバブルメディアから読み取られるようになります。デーモンは、archiver.cmd ファイルに設定したファイルソートパラメータやメディア制限をすべて遵守しますが (詳細は archiver.cmd のマニュアルページを参照)、通常、ソフトウェアが自由にメディアを選択できないように制限するとパフォーマンスが低下し、メディアの使用率も低下します。アーカイブファイルの組み立てが完了すると、sam-archiverd はアーカイブ要求の優先順位を決定し、コピープロセスが最小回数のマウント操作で最大数のファイルを転送できるようにします (詳細は、sam-archiverd マニュアルページのスケジューリングに関するセクションを参照)。次に sam-archiverd は、コピー操作のスケジューリングを行い、どの時点でも、アーカイブセットポリシーやロボットライブラリで許可される最大ドライブ数を超えるドライブを必要としないようにします。
アーカイブ要求のスケジューリングが完了すると、sam-archiverd はスケジュールされたアーカイブ要求とドライブごとに、sam-arcopy プロセスのインスタンスを呼び出します。sam-arcopy インスタンスは、データファイルをアーカイブメディア上のアーカイブファイルにコピーし、アーカイブファイルシステムのメタデータを更新して新しいコピーの存在を反映させ、アーカイブログを更新します。
sam-arcopy プロセスが終了すると、sam-archiverd デーモンはアーカイブ要求をチェックし、キャッシュディスクからの読み取りエラー、リムーバブルメディアボリュームへの書き込みエラー、およびオープン、変更、または削除されたファイルに起因するエラーや省略の有無を調べます。アーカイブされなかったファイルがあれば、sam-archiverd が再度アーカイブ要求を合成します。
sam-arfind および sam-arcopy プロセスは、syslog 機能と archiver.sh を使用して、アーカイブアクティビティー、警告、および情報メッセージの継続的なレコードを作成できます。結果のアーカイバログには、アーカイブされたすべてのファイルのすべてのコピーに関する場所や処理の詳細な記録など、貴重な診断情報および履歴情報が含まれます。そのため、たとえば障害回復中に、それ以外の方法では回復不能な消失したデータファイルを回復するためにアーカイブログを使用できます (詳細は、お客様向けドキュメントライブラリの『Oracle Hierarchical Storage Manager and StorageTek QFS Software ファイルシステム回復ガイド』を参照)。ファイルシステム管理者は、アーカイバロギングを有効にし、archiver.cmd ファイルで logfile= ディレクティブを使用してログファイルを定義します。ログファイルの詳細については、archiver.cmd のマニュアルページを参照してください。
ステージングプロセスは、ファイルデータをアーカイブストレージから元のプライマリディスクキャッシュ内にコピーして戻します。アプリケーションがオフラインファイル (プライマリストレージ内で現在使用できないファイル) にアクセスしようとすると、アーカイブコピーが自動的にステージングされます (プライマリディスクにコピーされます)。次に、ステージングの直後に読み取り操作で追跡を行うため、アプリケーションは完全なデータがディスクに書き込まれる前でも、すぐにファイルにアクセスできるようになります。メディアエラーが発生した場合や特定のメディアボリュームが使用不可能の場合、ステージング処理では最初に使用可能なデバイスを使用して、次に使用可能なアーカイブコピーがあればそれを自動的にロードします。したがって、ステージングにより、ユーザーやアプリケーションに対してアーカイブストレージを透過的にします。すべてのファイルが常時、ディスク上で使用可能なように見えます。
大部分のファイルシステムでは、デフォルトのステージング動作で十分です。ただし、構成ファイル (/etc/opt/SUNWsamfs/stager.cmd) でディレクティブを挿入または変更することによりデフォルトを変更でき、ディレクトリごとまたはファイルごとにコマンド行からこれらのディレクティブをオーバーライドできます。たとえば、大規模ファイル内の小さなレコードにアクセスする場合、ファイルのステージングを行わない、アーカイブメディア内での直接データアクセスを選択することもできます。あるいは、結合ステージング機能を使用して、関連するファイルのいずれかがステージングされるたびに、それら関連ファイルのグループをステージングすることもできます。詳細は、stage および stager.cmd のマニュアルページを参照してください。
解放処理では、すでにアーカイブされたファイルのオンラインコピーのうち、現在使用されていないものを削除してプライマリディスクキャッシュ領域を解放します。ディスクアーカイブやテープボリュームなどのアーカイブメディアにコピーされたファイルは、アプリケーションからのアクセスがあった場合にステージングできます。したがって、ほかのファイル用の領域が必要な場合にそのファイルをディスクキャッシュ内に保持する必要はありません。ファイルシステムのサイズ増加に応じてプライマリストレージ容量が増えない場合でも、ディスクキャッシュからの不要なコピーの削除による解放では、新たに作成されたファイルや使用頻度の高いファイルに対して常にプライマリキャッシュストレージが使用可能であることを保証します。
解放処理は、キャッシュ使用率が高位境界値を超える場合、および低位境界値を上回ったままになっている場合に自動的に実行されます。この 2 つの構成可能しきい値は、アーカイブファイルシステムのマウント時に設定します。高位境界値が十分な空き領域が常に使用可能であることを保証するのに対し、低位境界値は、キャッシュ内で使用可能なファイルが常に妥当な数に保たれ、メディアのマウント操作が必要最小限に抑えられることを保証します。一般的な値は、最高値が 80%、最低値が 70% です。
大部分のファイルシステムでは、デフォルトの動作を使用した境界値による解放で十分です。ただし、構成ファイル (/etc/opt/SUNWsamfs/releaser.cmd) 内のディレクティブを変更したり追加したりしてデフォルトを変更でき、ディレクトリごとまたはファイルごとにコマンド行からそれらのデフォルトをオーバーライドできます。たとえば、順次アクセスされる大規模ファイルを部分的に解放すると、アプリケーションがディスク上に常に保持されているファイルの一部の読み取りを開始している間に、残りの部分をアーカイブメディアからステージングさせることができます。詳細は、release および releaser.cmd のマニュアルページを参照してください。
リサイクル処理では、使用されなくなったアーカイブコピーを削除してアーカイブメディア上の領域を解放します。ユーザーがファイルを変更すると、そのファイルの古いバージョンに関連付けられたアーカイブコピーは最終的に期限切れになります。リサイクラは、期限切れアーカイブコピーの割合がもっとも高いメディアボリュームを特定します。期限切れのファイルがアーカイブディスクボリュームに格納されている場合、リサイクラプロセスがそれを削除します。ファイルがリムーバブルメディア (テープボリュームなど) に存在する場合、リサイクラは、対象ボリュームに残っている期限切れではないコピーをほかのメディアに再アーカイブします。次に編集可能なスクリプト (/etc/opt/SUNWsamfs/scripts/recycler.sh) を呼び出し、リサイクルされたボリュームの再ラベル付け、ライブラリからのエクスポート、またはその他のユーザー定義アクションの実行を行います。
デフォルトでは、リサイクル処理は自動的に実行されません。Solaris crontab ファイルを構成して、都合のよいときにそれを実行できます。または、/opt/SUNWsamfs/sbin/sam-recycler コマンドを使用してコマンド行から必要に応じて実行することもできます。デフォルトのリサイクルパラメータを変更するには、ファイル /etc/opt/SUNWsamfs/archiver.cmd を編集するか、あるいは別の /etc/opt/SUNWsamfs/recycler.cmd ファイルを作成します。詳細は、対応するマニュアルページを参照してください。