Exadata Cloud Infrastructureデプロイメントの開始

Exadata Cloud Infrastructureの準備の準備タスクを完了したら、次の手順に従ってExadata Cloud Infrastructureシステムのデプロイを開始します。

Oracle Exadata Database Service on Dedicated Infrastructureリソースのタグ付け

タグ付けはOracle Cloud Infrastructure (OCI)向けの強力な基盤サービスであり、タグに基づいて一連のリソースに対する検索、アクセス制御および一括アクションを実行できます。

タグ付けの重要性

Oracle Cloud Infrastructure (OCI)タグ付けシステムを使用すると、組織のスキームに従ってリソースにタグ付けできるため、リソースのグループ化、コストの管理および使用状況に関するインサイトの取得が可能になります。また、タグは、セキュリティおよび最大可用性アーキテクチャ(MAA)に関するガバナンス・モデルを構築するのに役立ちます。組織がクラウド環境を拡大するにつれて、デプロイメント・アーキテクチャ、セキュリティのベスト・プラクティス、MAA、アプリケーション層などをトラッキングすることが困難になる場合があります。メタデータ・タグを使用してワークロード属性を識別すると、コスト超過なしでテナンシのセキュリティと可用性を最新状態に維持できます。

お客様がOCIリソースを安全かつコスト効率よく管理できるように、リソースのタグ付けのベスト・プラクティスに沿った一連の事前定義済タグが用意されています。これらのタグは、oracleStandardネームスペースとOracleApplicationNameネームスペースの2つのネームスペースにグループ化されます。タグ・ネームスペースは、タグ・キーのコンテナと見なすことができます。

組織に複数のクラウド・リソース(テナンシ内の複数のコンパートメントにまたがるExadataインフラストラクチャ、VMクラスタ、DBホーム、Oracle DatabaseおよびVM Cluster Networksなど)があるシナリオを考えてみます。これらのクラウド・リソースを特定の目的で追跡したり、レポートしたり、一括アクションを実行するとします。その場合、環境、クリティカル度、ターゲット・ユーザー、アプリケーションなどの様々な基準に基づいてこれらのリソースをグループ化できるシステムが必要です。これを実現するには、これらのリソースに適切なタグを適用します。

たとえば、開発スタック内のすべてのリソースにOracle-Standard.Environment=Devでタグ付けしたり、ビジネスクリティカルなアプリケーション・スタックにOracle-Standard.Criticality=HighまたはExtremeを設定できます。様々な理由でサービスが中断した場合、アプリケーションまたはビジネス機能に関連付けられているすべてのOCIリソースを迅速に識別したり、クリティカルなワークロードとクリティカルでないワークロードを分離することができます。

タグ付けは、タグで識別されたワークロード属性に基づいて最適化された構成をデプロイする場合にも役立ちます。たとえば、PeopleSoftアプリケーションのデータベース・デプロイメントには特定の構成が必要です。Oracle Databaseのデプロイ時にApplicationNameおよびAppMajorVersionタグを設定すると、データベースを構成して、PeopleSoftなどの特定のアプリケーションで即時利用できるように準備できます。

さらに、クラウド・アドバイザOCIサービスと統合することで、クラウド・サービスが企業のガイドラインにどの程度準拠しているかを直接かつ深く知ることができ、経営陣がビジョンを持ってガバナンスを行うことができるようになります。詳細は、クラウド・アドバイザの概要を参照してください。

タグの追加

リソースには、Oracle Cloud Infrastructure (OCI)コンソール、コマンドライン・インタフェースまたはSDKを使用してタグ付けできます。

Oracle Exadata Database Service on Dedicated Infrastructureデプロイメントでタグ付けできるクラウド・リソースは多数あります。Exadataインフラストラクチャ、VMクラスタ、DBホーム、Oracle Database、Autonomous Exadata VMクラスタ、Autonomous Container Database、Autonomous DatabaseおよびVMクラスタ・ネットワークはその一部です。タグは、リソースの作成時に適用するか、後で変更できます。たとえば、ACDのプロビジョニング中にAutonomous Container Database (ACD)にタグを適用したり、「詳細」ページから後で追加できます。

タグの使用の詳細は、タグ付けの仕組みを参照してください。タグ付けはOracle Cloud Infrastructure認可システムと統合されています。IAMポリシー・コントロールを使用して、タグ操作の委任または制限を有効にできます。定義済タグおよびフリーフォーム・タグの操作に必要な権限について学習するには、認証と認可を参照してください。(必須)概念の定義と目的を含む紹介テキストをここに入力します。

ヒント:

Oracle Autonomous Databaseでのタグの実装を示すチュートリアルを試してみる場合は、Oracle LiveLabsのフリート管理者専用Oracle Autonomous Databaseワークショップラボ14: Oracle標準タグを参照してください。

テナンシには、ほとんどのリソースに適用される標準タグのライブラリが付属しています。これらのタグは現在、ガバナンス管理者がデプロイできるタグ・ネームスペースのセットとして使用可能です。OCIのベスト・プラクティスでは、標準タグを適用できるすべてのリソースにこれらのタグを適用することをお薦めします。OCIサービス自動化では、レポートとガバナンスの他に、標準のタグ値に基づいてワークロード固有の最適化を提供できます。

たとえば、PeopleSoftアプリケーションのデータベース・デプロイメントには特定の構成が必要です。Autonomous Databaseのデプロイ時にOracle-ApplicationNameタグ・ネームスペースで適切なアプリケーション・タグ・キーを設定すると、データベースを構成して、PeopleSoftなどの特定のアプリケーションで即時利用できるように準備できます。

図4-1 タグ付けの例

Oracle-ApplicationNameタグ・ネームスペースに適切なアプリケーション・タグ・キーを設定します。

Oracle標準タグ

テナンシ・ガバナンス管理者は、テナンシ・レベルで標準タグをデプロイでき、特定のタグを必須とマークすることで、そのコンパートメントのリソースにタグを強制的に付けることができます。次に、OracleStandardというネームスペースに定義されている標準タグを示します。標準タグのインポートの詳細は、タグ・ネームスペースの管理の項の標準タグをインポートするにはを参照してください。

表4-1 Oracle標準タグ

タグ・キー タグ値のオプション 説明

OracleStandard.Criticality

  • 最大

企業のアプリケーション分類基準に沿ったリソースの階層化を可能にします。カスタマ・ガバナンスでは、このタグをレポートに使用し、リソースが属する層のガイドラインに従ってリソースが構成されるようにできます。

たとえば、OracleStandard.Criticalityが最大または高に設定されているデータベース・リソースには、可用性が最も高いSLAが必要であり、Autonomous Data Guardで構成する必要がある場合があります。

OracleStandard.Environment

  • 開発
  • テスト
  • 本番
  • 本番前
  • ステージング
  • トライアル
  • サンドボックス
  • ユーザー・テスト

リソース・ライフサイクルを示します。データベースの場合、統合密度の決定、コンテナ間のデータベース分散、メンテナンス・プランの設定、クローンの管理に役立ちます。

OracleStandard.Sensitivity

  • 公開
  • 内部
  • 機密
  • 高機密
  • 非常に高機密

アプリケーションまたはデータベース分類タグ。OracleStandard.Sensitivityを高機密に設定すると、アクセス制御リストまたは特定のネットワーク・セキュリティ・グループ(NSG)の強制がアクセスを制限するために必須であることを示すことができます。

OracleStandard.Regulation

値については、コンプライアンス規則のリストを参照してください。

リソースが準拠する必要がある1つ以上のコンプライアンス規則を示します。

タグ管理者は、OCIの「ガバナンスと管理」コンソールからリストに値を追加できます。詳細は、事前定義済の値の使用を参照してください。

OracleStandard.TargetUsers

  • 公開
  • 顧客
  • パートナ
  • 会社
  • ディビジョン
  • 部門
  • ワークグループ

リソースのエンド・ユーザーを示します。ターゲット・ユーザーを決定し、ガバナンス・チームがユーザー・タイプまたはアプリケーション・タイプに基づいて企業標準を設定できるようにする、別の形式のリソース分類。

OracleStandard.EndUserCount

  • 1
  • 10
  • 100
  • 1000
  • 10000
  • 100000
  • 1000000
  • 1000000
  • 10000000

エンド・ユーザーの概数。このタグは、可用性またはセキュリティ・イベント中に影響を受けるユーザー数または影響を受けるユーザーの範囲を特定するのに役立ちます。また、これは、多数のクラウド・リソースに影響する重大な停止が発生した場合にリカバリ作業に優先順位を付けるのにも役立ちます。

OracleStandard.OwnerEmail

フリーフォーム・タグ。例: john.smith@acme.comまたはapp_support_grp@acme.com

リソース所有者の電子メール・アドレスを示します。

OracleStandard.Org

  • 人事
  • 財務
  • マーケティング
  • 販売
  • 法務
  • 研究開発
  • 顧客サポート
  • 内部サポート
  • 製造

リソースを所有または使用する顧客の事業部門または部門を識別します。これは、コスト集計レポートと、ビジネス単位間の使用状況の決定に役立ちます。タグ管理者は、OCIの「ガバナンスと管理」コンソールからリストに関連する値を追加できます。詳細は、事前定義済の値の使用を参照してください。

OracleStandard.CostCenter

  • 12345
  • WebMarketing

コスト・センターの自由形式フィールド。

OracleStandard.RecoveryTimeObjectiveMinutes

0-10080

時間(分)。リソースが障害からのリカバリに必要な最大時間を示します。

OracleStandard.RecoveryPointObjectiveMinutes

0-1440

時間(分)。データベースやストレージ・デバイスなどのデータ・ストア・リソースの最大データ損失許容範囲。

コンプライアンス規則のリスト

表4-2 コンプライアンス規則のリスト

規則 説明

PCI DSS

クレジット・カード業界データ・セキュリティ基準

HIPAA

医療保険の相互運用性と説明責任に関する法律

ISO

国際標準化機構

SOC1

システムおよび組織管理1

SOC 2

システムおよび組織管理2

FedRamp

米国連邦リスク承認管理プログラム

GLBA

グラム・リーチ・ブライリー法

CCPA

カリフォルニア州消費者プライバシ法

SOX

サーベンス・オクスリー法

NIST

米国国立標準技術研究所 - サイバー・セキュリティ

FISMA

連邦情報セキュリティ管理

HITECH

経済的および臨床的健全性のための医療情報技術に関する法律

FERPA

家族教育権利およびプライバシ法(学生プライバシ法)

FACTA

公正かつ正確な信用取引のための法律

Texas HB300

テキサス医療記録プライバシ法

CIS

国際インターネット・セキュリティ組織

CJIS

刑事司法情報サービス・セキュリティ・ポリシー

C-TPAT

テロリズムに対する関税-貿易パートナシップ

COPPA

児童オンライン・プライバシ保護法

PIPED ActまたはPIPEDA

個人情報保護および電子文書法

GDPR

一般データ保護規則

PIPL

個人情報保護法

Oracleアプリケーション名タグ

表4-3 Oracleアプリケーション名タグ

タグ・キー タグ値のオプション 説明

Hyperion

  • 11.2
  • 11.1

Hyperionアプリケーションのバージョンを示します。

JD Edwards

  • 9.2
  • 9.1
  • 9.0

JD Edwardsアプリケーションのバージョンを示します。

Oracle_E-Business_Suite

  • 12.2
  • 12.1
  • 12.1
  • 11i

Oracle E-Business Suiteアプリケーションのバージョンを示します。

PeopleSoft

  • 9.2
  • 9.1

PeopleSoftアプリケーションのバージョンを示します。

Siebel

  • 8.2
  • 8.1

Siebelアプリケーションのバージョンを示します。

Other_Oracle_Application

文字列形式の自由形式タグ。

前述以外のアプリケーションを示すために使用できます。アプリケーション名を文字列値として入力できます。

クラウド・インフラストラクチャのメンテナンス更新

Oracleは、Exadata Cloud Infrastructure上のすべてのOracle管理インフラストラクチャ・コンポーネントに対する更新を実行します。

インフラストラクチャ・メンテナンスに関して通知される連絡先を管理したり、メンテナンス・ウィンドウを設定して四半期ごとのインフラストラクチャ・メンテナンスを開始する時間を決定したり、Oracle Cloud InfrastructureコンソールでExadata Cloud Infrastructureのスケジュール済メンテナンス実行およびメンテナンス履歴を表示したりできます。インフラストラクチャ・メンテナンス・プロセスおよびメンテナンス制御の構成の詳細は、次を参照してください:

Oracle管理のExadata Cloud Infrastructureメンテナンスについて

Oracleは、Exadata Cloud Infrastructure上のすべてのOracle管理システム・コンポーネントに対してパッチおよび更新を実行します。

Oracleのパッチおよび更新には、物理データベース・サーバー・ホスト、Exadata Storage Server、ネットワーク・ファブリック・スイッチ、管理スイッチ、電力配分装置(PDU)、統合電源管理(ILOM)インタフェースおよびコントロール・プレーン・サーバーが含まれます。これは、インフラストラクチャ・メンテナンスと呼ばれます。

更新の頻度は、次のようにリージョン・タイプによって異なります:

  • 商用リージョン: Oracleは、四半期ごとの完全なインフラストラクチャ更新と、月ごとのセキュリティ・インフラストラクチャ更新を実行します。
  • 政府リージョン: Oracleは、毎月の完全なインフラストラクチャ・メンテナンス更新を実行します。

ごくまれな例外的状況を除き、計画を支援するために、これらの更新に関する事前通知が送信されます。VMクラスタ仮想マシン(VM)に、対応する推奨更新がある場合、Oracleからそれらに関する通知が提供されます。

可能なかぎり、スケジュールされた更新は、更新プロセス全体でサービスの可用性を保持する方法で実行されます。ただし、更新プロセス中に個々のシステム・コンポーネントが使用できない間は、パフォーマンスやスループットに顕著な影響が生じることがあります。

たとえば、通常、データベース・サーバーのパッチ適用では再起動が必要です。このような場合、データベース・サーバーは、可能なかぎりローリング方式で1つずつ再起動され、プロセス全体でサービスの可用性が保持されるようにします。ただし、各データベース・サーバーは、再起動中に短時間使用不能になるため、全体的なサービス容量はそれに応じて減少します。アプリケーションが再起動を許容できない場合は、必要に応じて軽減アクションを実行します。たとえば、データベース・サーバーのパッチ適用が発生したときにアプリケーションを停止します。

ノート

Oracle Cloud Infrastructure (OCI) US Government (OC2)および米国国防総省(OC3)リージョンのExadata Database on Dedicated Infrastructureを使用しているお客様は、OCIコンソールを使用して、月次および四半期ごとのパッチ適用イベントを再スケジュールできます。

現時点では、「Exadata Cloud Infrastructureのパッチ管理スケジュールの設定」と呼ばれるメンテナンス・スケジュールは、Exadataパッチ管理用のOCI US Government (OC2)およびUS DOD (OC3)レルムではまだ使用できません。パッチ管理再スケジュール上のExadata Database on Dedicated Infrastructureの詳細は、ここを参照してください。

四半期ごとのインフラストラクチャ・メンテナンス・プロセスの概要

デフォルトでは、インフラストラクチャ・メンテナンスによってExadataデータベース・サーバー・ホストがローリング方式で更新され、その後ストレージ・サーバーが更新されます。

非ローリング・メンテナンスを選択して、データベース・サーバーとストレージ・サーバーを更新することもできます。非ローリング・メンテナンス方法は、最初にストレージ・サーバーを同時に更新してから、データベース・サーバーを同時に更新します。非ローリング・メンテナンスでは、メンテナンス時間が最小化されますが、ストレージ・サーバーおよびデータベース・サーバーの更新中に完全なシステム・ダウンタイムが発生します。

ローリング・インフラストラクチャ・メンテナンスは、Exadataデータベース・サーバー・ホストから開始されます。ローリング・メンテナンス方法では、データベース・サーバーは一度に1つずつ更新されます。データベース・サーバー・ホストの各VMが停止され、ホストが更新および再起動されてからVMが起動されますが、その間他のデータベース・サーバーは稼働したままです。このローリング・メンテナンスは、ローリング・インスタンスの停止を処理するために書き込まれていない古いアプリケーションに影響します。すべてのサーバーが更新されるまでこのプロセスが続行されます。

データベース・サーバーのメンテナンスが完了すると、ストレージ・サーバーのメンテナンスが開始されます。ローリング・メンテナンス方法では、ストレージ・サーバーは一度に1つずつ更新され、VMクラスタのVMの可用性には影響しません。ただし、ローリング・ストレージ・サーバーのメンテナンスでは、ストレージ・サーバーがオフラインになり(使用可能なIO容量が減少)、オンラインに戻ったときに再同期されると、IOパフォーマンスが低下する可能性があります(データベース・サーバーのオーバーヘッドが少ない)。データベースおよびストレージ・インフラストラクチャを適切にサイジングして、メンテナンスされていないデータベースおよびストレージ・サーバーに分散された作業の増加に対応すると、パフォーマンスへの影響を最小限に抑える(または排除する)ことができます。

ノート

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

最大可用性アーキテクチャ(MAA)のベスト・プラクティスに従い、Data Guardを使用してクリティカルなアプリケーションの可用性を最大にすることをお薦めします。Data Guardが有効なデータベースの場合、プライマリ・データベースとスタンバイ・データベースを実行しているインフラストラクチャ・インスタンスのメンテナンス・ウィンドウを分離することをお薦めします。プライマリ・データベースをホストするインフラストラクチャ・インスタンスのメンテナンス操作の前に、スイッチオーバーを実行することもできます。これにより、インフラストラクチャ・メンテナンス中のプライマリ・データベースへの影響を回避できます。

事前チェックは、メンテナンス・ウィンドウの開始前にExadata Cloud Infrastructureコンポーネントで実行されます。事前チェックの目的は、インフラストラクチャ・メンテナンスの成功を妨げる可能性のある問題を特定することです。Exadataインフラストラクチャおよびすべてのコンポーネントは、事前チェック時にオンラインのままです。最初の事前チェックはメンテナンス開始の約5日前に実行され、別の事前チェックはメンテナンス開始の約24時間前に実行されます。事前チェックでメンテナンスの再スケジュールが必要な問題が識別された場合は、メンテナンス連絡先に通知が送信されます。

ノート

パッチ適用ウィンドウ中はデータベースまたはアプリケーションで主要なメンテナンス操作を実行しないでください。これらの操作はインフラストラクチャ・メンテナンス操作によって影響を受ける可能性があるためです
四半期メンテナンスWindowsの時間見積り

インフラストラクチャ・コンポーネントの更新にかかる時間は、Exadataインフラストラクチャ内のデータベース・サーバーおよびストレージ・サーバーの数、メンテナンス方法、およびカスタム・アクションが有効化されているかどうかによって異なります。

提示される概算時間は見積りです。カスタム・アクション(構成されている場合)の時間は見積りに含まれません。データベース・サーバーのメンテナンス時間は、更新前に各VMを停止してから、各ノードの更新後に次のノードに進む前に各VMおよび関連リソースを起動するために必要な時間によって異なる場合があります。ストレージ・サーバーのメンテナンス時間は、ASMリバランスに必要な時間によって異なります(この時間は次の見積りには含まれません)。メンテナンス中に問題が発生した場合、リストされている概算時間を超えて完了が遅延することもあります。このような状況では、Oracleクラウド操作によって、予想されるウィンドウを超えて解決が延長されると判断された場合、通知が送信され、メンテナンスが再スケジュールされることがあります。

ノート

Oracle Cloud Operationsで追加のメンテナンス作業が必要と判断された場合、次に示す時間枠が変更される可能性があります。追加の時間が必要な場合は、次の四半期メンテナンス・ウィンドウに追加の時間が必要であることを顧客に通知するために、Oracleから事前に顧客に通知が送信されます。

表4-4 Exadataインフラストラクチャ・メンテナンスのおおよその時間

Exadataシェイプ構成 ローリング・パッチ適用方式(概算時間) 非ローリング・パッチ適用方式(概算時間)
クォータ・ラック 5-6時間 4~7時間
ハーフ・ラック 10時間 4~7時間
フル・ラック 20時間 4~7時間
フレキシブル・シェイプ(X8M以上) コンピュート・ノード当たり1.5時間 + ストレージ・ノード当たり1時間 4~7時間

月次セキュリティ・メンテナンスの概要

四半期メンテナンスと並行して実行されるセキュリティ・メンテナンスは、重要なセキュリティ更新が必要な月に実行され、すべてのCVSSスコアにわたる脆弱性の修正を含みます。

ノート

CVEリリース・マトリックスの詳細は、Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(ドキュメントID 88828.1)を参照してください。

Exadataインフラストラクチャ・バージョンに固有のCVEリリース・マトリックスを表示するには、Exadataバージョン(Exadata 23など)をクリックします。バージョン固有のCVEリリース・マトリックスは、表の「ノート」列にリストされています。

セキュリティ・メンテナンスは、必要に応じて、各月の18日から21日の間に開始し、翌月の9日から12日まで実行される21日の期間中に適用されるようにスケジュールされています。顧客には、月次メンテナンス・ウィンドウの開始日の7日前までにスケジュール案が通知され、必要に応じて、ウィンドウ内の別の日付に月次メンテナンスを再スケジュールできます。毎月のセキュリティ・メンテナンス・プロセスでは、データベース・サーバーが更新され、重要なセキュリティの脆弱性と製品に関する問題が修正されます。また、月次メンテナンスでは、ストレージ・サーバーをExadata Storageソフトウェア・イメージに更新して、既知のセキュリティの脆弱性と製品の問題を解決します。

データベース・サーバーへの更新は、Kspliceテクノロジを介してオンラインで適用され、コンピュート(データベース)サーバーで実行されているワークロードには影響しません。データベース・サーバーのセキュリティ更新は、VMおよびデータベースを含むVM内のすべてのプロセスが稼働している間、ホスト・サーバーにオンラインで適用されるためです。サーバーとVMは再起動されません。ストレージ・サーバーに対する更新は、ローリング方式で適用されます。四半期ごとのメンテナンスと同様に、ストレージ・サーバーの再起動による影響は、アプリケーションに対して最小限に抑える必要があります。

サービス・インフラストラクチャの更新中、メモリーやストレージのスケーリング、オペレーティング・システムとGrid Infrastructureのパッチ適用(事前チェックを含む)、コンピュート・サーバーとストレージ・サーバーの柔軟な拡張など、一部の操作がブロックされる場合があります。
ノート

毎月のインフラストラクチャ・メンテナンス中は、VMの起動および停止操作のみがサポートされます。
更新が完了するまで、これらの操作を延期するように計画してください。セキュリティ更新の適用には、DBサーバー・ホストごとに約15分かかります。さらに、I/Oアクティビティに応じて、ストレージ・サーバーごとに60分かかります。影響を受ける操作を試行すると、コンソールは、進行中のセキュリティ更新を通知します。ゲストVMではソフトウェアは更新されません。

同月の月次および四半期メンテナンスの理解

四半期と月の両方のセキュリティ・メンテナンスが同じ月に実行されるようにスケジュールされている場合は、特別な考慮事項があります。四半期メンテナンスでは、セキュリティ・メンテナンスによってすでに適用されているセキュリティ修正が再適用され、既存のストレージ・サーバーのバージョンが更新に含まれるバージョンと同じかそれより新しい場合は、四半期メンテナンスも月次メンテナンスもストレージ・サーバー更新を適用しません。

  • 四半期メンテナンス中に適用される更新の内容は、メンテナンス四半期の開始時に決定され、メンテナンス四半期の開始前の月から最新のExadataリリースを使用します。その時点で追加のセキュリティ修正が使用可能な場合は、それらの更新が四半期メンテナンスに含まれます。このイメージは四半期全体で使用されます。たとえば、1月のリリースは、2月、3月および4月の四半期メンテナンスに使用されます。
  • 四半期メンテナンスが適用されると、データベース・サーバーに以前にインストールされたセキュリティ更新が、適用される四半期メンテナンス・リリースに含まれていない可能性があります。その場合、自動化では、四半期メンテナンスによってインストールされた新しいリリースに同じセキュリティ修正が適用されるため、セキュリティ修正が低下することはありません。ストレージ・サーバーの現在のイメージが、四半期または月次セキュリティ・メンテナンスによって適用されるイメージと同じかそれより新しい場合、そのメンテナンスはストレージ・サーバーに対してスキップされます。

四半期メンテナンスが月次スケジュールの24時間以内にスケジュールされている場合、スケジュールされた月次メンテナンスはスキップされ、かわりに四半期メンテナンスの直後に月次更新が適用されます。

  • 同じ時間にスケジュールされている場合、四半期メンテナンスの完了直後に月次更新が実行されます。
  • 月次メンテナンスが四半期メンテナンスより0-24時間前に開始するようにスケジュールされている場合、月次メンテナンスはスケジュールどおりに実行されません。かわりに、待機して四半期メンテナンスの直後に実行されます。四半期メンテナンスが後で再スケジュールされた場合、月次セキュリティ・メンテナンスは即座に開始されます。したがって、四半期メンテナンスと月次メンテナンスを同じ時間にスケジュールすることをお薦めします。そうすると、四半期メンテナンスを直前に再スケジュールした場合、月次メンテナンスはスケジュールの編集直後ではなく、スケジュールされた時間に実行されます。また、四半期メンテナンスの再スケジュール時に、月次セキュリティ・メンテナンスを再スケジュールすることもできます(月次メンテナンスが現在のメンテナンス・ウィンドウ内にある場合にかぎります)。月次メンテナンスはメンテナンス・ウィンドウ内の別の時間に再スケジュールできますが、スキップすることはできません。

四半期メンテナンス前の月次セキュリティ・メンテナンス

  • 四半期メンテナンスの前にセキュリティ・メンテナンスを適用するには、月次セキュリティ・メンテナンスを四半期メンテナンスの24時間以上前に実行するように再スケジュールします。セキュリティ・メンテナンスは、アプリケーションに影響を与えずにデータベース・サーバーにセキュリティ・パッチをオンラインで適用し、アプリケーションへの影響を最小限に抑えてストレージ・サーバーに更新を適用します(パフォーマンスが若干低下する可能性があります)。四半期メンテナンスはスケジュールどおりに実行され、データベース・サーバーでローリング・メンテナンスが実行されます。これは、ローリング再起動を処理するために書き込まれていないアプリケーションに影響します。四半期メンテナンスの一環として、システムにすでにインストールされているデータベース・サーバーに同じセキュリティ更新が適用されます(セキュリティの低下はありません)。
  • 最新のセキュリティ更新の適用に関心がある場合は、新しい月次メンテナンス・ウィンドウが開いた後(通常は月の21日)、月次セキュリティ・メンテナンスの実行をスケジュールします。
  • ストレージ・サーバーをリブートする月次セキュリティ・メンテナンスの影響は最小限に抑える必要があるため、この月のアプリケーションへの影響は、四半期メンテナンス中のデータベース・サーバーの再起動のみによるものです。ただし、セキュリティ・メンテナンスのためにメンテナンス・ウィンドウをエンド・ユーザーと調整する必要がある場合は、2つのメンテナンス・ウィンドウが必要です。

月次セキュリティ・メンテナンス前の四半期メンテナンス

  • 月次セキュリティ・メンテナンスの前に四半期メンテナンスを実行するには、四半期メンテナンスの開始がスケジュールされる24時間前に実行するようにセキュリティ・メンテナンスを再スケジュールします。セキュリティ・メンテナンスは、四半期メンテナンスが完了するまで延期されます。四半期メンテナンスでは、データベース・サーバーでローリング・メンテナンスが実行されます。これは、ローリング再起動を処理するために書き込まれていないアプリケーションに影響します。四半期メンテナンスでは、ストレージ・サーバーのパッチ適用がスキップされる場合とスキップされない場合があります。これは、現在インストールされているリリースより新しいか古いかによって異なります。ほとんどの場合、インストールされるバージョンは、四半期メンテナンスに関連付けられているバージョンより新しいものである必要があります。このルールの例外は、メンテナンス四半期の最初の月である場合、または1か月以上前の月にセキュリティ・メンテナンスをスキップした場合に発生します。セキュリティ・メンテナンスは、四半期メンテナンスの完了直後またはスケジュールされたいずれか後のいずれか後に実行されます。これは、オンライン更新をデータベース・サーバーに適用し(アプリケーションの影響なし)、ストレージ・サーバーをローリング方式で更新します。場合によっては、四半期ごとのメンテナンスにセキュリティ・メンテナンスと同じストレージ・サーバー・リリースが含まれている場合があり、セキュリティ・メンテナンス・ストレージ・サーバーの更新はスキップされます。
  • セキュリティ・メンテナンスの前に四半期メンテナンスを実行するエンド・ユーザーへの影響は、最初にセキュリティ・メンテナンスを実行する場合とほぼ同じである必要があります。四半期メンテナンスは中断を伴うイベントになりますが、ストレージ・サーバーを再起動するセキュリティ・メンテナンスによって中断が最小限に抑えられ、セキュリティ・メンテナンスがオンラインのデータベース・サーバーに適用されます。ただし、セキュリティ・メンテナンスのためにメンテナンス・ウィンドウをエンド・ユーザーと調整する必要がある場合は、2つのメンテナンス・ウィンドウが必要です。これら2つのメンテナンス・ウィンドウを、エンド・ユーザーに対して単一のメンテナンス・ウィンドウとして表示されるようにスケジュールできます。これを行うには、四半期メンテナンスと同時に(または最大24時間前に)セキュリティ・メンテナンスを開始するように再スケジュールします。セキュリティ・メンテナンスは、四半期メンテナンスが完了するまで延期されます。毎月のセキュリティ・メンテナンスを定期的に適用している場合、ストレージ・サーバーは四半期ごとのメンテナンスによってスキップされ、四半期ごとのメンテナンスが完了するとすぐにセキュリティ・メンテナンスによって更新されます。

メンテナンスWindowsの最小化

  • メンテナンス・ウィンドウの数を最小化(エンド・ユーザーとのネゴシエーションが必要)するには、四半期メンテナンスと月次メンテナンスを同時にスケジュールします。セキュリティ・メンテナンスはブロックされます。四半期メンテナンスでは、データベース・サーバーがローリング方式で更新され、ストレージ・サーバーがスキップされる可能性が高くなります。セキュリティ・メンテナンスはただちにフォローアップされ、データベース・サーバーとストレージ・サーバーをローリング方式で更新します。その結果、単一のメンテナンス・ウィンドウで単一のデータベースとストレージ・サーバーが再起動されます。
  • これには2つの例外があります。1.四半期メンテナンスと月次メンテナンスに同じストレージ・サーバー・リリースが含まれている場合、四半期メンテナンスはストレージ・サーバー更新を適用し、セキュリティ・メンテナンスはスキップされます。お客様の観点では、これは単一のメンテナンス・ウィンドウでの単一のローリング再起動です。2.ストレージ・サーバーに現在インストールされているリリースは、四半期メンテナンスに含まれるリリースより古いため、セキュリティ・メンテナンスのリリースより古いものです。これにより、四半期ごとのメンテナンスによってストレージが更新され、その後、セキュリティ・メンテナンスによってストレージも更新されます。これは、現在のイメージが2か月以上古い必要があるため、前月のセキュリティ・メンテナンスをスキップした場合にのみ発生します。このようなシナリオでは、最初にセキュリティ・メンテナンスをスケジュールし、次に四半期メンテナンスをスケジュールできます。これにより、1台のストレージ・サーバーが再起動されますが、2つの異なるメンテナンス・ウィンドウ(最初にセキュリティ・メンテナンス、次に後に四半期メンテナンス)が再起動されます。
  • エンド・ユーザーへの影響を最小限に抑えるには、常に月次セキュリティ更新を適用し、両方がスケジュールされている月数で同時にスケジュールします。
ノート

Oracleがセキュリティ・メンテナンスをスケジュールする前にExadataインフラストラクチャがプロビジョニングされた場合、セキュリティ・メンテナンスの対象となります。

スケジュールされた月次Exadataインフラストラクチャ・メンテナンスの前にいつでも、再スケジュールできます。

コンソールを使用したOracle管理インフラストラクチャ更新の構成

ソフトウェア更新は、四半期ごとおよび月ごとにスケジュールされます。コンソールを使用して、それらをスケジュールおよび計画できます。

Exadata Cloud Infrastructureソフトウェアの完全な更新は、商用リージョンの場合は四半期ベースで、政府リージョンの場合は月次でスケジュールされます。さらに、重要なセキュリティ更新は毎月スケジュールされます。これらのインフラストラクチャの更新をオプト・アウトすることはできませんが、クラウド通知ポータルを介して更新が事前にアラートされ、スケジュールを柔軟に設定して計画を立てることができます。

四半期ごとのインフラストラクチャ・メンテナンスの場合、メンテナンスを開始するタイミングを決定するメンテナンス・ウィンドウを設定できます。また、Oracle Cloud Infrastructureコンソールの「Exadataインフラストラクチャの詳細」ページで、メンテナンス方法の編集、カスタム・アクションの有効化、スケジュール済メンテナンス実行とメンテナンス履歴の表示、メンテナンス連絡先の管理を行うことができます。

Exadata Cloud Infrastructureの四半期ごとのインフラストラクチャ・メンテナンスのプリファレンスの表示または編集

Oracle Exadata Database Service on Dedicated Infrastructureのインフラストラクチャ・メンテナンスのプリファレンスを編集するには、インフラストラクチャ構成の値を指定する準備をします。行った変更は将来のメンテナンス実行にのみ適用され、すでにスケジュールされているものには適用されません。

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
    ノート

    メンテナンス・プリファレンスの指定は、政府リージョンでは使用できません。
  2. 「リージョン」および「コンパートメント」を選択して、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
  3. 「Exadataインフラストラクチャ」をクリックします。
  4. 編集するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

  5. 「メンテナンスのプリファレンスの編集」をクリックします。

    「メンテナンスのプリファレンスの編集」ページが表示されます。

    ノート

    メンテナンス・プリファレンスに加えられた変更は、将来のメンテナンスにのみ適用され、すでにスケジュールされているメンテナンスには適用されません。スケジュール済メンテナンスを変更するには、Exadata Cloud Infrastructureのスケジュール済メンテナンスの表示または編集を参照してください。
  6. 「メンテナンスのプリファレンスの編集」ページで、次を構成します:
    • メンテナンス方法の選択:
      • ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
      • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
    • DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
      • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。

        デフォルト: 30分

        最大: 120分

    • メンテナンス・スケジュール:
      • プリファレンスなし: システムによってインフラストラクチャ・メンテナンスの日付と開始時刻が割り当てられます。
      • スケジュールの指定: インフラストラクチャ・メンテナンスに対して希望する月、週、平日、開始時刻およびリード・タイムを選択します。
        ノート

        メンテナンス・スケジュールの指定は、政府リージョンでは使用できません。
        • 「メンテナンス月」で、Exadataインフラストラクチャのメンテナンスを実行する月を四半期ごとに少なくとも1つ指定します。四半期ごとに複数の月を選択できます。事前通知に長いリード・タイム(たとえば、4週間)を指定する場合は、メンテナンス実行を行うことができる月を四半期ごとに2つまたは3つ指定することをお薦めします。これにより、必要なリード・タイムを考慮したうえで、メンテナンス更新が適時に適用されるようになります。リード・タイムについては、後のステップで説明します。
        • オプション。「該当月の週」で、メンテナンスを実行する月の週を指定します。週は月の1日、8日、15日、22日から始まり、7日の期間があります。週の開始および終了は、曜日ではなくカレンダの日付に基づきます。28日より多くの日数を含む月の第5週には、メンテナンスをスケジュールできません。月の週を指定しない場合は、Oracleによって、中断が最小限になる週にメンテナンス更新が実行されます。
        • オプション。「曜日」で、メンテナンスを実行する曜日を指定します。曜日を指定しない場合は、Oracleによって、中断が最小限になる週末の日にメンテナンス更新が実行されます。
        • オプション。「開始時間」で、メンテナンス実行を開始する時間を指定します。開始時間を指定しない場合は、Oracleによって、中断が最小限になる時間が選択されてメンテナンス更新が実行されます。
        • 「リード・タイム」で、メンテナンス・イベントの何週間前に通知メッセージを受信するかを指定します。リード・タイムにより、事前通知に必要な最短期間を考慮して、新しくリリースされるメンテナンス更新がスケジュールされます。
  7. 「変更の保存」をクリックします。

    ローリングから非ローリング・メンテナンス方法に切り替えると、「非ローリング・メンテナンス方法の確認」ダイアログが表示されます。

    1. 表示されたフィールドにインフラストラクチャの名前を入力して、変更を確認します。
    2. 「変更の保存」をクリックします。
Exadata Cloud Infrastructureの自動月次メンテナンス・スケジュールを設定するには
Exadata Cloud Infrastructureの次のスケジュール済四半期メンテナンスのプロパティを表示または編集するには
Exadata Cloud Infrastructureリソースのメンテナンス履歴を表示するには
メンテナンスの進行中またはカスタム・アクションの待機中の四半期メンテナンスの表示および編集

メンテナンスの進行中、カスタム・アクションを有効または無効にして、カスタム・アクション・タイムアウトを変更できます。メンテナンスのカスタム・アクションの待機中、タイムアウト前にメンテナンスを再開するか、タイムアウトを延長できます。

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
  2. 「リージョン」および「コンパートメント」を選択して、編集するOracle Exadataインフラストラクチャが配置されているリージョンおよびコンパートメントを指定します。
  3. 「Exadataインフラストラクチャ」をクリックします。
  4. 編集するExadataインフラストラクチャの名前をクリックします。

    「インフラストラクチャの詳細」ページに、選択したOracle Exadataインフラストラクチャに関する情報が表示されます。

    ノート

    「メンテナンス進行中」ステータスが「次回のメンテナンス」フィールドに表示されます。

メンテナンス進行中のメンテナンスの表示および編集
  1. 「次回のメンテナンス」フィールドの「表示」リンクをクリックします。

    「Exadata Infrastructureメンテナンス」ページが表示されます。

  2. 「メンテナンス実行の編集」をクリックします。

    「メンテナンスの編集」ページが表示されます。

    ノート

    カスタム・アクション構成のみを編集でき、メンテナンス方法やスケジュールされた開始時間は編集できません。メンテナンス進行中のカスタム・アクションの有効化または無効化、またはカスタム・アクション・タイムアウトの変更は、まだ更新されていないすべてのデータベース・サーバーに適用されます。

  3. 「メンテナンスの編集」ページで、次を実行します:
    • DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
      • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。

        デフォルト: 30分

        最小: 15分

        最大: 120分

  4. 「変更の保存」をクリックします。

    ローリング・メンテナンス方法を構成した場合は、「表示」リンクが「推定メンテナンス時間合計」フィールドに表示されます。

    1. 「表示」をクリックします。
      「推定メンテナンス時間詳細」ページに、次の詳細が表示されます:
      • 推定メンテナンス時間合計
      • データベース・サーバー推定メンテナンス時間
      • ストレージ・サーバー推定メンテナンス時間
      • ネットワーク・スイッチ推定メンテナンス時間
      • コンポーネントが更新される順序。ローリング・メンテナンスでは、コンポーネントは表示されている順序で更新されます。
    2. 「閉じる」をクリックします。
メンテナンスのカスタム・アクション待機中のメンテナンスの表示および編集
  1. 「次回のメンテナンス」フィールドの「表示」リンクをクリックします。

    「Exadata Infrastructureメンテナンス」ページが表示されます。

    ノート

    • カスタム・アクションの待機中、メンテナンス実行の編集は使用できません。
    • メンテナンスのカスタム・アクションの待機中は、情報ブロックが表示されます。情報ブロックは、メンテナンスが再開されると削除されます。
  2. 情報ブロックで、次のいずれかを実行します:
    1. 「メンテナンスを今すぐ再開」をクリックしてメンテナンスを再開し、次のデータベース・サーバーに進みます。

      「メンテナンスの再開」ダイアログが表示されます。「メンテナンスを今すぐ再開」をクリックします。

    2. 「カスタム・アクション・タイムアウトの延長」をクリックします。

      2時間の最大許容時間内でタイムアウトを複数回延長できます。最大制限を超えて延長しようとすると、「カスタム・アクション・タイムアウトは延長できません」ダイアログが表示され、カスタム・アクション・タイムアウトがすでに最大許容時間である2時間まで延長されており、それ以上延長できないことが示されます。

ライフサイクル状態情報を使用したインフラストラクチャ・メンテナンスのモニター

Exadataインフラストラクチャ・リソースのライフサイクル状態により、インフラストラクチャ・リソースのメンテナンスがいつ開始および終了するかをモニターできます。

Oracle Cloud Infrastructureコンソールで、「Exadataインフラストラクチャの詳細」ページにライフサイクル状態の詳細メッセージが表示されます(「ステータス」フィールドの横にツールチップが表示されます)。これらのメッセージには、ListCloudExadataInfrastructures API、およびSDKOCI CLIなどのAPIに基づくツールを使用してアクセスすることもできます。

インフラストラクチャ・メンテナンスの実行時には、次が予想されます:
  • メンテナンス・ウィンドウを指定した場合、指定した開始時間にパッチ適用が開始されます。インフラストラクチャ・リソースのライフサイクル状態が「使用可能」から「メンテナンス進行中」に変わります。
    ノート

    メンテナンスの開始前に事前チェックが実行されます。
  • Exadataデータベース・サーバーのメンテナンスが開始されると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」になり、関連するライフサイクル状態メッセージは「このシステム(dbnodes)の基礎となるインフラストラクチャは更新中です」です。
  • ストレージ・サーバーのメンテナンスが開始されると、インフラストラクチャ・リソースのライフサイクル状態は「メンテナンス進行中」になり、関連するライフサイクル状態メッセージは「このシステム(セル・ストレージ)の基礎となるインフラストラクチャは更新中であり、これはデータベースの可用性には影響しません」です。
  • ストレージ・サーバーのメンテナンスが完了すると、ネットワーク・スイッチがローリング方式で1つずつ更新されます。
  • メンテナンスが完了すると、インフラストラクチャ・リソースのライフサイクル状態は「使用可能」になり、コンソールおよびAPIベースのツールにライフサイクル状態メッセージは表示されません。

インフラストラクチャ・メンテナンス更新に関する通知の受信

通知を受信するには、2つの方法があります。1つはインフラストラクチャ・メンテナンス連絡先への電子メールによる方法で、もう1つはメンテナンス・イベントにサブスクライブして通知を受信する方法です。

Oracleは、スケジュール・プリファレンスに基づいてインフラストラクチャのメンテナンス実行をスケジュールし、すべてのインフラストラクチャ・メンテナンス連絡先に電子メール通知を送信します。コンソールにログインして、スケジュール・メンテナンス実行の詳細を表示できます。スケジュール・リマインダ、パッチ適用の開始、パッチ適用の終了など、スケジュール済メンテナンス実行のためのOracleの準備として、適切なメンテナンス関連イベントが生成されます。すべてのメンテナンス関連イベントの詳細は、Oracle Cloud Exadataインフラストラクチャ・イベントを参照してください。障害が発生した場合、Oracleはメンテナンス実行を再スケジュールし、関連する通知を生成して、インフラストラクチャ・メンテナンス連絡先に通知します。

Oracle Cloud Infrastructure Eventsの詳細は、イベントの概要を参照してください。インフラストラクチャ・メンテナンス連絡先に送信された通知以外の追加の通知を受信するには、インフラストラクチャ・メンテナンス・イベントにサブスクライブし、Oracle Notification Serviceを使用して通知を受信します。通知の概要を参照してください。

インフラストラクチャ・メンテナンス連絡先の管理

Exadataインフラストラクチャ・メンテナンス連絡先の管理について学習します。

Exadata Cloud Infrastructureのメンテナンス連絡先を管理するには

コンソールを使用して、Exadataインフラストラクチャ・メンテナンス通知の連絡先を管理します。

Exadataインフラストラクチャ管理者がシステム更新通知に忙殺されないように、メンテナンス通知が送信されるユーザーの電子メール・アドレスを最大10個まで指定できます。

  1. ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします。
  2. 「Oracle Exadata Database Service on Dedicated Infrastructure」セクションで、「Exadataインフラストラクチャ」をクリックして、デフォルト・コンパートメント内のExadataインフラストラクチャのリストを表示します。「リスト範囲」セクションにある「コンパートメント」ドロップダウンから別のコンパートメントを選択できます。
  3. Exadataインフラストラクチャ・リソースのリストで、アクセスするインフラストラクチャを検索し、強調表示された名前をクリックしてその詳細ページを表示します。
  4. 「メンテナンス」セクションで、「顧客の連絡先」フィールドの「管理」をクリックして「連絡先の管理」ダイアログを表示します。
  5. 「連絡先の追加」ボタンをクリックすると、有効な電子メール・アドレスを入力するフィールドが表示されます。Exadataインフラストラクチャごとに最大10個のメンテナンス連絡先を設定できます。
  6. 電子メール・アドレスを編集するには、「連絡先の管理」ダイアログで、編集する電子メール・アドレスの前にあるボックスを選択し、「編集」ボタンをクリックします。
  7. リストから電子メール・アドレスを削除するには、「連絡先の管理」ダイアログで、削除する電子メール・アドレスの前にあるボックスを選択し、「削除」ボタンをクリックします。