| Oracle® Database高可用性概要 12cリリース1 (12.1) B71280-03 |
|
 前 |
 次 |
MAAの実装を成功させるには、運用ベスト・プラクティスを使用します。
この章の内容は次のとおりです。
高可用性およびパフォーマンスに関するサービス・レベル合意(SLA)を理解して文書化します。
第1章「高可用性の概要」に示すように、高可用性の属性と、停止時間の様々な原因を理解します。
2.1項「高可用性要件」および2.2項「高可用性要件を文書化する方法」に示すように、部門、経営幹部および高可用性とパフォーマンスに関するサービス・レベル合意の技術チームから同意を得ます。
高可用性とパフォーマンスに関するサービス・レベル合意の同意を得たら、第2章「高可用性およびデータ保護 - 要件からのアーキテクチャの取得」に示すように、標準で検証済のOracleのアーキテクチャの1つに要件をマップします。第4章「計画外停止時間用Oracle Database高可用性ソリューション」および第5章「計画停止時間用Oracle Database高可用性ソリューション」にあるアーキテクチャに類似した、MAA参照アーキテクチャに関連する停止と計画メンテナンスのマトリックスを評価してください。選択したMAA参照アーキテクチャの詳細は、第7章「高可用性アーキテクチャ」を参照してください。
|
関連項目:
|
修復作業を検証および自動化して、ターゲット高可用性の品質保証契約(SLA)に準拠していることを確認します。バックアップ、リストアおよびリカバリの操作を検証して、可能性のある各種の停止に対するすべての修復作業を定期的に評価します(詳細は表4-1、表4-2、表5-7および表5-8を参照してください)。
Data Guardを障害回復とデータ保護に使用する場合は、定期的なスイッチオーバー作業を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実施することをお薦めします。また、アプリケーションおよびData Guardのスイッチオーバーを定期的に実行して、すべてのロール移行手順を完全に検証します。
よいテスト環境や適切なテスト・プラクティスは、本番環境で最高の安定性と可用性を達成するための重要な前提条件です。テスト環境であらゆる変更を完全に検証することで、本番で同じ変更を適用する前に、問題を事前に検知して防ぐことができます。
実際の作業には次のようなものがあります。
テスト・システムは本番MAA環境のレプリカ(MAAのGold層を使用するなど)にする必要があります。テスト・システムが、選択したMAAサービス・レベルで運用される標準の参照アーキテクチャと同一でない場合は、トレードオフがあります。本番をまねたワークロードで、機能、パフォーマンスおよび可用性テストを実行することをお薦めします。可用性とパフォーマンスSLA (6.1項参照)が各変更後も維持されているかを評価し、本番環境に変更を適用している間になにか失敗した場合に、明確なフォールバックまたは修復プロシージャの準備が整っていることを確認します。
適切に構成されたテスト・システムによって、多くの問題を回避できます。変更が検証されるのは同等の本番およびスタンバイ・データベース構成で、これには完全なデータ・セットが含まれ、本番を模倣するためのワークロード・フレームワーク(たとえば、Oracle Real Application Testing)が使用されるためです。
テスト・システムの廃止によってコストを削減しようとしないでください。この決断は後々、本番アプリケーションの安定性と可用性に影響を及ぼすことになります。テストおよびQAのためにシステム・リソースのサブセットのみを使用すると、表6-1に示されているトレードオフがあります(MAAのGold層の例です)。
表6-1 各種のテストおよびQA環境のトレードオフ
| テスト環境 | 利点とトレードオフ |
|---|---|
|
本番システムとスタンバイ・システムの完全レプリカ |
すべてのパッチとソフトウェアの変更を検証します。 すべての機能テストを検証します。 本番スケールにおける完全パフォーマンス検証。 完全な高可用性の検証。 |
|
本番システムの完全レプリカ |
すべてのパッチとソフトウェアの変更を検証します。 すべての機能テストを検証します。 本番スケールにおける完全パフォーマンス検証。 完全な高可用性検証からスタンバイ・システムをマイナスしたもの。 スタンバイ・データベースによる機能、パフォーマンス、高可用性および障害時リカバリの検証はなし。 |
|
スタンバイ・システム |
ほとんどのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。 Data Guardスナップショット・スタンバイの使用時は、完全なパフォーマンス検証。ただし、フェイルオーバーが必要な場合はリカバリ時間が長くなる可能性があります。 ロール移行の検証。 スタンバイ・データベースとテスト・データベースが同じシステムに存在する場合は、リソース管理およびスケジューリングが必要です。 |
|
共有システム・リソース |
ほとんどのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。 本番の模倣に十分なシステム・リソースを割当てできれば、この環境はパフォーマンス・テストに適している場合があります。 ただし、通常は、環境に本番システム・リソースのサブセットが含まれ、パフォーマンスの検証には欠落が生じます。 リソース管理およびスケジューリングが必要です。 |
|
システム・リソースの小規模バージョンまたはサブセット |
すべてのパッチとソフトウェアの変更を検証します。すべての機能テストを検証します。 本番スケールにおけるパフォーマンス・テストなし。 限定的な、完全スケールの高可用性評価。 |
|
異なるハードウェアまたはプラットフォームのシステム・リソース(同一オペレーティング・システム) |
ほとんどのパッチとソフトウェアの変更を検証します。限定的な、ファームウェア・パッチ適用テスト。 すべての機能テストを、ハードウェアの新機能で制限されていないかぎり、検証します。 限定的な、本番スケールのパフォーマンス・テスト。 限定的な、完全スケールの高可用性評価。 |
|
関連項目: 『Oracle Databaseテスト・ガイド』 |
ハードウェア、ソフトウェア、データベース、アプリケーションまたはすべての変更を本番前に検証およびテストすることは、安定性を維持するために重要です。上位レベルの本番前検証の手順は次のとおりです。
パッチまたはアップグレードのドキュメントや、対象の変更に関連するドキュメントを確認します。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適用および一時ロジカル・スタンバイ方式の詳細は、3.1.3.1項「Data Guard REDO適用およびStandby-First Patchの適用」および3.1.3.2項「Data Guard一時ロジカル・ローリング・アップグレード」を参照してください。
本番環境で変更を適用します。
|
関連項目:
|
適切なセキュリティ基準のないシステムまたはデータベースに配置された企業データは、深刻なリスクに直面している可能性があります。明確に定義されたセキュリティ・ポリシーは、システムに対する不正アクセスを遮断し、企業の機密情報を破壊行為から保護するのに役立ちます。適切なデータ保護により、セキュリティの侵害によるシステム停止の可能性を抑制できます。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
システムの安定性を維持し、テスト・システムまたはMAAサービスレベル層の基本アーキテクチャのいずれかで厳密に評価されるまで変更がプライマリ・データベースに適用されないように、変更を管理および制御する手順を設けます。
変更を確認して、変更管理チームからフィードバックと承認を受け取ります。このチームにはビジネス要件、機能性、パフォーマンスおよびシステムの可用性に影響する、あらゆるコンポーネントの代表が含まれることが必要です。たとえば、チームにはエンドユーザー、アプリケーション、データベース、ネットワークおよびシステムの代表を含むことができます。
最新の推奨パッチおよびソフトウェア・バージョンに対する定期的なテストと適用によって、最新のセキュリティおよびソフトウェアの修正がシステムで確実に行われるようにします。これは、安定性を維持し、多くの既知の問題を回避するために必要です。本番システムでアップグレードを実行する前に、テスト・システムですべての更新および変更を必ず検証してください。
さらに、orachk (単一インスタンスおよびOracle RACシステムをサポート)、odachk (Oracle Data Applianceシステムをサポート)およびexachk (Oracle Exadata Database MachineおよびOracle SuperClusterシステムをサポート)などのOracleヘルス・チェック・ツールにより、重要なソフトウェア更新の推奨事項が提供されます。
|
関連項目:
|
スタンバイ・データベースがある場合、事前に定められたしきい値に従って、プライマリ・データベースが停止または機能が低下した場合はいつでもスタンバイ・データベースを使用できるように、運用およびDBAチームが十分に準備できていることが重要です。効率的に応答および実行すること(フェイルオーバーの検知と決定が含まれます)で、全体的な停止時間を時間単位から分単位に削減できます。
Data Guardを高可用性、障害時リカバリ、データ保護のために使用する場合、3～6か月ごとに定期的なスイッチオーバーの操作を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実行することをお薦めします。
|
関連項目: My Oracle Supportに用意されているData Guardスイッチオーバーのためのノートは次のとおりです。
|
修復を妨げないためのエスカレーション管理手順を確立します。ほとんどの修復ソリューションは、適切に実施されていればMAAソリューションで自動的かつ透過的です。問題が発生するのは、プライマリ・データベースまたはシステムが可用性またはパフォーマンスのSLAに適合せず、フェイルオーバー手順がData Guardの一部のフェイルオーバー・シナリオのように自動で行われるのではない場合です。適切なエスカレーション・ポリシーが施行されず、決定が迅速に行われないと、停止時間が長引く可能性があります。
可用性が最優先である場合、修復およびフェイルオーバー操作を最初に実行し、アプリケーション・サービスが再構築されてから、根本原因分析(RCA)用のログおよび情報の収集を続行します。
|
関連項目:
|
高可用性環境を維持するには、停止時間が発生する前に、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャを構成する必要があります。また、可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したディスク、フラッシュ・カード、ファン、電源などのハードウェア・コンポーネントを置き換えることができます。
Oracleデータベース・ヘルス・チェックは、ハードウェアおよびソフトウェアの構成とベスト・プラクティスに対するMAA準拠を評価するように設計されています。Oracleヘルス・チェック・ツールはすべて、Oracle Grid Infrastructure、Oracle Databaseを評価し、自動MAAスコアカードを提供するか、または主要なアーキテクチャおよび構成の設定が失敗に対する耐性がない、または高速リカバリに対応していない場合にその強調部分を確認します。Exadata Database MachineなどのOracleの設計されたシステムには、数百の追加のソフトウェア、エラーおよび構成のチェックが存在します。
Oracleでは、定期的に(たとえば、Exadata Database Machineの場合毎月)最新のデータベース・ヘルス・チェックのダウンロードと実行、および主要なFAILURES、WARNINGS、およびINFOメッセージへの対処をお薦めしています。ExadataおよびOracle SuperClusterエンジニアド・システムではexachkを使用し、Oracle Database Applianceではodachk、および単一インスタンス環境を含むその他のOracleデータベース・デプロイメントではorachkを使用します。
さらに、計画メンテナンス・アクティビティの前と後に、ヘルス・チェックを実行することもお薦めします。
|
関連項目:
|
可能性のある停止時間を回避するには、Enterprise Managerと、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャの両方を構成および使用する必要があります。監視インフラストラクチャを使用すると、ユーザーは高可用性を監視しやすくなり、次の作業も実行できます。
システム、ネットワーク、アプリケーション、データベースおよびストレージの統計の監視
パフォーマンスおよびサービスの統計の監視
システムまたはアプリケーションの問題の初期警告インジケータとなる、パフォーマンスおよび高可用性のしきい値の作成
パフォーマンスおよび可用性アドバイスの提供
確立されたアラート、ツール、およびデータベース・パフォーマンス
設計されたシステムのハードウェア障害のアラートの受信
Oracle高可用性環境でのEnterprise Managerによる監視インフラストラクチャに加えて可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したハードウェアを置き換えることができます。たとえば、Oracle Automatic Service Request (ASR)は安全かつスケーラブルな、ユーザーがインストール可能なソフトウェア・ソリューションで、これは機能として使用できます。特定のハードウェア障害が発生したとき、OracleのSolarisサーバーおよびストレージ・システムの自動ケース生成を使用することで、このソフトウェアでは問題をより早く解決します。
|
関連項目: My Oracle Supportのノート1185493.1『Oracle自動サービス要求』
|
Oracle Databases、Exadata Database Machine、Oracle SuperCluster、Oracle Fusion Middleware、Oracle Applications、およびOracle Enterprise Manager Grid Controlに対するMAAソリューションおよびベスト・プラクティスは、継続的に開発され、Oracle Technology Network (OTN)で公開されています
