可用性を最大化するための運用前提条件

6.1 可用性およびパフォーマンスのSLAの理解

高可用性およびパフォーマンスに関するサービス・レベル合意(SLA)を理解して文書化します。

「高可用性の概要」に示すように、高可用性の属性と、停止時間の様々な原因を理解します。
「高可用性要件」および「高可用性要件を文書化する方法」に示すように、部門、経営幹部および高可用性とパフォーマンスに関するサービス・レベル合意の技術チームから同意を得ます。

6.2 SLAを満たす高可用性アーキテクチャの実装および検証

高可用性とパフォーマンス・サービス・レベル要件について合意を得たら、「高可用性およびデータ保護 - 要件からのアーキテクチャの取得」で説明されているOracleの標準および検証済アーキテクチャのいずれかにマッピングします。「計画外停止時間用Oracle Database高可用性ソリューション」および「計画停止時間用Oracle Database高可用性ソリューション」に記載されているものと同様のMAA参照アーキテクチャに関連する停止および計画内メンテナンス・マトリックスを評価します。選択されたMAA参照アーキテクチャの詳細は、「高可用性アーキテクチャ」を参照してください。

関連項目:

高可用性アーキテクチャ

Oracle MAAホワイト・ペーパー『高可用性ベスト・プラクティス: サービスとしてのデータベース統合の基盤』(http://www.oracle.com/goto/maa)

6.3 テスト・プラクティスおよび環境の構築

修復作業を検証および自動化して、ターゲット高可用性の品質保証契約(SLA)に準拠していることを確認します。バックアップ、リストアおよびリカバリの操作を検証して、可能性のある各種の停止に対するすべての修復作業を定期的に評価します。

Data Guardを障害回復とデータ保護に使用する場合は、定期的なスイッチオーバー作業を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実施することをお薦めします。また、アプリケーションおよびData Guardのスイッチオーバーを定期的に実行して、すべてのロール移行手順を完全に検証します。

よいテスト環境や適切なテスト・プラクティスは、本番環境で最高の安定性と可用性を達成するための重要な前提条件です。テスト環境であらゆる変更を完全に検証することで、本番で同じ変更を適用する前に、問題を事前に検知して防ぐことができます。

実際の作業には次のようなものがあります。

この章の内容は次のとおりです。

関連項目:

6.3.1 テスト・システムおよびQA環境の構成

テスト・システムは本番MAA環境のレプリカ(MAAのGold層を使用するなど)にする必要があります。テスト・システムが、選択したMAAサービス・レベルで運用される標準の参照アーキテクチャと同一でない場合は、トレードオフがあります。本番をまねたワークロードで、機能、パフォーマンスおよび可用性テストを実行することをお薦めします。可用性とパフォーマンスSLAが各変更後も維持されているかを評価し、本番環境に変更を適用している間になにか失敗した場合に、明確なフォールバックまたは修復プロシージャの準備が整っていることを確認します。

適切に構成されたテスト・システムによって、多くの問題を回避できます。変更が検証されるのは同等の本番およびスタンバイ・データベース構成で、これには完全なデータ・セットが含まれ、本番を模倣するためのワークロード・フレームワーク(たとえば、Oracle Real Application Testing)が使用されるためです。

テスト・システムの廃止によってコストを削減しようとしないでください。この決断は後々、本番アプリケーションの安定性と可用性に影響を及ぼすことになります。テストおよびQAのためにシステム・リソースのサブセットのみを使用すると、表6-1に示されているトレードオフがあります(MAAのGold層の例です)。

表6-1 各種のテストおよびQA環境のトレードオフ

テスト環境	利点とトレードオフ
本番システムとスタンバイ・システムの完全レプリカ	すべてのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。本番スケールにおける完全パフォーマンス検証。完全な高可用性の検証。
本番システムの完全レプリカ	すべてのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。本番スケールにおける完全パフォーマンス検証。完全な高可用性検証からスタンバイ・システムをマイナスしたもの。スタンバイ・データベースによる機能、パフォーマンス、高可用性および障害時リカバリの検証はなし。
スタンバイ・システム	ほとんどのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。 Data Guardスナップショット・スタンバイの使用時は、完全なパフォーマンス検証。ただし、フェイルオーバーが必要な場合はリカバリ時間が長くなる可能性があります。ロール移行の検証。スタンバイ・データベースとテスト・データベースが同じシステムに存在する場合は、リソース管理およびスケジューリングが必要です。
共有システム・リソース	ほとんどのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。本番の模倣に十分なシステム・リソースを割当てできれば、この環境はパフォーマンス・テストに適している場合があります。ただし、通常は、環境に本番システム・リソースのサブセットが含まれ、パフォーマンスの検証には欠落が生じます。リソース管理およびスケジューリングが必要です。
システム・リソースの小規模バージョンまたはサブセット	すべてのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。本番スケールにおけるパフォーマンス・テストなし。限定的な、完全スケールの高可用性評価。
異なるハードウェアまたはプラットフォームのシステム・リソース(同一オペレーティング・システム)	ほとんどのパッチとソフトウェアの変更を検証します。限定的な、ファームウェア・パッチ適用テスト。すべての機能テストを、ハードウェアの新機能で制限されていないかぎり、検証します。限定的な、本番スケールのパフォーマンス・テスト。限定的な、完全スケールの高可用性評価。

関連項目:

可用性およびパフォーマンスのSLAの理解

『Oracle Databaseテスト・ガイド』

6.3.2 本番前の検証手順の実行

ハードウェア、ソフトウェア、データベース、アプリケーションまたはすべての変更を本番前に検証およびテストすることは、安定性を維持するために重要です。上位レベルの本番前検証の手順は次のとおりです。

パッチまたはアップグレードのドキュメントや、対象の変更に関連するドキュメントを確認します。SLAで停止時間をゼロまたは最小限にすることが必要な場合、ローリング・アップグレードの実行の可能性を評価します。計画済停止時間を最小化または排除するローリング・アップグレードの機会を評価します。パッチまたは変更がStandby-First Patchに適格かどうか評価します。

注意:

Standby-First Patchを使用すると、プライマリ・データベースは以前のソフトウェア・リリースのまま、パッチを最初にフィジカル・スタンバイ・データベースに適用できます(この適用対象は特定のパッチ・タイプで、Oracleパッチ・セットおよびメジャー・リリース・アップグレードには適用されません。パッチ・セットおよびメジャー・リリースにはData Guardの一時ロジカル・スタンバイのメソッドを使用してください)。変更作業が終了したら、スタンバイ・データベースへのスイッチオーバーを実行します。フォールバックは必要な場合にスイッチオーバーすることです。もう1つの方法として次の手順に進み、本番環境に変更を適用することもできます。詳細は、My Oracle Supportのノート1265700.1(https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265700.1)『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。
テスト環境でアプリケーションを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。手順を自動化して、フォールバック手順の文書化およびテストも確認します。これには、テストでパッチ適用の前後に取得されたメトリックを、本番システムで取得されたメトリックと比較することが必要です。Real Application Testingは、本番システムでワークロードを取得し、それをテスト・システムで再現するために使用できます。AWRとSQLパフォーマンス・アナライザは、パッチによって引き起こされたパフォーマンスの向上または低下を評価するために使用できます。

本番環境を模倣するテスト・システムで新規ソフトウェアを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。パッチまたはアップグレードの手順を自動化して、フォールバックを確認します。この手順を一通り実施することで、パッチまたはアップグレードの実施中および実施後における最も致命的な問題を回避できます。
部門で決められているセキュリティ上の制約にも準拠しながら、アプリケーションを包括的に検証するには、Oracle Real Application Testingおよびテスト・データ管理機能を使用します。Oracle Real Application Testing (個別のデータベース・オプション)を使用すると、Oracle Databaseを現実的な環境でテストできます。Oracle Real Application Testingでは、本番環境にデプロイメントを行う前に、本番環境のワークロードを取得し、こららのワークロードに対するシステムの変更の影響を評価することで、システム変更が原因で不安定になるリスクを最小限にします。Oracle Real Application Testingの主要コンポーネントは、SQLパフォーマンス・アナライザおよびデータベース・リプレイです。テストするシステム変更の性質とその影響、およびテストを実行するシステムの種類に応じて、テストの実行にいずれかまたは両方のコンポーネントを使用できます。

現実的な環境でテストを行う場合、テスト環境の本番ではないユーザーに機密データが公開されてしまうリスクがあります。Oracle Databaseのテスト・データの管理機能では、テスト・データに対してデータ・マスキングおよびデータ・サブセット化を実行し、このリスクを最小限にできます。
適用可能な場合、すべての変更の最終的な本番前検証をData Guardスタンバイ・データベースで実行してから、それを本番に適用してください。適用可能な場合、Data Guard環境で変更を適用します。
本番環境で変更を適用します。

関連項目:

Data Guard Standby-First Patchの適用と一時ロジカル・スタンバイ方式の詳細は、「Data Guard REDO適用およびStandby-First Patchの適用」および「Data Guard一時ロジカル・ローリング・アップグレード」を参照してください。

『Oracle Databaseテスト・ガイド』

フィジカル・スタンバイ・データベースのスナップショット・スタンバイ・データベースへの変換の詳細は、『Oracle Data Guard概要および管理』を参照してください。

既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行の詳細は、『Oracle Data Guard概要および管理』を参照してください。

Oracle GoldenGateの詳細は、『Oracle GoldenGate Windows and UNIX管理者ガイド』を参照してください。

Oracle MAAホワイト・ペーパー『Oracle Databaseローリング・アップグレード: Data Guardフィジカル・スタンバイ・データベースの使用』(http://www.oracle.com/goto/maa)

My Oracle Supportのノート1265700.1(https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265700.1)『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。

6.4 セキュリティ・ベスト・プラクティスの設定および使用

適切なセキュリティ基準のないシステムまたはデータベースに配置された企業データは、深刻なリスクに直面している可能性があります。明確に定義されたセキュリティ・ポリシーは、システムに対する不正アクセスを遮断し、企業の機密情報を破壊行為から保護するのに役立ちます。適切なデータ保護により、セキュリティの侵害によるシステム停止の可能性を抑制できます。

関連項目:

『Oracle Databaseセキュリティ・ガイド』

6.5 変更管理手順の確立

システムの安定性を維持し、テスト・システムまたはMAAサービスレベル層の基本アーキテクチャのいずれかで厳密に評価されるまで変更がプライマリ・データベースに適用されないように、変更を管理および制御する手順を設けます。

変更を確認して、変更管理チームからフィードバックと承認を受け取ります。このチームにはビジネス要件、機能性、パフォーマンスおよびシステムの可用性に影響する、あらゆるコンポーネントの代表が含まれることが必要です。たとえば、チームにはエンドユーザー、アプリケーション、データベース、ネットワークおよびシステムの代表を含むことができます。

6.6 推奨パッチおよびソフトウェアの定期的な適用

最新の推奨パッチおよびソフトウェア・バージョンに対する定期的なテストと適用によって、最新のセキュリティおよびソフトウェアの修正がシステムで確実に行われるようにします。これは、安定性を維持し、多くの既知の問題を回避するために必要です。本番システムでアップグレードを実行する前に、テスト・システムですべての更新および変更を必ず検証してください。

さらに、Oracleヘルス・チェック・ツールorachk (非エンジニアド・システムとOracle Database Applianceをサポート)およびexachk (Oracle Exadata Database Machine、Exalogic、Zero Data Loss Recovery Appliance、Big Data Applianceなどのエンジニアド・システムをサポート)は、そのシステムとデータベースのヘルス・チェックおよびMAAの推奨事項とともに、Oracleソフトウェアのアップグレードに関するアドバイス、重要なソフトウェア更新の推奨事項、およびパッチ適用とアップグレードの事前チェックを提供します。

関連項目:

My Oracle Supportのノート756671.1 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=756671.1)『Oracle推奨パッチ -- Oracle Database』を参照してください。

My Oracle Supportのノート888828.1 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=888828.1)『Exadata Database MachineとExadata Storage Serverでサポートされるバージョン』を参照してください。

My Oracle Supportのノート1268927.2 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1268927.2)『ORAchk - Oracleスタックのヘルス・チェック』を参照してください。

My Oracle Supportのノート1070954.1 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1070954.1)『Oracle Exadata Database MachineのexachkまたはHealthCheck』を参照してください。

6.7 障害時リカバリ検証の実行

RTOやRPOなどの障害時リカバリ・サービス・レベル要件を満たしているか確認するには、障害時リカバリ検証が必要です。

スタンバイ・データベースとしてOracle GoldenGateレプリカを使用している場合でも、Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)、ZFS Storage、または別のサード・パーティのデータベース・バックアップを利用している場合でも、操作およびデータベース管理チームは、事前に設定したしきい値に従って、プライマリ・データベースの停止またはパフォーマンス低下時にいつでもデータベースとアプリケーションをフェイルオーバーまたは復元できるよう十分に準備しておくことが重要です。検出や、フェイルオーバーまたは復元どちらにするかの決定を含め、効果的に反応および実行することで、停止時間全体を大幅に削減できます。

Data GuardまたはOracle GoldenGateを高可用性、障害時リカバリ、データ保護のために使用する場合、3～6か月ごとに定期的なアプリケーションとデータベースのスイッチオーバーの操作を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実行することをお薦めします。

既存のバックアップ・ソリューションを使用して障害時リカバリ・ソリューションを検証するには、定期的なRMANクロス・チェック、RMANバックアップ検証および完全なデータベースの復元とリカバリが必要です。リカバリ・アプライアンスでは、アプライアンス内で自固有のバックアップ・チェックと検証が動的に実行されますが、定期的な復元とリカバリのテストもお薦めします。

関連項目:

Oracle Data Guardとロール・トランジションのベスト・プラクティスの詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

ロール・トランジションの詳細は、『Oracle Data Guard概要および管理』を参照してください。

スイッチオーバーとフェイルオーバー操作の詳細は、『Oracle Data Guard Broker』を参照してください。

『Zero Data Loss Recovery Appliance管理者ガイド』

6.8 エスカレーション管理手順の確立

修復を妨げないためのエスカレーション管理手順を確立します。ほとんどの修復ソリューションは、適切に実施されていればMAAソリューションで自動的かつ透過的です。問題が発生するのは、プライマリ・データベースまたはシステムが可用性またはパフォーマンスのSLAに適合せず、フェイルオーバー手順がData Guardの一部のフェイルオーバー・シナリオのように自動で行われるのではない場合です。適切なエスカレーション・ポリシーが施行されず、決定が迅速に行われないと、停止時間が長引く可能性があります。

可用性が最優先である場合、修復およびフェイルオーバー操作を最初に実行し、アプリケーション・サービスが再構築されてから、根本原因分析(RCA)用のログおよび情報の収集を続行します。簡易なデータ収集には、トレース・ファイル・アナライザ・コレクタ(TFA)を使用します。

関連項目:

MAAの停止および修復の詳細は、Oracle Technology Network(OTN) (http://www.oracle.com/goto/maa)でMAA Webページを確認してください。

Oracle Supportのノート1513912.2『TFAコレクタ - 拡張診断収集のツール』(1513912.2)を参照してください。

6.9 高可用性のための監視およびサービス要求インフラストラクチャの構成

高可用性環境を維持するには、停止時間が発生する前に、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャを構成する必要があります。また、可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したディスク、フラッシュ・カード、ファン、電源などのハードウェア・コンポーネントを置き換えることができます。

この章の内容は次のとおりです。

6.9.1 データベース・ヘルス・チェックの定期的な実行

Oracleデータベース・ヘルス・チェックは、ハードウェアおよびソフトウェアの構成とベスト・プラクティスに対するMAA準拠を評価するように設計されています。Oracleヘルス・チェック・ツールはすべて、Oracle Grid Infrastructure、Oracle Databaseを評価し、自動MAAスコアカードを提供するか、または主要なアーキテクチャおよび構成の設定が失敗に対する耐性がない、または高速リカバリに対応していない場合にその強調部分を確認します。Exadata Database MachineなどのOracleの設計されたシステムには、数百の追加のソフトウェア、エラーおよび構成のチェックが存在します。

Oracleでは、定期的に(たとえば、Exadata Database Machineの場合毎月)最新のデータベース・ヘルス・チェックのダウンロードと実行、および主要なFAILURES、WARNINGS、およびINFOメッセージへの対処をお薦めしています。Oracle Exadata Database Machine、Exalogic、Zero Data Loss Recovery Appliance、Big Data Applianceなどのエンジニアド・システムにはexachkを使用し、Oracle Database Applianceなどの非エンジニアド・システムにはorachkを使用します。

さらに、計画メンテナンス・アクティビティの前と後に、ヘルス・チェックを実行することもお薦めします。

計画内メンテナンス・ウィンドウより前に既存のまたは新しい重要なヘルス・チェック・アラートを評価する
テスト後の計画内メンテナンス・ウィンドウへの新しい推奨事項の追加を評価する
既存のソフトウェアまたは重要なソフトウェアの推奨事項を評価する

関連項目:

My Oracle Supportのノート1268927.2 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1268927.2)『ORAchk - Oracleスタックのヘルス・チェック』を参照してください。

My Oracle Supportのノート1070954.1 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1070954.1)『Oracle Exadata Database MachineのexachkまたはHealthCheck』を参照してください。

6.9.2 高可用性のためのOracle Enterprise Manager監視インフラストラクチャの構成

可能性のある停止時間を回避するには、Enterprise Managerと、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャの両方を構成および使用する必要があります。監視インフラストラクチャを使用すると、ユーザーは高可用性を監視しやすくなり、次の作業も実行できます。

システム、ネットワーク、アプリケーション、データベースおよびストレージの統計の監視
パフォーマンスおよびサービスの統計の監視
システムまたはアプリケーションの問題の初期警告インジケータとなる、パフォーマンスおよび高可用性のしきい値の作成
パフォーマンスおよび可用性アドバイスの提供
確立されたアラート、ツール、およびデータベース・パフォーマンス
設計されたシステムのハードウェア障害のアラートの受信

関連項目:

高可用性のモニタリングの詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

潜在的な問題および障害の検出と対応の詳細は、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドを参照してください。

Enterprise ManagerとExadataの管理性のベスト・プラクティスは、Enterprise ManagerのMAAベスト・プラクティスの分野(http://www.oracle.com/goto/maa)を参照してください。

6.9.3 自動サービス要求インフラストラクチャの構成

Oracle高可用性環境でのEnterprise Managerによる監視インフラストラクチャに加えて可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したハードウェアを置き換えることができます。たとえば、Oracle Automatic Service Request (ASR)は安全かつスケーラブルな、ユーザーがインストール可能なソフトウェア・ソリューションで、これは機能として使用できます。特定のハードウェア障害が発生したとき、OracleのSolarisサーバーおよびストレージ・システムの自動ケース生成を使用することで、このソフトウェアでは問題をより早く解決します。

関連項目:

My Oracle Supportのノート1185493.1『Oracle自動サービス要求』

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1185493.1

6.10 最新のMAAベスト・プラクティスの確認

MAAソリューションおよびベスト・プラクティスは、Oracle Technology Network(OTN) (http://www.oracle.com/goto/maa)で継続的に開発および公開されています。

Oracle Database MAAベスト・プラクティスは、Oracle Exadata Database Machine、Zero Data Loss Recovery ApplianceおよびOracle Cloudのページで参照してください。

MAAソリューションには、Oracleテクノロジのすべてのスタックが含まれるため、MAAのページでOracle Fusion Middleware、Oracle Fusion Applications、Oracle Applications Unlimited、Oracle Exalytics、Oracle Exalogic、Oracle VM、Oracle Enterprise Manager Cloud ControlのMAAベスト・プラクティスを参照できます。