Caché 高可用性ソリューション

Caché HA ソリューションにおける問題

Caché システムに有効な HA ソリューションを評価するときには、以下に示す 2 つの重要な問題について注意してください。

• 共有ストレージ

  HA アーキテクチャの重要な原則は、単一障害点を排除することです。ほとんどの HA ソリューションは、共有ストレージ・コンポーネントに依存しています。これは、ストレージに障害が発生すると、システムの可用性を維持することが不可能になるというリスクを意味しています。ストレージ・レベルの冗長性により、このリスクをある程度は軽減できますが、ある種のデータ破損を持ち越す可能性があります。

  これに対して、Caché ミラーリングでは、プライマリとバックアップの完全に独立したストレージ間で論理的なデータ・レプリケーションを使用します。これにより、単一障害点の問題を完全に排除し、ほとんどの種類のデータ破損を持ち越すことを回避しています。

  ミラーリング以外のソリューションを使用しているときには、単一のストレージの障害が深刻な状況につながる可能性があります。このことから、このような手法には、ディスクの冗長化、データベースのジャーナリング ("Caché データ整合性ガイド" の “ジャーナリング” の章を参照)、および適切なバックアップ手順 ("Caché データ整合性ガイド" の “バックアップとリストア” の章を参照) を組み合わせる必要があります。こうした対応が、ディスクの障害による影響を軽減するうえで重要になります。

• Caché のアップグレード

  多くの HA ソリューションは、全体的な可用性を損なうことなく、特定のコンポーネント・システムの計画的ダウン・タイムに対応できます。ただし、プロダクションの Caché インスタンスをアップグレードするには、かなりのダウン・タイムが必要になります。

  ただし、Caché ミラーリングでは、アプリケーション・データとは別のデータベースにアプリケーション・コード、クラス、およびルーチンを保持していれば、最小のダウンタイムで Caché をアップグレードできます。詳細は、"Caché インストール ガイド" の “Caché のアップグレード” の章にある "ミラーリングを使用した最小ダウンタイムのアップグレード" を参照してください。

  そのため、ミラーリング以外の HA ソリューションでは、Caché のアップグレードや Caché のシャットダウンが必要になるメンテナンスのためのダウン・タイム・ウィンドウについて、慎重な計画の策定が必要になります。

HA ソリューションを配備しない場合

Caché データベースの構造的な整合性と論理的な整合性は、ライト・イメージ・ジャーナリング、データベース・ジャーナリング、およびトランザクション処理といった組み込みの機能によって、常にプロダクション・システムの障害から保護されています。これらの機能の詳細は、"Caché データ整合性ガイド" の “データ整合性の概要” の章を参照してください。しかし、HA ソリューションを配備していないと、障害の原因や、原因の特定および解決の能力によっては、多大なダウン・タイムを招くことがあります。業務上それほど重要ではない多くのアプリケーションでは、このリスクは許容できるかもしれません。

この方法を採用するお客様は、以下の特質を備えています。

• ジャーナリングやバックアップとリストアなどの明確で詳細な運用面のリカバリ手順。

• ディスクの冗長性 (RAID やディスク・ミラーリング)。

• ハードウェアをすばやく入れ替えることができる能力。

• すべてのベンダとの年中無休のメンテナンス契約。

• 障害に起因して発生するある程度のダウンタイムに対する管理上の受容とアプリケーション・ユーザの許容。

OS レベルのクラスタ HA

HA を実現する手法として広く使用されているものにフェイルオーバー・クラスタがあります。この手法では、共有ストレージおよびアクティブなメンバをフォローするクラスタ IP アドレスを使用し、プライマリ・プロダクション・システムを (一般的に同じ構成の) スタンバイ・システムで補完します。プロダクション・システムに障害が発生すると、スタンバイ・システムがプロダクションの作業負荷を引き受けて、障害が発生したプライマリ・システムでそれまで実行されていた Caché などのプログラムとサービスを引き継ぎます。

Caché は、Microsoft Windows Server Clusters、IBM PowerHA SystemMirror、Red Hat Enterprise Linux HA など、オペレーティング・システム・レベルで提供されるフェイルオーバー・ソリューションと簡単に統合できるように設計されています。共有ストレージ・デバイスに Caché のインスタンスを 1 つだけインストールして、両方のクラスタ・メンバでそのインスタンスを認識するようにします。続いて、このインスタンスをフェイルオーバー・クラスタ構成に追加して、フェイルオーバーの構成要素として自動的に起動するようにします。アクティブ・ノードを使用できない期間が指定の時間数に達すると、クラスタ IP アドレスと共有ストレージのコントロールがフェイルオーバー・テクノロジによってスタンバイ・システムに移管され、新しいプライマリ・システムで Caché が再起動します。ここで再起動するシステムでは、通常の起動リカバリが自動的に実行され、WIJ、ジャーナリング、およびトランザクション処理によって、障害が発生したシステム上で Caché が再起動した場合とまったく同様に構造上の整合性とデータの整合性が維持されます。

スタンバイ・サーバには、障害が発生したプライマリ・システムがリストアされるまでの間、通常のプロダクション作業負荷を処理できる能力が必要です。スタンバイ・システムがプライマリ・システムになって、障害からリストアされたプライマリ・システムがスタンバイ・システムになる構成も可能です。

この手法では、共有ストレージ・デバイスに障害が発生すると深刻な状況となります。このことから、十分なリカバリ機能を実現するうえで、ディスクの冗長化、ジャーナリング、およびバックアップとリストアの良好な手順がきわめて重要です。

仮想化プラットフォーム HA

仮想化プラットフォームには、一般に HA 機能が備わっています。多くの場合、その HA 機能でゲスト・オペレーティング・システムと、それを実行しているハードウェアの両方の状態を監視します。そのどちらかに障害が発生すると、仮想化プラットフォームは障害が発生した仮想マシンを自動的に再起動します。必要に応じて、代替のハードウェア上で再起動することもあります。Caché インスタンスは、再起動時に通常のスタートアップ・リカバリを自動的に実行し、物理サーバで Caché が再起動された場合とまったく同じように構造的な整合性と論理的な整合性が維持されます。

仮想化 HA は、仮想化プラットフォームのインフラストラクチャに組み込まれているため、非常にわずかな作業で構成できる (構成作業がまったく必要ないこともある) という利点があります。さらに、仮想化プラットフォームでは、仮想マシンをメンテナンス目的で代替のハードウェアに計画的に再配置することもできます。これにより、例えば、物理サーバのアップグレードをダウン・タイムなしで実行できます。

Caché ミラーリング

自動フェイルオーバーを備えた Caché ミラーリングは、HA に別の手法を採用しています。この手法では、完全に独立したシステム間での論理的なデータ・レプリケーションによって、共有ストレージにおける単一障害点のリスクを回避し、ほとんどすべて (システム、ストレージ、およびネットワーク) の障害シナリオで、プロダクションは即座に代替の Caché インスタンスにフェイルオーバーできるようになります。

Caché ミラーでは、プライマリ・フェイルオーバー・メンバと呼ばれる 1 つの Caché インスタンスがプロダクション・データベースへのアクセスを提供します。別のホスト上のバックアップ・フェイルオーバー・メンバと呼ばれるもう 1 つのインスタンスは、プライマリと同期的に通信して、プライマリのジャーナル・レコードを取得し、レコードの受信を通知し、そのレコードを同じデータベースのバックアップ側専用のコピーに適用します。この方法では、バックアップがプライマリから最新のジャーナル・ファイルを受け取っているかどうかについて、プライマリとバックアップの両方が常に認識しているため、バックアップとプライマリのデータベースを正確に同期できるようになります。

これにより、プライマリが停止したときに、ミラーはデータを損失することなく、すばやく自動的にバックアップにフェイルオーバーできます。3 番目のシステム (アービター) は、プライマリが応答しなくなったときに、バックアップによる引き継ぎが必要かどうかの判断を支援します。フェイルオーバー・メンバが共有する仮想 IP アドレスや Caché ECP などのメカニズムにより、アプリケーションの接続は新しいプライマリにリダイレクトされます。フェイルオーバー・プロセスはわずか数秒で完了するため、このプロセスに気付くユーザはほとんどいないでしょう。また、バックアップは専用のデータベースのコピーを保持しているため、プライマリとプライマリのストレージに全体的な障害が発生しても、データベースが利用不可の状態になることはありません。実際、バックアップが最新のジャーナル・データを得られなかったとしても、バックアップのミラー・エージェントは、プライマリのホストがオンラインであれば、そのホストからジャーナル・データを取得できます。

フェイルオーバー後に、以前のプライマリを稼働状態にリストアすると、そのプライマリはバックアップになり、そのデータベースは新しいプライマリのデータベースに合わせて同期され、ミラーは完全な HA 機能を取り戻します。その後で、それぞれのシステムを元の役割に戻すことも、新しい配置を維持することもできます。

ミラーには、災害復旧 (DR) 非同期メンバを含めることもできます。このメンバには、プライマリのコピーが非同期的に維持されます。DR 非同期はフェイルオーバー・メンバに昇格させることができます。例えば、障害が発生したプライマリを短時間で稼働状態にリストアできないときや、(物理的に分離されている場合は) データ・センタの障害などで両方のフェイルオーバー・メンバがダウンする停止状態からの災害復旧の際には、DR 非同期がバックアップになります。最後に、ミラーにはレポート非同期メンバを含めることができます。このメンバは、ビジネス・インテリジェンスおよびデータ・ウェアハウジングを目的としたプロダクション・データベースの非同期コピーを維持します。

ミラーリングは、仮想化プラットフォーム HA と併用することで、ハイブリッド型 HA の手法を作成することもできます。この手法では、システム・レベルまたは OS レベルで発生する計画外の停止に仮想化プラットフォームで対応し、計画的なすべての停止と計画外のデータベースの停止 (Caché の停止とストレージの障害の両方を含む) には、自動フェイルオーバーを通じたミラーリングで対処します。

Caché ミラーリング (DR 機能を含む) の詳細は、"Caché 高可用性ガイド" の “ミラーリング” の章を参照してください。

HA ソリューションの機能の比較

以下の表では、HA ソリューションのミラーリング、クラスタリング、および仮想化について、大まかな機能を比較しています。

* アプリケーション・データを格納するデータベースとは別のデータベースに、アプリケーション・コード、クラス、およびルーチンが保持される構成が必要になります。

フェイルオーバーを伴う ECP の使用

どの手法を HA に採用するかにかかわらず、エンタープライズ・キャッシュ・プロトコル (ECP) を使用すると、ユーザとデータベース・サーバを分離するレイヤを用意できます。データベース・サーバに障害が発生しても、ユーザ側では ECP アプリケーション・サーバとの接続が維持されます。この停止の間にデータベースに頻繁にアクセスするユーザ・セッションと自動トランザクションは、フェイルオーバーの完了または障害が発生したシステムの再起動によってデータベース・サーバが再び利用可能になるまで一時停止状態になります。

ただし、HA の方策に ECP を追加することでシステムが複雑になり、新たな障害点が発生する可能性のある点に注意してください。

ECP の機能と実装の詳細は、"Caché 高可用性ガイド" の “ECP および高可用性” の章、および "Caché 分散データ管理ガイド" を参照してください。