| Oracle® Database高可用性概要 12cリリース1 (12.1) B71280-03 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
可用性は、要求に応じてアプリケーション、サービスまたは機能がどの程度使用可能であるかを表しています。可用性は、アプリケーションのユーザーの感覚を基準に評価されます。データが使用できない場合やコンピュータ・システムが予想どおりに機能しない場合、ユーザーは不満を感じます。ユーザーがソリューション全体の複雑なコンポーネントを理解したり、区別しようと考えたりすることはありません。予想を超える使用状況が原因で発生したパフォーマンス障害は、アーキテクチャの重要なコンポーネントに障害が発生した場合と同じ混乱をもたらします。ユーザーがシステムにアクセスできないことを使用不可といいます。一般的に、システムの使用不可期間は停止時間と呼ばれます。
システムをいつでも使用できる状態にしておくには、高可用性が必要です。可用性の高いシステムは、主要期間、年間を通じて毎日毎時間、割込みのない計算処理を提供するように設計されています。これは24x365と表されます。このようなシステムにも、システムのハードウェアまたはソフトウェアのアップグレードなど、計画メンテナンス操作のための高可用性ソリューションが必要です。
信頼性、リカバリ可能性、タイムリなエラー検出および継続的稼働は、高可用性ソリューションの主な特徴です。
信頼性: 信頼できるハードウェアは高可用性ソリューションの1つの要素です。信頼できるソフトウェア(データベース、Webサーバー、アプリケーションなど)も同様に、高可用性ソリューションを実現する上で重要です。関連する特性はリジリエンスです。たとえば、低コストの汎用ハードウェアをOracle Real Application Clusters(Oracle RAC)などのソフトウェアを組み合せることで、非常に信頼性の高いシステムの実装に使用できます。Oracle RACデータベースのリジリエンスが高ければ、個々のサーバーに障害が発生しても、処理は続行できます。
リカバリ能力: 障害からのリカバリには多数の方法がある場合があります。したがって、高可用性の環境でどのようなタイプの障害が発生する可能性があるかを判断し、ビジネスの要件を満たして迅速にそれらの障害からリカバリする方法を決めることが重要です。たとえば、重要な表が誤ってデータベースから削除された場合、その表をリカバリするにはどのような処置を取ればよいでしょうか。アーキテクチャには、品質保証契約(SLA)で規定された時間内にリカバリする能力があるでしょうか。
タイムリなエラー検出: アーキテクチャのコンポーネントに障害が発生した場合、予期しない障害からリカバリするには素早い検出が重要です。停止から素早くリカバリできても、問題の検出にさらに90分かかったとしたら、SLAを遵守できない可能性があります。環境の状態を監視するには、状態を素早く表示するための信頼できるソフトウェア、およびデータベース管理者に問題を通知する機能が必要です。
継続的稼働: データへの継続的なアクセスを提供することが、メンテナンス・アクティビティを実行するための停止時間をほとんど、あるいはまったく許容できないという場合に不可欠です。表をデータベース内の別の場所に移動したり、ハードウェアにCPUを追加したりといったアクティビティは、高可用性アーキテクチャではユーザーに対して透過的に行う必要があります。
より具体的に言えば、高可用性アーキテクチャは次の特徴を備えている必要があります。
中断を最小限またはゼロにして、処理が継続するように障害を許容すること
システム、データまたはアプリケーションの変更に対して透過的である(または耐性がある)こと
予防措置が組み込まれていること
障害のアクティブな監視と素早い検出が可能であること
素早いリカバリが可能であること
検出操作およびリカバリ操作が自動化されていること
データ損失を最小限に抑えるか防止するためにデータを保護すること
運用面でのベスト・プラクティスを実施して環境を管理していること
できるかぎり安価な総所有コストでSLA(リカバリ時間目標(RTO)やリカバリ・ポイント目標(RPO)など)で設定した目標を達成すること
高可用性がどの程度重要であるかはアプリケーションによって異なります。データベースとインターネットは、組織やコミュニティの隅々にまでデータベース・アプリケーションを行き渡らせ、世界的なコラボレーションと情報共有を可能にしました。こうしたデータベース・アプリケーションの浸透により、データ管理ソリューションにおける高可用性の重要性が浮き彫りになっています。中小企業もグローバルな企業も、1日24時間データへのアクセスを必要とするユーザーを世界中に抱えています。このデータ・アクセスが行えなければ、業務は停止し、収益が失われます。これらのソリューションに依存する傾向が強まったことを反映して、ユーザーは情報技術(IT)部門やソリューション提供者の品質保証契約を求めるようになりました。可用性は、時間と利便性のみでなく、ドル、ユーロおよび円で評価されることがますます増えています。
企業は、そのITインフラストラクチャを利用して、競争力を付け、生産性を高め、より多くの情報に基づいてより迅速に決定を下す力をユーザーに与えてきました。しかし、こうした利点により、インフラストラクチャへの依存度はますます高まりました。重要なアプリケーションが使用できなくなった場合、ビジネスが危機に瀕します。ビジネスの収益が減少し、違約金を被り、顧客や会社の株価に対する影響が続く悪評を呼ぶ可能性があります。
企業がソリューションを再構築して競争力を強めるにつれて、より高いレベルの可用性を提供する必要性は高まる一方です。ほとんどの場合、こうした新しいソリューションは重要なビジネス・データへの即時アクセスに依存しています。データが使用できない場合、業務が停止する可能性もあります。停止時間は、生産性の低下、収益の損失、カスタマ・リレーションシップの悪化、悪評および訴訟につながりかねません。
停止時間の直接のコストを試算するのは必ずしも容易ではありません。顧客の怒り、従業員の空き時間、悪評などはすべてコストに結び付きますが、通貨に直接換算することはできません。その一方で、SLAの目標が達成されないことによる収益の損失や法的処罰は容易に定量化可能です。ソリューションに依存してサービスを提供している業界では、停止時間のコストが急速に増大する可能性があります。
停止時間のコストという点で考慮が必要なその他の要因は、次のとおりです。
1回の計画外停止の最大許容時間
イベントの継続時間が30秒未満の場合、イベントが与える影響は非常に小さく、ユーザーがイベントを感じ取ることはほとんどありません。停止時間が長くなるにつれて、その影響は著しく大きくなり、ビジネスにも悪影響を及ぼすことになります。
許容できるインシデントの最大頻度
停止の頻度が高くなると、停止が短時間であったとしても、同様に業務が中断する可能性があります。
ソリューションを設計する場合、停止時間の実際のコストを把握して、可用性が向上することでどのように利益が得られるのかを認識することが重要です。
オラクル社では、規模に関係なくあらゆる組織に適する幅広い高可用性ソリューションを提供しています。小規模なワークグループもグローバルな企業も同様に、重要なビジネス・アプリケーションの利用範囲を拡大できます。Oracleとインターネットがあれば、いつでもどこからでも、アプリケーションおよびデータへの信頼性の高いアクセスが可能になります。
高可用性ソリューションを設計する上での課題の1つは、停止時間のあらゆる原因を検討し、対処することです。フォルト・トレラントおよびリジリエンスがあるITインフラストラクチャを設計する際、計画外停止時間と計画停止時間の両方の原因を考慮することは重要です。複数のタイムゾーンのユーザーをサポートするグローバル企業では特に、計画停止時間も計画外停止時間と同じく業務に悪影響を及ぼします。
表1-1は、計画外停止のタイプと説明、および各タイプの例を示しています。
| タイプ | 説明 | 例 |
|---|---|---|
|
サイト障害は、データ・センターでのすべての処理か、またはデータ・センターでサポートされているアプリケーションのサブセットに影響する可能性があります。 |
|
|
|
クラスタ全体の障害 |
Oracle RACデータベースのホストであるクラスタ全体が使用不可能になるか、故障します。次のような機能があります。
|
|
|
コンピュータ障害による停止は、データベースを実行しているシステムが停止または利用不可能になり、使用できない状態になったときに発生します。データベースがOracle RACを使用している場合、コンピュータ障害はシステムのサブセットを表します(データへの完全なアクセスを維持)。 |
|
|
|
ネットワーク障害 |
ネットワーク障害停止は、ネットワーク・デバイスが停止するか、アプリケーション・サービスの処理に不可欠な、アプリケーションからデータベース、データベースからストレージ、またはシステムからシステムのネットワーク・トラフィックや通信が減少したときに発生します。 |
|
|
ストレージ障害による停止は、データベース・コンテンツの一部またはすべてが格納されているストレージが停止または利用不可能になり、使用できない状態になったときに発生します。 |
|
|
|
破損ブロックは変更されたブロックです。そのため、Oracle Databaseが検出するものとは異なります。ブロック破損は、物理的破損と論理的破損に分類されます。
ブロック破損は、さらにインターブロック破損とイントラブロック破損に分類できます。 データ破損による停止は、ハードウェア、ソフトウェアまたはネットワークのコンポーネントで、読取りまたは書込み対象のデータが破損したときに発生します。データ破損による停止から受けるサービス・レベルの影響は、アプリケーションまたはデータベースの一部(単一データベース・ブロック・レベル)から大部分(基本的に使用不可にする)まで、大きく異なります。 |
|
|
|
人的エラーによる停止は、データベース内のデータを破損または使用不可能の状態にする意図的でない操作やその他の操作が行われた場合に発生します。人的エラーによる停止から受けるサービス・レベルの影響は、影響を受けたデータの量および重大性によって大きく異なります。 |
|
|
|
データ破損の別の形である書込み欠落や宛先違いの書込みは、素早く検出し修復することがさらに困難です。データ・ブロックの宛先違いの書込みまたは書込み欠落は次の場合に発生します。
宛先違いの書込みや書込み欠落が原因のブロック破損は、データベースの可用性を大きく損ねる可能性があります。データ・ブロックが物理的または論理的に正しくても、後続のディスク読取りで、古いブロックやOracle Databaseのブロック・アドレスが正しくないブロックが表示されます。 |
|
|
|
遅延または減速が発生するのは、リソースやロックの競合が原因でデータベースまたはアプリケーションがトランザクションを処理できなくなったときです。認識される遅延は、システム・リソースの不足が原因で引き起こされます。 |
|
表1-2は、計画停止のタイプと説明、および各タイプの例を示しています。
表1-2 計画停止時間の原因
| タイプ | 説明 | 例 |
|---|---|---|
|
システム変更およびデータベース変更 |
計画されたシステム変更は、日常的、定期的なメンテナンス業務および新しいデプロイメントが行われるときに発生します。 計画されたシステム変更には、データベース内の組織データ構造外で発生する計画的な業務環境への変更が含まれます。 計画されたシステム変更から受けるサービス・レベルの影響は、計画停止時間の性質および範囲、変更の実装前に行われるテストと検証作業、影響を最小化するためのテクノロジならびに機能により、大きく異なります。 |
|
|
データ変更 |
計画されたデータ変更は、Oracle Databaseオブジェクトの論理的構造または物理的組織に変更があった場合に発生します。この変更を行うのは主に、パフォーマンスまたは管理性を改善するためです。 |
|
|
アプリケーション変更 |
計画されたアプリケーション変更には、データ変更やスキーマおよびプログラムの変更などがあります。この変更を行うのは主に、パフォーマンス、管理性および機能性を改善するためです。 |
|
オラクル社では、計画外停止時間と計画停止時間の回避、および障害からのリカバリに役立つ高可用性ソリューションを提供しています。これらの高可用性ソリューションの詳細は、第4章および第5章で説明します。
Oracleの高可用性ソリューションと正常な操作実行が、ITインフラストラクチャの実装を成功させる鍵です。ただし、テクノロジのみでは十分ではありません。
可用性要件に最も適したアーキテクチャを選択し、実装するのは、きわめて困難な作業です。最大可用性アーキテクチャ(MAA)は、ビジネス要件に適した高可用性アーキテクチャを選択し実装するプロセスを簡略化します。MAAには次の特長があります。
すべてのコンポーネントに冗長性を持たせること
コンピュータ障害、ストレージ障害、人的エラー、データ破損、書込み欠落、システムの遅延または減速、およびサイト障害からの保護および許容が可能であること
できるだけ素早く透過的に停止からリカバリすること
計画停止時間をなくすか短縮するソリューションを提供すること
一貫した高パフォーマンスと堅牢なセキュリティを実現すること
デプロイメント、管理、スケーラビリティおよび可用性を簡単に実行できるようOracle Engineered Systemオプションを提供すること
できるかぎり安価な総所有コストでSLAを遵守すること
この種のアーキテクチャを構築、実装および維持するには、次のことが必要です。
ITシステムおよびビジネス・プロセスの技術面および運営面の両方を含め、固有の高可用性の要件を分析します(第2章「高可用性要件の特定 - 要件からアーキテクチャへの取得」を参照してください)。
Oracle高可用性機能を理解します。第3章「可用性を最大化するための機能」を参照してください。
各MAA層や、業務とアプリケーションに関する様々な高可用性機能に対する可用性の影響を理解します(第4章「計画停止時間用Oracle Database高可用性ソリューション」および第5章「計画外停止時間用Oracle Database高可用性ソリューション」を参照してください)。
運用のベスト・プラクティスを使用してMAAを正常に実装します。第6章「可用性を最大化するための運用前提条件」を参照してください。
高可用性アーキテクチャを選択します(第7章「高可用性アーキテクチャ」を参照してください)。
Oracle Exadata Database Machine、Oracle SuperCluster、Oracle Database ApplianceといったOracleのエンジニアド・システムがMAA全体とどのような関係にあるかを理解します(第8章「Oracle Engineered Systems」を参照してください)。
Oracle Grid Computing、Oracle Active Data Guardのリアルタイムのレポートおよび使用、プラガブル・データベースまたはOracle VirtualizationおよびOracle Data Cloudを使用したOracle Databaseマルチテナント・アーキテクチャにより、あらゆる高可用性アーキテクチャおよびソリューションの投資利益率(ROI)を最適化します。第9章「投資利益率の最適化」を参照してください。
次のリソースを使用して、高可用性アーキテクチャを実装します。
MAAおよび高可用性ベスト・プラクティスのホワイト・ペーパーおよびその他の情報
オラクル社では、各種ベスト・プラクティス・ホワイト・ペーパー、概念実証を伴うカスタマMAAペーパー、カスタマ・ケース・スタディ、記録されているWebキャスト、デモンストレーションおよびプレゼンテーションを提供しています。これらのリソースは、MAAの様々な高可用性テクノロジに関する技術的な詳細を、そのようなテクノロジを構成および使用するためのベスト・プラクティス推奨事項とともに提供します。
これらのMAAリソースは、http://www.oracle.com/goto/maaで入手できます。
