Storage Foundation Cluster File System High Availability 7.4 管理者ガイド - Linux
- 第 I 部 Storage Foundation Cluster File System High Availability の概要
- Storage Foundation Cluster File System High Availability の概要
- Veritas File System について
- Storage Foundation Cluster File System(SFCFS)について
- Veritas Replicator について
- Dynamic Multi-Pathing の動作
- Veritas Volume Manager の動作
- Veritas File System の動作
- Storage Foundation Cluster File System High Availability の動作方法
- Storage Foundation Cluster File System High Availability アーキテクチャについて
- クラスタファイルシステムでサポートされている Veritas File System 機能について
- 単一ネットワークリンクと信頼性について
- I/O フェンシングについて
- Cluster Volume Manager の動作
- Storage Foundation Cluster File System High Availability の概要
- 第 II 部 ストレージのプロビジョニング
- 新しいストレージのプロビジョニング
- ストレージを設定するための高度な割り当て方法
- 割り当て動作のカスタマイズ
- 特定のレイアウトのボリュームの作成
- VxFS ファイルシステムの作成とマウント
- VxFS ファイルシステムの作成
- VxFS ファイルシステムのマウント
- ファイルシステムサイズの変更
- 空き領域の監視
- エクステント属性
- 第 III 部 DMP を使ったマルチパスの管理
- Dynamic Multi-Pathing の管理
- 新しく追加されたディスクデバイスの検出と設定
- ディスクの検出とディスクアレイの動的な追加について
- デバイス検出層の管理方法
- vxdmpadm ユーティリティを使った DMP の管理
- I/O 統計情報の収集と表示
- I/O ポリシーの指定
- 新しく追加されたディスクデバイスの検出と設定
- デバイスの動的再構成
- デバイスの管理
- イベント監視
- Dynamic Multi-Pathing の管理
- 第 IV 部 Storage Foundation Cluster File System High Availability の管理
- Storage Foundation Cluster File System High Availability とそのコンポーネントの管理
- CFS の管理
- mount、fsclustadm、fsadm コマンドについて
- CFS プライマリノードで障害が発生した場合
- SFCFSHA のスナップショットについて
- VCS の管理
- CVM の管理
- マスターフェールオーバーへのクラスタノードの優先設定の設定について
- CVM マスターの手動での変更について
- 共有ディスクグループのインポート
- Flexible Storage Sharing の管理
- ODM の管理
- I/O フェンシングの管理について
- vxfentsthdw ユーティリティについて
- vxfenadm ユーティリティについて
- vxfenclearpre ユーティリティについて
- vxfenswap ユーティリティについて
- コーディネーションポイントサーバーの管理について
- ディスクベースとサーバーベースのフェンシング設定間の移行について
- SFCFSHA のグローバルクラスタの管理
- クラスタ化された NFS の使用
- クラスタ化された NFS のしくみ
- クラスタ化された NFS の設定および設定解除
- クラスタ化された NFS の管理
- クラスタ化された NFS の設定例
- Common Internet File System の使用
- クラスタ化された NFS を使用した Oracle の展開
- Oracle データベースへの SFCFSHA ユーティリティの使用
- サイトとリモートミラーの管理
- SFCFSHA を使った iSCSI の管理
- SFCFSHA を使ったデータストアの管理
- Storage Foundation Cluster File System High Availability とそのコンポーネントの管理
- 第 V 部 I/O パフォーマンスの最適化
- 第 VI 部 Veritas Extension for Oracle Disk Manager
- Veritas Extension for Oracle Disk Manager の使用
- Oracle Disk Manager について
- Oracle Disk Manager と Oracle Managed Files について
- Cached ODM の使用
- Veritas Extension for Oracle Disk Manager の使用
- 第 VII 部 PITC の使用
- PITC 方法の理解
- ボリュームスナップショットの管理
- 従来のサードミラーブレークオフスナップショット
- フルサイズインスタントスナップショット
- インスタントスナップショットの作成
- インスタントスナップの DCO と DCO ボリュームの追加
- インスタントスナップショットの同期の制御
- インスタントスナップショットの作成
- カスケードスナップショット
- バージョン 0 の DCO および DCO ボリュームの追加
- Storage Checkpoint の管理
- FileSnaps の管理
- スナップショットファイルシステムの管理
- 第 VIII 部 Storage Foundation Cluster File System High Availability を使用したストレージの最適化
- 第 IX 部 ストレージ利用率の最大化
- SmartTier によるストレージの階層化
- ボリュームセットの作成と管理
- MVS ファイルシステム
- SmartTier の管理
- ホットリロケーションの管理
- データの重複排除
- ファイルの圧縮
- Cloud Connector を使用したクラウドへのファイルの移行
- 第 X 部 ストレージの管理
- ボリュームとディスクグループの管理
- デフォルトのディスクグループの名前の付け方
- ボリュームまたはディスクの移動
- タスクの監視と制御
- オンライン再レイアウトの実行
- ボリュームへのミラーの追加
- ディスクグループの管理
- プレックスとサブディスクの管理
- Veritas InfoScale Storage 環境の Erasure coding
- ストレージの破棄
- ルータビリティ
- クォータ
- FCL(File Change Log)
- ボリュームとディスクグループの管理
- 第 XI 部 参照
- 付録 A. パス名の逆引きルックアップ
- 付録 B. チューニングパラメータ
- 付録 C. コマンドリファレンス
- 付録 D. スタータデータベースの作成
I/O 頻度とアクセス頻度の計算
VxFS SmartTier の重要なアプリケーションには、非アクティブファイルの安価なストレージへの自動再配置があります。ファイルシステムのスキャンでは、<ACCAGE> 要素に指定された期間にアクセスのなかったファイルが、下位階層のストレージに再配置されるようにスケジュールされます。ただし、最後のアクセスからの時間だけでは、負荷ベースの再配置基準としては不十分です。
その理由は次のとおりです。
アクセス期間はバイナリ測定値です。ファイルの最後のアクセスからの時間は、ファイルのメタデータの POSIX atime から fsppadm enforce コマンドの発行時間を引いて求められます。ファイルが fsppadm enforce コマンド発行の前の日にオープンされた場合、そのファイルの最後のアクセスからの時間は、たとえその前の 1 カ月間アクティブにならなくても、1 日です。 ポリシールールの目的が、非アクティブなファイルを下位階層のボリュームに再配置することであれば、<ACCAGE> 値に定義された期間に偶然にアクセスされたファイルには不適切な処理を行ってしまいます。
アクセス期間は重要なアクティビティの続行を示すインジケータとしては不適切です。 非アクティブなファイルを下位階層ボリュームに再配置するための基準として、最後のアクセスからの時間である ACCAGE を使うと、実行する必要がある再配置をスケジュールできない場合があります。ただし、少なくともこの方法を使うと再配置アクティビティが必要よりも少なくなります。 以前にアクティブにならなかったファイルをアクティビティが再開したことで再配置するような基準に、ACCAGE を使うのはさらに不適切です。この方法は正当な理由のない再配置アクティビティをスケジュールするようなものだからです。 ポリシールールの目的が、最近 I/O 負荷のあったファイルを、パフォーマンスが速く、耐障害性の優れていると思われるストレージに再配置することであれば、ACCAGE はフィルタとしては粗すぎます。たとえば、ルールに、過去 3 日間にアクセスされた
tier2
ボリュームのファイルをtier1
ボリュームに再配置するように指定されている場合、1 人のユーザーに参照されたファイルと実際にアプリケーションで何度も使われたファイルは区別されません。
SmartTier は、このような不足を克服するため I/O 頻度とアクセス頻度の概念を実装します。ファイルの I/O 頻度は、指定期間中のファイルへの(またはファイルからの)転送バイト数をファイルサイズで割った値です。 たとえば、fsppadm enforce 操作時に、1 MB のストレージを占有するファイルがあり、そのデータに対して過去 3 日間に 15 回完全な読み取りまたは書き込みが行われた場合、VxFS はそのファイルの 3 日間の平均 I/O 頻度を 5 と計算します(15 MB I/O ÷ 1 MB ファイルサイズ ÷ 3 日)。
同様に、ファイルの平均アクセス頻度とは、指定した期間数 x 24 時間におけるファイルに対する読み取りまたは書き込みの要求数を、指定した期間数で割った値です。I/O 頻度とは異なり、アクセス頻度はファイルサイズに関係しません。2 日間で 20 回の I/O 要求があった大容量ファイルと 2 日間で 20 回のアクセスがあった小容量ファイルの平均アクセス頻度は同じです。
ファイルシステムのアクティブな配置ポリシーに <IOTEMP> または <ACCESSTEMP> 節が記述されている場合、VxFS はポリシーの実施を開始し、ファイルシステムの FCL ファイルの情報を使って、ファイルシステムの全ファイルに対する平均 I/O 負荷を計算します。計算の対象期間は、ポリシーに指定した最長の <PERIOD> です。これよりも短い期間の指定は無視されます。VxFS はこれらの計算結果を使って、I/O 頻度ベースの再配置または削除の対象ファイルを決定します。
Veritas File System ファイルの変更ログファイルについてを参照してください。
メモ:
FCL がオフになっている場合は、I/O 頻度ベースの再配置は不正確になります。FCL がオフになっている場合は、fsppadm enforce コマンドを呼び出す時に、警告が表示されます。
FCL(File Change Log)は、名前が意味するとおり、VxFS ファイルシステム内でのファイルに対する変更情報を記録します。作成、削除、拡張を記録する他に、FCL はファイル別に I/O 負荷(読み取りと書き込みのバイト数)の累積量を定期的に取得します。ファイルの I/O 負荷は、ファイルが開かれるまたは閉じられるたびに FCL に記録されます。さらに、定期的な間隔で長い期間開かれたままになっているファイルの情報が取得されます。
ファイルシステムのアクティブなファイル配置ポリシーに <IOTEMP> 節がある場合、fsppadm enforce コマンドの実行で、FCL のスキャンが開始され、ポリシーで指定された所定の期間の I/O 負荷情報が抽出されます。所定の期間とは、fsppadm enforce コマンドの発行時間と、その時間からアクティブなポリシーの <PERIOD> 要素に指定された最長の間隔値を引いた時間との間です。
最長間隔の期間に I/O 負荷のあったファイルに対し、VxFS は読み取り処理、書き込み処理、合計データ転送(両方の合計)処理の量を概算で求めます。これは、ファイルに保持された最も新しい FCL レコードの I/O レベルから、最も古いものを引いた値です。次に、各ファイルの I/O 負荷を Tscan 時のファイルサイズで割って、各ファイルの I/O 頻度を計算します。ファイルサイズで割ることは、大容量ファイルの再配置は小容量ファイルの再配置よりも多くの I/O リソースを消費することを勘案しています。このアルゴリズムを使う場合、大容量ファイルが所定の I/O 頻度に達するにはより多くのアクティビティが必要となるため、再配置のリソースコストが正当化されます。
この計算結果はいくつかの方法による概算ですが、容易に計算できます。またさらに重要なことは、最近の I/O 負荷の偏たりのない相対的な算出値であるということで、これを基に適切な再配置を決定できます。
ファイルの再配置と削除は、読み取り、書き込み、合計 I/O 負荷のいずれかを基に決定できます。
次の XML の抜粋は、ポリシールールに IOTEMP を記述して、アクティビティが少ないファイルを tier1
から tier2
ボリュームに再配置する例です。
<RELOCATE> <FROM> <SOURCE> <CLASS>tier1</CLASS> </SOURCE> </FROM> <TO> <DESTINATION> <CLASS>tier2</CLASS> </DESTINATION> </TO> <WHEN> <IOTEMP Type="nrwbytes}"> <MAX Flags="lt">3</MAX> <PERIOD Units="days">4</PERIOD> </IOTEMP> </WHEN> </RELOCATE>
この例では、ルールが適用されたファイルで 4 日間の I/O 頻度が 3 未満のものは tier1
から tier2
ボリュームに再配置されます。 Type="nrwbytes}" XML 属性を指定すると、合計データ転送処理(読み取りと書き込みの合計バイト数)が計算に使われます。たとえば、fsppadm enforce スキャン直前の 4 日間に、150 MB 未満のデータ転送を行った 50 MB のファイルは再配置対象となります。 VxFS は、所定の期間にアクティビティのなかったファイルは I/O 頻度がゼロであるとみなします。VxFS は、ファイルシステムのディレクトリツリーをスキャンする時に見つけた対象ファイルの順番で再配置を行います。
I/O 頻度またはアクセス頻度を使うと、POSIX atime または mtime などのアクティビティのバイナリ指標を使うよりも、所定の期間に偶然にアクセスされただけのファイルを再配置しない機会を少なくすることができます。ファイルへの(またはファイルからの)転送バイト数が少量しかない大容量ファイルの I/O 頻度は低い値です。したがってこのようなファイルは、直近にアクティビティがあったとしても、tier2
ボリュームへの再配置対象となります。
ただし、ファイル再配置基準としての I/O 頻度またはアクセス頻度が高い値になれば、上方再配置の対象となります。つまり、以前にアクティブになっていないか低頻度のためにストレージ階層の下位に再配置されていたファイルは、そのファイルに対する I/O 負荷レベルの上昇が検出されると、ストレージ階層の上位に再配置されます。
次の XML の抜粋は、アクティビティレベルが上昇したファイルを tier2
から tier1
ボリュームに再配置する例です。
<RELOCATE> <FROM> <SOURCE> <CLASS>tier2</CLASS> </SOURCE> </FROM> <TO> <DESTINATION> <CLASS>tier1</CLASS> </DESTINATION> </TO> <WHEN> <IOTEMP Type="nrbytes"> <MAX Flags="gt">5</MAX> <PERIOD Units="days">2</PERIOD> </IOTEMP> </WHEN> </RELOCATE>
<RELOCATE> 文には、tier2
ボリュームのファイルで、2 日間の読み取りバイト数を使って計算された I/O 頻度が 5 より大きなものは、tier1
ボリュームに再配置されるように指定されています。所定の期間におけるこのファイルへの書き込みバイト数は、この計算では使われません。
アクティビティのバイナリ指標ではなく I/O 頻度をファイル再配置基準として使うことで、管理者は細かいレベルで自動ファイル再配置を制御でき、これを使ってポリシーをアプリケーションの必要条件に合わせることができます。たとえば、上方再配置文の <PERIOD> 要素に大きな値を指定すれば、ファイルに対する持続的な I/O 負荷がないかぎり、ファイルが再配置されることはありません。代わりに、高い頻度と短い期間を指定すれば、短期間に I/O 負荷の集中したファイルが再配置されるようになります。
I/O 頻度とアクセス頻度は、i ノードでインデックス付けされた一時テーブル作成のために sqlite3
データベースを活用します。この一時テーブルを使って、I/O 頻度とアクセス頻度を基にしたファイルのフィルタ処理を行います。一時テーブルは、マウントポイントの lost+found
ディレクトリにあるデータベースファイル .__fsppadm_fcliotemp.db
に格納されています。