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

MAAの実装を成功させるには、次の運用ベスト・プラクティスを使用します。

• 可用性およびパフォーマンスのSLAの理解
  
• SLAを満たす高可用性アーキテクチャの実装および検証
  
• テスト・プラクティスおよび環境の構築
  
• セキュリティ・ベスト・プラクティスの設定および使用
  
• 変更管理手順の確立
  
• 推奨パッチおよびソフトウェアの定期的な適用
  
• 障害時リカバリ検証の実行
  RTOやRPOなどの障害時リカバリ・サービス・レベル要件を満たしているか確認するには、障害時リカバリ検証が必要です。
• エスカレーション管理手順の確立
  
• 高可用性のための監視およびサービス要求インフラストラクチャの構成
  高可用性環境を維持するには、停止時間が発生する前に、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャを構成する必要があります。
• 最新のMAAベスト・プラクティスの確認
  MAAソリューションには、Oracleテクノロジのすべてのスタックが含まれるため、MAAのページでOracle Fusion Middleware、Oracle Fusion Applications、Oracle Applications Unlimited、Oracle Exalytics、Oracle Exalogic、Oracle VM、Oracle Enterprise Manager Cloud ControlのMAAベスト・プラクティスを参照できます。

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

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

• 「高可用性の概要」に示すように、高可用性の属性と、停止時間の様々な原因を理解します。

• 「高可用性要件」および「高可用性要件を文書化する方法」に示すように、部門、経営幹部および高可用性とパフォーマンスに関するサービス・レベル合意の技術チームから同意を得ます。

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

高可用性およびパフォーマンスのサービス・レベル要件に関する合意事項がある場合は、次の作業を行います。

• 高可用性およびデータ保護 - 要件からのアーキテクチャの取得で説明されているOracle MAAの標準および検証済MAA参照アーキテクチャのいずれかに要件をマッピングします
• 「計画外停止時間用Oracle Database高可用性ソリューション」および「計画停止時間用Oracle Database高可用性ソリューション」の参照アーキテクチャに関連する停止および計画内メンテナンス・マトリックスを評価します
• 高可用性アーキテクチャにMAAアーキテクチャを実装するために必要なデータベース機能について学習します

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

ターゲットの高可用性SLAが満たされていることを確認するには、次のものを検証または自動化する必要があります。

• すべてのソフトウェア更新およびアップグレード・メンテナンス・イベント
• すべての修復操作(各種の計画外停止のための修復操作を含む)
• バックアップ、リストアおよびリカバリ操作

障害時リカバリとデータ保護のためにOracle Data Guardを使用する場合は、次のことをお薦めします。

• 定期的にスイッチオーバー操作を実行するか、アプリケーションおよびデータベースの完全なフェイルオーバー・テストを実行します
• アプリケーションおよびData Guardのスイッチオーバーを定期的に実行して、エンドツーエンドのロール・トランジション手順を検証します

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

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

• テスト・システムおよびQA環境の構成
  
• 本番前の検証ステップの実行
  

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

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

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

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

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

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

関連項目:

『Oracle Databaseテスト・ガイド』

本番前の検証ステップの実行

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

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

   注意:

   Standby-First Patchを使用すると、プライマリ・データベースは以前のソフトウェア・リリースのまま、パッチを最初にフィジカル・スタンバイ・データベースに適用できます(この適用対象は特定のソフトウェア・アップデートのタイプで、メジャー・リリース・アップグレードには適用されません。パッチ・セットおよびメジャー・リリースにはData Guardの一時ロジカル・スタンバイおよびDBMS_ROLLINGの方法を使用してください)。変更作業が終了したら、スタンバイ・データベースへのスイッチオーバーを実行します。フォールバックは必要な場合にスイッチオーバーすることです。もう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適用』を参照してください。

2. テスト環境でアプリケーションを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。手順を自動化して、フォールバック手順の文書化およびテストも確認します。これには、テストでパッチ適用の前後に取得されたメトリックを、本番システムで取得されたメトリックと比較することが必要です。Real Application Testingは、本番システムでワークロードを取得し、それをテスト・システムで再現するために使用できます。AWRとSQLパフォーマンス・アナライザは、パッチによって引き起こされたパフォーマンスの向上または低下を評価するために使用できます。

   本番環境を模倣するテスト・システムで新規ソフトウェアを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。パッチまたはアップグレードの手順を自動化して、フォールバックを確認します。このステップを一通り実施することで、パッチまたはアップグレードの実施中および実施後における最も致命的な問題を回避できます。

3. 部門で決められているセキュリティ上の制約にも準拠しながら、アプリケーションを包括的に検証するには、Oracle Real Application Testingおよびテスト・データ管理機能を使用します。Oracle Real Application Testing (個別のデータベース・オプション)を使用すると、Oracle Databaseを現実的な環境でテストできます。Oracle Real Application Testingでは、本番環境にデプロイメントを行う前に、本番環境のワークロードを取得し、こららのワークロードに対するシステムの変更の影響を評価することで、システム変更が原因で不安定になるリスクを最小限にします。Oracle Real Application Testingの主要コンポーネントは、SQLパフォーマンス・アナライザおよびデータベース・リプレイです。テストするシステム変更の性質とその影響、およびテストを実行するシステムの種類に応じて、テストの実行にいずれかまたは両方のコンポーネントを使用できます。

   現実的な環境でテストを行う場合、テスト環境の本番ではないユーザーに機密データが公開されてしまうリスクがあります。Oracle Databaseのテスト・データの管理機能では、テスト・データに対してデータ・マスキングおよびデータ・サブセット化を実行し、このリスクを最小限にできます。

4. 適用可能な場合、すべての変更の最終的な本番前検証をData Guardスタンバイ・データベースで実行してから、それを本番に適用してください。適用可能な場合、Data Guard環境で変更を適用します。

5. 本番環境で変更を適用します。

関連項目:

Data Guard REDO適用およびStandby-First Patchの適用およびData Guard一時ロジカル・ローリング・アップグレード

『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースへのフィジカル・スタンバイ・データベースの変換および既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行

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

Oracle Patchの保証 - Data Guard Standby-First Patch適用(Doc ID 1265700.1)

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

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

関連項目:

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

変更管理手順の確立

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

変更をレビューし、変更管理チームからフィードバックと承認を取得します。

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

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

さらに、Oracleヘルス・チェック・ツール

orachk

(非エンジニアド・システムおよびOracle Database Applianceをサポート)および

exachk

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

関連項目:

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』を参照してください。

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

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

スタンバイ・データベースとしてOracle GoldenGateレプリカを使用している場合でも、Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)、ZFS Storage、または別のサード・パーティのデータベース・バックアップを利用している場合でも、操作およびデータベース管理チームは、事前に設定したしきい値に従って、プライマリ・データベースの停止またはパフォーマンス低下時にいつでもデータベースとアプリケーションをフェイルオーバーまたは復元できるよう十分に準備しておくことが重要です。関係するチームは、それらを検出し、必要に応じてフェイルオーバーまたはリストアすることを決断できる必要があります。障害時に効率的に対応できると、全体的な停止時間が大幅に短縮されます。

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

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

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

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

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

関連項目:

MAAのWebページ(http://www.oracle.com/goto/maa)

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

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

高可用性環境を維持するには、停止時間が発生する前に、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャを構成する必要があります。

また、可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したディスク、フラッシュ・カード、ファン、電源などのハードウェア・コンポーネントを置き換えることができます。

• データベース・ヘルス・チェックの定期的な実行
  Oracle Databaseのヘルス・チェックは、ハードウェアおよびソフトウェアの構成とベスト・プラクティスに対するMAAの準拠を評価するように設計されています。
• 高可用性Oracle Enterprise Manager監視インフラストラクチャの構成
  可能性のある停止時間を回避するには、Enterprise Managerと、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャの両方を構成および使用する必要があります。
• 自動サービス要求インフラストラクチャの構成
  Oracle高可用性環境でのEnterprise Managerによる監視インフラストラクチャに加えて可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したハードウェアを置き換えることができます。

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

Oracleデータベース・ヘルス・チェックは、ハードウェアおよびソフトウェアの構成とベスト・プラクティスに対するMAA準拠を評価するように設計されています。

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

Oracleでは、定期的に(たとえば、Exadata Database Machineの場合毎月)最新のデータベース・ヘルス・チェックのダウンロードと実行、および主要なFAILURES、WARNINGS、およびINFOメッセージへの対処をお薦めしています。ツール

exachk

はOracle Exadata Database Machine、Exalogic、Zero Data Loss Recovery ApplianceおよびBig Data Applianceなどのエンジニアド・システムに対して使用し、

orachk

は非エンジニアド・システムおよびOracle Database Applianceに対して使用します。

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

次のことを評価する必要があります。

• 計画内メンテナンス・ウィンドウより前の既存のまたは新しい重要なヘルス・チェック・アラート

• テスト後の計画内メンテナンス・ウィンドウへの新しい推奨事項の追加

• 既存のソフトウェアまたは重要なソフトウェアの推奨事項

関連項目:

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』を参照してください。

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

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

監視インフラストラクチャを使用すると、ユーザーは高可用性を監視しやすくなり、次の作業も実行できます。

• システム、ネットワーク、アプリケーション、データベースおよびストレージの統計の監視

• パフォーマンスおよびサービスの統計の監視

• システムまたはアプリケーションの問題の初期警告インジケータとなる、パフォーマンスおよび高可用性のしきい値の作成

• パフォーマンスおよび可用性アドバイスの提供

• 確立されたアラート、ツール、およびデータベース・パフォーマンス

• 設計されたシステムのハードウェア障害のアラートの受信

関連項目:

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

Enterprise ManagerのMAAベスト・プラクティス(http://www.oracle.com/goto/maa)

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

Oracle高可用性環境でのEnterprise Managerによる監視インフラストラクチャに加えて可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したハードウェアを置き換えることができます。

たとえば、Oracle Automatic Service Request (ASR)は安全かつスケーラブルな、ユーザーがインストール可能なソフトウェア・ソリューションで、これは機能として使用できます。特定のハードウェア障害が発生したとき、OracleのSolarisサーバーおよびストレージ・システムの自動ケース生成を使用することで、このソフトウェアでは問題をより早く解決します。

関連項目:

My Oracle Supportのノート1185493.1 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1185493.1)の「Oracle自動サービス要求」を参照してください

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

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

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