ディスクテクノロジー

ハードディスクは、データ記憶域のベーシスにあり、 R/3 システムの単一要因で引き起こされる致命的な障害を、概念的に示します。ディスクバックアップスキーム( データベースキー問題のデータベースバックアップ、および回復のセクションで説明されるデータベースバックアップを含む)は、最小限のデータ可用性要件しか供給しません。 R/3 システムのディスクデータは、より有意に利用できるように作成する必要があります。このセクションでは、 R/3 システム環境におけるディスクの可用性を向上するのに有効な、適切なディスクテクノロジーの概要および実用的なガイドラインを説明します。

適切な解決方法についての詳細は、ハードウェア購入先に問い合わせすることをお奨めします。この領域は複雑で、この文書における情報は R/3 システムを対象として書かれてますが、一般論でしかないためです。

R/3 システムデータ高可用性の必要性

“ディスクハードウェアクラッシュの後、業務上許容できる R/3 システムデータ可用性の最低条件は何か”という本質的な質問に答える必要があります。

高可用性要件がほとんど求められない場合には、ディスク障害の後でバックアップから R/3 システムデータベースを回復させるのに、予期しないダウンタイムを利用することが可能な場合があります。以下のステップを考慮する必要があります。

復元および回復操作は、データベースのサイズと可能なバックアップの品質によって決まります(たとえば、トランザクションログデータの再実行は、最新バックアップを使用するより時間がかかります)。

より正確な可用性を必要とするインストールでは、オンラインデータの冗長性に2つの異なるレベルが認識されます。

ディスクドライブ上の単一要因による障害が発生しても、データはオンライン状態のままで、完全に利用可能です。これは、障害が発生した時に使用できるようデータの補足コピーが連続的に更新されていることを示します。

2つの異なるディスク障害が発生しても、データはオンライン状態のままで、完全に利用可能です。つまり、データの補足コピーが2つ連続的に更新されていることを示します。

大規模なデータベース特有の問題(データベースのバックアップまたは復元に非常に長い時間がかかる、など)を、ディスクの冗長性の2つのレベルを使用して多少なりとも解決することができます。バックアップはより簡単になり、復元にかかる時間が削減されます。

ダウンタイムを避ける必要がある場合、2つのレベルの冗長性を使用します。

非常に繊細なアプリケーションでは、ディスクに2つのレベルの冗長性を移行してください(3つの方法のミラーリングなど、下記参照)。

パフォーマンスおよび高可用性ディスクシステムの費用

データの高可用性のためにシステムパフォーマンスが犠牲にされることは、ほとんどありません。ただし、高可用性の要件は冗長性を伴うため、データはチェックまたは複数回のディスクへの書き込み、あるいはその両方が必要になります。高可用性環境でのパフォーマンスを更新するには、以下に関して基本ハードウェアの改善を考慮する必要があります。

費用に関係なくディスクシステムの高可用性を考慮する

通常、ハードウェアのアップグレードに必要な費用は、確実に払い戻されます。システムが使用できなくなった場合には、必要とする収益の損失、サポートおよびサービスのために費用がかかることに留意してください。

障害の発生したシナリオのデータ可用性

高可用性のために品質を弁別する上で重要なことは、障害発生時に何が起こるかということです。処理を続行するためデータの残余部分にアクセスする必要がある場合、高可用性環境にあるディスクシステムはどのように反応するのかを説明します(ソフトウェアおよびハードウェアに関して)。

以下の点で、ディスクハードウェアそのものまたはホストマシン CPU 、あるいはその両方で作業ロードが重くなるため、障害発生時にはオンラインパフォーマンスが低下するのは避けられません。

使用するディスクテクノロジーの種類によって、パフォーマンスが低下する期間が予想されます。高可用性の目的のためには不適切なディスク装置を選ぶと、許容不可能なパフォーマンスの低下のため、障害発生時にデータにアクセスできなくなります。

これは、ある障害が発生すると同時に、データ消失の危険性が増加する冗長性の1つのレベルのディスクシステムに共通した特徴であることに注意してください。これは、主に以下の理由から生じます。

平均故障間隔

ハードディスクの基本特性は、“平均故障間隔”( MTBF )で時間単位で表わされます(通常、 100,000 時間 = 11 年)。これは、ディスク装置の操作に故障が発生するまでの平均統計時間です。たとえば、ディスク装置の MTBF 50 年と仮定します。このディスク装置が 25 ある会社ではおおよそ2年ごとに1つのディスクに故障が発生します。統計的にみて、ある特定のディスクが最初の週で故障することはないと、確実には保証されていません。つまり、統計によって、そのようなことが起こる可能性が比較的低いということが分かっているだけです。

ディスクスピンドル自身の MTBF とエンティティとして使われるディスクシステムの MTBF に、重大な差異が生じる場合があることに注意してください。ディスク装置には、完全に故障する可能性のあるコンポーネントが多く含まれています。たとえば、多くのディスク装置に複数のディスクスピンドルが含まれています( JBOD および RAID システム)。この場合、装置の有効 MTBF の合計は、おおよそ配列のスピンドル数に比例して下がります。

所与の装置に特定されている MTBF 値は、通常、純ハードウェアクラッシュの統計から計算されます。しかし実際には、データの非可用性はこの統計に含まれないさらに複雑な問題から生じる場合があります。したがって、 MTBF は純ハードウェア障害許容力と比較するガイドラインとしてのみ機能します。

高可用性の獲得

ディスクシステムの各サブコンポーネントは故障する可能性があるので、ここでは最大システム可用性の獲得の仕方について説明します。一般的に、高可用性は、ハードウェアおよびデータの冗長性によって獲得されます(この場合ソフトウェアはデータとみなされます)。

ハードウェアアスペクトのガイドとして、以下のことを考慮します。

冗長データストレージには2つの基本方法があります。

下記のディスクベースコンポーネントは、 R/3 システムの可用性にとって重要です。コンポーネントが読み込み、または書き込みのどちらを主とするかによって、データ保護に適切な方法を選択する必要があります(下記説明参照)。

R/3 システム(通常読み込み中心)

DBMS (読み込み中心)

DBMS ログファイル(書き込み中心)

− オペレーティングシステム(読み込み中心)

− オペレーティングシステムスワップ領域(書き込み中心)

冗長データストレージとハードウェアアスペクトのそれぞれの構造の利点および欠点については、下記で詳細に説明されます。

高可用性ディスクテクノロジーの一般オプション

高可用性ディスクシステムにデータを冗長して保存する主なテクノロジーは2つあります。

これには、 RAID テクノロジー(“経済的 / 独立ディスクの冗長配列”)の全範囲が含まれます。

RAID ディスクのハードウェアエミュレートミラーリング( RAID レベル 1 、下記ダイアグラム参照)

RAID システム(レベル > 1 )のエラー修正テクノロジー(チェックビット計算)

インテリジェントディスク(コントローラ、記憶域プロセッサ、マイクロコード)は、ホストマシン CPU から独立して動作し、ディスクスピンドルの1つが故障しても装置からデータを確実にリトリーブすることができます。

これは、 OS のアドオンソフトウェア方式で、“論理ボリュームマネージャ”ソフトウェア( LVM )です。 CPU サイクルは、 LVM ソフトウェアを実行するためにホストマシンから奪われるので、データがディスク上の物理的冗長(ミラーされた)格納場所に書き込まれているか確認が必要です。基本ディスクテクノロジーは、複数の物理的に独立した(スタンドアロン)ディスクまたはハードウェアリソースを共有するディスクの配列(ディスクタワー、ラックまたはキャビネット、 JBOD )のどちらでも可能ですが、装置にインストールされたインテリジェント RAID コントローラでは不可能です。

RAID のあるハードウェア方式冗長性

RAID は、“経済的 / 独立ディスクの冗長配列”を表わします。 RAID 装置は、 OS に単一ディスクドライブとして論理的に表示される一方(つまり、ユーザ透過性)、1つの単一インテリジェントディスクコントローラと共にディスクスピンドルの配列で内部構成されます。コントローラおよびそのソフトウェア(マイクロコード)は、ディスク配列へのデータ分散、データの冗長記憶域および配列内のチェックビットの計算を処理します。 RAID 配列には、オプショナル記憶域プロセッサ( CPU )が含まれ、配列内で処理されるデータの実行を援助します。

RAID “レベル”の分類は、 Garth Gibson Randy Katz 1988 年に SIGMOD 論文の中で発表したものです。二人は、 RAID レベルを定義し、チェック情報の登録方法とディスクスピンドルにあるデータ(およびチェックビット)の分散方法を区別しました。レベル番号は、冗長性の品質、またはパフォーマンスの分類と全く関係ないことに注意してください。 R/3 システムにもっとも関連する RAID レベルの概要は、下記テーブルで示されています。

R/3 システムに関連する RAID レベル

RAID レベル 3 および 4 のあるシステムも、近年商品化されました。ただ、通常は R/3 システムのような OLTP (オンライントランザクション処理)アプリケーションソフトウェアには適しません。初期の RAID 定義に加えて、ベンダ特定レベルも紹介されています。多くのハードウェアベンダは設定可能な RAID レベルのある装置を供給するため、ディスクシステムの設定が、より柔軟になります。

RAID システムのパフォーマンス

RAID システム(ハードウェア方式冗長性)の一般的な利点は、データ記憶域がディスクハードウェアによって単独で効果的に処理されることです。データ記憶域の最適化は、配列で独立して生じるため、ホストマシン CPU に追加のオーバーヘッドはありません。

ディスク装置のパフォーマンスは、一般的に以下のファクタによって決まり、そのうちいくつかは特に RAID に関連したものです。

読み込み書き込みアクセス比率

書き込みパフォーマンスは、情報を冗長して保持するため、どのディスクシステムにおいても重要となります。これは、以下のオーバーヘッド時間によります。

したがって、読み込み書き込み比率は、高可用性ディスクシステムにおいては、特に重要です。意思決定サポートシステムは、一般に読み込み書き込み比率が大変高い(通常、ほとんど読み込み、定期バッチ更新による書き込みアクセスあり)一方、 OLTP 作業ロードの高い R/3 システムでは書き込み中心です。

RAID 5

RAID 5 の書き込み不利は、周知です。一般に、 RAID 5 パフォーマンスは、以下のようにアプリケーションの特性に影響されます。

RAID 5 の特性

アクセスモード

コメント

小規模 I/O

ランダム読込が速い(並行処理)

大規模 I/O

遅い、並行処理不可

書き込み

遅い

小規模書込

非効率、読込 - 修正 - 書込の連続が必要(ストライプを読込、該当ストライプ領域を修正、新規等価を計算、そして書込)

大規模書込

より効率的、チェックの計算後ストライプ全体の書換

読込

比較的速い(並行処理)、小規模ランダムチャンクでは最速

所与の R/3 システムで中心となるアクセスモードのタイプは、システムのセットアップ方法によって決まり、一般のタームでは決められません。ただし、書込中心環境では、 RAID 5 のパフォーマンスは落ちることに注意してください。

RAID 0 および 1, RAID 10

ストライピング(純ストライピングは RAID 0 )は、効果的に、並行アクセスし、同時 I/O によって読み込みおよび書込の速度が速くなります。小規模 I/O を効率よく処理することができます。ただし、 RAID 0 だけは冗長性を備えておらず、高可用性設定にはなりません。ストライピングは RAID 5 でも使用されることに注意してください。

RAID 1 (ハードウェアミラーリング)の読み込みパフォーマンスは、ミラーのどちら側から読み込んでも増加可能です。このパフォーマンスは、 RAID 0 との組み合わせでさらに増加することができ、そうなると RAID 1/0 または RAID 10 (ストライプされたミラーリング)と呼ばれます。導入が簡単なため( RAID 5 と比較して)、 RAID 10 はより強固なテクノロジーです。ミラーリングにはディスク領域が2倍必要なので、スピンドルの費用が 100% 増加することが主な欠点です。 RAID 10 は、 RAID 5 と比較すると、パフォーマンスの利点が、ほとんどの読込 / 書込環境で生まれますが、行われたインストールにおいて具体的な OLTP ベンチマークでパフォーマンスを確かめる必要があります。

書込キャッシュのある RAID

書込キャッシュは、 RAID 配列で生じた書込不利を埋め合わせるのに適した方法です。これは、 RAID 装置により、キャッシュからディスクへのデータ書込が引き継がれるため、ホストマシン CPU はデータの受け入れのための書込キャッシュのみが必要になるという理由によります。大規模書き込みキャッシュにより、書きみ込不利は完全に避けられます。キャッシュは、致命的で、かつ単一要因が引き起こされる障害になる場合があることに注意してください。キャッシュの詳細については、下記を参照してください。

RAID の障害シナリオ

障害発生時に、ディスクシステムの高可用性解決策としてパフォーマンスの低下が予測されます。以下のポイントは、 RAID システムに特有のものです。

コントローラおよびマイクロコード

コントローラおよびそのマイクロコードのタスクは、チェック情報の登録または配列のディスクスピンドルにわたるデータとチェックビットの分散、あるいはその両方となります。ハードウェアおよびソフトウェアの両方とも、きわめて重要な単一要因が引き起こす障害であることはあきらかです。マイクロコードとハードウェア間における設定不整合および非互換性は、不慮の問題および危険性を引き起こす可能性があります。このような内部の複雑さのため、 RAID 5 では、マイクロコードの問題が生じる傾向がありますが、一方この点に関しては、 RAID 1 および 10 には問題はありません。

RAID マイクロコードのアップグレード時に、本稼動ではないシステム使用よるテスト

RAID マイクロコードをアップグレードする必要がある場合、最初に、重要でないディスクの内容でパフォーマンスおよび確実性をチェックすることを強く推奨します。事前にチェックをせず、本稼動 R/3 システムでマイクロコードを更新すると、重要なデータを危険にさらすことになります。

RAID の要約

このセクションでは、 RAID システムの利点および欠点の概要、および RAID がどのような時に利点となるかについて説明します。

− ハードウェアが CPU から独立して作業するので、ホストマシンオーバーヘッドが存在しない

− 大規模理論記憶域容量( RAID でも JBOD でも、一般にディスク配列についても同様

− ホットスピンドルスワッピングが可能。

− 柔軟性のある設定

− 読込中心環境における高いパフォーマンスの可能性

− 有効なメガバイトごとの財務費用は、 RAID 5 が、冗長性のない場合に比べると、少しだけ高くなります

RAID 10 のパフォーマンス向上

RAID 5 の書き込み不利

RAID 5 I/O 仕様に依存するパフォーマンス

− きわめて少ないパフォーマンス調整に対するデータ配置への制御

− マイクロコードは、致命的で、かつ単一要因で引き起こされる障害である

RAID は、以下の状況で有効な解決策になります。

LVM のあるソフトウェア方式冗長性

LVM (“論理ボリュームマネージャ”)を使用したソフトウェア方式ミラーリングによるスタンドアロンディスクの使用は、主に RAID システムを使用したハードウェア方式冗長性と競合するものです。

ソフトウェアミラーリングのディスク装置

LVM で使用されるディスク装置には、2つの主なタイプがあります。

このスタンドアロンディスク装置には、コントローラ、独自の SCSI インタフェース、電源装置などがあります。各スタンドアロンディスクは、物理的に別個の装置です。

これは、データ I/O を処理するため1つのラック、電源装置および標準ディスクコントローラ( RAID に類似したコントローラの代用)を共有する複数のディスクの配列を使用します。装置全体への物理 SCSI パスは1つだけです。このため、 SLED に対比して、 JBOD には合計記憶域容量に関して高い限界値が提供されています。このような装置は、外部からはスタンドアロンディスクとしてとらわれています。

LVM のあるソフトウェアミラーリング

LVM (論理ボリュームマネージャ)ソフトウェアは、通常オペレーティングシステムへのアドオンまたはその一部として存在します。これにより、複数の分散ハードウェアディスクまたは分割、あるいはその両方の一般アドレス領域が提供されます。ミラーリングに使用される場合、ソフトウェアは単一論理ボリューム(ファイルシステムまたはローデバイスのどちらでも可能)とユーザおよびアプリケーションに透過性の方法での複数物理コピー( LVM RAID 5 に類似した設定もあるが、一般的には CPU 中心)を関連付けます。商業関連データベースシステムは、 LVM ソフトウェアをサポートします。

ミラーディスクシステムの2つ(または3つ)のミラーコピーは、物理的に独立した(異なるスタンドアロンディスクまたは少なくとも配列上の異なるスピンドル)ディスクスピンドルに配置してください。データのコピーを含むディスク(またはディスク全体)のセクターが故障した場合でも、データは(他のディスクの)他のコピーによってアクセス可能です。

ミラーリングに必要でなくても、 LVM ソフトウェアは装置への冗長 SCSI パスを処理することができます(1つのパスに障害が発生しても冗長パスに切り替えられます)。高可用性のために、この機能を利用することを推奨します。

LVM のパフォーマンス

LVM の欠点の1つは、オペレーティングシステムの一部としてホストマシンから CPU サイクルが奪われてしまうことです。これは、 CPU オーバーヘッドが含まれない RAID などのハードウェア方式冗長性解決策に対比するものです。ミラーリングモードでは、 LVM によりオペレーティングシステムが指示され、物理的にデータが記憶域媒体に2回(または3つの方法のミラーリングでは3回)送信されます。パフォーマンス全体の低下は、数パーセント程度のみと言われています。つまり、 LVM オーバーヘッドは、 CPU 限界域まで達した場合以外には、 R/3 システムに大きな影響を与えません。

LVM RAID と同様)では、パフォーマンスの低下は読込書込比率によって決まり、下記のように書込中心アプリケーションでは、パフォーマンスに重要な低下を引き起こします。

LVM RAID 0 同様)データをストライプするよう設定できるので、改善されたパフォーマンスのためディスクアクセスを並行処理することができます。これは、作業が複数の独立ディスクコントローラまたは異なるディスクを取り付けた異なる SCSI チャネル、あるいはその両方にストライプできる場合、特に有効です。ストライピングによって利点を得るアプリケーションには、多数のランダムアクセスおよび多量の順次読込 / 書込があります( LVM のバージョンにより多量の I/O 要求を内部で並行処理することが可能な場合)。また、並行アクセスできる異なるディスクに大規模データベーステーブルのあるアプリケーションも、通常ストライピングによって利点を得ます。

LVM を使用した3つの方法のミラーリング

LVM ソフトウェアは、通常2つの方法のミラーリングで設定され、1つのレベルの冗長性解決策を提供(1つのディスク障害は許容可能)しますが、3つの方法のミラーリング(1つの元データと2つのデータ冗長コピー)で設定することもできます。2つのディスク障害が許容可能なので、結果は2つのレベルの冗長性です。この設定は、高可用性要件が非常に厳しい R/3 システムで使用でき、以下の操作モードが可能になります。

2つの同時ディスク障害が許容できるので(2つのレベルの冗長性)冗長性は単一ディスク障害の後でも損失されません。

R/3 システムは、バックアップ中、1つのレベルの冗長性によって完全にオンラインのままとなります(1つの追加ディスク障害がバックアップ期間中許容されたまま)。

LVM での3つの方法のミラーリングは、操作をほとんど中断せずに、オフラインデータベースバックアップするために使用されます。 DBMS は、 ORACLE のバックアップで述べられたように一時的にシャットダウンしなければなりません。バックアップを行うには、3番目のミラーコピーがバックアップのために分割され、残りの2つのコピーへの標準データベースサービスの続行を可能にします。3つの方法のミラーリングは、最高のデータ可用性を提供しますが、パフォーマンスおよび財務費用に関しては最も不経済な方法です。 CPU パフォーマンスへの関連するインパクトとともに、データをディスクに合計3回書き込む必要があります。記憶域のメガバイトごとの費用は、標準ディスク領域の3倍必要とするので、3つのファクターによって約3倍に増加します。

3つの方法のミラーリングは、数少ないオプションの1つで、常にトランザクション処理ロードが重い超大規模 R/3 システムデータベース( VLDB )の許容期間内にバックアップを実行します。

LVM の障害シナリオ

故障したディスクまたは論理ボリュームが置換された後、 LVM はミラーを再同期化する必要があります。 CPU パフォーマンスへの直接の影響は少ないのですが、故障した論理ボリュームの I/O は全て必然的に障害となります。 R/3 システムデータが高度に統合されているので、この状況ではパフォーマンス全体の低下が予想されます。 RAID の問題はホストマシンではなくディスク配列にあり障害中の実行も妨害されるという点で LVM RAID と類似しています。

現行の LVM ベースディスクシステムの欠点は、ホットディスクスワッピングが一般的に RAID のようにサポートされていないことです。ホストマシンを完全にシャットダウンする必要がない場合でも、通常 R/3 システムは、ディスク置換中、休止状態にしなければなりません。 LVM とホットスワッピングメカニズムをエミュレートするためにミラーの各側にホットスペアスピンドルの設定が可能な場合があります。自動スワッピングは、 LVM 設定でほとんどサポートされません。

LVM の要約

このセクションでは、 LVM がどのような時に利点となるかについて、更に LVM システムの利点および欠点の概要について説明します。

− 2つまたは3つの方法のミラーリングが可能

− データがオンラインに正常パフォーマンスで留まる一方で(3つの方法のミラーリングが使用されている場合は追加冗長)、1つのミラーを分割することによりバックアップが可能

− 各ディスクにそれぞれハードウェアコンポーネント一式があり(コンポーネント障害が1つのディスクにしか影響しない)、さらにハードウェア冗長性がある

− パフォーマンス調整のためのデータ配置への物理的な総合制御がある

− 複数の独立ディスクコントローラ、障害なし、同時 I/O 可能、単一要因で引き起こされる障害なし

LVM 読み込み、ミラーのどちらの側からも読み込めるのでパフォーマンスが向上

− ストライピング可能、つまり異なるデータチャネルまたはディスクの同時 I/O 可能

− ホストマシン CPU オーバーヘッドにより、わずか数パーセントではあるが LVM は原則的に、パフォーマンスの低下を引き起こす

LVM 書き込み、オペレーティングシステムがディスクにデータを複数回送信する必要があるので、パフォーマンスは低下する

SLED が使用される場合( JBOD は容量を増やすために使用可能)各スタンドアロンディスクは、1つの SCSI ターゲットアドレスを使用し、バスの合計容量は制限される

− 故障したディスクの置換が不便な場合、必要に応じて R/3 システムをシャットダウンする必要もある。

− スワップされたディスクがサービスに戻る場合、より多くの管理作業が必要になる( RAID と比較して)

− 2倍のディスクスピンドルが使用されるため( SLED では 100% 費用が増加、 JBOD ではそれより少ない) MB ごとのハードウェア費用が増加する

LVM は、以下の状況で有効な解決策になります。

ソフトウェア方式冗長性またはハードウェア方式冗長性

ソフトウェア方式( LVM )かハードウェア方式( RAID )のどちらの冗長性を使用するか決定することは難しく、各ユーザのインストールの詳細によって決まります。

どちらか選択する前にインストールを詳しく分析

この文書では、ソフトウェアまたはハードウェアのどちらの冗長性がインストールに適当かという指針のみを説明します。ハードウェア購入先に問い合わせて、インストールの詳細についてよく相談してから決定してください。

以下に極端な例を2つ示し、関連ある諸問題を説明します。

以下の要因により、通常 Raid システムが適している( RAID 10 が最適)

− データ処理は、ディスク配列の内部にあるハードウェアによって行われる

CPU パフォーマンスは影響を受けない

− 障害が発生した場合、再構築は CPU にロードをかけない

− ディスクの置換が容易である(ディスクは“ホット”でスワップ可能)

RAID 5 は、ディスク領域の使用有効メガバイトごとの価格は安いが、書込パフォーマンスの質が低い

− 大規模書込キャッシュのある装置が適している

以下の要因により、スタンドアロンディスクの LVM ミラーリングが適切である。

CPU サイクルは LVM の犠牲となりうる。

− アウトプットを並行処理し、パフォーマンスを最大化するため、 LVM は複数のディスクにストライプされる

LVM は、ミラーのどちらの側からも読み込めるよう設定される

− 大規模書込キャッシュのある装置の使用が望ましい

− 3つの方法のミラーリングでバックアップのため3番目のミラーを分割するオプションが可能

− 障害発生時の破壊を最小にするため、ミラーの各側にホットディスクを用意しておく

LVM および RAID 5 の両方のタイプのディスク冗長性を使用するよう計画する場合、データの優勢なアクセスモード(読込中心は書込中心など)に応じてディスクテクノロジーを採用することを一般的に推奨します。上記の“高可用性達成方法”一覧を参照してください。

データが書き込みアクセスを必要とするので、一例として、トランザクションログ( ORACLE Redo ファイルまたは INFORMIX データベーススペース LOGDBS など)を LVM を使用してミラーされたディスクに配置することを推奨します。残りのデータベースデータは書込アクセスがそれ程多いと思われないので、 RAID 5 テクノロジーを使用してディスクに配置してください。

R/3 システムデータをアクセス要求に応じて分割することも可能ですが、これには R/3 システムインストール調整に関して専門的判断が必要です。詳細については、 SAP データベースインストールガイドを参照してください。

ディスク装置のキャッシュ

ディスク装置はキャッシュによって大きく精度を上げることができます。ただし、パフォーマンスの向上は、下記のように障害発生時の可用性との関連に対して調整する必要があります。

パフォーマンス向上

ディスク I/O パフォーマンスは、キャッシュを利用することで大幅に向上されます。ディスクおよび SIMM モジュール(キャッシュで使用)のアクセス時間は、要因により 100 万に至るまで(キャッシュ SIMM での 10 ナノ秒に対して、ディスクでは約 10 ミリ秒)異なります。下記のように書込および読込キャッシュが使用できます。

キャッシュを高可用性ディスクシステム向上の方法として考慮

一般的に大規模ディスクキャッシュは、高可用性ディスクシステムに見合った書込不利を埋め合わせることができます。現在、キャッシュサイズが 4 GB までのディスク装置が使用可能です。ただし、キャッシュ増加の条件付き回収は、 R/3 システム使用パターンに大きく依存します。

キャッシュでの障害シナリオ

ディスクスピンドルそのものに常に保存されていないデータがあるので、書込キャッシュには特に注意が必要です。これにより単一要因で引き起こされる障害が表示されるので、以下のように冗長性を増加する障害許容方法をとります。

読込キャッシュでは、ディスクそのものからデータを常に利用できるので、冗長性予防措置は原則として特に重要ではありません。

バスアーキテクチャ

バス速度は、ディスクスピンドルへのデータの実際書込プロセスに制限要因がある限り、パフォーマンスの妨害にはなりません。ただし、大規模キャッシュがバスアーキテクチャに対して妨害になる可能性があります。高速最新式バスアーキテクチャにより、高可用性オプションのあるディスクデータ記憶域のパフォーマンスを最大にすることができます。ただし、パフォーマンスを最大にするには、バス転送率がディスク装置内部でサポートされる必要があることに注意してください。

OS サポートが利用可能ならば、冗長バスアーキテクチャに活用

R/3 システムの高可用性解決策では、冗長バスアーキテクチャに OS サポートの利点を活用することを推奨します。たとえば、与えられたディスクに接続するため2つの独自のチャネル( SCSI パス)が存在する場合、1つのチャネルが故障した場合に2つ目のチャネルが使用されるよう、適切な OS 装置ドライバを設定することができます。 LVM 導入では、この高可用性機能がサポートされているものもあります。

以下のセクションでは、 SCSI バステクノロジーおよびファイバチャネル( FCS )テクノロジーの高可用性に関して説明します。パフォーマンスに優れた追加ベンダ指定バスアーキテクチャがあり、高可用性に適しています。ただし、標準設備には一般互換性に関して明らかに利点があることに注意してください。最適なバスアーキテクチャの詳細なアドバイスについては、ハードウェア購入先に相談してください。

SCSI

SCSI とは、“小型コンピュータ用周辺機器インタフェース”のことです。 SCSI バスアーキテクチャの重要要因には、以下のものが含まれます。

単一端と異なる SCSI バスは、電気レベルで違うことに注意してください。つまり、コネクタが同じでも、これらのシステムには互換性がなく、変換機能なしで接続されると電気的にお互いに被害を被る可能性があります。

一般的に、問題のない、バス幅 / 速度および装置接続が提供されるバステクノロジーの使用を推奨します。したがって、最大幅で最高速度の異なるバス SCSI-2 は、選択のオプションです。異なるバスにより、確実さが改善され、上記 SCSI-1 システムのノイズが減らされます。一般的に SCSI-2 も最高転送速度で実行することができます。

以下のことに注意してください。

SCSI バス停止

大規模インストールでは、通常複数の SCSI ディスク装置が取り付け可能な共有 SCSI バスを使用します。 クラスタテクノロジーを参照してください。ディスクの正しい装着は、永久 SCSI バス停止の観点から見ると、高可用性をもたらします。どの SCSI バスも、正しいバス操作を確実に行うために両端で厳密で正確に停止する必要があります。通常、ボード上の SCSI 停止は SCSI ディスク装置( SCSI コントローラ上)に直接搭載されます。ただし、これは関連するディスクが単一要因で引き起こされる障害になることを示します。ボード上のターミネータの1つを搭載するディスクを、修理またはサービスのために取り外さなければいけない場合、 SCSI バスは“オープン”または停止しないで、共有バスにある全 SCSI ディスクを使用できないようにします。

この問題は、必ず外部で SCSI バスを停止することで容易に回避できます。つまり全ディスクを Y ケーブルを介して取付け、ターミネータを装置の外側のケーブルに直接接続するのです。その後、バスのディスク装置の1つがオフラインにされても、バスは完全に操作することができます。

ファイバチャネル標準( FCS

FCS により大きくパフォーマンスを向上させることができます。 FCS ANSI 標準化高速インタフェースであり、長距離(数 km まで)に及び、 100 MB/ 秒までの転送率を維持することができます(速度および距離はハードウェアに依存)。多数の装置が接続可能で、エラー検出およびハードウェアレベルでの修正のサポートも提供されています。与えられたディスクが内部でも高速転送をサポートできる場合、このテクノロジーにより最大限の利点がもたらされます。

容量オプション

バスの装置の最大数により、 R/3 システムに直接どれだけのディスク容量を取り付けることができるかが決定されます。 FCS は、潜在的に SCSI より多くの装置をサポートすることができます。ただし、多くの場合、 CPU およびバスパフォーマンスは可能なディスクの最大数の限界を設定します。

新しくディスク設備を選ぶ時には、早い段階で容量および増加オプションを考慮することが重要です。将来増加する可能性のあるシステムをより効率よく実行すると、確実性が上り、必要に応じて容易に拡張することができます。容量を最初の段階で完全に利用したシステムは、それ以上のニーズに適応させようとすると、問題を引き起こします。

このような情況においては、ディスク配列( JBOD システムまたは RAID システム)には、数少ない SCSI チャネルで多量のディスク領域を供給する、つまり潜在的な記憶域容量が大変大きいという利点があることが特にあげられます。各ディスクが1つの SCSI チャネルを使用し、将来の増加の可能性(少なくとも仮説的なものであり、ディスクパフォーマンスがさらに厳しい制限を強要しうるため)を制限することが、単一スタンドアロンディスクの欠点となります。

ディスク置換プロシージャ

高可用性ディスクシステムでも、故障したディスクは最終的に置換しなければなりません。最終的に標準操作に戻す必要のあるサービス破壊の程度は、実にさまざまです。

障害発生時に備えて少なくとも1つのスペアディスクを保持

これは簡単な推奨にすぎませんが、障害が発生した場合に多くの時間を節約することができます。ディスクは“接続および実行”できるようにしておきます(設定は必要なし)。ただし、実際に障害が発生する前にテストしておくことをお奨めします。

以下の用語は、置換する方法を調べるために使用されます。

置換方法は、ディスク装置の基本設計によって決定されます。つまり、スワップ能力の低い装置は通常アップグレードオプションを備えていません。“ホットスワップ”機能は、ディスク領域の費用をメガバイトにつき 50% まで増加させます。ダウンタイムおよびサービス費用を削減することで回収されます。

ホットスワップを行う能力は、ディスク配列でも同じです( JBOD システムまたは RAID システムのどちらでも)。一般に、 RAID システムでは故障したディスクがホットスワップされた後で、続いて管理されることなく自動的に再同期化が開始されます。 JBOD で作動する LVM も、故障したスピンドルのホットスワップを利用しますが、アプリケーションおよび管理作業を停止する必要が生じる場合があります。 LVM 方式ミラーの場合、ディスク障害発生時に破壊を最小限にするために、ミラーの両側にホットスペアディスクを置くことをお奨めします。

ジャーナルファイルシステム( JFS

ジャーナルファイルシステム( JFS )は、障害に対する障害許容力を備え、システムクラッシュ後の起動時間を短縮し、オンラインパフォーマンスを向上させるように設計されています。

R/3 システムの高可用性に向けた JFS を考慮

障害の後で再起動する時間がかなり短縮できるため、 R/3 システムで高可用性が問題になる場合、標準ファイルシステムではなく、ジャーナルファイルシステムアーキテクチャを使用することを推奨します。これは、多くの管理タスクが容易になる他、実行時間パフォーマンスが向上する場合もあります。

システム障害(ノード電源障害など)は、クラッシュ後、ファイルシステムの不整合を引き起こす可能性があります。このため、 UNIX システムではチェックが必要であり、また破壊されている場合は、ファイルシステムを起動中に再構築しなければなりません。通常このプロシージャには、ファイルシステム全体を完全にスキャンすることが含まれ、合計ダウンタイムがかなり延長されます(特に大規模システムでは)。

JFS が明らかに優れている点は、破壊され再構築する必要のあるファイルのみ示され、起動時のチェックにアドレスされることです。ファイルシステムのチェックは、短時間で済みます。

標準システム操作でファイルにアクセスする一方、 JFS はリレーショナルデータベースシステムによって使用される REDO ログと同様の同期ログメカニズムを使用します。ファイルへの変更が含まれているメタデータは、予約された領域に書き込まれ、“コミット”の後でしか、実際のファイルに適用されません。破壊されたファイルは、システム障害が発生した後でログから再構築することができます。

JFS の内部アーキテクチャのため、メモリ領域の増加、非断片化およびバックアップなど、ファイルシステムの多くの管理タスクがオンラインで実行されます。 JFS は、より優れた実行時間パフォーマンスを提供します。これらの機能により、 JFS は高可用性要件のファイルシステムとして選択されます。

チェックリスト:ディスクシステムの単一要因で引き起こされる障害

単一要因で引き起こされる障害に備え、 R/3 システムのディスクアスペクトをチェック

R/3 システムを高可用性にするために、単一要因で引き起こされる障害をできる限り回避するようにします。 R/3 システム内の障害を引き起こす可能性のある要因を、頻度、障害による影響、および冗長性を備えるために必要な費用などの面から認識し、優先順位をつけます。最後に、決定した解決策を導入する際に、実際にどれくらい信頼性があるかを確認するためテストします。

ディスクシステムのハードウェア内で、単一要因で引き起こされる可能性のある障害には、以下のものが含まれます。

− 電源障害をアドレスする不揮発性 SIMM またはバッテリーバックアップ

SIMM 障害をアドレスするミラーされた SIMM

ディスクベースデータ内で単一要因が引き起こす可能性のある障害は、以下のとおりです。

R/3 システム

DBMS およびログファイル

− オペレーティングシステムおよびスワップ領域