| Oracle Database高可用性ベスト・プラクティス 11gリリース2(11.2) B65088-05 |
|
 前 |
 次 |
MAAの実装を成功させるには、運用ベスト・プラクティスを使用します。
この章には、次の項目が含まれます。
高可用性およびパフォーマンスに関する品質保証契約(SLA)を理解して文書化し、停止およびソリューション・マトリックスを作成します。
『Oracle Database高可用性概要』に記載されているシステム停止における、停止時間、リカバリ時間目標(RTOまたはリカバリ時間)、およびリカバリ・ポイント目標(RPOまたはデータ損失許容度)のビジネス上のコストを文書化します。
表13-1「プライマリ・サイトでの計画外の停止のリカバリ時間および手順」と表14-1「プライマリ・サイトでの計画済の停止のソリューション」に示されているものと同様の、停止およびソリューション・マトリックスを構築します。
最適な高可用性アーキテクチャを構築するための高可用性環境を実装します。
ソフトウェアのインストール、または最新の認定パッチ・セットによるソフトウェアの更新
ベスト・プラクティスを使用したソフトウェアの構成
選択内容と構成の文書化
修復作業を検証および自動化して、ターゲットHAの品質保証契約(SLA)に準拠していることを確認します。バックアップ、リストアおよびリカバリの操作を検証して、可能性のある各種の停止に対するすべての修復作業を定期的に評価します(詳細は表13-1を参照してください)。
Oracle Data Guardを障害回復とデータ保護に使用する場合は、定期的なスイッチオーバー作業を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実施することをお薦めします。また、アプリケーションおよびData Guardのスイッチオーバーを定期的に実行して、すべてのロール移行手順を完全に検証します。詳細は、2.8項「Data Guardのロール移行の実行」を参照してください。
適切なセキュリティ基準のないシステムまたはデータベースに配置された企業データは、深刻なリスクに直面している可能性があります。明確に定義されたセキュリティ・ポリシーは、システムに対する不正アクセスを遮断し、企業の機密情報を破壊行為から保護するのに役立ちます。適切なデータ保護により、セキュリティの侵害によるシステム停止の可能性を抑制できます。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
システムの安定性を維持し、テスト・システムで厳密に評価されるまで変更がプライマリ・データベースに適用されないように、変更を管理および制御する手順を設けます。
変更を確認して、変更管理チームからフィードバックと承認を受け取ります。このチームにはビジネス要件、機能性、パフォーマンスおよびシステムの可用性に影響する、あらゆるコンポーネントの代表が含まれることが必要です。たとえば、チームにはエンドユーザー、アプリケーション、データベース、ネットワークおよびシステムの代表を含むことができます。
最新の推奨パッチおよびソフトウェア・バージョンに対する定期的なテストと適用によって、最新のセキュリティおよびソフトウェアの修正がシステムで確実に行われるようにします。これは、安定性を維持し、多くの既知の問題を回避するために必要です。本番システムでアップグレードを実行する前に、テスト・システムですべての更新および変更を必ず検証してください。詳細は、次のWebサイトのMy Oracle Support Note 756671.1の『Oracle推奨パッチ - Oracle Database』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=756671.1
適切なテストとパッチ適用は安定性を維持するための重要な前提条件です。変更はすべてテスト・システムで完全に検証してから、本番環境に適用する必要があります。実際の作業には次のようなものがあります。
テスト・システムは機能テスト、パフォーマンス・テストおよび可用性テストを実行することを目的とした、本番およびスタンバイの環境とワークロードの精密なレプリカです(詳細は表13-1を参照してください)。変更はすべて、変更の効果とフォールバック手順の評価も含めて最初にテスト環境で検証してから、本番環境にその変更を導入する必要があります。
適切に構成されたテスト・システムによって、多くの問題を回避できます。変更が検証されるのは同等の本番およびスタンバイ・データベース構成で、これには完全なデータ・セットが含まれ、本番を模倣するためのワークロード・フレームワーク(たとえば、Oracle Real Application Testing)が使用されるためです。
テスト・システムの廃止によってコストを削減しようとしないでください。この決断は後々、本番アプリケーションの安定性と可用性に影響を及ぼすことになります。テストおよびQAのためにシステム・リソースのサブセットのみを使用すると、表2-1に示されているトレードオフがあります。
表2-1 各種のテストおよびQA環境のトレードオフ
| テスト環境 | 利点とトレードオフ |
|---|---|
|
本番システムとスタンバイ・システムの完全レプリカ |
すべてのパッチとソフトウェアの変更を検証します。 すべての機能テストを検証します。 本番スケールにおける完全パフォーマンス検証。 完全HA検証。 |
|
本番システムの完全レプリカ |
すべてのパッチとソフトウェアの変更を検証します。 すべての機能テストを検証します。 本番スケールにおける完全パフォーマンス検証。 完全HA検証からスタンバイ・システムをマイナスしたもの。 スタンバイ・データベースによる機能、パフォーマンス、HAおよび障害回復の検証はなし。 |
|
スタンバイ・システム |
ほとんどのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。 Data Guardスナップショット・スタンバイの使用時は、完全なパフォーマンス検証。ただし、フェイルオーバーが必要な場合はリカバリ時間が長くなる可能性があります。 ロール移行の検証。 スタンバイ・データベースとテスト・データベースが同じシステムに存在する場合は、リソース管理およびスケジューリングが必要です。 |
|
共有システム・リソース |
ほとんどのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。 本番の模倣に十分なシステム・リソースを割当てできれば、この環境はパフォーマンス・テストに適している場合があります。 ただし、通常は、環境に本番システム・リソースのサブセットが含まれ、パフォーマンスのテスト/検証には欠落が生じます。 リソース管理およびスケジューリングが必要です。 |
|
システム・リソースの小規模バージョンまたはサブセット |
すべてのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。 本番スケールにおけるパフォーマンス・テストなし。 限定的な、完全スケールの高可用性評価。 |
|
異なるハードウェアまたはプラットフォームのシステム・リソース(同一オペレーティング・システム) |
ほとんどのパッチとソフトウェアの変更を検証します。限定的な、ファームウェア・パッチ適用テスト。 すべての機能テストを、ハードウェアの新機能で制限されていないかぎり、検証します。 限定的な、本番スケールのパフォーマンス・テスト。 限定的な、完全スケールの高可用性評価。 |
|
関連項目: 『Oracle Database Real Application Testingユーザーズ・ガイド』 |
ソフトウェア・パッチまたはすべての変更を本番前に検証およびテストすることは、安定性を維持するために重要です。上位レベルの本番前検証の手順は次のとおりです。
パッチまたはアップグレードのドキュメントや、対象の変更に関連するドキュメントを確認します。SLAで停止時間をゼロまたは最小限にすることが必要な場合、ローリング・アップグレードの実行の可能性を評価します。計画済停止時間を最小化または排除するローリング・アップグレードの機会を評価します。パッチがStandby-First Patchingに適格かどうか評価します。
|
注意: Standby-First Patchを使用すると、プライマリ・データベースは以前のソフトウェア・リリースのまま、パッチを最初にフィジカル・スタンバイ・データベースに適用できます(この適用対象は特定のパッチ・タイプで、Oracleパッチ・セットおよびメジャー・リリース・アップグレードには適用されません。パッチ・セットおよびメジャー・リリースにはData GuardのTransient Logical Standbyメソッドを使用してください)。変更作業が終了したら、スタンバイ・データベースへのスイッチオーバーを実行します。フォールバックは必要な場合にスイッチオーバーすることです。もう1つの方法として次の手順に進み、本番環境に変更を適用することもできます。詳細は、次のWebサイトのMy Oracle Support Note 1265700.1の『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。
|
テスト環境でアプリケーションを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。手順を自動化して、フォールバック手順の文書化およびテストも確認します。これには、テストでパッチ適用の前後に取得されたメトリックを、本番システムで取得されたメトリックと比較することが必要です。Real Application Testingは、本番システムでワークロードを取得し、それをテスト・システムで再現するために使用できます。AWRとSQLパフォーマンス・アナライザは、パッチによって引き起こされたパフォーマンスの向上または低下を評価するために使用できます。
本番環境を模倣するテスト・システムで新規ソフトウェアを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。パッチまたはアップグレードの手順を自動化して、フォールバックを確認します。この手順を一通り実施することで、パッチまたはアップグレードの実施中および実施後における最も致命的な問題を回避できます。
テスト・システムの構成の詳細は、2.7.1項「テスト・システムおよびQA環境の構成」を参照してください。
任意でOracle Real Application Testingオプションを使用すると、Oracle Databaseを現実的な環境でテストできます。Oracle Real Application Testingは、本番環境へのデプロイメントを行う前に、本番環境でのワークロードを取得し、システムの変更による影響を評価することで、その変更が原因で不安定になるリスクを最小限にします。Oracle GoldenGateは、変更を適用するためのもう1つのロジカル・レプリカとして使用することもできます。
テスト・システムの構成の詳細は、2.7.1項「テスト・システムおよびQA環境の構成」を参照してください。
適用可能な場合、すべての変更の最終的な本番前検証をData Guardスタンバイ・データベースで実行してから、それを本番に適用してください。適用可能な場合、Oracle Data Guard環境で変更を適用します。Data Guardの一時ロジカル・スタンバイ・メソッドの詳細は、14.2.6項「データベースのアップグレード」を参照してください。
本番環境で変更を適用します。
|
関連項目:
|
スタンバイ・データベースがある場合、事前に定められたしきい値に従って、プライマリ・データベースが停止または機能が低下した場合はいつでもスタンバイ・データベースを使用できるように、運用およびDBAチームが十分に準備できていることが重要です。効率的に応答および実行すること(フェイルオーバーの検知と決定が含まれます)で、全体的な停止時間を時間単位から分単位に削減できます。
Oracle Data Guardを障害回復とデータ保護に使用する場合は、四半期ごとに定期的なスイッチオーバー作業を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実施することをお薦めします。Oracle Data Guardの構成とロール移行のベスト・プラクティスの詳細は、第9章「Oracle Data Guardの構成」と9.4.1項「Oracle Data Guardのスイッチオーバーのベスト・プラクティス」を参照してください。
|
関連項目: My Oracle Supportに用意されているData Guardスイッチオーバーのためのノートは次のとおりです。
|
修復を妨げないためのエスカレーション管理手順を確立します。ほとんどの修復ソリューションは、適切に実施されていればMAAソリューションで自動的かつ透過的です。問題が発生するのは、プライマリ・データベースまたはシステムが可用性またはパフォーマンスのSLAに適合せず、フェイルオーバー手順がData Guardの一部のフェイルオーバー・シナリオのように自動で行われるのではない場合です。適切なエスカレーション・ポリシーが施行されず、決定が迅速に行われないと、停止時間が長引く可能性があります。
可用性は最優先課題であり、今後の根本原因分析(RCA)のために十分なデータを収集するための代替計画を作成する必要があります。
MAAの停止および修復の詳細は、次のOracle Technology Network(OTN)でMAA Webページを確認してください。
高可用性環境を維持するには、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャを構成する必要があります。また、可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したハードウェアを置き換えることができます。
可能性のある停止時間を回避するには、Enterprise Managerと、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャの両方を構成および使用する必要があります。監視インフラストラクチャを使用すると、ユーザーは高可用性を監視しやすくなり、次の作業も実行できます。
システム、ネットワーク、アプリケーション、データベースおよびストレージの統計の監視
パフォーマンスおよびサービスの統計の監視
システムまたはアプリケーションの問題の初期警告インジケータとなる、パフォーマンスおよび高可用性のしきい値の作成
Oracle HA環境でのEnterprise Managerによる監視インフラストラクチャに加えて可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したハードウェアを置き換えることができます。たとえば、Oracle Auto Service Request (ASR)は安全かつスケーラブルな、ユーザーがインストール可能なソフトウェア・ソリューションで、これは機能として使用できます。特定のハードウェア障害が発生したとき、OracleのSunサーバーおよびストレージ・システムの自動ケース生成を使用することで、このソフトウェアでは問題をより早く解決します。
|
関連項目: 次のWebサイトのMy Oracle Support Note 1185493.1の「Oracle Auto Service Request」を参照してください。
|
