機械翻訳について
  1. Oracle Exadata Database Service on Cloud@Customer管理者ガイド
  2. How-toガイド
  3. VMクラスタの管理

VMクラスタの管理

Oracle Exadata Database Service on Cloud@CustomerでVMクラスタを管理する方法について学習します。

関連トピック

親トピック: How-toガイド

Oracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理について

VMクラスタは、Oracle Exadata Database Service on Cloud@CustomerインフラストラクチャとデプロイするOracle Databasesの間のリンクを提供します。

VMクラスタには、クラスタ内のデータベースをサポートするOracle Clusterwareのインストールが含まれます。 VMクラスタ定義で、データベースで使用可能なCPUリソースの量を決定する有効なCPUコアの数も指定します

Exadata Cloud@Customerインフラストラクチャにデータベースを作成する前に、VMクラスタ・ネットワークを作成して、VMクラスタに関連付ける必要があります。

ノート:

Oracle Cloud Infrastructureコンソール、APIまたはCLIを使用してクラウド・リソースに説明、タグまたはわかりやすい名前を割り当てる場合は、機密情報を入力しないでください。

親トピック: VMクラスタの管理

VMクラスタ・ノードのサブ設定の概要

VMクラスタ・ノード・サブセットを使用すると、データベース・サーバーのサブセットを新規および既存のVMクラスタに割り当てることで、コンピュート(CPU、メモリー、ローカル・ストレージ)リソースの割当てにおける柔軟性を最大限に高めることができます。

VMクラスタ・ノード・サブセットを使用すると、次のことができます:
  • リソースおよびスケーラビリティの要件が低いデータベースをホストしたり、ワークロードの残りの部分から分離が必要な少数のデータベースをホストするために、小さいVMクラスタを作成します。
  • ノードを追加または削除して既存のVMクラスタを拡張または縮小し、使用可能なリソースを最適に使用できるようにします。
VMクラスタ・ノードのサブセット化に役立つ次の点を確認してください。
  • VMクラスタ・ノード・サブセット機能は、Gen2 Exadata Cloud@Customerサービスの新規および既存のVMクラスタで使用できます。
  • VMクラスタ全体のすべてのVMは、VMがクラスタのプロビジョニング中に作成されたか、既存のVMクラスタを拡張して後で追加されたかに関係なく、VMごとに同じリソース割当てを持ちます。
  • VMクラスタに必要なVMは、ノード・サブセット化を備えた1つ以上です。 ただし、Oracleでは、高可用性を実現するために、VMクラスタ当たり少なくとも2つのVMを推奨しています。
  • 各VMクラスタ・ネットワークは、インフラストラクチャ内のすべてのDB ServerのIPアドレスで事前にプロビジョニングされます。 1つのクラスタ・ネットワークは単一のVMクラスタでのみ使用でき、IPアドレスが他のクラスタ・ネットワークと重複しないように検証されます。 クラスタへのVMの追加または削除は、関連付けられたクラスタ・ネットワーク内の各DBサーバーに割り当てられた事前にプロビジョニングされたIPアドレスには影響しません。

DBサーバー当たりのVMの最大数およびシステム当たりのVMクラスタの最大数については、「システム・シェイプおよび構成表」を参照してください。 システム当たりのVMクラスタの最大数は、DBサーバーごとに使用可能なリソースに依存し、DBサーバーごとの最大VM制限の対象となります。

ノート:

クラスタにノード・サブセット化されたデータベースが含まれている場合、ノード・サブセット化されたデータベースを作成するプロセスがバックエンドで発生し、ノード・サブセット化されたデータベースのメタデータがコントロール・プレーン・サーバーと同期されないため、プラガブル・データベースの帰属使用量およびコスト機能は機能しません。

ただし、データベースが最初にノード・サブセット化を使用せずに作成され、後でノード・サブセット化されたデータベースに変換された場合、メタデータはコントロール・プレーンですでに使用可能であるため、この問題は発生しません。

関連トピック

親トピック: VMクラスタの管理

自動診断収集の概要

診断収集および通知を有効にすることで、Oracle Cloud操作により、ゲストVMの問題を迅速かつ効果的に識別、調査、追跡および解決できます。 イベントをサブスクライブして、リソース状態の変更に関する通知を取得します。

  • 診断イベントの有効化

    Oracleがクリティカル・イベント、警告イベント、エラー・イベントおよび情報イベントを収集して公開することを許可します。 詳細は、「データベース・サービス・イベント」を参照してください。

  • ヘルス・モニタリングの有効化

    Oracleがヘルス・メトリック/イベント(Oracle Database up/down、ディスク領域使用量など)を収集し、それらをOracle Cloud操作と共有できるようにします。 一部のイベントの通知も受信します。 詳細は、「健全性メトリック」を参照してください。

  • インシデント・ログおよびトレース収集の有効化

    Oracleがインシデント・ログおよびトレースを収集して障害診断および問題解決を可能にします。 詳細は、「インシデント・ログおよびトレース・ファイル」を参照してください。

診断収集:

  • 有効: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルの収集を選択した場合(3つのオプションすべて)。
  • 無効: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルを収集しないことを選択した場合(3つすべてのオプション)。
  • 一部使用可能: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイル(1つまたは2つのオプション)を収集することを選択した場合。

診断イベントおよびヘルス・モニタリングを無効にすると、オプションに関連付けられたチェック・ボックスの選択を解除した時点からのみ、データ/イベントの収集および通知が停止されます。 ただし、履歴データはOracle Cloud操作データ・リポジトリからパージされません。

関連トピック

親トピック: VMクラスタの管理

インシデント・ログおよびトレース・ファイル

この項では、インシデント・ログおよびトレース収集をオプトインした場合にOracle Supportで収集できるすべてのファイルをリストします。

ノート:

  • Oracleは、問題が検出され、解決するためにカスタマ・インタラクションが必要な場合に、インフラストラクチャのカスタマ・サポートID (CSI)に対してサービス・リクエスト(SR)を作成します。
  • 顧客のOracle Cloud Infrastructureテナンシ管理電子メールは、SRを作成してログをそれにアタッチするためのCSI連絡先として使用されます。 テナンシ管理者がMy Oracle Support (MOS)でCSI連絡先として追加されていることを確認します。

Oracle Trace File Analyze (TFA)コンポーネント駆動型ログ収集

通常、ディレクトリはコンポーネントに割り当てられ、そのコンポーネントを使用して、収集する必要があるファイルにTFAをガイドできます。たとえば、CRSコンポーネントをリクエストすると、CRSコンポーネントにマップされたディレクトリを参照し、必要な収集時間枠に一致するファイルを検索するようにTFAに指示します。

ノート:

以前にインシデント・ログおよびトレース・ファイルの収集をオプト・インし、Oracle Cloud操作でログ収集ジョブを実行したときにオプト・アウトすると、ジョブはそのコースを実行し、取り消しません。 インシデント・ログおよびトレース・ファイル収集オプションに再度オプトインするまで、今後のログ収集は行われません。

TFAには、特定のコンポーネントがリクエストされたときに実行されるスクリプトが付属しています。たとえば、CRSコンポーネントの場合、crscollect.plは多数のcrsctlコマンドを実行して入力を収集します。 デフォルトでは、TFAは収集されたログをリダクションしません。

表5-13 Oracle Trace File Analyze (TFA)コンポーネント駆動型ログ収集

コンポーネント スクリプト ファイル/ディレクトリ

OS: オペレーティング・システム・ログ

oscollect.pl
  • /var/log/messages
  • OSWatcherアーカイブ
  • Exadataのみ: ExaWatcherアーカイブ

    /opt/oracle.ExaWatcher/archive/

CRS: Grid Infrastructureおよびクラスタ・ログ

crscollect.pl
  • /etc/oracle
  • GIHOME/crf/db/HOSTNAME1
  • GIHOME/crs/log
  • GIHOME/css/log
  • GIHOME/cv/log
  • GIHOME/evm/admin/log
  • GIHOME/evm/admin/logger
  • GIHOME/evm/log
  • GIHOME/log/-/client
  • GIHOME/log/HOSTNAME1
  • GIHOME/log/HOSTNAME1/admin
  • GIHOME/log/HOSTNAME1/client
  • GIHOME/log/HOSTNAME1/crflogd
  • GIHOME/log/HOSTNAME1/crfmond
  • GIHOME/log/HOSTNAME1/crsd
  • GIHOME/log/HOSTNAME1/cssd
  • GIHOME/log/HOSTNAME1/ctssd
  • GIHOME/log/HOSTNAME1/diskmon
  • GIHOME/log/HOSTNAME1/evmd
  • GIHOME/log/HOSTNAME1/gipcd
  • GIHOME/log/HOSTNAME1/gnsd
  • GIHOME/log/HOSTNAME1/gpnpd
  • GIHOME/log/HOSTNAME1/mdnsd
  • GIHOME/log/HOSTNAME1/ohasd
  • GIHOME/log/HOSTNAME1/racg
  • GIHOME/log/HOSTNAME1/srvm
  • GIHOME/log/HOSTNAME1/xag
  • GIHOME/log/diag/asmtool
  • GIHOME/log/diag/clients
  • GIHOME/log/procwatcher/PRW_SYS_HOSTNAME1
  • GIHOME/network/log
  • GIHOME/opmn/logs
  • GIHOME/racg/log
  • GIHOME/scheduler/log
  • GIHOME/srvm/log
  • GRIDBASE/crsdata/@global/cvu
  • GRIDBASE/crsdata/HOSTNAME1/core
  • GRIDBASE/crsdata/HOSTNAME1/crsconfig
  • GRIDBASE/crsdata/HOSTNAME1/crsdiag
  • GRIDBASE/crsdata/HOSTNAME1/cvu
  • GRIDBASE/crsdata/HOSTNAME1/evm
  • GRIDBASE/crsdata/HOSTNAME1/output
  • GRIDBASE/crsdata/HOSTNAME1/ovmmwallets
  • GRIDBASE/crsdata/HOSTNAME1/scripts
  • GRIDBASE/crsdata/HOSTNAME1/trace
  • GRIDBASE/diag/crs/-/crs/cdump
  • GRIDBASE/diag/crs/HOSTNAME1/crs/cdump
  • GRIDBASE/diag/crs/HOSTNAME1/crs/incident
  • GRIDBASE/diag/crs/HOSTNAME1/crs/trace

Database: Oracle Databaseログ

DB固有のスクリプトがありません - ORACLE_HOMEに対してopatch lsinventoryを実行し、TFAからDBが実行されると、特定のDBインシデントの時間範囲に基づいてipspackが実行されます。

  • ORACLE_BASE/diag/rdbms/<dbname>/<instance_name>/cdump
  • ORACLE_BASE/diag/rdbms/<dbname>/<instance_name>/trace
  • ORACLE_BASE/diag/rdbms/<dbname>/<instance_name>/incident

クラウド・ツール・ログ

  • Cregファイル: マスクされた機密情報を含む/var/opt/oracle/creg/*.iniファイル
  • Cstateファイル: /var/opt/oracle/cstate.xml

  • データベース関連のツール・ログ:

    dbNameが指定された場合は/var/opt/oracle/log/<dbName>、それ以外の場合はすべてのデータベース/var/opt/oracle/log/のログを収集

    dbNameが指定された場合は/var/opt/oracle/dbaas_acfs/log/<dbName>、それ以外の場合はすべてのデータベース/var/opt/oracle/log/<dbName>のログを収集

  • データベース環境ファイル: dbNameが指定された場合は/home/oracle/<dbName>.env、それ以外の場合はすべてのデータベース/home/oracle/*.envのログを収集
  • パイロット・ログ: /home/opc/.pilotBase/logs
  • ログ・ディレクトリのリスト:
    • /var/opt/oracle/log
    • /var/opt/oracle/dbaas_acfs/log
    • /var/opt/oracle/dbaas_acfs/dbsystem_details
    • /var/opt/oracle/dbaas_acfs/job_manager
    • /opt/oracle/dcs/log

DCSエージェント・ログ

  • /opt/oracle/dcs/log/

ツール関連のGrid Infrastructure/データベース・ログ

  • Grid Infrastructure: GI_HOME/cfgtoollogs
  • データベース・アラート・ログ: /u02/app/oracle/diag/rdbms/*/*/alert*.log

関連トピック

親トピック: VMクラスタの管理

ヘルス・メトリック

Oracle Trace File Analyzerによって収集されたデータベースおよびデータベース以外のヘルス・メトリックのリストを確認します。

ノート:

Oracleでは将来、より多くのメトリックを追加できますが、すでにメトリックの収集を選択している場合は、オプトイン値を更新する必要はありません。 現在のプリファレンスに基づいて有効/無効のままになります。

ゲストVMヘルス・メトリック・リスト - データベース・メトリック

表5-14 ゲストVMヘルス・メトリック・リスト - データベース・メトリック

メトリック名 メトリック表示名 単位 集計 Interval 収集頻度 説明

CpuUtilization

CPU Utilization

パーセンテージ

平均

1分

5分以内

CPU使用率はパーセンテージで表され、すべてのコンシューマ・グループにわたって集計されます。 使用率は、データベースで使用可能なCPUの数(OCPUの数の2倍)に関してレポートされます。

StorageUtilization

Storage Utilization

パーセンテージ

平均

1時間

1時間

現在使用中のプロビジョニングされたストレージ容量の割合。 すべての表領域の割当て済領域の合計を表します。

BlockChanges

DBブロック変更

変更/秒

平均

1分

5分以内

1秒当たりの変更されたブロックの平均数。

ExecuteCount

実行回数

Count

合計

1分

5分以内

選択した間隔でSQL文を実行したユーザーおよび再帰コールの数。

CurrentLogons

現在のログオン

Count

合計

1分

5分以内

 選択された間隔の成功したログオン数。

TransactionCount

トランザクション件数

Count

合計

1分

5分以内

選択した期間中のユーザー・コミットおよびユーザー・ロールバックを組み合せた数。

UserCalls

ユーザー・コール

Count

合計

1分

5分以内

選択した間隔中のログオン、解析、および実行コールをあわせた数。

ParseCount

解析件数

Count

合計

1分

5分以内

選択した間隔でのハード解析およびソフト解析の数。

StorageUsed

使用済ストレージ領域

GB

Max

1時間

1時間

収集時にデータベースによって使用されていたストレージ領域の合計量。

StorageAllocated

Storage Space Allocated

GB

Max

1時間

1時間

収集時にデータベースに割り当てられていたストレージ領域の合計量

StorageUsedByTablespace

表領域による使用済ストレージ領域

GB

Max

1時間

1時間

収集時に表領域によって使用されたストレージの合計容量。 コンテナ・データベースの場合、このメトリックはルート・コンテナ表領域を提供します。

StorageAllocatedByTablespace

表領域による割当て済ストレージ領域

GB

Max

1時間

1時間

収集時に表領域に割り当てられたストレージ領域の合計量。 コンテナ・データベースの場合、このメトリックはルート・コンテナ表領域を提供します。

StorageUtilizationByTablespace

表領域によるストレージ領域使用率

パーセンテージ

平均

1時間

1時間

これは、表領域が収集時に使用したストレージ領域の割合を示します。 コンテナ・データベースの場合、このメトリックはルート・コンテナ表領域を提供します。

ゲストVMヘルス・メトリック・リスト - 非データベース・メトリック

表5-15 ゲストVMヘルス・メトリック・リスト - 非データベース・メトリック

メトリック名 メトリック表示名 単位 集計 収集頻度 説明

ASMDiskgroupUtilization

ASMディスク・グループ使用率

パーセンテージ

Max

10分

ディスク・グループで使用されている使用可能な領域の割合。 使用可能な領域は、成長に使用できる領域です。 DATAディスク・グループは、Oracleデータベース・ファイルを格納します。 RECOディスク・グループには、アーカイブやフラッシュバック・ログなどのリカバリ用のデータベース・ファイルが含まれています。

FilesystemUtilization

ファイルシステム使用率

パーセンテージ

Max

1分

プロビジョニングされたファイルシステムの利用率。

CpuUtilization

CPU Utilization

パーセンテージ

平均

1分

CPU使用率。

MemoryUtilization

Memory Utilization

パーセンテージ

平均

1分

新規アプリケーションの起動に使用可能なメモリーの割合(スワップなし)。 使用可能なメモリーは、次のコマンドで取得できます: cat /proc/meminfo。

SwapUtilization

スワップ使用率

パーセンテージ

平均

1分

合計スワップ領域の使用率。

LoadAverage

平均のロード

数値

平均

1分

5分間のシステム負荷平均。

NodeStatus

ノード・ステータス

Integer

平均

1分

ホストにアクセスできるかどうかを示します。

OcpusAllocated

割当て済OCPU

Integer

Max

1分

割当て済OCPUの数。

関連トピック

親トピック: VMクラスタの管理

スケール・アップまたはスケール・ダウン操作の概要

Multiple VMs per Exadata system (MultiVM)機能リリースでは、VMクラスタ・リソースをスケール・アップまたはスケール・ダウンできます。

親トピック: VMクラスタの管理

VMクラスタ・リソースのスケール・アップまたはスケール・ダウン

メモリー、ローカル・ディスク・サイズ(/u02)、ASMストレージおよびCPU (X11MのECPU)をスケール・アップまたはスケール・ダウンできます。

ノート:

VMまたはVMクラスタが停止しても、Oracleは請求を停止しません。 VMクラスタの請求を停止するには、OCPU (X11MのECPU)数をゼロに減らします。

これらのリソースをスケール・アップまたはスケール・ダウンするには、顧客DB管理者による既存の使用量および容量管理の完全な監査が必要です。 スケール・ダウン操作中またはスケール・ダウン後の障害を回避するために、既存の使用方法を確認します。 スケール・アップする際には、作成する次のVMクラスタに残っているこれらのリソースの量を考慮してください。 Exadata Cloud@Customer Cloudツールは、VMクラスタ内のメモリー、ローカル・ディスクおよびASMストレージの現在の使用量を計算し、ヘッド・ルームを追加して、スケール・ダウンできない最小値に達し、この最小値を下回る値を指定することを想定しています。

ノート:

  • VMクラスタを作成またはスケーリングする場合、OCPUの数(X11MのECPU)をゼロに設定すると、VMクラスタが停止され、そのVMクラスタに対する請求はなくなりますが、ハイパーバイザでは、各VMの最小2 OCPU (X11Mの8 ECPU)が予約されます。 これらの予約済OCPU (X11MのECPU)は、割り当てられたVMが停止されていても、他のどのVMにも割り当てられません。 コントロール・プレーンでは、使用可能な最大OCPU (X11MのECPU)が表示されている場合、予約済OCPU (X11MのECPU)は考慮されないため、後続のスケーリング操作を実行する際に、操作を正常に完了するのに十分なOCPU (X11MのECPU)を取得できることを確認するために、これらの予約済OCPU (X11MのECPU)を考慮する必要があります。
  • メモリーおよび/u02のスケール・アップまたはスケール・ダウン操作では、現在の値と新しい値の差が2%未満の場合、そのVMは変更されません。 これは、メモリーの変更にはVMの再起動が含まれ、/u02の変更にはOracle Grid Infrastructureスタックの停止と/u02のアンマウントが含まれるためです。 本番顧客は、このようなわずかな増加や減少に対してサイズ変更を行わないため、そのようなリクエストは問題ありません。
  • VMクラスタのいずれかのDBサーバーが停止している場合でも、VMクラスタ・リソースをスケーリングできます:
    • DBサーバーが停止し、スケーリングが実行された場合、DBサーバーとVMがオンラインに戻っても、そのサーバー上のVMは新しいOCPUに自動的にスケーリングされません。 クラスタ内のすべてのVMに同じOCPU値があることを確認するのは、ユーザーの責任です。
    • DBサーバーが停止している場合でも、そのDBサーバー上にVMがあるVMクラスタに対する請求は停止しません。

親トピック: スケール・アップまたはスケール・ダウン操作の概要

メモリーおよびラージ・ページのサイズ変更

VMクラスタでデータベース・サーバーのメモリーをスケール・アップおよびスケール・ダウンできます。 メモリーのスケーリングを有効にするには、データベース・サーバーのローリング再起動が必要です。 メモリーのスケーリングが成功するには、データベースがオープン状態で自動起動する必要があります。

VMクラスタ内のメモリーを変更すると、そのクラスタ内のVMのラージ・ページ(HugePages)設定に影響します。 VMが最初に作成されたとき、各VMオペレーティング・システムは、ラージ・ページ用にVMに割り当てられたメモリーの50%で構成され、データベースはSGAにそのメモリーを使用するように構成されます。 Oracleでは、変更の影響を理解しないかぎり、ラージ・ページ構成を変更しないことをお薦めします。 構成が適切でないと、すべてのデータベースの起動が妨げられ、VMのブートが妨げられることもあります。

ラージ・ページ構成の変更は推奨されませんが、許可されています。 ただし、VMのメモリーが後でサイズ変更される場合は、クラウドの自動化によって変更がオーバーライドされる可能性があります。 メモリー・サイズ変更操作中、クラウド自動化は、最大制限60%で、ラージ・ページのメモリーを合計メモリーの割合として維持しようとします。 ラージ・ページが合計メモリーの60%を超えて使用するように構成されている場合、クラウド自動化によってこの60%の制限に自動的にサイズ変更されます。

新しいラージ・ページの割当てが計算されると、自動化によって次のチェックが実行されます:
  • 条件1: 現在のHugePages使用量に1.15を掛けた値(現在使用されている値より15%多い値)は、新しいラージ・ページ割当てより小さくする必要があります。
  • 条件2: 現在のHugePages使用量に1.15を掛けた値も、新しい合計メモリー・サイズの60%未満である必要があります。

ノート:

現在のHugePagesの使用方法は、現在の合計HugePagesから空きHugePagesを減算して決定されます。
両方の条件が満たされた場合、クラウドの自動化により、メモリーの変更がVMに適用されます。 いずれかの条件が満たされない場合、プロセスは次のようなエラーで終了します: 
EXACLOUD: Requested memory is insufficient. The new hugepage count is <<>>, which is less than the minimum required for the VM. Not proceeding with the change.

このプロセスにより、VMをブートするのに十分な従来型メモリーが確保されます。 サイズ変更を続行する前に、データベース・インスタンスを実行することで、自動化によって事前チェックが実行され、現在のラージ・ページの使用状況が判断されます。 事前チェックで、サイズ変更後に既存のデータベースをサポートするのに十分なサイズのページ・メモリーがないことが示された場合、サイズは失敗し、プロセスは続行されません。

親トピック: スケール・アップまたはスケール・ダウン操作の概要

ASMストレージの計算

次の式を使用して、必要最小限のASMストレージを計算します:

  • DATA、RECOなどのディスク・グループごとに、VMクラスタの任意のゲストVMでasmcmd lsdgコマンドを実行して、合計サイズと空きサイズをノートします。
  • 各ディスク・グループで、使用サイズを (合計サイズ - 空きサイズ) / 3で計算します。 ディスク・グループがトリプル・ミラー化されているため、 /3が使用されます。

  • DATA:RECO比率は次のとおりです:

    80:20 (「ローカル・バックアップ」オプションがユーザー・インタフェースで選択されていない場合)。

    40:60 (「ローカル・バックアップ」オプションがユーザー・インタフェースで選択された場合)。

  • ユーザー・インタフェースで指定された新しい合計サイズが次の条件を満たしていることを確認します:

    DATAの使用済サイズ * 1.15 <= (新規合計サイズ* DATA %)

    RECOの使用済サイズ * 1.15 <= (新規合計サイズ* RECO %)

例5-3 ASMストレージの計算

  1. ゲストVMでasmcmd lsdgコマンドを実行します:
    • SPARSEなし:
      /u01/app/19.0.0.0/grid/bin/asmcmd lsdg
ASMCMD>
State   Type Rebal Sector Logical_Sector Block AU     Total_MB   Free_MB    Req_mir_free_MB   Usable_file_MB   Offline_disks    Voting_files   Name
MOUNTED HIGH N        512     512        4096 4194304 12591936   10426224   1399104           3009040           0                       Y      DATAC5/
MOUNTED HIGH N        512     512        4096 4194304 3135456    3036336    348384            895984            0                       N      RECOC5/
ASMCMD>
    • SPARSEの場合:
      /u01/app/19.0.0.0/grid/bin/asmcmd lsdg
ASMCMD>
State   Type Rebal Sector Logical_Sector Block AU       Total_MB   Free_MB   Req_mir_free_MB   Usable_file_MB   Offline_disks    Voting_files   Name
MOUNTED HIGH N        512     512        4096 4194304   12591936   10426224  1399104           3009040            0                       Y     DATAC5/
MOUNTED HIGH N        512     512        4096 4194304   3135456    3036336   348384            895984             0                       N     RECOC5/
MOUNTED HIGH N        512     512        4096 4194304   31354560   31354500  3483840           8959840            0                       N     SPRC5/
ASMCMD>

    ノート:

    SPARSEディスク・グループ(SPRC5)のすべての属性のリストされた値は、仮想サイズを表します。 Exadata DBシステムおよびExadata Cloud@Customerでは、physicalSizeに1:10の比率を使用 : virtualSize。 したがって、計算のすべての目的で、これらの属性にSPARSEを使用する場合は、前述の値の1/10を使用する必要があります。

  2. ディスク・グループの使用済サイズ= (Total_MB - Free_MB) /3
    • SPARSEなし:

      DATAC5の使用サイズ= (12591936 - 10426224 ) / 3 = 704.98 GB

      RECO5に使用されるサイズ= (3135456 - 3036336 ) / 3 = 32.26 GB

    • SPARSEの場合:

      DATAC5の使用サイズ= (12591936 - 10426224 ) / 3 ~= 704.98 GB

      RECO5に使用されるサイズ= (3135456 - 3036336 ) /3 ~= 32.26 GB

      SPC5の使用サイズ= (1/10 * (31354560) - 31354500)) / 3 ~= 0 GB

  3. ディスク・グループ間のストレージの分散
    • SPARSEなし:

      DATA:この例ではRECO比率は80:20です。

    • SPARSEの場合:

      DATA RECO : この例では、SPARSE比率は60:20:20です。

  4. 新しいリクエスト・サイズは、次の条件を満たす必要があります:
    • SPARSEなし: (たとえば、ユーザー・インタフェースでは5 TBです。)

      5 TB = 5120 GB、5120 *.8 = 4096 GB、5120 *.2 = 1024 GB

      DATAの場合: (704.98 * 1.15 ) <= 4096 GB

      RECOの場合: (32.36 * 1.15) <= 1024 GB

    • SPARSEあり: (たとえば、ユーザー・インタフェースでは8 TBです。)

      8 TB = 8192 GB、8192 *.6 = 4915 GB、8192 *.2 = 1638 GB、8192 *.2 = 1638 GB

      DATAの場合: (704.98 * 1.15 ) <= 4915 GB

      RECOの場合: (32.36 * 1.15) <= 1638 GB

      SPR用: (0 * 1.15) <= 1638 GB

上のサイズ変更が実行されます。 前述の条件が新しいサイズで満たされない場合、サイズ変更は事前チェックに失敗します。

親トピック: スケール・アップまたはスケール・ダウン操作の概要

VMにプロビジョニングできるローカル・ストレージの見積り

VMイメージには、VMとそのオペレーティング・システムの起動および実行に必要なファイル、および/u02に格納されているOracle Homesの領域が含まれます。 VMに関連付けられている任意のファイル・システムに割り当てることができる最小値を超える追加のローカル・ストレージ領域を推定するには、サーバー上のすべてのVMのVMイメージのサイズを合計使用可能領域から減算します。 ファイル・システムを展開してデフォルトのVMイメージ・サイズを変更していない場合は、次のVMイメージ・サイズ(デフォルトおよび最小)を使用します。 VMイメージ・サイズを持っている場合、または変更する予定がある場合は、OCIコンソールおよび「VMクラスタのスケーリング」アクションを使用して、既存のVMクラスタに割り当てられ、使用可能なものをチェックする必要があります。/u02以外のファイル・システムを拡張すると、ファイル・システムに追加されたよりも多くの増分ストレージが消費されるためです。 この情報は、新しいVMクラスタの作成中に「VMクラスタの構成」アクションでも使用できます。

X8-2およびX7-2システム

  • VMイメージで使用可能な合計領域(X7 All Systems): 1237 GB
  • VMイメージで使用可能な合計領域(X8 All Systems): 1037 GB
  • /u02を含むVMイメージ・サイズ(デフォルトおよび最小): 244 GB
  • デフォルト(最小) /u02: 60 GB

X8M-2システム

  • VMイメージで使用可能な合計領域(X8Mベース・システム): 1237 GB
  • VMイメージで使用可能な合計領域(X8M Elastic): 2500 GB
  • /u02を含むVMイメージ・サイズ(デフォルトおよび最小): 244 GB
  • デフォルト(最小) /u02: 60 GB

X11M、X10MおよびX9M-2システム

  • VMイメージに使用可能な合計(ベース・システムX9M): 1077 GB
  • VMイメージで使用可能な合計(エラスティック): 2243 GB
  • /u02を含むVMイメージ・サイズ(デフォルトおよび最小): 244 GB
  • デフォルト(最小) /u02: 60 GB

親トピック: スケール・アップまたはスケール・ダウン操作の概要

ローカル・ストレージのスケーリング

ローカル領域のスケーリング操作のガイドライン

ローカル・ストレージは、VM内の多数の個々のファイル・システムのサイズを変更することでスケーリングできます。 デフォルトでは、ファイルシステムは最小サイズで作成されます。 必要に応じて、ファイル・システムのサイズを増やすことができます。 ただし、縮小できるのは/u02のみです。 他のファイル・システムのサイズは増やすことしかできません。 どのファイル・システムでもサポートされる最大サイズは900 GBです。

すべてのファイル・システムによって消費されるストレージが、ファイル・システム・サイズの合計を超えています。 ファイル・システムのサイズ変更時の空きローカル・ストレージへの影響を確認するには、OCIコンソールに表示される計算を参照してください。

OCIコンソールまたはAPIを使用して、次のローカル・ファイル・システムのサイズを増減できます:

  • /u02

OCIコンソールまたはAPIを使用すると、次のローカル・ファイルシステムのサイズを増やすことができます:

  • /
  • /u01
  • /tmp
  • /var
  • /var/log
  • /var/log/audit
  • /home

ただし、次のローカル・ファイル・システムのサイズを変更することはできません:

  • /crashfiles
  • /boot
  • /acfs01
  • /u01/app/19.0.0.0/grid

ノート:

  • /u02を除き、ファイルシステムを拡張することしかできず、拡張したあとはそのサイズを小さくすることはできません。
  • サイズ変更を有効にするには、各VMのローリング再起動が必要です。
  • 各ファイル・システムは最大900 GBまでしか拡張できません
  • 追加のローカル・ファイル・システムのサイズを増やす機能は、X8M以降のシステムでのみサポートされます。

これらのファイル・システムのサイズ変更の詳細は、「VMにプロビジョニングできるローカル・ストレージの容量の見積り」を参照してください。

現在の使用率に基づくリソース制限

  • スケール・ダウン操作では、クラスタ内のすべてのノードにわたって、ローカル領域使用率が最も高い上位に15%のバッファを残す必要があります。
  • 許可されるノードごとの最小ローカル領域は、前述の2つの制限よりも大きくなります。
  • 各ノードでdf -khコマンドを実行して、ローカル・ストレージが最も高いノードを確認します。
  • csshなどのユーティリティを使用して、クラスタ内のすべてのホストから一度だけ同じコマンドを発行することもできます。
  • 各ノードをスケール・ダウンできるローカル・ストレージの最小値は、= 1.15x (すべてのノードで使用されるローカル領域の最大値)です。

ACFSファイル・システム

サポートからリクエストされた場合は、/acfs01ファイル・システムのサイズを変更することもできます。 このファイルシステムは、ソフトウェアをステージングするためにシステムで使用されます。 Exadataストレージが使用され、/u02について前述の制限の対象にはなりません。 これは、クラスタ内のすべてのノードから表示できる共有ファイル・システムであり、任意のVMのコマンドラインからオンラインでサイズ変更できます。

  • デフォルト・サイズ: /acfs01のデフォルト・サイズは100 GBです。
  • スケーリング /acfs01: /sbin/acfsutilコマンドを使用して、任意のVMからユーザー・グリッドとしてacfs01をスケーリングできます。 リブートは必要ありません。 サイズ変更操作は、VMクラスタで実行されているデータベース・サービスの可用性には影響しません。 gridユーザーが発行する次のコマンドでは、/acfs01のサイズが100 GB増加: /sbin/acfsutil size +100 GB /acfs01。
  • 必要に応じて、追加のACFSファイル・システムを作成できます。 これらはExadata Storageディスク・グループからのストレージも消費し、クラスタ内のすべてのVM間で共有できます。 詳細は、ACFSのドキュメントを参照してください。

親トピック: スケール・アップまたはスケール・ダウン操作の概要

コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用して、Oracle Exadata Database Service on Cloud@CustomerでVMクラスタを作成、編集および管理する方法について学習します。

親トピック: VMクラスタの管理

コンソールを使用したASM VMクラスタの作成

ASM VMクラスタを作成するには、インフラストラクチャの構成に必要なフィールドに値を指定する準備をします。

ASM VMクラスタを作成するには、次のものがあることを確認します:

  • VMクラスタをホストするために、アクティブなExadataインフラストラクチャを使用できます。
  • 検証されたVMクラスタ・ネットワークは、VMクラスタで使用できます。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Exadataインフラストラクチャを含む「リージョン」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. 「Exadata VMクラスタの作成」をクリックします。
  5. Exadata VMクラスタの作成ページで、リクエストされた情報を指定します:
    1. コンパートメントの選択:使用可能なコンパートメントのリストから、VMクラスタを含めるコンパートメントを選択します。
    2. 表示名の指定: 表示名は、VMクラスタの識別に使用できるわかりやすい名前です。 Oracle Cloud識別子(OCID)はVMクラスタを一意に識別するため、名前は一意である必要はありません。
    3. Exadata Infrastructureを選択します:リストから、VMクラスタをホストするExadataインフラストラクチャを選択します。 使用可能でアクティブなExadataインフラストラクチャのないVMクラスタは作成できません。
    4. VMクラスタ・ネットワークの選択: リストから、VMクラスタに使用するVMクラスタ・ネットワーク定義を選択します。 VMクラスタを作成する前に、使用可能で検証済のVMクラスタ・ネットワークが必要です。
    5. VMクラスタを構成します:
      • DBサーバー:
        • VMリソースを割り当てるVM配置の場合は、「DBサーバーの変更」をクリックします。
        • 「DBサーバーの変更」ダイアログで、VMを配置するデータベース・サーバーを少なくとも1つ選択します。 メンテナンス中および計画外停止中も使用可能な高可用性データベース・サービスが必要な場合は、少なくとも2つのデータベース・サーバーを選択します。 VMごとの割当てに使用できる最大リソースは、選択したデータベース・サーバーの数に基づきます。

          ノート:

          • すでに8つのVMが実行されているDBサーバーは選択できません。
          • 選択したDBサーバー間の最大ローカル・ストレージ・リソースを計算する場合、VMをホストするためにシステムが必要とする予約済ローカル・ストレージは、リソースが最も少ないDBサーバーから差し引かれます。

            たとえば、選択したDBサーバーで使用可能なローカル・ストレージがDBサーバー3の場合は823 GB、DBサーバー4の場合は813 GB、選択したサーバー全体の最小値は813 GBで、リソース割当てに使用できる最大値は813 GBです - 184 GB (X8M DBサーバーでVMをホストするために予約されたローカル・ストレージ) = 629 GB。

            詳細は、「VMにプロビジョニングできるローカル・ストレージの容量の見積り」を参照してください。

        • 「変更の保存」をクリックします。
      • VM当たりのOCPU (X11MのECPU)数を指定します: このクラスタ内のVMごとにプロビジョニングするOCPU (X11MのECPU)数を指定します。 X11MにOCPUを0(ゼロ)またはECPUを0(停止VM条件)に指定しないかぎり、最小値は、VMごとに2 OCPU、またはVMごとに8 ECPU (ライブVM条件の場合)です。

        値0を指定すると、VMクラスタ仮想マシンはすべてクラスタ作成プロセスの終了時に停止します。 この場合、後でOCPU (X11MのECPU)リソースをスケーリングして仮想マシンを起動できます。 「コンソールを使用したVMクラスタのリソースのスケーリング」を参照してください。

        VMクラスタ全体のOCPU (X11MのECPU)数は、指定したVMごとのOCPU (X11MのECPU)数と、VMクラスタ用に構成された物理データベース・サーバーの数に基づいて自動的に計算されます。

        OCPU: Oracle Computeユニット(OCPU)は、ハイ・パー・スレッドが有効になっているIntel Xeonプロセッサの1つの物理コアに相当するCPU容量を提供します。 各OCPUが2つのハードウェア実行スレッドに相当し、これをvCPUと言います。

        「Oracle Platform as a Service and Infrastructure as a Service - Public Cloud Service DescriptionsMetered & Non-Metered」を参照してください。

        ECPU: ECPUは、コンピュート・リソースの抽象化されたメジャーです。 ECPUは、コンピュート・サーバーとストレージ・サーバーのプールから柔軟に割り当てられているコアの数に基づきます。

      • VMクラスタのリクエストされたOCPU (X11MのECPU)数: VM当たりのOCPU (X11MのECPU)数を指定フィールドに指定した値に基づいて、VMクラスタに割り当てられたCPUコアの合計数が表示されます。 このフィールドは編集できません。
      • VM当たりのメモリー(GB)を指定します: 各VMのメモリーを指定します。 値は1GBの倍数とする必要があり、Exadataインフラストラクチャで使用可能なメモリーによって制限されます。
      • VMクラスタのリクエストされたメモリー(GB): VM当たりのメモリーの指定(GB)フィールドに指定した値に基づいて、VMクラスタに割り当てられたメモリーの合計量が表示されます。 このフィールドは編集できません。
      • VM当たりのローカル・ファイル・システム・サイズ(GB)を指定します: 個々のVMごとにローカル・ファイル・システム・サイズを指定します。 値は1 GBの倍数である必要があり、X11Mインフラストラクチャ上のファイル・システムの使用可能なサイズによって制限されます。

        ローカル・システム・ストレージの最小サイズは60 GBである必要があります。 新しいVMクラスタを作成するたびに、使用可能な合計領域のうち残りの領域が新しいVMクラスタに使用されます。

        個々のVMごとのサイズを指定する方法の詳細および手順は、スケール・アップまたはスケール・ダウン操作の概要を参照してください。

        1. 「追加のローカル・ファイル・システム構成オプションを表示」をクリックします。
        2. 必要に応じて、/, /u01, /tmp, /var, /var/log, /var/log/auditおよび/homeファイル・システムのサイズを変更します。

          ノート:

          • これらのファイル・システムは拡張のみ可能で、拡張後にサイズを減らすことはできません。
          • バックアップ・パーティションおよびミラー化により、/および/varファイル・システムは、割り当てられた領域の2倍を消費します。これは、読取り専用「ミラー化による / (GB)の割当て済ストレージの合計」および「ミラー化による/var (GB)の割当て済ストレージの合計」フィールドに示されています。
          • VMクラスタの作成後、Exadata Infrastructureの詳細ページの「Exadataリソース」セクションをチェックして、ローカル・ストレージ(/u02)およびローカル・ストレージ(追加のファイル・システム)に割り当てられているファイル・サイズを確認します。
      • VM当たりの予約済ローカル・ストレージ(GB): ルート・ファイル・システム、Oracle Grid Infrastructureホームおよび診断ログ用に内部的に予約されているローカル・ストレージ・サイズを表示します。 このフィールドは編集できません。
    6. Exadataストレージの構成: 次の設定では、VMクラスタで使用するためのExadataストレージの構成方法を定義します。 選択したストレージ・タイプは、VMクラスタが目的のストレージ・タイプでプロビジョニングされた後は、後で変更できません。 選択できるオプションは2つあります: 自動ストレージ・タイプ(ASM)およびExascale。 Exascaleストレージ・タイプの詳細は、「コンソールを使用したExascale VMクラスタの作成」を参照してください。
      自動ストレージ管理(ASM)
      • 使用可能なExadataストレージの指定: 個々のVMのサイズを指定します。 推奨される最小サイズは2 TBです。
      • Exadataスナップショットのストレージの割当て: Exadataスナップショット機能をサポートするために必要なスパース・ディスク・グループを作成するには、このオプションを選択します。 Exadataスナップショットを使用すると、非常に迅速かつ容易に作成および破棄できるOracleデータベースの領域効率のよいクローンを作成できます。
      • ローカル・バックアップ用のストレージの割当て: ローカル・データベース・バックアップを有効にするようにExadataストレージを構成するには、このオプションを選択します。 このオプションを選択すると、バックアップに対応するためにRECOディスク・グループにより多くの領域が割り当てられます。 このオプションを選択しない場合、VMクラスタ内のデータベースのバックアップ先としてローカルExadataストレージを使用することはできません。

      表5-16 ストレージ割当て

      記憶域の割当て DATAディスク・グループ RECOディスク・グループ SPARSEディスク・グループ

      Exadataスナップショット: いいえ

      ローカルExadataストレージでのバックアップの有効化: いいえ

      80%

      20%

      0% (SPARSEディスク・グループは作成されません。)

      Exadataスナップショット: いいえ

      ローカルExadataストレージでのバックアップの有効化: Yes

      40%

      60%

      0% (SPARSEディスク・グループは作成されません。)

      Exadataスナップショットのストレージの割当て: Yes

      ローカルExadataストレージでのバックアップの有効化: いいえ

      60%

      20%

      20%

      Exadataスナップショットのストレージの割当て: Yes

      ローカルExadataストレージでのバックアップの有効化: Yes

      35%

      50%

      15%
    7. バージョンの選択:
      • Oracle Grid Infrastructureバージョンを選択します: リストから、VMクラスタにインストールするOracle Grid Infrastructureリリース(19cおよび23ai)を選択します。

        Oracle Grid Infrastructureリリースによって、VMクラスタでサポートできるOracle Databaseリリースが決まります。 Oracle Grid Infrastructureソフトウェア・リリースより後のOracle Databaseリリースは実行できません。

        ノート:

        Grid Infrastructure 23aiでVMクラスタをプロビジョニングするための最小要件:
        • Exadataシステム・ソフトウェアを実行するExadataゲストVM 23.1.8
        • Exadata Infrastructure Exadataシステム・ソフトウェアの実行23.1.x
      • Exadataゲスト・バージョンの選択:
        • Oracle Linux 7およびExadataイメージ・バージョン22.1.10.0.0.230422のExadataインフラストラクチャ:
          • 「イメージを変更」ボタンは有効になっていません。
          • Oracle Grid Infrastructureバージョンのデフォルトは19.0.0.0.0です。
          • Exadataゲストのバージョンは、ホストOSのバージョンと同じです。
        • Oracle Linux 8およびExadataイメージ・バージョン23.1.3.0.0.230613のExadataインフラストラクチャ:
          • Exadataゲスト・バージョンは、デフォルトで最新(23.1.3.0)になります。
          • Oracle Grid Infrastructureバージョンのデフォルトは19.0.0.0.0です
          • 「イメージを変更」ボタンが有効になっています。
          • 「イメージの変更」をクリックします。

            結果の「イメージの変更」パネルには、使用可能なExadataイメージのメジャー・バージョン(23.1.3.0および22.1.3.0)のリストが表示されます。

            各メジャー・バージョンの最新リリースは、"(latest)で示されます。

          • スライド「使用可能なすべてのバージョンの表示」。

            最新バージョンのExadataイメージ23.1.3.0および22.1.3.0を含む6つの過去のバージョンが表示されます。

          • バージョンの選択
          • 「変更の保存」をクリックします。
    8. SSHキーの追加:VMクラスタ仮想マシンへのアクセスに使用するSSHキー・ペアの公開キー部分を指定します。 キーを含むファイルをアップロードするか、SSHキー文字列を貼り付けることができます。

      複数のキーを指定するには、複数のキー・ファイルをアップロードするか、各キーを別々のフィールドに貼り付けます。 貼り付けられたキーの場合、各キーが単一の連続した行にあることを確認します。 結合キーの長さは10,000文字を超えることはできません。

    9. ライセンス・タイプの選択:
      • ライセンス持込み (BYOL): VMクラスタで使用するOracle Databaseソフトウェア・ライセンスを組織がすでに所有している場合は、このオプションを選択します。
      • 含まれるライセンス: Exadata Database Service on Cloud@Customerの一部としてOracle Databaseソフトウェア・ライセンスをサブスクライブするには、このオプションを選択します。
    10. 診断収集:

      診断収集および通知を有効にすることで、Oracle Cloud操作により、ゲストVMの問題を迅速かつ効果的に識別、調査、追跡および解決できます。 イベントをサブスクライブして、リソース状態の変更に関する通知を取得します。 詳細は、「イベントの開始」を参照してください。

      ノート:

      収集されるイベント、メトリックおよびログ・ファイルのリストが将来変更される可能性があることを理解することに反対しています。 この機能はいつでもオプトアウトできます。
      • 診断イベントの有効化: Oracleがクリティカル・イベント、警告イベント、エラー・イベントおよび情報イベントを収集して公開できるようにします。
      • ヘルス・モニタリングの有効化: Oracleが、Oracle Database up/down、ディスク領域使用量などのヘルス・メトリック/イベントを収集し、Oracle Cloud操作と共有できるようにします。 一部のイベントの通知も受信します。

      • インシデント・ログおよびトレース収集の有効化: Oracleがインシデント・ログおよびトレースを収集して障害診断および問題解決を可能にします。

        デフォルトでは、3つのチェック・ボックスがすべて選択されています。 デフォルト設定をそのままにすることも、必要に応じてチェックボックスをクリアすることもできます。 診断収集設定は、「VMクラスタ詳細」ページの「一般情報」 >> 「診断収集」に表示されます。

        • 有効: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルの収集を選択した場合(3つのオプションすべて)。

        • 無効: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルを収集しないことを選択した場合(3つすべてのオプション)。

        • 一部有効: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルの収集を選択した場合(1つまたは2つのオプション)。
    11. 高度なオプションを表示:
      • タイムゾーン: Exadata InfrastructureのデフォルトのタイムゾーンはUTCですが、別のタイムゾーンを指定することもできます。 タイムゾーン・オプションは、Java.util.TimeZoneクラスとOracle Linuxオペレーティング・システムの両方でサポートされているオプションです。

        ノート:

        UTCまたはブラウザで検出されたタイムゾーン以外のタイムゾーンを設定する場合は、「別のタイムゾーンの選択」オプションを選択し、「リージョン」または「国」を選択してから、対応する「タイムゾーン」を選択します。

        目的のリージョンまたは国が表示されない場合は、「その他」を選択し、適切な「タイムゾーン」を選択します。

      • タグ: オプションで、タグを適用できます。 リソースを作成する権限がある場合は、そのリソースにフリー・フォーム・タグを適用する権限もあります。 定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。 タグ付けの詳細は、「リソース・タグ」を参照してください。 タグを適用するかどうか不明な場合は、このオプションをスキップする(タグを後から適用できます)か、管理者に問い合せてください。
  6. オプションで、リソース構成をスタックとして保存できます。
    • リソース構成をスタックとして保存するには:
      1. 「スタックとして保存」をクリックします。
      2. 結果の「スタックとして保存」ダイアログで、次の詳細を指定します:
        1. 名: (オプション)わかりやすい名前を指定します。
        2. 説明: (オプション)簡単な説明を入力します。
        3. コンパートメント: このスタックが存在するコンパートメントを選択します。
        4. タグ: タグを追加します。
      3. 「保存」をクリックします。

        スタックを保存すると、保存されたスタックへのリンクを含むバナーが表示されます。

      4. リンクをクリックして、Resource Manager Serviceコンソールでスタックを開きます。

        「リソース・マネージャおよびTerraform」を参照してください。

    • スタックの詳細を表示するには:
      1. ナビゲーション・メニューを開きます。 「開発者サービス」の下で、「リソース・マネージャ」をクリックします。
      2. 「スタック」をクリックします。
      3. 詳細を表示するスタックの名前をクリックします。

        または、アクション・メニュー(3つのドット)をクリックし、「スタックの詳細を表示」オプションを選択します。

  7. 「VMクラスタの作成」をクリックします。

    「VMクラスタの詳細」ページが表示されます。 作成プロセスの実行中、VMクラスタの状態は「保留中」です。 VMクラスタの作成プロセスが完了すると、VMクラスタの状態が「使用可能」に変わります。

    「VMクラスタ詳細」ページの「Exadata Databaseストレージ」セクションには、構成されるストレージのタイプ(この場合はASM)が表示されます。

関連トピック

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用したExascale VMクラスタの作成

Exascale VMクラスタを作成するには、インフラストラクチャの構成に必要なフィールドに値を指定する準備をします。

Exascale VMクラスタを作成するには、次のものがあることを確認します:

  • VMクラスタをホストするために使用できるアクティブなExadataインフラストラクチャ。
  • VMクラスタが使用できる検証済みのVMクラスタ・ネットワーク。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Exadataインフラストラクチャを含む「リージョン」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. 「Exadata VMクラスタの作成」をクリックします。
  5. Exadata VMクラスタの作成ページで、リクエストされた情報を指定します:
    1. コンパートメントの選択:使用可能なコンパートメントのリストから、VMクラスタを含めるコンパートメントを選択します。
    2. 表示名の指定: 表示名は、VMクラスタの識別に使用できるわかりやすい名前です。 Oracle Cloud識別子(OCID)はVMクラスタを一意に識別するため、名前は一意である必要はありません。
    3. Exadata Infrastructureを選択します:リストから、VMクラスタをホストするExadataインフラストラクチャを選択します。 使用可能でアクティブなExadataインフラストラクチャのないVMクラスタは作成できません。
    4. VMクラスタ・ネットワークの選択: リストから、VMクラスタに使用するVMクラスタ・ネットワーク定義を選択します。 VMクラスタを作成する前に、使用可能で検証済のVMクラスタ・ネットワークが必要です。
    5. VMクラスタを構成します:
      • DBサーバー:
        • VMリソースを割り当てるVM配置の場合は、「DBサーバーの変更」をクリックします。
        • 「DBサーバーの変更」ダイアログで、VMを配置するデータベース・サーバーを少なくとも1つ選択します。 メンテナンス中および計画外停止中も使用可能な高可用性データベース・サービスが必要な場合は、少なくとも2つのデータベース・サーバーを選択します。 VMごとの割当てに使用できる最大リソースは、選択したデータベース・サーバーの数に基づきます。

          ノート:

          • すでに8つのVMが実行されているDBサーバーは選択できません。
          • 選択したDBサーバー間の最大ローカル・ストレージ・リソースを計算する場合、VMをホストするためにシステムが必要とする予約済ローカル・ストレージは、リソースが最も少ないDBサーバーから差し引かれます。

            たとえば、選択したDBサーバーで使用可能なローカル・ストレージがDBサーバー3の場合は823 GB、DBサーバー4の場合は813 GB、選択したサーバー全体の最小値は813 GBで、リソース割当てに使用できる最大値は813 GBです - 184 GB (X8M DBサーバーでVMをホストするために予約されたローカル・ストレージ) = 629 GB。

            詳細は、「VMにプロビジョニングできるローカル・ストレージの容量の見積り」を参照してください。

        • 「変更の保存」をクリックします。
      • VM当たりのOCPU (X11MのECPU)数を指定します: このクラスタ内のVMごとにプロビジョニングするOCPU (X11MのECPU)数を指定します。 X11MにOCPUを0(ゼロ)またはECPUを0(停止VM条件)に指定しないかぎり、最小値は、VMごとに2 OCPU、またはVMごとに8 ECPU (ライブVM条件の場合)です。

        値0を指定すると、VMクラスタ仮想マシンはすべてクラスタ作成プロセスの終了時に停止します。 この場合、後でOCPU (X11MのECPU)リソースをスケーリングして仮想マシンを起動できます。 「コンソールを使用したVMクラスタのリソースのスケーリング」を参照してください。

        VMクラスタ全体のOCPU (X11MのECPU)数は、指定したVMごとのOCPU (X11MのECPU)数と、VMクラスタ用に構成された物理データベース・サーバーの数に基づいて自動的に計算されます。

        OCPU: Oracle Computeユニット(OCPU)は、ハイ・パー・スレッドが有効になっているIntel Xeonプロセッサの1つの物理コアに相当するCPU容量を提供します。 各OCPUが2つのハードウェア実行スレッドに相当し、これをvCPUと言います。

        「Oracle Platform as a Service and Infrastructure as a Service - Public Cloud Service DescriptionsMetered & Non-Metered」を参照してください。

        ECPU: ECPUは、コンピュート・リソースの抽象化されたメジャーです。 ECPUは、コンピュート・サーバーとストレージ・サーバーのプールから柔軟に割り当てられているコアの数に基づきます。

      • VMクラスタのリクエストされたOCPU (X11MのECPU)数: VM当たりのOCPU (X11MのECPU)数を指定フィールドに指定した値に基づいて、VMクラスタに割り当てられたCPUコアの合計数が表示されます。 このフィールドは編集できません。
      • VM当たりのメモリー(GB)を指定します: 各VMのメモリーを指定します。 値は1GBの倍数とする必要があり、Exadataインフラストラクチャで使用可能なメモリーによって制限されます。
      • VMクラスタのリクエストされたメモリー(GB): VM当たりのメモリーの指定(GB)フィールドに指定した値に基づいて、VMクラスタに割り当てられたメモリーの合計量が表示されます。 このフィールドは編集できません。
      • VM当たりのローカル・ファイル・システム・サイズ(GB)を指定します: 個々のVMごとにローカル・ファイル・システム・サイズを指定します。 値は1 GBの倍数である必要があり、X11Mインフラストラクチャ上のファイル・システムの使用可能なサイズによって制限されます。

        ローカル・システム・ストレージの最小サイズは60 GBである必要があります。 新しいVMクラスタを作成するたびに、使用可能な合計領域のうち残りの領域が新しいVMクラスタに使用されます。

        個々のVMごとのサイズを指定する方法の詳細および手順は、スケール・アップまたはスケール・ダウン操作の概要を参照してください。

        1. 「追加のローカル・ファイル・システム構成オプションを表示」をクリックします。
        2. 必要に応じて、/, /u01, /tmp, /var, /var/log, /var/log/auditおよび/homeファイル・システムのサイズを変更します。

          ノート:

          • これらのファイル・システムは拡張のみ可能で、拡張後にサイズを減らすことはできません。
          • バックアップ・パーティションおよびミラー化により、/および/varファイル・システムは、割り当てられた領域の2倍を消費します。これは、読取り専用「ミラー化による / (GB)の割当て済ストレージの合計」および「ミラー化による/var (GB)の割当て済ストレージの合計」フィールドに示されています。
          • VMクラスタの作成後、Exadata Infrastructureの詳細ページの「Exadataリソース」セクションをチェックして、ローカル・ストレージ(/u02)およびローカル・ストレージ(追加のファイル・システム)に割り当てられているファイル・サイズを確認します。
      • VM当たりの予約済ローカル・ストレージ(GB): ルート・ファイル・システム、Oracle Grid Infrastructureホームおよび診断ログ用に内部的に予約されているローカル・ストレージ・サイズを表示します。 このフィールドは編集できません。
    6. Exadataストレージの構成: 次の設定では、VMクラスタで使用するためのExadataストレージの構成方法を定義します。 選択したストレージ・タイプは、VMクラスタが目的のストレージ・タイプでプロビジョニングされた後は、後で変更できません。 選択できるオプションは2つあります: 自動ストレージ・タイプ(ASM)およびExascale。 ASMストレージ・タイプの詳細は、「コンソールを使用したASM VMクラスタの作成」を参照してください。

      ノート:

      Exascaleストレージを構成するための最小要件

      • この機能は、Exadata InfrastructureモデルX8M以降でサポートされています。
      • この機能は、Exadataシステム・ソフトウェア・リリース24.1以降で使用できます。
      • この機能には、Oracle Grid Infrastructureバージョン23ai (24.3)が必要で、Oracleデータベース・バージョン23ai (23.4)以降をサポートしています。

      最小要件が満たされない場合、Exascaleオプションは無効になります。

      Exascaleデータベース・ストレージ・ボールト:
      • 新しいストレージ・ボールトを作成します: VMクラスタのプロビジョニング中に新しいExascaleデータベース・ストレージ・ボールトを作成するには、このオプションを選択します。
        • ストレージ・ボールト名: ボールトのわかりやすい名前を入力します。 このボールトを別のコンパートメントに作成する場合は、「コンパートメントの変更」リンクをクリックし、コンパートメントを選択します。
        • データベースのストレージ容量: 画面に表示される最小値と最大値内のデータベースのストレージ容量を入力します。

          ノート:

          表示されている最大値を超える追加の領域が必要な場合は、Exascale容量を増やす必要があります。 詳細は、「コンソールを使用したExascale Storage Vaultのスケーリング」」を参照してください。
      • 既存のストレージ・ボールトの選択: 選択したコンパートメントに存在するボールトを選択します。
    7. バージョンの選択:

      ノート:

      Exascale VMクラスタにプロビジョニングできるのは、Oracleデータベース23aiのみです。
      • Oracle Grid Infrastructureバージョンを選択します: Oracle Grid Infrastructureリリースのデフォルトは23aiです。
      • Exadataゲスト・バージョンの選択:
        • Exadataゲスト・バージョンのデフォルトは最新(24.1.6.0)です
        • Oracle Grid Infrastructureバージョンのデフォルトは23aiです
        • 「イメージを変更」ボタンが有効になっています。
        • 「イメージの変更」をクリックします。

          結果の「変更」イメージ・パネルには、使用可能なExadataイメージのメジャー・バージョン(24.1.6.0以降)のリストが表示されます。

          各メジャー・バージョンの最新リリースは、"(latest)で示されます。

        • スライド「使用可能なすべてのバージョンの表示」。

          Exadataイメージの最新バージョン24.1.6.0以降を含む6つの過去のバージョンが表示されます。

        • バージョンの選択
        • 「変更の保存」をクリックします。
    8. SSHキーの追加:VMクラスタ仮想マシンへのアクセスに使用するSSHキー・ペアの公開キー部分を指定します。 キーを含むファイルをアップロードするか、SSHキー文字列を貼り付けることができます。

      複数のキーを指定するには、複数のキー・ファイルをアップロードするか、各キーを別々のフィールドに貼り付けます。 貼り付けられたキーの場合、各キーが単一の連続した行にあることを確認します。 結合キーの長さは10,000文字を超えることはできません。

    9. ライセンス・タイプの選択:
      • ライセンス持込み (BYOL): VMクラスタで使用するOracle Databaseソフトウェア・ライセンスを組織がすでに所有している場合は、このオプションを選択します。
      • 含まれるライセンス: Exadata Database Service on Cloud@Customerの一部としてOracle Databaseソフトウェア・ライセンスをサブスクライブするには、このオプションを選択します。
    10. 診断収集:

      診断収集および通知を有効にすることで、Oracle Cloud操作により、ゲストVMの問題を迅速かつ効果的に識別、調査、追跡および解決できます。 イベントをサブスクライブして、リソース状態の変更に関する通知を取得します。 詳細は、「イベントの開始」を参照してください。

      ノート:

      収集されるイベント、メトリックおよびログ・ファイルのリストが将来変更される可能性があることを理解することに反対しています。 この機能はいつでもオプトアウトできます。
      • 診断イベントの有効化: Oracleがクリティカル・イベント、警告イベント、エラー・イベントおよび情報イベントを収集して公開できるようにします。
      • ヘルス・モニタリングの有効化: Oracleが、Oracle Database up/down、ディスク領域使用量などのヘルス・メトリック/イベントを収集し、Oracle Cloud操作と共有できるようにします。 一部のイベントの通知も受信します。

      • インシデント・ログおよびトレース収集の有効化: Oracleがインシデント・ログおよびトレースを収集して障害診断および問題解決を可能にします。

        デフォルトでは、3つのチェック・ボックスがすべて選択されています。 デフォルト設定をそのままにすることも、必要に応じてチェックボックスをクリアすることもできます。 診断収集設定は、「VMクラスタ詳細」ページの「一般情報」 >> 「診断収集」に表示されます。

        • 有効: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルの収集を選択した場合(3つのオプションすべて)。

        • 無効: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルを収集しないことを選択した場合(3つすべてのオプション)。

        • 一部有効: 診断、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルの収集を選択した場合(1つまたは2つのオプション)。
    11. 高度なオプションを表示:
      • タイムゾーン: Exadata InfrastructureのデフォルトのタイムゾーンはUTCですが、別のタイムゾーンを指定することもできます。 タイムゾーン・オプションは、Java.util.TimeZoneクラスとOracle Linuxオペレーティング・システムの両方でサポートされているオプションです。

        ノート:

        UTCまたはブラウザで検出されたタイムゾーン以外のタイムゾーンを設定する場合は、「別のタイムゾーンの選択」オプションを選択し、「リージョン」または「国」を選択してから、対応する「タイムゾーン」を選択します。

        目的のリージョンまたは国が表示されない場合は、「その他」を選択し、適切な「タイムゾーン」を選択します。

      • タグ: オプションで、タグを適用できます。 リソースを作成する権限がある場合は、そのリソースにフリー・フォーム・タグを適用する権限もあります。 定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。 タグ付けの詳細は、「リソース・タグ」を参照してください。 タグを適用するかどうか不明な場合は、このオプションをスキップする(タグを後から適用できます)か、管理者に問い合せてください。
  6. オプションで、リソース構成をスタックとして保存できます。
    • リソース構成をスタックとして保存するには:
      1. 「スタックとして保存」をクリックします。
      2. 結果の「スタックとして保存」ダイアログで、次の詳細を指定します:
        1. 名: (オプション)わかりやすい名前を指定します。
        2. 説明: (オプション)簡単な説明を入力します。
        3. コンパートメント: このスタックが存在するコンパートメントを選択します。
        4. タグ: タグを追加します。
      3. 「保存」をクリックします。

        スタックを保存すると、保存されたスタックへのリンクを含むバナーが表示されます。

      4. リンクをクリックして、Resource Manager Serviceコンソールでスタックを開きます。

        「リソース・マネージャおよびTerraform」を参照してください。

    • スタックの詳細を表示するには:
      1. ナビゲーション・メニューを開きます。 「開発者サービス」の下で、「リソース・マネージャ」をクリックします。
      2. 「スタック」をクリックします。
      3. 詳細を表示するスタックの名前をクリックします。

        または、アクション・メニュー(3つのドット)をクリックし、「スタックの詳細を表示」オプションを選択します。

  7. 「VMクラスタの作成」をクリックします。

    「VMクラスタの詳細」ページが表示されます。 作成プロセスの実行中、VMクラスタの状態は「保留中」です。 VMクラスタの作成プロセスが完了すると、VMクラスタの状態が「使用可能」に変わります。

    「VMクラスタ詳細」ページの「Exadata Databaseストレージ」セクションには、構成されたストレージ・ストレージのタイプ(この場合はExascale)が表示されます。

関連トピック

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用した診断収集の有効化、部分的に有効化または無効化

VMクラスタのプロビジョニング後に、ゲストVMの診断収集を有効化、部分的に有効化または無効化できます。 VMクラスタ・レベルで診断収集を有効にすると、VMクラスタの下のすべてのリソース(DBホーム、データベースなど)に構成が適用されます。

ノート:

  • 収集されるイベント、メトリックおよびログ・ファイルのリストが将来変更される可能性があることを理解することに反対しています。 この機能はいつでもオプトアウトできます。
  • Oracleでは将来、より多くのメトリックを追加できますが、すでにメトリックの収集を選択している場合は、オプトイン値を更新する必要はありません。 現在のプリファレンスに基づいて有効/無効のままになります。
  • 以前にインシデント・ログおよびトレース・ファイルの収集をオプト・インし、Oracle Cloud操作でログ収集ジョブを実行したときにオプト・アウトすると、ジョブはそのコースを実行し、取り消しません。 インシデント・ログおよびトレース・ファイル収集オプションに再度オプトインするまで、今後のログ収集は行われません。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. Exadataインフラストラクチャを含む「リージョン」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. 診断データ収集を有効または無効にするVMクラスタの名前をクリックします。
  5. 「VMクラスタ詳細」ページの「一般情報」で、「診断収集」を有効化、部分的に有効化または無効化します。
  6. 「編集」をクリックします。

    「診断収集設定の編集」ウィンドウが表示されます。

  7. チェックボックスを選択または選択解除して、「変更内容を保存」をクリックします。

関連トピック

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用したプロビジョニングされたクラスタへのVMの追加

プロビジョニングされたクラスタに仮想マシンを追加するには、この手順を使用します。

VMクラスタがExadata Database Service Guest VM OS 23.1にアップグレードされると、Exadata Cloud@CustomerインフラストラクチャでExadata System Softwareバージョン22.1.16以降が実行されている場合は、新しいVMまたは新しいデータベース・サーバーをこのVMクラスタに追加できます。

ノート:

Exadata System Software 23.1 for Exadata Cloud@Customer Infrastructureへのアップグレードは、2023年2月の更新サイクルで使用可能になります。
プロビジョニングされたクラスタにVMを追加する際に役立つ次の点を確認してください。
  • クラスタ内の既存のプロビジョニングされたVMで実行されている同じゲストOSイメージ・バージョンを使用して、VMクラスタを拡張するために追加された新しいVMをプロビジョニングします。 ただし、既存のVMでゲストOSイメージに対して行われたカスタマイズは、新しく追加されたVMに手動で適用する必要があります。
  • 1年以上前のゲストOSイメージ・バージョンを実行しているVMクラスタの場合は、クラスタを拡張するためにVMを追加する前にゲストOSイメージのバージョンを更新する必要があります。
  • Data Guard構成に含まれないデータベースでは、既存のクラスタ内のすべてのVMで実行されているデータベースのみが、新しくプロビジョニングされたVMに追加されます。 VMのサブセットで実行されているデータベースは、新しく追加されたVMで実行するように自動的に拡張されません。
VMをVMクラスタに追加しようとすると、エラー[FATAL] [INS-32156] Installer has detected that there are non-readable files in oracle home.が発生することがあります この問題を解決するには、クラスタ・ノードを追加する前に、「VMクラスタへのVMの追加が失敗」で説明されているステップに従います。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。

    VMクラスタがデフォルトで選択されています。

  2. コンパートメントを選択します。

    選択したコンパートメントのVMクラスタのリストが表示されます。

  3. 仮想マシンを追加するVMクラスタの名前をクリックします。
  4. 「VMクラスタ詳細」ページの「リソース」で、「仮想マシン」をクリックし、「仮想マシンの追加」をクリックします。
  5. 「仮想マシンの追加」ダイアログで、VMを追加する追加のDBサーバーを選択します。

    既存のDBサーバーは選択解除できません。 新しく追加されたDBサーバーに基づいて、VMごとに使用可能な最大リソースが更新されます。

    DBサーバー・ステータスには、「このVMクラスタ内」、「ネットワークが構成されていません」、「追加可能」および「リソース不足」があります。 「追加可能」ステータスのDBサーバーのみを追加できます。

    ネットワークが構成されていないDBサーバーは追加できません。 ネットワークを構成するには、関連付けられたインフラストラクチャのVMクラスタ・ネットワークを編集します。 詳細は、「コンソールを使用したVMクラスタ・ネットワークへの別のDBサーバーの追加」を参照してください。

  6. 「追加可能」ステータスのDBサーバーを選択し、「変更内容を保存」をクリックします。

    DBサーバーのステータスが割当て済に変わります。

    ノート:

    割り当てられたDBサーバーは削除できません。

新しく追加されたVMのData Guard対応データベースのデータベース・インスタンスを拡張するには、「Data Guard対応データベースのノード・リストは更新されません」を参照してください。

関連トピック

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用したExadata Infrastructure上のDBサーバーのリストの表示

Oracle Exadata Cloud@Customerシステム上のデータベース・サーバー・ホストのリストを表示するには、この手順を使用します。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「インフラ」の下で、Exadata Infrastructureをクリックします。
  3. Exadata Infrastructuresのリストで、詳細を表示するインフラストラクチャの表示名をクリックします。
  4. 「リソース」の下で、「DBサーバー」をクリックします。
  5. DBサーバーのリストで、詳細を表示するDBサーバーの名前をクリックします。

    DBサーバーは、ホストされている各クラスタのVMと、それらに割り当てられたリソースをリストします。

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用したVMクラスタからのVMの削除

プロビジョニングされたクラスタから仮想マシンを削除するには、この手順を使用します。

ノート:

クラスタからVMを終了するには、VMからData Guard構成(プライマリまたはスタンバイ)の一部であるデータベースを削除し、終了フローを続行する必要があります。 手動ステップの詳細は、My Oracle Supportノート2811352.1を参照してください。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. CPUリソースをスケーリングするVMクラスタを含む「リージョン」および「コンパートメント」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. 仮想マシンを削除するVMクラスタの名前をクリックします。
  5. 「リソース」の下で、「仮想マシン」をクリックします。
  6. 仮想マシンのリストで、仮想マシンの「アクション」アイコン(3つのドット)をクリックし、「削除」をクリックします。
  7. 「仮想マシンの終了」ダイアログで、仮想マシンの名前を入力し、「削除」をクリックします。

    VMがクラスタから削除されました。 「VMクラスタ詳細」ページには、更新されたリソース割当ての詳細が「VMクラスタ・リソースの割当て」の下に表示されます。

関連トピック

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用したVMクラスタのライセンス・タイプの更新

ライセンスを変更するには、ライセンス情報の変更に必要なフィールドに値を指定する準備をします。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. ライセンス・タイプを更新するVMクラスタを含む「リージョン」および「コンパートメント」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. ライセンス・タイプを更新するVMクラスタの名前をクリックします。

    「VMクラスタ詳細」ページには、選択したVMクラスタに関する情報が表示されます。

  5. 「ライセンス・タイプの更新」をクリックします。
  6. ダイアログ・ボックスで、次のライセンス・タイプのいずれかを選択し、「変更内容を保存」をクリックします。
    • ライセンス持込み (BYOL): VMクラスタで使用するOracle Databaseソフトウェア・ライセンスを組織がすでに所有している場合は、このオプションを選択します。
    • 含まれるライセンス: Exadata Database Service on Cloud@Customerの一部としてOracle Databaseソフトウェア・ライセンスをサブスクライブするには、このオプションを選択します。

    ライセンス・タイプを更新しても、VMクラスタの機能が変更されたり、操作が中断されることはありません。 お客様は、VMクラスタのライセンス・タイプを月に1回のみ変更できます。

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

VMクラスタの作成後のコンソールを使用したSSHキーの追加

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Cloud@Customerをクリックします。
  2. Exadataインフラストラクチャを含む「リージョン」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. SSHキーを追加するVMクラスタの名前をクリックします。
  5. 「VMクラスタ詳細」ページで、「SSHキーの追加」をクリックします。
  6. SSHキーの追加ダイアログで、次のいずれかのメソッドを選択します:
    • SSHキー・ペアの生成: コントロール・プレーンで公開キーと秘密キーのペアを生成する場合は、このオプションを選択します。

      「秘密キーの保存」および「公開キーの保存」をクリックして、SSHキー・ペアをダウンロードして保存します。

    • SSHキー・ファイルのアップロード: SSHキー・ペアを含むファイルをアップロードするには、このオプションを選択します。
    • SSHキーの貼付け: SSHキー文字列を貼り付けるには、このオプションを選択します。

      複数のキーを指定するには、「別のSSHキー」をクリックします。 貼り付けられたキーの場合、各キーが単一の連続した行にあることを確認します。 結合キーの長さは10,000文字を超えることはできません。

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

関連トピック

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用したVMクラスタのリソースのスケーリング

Oracle Exadata Database Service on Cloud@Customer以降では、複数のリソースを同時にスケールアップまたはスケール・ダウンできます。 リソースを一度に1つずつスケール・アップまたはスケール・ダウンすることもできます。

次の状況でリソースをスケール・ダウンします:
  • ユースケース1: すべてのリソースを1つのVMクラスタに割り当てる場合で、複数のVMクラスタを作成する場合は、新しいクラスタに割り当てるために使用可能なリソースはありません。 したがって、必要に応じてリソースをスケール・ダウンして、追加のVMクラスタを作成します。
  • ユースケース2: ワークロードに基づいて異なるリソースを割り当てる場合は、それに応じてスケール・ダウンまたはスケール・アップします。 たとえば、レポート/ETLのために夜間バッチ・ジョブを実行し、ジョブが終了したらVMをスケール・ダウンできます。
次のリソースを任意の組合せでスケール・ダウンできます:
  • OCPU (X11MのECPU)
  • メモリー
  • ローカル記憶域
  • Exadataストレージ

各スケーリング操作が完了するまでには数分かかる場合があります。 各操作の時間はシステム内のアクティビティによって異なりますが、原則として、ほとんどの操作はクォータ・ラックでは15分、ハーフ・ラックでは20分、フル・ラックでは30分以内に完了する必要があります。 短期間で複数のOCPU (X11MのECPU)スケーリング操作を実行すると、完了までの時間が長くなる可能性があります。 オンラインですが、OCPU (X11MのECPU)スケーリングは、システム全体に影響を及ぼす前に異常を検出して保護するために、すべてのVMにパラレルに実装されるわけではありません。 メモリーおよびローカル・ストレージのスケーリングでは、VMの再起動が必要であり、ローリング方式で一度に1つのVMが実行されます。

複数のスケール・ダウン操作を実行すると、各操作がシリアルに実行されます。 たとえば、コンソールからメモリーおよびローカル・ストレージをスケーリングすると、システムは最初にメモリーをスケーリングし、その操作が完了するとストレージをスケーリングします。 すべての操作を完了するまでの時間は、個々の操作を完了するまでの時間の合計になります。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. CPUリソースをスケーリングするVMクラスタを含む「リージョン」および「コンパートメント」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. CPUリソースをスケーリングするVMクラスタの名前をクリックします。

    「VMクラスタの詳細」ページには、選択したVMクラスタに関する情報が表示されます。

  5. 「スケール・アップ/ダウン」をクリックします。
  6. ダイアログ・ボックスで、次のいずれかまたはすべてを調整します:
    • OCPU (X11MのECPU)数:

      OCPU (X11MのECPU)数値は、すべての仮想マシンで同じ数のCPUコアが有効になるように、仮想マシンの数の倍数にする必要があります。

      OCPU (X11MのECPU)数をゼロに設定すると、VMクラスタ仮想マシンがすべて停止します。 ゼロ設定から変更すると、VMクラスタ仮想マシンはすべて起動されます。 それ以外の場合、有効なCPUコアの数の変更はオンライン操作であり、この操作のために仮想マシンは再起動されません。 「システム構成」も参照してください。

      ノート:

      CPU_COUNTデータベース初期化パラメータを明示的に設定している場合、その設定は、VMクラスタに割り当てられているCPUコアの数を変更しても影響を受けません。 したがって、Oracle Databaseインスタンス・ケージング機能を有効にした場合、CPU_COUNT設定を変更するまで、データベース・インスタンスは余分なCPUコアを使用しません。 CPU_COUNTが0 (デフォルト設定)に設定されている場合、Oracle Databaseはオペレーティング・システムによってレポートされるCPUの数を継続的に監視し、現在の数を使用します。
    • メモリー:

      個々のVMのメモリーを指定します。 値は1GBの倍数とする必要があり、Exadataインフラストラクチャで使用可能なメモリーによって制限されます。

      メモリーをスケール・アップまたはスケール・ダウンすると、関連付けられた仮想マシンは、VMクラスタへの影響を最小限に抑えるために一度に1つの仮想マシンにローリング方式で再起動されます。

    • ローカル・ファイル・システムのサイズ:

      個々のVMのサイズを指定します。 値は1GBの倍数とする必要があり、Exadataインフラストラクチャで使用可能なファイル・システムのサイズによって制限されます。

      ローカル・ファイル・システム・サイズをスケール・アップまたはスケール・ダウンすると、VMクラスタへの影響を最小限に抑えるために、関連する仮想マシンは1度に1つの仮想マシンにローリング方式で再起動されます。

      1. 「追加のローカル・ファイル・システム構成オプションを表示」をクリックします。
      2. 必要に応じて、/, /u01, /tmp, /var, /var/log, /var/log/auditおよび/homeファイル・システムのサイズを変更します。

        ノート:

        • これらのファイル・システムは拡張のみ可能で、拡張後にサイズを減らすことはできません。
        • バックアップ・パーティションおよびミラー化により、/および/varファイル・システムは、割り当てられた領域の2倍を消費します。これは、読取り専用「ミラー化による / (GB)の割当て済ストレージの合計」および「ミラー化による/var (GB)の割当て済ストレージの合計」フィールドに示されています。
      3. VMクラスタの作成後、Exadata Infrastructureの詳細ページの「Exadataリソース」セクションをチェックして、ローカル・ストレージ(/u02)およびローカル・ストレージ(追加のファイル・システム)に割り当てられているファイル・サイズを確認します。

      VMごとに予約されたローカル・ストレージ(GB): ルート・ファイル・システム、Oracle Grid Infrastructureホームおよび診断ログ用に内部的に予約されたサイズを表示します。

    • 使用可能なExadataストレージ・サイズ:

      VMクラスタに割り当てられるExadataストレージの合計量を指定します。 このストレージは、すべてのExadata Storage Serverから均等に割り当てられます。 推奨される最小サイズは2 TBです。

      VMクラスタのExadataストレージの割当てを削減できます。 ただし、新しい金額が既存のコンテンツを対象としていることを確認し、データの予想される増加を可能にする必要もあります。

      ノート:

      サイズを小さくする場合、新しいサイズは現在使用されているサイズよりも15%以上大きくする必要があります。

      VMクラスタに割り当てられたExadataストレージを変更することはオンライン操作です。 この操作により、仮想マシンは再起動されません。

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

関連トピック

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用したVMクラスタ仮想マシンの停止、起動または再起動

コンソールを使用して、仮想マシンを停止、起動またはリブートします。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 停止、起動または再起動する仮想マシンを含むVMクラスタに関連付けられている「リージョン」および「コンパートメント」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. 停止、起動または再起動する仮想マシンを含むVMクラスタの名前をクリックします。

    「VMクラスタ詳細」ページには、選択したVMクラスタに関する情報が表示されます。

  5. 「リソース」リストで「仮想マシン」をクリックします。

    仮想マシンのリストが表示されます。

  6. ノードのリストで、ノードのアクションアイコン(3ドット)をクリックし、次のいずれかのアクションをクリックします:
    1. 開始: 停止しているノードを再起動します。 ノードが再起動すると、「停止」アクションが有効になります。
    2. 停止: ノードを停止します。 ノードが停止すると、「開始」アクションが有効になります。
    3. 再起動: ノードを停止してから再起動します。

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用したVMクラスタ仮想マシンのステータスの確認

VMクラスタ仮想マシンのヘルス・ステータスを確認します。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 目的の仮想マシンを含むVMクラスタに関連付けられている「リージョン」および「コンパートメント」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. 目的の仮想マシンを含むVMクラスタの名前をクリックします。

    「VMクラスタ詳細」ページには、選択したVMクラスタに関する情報が表示されます。

  5. 「リソース」リストで「仮想マシン」をクリックします。

    仮想マシンのリストが表示されます。 VMクラスタの各仮想マシンについて、名前、状態およびクライアントのIPアドレスが表示されます。

  6. ノード・リストで、目的の仮想マシンを検索し、その状態を確認します。

    アイコンとそのステータスを示す関連テキストの色。

    • 使用可能: 緑色のアイコン。 ノードは操作可能です。
    • 開始: 黄色のアイコン。 コンソールまたはAPIの起動または再起動アクションのため、ノードが起動しています。
    • 停止中: 黄色のアイコン。 コンソールまたはAPIでの停止または再起動アクションのため、ノードが停止しています。
    • 停止: 黄色のアイコン。 ノードが停止されます。
    • 失敗: 赤色のアイコン。 エラー状態により、仮想マシンの継続的な操作が防止されます。

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用したVMクラスタの別のコンパートメントへの移動

Oracle Exadata Database Service on Cloud@CustomerでVMクラスタを含むコンパートメントを変更するには、この手順を使用します。

VMクラスタを移動すると、コンパートメントの変更は、VMクラスタに関連付けられている仮想マシンとデータベースにも適用されます。 ただし、コンパートメントの変更は、現在のコンパートメントに残るExadataインフラストラクチャなどの他の関連リソースには影響しません。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 移動するVMクラスタを含む「リージョン」および「コンパートメント」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. 移動するVMクラスタの名前をクリックします。

    「VMクラスタ詳細」ページには、選択したVMクラスタに関する情報が表示されます。

  5. 「リソースの移動」をクリックします。
  6. 表示されるダイアログで、VMクラスタの新しいコンパートメントを選択し、「リソースの移動」をクリックします。

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

コンソールを使用したVMクラスタの終了

VMクラスタを終了する前に、そのクラスタに含まれるデータベースを終了する必要があります。

VMクラスタを終了すると、Cloud Control Planeから削除されます。 このプロセスでは、仮想マシンとその内容が破棄されます。
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 終了するVMクラスタを含む「リージョン」および「コンパートメント」を選択します。
  3. 「VMクラスタ」をクリックします。
  4. 終了するVMクラスタの名前をクリックします。

    「VMクラスタ詳細」ページには、選択したVMクラスタに関する情報が表示されます。

  5. 「終了」をクリックします。
  6. 表示されるダイアログで、VMクラスタの名前を入力し、「VMクラスタの終了」をクリックしてアクションを確認します。

親トピック: コンソールを使用したOracle Exadata Database Service on Cloud@CustomerでのVMクラスタの管理

APIを使用したOracle Exadata Database Service on Cloud@Customer VMクラスタの管理

APIコールのリストを確認して、Oracle Exadata Database Service on Cloud@Customer VMクラスタ・ネットワークおよびVMクラスタを管理します。

APIの使用およびリクエストの署名の詳細は、「REST API」および「セキュリティ資格証明」を参照してください。 SDKの詳細は、「ソフトウェア開発キットおよびコマンドライン・インタフェース」を参照してください。

次のAPI操作を使用して、Oracle Exadata Database Service on Cloud@Customer VMクラスタ・ネットワークおよびVMクラスタを管理します:

VMクラスタ・ネットワーク:
  • GenerateRecommendedVmClusterNetwork
  • CreateVmClusterNetwork
  • DeleteVmClusterNetwork
  • GetVmClusterNetwork
  • ListVmClusterNetworks
  • UpdateVmClusterNetwork
  • ValidateVmClusterNetwork
VMクラスタ:
  • CreateVmCluster
  • DeleteVmCluster
  • GetVmCluster
  • ListVmClusters
  • UpdateVmCluster

APIの完全なリストは、「データベース・サービスAPI」を参照してください。

関連トピック

親トピック: VMクラスタの管理

コンソール接続を使用した仮想マシンのトラブルシューティング

コンソール接続を使用して、正常に動作していない仮想マシンをトラブルシューティングできます。 たとえば、以前作業していたゲストVMは応答を停止します。

ノート:

シリアル・コンソール機能を使用するには、22.Xユーザーの場合はExadata Infrastructureバージョン22.1.10以上、23.Xユーザーの場合はバージョン23.1.1以上が必要です。 シリアル・コンソール機能は、すぐに作成された新しいVMクラスタで使用できますが、次回の四半期メンテナンス・サイクル後に、以前の既存のVMクラスタでのみ使用できます。 また、opcまたはrootユーザーのパスワードの設定など、次に示すすべての前提条件を確認してください。 これらの要件を事前に満たすために必要な変更を行わないと、VMにアクセスできない場合、必要に応じてシリアル・コンソールに緊急に接続できなくなります。

管理および一般的な使用のために実行中のインスタンスに接続するには、Secure Shell (SSH)を使用します。 詳細は、「SSHを使用した仮想マシンへの接続」を参照してください

シリアル・コンソールへのSSH接続を行うには、次の構成ステップに従います。
  1. 適切な権限があることを確認してください。
  2. SSHキー・ペアの作成(まだない場合)を含め、前提条件を完了します。
  3. 仮想マシン・シリアル・コンソールを作成します。
  4. SSHを介してシリアル・コンソールに接続します。
インストールされているDBサーバーのバージョンを確認するには、次のステップを実行します:
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 「リージョン」で、Oracle Exadataインフラストラクチャに関連付けるリージョンを選択します。
  3. 「インフラストラクチャ」の下で、Exadata Infrastructureをクリックします。
  4. 目的のインフラストラクチャの名前をクリックします。
  5. 表示される「インフラストラクチャの詳細」ページで、「バージョン」セクションに移動して、インストールされているDBサーバーのバージョンを確認します。

親トピック: VMクラスタの管理

必要なIAMポリシー

管理者は、IAMポリシーを介して、Exadata Database Service on Cloud@Customerシステムの仮想マシン・コンソールへのセキュア・アクセス権を付与する必要があります。

このアクセスは、コンソールを使用しているか、SDK、CLIまたはその他のツールでREST APIを使用しているかにかかわらず必要です。 権限がない、または認可されていないというメッセージが表示された場合は、どのタイプのアクセス権があり、どのcompartmentで作業するかを管理者に確認してください。

仮想マシン・コンソール接続を作成するには、管理者は、IAMポリシーを介した仮想マシン・コンソール接続の読取りおよび管理へのアクセス権をユーザーに付与する必要があります。 仮想マシン・コンソール接続のリソース名はdbnode-console-connectionです。 仮想マシンのリソース名はdb-nodesです。 次のポリシーは、仮想マシン・コンソール接続を作成する権限を付与します: 

Allow group <group_name> to manage dbnode-console-connection in tenancy
Allow group <group_name> to read db-nodes in tenancy

親トピック: コンソール接続を使用した仮想マシンのトラブルシューティング

前提条件

SSHクライアントをインストールし、SSHキー・ペアを作成する必要があります。

親トピック: コンソール接続を使用した仮想マシンのトラブルシューティング

コントロール・プレーン接続用に開くポート

コントロール・プレーン・サーバー(CPS)が必要なOCIエンドポイントに到達できるように、ファイアウォール・ルールが正しいことを確認してください。 詳細については、表3-2を参照してください

親トピック: 前提条件

SSHクライアントとコマンドライン・シェルのインストール(Microsoft Windows)

Microsoft Windowsには、デフォルトではSSHクライアントは含まれません。 Windowsクライアントから接続する場合は、SSHクライアントをインストールする必要があります。 PuTTY plink.exeをWindows PowerShellとともに使用することも、次のようなOpenSSHのバージョンを含むソフトウェアを使用することもできます:

このトピックの手順は、PuTTYおよびWindows PowerShellを頻繁に使用します。

Windows PowerShellを指定してWindowsからコンソール接続を行う場合、PowerShellがすでにWindowsオペレーティング・システムにインストールされている可能性があります。 そうでない場合は、リンクのステップに従います。 PowerShellを使用してWindowsクライアントからインスタンスに接続する場合は、plink.exeが必要です。plink.exeは、PuTTYに含まれているコマンド・リンク接続ツールです。 PuTTYをインストールするか、plink.exeを個別にインストールできます。 インストールの詳細は、http://www.putty.orgを参照してください。

親トピック: 前提条件

SSHキー・ペアの作成

セキュアなコンソール接続を作成するには、SSHキー・ペアが必要です。 キー・ペアの作成に使用されるメソッドは、オペレーティング・システムによって異なります。 シリアル・コンソールに接続する場合は、RSAキーを使用する必要があります。 この項の手順では、RSA SSHキー・ペアを作成する方法を示します。

LinuxのSSHキー・ペアの作成

UNIXスタイルのシステムを使用している場合は、ssh-keygenユーティリティがすでにインストールされている可能性があります。 ユーティリティがインストールされているかどうかを確認するには、コマンドラインでssh-keygenと入力します。 ユーティリティがインストールされていない場合は、http://www.openssh.com/portable.htmlからUNIXのOpenSSHをダウンロードしてインストールできます。

  1. コマンドを入力するためのシェルまたはターミナルを開きます。
  2. プロンプトで、ssh-keygenと入力し、プロンプトが表示されたらキーの名前を指定します。 オプションで、パスフレーズを含めます。

    キーはデフォルト値で作成されます: 2048ビットのRSAキー。

    または、次の例のように完全なssh-keygenコマンドを入力することもできます:
    ssh-keygen -t rsa -N "" -b 2048 -C "<key_name>" -f <path/root_name>
    引数 説明

    -t rsa

    RSAアルゴリズムを使用します。

    -N "<passphrase>"

    キーの使用を保護するパスフレーズ(パスワードなど)。 パスフレーズを設定しない場合、引用符の間に何も入力しないでください。

    パスフレーズは必須ではありません。 秘密キーを不正使用から保護するためのセキュリティ対策として指定できます。 パスフレーズを指定する場合、インスタンスに接続するときにパスフレーズを指定する必要があります。これにより、通常はインスタンスへの接続の自動化が難しくなります。

    -b 2048

    2048ビットのキーを生成します。 2048がデフォルトであるため、2048が許容可能な場合は、これを設定する必要はありません。

    SSH-2 RSAには最小2048ビットが推奨されています。

    -C "<key_name>"

    キーを識別する名前。

    -f <path/root_name>

    キー・ペアが保存されるロケーションとファイルのルート名。

親トピック: SSHキー・ペアの作成

PuTTYを使用してWindows用のSSHキー・ペアを作成

Windowsクライアントを使用してインスタンス・コンソール接続に接続している場合は、PuTTYによって生成されたSSHキー・ペアを使用します。

ノート:

PuTTYの最新バージョンを使用していることを確認します。http://www.putty.orgを参照してください。

  1. コンピュータ上のPuTTYフォルダ内にあるputtygen.exeを探します(たとえば、C:\Program Files (x86)\PuTTY)。 puttygen.exeをダブルクリックして開きます。
  2. SSH-2 RSAのキー・タイプと2048ビットのキー・サイズを指定します:
    • 「キー」メニューで、デフォルト値の「SSH-2RSAキー」が選択されていることを確認します。
    • 「生成するキーのタイプ」では、デフォルトのキー・タイプRSAを受け入れます。
    • まだ設定されていない場合は、「生成されたキーのビット数」を2048に設定します。
  3. 「生成」をクリックします。
  4. キーにランダム・データを生成するには、PuTTYウィンドウの空白領域をマウスで移動します。

    キーが生成されると、「OpenSSH authorized_keysファイルに貼り付けるための公開キー」の下に表示されます。

  5. 日付やタイムスタンプなど、「キー・コメント」が生成されます。 デフォルトのコメントを保持することも、よりわかりやすい独自のコメントに置き換えることもできます。
  6. 「キーのパスフレーズ」フィールドを空白のままにします。
  7. 「秘密キーを保存」をクリックし、パスフレーズなしでキーを保存するためのプロンプトでYesをクリックします。

    キー・ペアはPuTTY秘密キー(PPK)形式で保存されます。これは、PuTTYツール・セットでのみ動作する独自の形式です。

    キーには任意の名前を付けることができますが、ppkファイル拡張子を使用します。 たとえば、mykey.ppkです。

  8. 公開キーの下に表示される、OpenSSH authorized_keysファイルに貼り付けるために生成されたすべてのキーを選択し、Ctrl + Cを使用してコピーし、テキスト・ファイルに貼り付けてから、秘密キーと同じロケーションにファイルを保存します。

    ノート:

    「公開キーの保存」は、キーをOpenSSH形式で保存しないため、使用しないでください。

    キーには任意の名前を付けることができますが、一貫性を保つために、秘密キーと同じ名前とpubのファイル拡張子を使用します。 たとえば: mykey.pub。

  9. 公開キー・ファイルと秘密キー・ファイルの名前とロケーションを書き留めます。 インスタンス・コンソール接続を作成する場合は、公開キーが必要です。 PuTTYを使用してインスタンス・コンソール接続に接続するには、秘密キーが必要です。 たとえば: $HOME\Documents\mykey.ppk。
PuTTYを使用して生成されたSSHキー・ペアを使用して接続を作成するには

SSHキー・ペアの生成の詳細は、「PuTTYを使用してWindows用のSSHキー・ペアを作成」を参照してください

「シリアル・コンソール・アクセスの作成」ウィンドウで次を実行します:

  1. OpenSSH形式から生成されたSSHキーを貼り付けるか、「SSHキー・ファイルのアップロード」を選択して、「PuTTYを使用してWindows用のSSHキー・ペアを作成」のステップ8で保存された公開キーのパスを指定します。
  2. 接続が「アクティブ」になったら、「Windowsのシリアル・コンソール接続のコピー」をクリックします。
  3. 前のステップでコピーした接続文字列をテキスト・ファイルに貼り付けます。
  4. テキスト・ファイルで、<PATH_FILE_PUTTY_PRIVATE.ppk>を、コンピュータ上のPuTTY秘密キー(PPK)ファイル・パスを指すように置き換えます。 たとえば、.ppkファイルを$HOME\Documents\mykey.ppkに保存した場合です。
  5. 変更した接続文字列をPowerShellウィンドウに貼り付け、Enterを押してコンソールに接続します。
シリアル・コンソールからの仮想マシンへのサインイン

仮想マシン・コンソール接続を使用して仮想マシンにサインインする場合は、Secure Shell (SSH)接続を使用してサインインできます。 ユーザー名とパスワードでサインインする場合は、パスワードを持つユーザー・アカウントが必要です。 Oracle Exadata Cloudでは、opcまたはrootユーザーのデフォルト・パスワードは設定されません。 したがって、opcまたはrootユーザーとしてサインインする場合は、opcまたはrootユーザーのパスワードを作成する必要があります。 それ以外の場合は、パスワードを使用して別のユーザーを追加し、そのユーザーとしてサインインします。 これは、シリアル・コンソールへのログインが必要になる可能性のある状況になる前に、事前に完了するようにしてください。

親トピック: 前提条件

ファイアウォールを介した接続

シリアル・コンソールへのアクセスに使用するクライアントがファイアウォールの背後にある場合は、仮想マシンのシリアル・コンソールにアクセスするために、このクライアントが必要なエンドポイントにアクセスできることを確認する必要があります。 シリアル・コンソールに接続するクライアント・システムは、ポート443を使用して直接またはプロキシを介してSSH経由でシリアル・コンソール・サーバー(vm-console.exacc.us-ashburn-1.oci.oraclecloud.comなど)にアクセスできる必要があります。

親トピック: 前提条件

仮想マシン・シリアル・コンソール接続の作成

シリアル・コンソールへのローカル接続を行う前に、仮想マシン・コンソール接続を作成する必要があります。

ノート:

仮想マシン・コンソール接続は、一度に1つのクライアントに制限されます。 クライアントに障害が発生した場合、接続は約5分間アクティブのままになります。 この間、他のクライアントは接続できません。 5分後、接続が閉じられ、新しいクライアントが接続できるようになります。 5分間のタイムアウト中に、新しいクライアントへの接続を試みると失敗し、次のメッセージが表示されます: 

channel 0: open failed: administratively prohibited: console access is limited to one connection at a time
  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 関心のあるVMクラスタをクリックします。
  3. 表示された「VMクラスタ詳細」ページで、目的の仮想マシンの名前をクリックします。

    「リソース」では、デフォルトで「コンソール接続」が選択されています。

  4. 「シリアル・コンソール・アクセスの作成」をクリックします。
  5. 結果の「シリアル・コンソール・アクセスの作成」ウィンドウには、SSHキーを追加するための3つのオプションがあります
    • キー・ペアを生成: 使用するSSHキー・ペアをOracle Cloud Infrastructureで生成できます。 PowerShellまたはPuTTYを使用してWindowsクライアントからインスタンスに接続している場合、生成されたSSHキー・ペアを最初に.ppkファイルに変換しないと使用できません。
    • 公開キー・ファイルのアップロード: コンピュータ上の公開キー・ファイルを参照します。 前提条件セクションの「SSHキー・ペアの作成」のステップに従ってキー・ペアを作成した場合は、このオプションを使用して.pubファイルにナビゲートします。
    • 公開キーの貼付け: 公開キー・ファイルのコンテンツをテキスト・ボックスに貼り付けます。
  6. 「コンソール接続の作成」をクリックします。

    コンソール接続が作成され、使用可能になると、状態は「アクティブ」に変わります。

関連トピック

親トピック: コンソール接続を使用した仮想マシンのトラブルシューティング

シリアル・コンソールへのSSH接続の作成

仮想マシンのコンソール接続を作成したら、Secure Shell (SSH)接続を使用してシリアル・コンソールに接続できます。 シリアル・コンソールへのSSH接続を行う場合は、RSAキーを使用する必要があります。 インスタンスの起動時に使用したシリアル・コンソールに同じSSHキーを使用することも、別のSSHキーを使用することもできます。

シリアル・コンソールの使用が終了し、SSH接続を終了したら、シリアル・コンソール接続を削除する必要があります。 セッションから切断しない場合、Oracle Cloud Infrastructureは24時間後にシリアル・コンソール・セッションを終了するため、再認証して再度接続する必要があります。

親トピック: コンソール接続を使用した仮想マシンのトラブルシューティング

サーバー・ホスト・キーの検証

シリアル・コンソールに初めて接続すると、サーバー・ホスト・キーのフィンガープリントを検証するように求められます。 サーバー・ホスト・キーのフィンガープリントは、サーバー・ホストの公開SSHキーのSHA256ハッシュです。 サーバーSSHハンドシェイク・レスポンスは、関連付けられた秘密キーで署名されます。 サーバー・ホスト・キーのフィンガープリントを検証すると、潜在的な攻撃から保護されます。

シリアル・コンソールに手動で接続する場合、サーバー・ホスト・キーのフィンガープリントは自動的に検証されません。 フィンガープリントを手動で検証するには、Oracle Cloud Infrastructureコンソールに表示されるフィンガープリント値を、接続時に端末に表示されるRSAキー・フィンガープリントの値と比較します。

コンソールでサーバー・ホスト・キーのフィンガープリントを検索するには、「仮想マシン」の詳細ページで、「リソース」の下にある「コンソール接続」をクリックします。 このテーブルには、サーバー・ホスト・キーの指紋が表示されます。 コンソールのフィンガープリントは、シリアル・コンソールへの接続時に端末に表示される「RSAキー・フィンガープリント」の値と一致する必要があります。

サーバー・ホスト・キーは、セキュリティ目的で定期的にローテーションされます。 キー・ローテーションを行うと、1つのキー・バージョンによって暗号化または署名されるデータの量を制限することで、キーが危殆化したときに引き起こされるリスクを軽減します。 キーが回転したときに、シリアル・コンソールに接続しようとすると、攻撃の可能性を示す警告が表示されます。 警告には、Host key verification failedエラーと.ssh/known_hostsファイルの行番号が含まれます。 .ssh/known_hostsファイルのその行を削除してから、シリアル・コンソールに再接続します。 その後、新しいサーバー・ホスト・キー・フィンガープリントを受け入れるように求められます。

Mac OS XおよびLinuxオペレーティング・システムからの接続

SSHクライアントを使用したシリアル・コンソールへの接続。 Mac OS XとほとんどのLinuxやUNIX系のオペレーティング・システムには、デフォルトでSSHクライアントOpenSSHが含まれています。

Mac OS XまたはLinuxでOpenSSHを使用してシリアル・コンソールに接続するには

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 関心のあるVMクラスタをクリックします。
  3. 表示された「VMクラスタ詳細」ページで、目的の仮想マシンの名前をクリックします。
  4. Oracle Cloud Infrastructureコンソールの仮想マシンの詳細ページで、「リソース」の下の「コンソール接続」をクリックします。
  5. アクション・メニュー(3つのドット)をクリックし、「Linux/Macのシリアル・コンソール接続のコピー」をクリックします。
  6. Mac OS XまたはLinuxシステムの端末ウィンドウに接続文字列を貼り付け、Enterキーを押してコンソールに接続します。

    デフォルトのSSHキーまたはSSH-agentを使用していない場合は、アイデンティティ・ファイル・フラグを含むようにシリアル・コンソール接続文字列-iを変更し、使用するSSHキーの秘密キー部分を指定します(例: id_rsa)。 次の行に示すように、SSH接続とSSH ProxyCommandの両方にこのフラグを指定します: 

    ssh -i /<path>/<ssh_key> -o ProxyCommand='ssh -i /<path>/<ssh_key> -W %h:%p -p 443...
  7. プロンプトが表示された場合は、サーバー・ホスト・キーのフィンガープリントを検証して受け入れます。

    以前にサーバー・ホスト・キーのフィンガープリントを受け入れたが、キーがローテーションされている場合は、攻撃の可能性があることを示す警告が表示されます。 警告には、Host key verification failedエラーと.ssh/known_hostsファイルの行番号が含まれます。 .ssh/known_hostsファイルで指定した行を削除してから、シリアル・コンソールに再接続します。 新しいサーバー・ホスト・キー指紋を検証して承認します。

  8. もう一度Enterを押して、コンソールをアクティブ化します。

    接続がアクティブな場合、コンソールにメッセージが表示されます: 

    =================================================
IMPORTANT: You are now connected to the serial console for this VM. This should be used in emergency situations only.

See product documentation for more details and alternative connectivity options for normal operations
=================================================
  9. 仮想マシンを再起動します。

    ユーザー名またはパスワードを入力する必要はありません。 仮想マシンが機能していて、接続がアクティブな場合、シリアル出力がコンソールに表示されます。 シリアル出力がコンソールに表示されない場合、ゲストVMオペレーティング・システムはブートしません。

    トラブルシューティング・オプションの詳細は、「Linuxオペレーティング・システムでのゲストVMコンソール接続からの仮想マシンのトラブルシューティング」を参照してください。

    1. ExaDB-C@C 「VMクラスタ詳細」ページに移動します。
    2. 「リソース」の下で、「仮想マシン」をクリックします。
    3. リブートする仮想マシンのアクション・メニュー(3つのドット)から「再起動」を選択します。
Windowsオペレーティング・システムからの接続

Microsoft Windows PowerShellからシリアル・コンソールに接続するステップは、OpenSSHのステップとは異なります。 次のステップは、Windows端末では機能しません。

ノート:

PowerShellを使用してWindowsクライアントからインスタンスに接続する場合は、plink.exeが必要です。plink.exeは、PuTTYに含まれているコマンド・リンク接続ツールです。 PuTTYをインストールするか、plink.exeを個別にインストールできます。 詳細は、「SSHクライアントとコマンド行シェルのインストール(Windows)」を参照してください。

Microsoft Windowsのシリアル・コンソールに接続するには

  1. Oracle Cloud Infrastructureコンソールの「仮想マシンの詳細」ページで、「リソース」の下の「コンソール接続」をクリックします。
  2. Actions (処理)メニュー(3つのドット)をクリックします。

    使用しているSSHクライアントに応じて、次のいずれかを行います:

    • Windows PowerShellを使用している場合は、「Windowsのシリアル・コンソール接続のコピー」をクリックします。
    • OpenSSHを使用している場合は、「Linux/Macのシリアル・コンソール接続のコピー」をクリックします。

    ノート:

    Windowsのコピーされた接続文字列には、秘密キー・ファイルのロケーションを指定するパラメータ-iが含まれます。 接続文字列のこのパラメータのデフォルト値は、Windowsクライアントで構成されていないか、秘密キー・ファイルが保存されているロケーションを表していない可能性のある環境変数を参照しています。 次のステップに進む前に、-iパラメータに指定された値を確認し、必要な変更を行ってください。

  3. 前のステップでコピーした接続文字列をテキスト・ファイルに貼り付けて、秘密キー・ファイルにファイル・パスを追加できるようにします。
  4. テキスト・ファイルで、$env:homedrive$env:homepath\oci\console.ppkをコンピュータ上の.ppkファイルへのファイル・パスに置き換えます。 このファイル・パスは文字列に2回表示されます。 両方のロケーションで置き換えます。
  5. 変更した接続文字列をPowerShellウィンドウまたはOpenSSHクライアントに貼り付け、Enterを押してコンソールに接続します。
  6. プロンプトが表示された場合は、サーバー・ホスト・キーのフィンガープリントを検証して受け入れます。
    サーバー・ホスト・キーの指紋を以前に受け入れたが、そのキーがローテーションされている場合は、攻撃の可能性を示す警告が表示されます。 警告には、ホスト・キー検証失敗エラーと.ssh/known_hostsファイルの行番号が含まれます。 .ssh/known_hostsファイルで指定した行を削除してから、シリアル・コンソールに再接続します。 新しいサーバー・ホスト・キー指紋を検証して承認します。
  7. もう一度Enterを押して、コンソールをアクティブ化します。
  8. 仮想マシンを再起動します。

    ユーザー名またはパスワードを入力する必要はありません。 仮想マシンが機能していて、接続がアクティブな場合、シリアル出力がコンソールに表示されます。 シリアル出力がコンソールに表示されない場合、ゲストVMオペレーティング・システムはブートしません。

    トラブルシューティング・オプションの詳細は、「ゲストVMコンソール接続からの仮想マシンのトラブルシューティング」を参照してください。

    1. ExaDB-C@C 「VMクラスタ詳細」ページに移動します。
    2. 「リソース」の下で、「仮想マシン」をクリックします。
    3. リブートする仮想マシンのアクション・メニュー(3つのドット)から「再起動」を選択します。
OCIコンソールを使用して生成されたSSHキー・ペアを使用して接続を作成するには

「シリアル・コンソール・アクセスの作成」ウィンドウで次を実行します:
  1. 「キー・ペアを生成」をクリックします。
  2. 「秘密キーの保存」をクリックします。
  3. 「コンソール接続の作成」をクリックします。

    ノート:

    PuTTYの最新バージョンを使用していることを確認します。http://www.putty.orgを参照してください。

  4. コンピュータのPuTTYフォルダ(たとえば、C:\Program Files (x86)\PuTTY. Double-click puttygen.exe)でputtygen.exeを検索して開きます。
  5. PuTTYキー・ジェネレータで、「変換」メニューをクリックし、「インポート」をクリックします。
  6. Windows Explorerで、OCIコンソールで生成されたSSHキー(ステップ1)を選択し、「オープン」をクリックします。

    PuTTYはキーをインポートし、PuTTYキー・ジェネレータ・ウィンドウにキーに関する情報を表示します。

  7. 「秘密キーを保存」をクリックします。
  8. パスフレーズなしでキーを保存するように求められたら、Yesをクリックします。

    キー・ペアは、PuTTYツール・セットでのみ機能する独自の形式であるPuTTY秘密キー(PPK)形式で保存されます。

    キーには任意の名前を付けることができますが、.ppkファイル拡張子を使用します。 たとえば、$HOME\Desktop\key-vm-console.ppkです。

  9. テキスト・エディタを使用して、PuTTY秘密キー(PPK)パスを指すようにコマンドを変更します。 <PATH_FILE_PUTTY_PRIVATE.ppk>を、コンピュータ上のPuTTY秘密キー(PPK)ファイル・パスを指すように置き換えます。 たとえば、.ppkファイルを$HOME\Desktop\key-vm-console.ppkに保存した場合です。
  10. 変更した接続文字列をPowerShellウィンドウに貼り付け、Enterを押してコンソールに接続します。
生成された.key秘密キー・ファイルを変換するには

  1. PuTTYgenを開きます。
  2. 「ロード」をクリックし、インスタンスの作成時に生成された秘密キーを選択します。
    キー・ファイルの拡張子は、.keyです。
  3. 「秘密キーを保存」をクリックします。
  4. キーの名前を指定します。
    新しい秘密キーの拡張子は、.ppkです。
  5. 「保存」をクリックします。

クラウド・シェルを使用したシリアル・コンソールへの接続

Cloud Shell統合を使用して、シリアル・コンソールに迅速かつ簡単に接続できます。 クラウド・シェルは、コンソールからアクセスできるwebブラウザベースの端末です。 Cloud Shell統合により、インスタンス・コンソール接続と一時SSHキーが自動的に作成されます。 Cloud Shellからシリアル・コンソールに接続するための唯一の前提条件は、ユーザーに正しい権限を付与することです。 Cloud Shellの使用の概要については、「クラウド・シェルの使用方法」を参照してください。

ノート:

  • デフォルトでは、クラウド・シェルは、「Cloud Shell管理対象パブリック・ネットワーク」を有効にしていないかぎり、テナンシ・ホーム・リージョン内のOCI内部リソースへのネットワーク・アクセスを制限します。 管理者は、Cloud Shellパブリック・ネットワークを有効にするようにアイデンティティ・ポリシーを構成する必要があります。 詳細は、「クラウド・シェル・ネットワーキング」を参照してください。
  • クラウド・シェルを使用して複数のDBノードに同時に接続することはできません。 たとえば、DBnode1へのオープン接続があり、DBnode2に接続する場合は、まずアクティブなクラウド・シェルをDBnode1から終了してから、DBnode2への接続を確立する必要があります。
  • コントロール・プレーン・サーバー(CPS)が必要なOCIエンドポイントに到達できるように、ファイアウォール・ルールが正しいことを確認してください。 詳細については、表3-2を参照してください

シリアル・コンソールの使用が終了し、SSH接続を終了したら、シリアル・コンソール接続を削除する必要があります。 セッションから切断しない場合、Oracle Cloud Infrastructureはシリアル・コンソール・セッションを24時間後に終了するため、再認証して接続する必要があります。

関連トピック

親トピック: コンソール接続を使用した仮想マシンのトラブルシューティング

Cloud Shellを使用してシリアル・コンソールに接続するには

  1. コンソールにサインインします。
  2. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  3. Oracle Cloud Infrastructureコンソールのインスタンスの詳細ページで、「リソース」の下の「コンソール接続」をクリックします。
  4. 「Cloud Shell接続の起動」をクリックします。

    このアクションは、コンソールの下部にあるドロワーにクラウド・シェルを表示します。

  5. コンソール接続がすでに存在する場合は、既存のリソースを削除するかどうかを尋ねられます。 yを押してから、Enterを押します。
  6. 終了したら、インスタンス・コンソール接続を終了します。

仮想マシンのコンソール履歴の表示

ノート:

シリアル・コンソールにアクセスし、コンソール履歴を使用するには、コントロール・プレーン・サーバー(CPS)が必要なOCIエンドポイントにアクセスできるようにファイアウォール・ルールを構成する必要があります。 オブジェクト・ストレージおよびVMコンソールの接続要件については、「表3-2」の詳細を確認してください。

仮想マシンの最近のシリアル・コンソール・データを取得して表示できます。 データには、仮想マシンのブート時に発生する構成メッセージ(カーネルやBIOSメッセージなど)が含まれており、仮想マシンのステータスの確認や問題の診断やトラブルシューティングに役立ちます。

コンソール履歴は、指定された仮想マシンの最新のシリアル・コンソール・データを最大1メガバイト取得します。 RAWコンソール・データ(マルチバイト文字を含む)が取得されます。

コンソール履歴は、ポイント・イン・タイム・レコードです。 対話型コンソール接続を使用して、故障した仮想マシンをトラブルシューティングするには、シリアル・コンソール接続を使用します。

親トピック: コンソール接続を使用した仮想マシンのトラブルシューティング

コンソール履歴データの管理

コンソールまたはAPIを使用して、コンソール履歴取得を管理できます。 コンソール履歴を使用すると、インスタンスにリモートで接続しなくても、仮想マシンからのシリアル出力を表示できます。 コンソール履歴を使用して、シリアル・コンソールで実行された以前のアクセスおよびアクションを監査できます。

コンソールのインスタンスの詳細ページで、コンソール履歴の取得とダウンロード、メタデータの詳細の表示と編集、およびコンソール履歴取得の削除を行うことができます。

コンソールを使用したコンソール履歴の取得

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 目的の「VMクラスタ」をクリックします。
  3. 表示された「VMクラスタ詳細」ページで、目的の仮想マシンの名前をクリックします。
    「リソース」では、デフォルトで「コンソール接続」が選択されています。
  4. 「コンソール履歴」をクリックします。
  5. 目的の履歴の名前をクリックします。
  6. 表示されたウィンドウで、「ダウンロード」をクリックしてコンソール履歴のコピーをダウンロードします。
  7. 「保存して閉じる」をクリックして履歴を保存し、ウィンドウを閉じます。
コンソールを使用したコンソール履歴取得のダウンロード

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 目的の「VMクラスタ」をクリックします。
  3. 表示された「VMクラスタ詳細」ページで、目的の仮想マシンの名前をクリックします。
    「リソース」では、デフォルトで「コンソール接続」が選択されています。
  4. 「コンソール履歴」をクリックします。
  5. 目的の履歴の名前をクリックします。
  6. 表示されたウィンドウで、「ダウンロード」をクリックしてコンソール履歴のコピーをダウンロードします。
コンソールを使用したコンソール履歴取得の表示

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 目的の「VMクラスタ」をクリックします。
  3. 表示された「VMクラスタ詳細」ページで、目的の仮想マシンの名前をクリックします。
    「リソース」では、デフォルトで「コンソール接続」が選択されています。
  4. 「コンソール履歴」をクリックします。
  5. 目的の履歴の名前をクリックします。
  6. コンソール履歴リストで、表示するコンソール履歴の取得について、「アクション」メニューをクリックし、「詳細の表示」をクリックします。
コンソールを使用したコンソール履歴取得のメタデータ詳細の表示および編集

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 目的の「VMクラスタ」をクリックします。
  3. 表示された「VMクラスタ詳細」ページで、目的の仮想マシンの名前をクリックします。
    「リソース」では、デフォルトで「コンソール接続」が選択されています。
  4. 「コンソール履歴」をクリックします。
  5. コンソール履歴リストで、表示するコンソール履歴の取得について、「アクション」メニューをクリックし、「詳細の表示」をクリックします。
  6. オプションで、コンソール履歴の名前を編集します。 機密情報の入力は避けてください。
  7. タグを表示または編集するには、「タグ付けオプションの表示」をクリックします。
  8. タグを編集または削除するには、タグの横にある編集アイコンをクリックします。 タグを編集するには、「タグの編集」ダイアログで変更を行い、「保存」をクリックします。 タグを削除するには、「タグの削除」をクリックします。
  9. 「保存してクローズ」をクリックします。
コンソールを使用したコンソール履歴取得の削除

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 目的の「VMクラスタ」をクリックします。
  3. 表示された「VMクラスタ詳細」ページで、目的の仮想マシンの名前をクリックします。
    「リソース」では、デフォルトで「コンソール接続」が選択されています。
  4. 「コンソール履歴」をクリックします。
  5. コンソール履歴リストで、表示するコンソール履歴の取得について、「アクション」メニューをクリックし、「削除」をクリックします。
  6. 確認ダイアログで、「コンソール履歴の削除」をクリックします。
APIを使用したコンソール履歴データの管理

APIコールのリストを確認して、コンソール履歴データを管理します。

APIの使用およびリクエストの署名の詳細は、REST APIおよび「セキュリティ資格証明」を参照してください。 SDKの詳細は、「ソフトウェア開発キットとコマンドライン・インタフェース」を参照してください。

APIの完全なリストは、データベース・サービスAPIを参照してください。

コンソール履歴データを管理するには、次のAPI操作を使用します。

  • コンソール履歴を取得するには、createDbNodeConsoleHistoryメソッドを使用します。
  • コンソール履歴メタデータの詳細を取得するには、getDbNodeConsoleHistoryメソッドを使用します。
  • コンソール履歴コンテンツの詳細を取得するには、getDbNodeConsoleHistoryContentメソッドを使用します。
  • コンソール履歴メタデータを編集するには、updateDbNodeConsoleHistoryメソッドを使用します。
  • コンソール履歴取得をリストするには、listDbNodeConsoleHistoriesメソッドを使用します。
  • コンソール履歴取得を削除するには、deleteDbNodeConsoleHistoryメソッドを使用します。

Linuxオペレーティング・システムでのゲストVMコンソール接続からの仮想マシンのトラブルシューティング

インスタンス・コンソール接続を使用して接続した後で、次のような様々なタスクを実行できます:

  • システム構成ファイルを編集します。
  • opcユーザーのSSHキーを追加またはリセットします。
  • opcユーザーのパスワードをリセットします。

これらのタスクでは、メンテナンス・モードでBashシェルに起動する必要があります。

親トピック: コンソール接続を使用した仮想マシンのトラブルシューティング

メンテナンス・モードで起動するには

ノート:

デフォルトのユーザーおよびパスワード:
  • アカウント: Grubブート・ローダー
  • ユーザー名: root
  • デフォルト・パスワード: sos1Exadata
  • アカウント・タイプ: オペレーティング・システムのユーザー

詳細は、「Oracle Exadataのデフォルト・ユーザー・アカウント」を参照してください。

  1. VMクラスタからVMを再起動します。
  2. Oracle Linux 7.xまたはOracle Linux 8.xを実行している仮想マシンの場合、再起動プロセスの開始時に、端末ウィンドウに切り替えると、コンソール・メッセージがウィンドウに表示されます。 「GRUBブート・メニュー」が表示されたらすぐに、up/down 「矢印キー」を使用して自動ブート・プロセスを停止し、ブート・メニューを使用できます。
  3. ブート・メニューで、メニューの最上位のアイテムを強調表示し、eを押してブート・エントリを編集します。
  4. 編集モードでは、「下矢印キー」を使用してエントリを下にスクロールし、linux16で始まる行まで移動します。
  5. その行末に次を追加します:
    init=/bin/bash
  6. キーボード・ショートカットCTRL+Xを入力して、ターミナル・ウィンドウからインスタンスを再起動します。

    インスタンスが再起動されると、Bashシェルのコマンドライン・プロンプトが表示され、次の手順を実行します。

システム構成ファイルを編集するには

  1. Bashシェルで、次のコマンドを実行して、変更するファイルのコンテキストを保持するSElinuxポリシーをロードします:
    /usr/sbin/load_policy -i
  2. 次のコマンドを実行し、読取り/書込み権限でルート・パーティションを再マウントします:
    /bin/mount -o remount, rw /
  3. 必要に応じて構成ファイルを編集して、インスタンスのリカバリを試行します。
  4. 構成ファイルの編集が終了したら、既存のシェルからインスタンスを起動するため、次のコマンドを実行します:
    exec /usr/lib/systemd/systemd
    または、インスタンスを再起動するには、次のコマンドを実行します:
    /usr/sbin/reboot -f
opcユーザーのSSHキーを追加またはリセットするには

  1. Bashシェルで、次のコマンドを実行して、変更するファイルのコンテキストを保持するSElinuxポリシーをロードします:
    /usr/sbin/load_policy -i
  2. 次のコマンドを実行し、読取り/書込み権限でルート・パーティションを再マウントします:
    /bin/mount -o remount, rw /
  3. Bashシェルから次のコマンドを実行して、opcユーザーのSSHキー・ディレクトリに変更します:
    cd ~opc/.ssh
  4. authorized_keysファイルに公開キー・エントリを含めます。

    ノート:

    必要に応じて、ファイルを編集して前のキーを削除できます。 ただし、クラウドの自動化が壊れるのを防ぐために、クラウド自動化キーを必ず保持してください。 
    echo '<contents of public key file>' >> authorized_keys
  5. インスタンスを再起動するには、次のコマンドを実行します:
    /usr/sbin/reboot -f
opcユーザーのパスワードをリセットするには

  1. Bashシェルから次のコマンドを実行して、変更するファイルのコンテキストを保持するSElinuxポリシーをロードします。

    このステップでは、SSHおよびコンソールを使用してインスタンスにサインインする必要があります。

    /usr/sbin/load_policy -i
  2. 次のコマンドを実行し、読取り/書込み権限でルート・パーティションを再マウントします:
    /bin/mount -o remount, rw /
  3. 次のコマンドを実行して、opcユーザーのパスワードをリセットします:
    sudo passwd opc
  4. インスタンスを再起動するには、次のコマンドを実行します:
    sudo reboot -f

    ノート:

    opcパスワードを設定するかわりに、rootパスワードを設定することも可能です。

仮想マシン・シリアル・コンソール接続の終了

親トピック: コンソール接続を使用した仮想マシンのトラブルシューティング

シリアル・コンソール接続を終了するには

SSHを使用する場合、新しい行の先頭にある~文字がエスケープ文字として使用されます。

  1. シリアル・コンソールを終了するには、次のように入力します:
    ~.
  2. SSHセッションを一時停止するには、次のように入力します:
    ~^z

    ^文字は、CTRLキーを表します。

  3. すべてのSSHエスケープ・コマンドを表示するには、次のように入力します:
    ~?
仮想マシンのシリアル・コンソール接続を削除するには

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. 関心のあるVMクラスタをクリックします。
  3. 表示された「VMクラスタ詳細」ページで、目的の仮想マシンの名前をクリックします。

    「リソース」では、デフォルトで「コンソール接続」が選択されています。

  4. アクション・メニューをクリックし、「削除」をクリックします。 要求されたら、確認します。