高可用性の概要

1.1 高可用性とは

可用性は、要求に応じてアプリケーション、サービスまたは機能がどの程度使用可能であるかを表しています。可用性は、アプリケーションのユーザーの感覚を基準に評価されます。データが使用できない場合やコンピュータ・システムが予想どおりに機能しない場合、ユーザーは不満を感じます。ユーザーがソリューション全体の複雑なコンポーネントを理解したり、区別しようと考えたりすることはありません。予想を超える使用状況が原因で発生したパフォーマンス障害は、アーキテクチャの重要なコンポーネントに障害が発生した場合と同じ混乱をもたらします。ユーザーがシステムにアクセスできないことを使用不可といいます。一般的に、システムの使用不可期間は停止時間と呼ばれます。

システムをいつでも使用できる状態にしておくには、高可用性が必要です。可用性の高いシステムは、主要期間、年間を通じて毎日毎時間、割込みのない計算処理を提供するように設計されています。これは 24x365と表されます。このようなシステムにも、システムのハードウェアまたはソフトウェアのアップグレードなど、計画メンテナンス操作のための高可用性ソリューションが必要です。

信頼性、リカバリ可能性、タイムリなエラー検出および継続的稼働は、高可用性ソリューションの主な特徴です。

信頼性: 信頼できるハードウェアは高可用性ソリューションの1つの要素です。信頼できるソフトウェア(データベース、Webサーバー、アプリケーションなど)も同様に、高可用性ソリューションを実現する上で重要です。関連する特性はリジリエンスです。たとえば、低コストの汎用ハードウェアをOracle Real Application Clusters(Oracle RAC)などのソフトウェアを組み合せることで、非常に信頼性の高いシステムの実装に使用できます。Oracle RACデータベースのリジリエンスが高ければ、個々のサーバーに障害が発生しても、処理は続行できます。
リカバリ能力: 障害からのリカバリには多数の方法がある場合があります。したがって、高可用性の環境でどのようなタイプの障害が発生する可能性があるかを判断し、ビジネスの要件を満たして迅速にそれらの障害からリカバリする方法を決めることが重要です。たとえば、重要な表が誤ってデータベースから削除された場合、その表をリカバリするにはどのような処置を取ればよいでしょうか。アーキテクチャには、品質保証契約(SLA)で規定された時間内にリカバリする能力があるでしょうか。
タイムリなエラー検出: アーキテクチャのコンポーネントに障害が発生した場合、予期しない障害からリカバリするには素早い検出が重要です。停止から素早くリカバリできても、問題の検出にさらに90分かかったとしたら、SLAを遵守できない可能性があります。環境の状態を監視するには、状態を素早く表示するための信頼できるソフトウェア、およびデータベース管理者に問題を通知する機能が必要です。
継続的稼働: データへの継続的なアクセスを提供することが、メンテナンス・アクティビティを実行するための停止時間をほとんど、あるいはまったく許容できないという場合に不可欠です。表をデータベース内の別の場所に移動したり、ハードウェアにCPUを追加したりといったアクティビティは、高可用性アーキテクチャではユーザーに対して透過的に行う必要があります。

より具体的に言えば、高可用性アーキテクチャは次の特徴を備えている必要があります。

中断を最小限またはゼロにして、処理が継続するように障害を許容すること
システム、データまたはアプリケーションの変更に対して透過的である(または耐性がある)こと
予防措置が組み込まれていること
障害のアクティブな監視と素早い検出が可能であること
素早いリカバリが可能であること
検出操作およびリカバリ操作が自動化されていること
データ損失を最小限に抑えるか防止するためにデータを保護すること
運用面でのベスト・プラクティスを実施して環境を管理していること
できるかぎり安価な総所有コストでSLA(リカバリ時間目標(RTO)やリカバリ・ポイント目標(RPO)など)で設定した目標を達成すること

1.2 可用性の重要性

高可用性がどの程度重要であるかはアプリケーションによって異なります。データベースとインターネットは、組織やコミュニティの隅々にまでデータベース・アプリケーションを行き渡らせ、世界的なコラボレーションと情報共有を可能にしました。こうしたデータベース・アプリケーションの浸透により、データ管理ソリューションにおける高可用性の重要性が浮き彫りになっています。中小企業もグローバルな企業も、1日24時間データへのアクセスを必要とするユーザーを世界中に抱えています。このデータ・アクセスが行えなければ、業務は停止し、収益が失われます。これらのソリューションに依存する傾向が強まったことを反映して、ユーザーは情報技術(IT)部門やソリューション提供者の品質保証契約を求めるようになりました。可用性は、時間と利便性のみでなく、ドル、ユーロおよび円で評価されることがますます増えています。

企業は、そのITインフラストラクチャを利用して、競争力を付け、生産性を高め、より多くの情報に基づいてより迅速に決定を下す力をユーザーに与えてきました。しかし、こうした利点により、インフラストラクチャへの依存度はますます高まりました。重要なアプリケーションが使用できなくなった場合、ビジネスが危機に瀕します。ビジネスの収益が減少し、違約金を被り、顧客や会社の株価に対する影響が続く悪評を呼ぶ可能性があります。

データの保護方法を決定する要因について検討し、ユーザーへの可用性を最大限に高めることが非常に重要です。

1.3 停止時間のコスト

企業がソリューションを再構築して競争力を強めるにつれて、より高いレベルの可用性を提供する必要性は高まる一方です。ほとんどの場合、こうした新しいソリューションは重要なビジネス・データへの即時アクセスに依存しています。データが使用できない場合、業務が停止する可能性もあります。停止時間は、生産性の低下、収益の損失、カスタマ・リレーションシップの悪化、悪評および訴訟につながりかねません。

停止時間の直接のコストを試算するのは必ずしも容易ではありません。顧客の怒り、従業員の空き時間、悪評などはすべてコストに結び付きますが、通貨に直接換算することはできません。その一方で、SLAの目標が達成されないことによる収益の損失や法的処罰は容易に定量化可能です。ソリューションに依存してサービスを提供している業界では、停止時間のコストが急速に増大する可能性があります。

停止時間のコストという点で考慮が必要なその他の要因は、次のとおりです。

1回の計画外停止の最大許容時間

イベントの継続時間が30秒未満の場合、イベントが与える影響は非常に小さく、ユーザーがイベントを感じ取ることはほとんどありません。停止時間が長くなるにつれて、その影響は著しく大きくなり、ビジネスにも悪影響を及ぼすことになります。
許容できるインシデントの最大頻度

停止の頻度が高くなると、停止が短時間であったとしても、同様に業務が中断する可能性があります。

ソリューションを設計する場合、停止時間の実際のコストを把握して、可用性が向上することでどのように利益が得られるのかを認識することが重要です。

オラクル社では、規模に関係なくあらゆる組織に適する幅広い高可用性ソリューションを提供しています。小規模な作業グループとグローバル企業が同じように組織の重要なビジネス・アプリケーションの可用性を拡張できます。Oracleとインターネットがあれば、いつでもどこからでも、アプリケーションおよびデータへの信頼性の高いアクセスが可能になります。

1.4 停止時間の原因

高可用性ソリューションを設計する上での課題の1つは、停止時間のあらゆる原因を検討し、対処することです。フォルト・トレラントおよびリジリエンスがあるITインフラストラクチャを設計する際、計画外停止時間と計画停止時間の両方の原因を考慮することは重要です。複数のタイムゾーンのユーザーをサポートするグローバル企業では特に、計画停止時間も計画外停止時間と同じく業務に悪影響を及ぼします。

表1-1は、計画外停止のタイプと説明、および各タイプの例を示しています。

表1-1 計画外停止時間の原因

タイプ	説明	例
サイト障害	サイト障害は、データ・センターのすべての処理、またはデータ・センターによってサポートされているアプリケーション・サブセットに影響を及ぼす場合があります。	サイト全体に及ぶ停電サイト全体のネットワーク障害データ・センターを操業不可能にする自然災害業務またはサイトへのテロまたは悪意のある攻撃
クラスタ全体の障害	Oracle RACデータベースのホストであるクラスタ全体が使用不可能になるか、故障します。次のものが含まれます。クラスタ内のノードの障害クラスタが使用不可能になる原因となった他のコンポーネントの障害および使用不可能なサイト上のOracleデータベースやインスタンスの障害	Oracle RACクラスタ上で最後まで動作しているノードに障害が発生し、ノードまたはデータベースが再起動不能冗長クラスタのインターコネクトが両方故障またはクラスタウェアの障害データベースの破損が、現行データベース・サーバーでの継続が不可能になるほど深刻ディスク・ストレージ障害
コンピュータ障害	コンピュータ障害による停止は、データベースを実行しているシステムが停止または利用不可能になり、使用できない状態になったときに発生します。データベースがOracle RACを使用している場合、コンピュータ障害はシステムのサブセットを表します(データへの完全なアクセスを維持)。	データベース・システム・ハードウェア障害オペレーティング・システム障害 Oracleインスタンス障害
ネットワークの障害	ネットワーク障害停止は、ネットワーク・デバイスが停止するか、アプリケーション・サービスの処理に不可欠な、アプリケーションからデータベース、データベースからストレージ、またはシステムからシステムのネットワーク・トラフィックや通信が減少したときに発生します。	ネットワーク切替え障害ネットワーク・インタフェース障害ネットワーク・ケーブル障害
ストレージ障害	ストレージ障害による停止は、データベース・コンテンツの一部またはすべてが格納されているストレージが停止または利用不可能になり、使用できない状態になったときに発生します。	ディスク・ドライブ障害ディスク・コントローラ障害ストレージ・アレイ障害
データ破損	破損ブロックは変更されたブロックです。そのため、Oracle Databaseが検出するものとは異なります。ブロック破損は、物理的破損と論理的破損に分類されます。物理ブロック破損はメディア破損とも呼ばれ、ブロックがデータベースにまったく認識されません。チェックサムが無効になるか、ブロック内容がすべてゼロになります。より複雑なブロック破損の例として、ブロックのヘッダーとフッターが一致しない場合があげられます。論理ブロック破損では、ブロックの内容は物理的には正常で、物理ブロック・チェックを通過します。ただし、ブロックが論理的に一貫性を欠いている場合があります。論理ブロック破損の例には、不正なブロック・タイプ、不正なデータまたはREDOブロック順序番号、行ピースや索引エントリの破損、あるいはデータ・ディクショナリの破損があります。ブロック破損は、さらにインターブロック破損とイントラブロック破損に分類できます。イントラブロック破損の場合、破損はブロック内部で発生し、物理ブロック破損または論理ブロック破損のいずれかになります。インターブロック破損の場合、破損はブロック間で発生し、論理ブロック破損になります。データ破損による停止は、ハードウェア、ソフトウェアまたはネットワークのコンポーネントで、読取りまたは書込み対象のデータが破損したときに発生します。データ破損による停止から受けるサービス・レベルの影響は、アプリケーションまたはデータベースの一部(単一データベース・ブロック・レベル)から大部分(基本的に使用不可にする)まで、大きく異なります。	オペレーティング・システムまたはストレージ・デバイス・ドライバ障害障害のあるホスト・バス・アダプタディスク・コントローラ障害ディスクの不正な読取りまたは書込みの原因となるボリューム・マネージャ・エラーソフトウェアまたはハードウェアの不具合
人的エラー	人的エラーによる停止は、データベース内のデータを破損または使用不可能の状態にする意図的でない操作やその他の操作が行われた場合に発生します。人的エラーによる停止から受けるサービス・レベルの影響は、影響を受けたデータの量および重大性によって大きく異なります。	(ファイル・システム・レベルの)ファイルの削除削除されたデータベース・オブジェクト故意でないデータ変更悪意のあるデータ変更
書込み欠落または宛先違いの書込み	データ破損の別の形である書込み欠落や宛先違いの書込みは、素早く検出し修復することがさらに困難です。データ・ブロックの宛先違いの書込みまたは書込み欠落は次の場合に発生します。書込み欠落は、書込みI/Oが永続記憶域で発生しなくても、I/Oサブシステムがブロック書込みの完了を確認する場合。プライマリ・データベースでの後続ブロック読取りのときに、I/Oサブシステムが、データベースの他のブロックの更新に使用される古いバージョンのデータ・ブロックを返すため、ブロックが破損します。宛先違いの書込みは、書込みI/Oは完了したが、他の場所に書き込まれ、後続の読取り操作で古い値が返される場合。 Oracle RACシステムでは、1つのクラスタ・ノードからの読取りI/Oで、別のノードからの書込みI/O完了後に古いデータが返される場合(書込みの欠落)。たとえば、属性キャッシュを無効にせずに(`noac`オプションを使用しないなど)ネットワーク・ファイル・システム(NFS)がOracle RACでマウントされている場合に発生します。この場合、1つのノードからの書込みI/Oは、キャッシュされるために別のノードに即時表示されません。宛先違いの書込みや書込み欠落が原因のブロック破損は、データベースの可用性を大きく損ねる可能性があります。データ・ブロックが物理的または論理的に正しくても、後続のディスク読取りで、古いブロックやOracle Databaseのブロック・アドレスが正しくないブロックが表示されます。	オペレーティング・システムまたはストレージ・デバイス・ドライバ障害障害のあるホスト・バス・アダプタディスク・コントローラ障害ボリューム・マネージャ・エラーその他のアプリケーション・ソフトウェアクラスタ全体で見えないネットワーク・ファイル・システム(NFS)書込み
遅延または減速	遅延または減速が発生するのは、リソースやロックの競合が原因でデータベースまたはアプリケーションがトランザクションを処理できなくなったときです。認識される遅延は、システム・リソースの不足が原因で引き起こされます。	データベースまたはアプリケーションのデッドロックシステム・リソースを消費する暴走プロセスログオン・ストームまたはシステム・フォルトアプリケーションのピークとシステムまたはデータベースのリソース不足の同時発生。リソースが適切に管理されていない統合データベース環境では、1つのアプリケーションで起こることも、多数のアプリケーションで起こることもあります。アーカイブREDOログの宛先または高速リカバリ領域の宛先がいっぱいになった場合

表1-2は、計画停止のタイプと説明、および各タイプの例を示しています。

表1-2 計画停止時間の原因

タイプ	説明	例
システム変更およびデータベース変更	計画されたシステム変更は、日常的、定期的なメンテナンス業務および新しいデプロイメントが行われるときに発生します。計画されたシステム変更には、データベース内の組織データ構造外で発生する計画的な業務環境への変更が含まれます。計画されたシステム変更から受けるサービス・レベルの影響は、計画停止時間の性質および範囲、変更の実装前に行われるテストと検証作業、影響を最小化するためのテクノロジならびに機能により、大きく異なります。	SMPサーバーへのプロセッサの追加、またはSMPサーバーからの削除クラスタへのノードの追加、またはクラスタからのノードの削除ディスク・ドライブまたはストレージ・アレイの追加および削除任意のフィールド交換可能ユニット(FRU)の交換構成パラメータの変更システム・ハードウェアおよびソフトウェアのアップグレードまたはパッチ適用 Oracleソフトウェアのアップグレードまたはパッチ適用アプリケーション・ソフトウェアのアップグレードまたはパッチ適用システム・プラットフォームの移行データベースの再配置 32ビットから64ビットへの移動クラスタ・アーキテクチャへの移行新しい記憶域への移行
データ変更	計画的なデータ変更は、Oracle Databaseオブジェクトの論理構造または物理的な編成が変更された場合に発生します。これらの変更は、主にパフォーマンスまたは管理性を向上させる目的で行われます。	表定義の変更表のパーティション化の追加索引の作成および再構築
アプリケーション変更	計画されたアプリケーション変更には、データ変更やスキーマおよびプログラムの変更などがあります。これらの変更は、主にパフォーマンス、管理性、および機能性を向上させる目的で行われます。	アプリケーション・アップグレード

タイプ

説明

例

システム変更およびデータベース変更

計画されたシステム変更は、日常的、定期的なメンテナンス業務および新しいデプロイメントが行われるときに発生します。

計画されたシステム変更には、データベース内の組織データ構造外で発生する計画的な業務環境への変更が含まれます。

計画されたシステム変更から受けるサービス・レベルの影響は、計画停止時間の性質および範囲、変更の実装前に行われるテストと検証作業、影響を最小化するためのテクノロジならびに機能により、大きく異なります。

SMPサーバーへのプロセッサの追加、またはSMPサーバーからの削除

クラスタへのノードの追加、またはクラスタからのノードの削除

ディスク・ドライブまたはストレージ・アレイの追加および削除

任意のフィールド交換可能ユニット(FRU)の交換

構成パラメータの変更

システム・ハードウェアおよびソフトウェアのアップグレードまたはパッチ適用

Oracleソフトウェアのアップグレードまたはパッチ適用

アプリケーション・ソフトウェアのアップグレードまたはパッチ適用

システム・プラットフォームの移行

データベースの再配置

32ビットから64ビットへの移動

クラスタ・アーキテクチャへの移行

新しい記憶域への移行

データ変更

計画的なデータ変更は、Oracle Databaseオブジェクトの論理構造または物理的な編成が変更された場合に発生します。これらの変更は、主にパフォーマンスまたは管理性を向上させる目的で行われます。

表定義の変更

表のパーティション化の追加

索引の作成および再構築

アプリケーション変更

計画されたアプリケーション変更には、データ変更やスキーマおよびプログラムの変更などがあります。これらの変更は、主にパフォーマンス、管理性、および機能性を向上させる目的で行われます。

アプリケーション・アップグレード

オラクル社では、計画外停止時間と計画停止時間の回避、および障害からのリカバリに役立つ高可用性ソリューションを提供しています。「計画外停止時間用Oracle Database高可用性ソリューション」および「計画停止時間用Oracle Database高可用性ソリューション」では、これらの高可用性ソリューションの詳細を説明しています。

1.5 最大可用性アーキテクチャ実装のロードマップ

Oracleの高可用性ソリューションと正常な操作実行が、ITインフラストラクチャの実装を成功させる鍵です。ただし、テクノロジのみでは十分ではありません。

可用性要件に最も適したアーキテクチャを選択し、実装するのは、きわめて困難な作業です。最大可用性アーキテクチャ(MAA)は、ビジネス要件に適した高可用性アーキテクチャを選択し実装するプロセスを簡略化します。MAAには次の特長があります。

すべてのコンポーネントに冗長性を持たせること
コンピュータ障害、ストレージ障害、人的エラー、データ破損、書込み欠落、システムの遅延または減速、およびサイト障害からの保護および許容が可能であること
できるだけ素早く透過的に停止からリカバリすること
計画停止時間をなくすか短縮するソリューションを提供すること
一貫した高パフォーマンスと堅牢なセキュリティを実現すること
デプロイメントおよび管理を簡単に実行し、高可用性、パフォーマンスおよび可用性を向上できるようOracle Engineered Systemオプションを提供すること
できるかぎり安価な総所有コストでSLAを遵守すること
オンプレミス、Oracle Public Cloud、およびオンプレミスとクラウドの一部で構成されるハイブリッド・アーキテクチャに適用すること
コンテナまたはOracle Multitenant、Oracle Database In-MemoryおよびOracle Shardingアーキテクチャに特別な考慮事項を提供すること

この種のアーキテクチャを構築、実装および維持するには、次のことが必要です。

ITシステムおよびビジネス・プロセスの技術面および運営面の両方を含め、固有の高可用性の要件を分析します(「高可用性およびデータ保護 - 要件からのアーキテクチャの取得」を参照してください)。
Oracle高可用性機能を理解します。「可用性を最大化するための機能」を参照してください。
各MAA層や、業務とアプリケーションに関する様々な高可用性機能に対する可用性の影響を理解します(「計画停止時間用Oracle Database高可用性ソリューション」および「計画外停止時間用Oracle Database高可用性ソリューション」を参照してください)。
運用のベスト・プラクティスを使用してMAAを正常に実装します。「可用性を最大化するための運用前提条件」を参照してください。
高可用性アーキテクチャを選択します(「高可用性アーキテクチャ」を参照してください)。
Oracle Exadata Database Machine、Oracle SuperCluster、Oracle Database Appliance、Zero Data Loss Recovery ApplianceなどのOracle Engineered SystemによるMAAの改善方法を学習します(「Oracle Engineered Systems」を参照してください)。
Oracle Grid Computing、Oracle Active Data Guardのリアルタイムのレポートおよび使用、プラガブル・データベースまたはOracle VirtualizationおよびOracle Data Cloudを使用したOracle Databaseマルチテナント・アーキテクチャにより、あらゆる高可用性アーキテクチャおよびソリューションの投資利益率(ROI)を最適化します(「投資利益率の最適化」を参照してください)。
次のリソースを使用して、高可用性アーキテクチャを実装します。
- MAAおよび高可用性ベスト・プラクティスのホワイト・ペーパーおよびその他の情報
  
  オラクル社では、各種ベスト・プラクティス・ホワイト・ペーパー、概念実証を伴うカスタマMAAペーパー、カスタマ・ケース・スタディ、記録されているWebキャスト、デモンストレーションおよびプレゼンテーションを提供しています。これらのリソースは、MAAの様々な高可用性テクノロジに関する技術的な詳細を、そのようなテクノロジを構成および使用するためのベスト・プラクティス推奨事項とともに提供します。
  
  これらのMAAリソースは、http://www.oracle.com/goto/maaで入手できます。
- Oracleデータベースの高可用性ベスト・プラクティス
  
  このマニュアルでは、MAA参照アーキテクチャの構成、修復および計画内メンテナンスのベスト・プラクティスを示します。これは、新しい高可用性環境を構成したり、簡素化やパフォーマンスを損わずに、既存の構成を移行して冗長かつ信頼できるシステムを作成したりする場合に役立ちます。