|
| Sun ONE Directory Server インストールおよびチューニングガイド |
適切にハードウェアをサイジングすることは、ディレクトリサービスの計画と導入において必須事項です。ハードウェアのサイジングには、利用可能なメモリ容量と利用可能なローカルディスクの空き容量がきわめて重要になります。
この章では、Directory Server インスタンスのディスクとメモリの要件を見積もる方法を紹介します。また、ネットワーク要件や SSL アクセラレータハードウェアの要件についても説明します。
推奨される最小要件
表 4-1 に、実際の運用環境でソフトウェアをインストールして使用するためのメモリとディスクの最小要件を示します。
指定したエントリ数における最小要件は、実際には表 4-1 で示す要件と異なることがあります。ここでのサイズは、比較的小さなエントリで、デフォルトの設定によるインデックスと最小限チューニングされたキャッシュを用いる場合です。デジタル写真などの大きなバイナリ属性値がエントリに含まれる場合や、インデックスまたはキャッシュに異なる設定を用いている場合は、それに応じてディスク容量とメモリの最小見積もりをそれぞれ上方修正します。
ディスク容量の最小要件には、アクセスログ専用の 1G バイトが含まれています。デフォルトでは、Directory Server は 10 個 (cn=config におけるnsslapd-accesslog-maxlogsperdir) のアクセスログファイルをローテーションするように設定されており、それぞれのログファイルは最大 100M バイト (cn=config における nsslapd-accesslog-maxlogsize) のメッセージを保持します。エラーログと監査ログの大きさは、Directory Server の設定状況によって変わります。ログの設定の詳細は、『Sun ONE Directory Server 管理ガイド』を参照してください。
最小の利用可能なメモリ
メモリの最小見積もりは、通常の導入における Directory Server インスタンスで使用されるメモリを反映しています。見積もりには、システムやほかのアプリケーションで使用されるメモリは含まれていません。より正確な見積もりを得るには、メモリの使用量を経験的に測定する必要があります。詳細は、「物理メモリのサイジング」を参照してください。
原則として、利用可能なメモリ量が多ければ多いほど良い状況であるといえます。
最小のローカルディスクの空き容量
ローカルディスクの空き容量の最小見積もりは、典型的な導入における Directory Server インスタンスで必要となる空き容量を反映しています。経験上、ディレクトリエントリが大きい場合、必要な空き容量は、ディスク上にある同等の LDIF のサイズを少なくとも 4 倍したサイズになります。詳細は、「ディスクサブシステムのサイジング」を参照してください。
ネットワークディスクにアクセスするサーバーやデータをインストールしないでください。Sun ONE Directory Server では、NFS、AFS、または SMB を介してネットワークに接続されたストレージの使用をサポートしていません。設定、ログ、データベース、およびインデックスファイルはすべて、インストールを終えてからも、常にローカルストレージ上に配置する必要があります。
Windows システムの場合は、ドライブは FAT ではなく NTFS でフォーマットします。FAT は Directory Server での使用がサポートされていません。NTFS では、アクセス制御をファイルやディレクトリに設定することができます。
最小プロセッサ能力
大ボリュームシステムでは、通常、複数の高速プロセッサを搭載することで、複数の同時検索、拡張インデックス、レプリケーション、およびその他の機能に適切な処理能力を実現しています。詳細は、「マルチプロセッサシステムのサイジング」を参照してください。
最小ネットワークキャパシティ
テストによると、想定される最大スループットによっては、サービスプロバイダレベルのパフォーマンスでも 100M ビット Ethernet で十分であることが示されています。論理的な最大スループットは、次のようにして見積もることができます。
最大スループット = 返される最大エントリ数/秒×平均エントリサイズ
たとえば、Directory Server がピーク時には 1 秒あたり 5000 個の検索に対応しなければならず、平均サイズが 2000 バイトのエントリを返すとします。このとき論理的な最大スループットは 10M バイト、つまり 80M ビットとなります。しかし 80M ビットの方が、100M ビット Ethernet アダプタ 1 つで実現するスループットよりも大きくなる傾向があります。実際に測定されるパフォーマンスは異なることがあります。
WAN (広域ネットワーク) でマルチマスターレプリケーションを実行したい場合は、その接続で、待ち時間が最小でパケット損失がほとんどない十分なスループットが得られることを確認します。
詳細は、「ネットワークキャパシティのサイジング」を参照してください。
物理メモリのサイジング
Directory Server では、データベーステクノロジを使用して情報を格納します。データベーステクノロジに依存するあらゆるアプリケーションでは、高速なメモリが十分あることが Directory Server のパフォーマンスを最適化する上で重要です。原則として、利用可能なメモリが多ければ多いほど、すばやくアクセスするためにキャッシュされるディレクトリ情報も多くなります。ディレクトリ内容全体を常にキャッシュするのに十分なメモリが各サーバーにあるのが理想的です。Sun ONE Directory Server 5.2 では 64 ビットメモリアドレッシングをサポートしているため、キャッシュサイズは数 G バイトに制限されていません。64 ビットアーキテクチャでは、合計で 1.5T バイト以上のキャッシュサイズを扱うことが論理的に可能になりました。
注 Directory Server を実際の運用環境で導入するときは、キャッシュサイズを論理的な処理上限よりも小さく設定し、通常のシステム操作で使用できる適切なリソースを確保します。
Directory Server を実行するのに必要なメモリサイズを見積もるには、特定の Directory Server 設定と、Directory Server が実行されるシステムの両方とで必要なメモリを見積もります。
Directory Server 用メモリのサイジング
特定の導入に対して見積もった設定値が決まると、Directory Server インスタンスに必要な物理メモリを見積もることができます。表 4-2 に、この節で説明する計算で使用した値をまとめて表示します。
表 4-2 Directory Server 用メモリのサイジングの値
値
内容1
nsslapd-cachememsize
サフィックスのエントリキャッシュサイズ
エントリキャッシュには形式化されたエントリが含まれており、クライアント要求に応答して送信されることになる。1 インスタンスで複数のエントリキャッシュを処理できる
nsslapd-dbcachesize
データベースキャッシュサイズ
データベースキャッシュはサーバーで使用されるデータベースとインデックスからの要素を保持する
nsslapd-import-cachesize
一括インポート用のデータベースキャッシュサイズ
インポートキャッシュは、エントリのインポート時にのみ使用される。インポートキャッシュ用に余分なメモリを確保する必要はないが、オフラインインポートだけを実行する場合は、エントリキャッシュやデータベースキャッシュ用に確保したメモリを再利用する
nsslapd-maxconnections
管理される接続の最大数
nsslapd-threadnumber
サーバーの起動時に作成される操作スレッド数
完全な説明は、『Sun ONE Directory Server Reference Manual』を参照してください。
おおよそのメモリサイズを見積もるには、次の手順を実行します。
- サーバープロセスの基本サイズ slapdBase を見積もります。
slapdBase = 75MB +(nsslapd-threadnumber x 0.5MB) +(nsslapd-maxconnections x 0.5 KB)
- エントリキャッシュサイズの合計 entryCacheSum を決定します。
entryCacheSum = Sum全エントリキャッシュ(nsslapd-cachememsize)
- 全キャッシュの合計サイズ cacheSum を決定します。
cacheSum = entryCacheSum + nsslapd-dbcachesize + nsslapd-import-cachesize
- Directory Server プロセスの合計サイズ slapedSize を決定します。
slapdSize = slapdBase + cacheSum
Directory Server で使用される物理メモリを測定するのに、Solaris システムの pmap(1) などのユーティリティまたは Windows のタスクマネージャを使用することができます。
- 着信クライアント要求を処理するのに必要なメモリ slapdGrowth を見積もります。
slapdGrowth = 20% x slapdSize
最初の見積もりなので、クライアント要求を処理するためのオーバーヘッドとして 20% を想定します。実際の割合は、その導入の特徴によって異なる可能性があります。この割合は Directory Server を運用環境に置く前に、実際に検証します。
- Directory Server の合計メモリサイズ slapdTotal を決定します。
slapdTotal = slapdSize + slapdGrowth
32 ビットサーバーを含む大規模導入では、slapdTotal の値が実際の上限である約 3.4G バイトを超えたり、論理的な処理上限である約 3.7G バイトを超えることもあります。この場合、第 6 章「キャッシュサイズのチューニング」に示されているように、キャッシュをチューニングするか、システムの制限内で動作させるか、あるいは製品の 64 ビットバージョンを使用することができます。
オペレーティングシステム用メモリのサイジング
オペレーティングシステムを実行するのに必要なメモリを見積もるには、経験的に行うことが必要となり、オペレーティングシステムのメモリ要件は、固有のシステム設定に基づいて大きく異なります。そのため、オペレーティングシステムで必要なメモリ量を見積もろうとする前に、第 5 章「オペレーティングシステムのチューニング」で説明するように、導入に対して典型的なシステムでチューニングすることを検討します。システムをチューニングしたら、最初の見積もりの systemBase に到達するまで、メモリの使用状況を監視します。メモリの使用状況を監視するには、Solaris の sar (1M) などのユーティリティまたは Windows タスクマネージャを使用することもできます。
注 最高のパフォーマンスを得るために、Directory Server を実行するシステムはこのサービス専用で使用します。
その他のアプリケーションやサービスを実行する必要がある場合は、必要な合計メモリをサイジングするときに、使用するメモリも監視します。
さらに、一般的なシステムオーバーヘッドと通常の管理目的とにメモリを割り当てます。systemOverhead の最初の見積もりは、大きさに関係なく、少なくとも数百 M バイト、または合計物理メモリの 10% のいずれかになります。システムが実際の運用環境でメモリのページインやページアウトを行わないよう、systemOverhead に十分な容量を割り当てることが目的です。
オペレーティングシステムで必要な合計メモリ systemTotal は、次のようにして見積もることができます。
systemTotal = systemBase + systemOverhead
合計メモリのサイジング
前述の節で見積もった slapdTotal および systemTotal を使用して、必要な合計メモリ totalRAM を見積もります。
totalRAM = slapdTotal + systemTotal
totalRAM は必要な合計メモリの見積もりであり、システムが Directory Server プロセス専用であることが前提です。また、この値には、システム上で実行する可能性のあるすべてのアプリケーションとサービスに対するメモリ使用量の見積もりが含まれています。
メモリ不足での処理
多くの場合、Directory Server で使用される全データをキャッシュするのに十分なメモリを用意するのは、費用効率は良くありません。
少なくとも Directory Server を実行するのに十分なメモリをサーバーに搭載すれば、継続的なページスワップは発生しません。継続的にページスワップすることは、パフォーマンスに強い悪影響があります。Directory Server を起動してエントリキャッシュをプライムする前後でメモリ統計を表示するには、Solaris やその他のシステムの vmstat (1M) などのユーティリティを使用することができます。Solaris システムの MemTool など、個別には利用可能だがサポートされていないユーティリティも、アプリケーションがテストシステムで実行されているときに、メモリの使用状況や割り当て状況を監視するのに役立ちます。
システムに追加のメモリを搭載できない場合は、これまでどおり継続的なページスワップを監視し続け、データベースキャッシュやエントリキャッシュのサイズを減らします。スワップスペースが不足すると、Directory Server はクラッシュします。
全ディレクトリデータをキャッシュするのに十分な物理メモリを確保できないときの可能な代替策は、第 6 章「キャッシュサイズのチューニング」を参照してください。
ディスクサブシステムのサイジング
ディスクの使用と I/O 能力は、パフォーマンスに強く影響します。特に大量の変更をサポートする導入では、ディスクサブシステムは I/O のボトルネックとなる可能性があります。この節では、Directory Server インスタンスで全体のディスク容量を見積もったり、ディスク I/O のボトルネックを軽減したりするための推奨について説明します。
ディスク I/O のボトルネックを軽減する詳細は、第 8 章「ログのチューニング」を参照してください。
ディレクトリサフィックスのサイジング
サフィックスに対するディスク容量の要件は、ディレクトリ内のエントリのサイズや個数によって変化するだけでなく、ディレクトリ設定や、特にサフィックスのインデックス方法によっても変化します。大規模導入で必要なディスク容量を測定するには、次の手順を実行します。
- 導入で想定される 3 つの代表的なエントリのセットである 10,000 エントリ、100,000 エントリ、1,000,000 エントリの各セットに対して LDIF を生成します。
生成したエントリは想定されるエントリタイプ (ユーザー、グループ、ロール、拡張スキーマのエントリ) の組み合わせを反映するとともに、特に userCertificate や jpegPhoto のように単一の大きな属性値が想定される場合の個々の属性値の平均サイズも反映する必要があります。
- Directory Server のインスタンスを導入で想定されるように設定します。
特に、実際の運用ディレクトリに対して実行するようにデータベースをインデックスします。後でインデックスを追加する可能性がある場合は、追加するインデックスのスペースも追加する必要があります。
- 各エントリセットをロードし、各セットで使用されるディスク容量を記録します。
- 結果をグラフにし、導入におけるサフィックスサイズの見積もりを推定します。
- エラーや変更のために使用されるディスク容量を追加します。
サフィックスのディスク容量は、全体の一部にすぎません。同様に、Directory Server のディスク使用状況についても検討する必要があります。
Directory Server のディスク使用状況
ディレクトリのサフィックスは、Directory Server によってディスクに格納されるものの一部です。ディスク使用に影響するその他の多くの要因は、導入後の Directory Server の使用状況によっても大きく異なります。そのため、ここでは一般的な状況について説明します。ここで説明する項目を設定する手順は、『Sun ONE Directory Server 管理ガイド』を参照してください。
Directory Server バイナリ
このバージョンの Directory Server をインストールするには、約 200M バイトのディスク容量が必要です。ただし、この見積もりにはデータに対する容量は含まれていません。含まれているのは製品のバイナリに対する容量だけです。
イベントログ
ログファイルのディスク使用の見積もりは、Directory Server 動作の割合、ログのタイプとレベル、およびログローテーションの方法によって変わります。
多くのログ要件は予測でき、事前に計画をたてることができます。Directory Server でログや特に監査ログに書き込みが行われる場合、負荷レベルとともにディスクの使用状況が増大します。高負荷の導入で大規模なログを必要とするときは、高負荷に適応するように、ディスク容量を追加することを計画します。高負荷のログで導入に必要なディスク容量を減らすには、インテリジェントログローテーションおよび保管システムを構築し、頻繁にログをローテーションします。そして古いファイルはテープや、より安価なディスククラスタなど費用がかからず大容量のストレージメディアに自動的に移行させます。
ログ要件は簡単に予測できないこともあります。たとえばログをデバッグすると、一時的ですが急激にエラーログが増大します。大規模で高負荷の導入では、一時的で大量のデバッグログ専用に、数 G バイトのディスク容量を別に設定することを検討します。詳細は、第 8 章「ログのチューニング」を参照してください。
トランザクションログ
トランザクションログの量は、ピーク時の書き込み負荷によって変わります。書き込みが急激に起こる場合は、書き込み負荷が一定である場合と比べて、トランザクションログで使用する容量が多くなります。Directory Server では、トランザクションログを定期的に削除しています。そのため、トランザクションログはチェックなしで増大し続けることはありません。ただし、オンラインバックアップ中は、トランザクションログはフラッシュされません。
Directory Server では、一般的に永続トランザクションが有効な状態で実行されています。永続トランザクション機能が有効であると、Directory Server では、変更操作 (add、delete、modify、および modrdn) ごとにトランザクションログへ同期書き込みを行います。この場合、ディスクがビジーの場合は操作がブロックされ、潜在的な I/O ボトルネックとなります。
更新パフォーマンスが重要な場合は、高速な書き込みキャッシュを持つディスクサブシステムをトランザクションログ用に使用することを計画します。詳細は、第 8 章「ログのチューニング」を参照してください。
レプリケーションの更新履歴ログデータベース
Directory Server 導入時にレプリケーションを行う場合は、 更新履歴ログを記録します。更新履歴ログのサイズは、変更される量と、使用された更新履歴ログのタイプによって異なります。変更履歴ログの削除方法に応じて、容量を計画します。大規模で高負荷の導入では、変更率が異常に高いときの変更履歴ログの増加を処理するために、数 G バイトのディスク容量を別に設定することを検討します。詳細は、第 8 章「ログのチューニング」を参照してください。
サフィックスの初期化と LDIF ファイル
サフィックスの初期化は一括ロードまたは一括インポートとも呼ばれます。この最中、Directory Server で必要となるディスク容量は、サフィックスデータベースファイルとサフィックスの初期化に使用される LDIF ファイルの分だけではなく、初期化プロセス中に使用される中間ファイルの分も必要となります。サフィックスの初期化中に使用される LDIF ファイルと中間ファイル用に、追加の容量をデータベースファイルと同じディレクトリに一時的に確保することを計画します。
バックアップと LDIF ファイル
バックアップでディスク容量を大量に消費することは珍しくありません。バックアップのサイズは、関連するデータベースファイルのサイズと等しくなります。データベースファイルの量を数倍した容量を割り当てることで、複数のバックアップに対応します。これにより、データベースとそれに対応するバックアップが別々のディスクで維持されます。時間が経過するにつれてバックアップを安価なストレージメディアに移行させるには、優れたストラテジを使用します。
導入でレプリケーションを行う場合、初期化用の LDIF ファイルを保持するためのディスク容量を追加することを計画します。これは、初期化用の LDIF ファイルはバックアップ用の LDIF ファイルと異なるためです。
ディスクベースでなくメモリベースのファイルシステムを使用する
一部のシステムでは、メモリベースの tmpfs ファイルシステムをサポートしています。たとえば Solaris 上では、/tmp は、パフォーマンスを向上させるために、メモリベースのファイルシステムとしてマウントされます。システムのほかのアプリケーションと共用されている /tmp にキャッシュファイルが置かれている場合は、/tmp 下で容量不足が起こらないように注意する必要があります。このようにしないと、メモリ量が低下し、メモリベースのファイルシステム内の Directory Server ファイルが、スワップパーティション専用のディスク容量にページングされる可能性があります。
一部のシステムは、RAM ディスクやその他のメモリベースファイルシステムをサポートしています。メモリベースのファイルシステムを作成および管理する手順については、オペレーティングシステムのマニュアルを参照してください。そのようなファイルシステム内のデータはすべて揮発性であり、システムリブート後にそれらのデータをメモリ内に再ロードする必要があることに注意してください。
(UNIX プラットフォーム) core ファイル
少なくとも core ファイル 1 〜 2 個分の空きスペースを残しておきます。Directory Server でのコアダンプはお勧めしませんが、クラッシュ中に生成された core ファイルを調査に使用できる場合は、クラッシュ後の回復とトラブルシューティングが極めて簡単になる場合があります。core ファイルは生成されると、cn=config の場合に nsslapd-errorlog で指定したファイルと同じディレクトリに格納されます。起動中にクラッシュした場合は ServerRoot/bin/slapd/server/ に格納されます。
管理用のディスク容量
システムと Directory Server の管理など、予期されるシステムの使用に対して空き容量を確保します。基本となる Directory Server インストール、ローカルインスタンス上に置かれたときの設定サフィックス、設定ファイルなどに十分なディスク容量を確実に割り当てます。
ディスク間のファイルの分散
当然のように更新される Directory Server データベースやログファイルを別のディスクサブシステムに配置することで、複数のディスクスピンドルやコントローラ間に I/O トラフィックの範囲を広げることができ、I/O ボトルネックを回避できます。次の各項目に対して、専用のディスクサブシステムを用意することを検討します。
トランザクションログ
永続トランザクション機能が有効であると、Directory Server では、変更操作ごとにトランザクションログへ同期書き込みを行います。そのため、ディスクがビジーであると、操作がブロックされてしまいます。トランザクションログを専用ディスクに配置することで書き込みパフォーマンスが向上し、Directory Server で処理可能な変更率が増加します。
詳細は、「トランザクションログ」を参照してください。
データベース
複数のデータベースをサポートすることで、各データベースをそれ専用の物理ディスクに置くことが可能になります。そのため、個々のデータベースが専用のディスクサブシステム上にある場合、Directory Server の負荷を複数のデータベース間に分散させることができます。データベース操作の I/O 競合を防ぐには、データベースファイルの各セットを個別のディスクサブシステムに配置することを検討します。
最高のパフォーマンスを得るには、データベースファイルを大きい I/O バッファを持つ専用高速ディスクサブシステムに配置します。キャッシュに候補エントリが見つからない場合、Directory Server はディスクからデータを読み込み、定期的に書き込みをフラッシュします。これらの操作で専用の高速ディスクサブシステムを使用すると、潜在的な I/O ボトルネックが軽減されます。
cn=config,cn=ldbm database,cn=plugins,cn=config における nsslapd-directory 属性では、Directory Server がインデックスファイルを含むデータベースファイルを格納するディスク位置を指定します。これらのファイルはデフォルトで、ServerRoot/slapd-ServerID/db/ にあります。
当然のことながら、データベース位置の変更では、Directory Server の再起動だけでなく、データベースの完全な再構築も必要となります。実際の運用サーバーでデータベース位置を変更することは、大掛かりな作業になる場合があるため、最も重要なデータベースを特定し、それを別のディスク上に配置した後で、サーバーの運用を開始してください。
ログファイル
Directory Server には、アクセス、エラー、および監査の各ログが用意されており、バッファのあるログ能力を備えています。バッファがあるにもかかわらず、これらのログファイルに書き込みをするには、ほかの I/O 操作と競合する可能性のあるディスクアクセスが必要です。パフォーマンス、容量、および管理を改善するには、ログファイルを別々のディスクに配置することを検討します。
詳細は、第 8 章「ログのチューニング」を参照してください。
メモリベースファイルシステム上のキャッシュファイル
tmpfs ファイルシステムでは、たとえば、物理メモリが使い果たされたときだけファイルがディスクにスワップされます。すべてのキャッシュファイルを物理メモリに保持するのに十分なメモリがあれば、tmpfs ファイルシステム (Solaris プラットフォーム)、または RAM ディスクなどのその他のメモリベースファイルシステム (その他のプラットフォーム) に同じサイズのディスク容量を割り当て、Directory Server がそのファイルシステムにキャッシュファイルを格納するように nsslapd-db-home-directory の値を設定することで、パフォーマンスの向上が得られます。これにより、システムでは、キャッシュファイルにマッピングされたメモリが、不必要にディスクへフラッシュしなくなります。
ディスクサブシステムの選択
「Fast, cheap, safe: pick any two (速度、低コスト、安全性: いづれか 2 つを選択)」 『Sun Performance and Tuning』、Cockroft と Pettit 著
速度と安全性
パフォーマンスと稼働時間の両方が重要な導入を実装するときは、大規模のディスクアレイ間に分散した I/O を高速でバッファできるように、不揮発性のメモリキャッシュを備えているハードウェアベースの RAID コントローラを検討します。負荷を多くのディスクで分散させ、高速接続でアクセスをバッファすることで、I/O は最適化され、高パフォーマンスの RAID ストライピングやパリティ ブロックによって極めて安定します。
Sun StorEdgeTM 製品で提供されているような大容量で不揮発性 I/O バッファや高パフォーマンスのディスクサブシステムによって、Directory Server のパフォーマンスや稼働時間は大きく向上します。
高速な書き込みキャッシュカードでは、特にトランザクションログ専用としたときに、書き込みパフォーマンスが向上する可能性があります。高速な書き込みキャッシュカードには、ディスクコントローラから独立した不揮発性のメモリキャッシュが備わっています。
速度と低コスト
高速で低コストのパフォーマンスを得るには、十分なディスク容量が複数ディスク間に分散されていることを確認します。回転速度が速く、シークタイムが短いディスクの使用を検討します。最高の結果を得るには、分散されたコンポーネントそれぞれに対して 1 つのディスクを専用にします。シングルポイントのエラーを避けるには、マルチマスターレプリケーションを使用することを検討します。
低コストと安全性
安価で安全な設定には、Solaris Volume Manager のように低コストでソフトウェアベースの RAID コントローラの使用を検討します。
RAID の選択
RAID とは Redundant Array of Inexpensive Disks (安価なディスクを複数使用した冗長アレイ) のことです。名前が示すとおり、RAID の第 1 の目的は回復力を備えることです。アレイ内のディスクで障害が発生しても、そのディスク上のデータは失われずに、アレイ内のほかのディスクで依然として利用できます。回復力を実装するために、RAID では抽象概念を持ち込み、通常は単一のボリュームとして参照される大容量の仮想ディスクとして、複数のディスクドライブを設定することができます。これは、物理ディスクを連結、ミラーリング、またはストライピングすることで実現されます。連結の実装では、あるディスクのブロックの後に別のディスクのブロックを論理的に続けます。たとえば、ディスク 1 にはブロック 0 〜 99、ディスク 2 にはブロック 100 〜 199、というようになります。ミラーリングの実装では、あるディスクのブロックを別のディスクにコピーし、その後は同期し続けます。ストライピングでは、複数の物理ディスクに仮想ディスクのブロックを分散させるアルゴリズムを使用します。
ストライピングの目的はパフォーマンスを得ることです。ランダム書き込みでは、書き込まれるデータがストライピングボリュームの複数のディスクに送信される可能性があるため、非常に迅速に処理されます。したがって、ディスクは並列で動作することが可能です。ランダム読み込みにも同じことが言えます。大量のシーケンシャルな読み込みと書き込みの場合は、それほど単純ではありません。しかし、シーケンシャルな I/O パフォーマンスも向上することが確認されています。たとえば、多くの I/O 要求を生成するアプリケーションでは、単一のディスクコントローラに集中することがあります。ストライピングボリュームのディスクすべてで専用のコントローラを使用している場合、このような集中は起こりにくく、パフォーマンスが向上します。
ソフトウェアとハードウェアのどちらの RAID 管理デバイスでも、RAID を実装することができます。それぞれの方法には利点と欠点があります。
- 一般にハードウェア RAID では、ハードウェアに実装されているため、高パフォーマンスが得られる。それにより、ソフトウェア RAID に比べて処理のオーバーヘッドが少なくて済む。さらに、ハードウェア RAID はホストシステムから分離されているため、アプリケーションを実行するためのホストリソースを消費しないで済む
- 一般にハードウェア RAID は、ソフトウェア RAID に比べて高価
- ソフトウェア RAID は、ハードウェア RAID に比べて柔軟性が高い。たとえば、通常、ハードウェア RAID マネージャは単一のディスクアレイや指定されたディスクアレイのセットと関連付けられている。一方、ソフトウェア RAID では、任意の個数のディスクアレイや、必要ならばアレイ内の特定のディスクだけをカプセル化できる
次の節では、レベルとして知られている RAID 設定について説明します。もっともよく使用される RAID レベルは 0、1、1+0、および 5 であり、これらについて詳細を説明しますが、あまり使用されないレベルについては比較と対照だけの対象とします。
RAID 0、ストライピングボリューム
ストライピングでは、データを複数の物理ディスクに分散します。論理ディスクや論理ボリュームは、チャンク (まとまり) やストライプ (しま状) に分割され、ラウンドロビン方式で物理ディスク上に分散されます。ストライプは常に 1 つ以上のディスクブロックから成り、すべてのストライプは同じサイズになります。
RAID 0 という名前は、冗長性がないことと矛盾しています。RAID 0 のストライプでディスク障害が発生すると、論理ボリューム全体が失われてしまいます。ただし、RAID 0 はすべての RAID レベルの中でもっとも安価であり、すべてのディスクをデータ専用にします。
RAID 1、ミラーボリューム
ミラーの目的は冗長性を実現することです。ミラー内のディスクの 1 つがエラーになっても、データは利用可能なままであり、処理を継続することができます。各物理ディスクがミラーされるため、物理ディスク容量の半分がミラー用に当てられてしまうのが欠点です。
RAID 1+0
RAID 10 とも呼ばれます。RAID 1+0 では、高レベルのパフォーマンスと回復力を備えています。その結果、RAID レベルの中では実装にもっとも費用がかかります。障害を起こしたすべてのディスクで別のミラーを作っている限り、最高で 3 ディスクが障害を起こしてもデータは利用可能なままです。RAID 1+0 はセグメントが RAID 1 であるストライピングアレイとして実装されます。
RAID 0+1
RAID 0+1 は RAID 1+0 に比べると回復力の点で劣っています。ストライプは作成されるとミラーされます。ミラーの同じ側にある 1 つ以上のディスクで障害が起きても、データは利用可能なままです。ただし、その後でミラーの別の側にあるディスクが障害を起こすと、論理ボリュームは失われます。RAID 1+0 とのわずかな違いは、RAID 1+0 では、どちらの側のディスクが同時に障害を起こしても、データが利用可能なままであるという点です。RAID 0+0 はセグメントが RAID 0 であるミラーアレイとして実装されます。
RAID 5
RAID 5 にはミラーリングのような回復力はありませんが、それにもかかわらず、単一ディスクが障害を起こしてもデータは利用可能なままであるという、冗長性を備えています。RAID 5 では冗長性を実現するために、論理エクスクルーシブを実行して作成されたパリティストライプや、ほかのディスク上で対応するストライプのバイトにあるパリティストライプを使用します。1 つのディスクが障害を起こすと、そのディスクのデータは、残りのディスクにある対応するストライプのデータとパリティを使用して、もう一度計算されます。ただし、このような補正計算を実行する必要がある場合は、パフォーマンスに影響します。
通常の運用では、RAID 5 は RAID 0、1+0、および 0+1 に比べてパフォーマンスが低いのが普通です。RAID 5 ボリュームでは論理書き込みのたびに 4 回の物理 I/O 操作を実行する必要があります。古いデータとパリティーが読み込まれ、エクスクルーシブまたは操作が 2 回実行され、そして新しいデータとパリティが書き込まれます。読み込み操作では、同じ負荷はかからないため、同数のディスクを使用した標準的なストライプの場合と比べてもパフォーマンスがわずかに低下するだけです。つまり RAID 5 ボリュームでは、パリティ専用のディスク容量があるため、ストライプ内には事実上 1 つ少ないディスクがあることになります。RAID 5 では利用可能なディスク容量以上をデータに使用するため、RAID 5 ボリュームは RAID 1+0 や 0+1 と比べて一般的に安価であるということです。
パフォーマンスの問題から、データが読み取り専用でない限り、またはボリュームへの書き込みが非常に少ない場合を除いて、通常は RAID 5 をお勧めしません。ただし、書き込みキャッシュと高速なエクスクルーシブまたは論理エンジンを備えたディスクアレイでは、パフォーマンスの問題を緩和することができ、導入によっては RAID 5 が安価な、ミラーに代わる実現可能な代替策となります。
RAID レベル 2、3、および 4
RAID レベル 2 および 3 は、ビデオストリーミングのように、大量のデータがシーケンシャルに転送される場合に適しています。どちらのレベルでも、1 度に I/O 操作は 1 回だけ処理可能で、ランダムアクセスを要求するアプリケーションには向いていません。RAID 2 はハミングエラー訂正コーディング (ECC) を使用して実装されます。3 つの物理ディスクドライブに ECC データを格納する必要があり、RAID 5 よりも高価ですが、ストライプが 3 つより多くのディスクで構成されている場合は RAID 1+0 より安価になります。RAID 3 ではビットワイズパリティ方法を使用して冗長性を実現しています。パリティは、RAID 5 のようには分散されませんが、単一の専用ディスクに書き込まれます。
RAID 2 や RAID 3 とは異なり、RAID 4 では複数のディスクドライブに同時にアクセス可能な独立アクセス技術を使用しています。RAID 5 に似た方法でパリティを使用しますが、パリティが単一ディスクに書き込まれる点が異なります。そのため、書き込みごとにパリティディスクにアクセスされるため、パリティディスクがボトルネックとなり、事実上、複数の書き込みが直列処理されています。
ソフトウェアのボリュームマネージャ
SolarisTM Volume Manager のようなボリュームマネージャは、Directory Server のディスク管理でも使用できます。Solaris Volume Manager は、実際の運用環境への導入において、その他のソフトウェアのボリュームマネージャと好意的に比較されています。
I/O およびディスク使用の監視
通常の運用環境で、ディスクをいっぱいにしないでください。潜在的な I/O ボトルネックを分離するには、Solaris システムやその他のシステムにおける iostat (1M) などのユーティリティを使用することもできます。Windows システムの I/O ボトルネックへの対応方法の詳細は、Windows ヘルプを参照してください。
マルチプロセッサシステムのサイジング
Directory Server ソフトウェアは、複数のプロセッサ間でスケールされるように最適化されています。一般に、プロセッサを追加すると、全体的な検索、インデックスの保守、およびレプリケーションパフォーマンスが向上します。
しかし、特定のディレクトリの導入では、プロセッサを追加してもパフォーマンスが大幅に改善しない効果がなくなる点に達していることがあります。検索、インデックス、およびレプリカで多大に要求されるパフォーマンス要件を扱うときは、解決策の一部として、負荷分散やディレクトリプロキシなどの技術を検討します。
ネットワークキャパシティのサイジング
Directory Server はネットワークを集中利用するアプリケーションです。Directory Server インスタンスでネットワークの可用性を向上させるには、システムにネットワークインタフェースを 2 つ以上搭載します。Directory Server ではそのようなハードウェア設定をサポートしており、同一プロセス内の複数のネットワークインタフェースで待機します。
負荷分散のために、同じネットワーク上でディレクトリサーバーをクラスタにする場合は、新たに生じる負荷がネットワークインフラストラクチャで対応できることを確認します。更新率の高いレプリケーションを WAN 環境でサポートする場合は、経験テストを通じて、ネットワーク品質と帯域幅がレプリケーションのスループット要件を満たすことを確認します。
SSL 用のサイジング
ソフトウェアには、Secure Sockets Layer (SSL) プロトコルがデフォルトで実装されています。ソフトウェアベースの SSL 実装を使用すると、Directory Server パフォーマンスに重大な悪影響を及ぼすことがあります。SSL モードでディレクトリを実行するには、全体のパフォーマンス要件を満たすために、複数のディレクトリのレプリカの導入が必要な場合があります。
ハードウェアアクセラレータカードでは SSL を使用する影響を取り除くことはできませんが、ソフトウェアベースの実装の場合と比べてパフォーマンスが大幅に改善されます。Sun ONE Directory Server 5.2 では、サポートされている Sun Crypto Accelerator ハードウェアのような SSL ハードウェアアクセラレータを使用できます。
Sun Crypto Accelerator ボードの使用は、SSL 鍵計算がボトルネックになっている場合に有効です。ただし、SSL 鍵計算がボトルネックでない場合には、そのようなハードウェアを使用しても、パフォーマンスの改善は望めません。ハードウェアが実際に加速するのは、接続確立時の SSL ハンドシェイク中に行われる鍵計算の処理であり、接続確立後のメッセージの暗号化や復号化の処理ではないからです。このようなハードウェアを Directory Server インスタンスで使用する手順は、付録 B 「Sun Crypto Accelerator ボードの使用」を参照してください。