 |
||
|
|
目次
ホワイト ペーパー：Cisco Unity 4.0の物理ストレージのベスト プラクティス（Microsoft Exchange対応）
Cisco Unity、SQL Server、およびExchangeのデータベースに関する情報
ハードウェアRAIDとソフトウェアRAIDの比較に関する情報
ホワイト ペーパー：Cisco Unity 4.0の物理ストレージのベスト プラクティス（Microsoft Exchange対応）
2004年9月7日改訂
この文書では、RAID（Redundant Array of Independent Disks）を使用したCisco Unityバージョン4.0およびCisco Unity Bridgeバージョン3.0の物理ストレージおよびディスク構成について、推奨されるベスト プラクティスを説明します。この文書は、ハードウェアの購入と導入を計画する際に使用してください。
この文書では、Microsoft Windows 2000やMicrosoft SQL Serverのインストール、またはRAIDに関するベンダー固有の設定については説明していません。
目次
RAIDストレージ レベルの選択
ベスト プラクティス- Cisco Unityで使用できる各種のハードウェア ベースのRAIDストレージについて調査します。
- RAID構成の選択は、システムの規模と保存およびアクセスするデータのタイプに基づいて行います。Cisco Unity、Microsoft Exchange、およびSQL Serverのトランザクション ログのパフォーマンス、データの完全性、および信頼性を最大限に高めるには、RAID 1を使用します。Cisco Unityデータのパフォーマンス、データ ストレージ、およびアクセス容量を最大限に高めるには、RAID 1またはRAID 10を使用します。
Cisco Unityのストレージの設定
Cisco Unityの各種RAID構成とディスク ボリュームの詳細を次の図に示しています。
システム規模の定義
表1に、図1および図2で使用されているシステム規模のラベルと次の製品がサポートするプラットフォームとの対応関係を示します。
小規模システムとは、ユニファイド メッセージングのユーザ数が499人、ポート数が16個までのシステムです。中規模システムとは、ユニファイド メッセージングのユーザ数が2,500人、ポート数が48個までのシステムです。大規模システムとは、ユニファイド メッセージングのユーザ数が7,500人、ポート数が72個までのシステムです。
表1に示すとおり、Cisco MCSプラットフォームの一部のモデルでは、Cisco Unityで2つのエンタープライズ コミュニケーション構成（ECS1とECS2）を使用できます。これらのマス ストレージ構成は、バイナリ、トランザクション ログ、およびデータベースをそれぞれ専用のRAIDアレイに分離することによって、プラットフォームの入出力のパフォーマンスを最適化するように設計されています。
ECS1プラットフォームは、音声メッセージングのみを展開するために最適化されています。大容量のハード ドライブとRAID構成を備え、Cisco Unityサーバでのメッセージの保存をサポートします。ECS1プラットフォームは通常、3つのRAID 1アレイか、または2つのRAID 1アレイと1つのRAID 10アレイを備えています。
ECS2プラットフォームは、ユニファイド メッセージングまたは音声メッセージングを展開するために最適化され、メッセージは独立したサーバに保存されます。ECS2プラットフォームは、2台のRAID 1ハード ドライブを備えています。これはオフボックスのメッセージ ストレージに対応した低コストの構成です。
サポートされているプラットフォームの最新の一覧表については、『Cisco Unity Supported Platforms List』をご覧ください。
http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_data_sheets_list.html
RAIDストレージ レベルに関する情報
Cisco Unityシステムのデータ ストレージ構成を選定するには、組織のデータ ストレージ要件を満たすRAIDレベルを特定する必要があります。
RAID 0
RAID 0では、データが等サイズのブロックに分割され、ドライブ セット全体に順次書き込まれます。これをデータ ストライピングといいます。
RAID 0では、I/O負荷がディスク間で均等に共有されるので、単一のドライブを使用する場合に比べてランダムI/Oアプリケーションのパフォーマンスが向上します。ただし、RAID 0はデータの冗長性を備えていないので、データを保護するには頻繁なバックアップ スケジュールを厳格に遵守する必要があります。
RAID 0はフォールトトレラントではなく、障害の発生したドライブからデータを復元する方法がないため、Cisco UnityではRAID 0を実装しないことを推奨します。
RAID 1
RAID 1は、ディスクのミラーリングによって信頼性の高いデータ保護を実現します。ここでは、すべてのデータが2台一組のディスクのそれぞれに1回ずつ、合計2回書き込まれます。読み取りは一組のドライブのいずれか一方から行われます。
1台のディスクに障害が発生しても、RAIDコントローラによって障害を起こしたディスクの交換、残りのディスクの情報を使用したデータの復旧、および再ミラーリングが可能です。その間、Cisco Unity、Exchange、Windows、およびSQL Serverは稼働し続けます。
RAID 1は、あらゆるRAIDレベルの中で最高のフォールトトレランスを実現できますが、使用するストレージ容量も最大になります。通常なら1台のディスクに格納するデータ量に対して2台のディスクが必要だからです。
RAID 1構成はスケーラブルであり、あらゆる規模のCisco Unityシステムで問題なく使用できます。RAID 1では偶数台のディスクが必要で、最小構成では2台一組のディスクを使用します。
一部の文献では、プライマリ ディスクとミラー ディスクを別々のRAIDコントローラに接続してフォールトトレランスを高めることが推奨されています。Cisco Unityでは、お客様の必要に応じてそうした構成を使用することも可能です。
RAID 4
RAID 4では、ディスク アレイでのデータ ストライピングを使用しますが、パリティ情報を保存する専用のディスクが追加されます。ディスク障害が発生した場合は、専用ディスク上のパリティ情報を使用してデータの復旧が行われます。
RAID 4のストライプ サイズは、レコード全体を格納できる大きさであり、多数の同時読み取りを行うアプリケーションに適していますが、複数のデータベース更新を同時に実行するCisco Unityのようなデータベース アプリケーションでは、他のRAID構成に比べて効率が低下します。そのため、Cisco UnityでRAID 4を使用することは推奨できません。
RAID 5
RAID 5は、ディスク アレイでストライプ セットとパリティを使用することによって、信頼性の高いデータ保護を実現します。パリティを使用する構成では、データがブロックに細分化され、パリティの計算が行われ、次にストライプのデータが各ディスク ドライブに書き込まれます。ドライブごとに1つのストライプがパリティ情報用に予約され、パリティは常に関連付けられたデータとは異なるドライブに書き込まれます。
RAID 5を使用してデータベースで読み取り動作を行うと、1つのI/Oが発生します。それに対して書き込みを行った場合は、4つのI/O動作（以前のパリティ情報の読み取りと以前のデータの読み取り、次に新しいデータの書き込みと新しいパリティ情報の書き込み）が発生します。
RAID 5アレイでは、単一のディスクに障害が発生しても、障害を起こしたディスク上のデータは他のディスク上のストライピングされたパリティ情報から復元できます。ただし、あるドライブが失われると、そこに格納されていたデータとパリティ情報にアクセスできなくなるため、データベースの読み取りおよび書き込みのパフォーマンスが低下し、障害を起こしたドライブが復旧するまで回復しません。障害を起こしたディスクへの読み取りまたは書き込みを要求するたびに、そのパリティ グループに属する他のすべてのドライブに対して検証プロセスが起動されるからです。最初に障害を起こしたディスクを交換してデータを復旧する前に2台めのディスク障害が発生した場合は、2台めのディスクのデータが失われます。この問題は、ホット スペアを用意することで緩和できます（詳細については、「オンライン スペア ドライブ」を参照してください)。
RAID 5では、1つのアレイに3台以上のディスクが必要です。RAID 5では最大32台のディスクを1セットにして使用できますが、それは推奨できません。1つのアレイ内のディスク数が増加すると、いずれかのディスクで障害が発生する確率も増加するからです。Cisco Unityシステムでは、1セットあたり3～5台のディスクの使用を推奨します。
RAID 5はRAID 1よりも安価に実装できます。RAID 5では、余分に必要なディスクはアレイあたり1台だけです。これは、フォールトトレランスを実現するためにあらゆるRAIDレベルで必要な、最小のストレージ容量です。読み取り動作の多い環境では（特に読み取りの割合が90%を超える場合）、RAID 5が使用可能で、他のRAID構成よりも低コストで実装できます。そのため、コストが重要な考慮事項となる特定の構成では、Cisco Unityのプライマリ データ ストアとしてRAID 1よりもRAID 5を推奨します。
RAID 0 + 1
RAID 0 + 1は、RAID 0とRAID 1を組み合わせて機能します。データは、2セットのRAID 0ドライブで構成されたRAID 1アレイ全体に同時にストライピングされます。
RAID 0 + 1は単一のディスク障害に対してフォールトトレラントですが、同一アレイ内で同時に2台のディスクに障害が発生すると、データが失われる可能性があります。ディスク障害からの復旧はパフォーマンスに重大な影響を与えます。残りのミラー内のすべてのディスクが、損傷したストライプ セットの復元に関与するからです。そのため、RAID 0 + 1を使用してCisco Unityを展開することは推奨できません。
RAID 10
RAID 10もRAID 0とRAID 1を組み合わせたものですが、RAID 1ディスクとRAID 0のスパニングを使用して機能します。データは1つのRAID 1ドライブ セット全体にストライピングされ、次に別のRAID 1ドライブ セットにミラーリングされます。各書き込み動作では、データをミラーリングするために2つの物理I/O動作が行われます。この方式によって、RAID 1ドライブ セットのミラーリングによるデータ保護を実現しながら、同時にRAID 0アレイの効率的なデータ分散を可能にします。
RAID 10システムで1台のディスクに障害が発生した場合は、コントローラによって残りのストライプ セットへの切り替えが行われます。通常、システムが障害を起こしたディスクのデータを交換ディスク上に復元している間、システムのパフォーマンスが顕著に低下することはありません。RAID 10は、複数のディスク障害の同時発生に対してフォールトトレラントです（ディスク障害が複数発生しても、それらが同一ミラー内のディスクでないかぎり、データが失われることはありません）。復旧はドライブおよびミラーを交換するだけで済み、その間、アレイの他のディスクは機能し続けます。
物理ディスクの数が同じなら、RAID 10はRAID 5の4倍の速度で動作します。ディスク ドライブの数が増えると、I/Oの能力も正比例して増加します。読み取り動作はプライマリ ドライブでもミラー ディスクでも実行できるので、I/Oの増加とともに複数の読み取り動作を同時に実行する頻度が増し、ドライブ セットは全体として高速になります。
ExchangeがCisco Unityサーバにインストールされていない場合は、すべてのディスクをRAID 1で構成することを推奨します。ExchangeがCisco Unityサーバにインストールされている場合は、最初の2つのディスク アレイをRAID 1で構成し、3つめのディスク アレイをRAID 10で構成することを推奨します。
オンライン スペア ドライブ
ホット スペアとも呼ばれるオンライン スペア ドライブによって、システムのフォールトトレランスを一層強化できます。オンライン スペア ドライブは、RAID 1アレイとRAID 5アレイの両方に追加できます。1台のドライブに障害が発生すると、RAIDコントローラによって、ただちに障害の起きたドライブのデータの復元が開始され、オンライン スペア ドライブに格納されます。また、RAIDコントローラは新しいデータについては直接オンライン スペア ドライブに保存するため、システムのI/Oパフォーマンスに対する復旧動作の影響は最小限に抑えられます。
RAIDコントローラの設定
ベスト プラクティス- RAIDコントローラが1つだけの場合は、データベース ドライブのリード キャッシュではなく、トランザクション ログのライト キャッシュを有効にします。シスコが提供しているサーバでは、ライト キャッシュが無効になっていることに注意してください。
- Cisco UnityサーバでUninterruptible Power Supply（UPS;無停電電源装置）を使用します。
RAIDコントローラに関する情報
ほとんどのRAIDコントローラは、リード キャッシュ、ライト キャッシュ、またはその両方をサポートするように設定できます。コントローラの設定ではリード キャッシュとライト キャッシュの比率を50:50にするのが一般的で、これはCisco Unityにも適しています。
RAID 5を使用する場合、ライト キャッシュによって処理のオーバーヘッドの増加を抑制できます。ただし、ディスクの速度は、書き込み時の負荷に対応できる必要があります。書き込みトランザクションの数がディスクでサポートできる数を超えた場合、ライト キャッシュは発生し、読み取り動作の速度も影響を受けます。
ライト キャッシュ ディスク コントローラを使用すると、SQL Serverのパフォーマンスも向上します。ただし、そのためにはコントローラとディスク サブシステムが、データ クリティカルなトランザクションRelational Database Management System（RDBMS;リレーショナル データベース管理システム）環境での使用を想定した、特別な設計となっている必要があります（Cisco Unityシステムで使用する前に、この点をハードウェア ベンダーに確認してください）。シスコが提供しているサーバでは、ライト キャッシュがデフォルトで無効になっていることに注意してください。
ページ書き込みトランザクションは、完全に適用されるか、または完全にロールバックされる最小の作業単位です。SQL Serverでデータ変更を行うと、2つの論理ページ書き込みトランザクションが発生します。1つはトランザクション ログ、もう1つはデータベース自体に対するものです。SQL Serverは、トランザクション ログに対してほとんど即座に書き込みを行いますが、データベースへの書き込みトランザクションを収集し、管理するために独自のキャッシュ バッファ システムを使用します。トランザクション ログへの書き込みはデータベースへの書き込みの前に発生するため、トランザクション ログは先行書き込みログと呼ばれることもあります。ライト キャッシュを実行するRAIDコントローラは、SQL Serverのページ書き込みトランザクションを中断させ、それらをハードウェア キャッシュにバッファしてページ書き込みを管理することにより、ディスクのパフォーマンスを最大限に高めます。リード キャッシュとライト キャッシュの比率を調整する場合、単一のパーティションを使用する構成ではライト キャッシュが100%になるように設定します。
リード キャッシュは通常、多数のシーケンシャル読み取りを実行するアプリケーションで使用します。リード キャッシュは、Cisco Unityのようなランダム リード アプリケーションでは何のメリットもありません。
データベースの最適化
すべてのシステムに適用できるベスト プラクティス- トランザクション ログとデータベース ファイルを別々のディスクに物理的に分離します。
- トランザクション ログ専用に高性能のディスクを割り当てます。
- データベースには専用のボリュームを使用します。これはRAID 5のパーティションでは特に重要です。
- 1台のディスクをまるごとページファイル専用に割り当てる必要はありません。ページファイルはオペレーティング システムのドライブで問題なく機能し、Cisco Unityサーバの場合はシステム ドライブに置いておく必要があります。ページファイルを別の場所に移動する場合は、オペレーティング システムのクラッシュ ダンプ機能を維持するために第2のページファイルを作成します。
- Exchangeデータベースのパーティションには、常にFATではなくNTFSを使用します。これには、情報ストア データベースとトランザクション ログを格納したパーティションが含まれます。
- 低遅延を保つために十分な数のディスク ドライブを使用します。
- トランザクション ログ ファイルに使用するすべてのディスクに、トランザクション ログの通常の書き込み動作だけでなく、それに加えて発生する読み取りにも対応できるI/O処理能力があることを確認します。
- SQL Serverデータベースでは圧縮ファイルを使用しません。圧縮ファイルはサポートされていません。
- Temp.dbデータベースは、ほとんどの場合、データと同じ場所に置くことができます。
- 新しいドライブをディスク アドミニストレータでフォーマットするときは、アロケーション ユニット サイズとして64 KBを使用します。
- トランザクション ログを専用のミラーに移動してから、Exchangeをバックアップします。
- システム バックアップの際にフル バックアップを実行しない場合は、循環ロギングをオンにします。常にフル バックアップを実行する場合は、循環ロギングをオフにして柔軟なバックアップ スケジュールを設定できます。循環ロギングの詳細については、「Exchangeでの循環ロギング」を参照してください。
Cisco Unityサーバ（Active Directory、Exchange Directory、Exchange Information Store、ローカルのCisco Unityサーバに関連付けられたExchangeメールボックス、SQL Server、およびSystem Stateを含む）のバックアップは、データ ファイルまたはログ ファイルと同一のディスクには保存しないようにします。可能な場合、バックアップにはネットワーク上の他の場所を使用します。
Cisco Unityサーバのバックアップの詳細については、『Cisco Unity Maintenance Guide 』の「Backing Up and Restoring a Cisco Unity System」の章を参照してください。
http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_maintenance_guides_list.html
Cisco Unity、SQL Server、およびExchangeのデータベースに関する情報
データベースの概要
Exchangeの情報ストアは、2つの個別のデータベースで構成されています。プライベート情報ストアは、新規インストールの際にPriv.edbとして作成され、ユーザ メールボックス内のデータが格納されます。パブリック情報ストアは、新規インストールの際にPub.edbとして作成され、パブリック フォルダ内のデータが格納されます。これらのデータベース ファイルのアクセス パターンは、ランダム読み取りが約60%、ランダム書き込みが約40%です。
データベース ファイルの基本単位は、データベース ページです。SQL ServerのほとんどのI/O処理は、データベース ページのレベルで行われます。各データベース ページのサイズは8 KBです。1つのエクステントは8つの連続するページからなり、SQL Serverオブジェクト（テーブルやインデックスなど）のアロケーション ユニットとなります。NTFSのアロケーション ユニットは256ページで構成され、ストレージの単位としては最大です。
読み取りはアプリケーション プロセスによって行われ、複数の読み取りをデータベースに対して直接同時に実行できます。書き込みは、アプリケーションがデータベースに対して直接行うわけではありません。書き込みはキャッシュに送られ、次に独立したバックグラウンドのデータベース プロセスによって実行されます。このプロセスは、新しいデータの追加や不要なデータの削除を行います。書き込み動作は通常、トランザクション ログ ページについては連続的に発生し、他のタイプのデータについては非同期バッチとして定期的に実行されます。
トランザクション ログ ファイルは一連のファイルで構成され、メモリ内のデータがディスクに書き込まれたあとだけでなく、書き込まれる前にも、それらのデータに対するセーフティ ネットとなります。データベースに変更が加えられると、トランザクションのレコードがトランザクション ログに書き込まれるため、そのトランザクションはシステム障害が発生した場合でも再実行できます。トランザクション ログ ファイルのサイズは限られており、ファイルが最大サイズに達すると、Exchangeによって新しいログ ファイルへの切り替えが行われ、追跡できるようにジェネレーション番号が割り当てられます。
データベース システム
Online Transaction Processing（OLTP;オンライン トランザクション処理）システムには、大量のデータが格納されます。新しいレコードが恒常的に追加され、データは多数のユーザによって同時にアクセスされます。I/O動作は通常、トランザクション ログを除くと書き込みよりも読み取りの割合が大きくなります。データベース ロックの時間が短いため、ロックの競合はあまり発生しません。Cisco UnityシステムでのOLTPデータ アクセスの例としては、Cisco Unity Administratorを使用した加入者情報の検索、呼処理、メッセージ通知、配信リストの使用、およびCisco Unity AssistantとCisco Unity Inboxの使用などがあります（バージョン3.1以前では、Cisco Unity AssistantはActiveAssistant[AA]と呼ばれ、Cisco Unity InboxはVisual Messaging Interface[VMI]と呼ばれていました）。
Decision Support System（DSS;意思決定支援システム）では、OLTPシステムから収集されたデータが格納され、複数の同時クエリーが処理されます。DSSシステムのI/O動作は大部分がデータベースのランダム読み取りで占められ、複雑または長大なクエリーの場合は長時間のデータベース ロックが発生します。Cisco UnityシステムでのDSSデータ アクセスは、レポートを実行する際に発生します。
シーケンシャルI/OとランダムI/O
I/Oタスクの実行に要する時間は、そのタスクがランダムまたはシーケンシャルのどちらであるかによって変わります。ランダムI/Oは、シーケンシャルI/Oに比べて完了するまでの時間が長くなります。ランダムI/Oの実行で費やされる時間の大部分はシーク時間、つまりディスクのさまざまな部分にあるデータの検索にかかる時間だからです。Windowsのパフォーマンス モニタは、1秒間に生成されるI/O動作の数を測定するのに役立つ場合もありますが、フォールトトレランスによって生成されるI/Oの追加分はカウントできません（書き込み数はRAID 1またはRAID 10使用時は2倍、RAID 5使用時は4倍）。
シーケンシャルI/Oはパフォーマンスに優れています。データがハード ディスク盤全体に分散して非シーケンシャルな位置にある場合は、ハード ディスクがディスク アームを移動させる時間（シーク時間）、およびリード/ライト ヘッドを回転させてデータの位置付けを行う時間（回転待ち時間）がかなり長くなります。データがハード ディスク盤の1つの連続した物理セクションに並んでいる場合は、ディスク アームとリード/ライト ヘッドは最小限の移動量で必要なディスクI/Oを実行できます。ほとんどのハード ディスクで、シーケンシャル動作を処理するパフォーマンスは、非シーケンシャル動作を処理する場合に比べて2倍になります。
シーケンシャルI/Oでは、9 GBのディスク ドライブで目立った遅延効果なしに毎秒200 I/Oを実行することが可能です。一方、テストの結果によると、ランダムI/O動作には毎秒75～80 I/Oの上限を設定する必要があります。
64 KBのデータの読み取りまたは書き込みに要する時間と、8 KBのデータの読み取りまたは書き込みに要する時間はほぼ同じなので、転送バイト数を大きくした方が有利です。SQL Serverのインデックス ページのデータ サイズは8 KBです。ログ マネージャは、可能な場合は常に32 KB単位でシーケンシャル書き込みを実行します。大量のデータを検索する必要がある場合、SQL Serverは64 KB I/Oで先読みを実行します。
RAIDコントローラは、データの読み取りおよび書き込みを16～128 KBのスライスに分割し、RAIDアレイを構成しているすべてのディスクに分散します。物理ドライブ全体にデータを分散すると、作業負荷が均等に分配され、I/Oのパフォーマンスが向上します。I/Oを不均等に分配すると一部のディスクがボトルネックになるのに対して、全ディスクの駆動状態が均等化されるためです。
シーケンシャル アクセス データの分離
3つのデータベース動作、トランザクション ログの書き込み、データベースに対するバルク アップデート、およびバッチ レポートは、主としてシーケンシャルになります。Cisco Unityシステムでは、トランザクション ログがシーケンシャルI/O動作の大部分を占めます。たとえば、Microsoft SQL Serverのトランザクション ログでは、I/Oはほぼすべてシーケンシャル書き込みなので、専用のディスク ドライブ セット上に分離することも考えられます。そうすれば、トランザクション ログ ファイルを格納したディスクは効率的にトランザクション ログの書き込み動作を実行でき、他の非シーケンシャルなI/O要求によって中断されることはありません。
トランザクション ログはかなりのサイズまで拡張する場合がありますが、1つの物理ディスク全体を排他的に使用する必要はなく、あまり使用されない他のファイルとディスク スペースを共有できます。
Cisco Unityの加入者データベースに対するバルク アップデートは、通常、システムを最初に設定したときに実行され、その後は使用率の低い時間帯に実行されるように計画できます。バッチ レポートも使用率の低い時間帯に実行されるようにスケジューリングできます。したがって、バルク アップデートとバッチ レポートは、Cisco UnityシステムでシーケンシャルI/Oを分割するうえで重要な考慮事項ではありません。
Exchangeでの循環ロギング
Exchange 5.5とExchange 2000では、データがJetデータベースに保存されます。カレント トランザクションは、ほとんどがEdb.logファイルに保存されます。Edb.logファイルのサイズが5 MBに達すると、Exchangeはファイル内の最も古いトランザクションがデータベースに対してコミット済みになっているかどうかを確認します。コミット済みになっていれば、それらの古いトランザクションは新しいトランザクションで上書きされるため、Edb.logファイルのサイズが5 MBを超えることはありません。ただし、Exchangeはデータベースに対してコミットされていないトランザクションは一切上書きしません。このプロセスを循環ロギングといいます。循環ロギングが有効になっている場合は、Exchangeのフル バックアップが必要です。
循環ロギングが無効になっているときにEdb.logファイルのサイズが5 MBに達した場合は、Exchangeによって同じ名前の新しいログ ファイルが作成され、アクティブでなくなったファイルは名前が変更されます。ログ ファイルの数はトランザクションのロギング数が増えるにしたがって増加し、システムはバックアップが完了するまで新しいログ ファイルの作成を続けます。循環ロギングを無効にした場合は、Exchangeのバックアップを実行する必要があります。放置するとトランザクション ログによってディスクが満杯になる恐れがあります。バックアップ スケジュールを設定して定期的にフル バックアップを行い、その他の期間は常に増分バックアップを行うという方式を推奨します。
Exchangeのバックアップを行わない場合は、循環ロギングを無効にしないでください。循環ロギングを無効にする場合は、継続してバックアップを実行し、何らかの理由でバックアップを停止することがないようにする必要があります。バックアップを行わなければ、トランザクション ログによってハード ディスクが満杯になる恐れがあります。ディスクが満杯になるとExchangeの機能が停止し、さらにCisco Unityの機能も停止する可能性があります。
RAIDタイプの選択
ベスト プラクティス
ハードウェアRAIDのみを使用します。ソフトウェアRAIDは、Cisco Unityシステムでは使用できません。
ハードウェアRAIDとソフトウェアRAIDの比較に関する情報
ソフトウェア ベースのRAID実装に比べてハードウェア ベースのRAID実装には利点が多く、このことはハードウェアRAIDがCisco Unityの実装方式になっている理由を理解するうえで重要です。
ソフトウェア ベースのRAIDは、オペレーティング システムとアプリケーション固有のコンポーネントが必要なため複雑であり、処理や保守に対するオーバーヘッドが増加します。ソフトウェアRAIDエンジンは、すべてのI/O要求を処理し、CPUリソースをアプリケーション コンポーネントと共有する必要があります。データ処理および物理メモリとのデータ転送が増加するため、大量のCPUリソースが消費され、システム パフォーマンスが低下する恐れがあります。
ハードウェア ベースのRAIDは、オペレーティング システムやアプリケーションから完全に独立しています。RAIDファームウェアは固有の専用プロセッサで実行されるので、アプリケーションCPUを共有する必要はありません。これにより、アプリケーションCPUでアプリケーション動作を実行しながら、RAIDアレイ アダプタのプロセッサでディスクI/Oとフォールトトレランスを同時に管理することが可能になります。RAIDのハードウェアまたはファームウェアで異常が発生しても、通常、アプリケーションCPUは動作を継続でき、システム管理者には異常を通知します。Cisco Unityサーバが不測の事態のためにクラッシュした場合でも、ハードウェア ベースのRAIDでは、加入者データとトランザクション データはミラーリングやパリティを使用して保護され、失われることはありません。RAIDバッテリ バックアップ モジュールはキャッシュの一貫性を維持し、未処理の操作を完了します。
上記の理由から、ソフトウェアRAIDはCisco Unityシステムではサポートされていません。
システムの容量およびパフォーマンスの計画
ベスト プラクティス- 余裕のある規模にします。システムの規模の決定については、『Cisco Unity Supported Platforms List』を参照してください。
http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_data_sheets_list.html - ディスクの空き容量とデータベースの拡張速度を継続的に監視します。
- Cisco Unity CPUでの1秒あたりのコンテキスト スイッチ回数、および1秒あたりのプロセッサ割り込み発生回数を監視し、システム パフォーマンスのボトルネックになる要因を調べるうえでの指標とします。
- ディスク キューの値を2未満に保つようにします。
- SQL Serverのトランザクション ログは、自動拡張に設定します。ただし、拡張する必要のないサイズにします。
- ユーザあたりのストレージ割り当ては20～30分に指定し、管理します。Cisco Unityはコーデックに依存しています。コーデックに伴うストレージへの影響の詳細については、『White Paper:Audio Codecs and Cisco Unity』を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/whitpapr/codecs.htm - Exchangeはアクティブ パーティションにはインストールしません。アクティブ パーティションが満杯になった場合、Windows 2000とCisco Unityが動作できなくなります。
データベースの計画に関する情報
ディスクのフラグメンテーション
ハード ディスクへのメモリ ページングの影響を抑制するため、Cisco Unityボリュームでのフラグメンテーションを定期的にチェックします。フラグメンテーションの合計が10%を超えているか、またはCisco Unityのファイルで過度なフラグメンテーション（500を超えるフラグメント）が発生している場合は、そのボリュームでデフラグを実行することを推奨します。
トランザクション ログのサイズ決定
最適なサイズは、復旧方式、ロギングされるデータベース動作のレベル、および定期バックアップの間隔に基づいて決まります。トランザクション ログが頻繁に拡張する場合、パフォーマンスに影響が出る可能性があります。
ディスク容量の80%以上が占有されると、パフォーマンスは大幅に低下します。ディスクが満杯になると、データベースが拡張できなくなり、Cisco Unityは停止します。
信頼性の計画
Cisco Unityシステムでは、コストが大幅に増加するだけで、信頼性をそれほど向上させないものもあります。たとえば、Cisco UnityのAdapter Fault Toleranceモードでは冗長NICを使用することができます。またRAIDコントローラに冗長電源装置を装備することも可能です。しかし、冗長RAIDコントローラは多くの場合、高価なわりに信頼性があまり向上しないので、装備するに値しません。
ログおよびファイルの移動
データベース計画の一部として、現在ページング ファイルを格納しているディスクよりも高速の新しいRAID 1アレイを導入して、Windowsのページング ファイルを移動できます。また、SQLまたはMSDEデータベースとトランザクション ログを移動することもできます。Cisco UnityデータベースとReportsデータベースを再配置する場合、両データベースを同時に移動する必要はありません。
Cisco Unityのトレース ログとUnity Messaging Repository（UMR）も再配置できます。トレース ログ、UnityMta（ストレージ）、およびFailed（配信不能メッセージ）ディレクトリを移動する場合、トレース ログとUMRを同時に移動する必要はありません。
Cisco Unityのデータベース、ログ、およびファイルの再配置の詳細については、『Cisco Unity Installation Guide』 Release 4.0(4)の「Preparing for the Installation」の章にある「Determining the Drive Locations for Files on the Cisco Unity System」を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity40/inst/inst404/ex/index.htm
データ ストア データベースとトランザクション ログ ファイルの移動方法については、『Cisco Unity Installation Guide』 Release 4.0(4)の「Installing and Configuring Cisco Unity Software」の章にある「Moving the Data Store Databases and Transaction Log Files」を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity40/inst/inst404/ex/index.htm
SQL Serverデータベースの移動の詳細については、Microsoftのサポート技術情報（Microsoft Knowledge Base）の文書番号224071を参照してください。Exchange 2000データベースの移動の詳細については、Microsoftのサポート技術情報の文書番号257184および155761を参照してください。いずれかのタイプのデータベースを移動するにあたって、その他の情報が必要な場合は、TACにご連絡ください。
SANの使用
Storage Area Network（SAN;ストレージ エリア ネットワーク）は、ネットワーク アプリケーションおよびデータに対応したフォールトトレラント ストレージの一つです。SANソリューションは通常、ストレージのデータ容量の要件が5テラバイトを超えるような、非常に大規模なネットワークで使用します。SANは通常、ファイバ チャネルとファイバ スイッチを使用してアプリケーション サーバに接続し、既知の各種攻撃に耐えられる独立したネットワークで中央集中型のデータ ストレージを実現します。またSANでは、バックアップと復元を簡単に管理でき、バックアップ トラフィックをデータ ネットワークから分離できます。コストに見合う効果が得られる場合は、SANは複数のRAIDアレイでスケーラビリティを拡張できます。
Cisco Unityシステムでは、このようなレベルのストレージ容量は必要ありません。SANはアクティブ/アクティブExchangeクラスタを構成する一部の実装で使用できますが、Cisco Unityで使用する場合に推奨されるSANのパフォーマンスと規模については、このホワイト ペーパーの対象範囲外です。
またCisco.comには、シスコのストレージ ルータを使用してSANの実装を補完する方法について、お役に立つ参考資料が多数ございます。
その他の参考資料
一般に受け入れられるRAIDレベルを定義し、ユーザを教育するため、1992年にRAID Advisory Boardが設立されました。RAID Advisory Boardでは、ベンダーとユーザ双方にとってのリソースとなるWebサイトを運営しています。
