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