| Oracle Database高可用性概要 11gリリース1（11.1） E05748-03 |
|
 戻る |
 次へ |
この章の内容は次のとおりです。
データベースとインターネットは、組織やコミュニティの隅々にまでデータベース・アプリケーションを行き渡らせ、世界的なコラボレーションと情報共有を可能にしました。こうしたデータベース・アプリケーションの浸透により、データ管理ソリューションにおける高可用性の重要性が浮き彫りになっています。小規模なビジネスもグローバルな企業も、1日24時間データにアクセスできる必要のあるユーザーを世界中に抱えています。このデータ・アクセスが行えなければ、業務は停止し、収益が失われます。ソリューションへの依存度を強めたユーザーは、情報テクノロジ（IT）部門やソリューション・プロバイダに品質保証契約を求めるようになりました。可用性は、時間と利便性のみでなく、ドル、ユーロおよび円で評価されることがますます増えています。
企業は、そのITインフラストラクチャを利用して、競争力をつけ、生産性を高め、より多くの情報に基づいてより迅速に決定を下す力をユーザーに与えてきました。しかし、こうした利点により、インフラストラクチャへの依存度はますます高まりました。重要なアプリケーションが使用できなくなった場合、ビジネスが危機に瀕します。収益や顧客が失われたり、処罰を受けたり、悪評が顧客や自社の株価にいつまでも影響を与えたりする可能性もあります。データの保護方法を決定する要因について検討し、ユーザーへの可用性を最大限に高めることが非常に重要です。
可用性は、要求に応じてアプリケーション、サービスまたは機能がどの程度使用可能であるかを表しています。可用性は、アプリケーションのエンド・ユーザーの感覚を基準に評価されます。データが使用できない場合やコンピュータ・システムが予想どおりに機能しない場合、エンド・ユーザーは不満を感じます。エンド・ユーザーがソリューション全体の複雑なコンポーネントを理解したり、区別しようと考えたりすることはありません。予想を超える使用状況が原因で発生したパフォーマンス障害は、ソリューションの重要なコンポーネントに障害が発生した場合と同じ被害をもたらします。
信頼性、リカバリ可能性、タイムリなエラー検出、および継続的稼働は、高可用性ソリューションの主な特徴です。
信頼性: 信頼できるハードウェアは高可用性ソリューションの1つの要素です。信頼できるソフトウェア（データベース、Webサーバー、アプリケーションなど）も同様に、高可用性ソリューションを実現する上で重要です。関連する特性はリジリエンスです。たとえば、低コストの汎用ハードウェアをOracle RACなどのソフトウェアと組み合せて使用すると、信頼性の高いシステムを実装できます。これは、各サーバーで障害が発生しても、Oracle RACデータベースのリジリエンスによって処理を継続できるためです。
リカバリ可能性: 障害からリカバリする方法には多くの選択肢があるため、高可用性環境で起こり得る障害のタイプ、およびビジネス要件を満たす時間内に障害からリカバリする方法を決定することが重要です。たとえば、重要な表が誤ってデータベースから削除された場合、その表をリカバリするにはどのような処置を取ればよいでしょうか。アーキテクチャには、品質保証契約（SLA）で規定された時間内にリカバリする能力があるでしょうか。
タイムリなエラー検出: アーキテクチャのコンポーネントに障害が発生した場合、予期しない障害からリカバリするには素早い検出が重要です。停止から素早くリカバリできても、問題の検出にさらに90分かかったとしたら、SLAを遵守できない可能性があります。環境の状態を監視するには、状態を素早く表示するための信頼できるソフトウェア、およびデータベース管理者に問題を通知する機能が必要です。
継続的稼働: データへの継続的なアクセスが可能です。メンテナンス・アクティビティを実行するための停止時間をほとんど、あるいはまったく許容できないという場合に不可欠です。表をデータベース内の別の場所に移動したり、ハードウェアにCPUを追加したりといったアクティビティは、高可用性アーキテクチャではエンド・ユーザーに対して透過的に行う必要があります。
より具体的に言えば、高可用性アーキテクチャは次の特徴を備えている必要があります。
中断を最小限またはゼロにして、処理が継続するように障害を許容すること
システム、データまたはアプリケーションの変更に対して透過的である（または耐性がある）こと
予防措置が組み込まれていること
障害の予防的監視と素早い検出が可能であること
素早いリカバリが可能であること
検出操作およびリカバリ操作が自動化されていること
データ損失が最小限またはゼロになるようにデータが保護されていること
運用面でのベスト・プラクティスを実施して環境を管理していること
できるかぎり安価な総所有コストでSLA（リカバリ時間（RTO）やリカバリ・ポイント（RPO）など）で設定した目標を達成すること
高可用性がどの程度重要であるかはアプリケーションによって異なります。しかし、企業がソリューションを再構築して競争力を強めるにつれて、より一層高いレベルの可用性を提供する必要性は増し続けています。ほとんどの場合、こうした新しいソリューションは重要なビジネス・データへの即時アクセスに依存しています。データが使用できない場合、業務が停止する可能性もあります。停止時間は、生産性の低下、収益の損失、カスタマ・リレーションシップの悪化、悪評および訴訟につながりかねません。
停止時間の直接のコストを試算するのは必ずしも容易ではありません。顧客の怒り、従業員の空き時間、悪評などはすべてコストに結びつきますが、通貨に直接換算することはできません。その一方で、SLAの目標が達成されないことによる収益の損失や法的処罰は容易に定量化可能です。ソリューションに依存してサービスを提供している業界では、停止時間のコストが急速に増大する可能性があります。
停止時間のコストという点で考慮が必要なその他の要因は、1回の計画外停止の最大許容時間、および許容できるインシデントの最大頻度です。イベントの継続時間が30秒未満の場合、イベントが与える影響は非常に小さく、エンド・ユーザーがイベントを感じ取ることはほとんどありません。停止時間が長くなるにつれて、その影響は著しく大きくなり、ビジネスにも悪影響を及ぼすことになります。また、停止の頻度が高くなると、停止が短時間であったとしても、同様に業務が中断する可能性があります。ソリューションを設計する場合、停止時間の実際のコストを把握して、可用性が向上することでどのように利益が得られるのかを理解することが重要です。
オラクル社では、規模に関係なくあらゆる組織に適する幅広い高可用性ソリューションを提供しています。小規模なワークグループもグローバルな企業も同様に、重要なビジネス・アプリケーションの利用範囲を拡大できます。Oracleとインターネットがあれば、いつでもどこからでも、アプリケーションおよびデータへの信頼性の高いアクセスが可能になります。
高可用性ソリューションを設計する上での課題の1つは、停止時間のあらゆる原因を検討し、対処することです。フォルト・トレラントおよびリジリエンスがあるITインフラストラクチャを設計する際、計画外停止時間と計画停止時間の両方の原因を考慮することは重要です。複数のタイムゾーンのユーザーをサポートするグローバル企業では特に、計画停止時間も同じく業務に悪影響を及ぼします。
表1-1は、計画外停止のタイプと説明、および各タイプの例を示しています。
表1-1 計画外停止時間の原因
表1-2は、計画停止のタイプと説明、および各タイプの例を示しています。
表1-2 計画停止時間の原因
| タイプ | 説明 | 例 |
|---|---|---|
|
システム変更およびデータベース変更 |
計画されたシステム変更は、日常的、周期的なメンテナンス業務および新しいデプロイメントが行われるときに発生します。 計画されたシステム変更には、データベース内の組織データ構造外で発生する計画的な業務環境への変更が含まれます。 計画されたシステム変更から受けるサービス・レベルの影響は、計画停止時間の性質および範囲、変更の実装前に行われるテストと検証作業、影響を最小化するためのテクノロジならびに機能により、大きく異なります。 |
|
|
データ変更 |
計画されたデータ変更は、Oracle Databaseオブジェクトの論理的構造または物理的組織に変更があった場合に発生します。この変更を行うのは主に、パフォーマンスまたは管理性を改善するためです。 |
|
|
アプリケーション変更 |
計画されたアプリケーション変更には、データ変更やスキーマおよびプログラムの変更などがあります。この変更を行うのは主に、パフォーマンス、管理性および機能性を改善するためです。 |
|
オラクル社では、計画外停止時間と計画停止時間の回避、および障害からのリカバリに役立つ高可用性ソリューションを提供しています。これらの高可用性ソリューションの詳細は、第2章で説明します。
可用性要件に最も適したアーキテクチャを選択し、実装するのは、きわめて困難な作業です。このアーキテクチャには次のことが求められます。
すべてのコンポーネントに冗長性を持たせること
コンピュータ障害、ストレージ障害、人的エラー、データ破損、書込み欠落、システムの停止または低速化、およびサイト障害からの保護および許容が可能であること
できるだけ素早く透過的に停止からリカバリすること
計画停止時間を排除または短縮するソリューションを提供すること
一貫した高いパフォーマンスを実現すること
デプロイ、管理および拡張が容易であること
できるかぎり安価な総所有コストでSLAを遵守すること
組織に最適なアーキテクチャを選択できるように、このマニュアルではいくつかの高可用性アーキテクチャについて説明し、要件に最も適合したアーキテクチャを選択するためのガイドラインを示します。構成と実装の詳細を理解するには、Oracle Databaseサーバー、Oracle RACおよびOracle Data Guardの用語に関する知識が必要です。
最高技術責任者と情報テクノロジ・アーキテクトには、次の章が役立ちます。
データベース管理者とネットワーク管理者にとっては、次の章の情報が有益です。
|
関連項目: 次のものに記載されているOracle高可用性ベスト・プラクティスの推奨事項を参照してください。
|
