インフラストラクチャ・メンテナンスについて

Oracleは、Oracle Data Infrastructure Cloud@Customer上のすべてのOracle管理インフラストラクチャ・コンポーネントを定期的に更新します。

Oracleでは、ベスト・プラクティスに従った自動化されたプロセスを使用して、製品の修正とセキュリティ修正を適用します。これらの更新は、データの保護と、データベースの可用性、整合性、セキュリティおよびOracle Cloudのコンプライアンス要件のサポートに役立ちます。自動化されたメンテナンスにより、インフラストラクチャのメンテナンスに必要な労力も削減されます。

Oracle管理コンポーネントには、物理サーバー・ホスト、ストレージ、ネットワーク・カード、Integrated Lights Out Management (ILOM)インタフェースおよびコントロール・プレーン・プロキシ・サービス・仮想マシンを含めることができます。

Oracleは3か月ごとに四半期メンテナンスを実行し、製品の修正、拡張機能およびセキュリティ修正を含めることができます。

Oracleでは、まれな例外的な状況を除き、スケジュール済メンテナンスの事前通知を提供しています。Oracleでは、VMクラスタ内の対応する推奨更新の通知も提供されます。

Oracleでは、メンテナンスをスケジュールして、可能な場合はサービスの可用性を維持します。一部の更新は、個々のコンポーネントが使用できない間、パフォーマンスとスループットに一時的に影響することがあります。たとえば、サーバーへのパッチ適用には通常、再起動が必要です。Oracleは、可能な場合はローリング順序でサーバーを再起動するため、更新プロセス中もサービスを使用できます。各サーバーは再起動中も短時間使用できなくなり、全体的なサービス容量が削減されます。アプリケーションが再起動を許容できない場合の緩和を計画します。たとえば、サーバーのパッチ適用中にアプリケーションをシャットダウンします。

四半期メンテナンス

Oracleでは、更新プロセス全体でデータベースの可用性を維持するローリング・メンテナンス操作を使用することで、アプリケーションに対する四半期メンテナンスの影響を最小限に抑えます。高可用性を実現するために設計されたアプリケーションは、中断することなくデータベース接続を使用可能なインスタンスに自動的に透過的に移行するため、ダウンタイムをスケジュールする必要がなくなります。

Oracleは、Oracle定義のメンテナンス・ポリシーに従ってメンテナンスをスケジュールします。予期しないビジネス要件が発生した場合は、メンテナンスを再スケジュールできます。

デフォルトでは、インフラストラクチャのメンテナンスは、サーバーから開始してストレージを更新し、ローリング更新を使用して実行されます。

サーバーは一度に1つずつ更新され、サーバーはいつでもオフラインになります。各ホストについて、VMが停止し、サーバーが更新および再起動され、その後、VMが起動され、他のサーバーは動作し続けます。このアプローチは、高可用性のために設計されたアプリケーションには影響しませんが、ローリング・インスタンスの再起動を処理するために書き込まれていない古いアプリケーションに影響を与える可能性があります。このプロセスは、両方のサーバーが更新されるまで続行されます。

サーバーの保守が完了すると、ストレージの保守が開始されます。ストレージディスクは一度に1つずつ更新されます。ストレージへのパッチ適用は、データベースの可用性には影響しないため、アプリケーションには影響しません。ただし、ローリング・ストレージ・メンテナンスによって、ストレージ・ディスクがオフライン(使用可能なI/O容量が減少)の間、およびサービスに戻った後に再同期される間(データ・インフラストラクチャ・サーバーではわずかなオーバーヘッドで)I/Oパフォーマンスが低下する可能性があります。メンテナンス中でないサーバーでの追加作業に対応するために、データベースおよびストレージを適切にサイズ設定すると、パフォーマンスへの影響を最小限に抑えるか、排除します。

ローリング・メンテナンス中は、データベースが使用可能であることが想定されますが、自動化メンテナンスではOracle Clusterwareが実行中であるすることは検証しますが、サーバーがオンラインに戻った後にすべてのデータベース・サービスおよびプラガブル・データベースの(PDB)が使用可能であるとは検証しません。メンテナンス後のデータベース・サービスおよびPDBの可用性が、サービス定義に依存する可能性があります。たとえば、優先ノードと使用可能ノードで構成されたデータベース・サービスは、メンテナンス中に再配置され、メンテナンスの完了後に元のノードに自動的に再配置されない場合があります。Oracleでは、潜在的な影響を軽減するために、アプリケーションの継続的な可用性を実現するためのドキュメントを確認することをお薦めします。ガイドラインに従うことで、サーバーが順次更新されるため、インフラストラクチャ・メンテナンスの影響はマイナー・サービスの低下に限定する必要があります。

Oracleでは、Maximum Availability Architecture (MAA)のベストプラクティスに従うことと、Data Guardを使用して重要なアプリケーションの最高可用性を確保することをお薦めします。Data Guardが有効なデータベースの場合、Oracleでは、プライマリ・データベースとスタンバイ・データベースを実行しているデータ・インフラストラクチャのメンテナンス・ウィンドウを分離することをお薦めします。また、プライマリ・データベースをホストしているデータ・インフラストラクチャでメンテナンスの前にスイッチオーバーを実行して、インフラストラクチャ・メンテナンス中のプライマリ・データベースへの影響を回避することもできます。

メンテナンス・ウィンドウがメンテナンスの成功を妨げる可能性のある問題を識別し始める前に、Oracle Data Infrastructure Cloud@Customerインフラストラクチャ・コンポーネントで事前チェックが実行されます。インフラストラクチャおよびすべてのコンポーネントは、事前チェック中もオンラインのままです。初期事前チェックは、メンテナンス開始の約2週間前に実行され、別の事前チェックはメンテナンス開始の約24時間前に実行されます。事前チェックで再スケジュールが必要な問題が識別されると、通知をサブスクライブしたユーザーに通知が送信されます。

メンテナンスWindowsの最小化

• メンテナンス・ウィンドウの数を最小限に抑えるため(エンド・ユーザーとのネゴシエーションが必要)、四半期メンテナンスを同時にスケジュールします。セキュリティ・メンテナンスはブロックされます。四半期メンテナンスでは、データ・インフラストラクチャ・サーバーがローリング方式で更新され、ストレージ・サーバーがスキップされる可能性が高くなります。セキュリティ・メンテナンスはすぐに追跡され、ローリング方式でデータ・インフラストラクチャ・サーバーとストレージ・サーバーがオンラインに更新されます。結果として、単一のメンテナンス・ウィンドウでデータベースおよびストレージ・サーバーが再起動されます。

• これには、2つの例外があります。

  • 四半期メンテナンスに同じストレージ・サーバー・リリースが含まれている場合、四半期メンテナンスによってストレージ・サーバーの更新が適用され、セキュリティ・メンテナンスはスキップされます。これも、単一のメンテナンス・ウィンドウでの1回のローリング再起動です。
  • ストレージ・サーバーに現在インストールされているリリースは、四半期メンテナンスに含まれているリリースより古く、セキュリティ・メンテナンスのリリースより古くなっています。これにより、四半期ごとのメンテナンスでストレージが更新され、セキュリティ・メンテナンスでストレージも更新されます。これは、前月のセキュリティ・メンテナンスをスキップした場合にのみ発生する可能性があります。これは、現在のイメージが少なくとも2か月遅れている必要があるためです。このようなシナリオでは、最初にセキュリティ・メンテナンスをスケジュールし、次に四半期メンテナンスをスケジュールできます。これにより、1つのストレージ・サーバーが再起動されますが、2つの異なるメンテナンス・ウィンドウ(最初にセキュリティ・メンテナンス用、次に四半期メンテナンス用)が再起動されます。
• データ・インフラストラクチャがOracleによってセキュリティ・メンテナンスがスケジュールされる前にプロビジョニングされた場合、そのデータ・インフラストラクチャはセキュリティ・メンテナンスの対象となります。