Skip to main content

This is documentation for Caché & Ensemble. See the InterSystems IRIS version of this content.Opens in a new tab

For information on migrating to InterSystems IRISOpens in a new tab, see Why Migrate to InterSystems IRIS?

ファイル・システムおよびストレージの構成における推奨事項

ファイル・システムおよびストレージの構成における推奨事項

このセクションでは以下の領域における一般的な推奨事項を示します。

また、データベース構成における推奨事項の概要は、"Caché システム管理ガイド" の “Caché の構成” の章にある "データベースの構成" のセクションを参照してください。

ファイル・システムの推奨事項

パフォーマンスと復元可能性を高めるために、Caché 用に少なくとも 4 つの独立したファイル・システムを備えて以下をホストすることをお勧めします。

  • インストール・ファイル、実行可能ファイル、およびシステム・データベース (既定では、ライト・イメージ・ジャーナル (WIJ) ファイルを含む)

  • データベース・ファイル (およびオプションで WIJ)

  • プライマリ・ジャーナル・ディレクトリ

  • 代替ジャーナル・ディレクトリ

さらに、それとは別に WIJ ファイル専用のファイル・システムを構成に追加することもできます。このファイルは、既定で install—dir\mgr\ ディレクトリに作成されます。このファイル・システムには、WIJ が最大サイズにまで拡大できる十分な領域を確保してください。この最大サイズは、[メモリと開始設定] ページ ([システム管理][構成][システム構成][メモリと開始設定]) で割り当てたデータベース・キャッシュのサイズと同じです ("Caché システム管理ガイド" の “Caché の構成” の章にある "メモリと開始設定" を参照)。WIJ の詳細は、"Caché データ整合性ガイド" の “ライト・イメージ・ジャーナリング” の章を参照してください。

Note:

UNIX®、Linux、および macOS プラットフォームでは、/usr/local/etc/cachesys は Caché レジストリ・ディレクトリであるため、ローカル・ファイル・システム上に配置する必要があります。

重大なディスク障害が発生してデータベース・ファイルを破損した場合、バックアップからのリカバリにおいてジャーナル・ファイルが重要な要素になります。 したがって、データベース・ファイルおよび WIJ が使用するデバイスから独立したストレージ・デバイスにプライマリ・ジャーナル・ディレクトリおよび代替ジャーナル・ディレクトリを配置する必要があります (WIJ の損傷によってデータベースの整合性が損なわれる可能性があるため、ジャーナルは WIJ から独立させる必要があります)。 代替ジャーナル・デバイスを使用すると、プライマリ・ジャーナル・デバイスでのエラーの後でもジャーナリングを続行できるため、プライマリ・ジャーナル・ディレクトリおよび代替ジャーナル・ディレクトリも相互に独立したデバイスに配置する必要があります。運用上の理由から、これらの異なるデバイスを同じストレージ・アレイ上の異なる論理ユニット (LUN) にすることもできますが、一般的には独立性が高いほど好ましいです (別々の物理ドライブを強く推奨)。別々のジャーナル・ストレージについての詳細は、"Caché データ整合性ガイド" の “ジャーナリング” の章にある"ジャーナリングの最善の使用方法" を参照してください。

ジャーナル・ディレクトリと WIJ ディレクトリは、インストール時には構成されません。これらのディレクトリを Caché のインストール後に変更する方法の詳細は、"Caché データ整合性ガイド" の "ジャーナル設定の構成" を参照してください。

Note:

現在のストレージ・アレイ (特に、SSD/フラッシュ・ベースのアレイ) では、前に推奨した種類の独立性は必ずしも可能ではありません。 このような技術を使用する場合、パフォーマンスと復元可能性を高めるために、ストレージ・ベンダの推奨事項を参照して、これに従ってください。

また、このセクションでは、以下の項目に関する情報も示しています。

ストレージの構成の推奨事項

現在、従来の磁気回転方式の HDD デバイスから SSD および PCIe フラッシュ・ベース・デバイスに至るまで多くのストレージ技術が利用されています。 さらに、複数のストレージ・アクセス技術には、NAS、SAN、FCoE、直接接続、PCIe、ハイパー・コンバージド・インフラストラクチャを備えた仮想ストレージなどがあります。

ご使用のアプリケーションに最適なストレージ技術は、アプリケーション・アクセス・パターンで決まります。 例えば、ランダム読み取りが大部分であるアプリケーションの場合、SSD またはフラッシュ・ベース・ストレージが理想的なソリューションです。また、書き込みが非常に多いアプリケーションの場合、従来の HDD デバイスが最適です。

以下の各セクションでは、一般的な提案としてのガイドラインについて説明します。 特定のストレージ製品のプロバイダは、個別のベスト・プラクティスや場合によっては相反するベスト・プラクティスを指定するかもしれません。それらを参照し、適切に従ってください。

ストレージの接続

ストレージの接続には以下の考慮事項が適用されます。

SAN (Storage Area Network) ファイバー・チャネル

各ホストから SAN スイッチまたはストレージ・コントローラに複数のパスを使用します。 1 つのカードの障害から保護するために複数の HBA を使用すると保護のレベルが上がりますが、最小の推奨事項は、少なくとも 1 つのデュアルポート HBA を使用することです。

ストレージ・アレイ・レイヤに復元可能性をもたらすには、ストレージ・コントローラの障害から保護し、ファームウェアの更新などのアクティビティのためのメンテナンス期間でさえも継続してアクセスを提供するために、アクティブ/アクティブ構成またはアクティブ/パッシブ構成のいずれかのデュアル・コントローラを備えたアレイをお勧めします。

冗長性を実現するために複数の SAN スイッチを使用する場合、推奨される一般的な方法は、各スイッチを個別の SAN ファブリックにし、不具合のある構成の変更を 1 つのスイッチにとどめ、両方のスイッチに影響してすべてのストレージ・アクセスが妨げられることがないようにすることです。

ネットワーク接続ストレージ (NAS)

これは、一般的に 10GB のイーサネットが使用可能であり、最高のパフォーマンスを実現するためには、10GB のスイッチおよびホスト・ネットワーク・インタフェース・カード (NIC) をお勧めします。

専用のインフラストラクチャを用意して、LAN の通常のネットワーク・トラフィックからトラフィックを分離することもお勧めします。 こうすることによって、ホストとストレージの間の NAS のパフォーマンスを予測できます。-

ジャンボ・フレームのサポートを含めて、ホストとストレージの間の十分な通信を提供することも必要です。

多くのネットワーク・インタフェース・カード (NIC) は TCP オフロード・エンジン (TOE) をサポートします。TOE のサポートは、普遍的に利点があるとみなされているわけではありません。使用可能なサイクル (またはその欠如) に対するオーバーヘッドおよびゲインは、サーバの CPU によって大きく変化します。 また、TOE のサポートは役に立つ期間が制限されます。これは、指定された NIC の TOE パフォーマンス・レベルにすぐにシステム処理能力が追いつくまたは多くの場合追い越すためです。

ストレージの構成

ストレージ・アレイを取り巻く状況は、技術的特徴、機能、およびパフォーマンスのオプションにおいて絶えず変化していて、複数のオプションが最適なパフォーマンスおよび復元可能性を Caché にもたらすようになります。 以下のガイドラインは、Caché の最適なパフォーマンスおよびデータの復元可能性を実現するための一般的なベスト・プラクティスを提供します。

過去において、最大の保護およびパフォーマンスを実現するために RAID10 が推奨されていました。 しかし、ストレージ・コントローラの機能、RAID の種類とアルゴリズムの効率、およびインラインの圧縮や複製などのコントローラ機能によって、かつてないほど多くのオプションが提供されています。 また、アプリケーションの入出力パターンによって、最高のソリューションをもたらすストレージ RAID レベルおよび構成をストレージ・ベンダと共に決定できます。

可能な場合には、ファイル・タイプのブロック・サイズと同等のブロック・サイズを使用することが最良です。ほとんどのストレージ・アレイは指定されたボリューム用に使用できるブロック・サイズが低く制限されていますが、ファイル・タイプのブロック・サイズをできる限り近くできます。例えば、ストレージ・アレイ上の 32KB または 64KB のブロック・サイズは、通常、8KB ブロック形式の CACHE.DAT ファイルを効果的にサポートする実用的なオプションです。 ここでの目標は、アプリケーションのニーズに基づいてストレージ・アレイの入出力が過剰または無駄にならないようにすることです。

以下の表は、Caché のインストール環境内でのストレージの入出力の一般的な概要を示しています。

入出力の種類

タイミング

方法

留意事項

データベースの読み取り (ほぼランダム)

ユーザの処理によって連続

ユーザの処理によってディスク入出力が開始され、データを読み取り

データベースの読み取りは、デーモンが処理する Web ページ、SQL クエリ、または直接ユーザ処理によって実行されます。

データベースの書き込み (順序付けされるが非連続で実行)

約 80 秒ごとまたは保留中の更新がデータベース・キャッシュのしきい値のパーセントに達したとき (先に基準を満たした方)

データベース・ライト・デーモン

(8 個のプロセス)

データベースの書き込みは、ライト・デーモンと呼ばれる一連のデータベース・システム・プロセスによって実行されます。 ユーザ処理によってデータベース・キャッシュが更新され、トリガ (時間またはデータベース・キャッシュのパーセントが一杯になったとき) によってライト・デーモンを使用してディスクの更新が実行されます。通常、更新レートに応じて、書き込みサイクル中に数 MB から数 GB 書き込む必要があることを想定しています。

WIJ 書き込み (連続)

約 80 秒ごとまたは保留中の更新がデータベース・キャッシュのしきい値のパーセントに達したとき (先に基準を満たした方)

データベース・マスタ・ライト・デーモン (1 個のプロセス) WIJ は、データベースの書き込みサイクル中のシステム障害から物理データベース・ファイルの整合性を保護するために使用されます。 書き込みは、約 256KB のサイズごとに行われます。

ジャーナル書き込み (連続)

ジャーナル・データの 64KB ごとまたは 2 秒ごと、または ECP、Ensemble、またはアプリケーションの同期要求

データベース・ジャーナル・デーモン (1 個のプロセス)

ジャーナル書き込みは連続で、4KB から 4MB までサイズが変化します。 1 秒あたり数十回の書き込みから、ECP および個別のアプリケーション・サーバを使用した非常に大きい配置の場合には 1 秒あたり数千回の書き込みまでになる場合があります。

ストレージのボトルネックは、データベースのシステム・パフォーマンスに影響する最も一般的な問題の 1 つです。一般的な誤りは、十分な数の個別ディスクを確保して 1 秒あたりに予期される入出力操作 (IOPS) をサポートするのではなく、データ容量のみに対してストレージをサイズ調整することです。

入出力の種類

平均応答時間

最大応答時間

留意事項

データベース・ブロック・サイズのランダム読み取り (キャッシュ処理なし)

<=6 ms

<=15 ms

データベース・ブロックは固定 8KB、16KB、32KB、または 64KB (ホストでのデータベース・キャッシュは大きいため、ディスクへのほとんどの読み取りはキャッシュされません)。

データベース・ブロック・サイズのランダム書き込み (キャッシュ処理あり)

<=1 ms

<2 ms

すべてのデータベース・ファイルの書き込みは、ストレージ・コントローラのキャッシュ・メモリによってキャッシュされることが想定されます。

4KB から 4MB のジャーナル書き込み (ECP 未使用)

<=2 ms

<=5 ms

ジャーナル書き込みは連続で、4KB から 4MB までサイズが変化します。 書き込みボリュームは ECP アプリケーション・サーバを使用しない場合には比較的小さいです。

4KB から 4MB のジャーナル書き込み (ECP 使用)

<=1 ms

<=2 ms

ECP から生成されるジャーナル同期要求によって、厳格な応答時間の要件が課され、スケーラビリティが維持されます。 同期要求の発行によって、ジャーナルの最後のブロックへの書き込みをトリガして、データの持続性を確保できます。

これらの数値はガイドラインとして提供しており、任意のアプリケーションで理想的なパフォーマンスを実現するためには、許容範囲およびしきい値がこれらの数値よりも高いまたは低い場合があります。これらの数値および入出力の水準は、ご使用のストレージ・ベンダとの議論の開始点として使用してください。

FeedbackOpens in a new tab