5 Oracle VMユーザー・ドメインの管理
Oracle VMは、InfiniBandネットワーク・ファブリックを使用するOracle Exadata Database Machineシステム全体で使用されるXenベースの仮想化テクノロジです。
- Oracle VMおよびExadata Database Machine
Exadata Database Machineをデプロイするときに、データベース・サーバーにOracle VMを実装できます。 - ベア・メタルOracle RACクラスタからOracle VMのOracle RACクラスタへの移行
- 実行中のドメインの表示
- ユーザー・ドメイン・コンソールの監視
- Oracle Enterprise Managerを使用したOracle VMの監視
Oracle Enterprise ManagerのExadataプラグインは、Oracle Enterprise Managerの仮想インフラストラクチャ・プラグインと組み合せて、仮想化されたOracle Exadata Database Machineを検出、管理および監視します。 - ユーザー・ドメインの開始
- Oracle VMユーザー・ドメインの自動起動の管理
デフォルトでは、ユーザー・ドメインは、作成するとき、管理ドメインが起動するときに自動的に起動するように構成されます。この機能は必要に応じて有効/無効を切り替えることができます。 - ユーザー・ドメイン内部のユーザー・ドメインのシャットダウン
- 管理ドメイン内部のユーザー・ドメインのシャットダウン
- Oracle VMユーザー・ドメインでのOracle Databasesのバックアップおよびリストア
Oracle VMユーザー・ドメインでのOracleデータベースのバックアップとリストアは、物理ノードでのOracleデータベースのバックアップとリストアと同じです。 - ユーザー・ドメインに割り当てられたメモリーの変更
- ユーザー・ドメインに割り当てられた仮想CPU数の変更
- ユーザー・ドメインのディスク領域の増加
ユーザー・ドメインのLogical Volume Manager (LVM)のパーティション、スワップ領域およびファイル・システムのサイズは拡大できます。 - データベース・サーバーのディスク拡張キット追加後の/EXAVMIMAGESの拡張
データベース・サーバーにディスク拡張キットを追加するときには、適切な手順に従って、新しい領域を/EXAVMIMAGES
ファイル・システムに追加することが重要です。 - Oracle VMクラスタの追加
Oracle Exadata Deployment Assistant (OEDA)を使用して、既存のExadata Database Machineに新しいOracle VMクラスタを作成できます。 - OEDACLIを使用したOracle VMでのOracle RACクラスタの拡張
Oracle VMに既存のOracle RACクラスタは、Oracle Exadata Deployment Assistantコマンドライン・インタフェース(OEDACLI)を使用してユーザー・ドメインを追加することで拡張できます。 - Oracle Grid InfrastructureおよびOracle Databaseの存在しないユーザー・ドメインの作成
- ユーザー・ドメインの別のデータベース・サーバーへの移動
ユーザー・ドメインは、別のデータベース・サーバーに移動できます。 - Oracle VMデプロイメントの管理ドメインとユーザー・ドメインのバックアップ
- Oracle VMデプロイメントのリカバリ
重大な障害が発生してOracle VMが損傷した場合や、サーバー・ハードウェアを新しいハードウェアに交換した場合は、スナップショット・ベースのバックアップからOracle VMをリカバリできます。 - Oracle VMで実行するOracle RACクラスタの削除
クラスタ内で実行中のデータベースとそのデータベースが使用しているOracle Exadata Storage Serverに保存されたすべてのデータを含めて、Oracle VMクラスタのすべてのOracle RACノードを削除できます。 - ユーザー・ドメインの削除
Oracle VMのユーザー・ドメインは、OEDACLIまたはdomu_maker
ユーティリティを使用して削除できます。 - タグ付けされたVLANインタフェースの実装
このトピックでは、Exadata上のOracle VM環境内のタグ付けされたVLANインタフェースの実装について説明します。 - Exadata Database MachineでのOracle VM Oracle RACクラスタ間のInfiniBandパーティションの実装
Exadata Database MachineのOracle VMで実行しているOracle Real Application Clusters (Oracle RAC)クラスタの場合、カスタムのInfiniBandパーティション、専用のパーティション・キーおよびパーティション化表を使用することで、Oracle RACクラスタごとにInfiniBandネットワークのネットワーク・トラフィックを分離できます。 - Oracle VM環境でのOracle EXAchkの実行
Oracle EXAchkバージョン12.1.0.2.2以降では、Exadata Database Machineでの仮想化がサポートされています。
5.1 Oracle VMおよびExadata Database Machine
Exadata Database Machineをデプロイする場合は、データベース・サーバーにOracle VMを実装できます。
Oracle VM Serverおよび1つ以上のOracle VMゲストが、すべてのデータベース・サーバーにインストールされます。Oracle Exadata Deployment Assistant (OEDA)で作成されたスクリプトを使用して初期デプロイメントでOracle VM環境を構成するか、既存の環境をOracle VMに移行できます。
ノート:
Oracle VMは、X7-8などの8ソケット・サーバーではサポートされていません。- Oracle VMについて
Oracle VMを使用すると、サポートされている仮想化環境内にOracle Linuxオペレーティング・システムとアプリケーション・ソフトウェアをデプロイできます。 - Oracle VMデプロイメントの仕様と制限
このトピックでは、Oracle VMをOracle Exadata Database Machineで使用するためのデプロイメントの仕様と制限について説明します。 - 管理ドメイン(dom0)でサポートされている操作
手動でdom0を変更すると、Oracle VM Serverの構成上の問題が発生する場合があります。これにより、パフォーマンスが低下したり、サービスが失われる可能性があります。 - Oracle VMリソース
Oracle VMインフラストラクチャの2つの基本部分(ネットワークおよびストレージ)は、Oracle VMの外部で構成されます。
親トピック: Oracle VMユーザー・ドメインの管理
5.1.1 Oracle VMについて
Oracle VMを使用すると、サポートされている仮想化環境内にOracle Linuxオペレーティング・システムとアプリケーション・ソフトウェアをデプロイできます。
Oracle Exadata Database MachineでOracle VMを使用する場合、ワークロードにCPU、メモリー、オペレーティング・システムおよびsysadminの分離を提供します。VMとネットワークおよびI/Oの優先度付けを組み合せて、完全なスタック分離を実現できます。連結の場合、Oracle VMで複数の信頼できるデータベースまたはプラガブル・データベースを作成すると、リソースをより動的に共有できます。
Oracle VM環境は、Oracle VM Server、仮想マシンおよびリソースで構成されます。Oracle VM Serverは、ドメインとも呼ばれる、仮想マシンを実行するための軽量でセキュアなサーバー・プラットフォームを提供する、管理された仮想化環境です。
Oracle VM Serverはベア・メタル・コンピュータにインストールされています。各Oracle VM Serverに存在するハイパーバイザは、フットプリントが非常に小さい仮想マシン・マネージャおよびスケジューラです。システムで唯一完全な権限を持つエンティティとなるように設計されています。CPUとメモリーの使用量、権限の確認、ハードウェア割込みなど、システムの最も基本的なリソースのみを制御します。
ハイパーバイザは、1台のホスト・コンピュータで複数の仮想マシンを安全に実行します。各仮想マシンは独自のドメインで実行され、独自のゲスト・オペレーティング・システムを持ちます。プライマリ管理ドメイン、dom0 (domain zeroの略称)は、ハイパーバイザの上部のゲストとしても実行されます。dom0には、ハードウェアおよびデバイス・ドライバへの特権アクセス権があります。
ユーザー・ドメイン(domU)は、InfiniBand HCAにアクセスできる権限のないドメインです。domUは、Oracle VM Serverでdom0によって起動および管理されます。domUは他のドメインとは独立して動作するため、domUの仮想リソースに適用される構成変更は、他のドメインには影響しません。domUの障害は、他のドメインには影響しません。
ドメイン、ゲストおよび仮想マシンは、ほぼ同じ意味に使用されていますが、若干の違いがあります。
- ドメインは、構成可能な一連のリソースで、メモリー、仮想CPU、仮想マシンを実行するネットワーク・デバイスおよびディスク・デバイスを含みます。
- ドメインまたは仮想マシンには仮想リソースが付与され、他のドメインまたはホスト・サーバー自体とは関係なく起動、停止および再起動できます。
- ゲストは、ドメイン内で実行される仮想化されたオペレーティング・システムです。各ゲスト・オペレーティング・システムには、「ユーザー・ドメイン」と呼ばれるこのシステムの管理ドメインがあり、「domU」と省略されます。
最大8つのゲストは、それぞれ独自のドメイン内で同じOracle VM Serverで実行できます。これらのドメインは、InfiniBandHCAにアクセスできる権限のないドメインです。各domUは、Oracle VM Serverで実行されるdom0とともに起動されます。他のドメインはdom0と直接相互作用しません。これらの要件は、ハイパーバイザ自体によって処理されます。dom0はハイパーバイザを管理する手段のみを提供します。
Oracle Exadata Database MachineでOracle VMを作成および構成するには、Oracle Exadata Deployment Assistant (OEDA)を使用します。
5.1.2 Oracle VMデプロイメントの仕様と制限
このトピックでは、Oracle VMをOracle Exadata Database Machineで使用するためのデプロイメントの仕様と制限について説明します。
表5-1 Oracle VMデプロイメントの仕様と制限
属性 | X3-2の値 | X4-2の値 | X5-2の値 | X6-2の値 | X7-2の値 | X8-2の値 |
---|---|---|---|---|---|---|
各データベース・サーバーのOracle VMユーザー・ドメインの最大数 |
8 |
8 |
8 |
8 |
8 |
8 |
Oracle VMを使用した各データベース・サーバー上の物理メモリーの合計 |
デフォルト: 256GB 最大値: 512GB |
デフォルト: 256GB 最大値: 512GB |
デフォルト: 256GB 最大値: 768GB |
デフォルト: 256GB 最大値: 768GB |
デフォルト: 384GB 最大値: 768GB |
デフォルト: 384GB 最大値: 768GB |
すべてのOracle VMユーザー・ドメインの各データベース・サーバー上の使用可能メモリーの合計 |
最大値: 464GB |
最大値: 464GB |
最大値: 720GB |
最大値: 720GB |
最大値: 720GB |
最大値: 720GB |
各Oracle VMユーザー・ドメインの最小メモリー制限 |
16GB |
16GB |
16GB |
16GB |
16GB |
16GB |
各データベース・サーバーの合計CPUコア(仮想CPU) |
16 (32) |
24 (48) |
32 (64) |
44 (88) |
48 (96) |
48 (96) |
各Oracle VMユーザー・ドメインのCPUコア(仮想CPU)制限 ノート: CPUのオーバープロビジョニングは許可されますが、パフォーマンスの競合が発生する可能性があります。 |
最小値: 2 (4) 最大値: 14 (28) |
最小値: 2 (4) 最大値: 22 (44) |
最小値: 2 (4) 最大値: 30 (60) |
最小値: 2 (4) 最大値: 42 (84) |
最小値: 2 (4) 最大値: 46 (92) |
最小値: 2 (4) 最大値: 46 (92) |
各データベース・サーバーのOracle VMユーザー・ドメインの合計使用可能ディスク領域 |
700GB |
1.6TB |
1.6TB (ストレージ拡張キットを使用すると3.7TB) |
1.6TB (ストレージ拡張キットを使用すると3.7TB) |
1.6TB (ストレージ拡張キットを使用すると3.7TB) |
3.2TB |
ノート:
1つのCPUコア= 1つのOCPU = 2つの仮想CPU = 2つのハイパー・スレッド
5.1.3 管理ドメイン(dom0)でサポートされている操作
dom0を手動で変更すると、Oracle VM Serverの構成上の問題が発生する場合があります。これにより、パフォーマンスが低下したり、サービスが失われる可能性があります。
警告:
Oracleでは、ドキュメント化されている内容以外のdom0への変更はサポートされていません。dom0内のサード・パーティ・ソフトウェアの実行はサポートされていません。dom0での操作がサポートされているかどうか不明な場合は、Oracleサポート・サービスに問い合せてください。
5.1.4 Oracle VMリソース
Oracle VMインフラストラクチャの2つの基本部分(ネットワークおよびストレージ)は、Oracle VMの外部で構成されます。
ネットワーク
Oracle Exadata Deployment Assistant (OEDA)を使用してOracle Exadataラックの構成詳細を指定する場合は、Oracle VM環境に必要なネットワークIPアドレスの作成方法を入力します。生成されたOEDA設定ファイルはOracle Exadataラックに転送され、ネットワーク・アドレスの作成に使用されます。
ストレージ
Oracle VMには、仮想マシンの作成および管理に不可欠な環境リソースを格納する場所が常に必要です。こういったリソースには、ISOファイル(仮想DVDイメージ)、VM構成ファイル、およびVM仮想ディスクがあります。このようなリソースのグループが格納される場所を記憶域リポジトリといいます。
Exadata Database Machineでは、Oracle VMの記憶域はOCFS2 (Oracle Cluster File System)ストレージとして構成されます。
X5-2以降の2ソケットのOracle Exadata Database Machineシステムでのみ、ディスク拡張キットを購入してストレージ容量を増やすことができます。追加のディスク領域を使用し、/EXAVMIMAGES
を拡張して、より多くのOracle VMゲスト(最大8個まで)をサポートしたり、各domUの/u01
パーティションのサイズを増やすことができます。
Exadataでサポートされる最大VM数
既存のExadata Database Serverの場合、サポートされるVMの最大数は8個です。ソフトウェアの前提条件については、My Oracle Supportのノート888828.1および1270094.1を参照してください。
- 管理ドメインのストレージ構成
管理ドメイン(dom0)には、イメージ・リポジトリおよびOracle VM構成ファイルが含まれます。 - ユーザー・ドメインのストレージ構成
ユーザー・ドメイン(domU)は、仮想化されたデータベース・ノードです。
関連トピック
5.1.4.1 管理ドメインのストレージ構成
管理ドメイン(dom0)には、イメージ・リポジトリおよびOracle VM構成ファイルが含まれます。
管理ドメインには次のディレクトリが含まれます。
/EXAVMIMAGES
。ゲストの作成に使用されたイメージが格納されます。このディレクトリ内のZIPファイルには、ISOファイルが含まれています。/conf
/GuestImages
。各ユーザー・ドメインを表すファイルが格納されます。
管理ドメインは、物理ディスク/dev/sda
に存在します。次の3つのディスク・パーティションがあります。
/dev/sda1
—/boot
としてマウントされます。/dev/sda2
—swap
に使用されます。/dev/sda3
— ボリューム・グループVGExaDb
に使用されます。
管理ドメイン用に作成された論理ボリュームは次のとおりです。
/dev/VGExaDb/LVDbSys2
— バックアップの実行中にdbnodeupdate.sh
によって使用されます/dev/VGExaDb/LVDbSys3
—/
としてマウントされます/dev/VGExaDb/LVDbSwap1
— スワップ領域に使用されます/dev/VGExaDb/LVDoNotRemoveOrUse
— バックアップの実行中にdbnodeupdate.sh
によって使用されます/dev/VGExaDb/LVDbExaVMImages
—EXAVMIMAGES
としてマウントされます
/EXAVMIMAGES
ディレクトリは、各仮想マシンの構成ファイルが配置される場所です。ファイルの名前は/EXAVMIMAGES/GuestImages/nodename/vm.cfg
の形式になります。各仮想マシンには、イメージ・リポジトリ内のISOファイルを指すイメージ・ファイルもあります。pv1_vgeexadb.img
を除く次のファイルは、reflinks (OCFS2機能)を使用して作成されます。
/EXAVMIMAGES/GuestImages/user-domain-name/System.img
/EXAVMIMAGES/GuestImages/user-domain-name/gridversion.img
/EXAVMIMAGES/GuestImages/user-domain-name/dbversion.img
親トピック: Oracle VMリソース
5.1.4.2 ユーザー・ドメインのストレージ構成
ユーザー・ドメイン(domU)は、仮想化されたデータベース・ノードです。
各ユーザー・ドメインには、管理ドメイン(dom0)レベルで4つの仮想ディスクがあります。これは、/EXAVMIMAGES/GuestImages/user_domain_name/vm.cfg
で参照できます。これらの4つの仮想ディスクは、次に示すように、実際のディスク・イメージ・ファイルである/EXAVMIMAGES/GuestImages/user_domain_name
の4つのファイルにソフト・リンクされます。
/dev/xvda
は、システム・イメージ・ファイルSystem.img
用です/dev/xvdb
は、Oracle Grid Infrastructureイメージ・ファイル(grid12.1.0.2.2.img
など)用です。この仮想ディスクのサイズは50GBで、/u01/app/version/grid
としてマウントされます。/dev/xvdc
は、Oracle Databaseイメージ・ファイル(db12.1.0.2.2-3.img
など)用です。この仮想ディスクのサイズは50GBで、/u01/app/oracle/product/version/dbhome_1
としてマウントされます。/dev/xvdd
は、pv1_vgexadb.img
イメージ・ファイル用です
System.img
(/dev/xvda
)ディスクには、pre-grub2イメージ上に2つのパーティションが作成され、grub2イメージ上に3つのパーティションが作成されます。
- Pre-Grub2イメージ
- パーティション1 — ユーザー・ドメイン(512MB)のブート・パーティション(
/boot
)で、ユーザー・ドメインのxvda1
として表されます。 - パーティション2 — bios-grubが格納されている場所(24.5GB)。ユーザー・ドメインの
xvda2
として表されます。
- パーティション1 — ユーザー・ドメイン(512MB)のブート・パーティション(
- Grub2イメージ
- パーティション1 — ユーザー・ドメイン(512MB)のブート・パーティション(
/boot
)で、ユーザー・ドメインのxvda1
として表されます。 - パーティション2 - Oracle Exadata Database Machine X7以上のシステムのEFIブート・パーティション
- パーティション3 — bios-grubが格納されている場所(24.5GB)。ユーザー・ドメインの
xvda3
として表されます。
- パーティション1 — ユーザー・ドメイン(512MB)のブート・パーティション(
pv1_vgexadb.img
(/dev/xvdd
)ディスクには1つのパーティションがあります。ディスク・パーティション/dev/xvdd1
のサイズは62GBです。
pre-grub2イメージの場合、2つの物理ボリューム(PV)がxvda2
およびxvdd1
パーティションの上部に配置されます。grub2イメージの場合、2つの物理ボリューム(PV)がxvda3
およびxvdd1
パーティションの上部に配置されます。サイズ86.49Gのボリューム・グループ(VgExaDb
)は、これらの物理ボリュームの上部に配置されます。このボリューム・グループには、次の論理ボリューム(LVM)が含まれています。
/dev/VGExaDb/LVDbSys1
(24GB) — ルート・ファイル・システム/
に使用されます。このLVMは、xvda2
パーティション(pre-grub2イメージの場合)またはxvda3
パーティション(grub2イメージの場合)に制限されます。/dev/VGExaDb/LVDbSys2
(24GB) —dbnodeupdate
バックアップに使用されます。/dev/VGExaDb/LVDbOra1
(24GB) —diagnostic_dest
領域を格納する/u01
ファイル・システムに使用されます。/dev/VGExaDb/LVDbSwap1
(16GB) —swap
に使用されます/dev/VGExaDb/LVDbDoNotRemoveOrUse
(1GB) —dbnodeupdate
によって使用される予約済LVM/dev/VGExaDb/LVDbVdnodenamedgname
(128MB) — quorumディスク用。
前述のリストの最初のLVMおよび最後のLVM以外のすべてのLVMは、xvdd1
パーティションに含まれています。
親トピック: Oracle VMリソース
5.2 ベア・メタルOracle RACクラスタからOracle VMのOracle RACクラスタへの移行
ノート:
このトピックは、2ソケットのx86サーバーにのみ適用されます。Oracle Exadata Database Machine X5-8などの8ソケット・サーバーには適用されません。ベア・メタルOracle RACクラスタからOracle VMのOracle RACクラスタへの移行は次の方法で実行できます。
-
既存のベア・メタルOracle RACクラスタを使用して、Oracle VMにOracle RACクラスタを移行します(ダウンタイムは発生しません)。
-
Oracle VMに新しいOracle RACクラスタを作成して、Oracle VMにOracle RACクラスタを移行します(最低限のダウンタイムが発生します)。
-
Oracle Data Guardを使用してOracle VMにOracle RACクラスタに移行します(最低限のダウンタイムが発生します)。
-
Oracle Recovery Manager (RMAN)バックアップおよびリストアを使用してOracle VMのOracle RACクラスタに移行します(ダウンタイムが発生します)。
ベア・メタルOracle RACクラスタからOracle VMのOracle RACクラスタに変換することは、次のことを示唆します。
-
各データベース・サーバーがOracle VM Serverに変換され、Oracle VM Serverには管理ドメイン(dom0)と、デプロイされるOracle RACクラスタの数に応じて1つ以上のユーザー・ドメインが作成されます。データベース・サーバー上の各ユーザー・ドメインは特定のOracle RACクラスタに属します。
-
変換手順の一環として、初めにベア・メタルOracle RACクラスタがOracle VM内の1つのOracle RACクラスタに変換されます。データベース・サーバーごとに1つのユーザー・ドメインがあります。
-
変換が終わった後のストレージ・セルのセル・ディスクとグリッド・ディスクの構成は、変換の開始時の構成と同じになります。
-
各データベース・サーバー上で管理ドメインによって使用されるシステム・リソースの量は同じになります。通常、管理ドメインでは8 GBのメモリーと4つの仮想CPUが使用されます。この点を考慮してOracle VMのOracle RACクラスタで実行するデータベースのSGAのサイズを決定してください。
- 詳細な手順は、My Oracle Supportノート2099488.1を参照してください。
5.5 Oracle Enterprise Managerを使用したOracle VMの監視
Oracle Enterprise ManagerのExadataプラグインは、Oracle Enterprise Managerの仮想インフラストラクチャ・プラグインと組み合せて、仮想化されたOracle Exadata Database Machineを検出、管理および監視します。
- Oracle Exadata Database Machine上のOracle VMドメインを検出する方法については、Oracle Enterprise Manager Exadata Managementスタート・ガイドの仮想化されたExadata Database Machineに関する項を参照してください。
親トピック: Oracle VMユーザー・ドメインの管理
5.7 Oracle VMユーザー・ドメインの自動起動の管理
デフォルトでは、ユーザー・ドメインは、作成するとき、管理ドメインが起動するときに自動的に起動するように構成されます。この機能は必要に応じて有効/無効を切り替えることができます。
5.7.1 ユーザー・ドメインの自動起動の有効化
次の手順では、管理ドメインが起動した場合に、ユーザー・ドメインが自動的に起動するのを有効にする方法について説明します。
親トピック: Oracle VMユーザー・ドメインの自動起動の管理
5.7.2 ユーザー・ドメインの自動起動の無効化
次の手順では、管理ドメインが起動した場合に、ユーザー・ドメインが自動的に起動するのを無効にする方法について説明します。
親トピック: Oracle VMユーザー・ドメインの自動起動の管理
5.9 管理ドメイン内部のユーザー・ドメインのシャットダウン
次の手順では、管理ドメイン内部でユーザー・ドメインをシャットダウンする方法について説明します。
親トピック: Oracle VMユーザー・ドメインの管理
5.10 Oracle VMユーザー・ドメインでのOracle Databasesのバックアップおよびリストア
Oracle VMユーザー・ドメインでのOracleデータベースのバックアップとリストアは、物理ノードでのOracleデータベースのバックアップとリストアと同じです。
親トピック: Oracle VMユーザー・ドメインの管理
5.11 ユーザー・ドメインに割り当てられたメモリーの変更
次の手順では、ユーザー・ドメインに割り当てられたメモリーを変更する方法について説明します。
ノート:
この手順では、ユーザー・ドメインを再起動する必要があります。メモリー割当てを変更する場合、xm mem-set
コマンドはサポートされていません。
親トピック: Oracle VMユーザー・ドメインの管理
5.12 ユーザー・ドメインに割り当てられた仮想CPU数の変更
-
ユーザー・ドメインに割り当てられた仮想CPU数を変更するためのすべてのアクションは、管理ドメインで実行されます。
-
ユーザー・ドメインに可能な仮想CPU数は、ユーザー・ドメインの
maxvcpus
パラメータで設定される値の範囲内で、動的に増減します。 -
仮想CPUをオーバーコミットすると、すべてのドメインに割り当てられた仮想CPUを、システム上の物理CPU数より多く割り当てることができます。ただし、CPUのオーバーコミットは、過剰に収容されたリソースへの競合するワークロードが十分理解され、同時に発生する要求が物理能力を超えない場合にのみ、実行する必要があります。
次の手順では、ユーザー・ドメインに割り当てられた仮想CPU数を変更する方法について説明します。
-
次の手順に従い、物理CPU数を判別します。
-
管理ドメインで、次のコマンドを実行します。
# xm info | grep -A3 nr_cpus nr_cpus : 24 nr_nodes : 2 cores_per_socket : 6 threads_per_core : 2
出力で、
nr_nodes
行はソケットの数を示しています。コマンドが実行されるExadataデータベース・サーバーのプロセッサは2ソケットで、ソケット当たり6コアであるため、物理CPUスレッドは24個(2ソケット x 6コア/ソケット = 12コア。12コア x 2スレッド/コア = 24 CPUスレッド)です。 -
次のコマンドを実行して、ユーザー・ドメインに構成されオンラインである仮想CPUの現在の設定を判別します。
# xm list DomainName -l | grep vcpus (vcpus 4) (online_vcpus 2)
前述のコマンドで、DomainNameはユーザー・ドメインの名前です。コマンドの出力例では、ユーザー・ドメインの仮想CPUの最大数は4で、現在のオンライン仮想CPUは2です。このユーザー・ドメインのオンラインの仮想CPUの数は、ユーザー・ドメインがオンラインの間に、
vcpus
パラメータよりも大きくない数に調整されます。オンラインの仮想CPUの数をvcpus
パラメータよりも大きい値に増やすには、ユーザー・ドメインをオフラインにする必要があります。
-
-
次の手順に従い、仮想CPU数を小さくするまたは大きくします。
-
仮想CPU数を減らすには:
-
次のコマンドを使用して、ユーザー・ドメインに現在割り当てられている仮想CPUの数を判別します。
# xm list
DomainName
-
次のコマンドを使用して、現在割り当てられている仮想CPU数を減らします。
# xm vcpu-set
DomainName
vCPUs_preferred
前述のコマンドで、vCPUs_preferredは、推奨される仮想CPU数の値です
-
-
仮想CPU数を増やすには
-
次のコマンドを使用して、
vcpus
パラメータの現在の設定を判別します。# xm list DomainName -l | grep vcpus (vcpus 4) (online_vcpus 2)
-
推奨される仮想CPU数が、
vcpus
パラメータの値より小さいか等しい場合、次のコマンドを実行して、オンライン仮想CPU数を増やします。# xm vcpu-set DomainName
vCPUs_preferred
前述のコマンドで、vCPUs_preferredは、推奨される仮想CPU数の値です
-
推奨される仮想CPU数が、
vcpus
パラメータの値より大きい場合、オンラインの仮想CPUの数をvcpus
パラメータよりも大きい値に増やすには、ユーザー・ドメインをオフラインする必要があります。次の手順を実行します。i.ユーザー・ドメインをシャットダウンします。
ii.
/EXAVMIMAGES/GuestImages/
DomainName
/vm.cfg
ファイルのバックアップ・コピーを作成します。iii.
/EXAVMIMAGES/GuestImages/
DomainName
/vm.cfg
ファイルを編集し、vcpus
パラメータを推奨される仮想vCPUの数に設定します。ノート: デフォルトでは、ユーザー・ドメインは、
vcpus
パラメータで構成された仮想CPUの数をオンラインにします。一部の仮想CPUをオフラインにしてユーザー・ドメインを起動する場合は、maxvcpus
パラメータをvm.cfg
に追加し、ユーザー・ドメインでオンラインにできる仮想CPUの最大数に設定します。vcpus
パラメータを仮想CPUの数に設定し、ユーザー・ドメインの起動時にオンラインにします。たとえば、2つの仮想CPUがオンラインのユーザー・ドメインを起動し、そのユーザー・ドメインがオンラインの間に、さらに6つの仮想CPUをユーザー・ドメインに追加する場合は、次の設定をvm.cfg
に使用します。maxvcpus=8 vcpus=2
iv.ユーザー・ドメインを開始します。
-
-
親トピック: Oracle VMユーザー・ドメインの管理
5.13 ユーザー・ドメインのディスク領域の増加
ユーザー・ドメインのLogical Volume Manager (LVM)パーティション、スワップ領域およびファイル・システムのサイズは拡大できます。
- 新規LVMディスクのユーザー・ドメインへの追加
- rootファイル・システムのサイズの増加
この手順では、システム・パーティションと/
(root)ファイル・システムのサイズを増やす方法について説明します。 - /u01ファイル・システムのサイズの増加
この手順では、/u01
ファイル・システムのサイズを増やす方法について説明します。 - Grid InfrastructureホームまたはDatabaseホーム・ファイル・システムのサイズの増加
ユーザー・ドメイン内のOracle Grid InfrastructureまたはOracle Databaseホームのファイル・システムのサイズを増やすことができます。 - スワップ領域のサイズの増加
この手順では、ユーザー・ドメインで構成されたスワップの容量を増やす方法について説明します。
親トピック: Oracle VMユーザー・ドメインの管理
5.13.1 新規LVMディスクのユーザー・ドメインへの追加
次の手順では、新LVMディスクをユーザー・ドメインに追加して、ユーザー・ドメイン内で使用できるLVMディスク領域の量を増やす方法について説明します。この手順を実行すると、ファイル・システムまたはスワップLVMパーティションのサイズを増やすことができます。これはシステムがオンラインの場合に実行できます。
ノート:
この手順は、管理ドメイン(Domain-0)およびユーザー・ドメイン内で実行するステップが必要です。
すべてのステップを、root
ユーザーとして実行してください。
親トピック: ユーザー・ドメインのディスク領域の増加
5.13.2 rootファイル・システムのサイズの増加
この手順では、システム・パーティションおよび/
(ルート)ファイル・システムのサイズを増やす方法について説明します。
これはファイル・システムがオンラインの場合に実行できます。
ノート:
2種類のシステム・パーティション、LVDbSys1
およびLVDbSys2
が使用できます。片方のパーティションがアクティブでマウントされます。もう一方のパーティションは非アクティブで、アップグレード中、バックアップする場所として使用します。この2つのシステム・パーティションは、サイズが等しい必要があります。
VGExaDb
ボリューム・グループ内に、少なくとも1GBの空き領域が必要です。空き領域は、ソフトウェア保守の際に、dbnodeupdate.sh
ユーティリティで作成したLVMスナップショットで使用します。「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、/
(root)および/u01
ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDb
ボリューム・グループに少なくとも6GBの空き領域が必要です。
関連トピック
親トピック: ユーザー・ドメインのディスク領域の増加
5.13.3 /u01ファイル・システムのサイズの増加
この手順では、/u01
ファイル・システムのサイズを増やす方法について説明します。
これはファイル・システムがオンラインの場合に実行できます。
ノート:
VGExaDb
ボリューム・グループ内に、少なくとも1GBの空き領域が必要です。空き領域は、ソフトウェア保守の際に、dbnodeupdate.sh
ユーティリティで作成したLVMスナップショットで使用します。「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、/
(root)および/u01
ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDb
ボリューム・グループに少なくとも6GBの空き領域が必要です。
関連トピック
親トピック: ユーザー・ドメインのディスク領域の増加
5.13.4 Oracle Grid InfrastructureホームまたはDatabaseホーム・ファイル・システムのサイズの増加
ユーザー・ドメイン内のOracle Grid InfrastructureまたはOracle Databaseホームのファイル・システムのサイズを増やすことができます。
Oracle Grid Infrastructureソフトウェア・ホームおよびOracle Databaseソフトウェア・ホームのために、それぞれのディスク・イメージ・ファイルが管理ドメインに作成されます。ディスク・イメージ・ファイルの場所は、/EXAVMIMAGES/GuestImages/DomainName/
ディレクトリです。ディスク・イメージ・ファイルは、仮想マシンの起動中に自動的にユーザー・ドメインに関連付けられ、別個にLVMではないファイル・システムとしてユーザー・ドメインにマウントされます。
親トピック: ユーザー・ドメインのディスク領域の増加
5.13.5 スワップ領域のサイズの増加
この手順では、ユーザー・ドメインで構成されたスワップの容量を増やす方法について説明します。
関連トピック
親トピック: ユーザー・ドメインのディスク領域の増加
5.14 データベース・サーバーのディスク拡張キット追加後の/EXAVMIMAGESの拡張
データベース・サーバーにディスク拡張キットを追加するときには、適切な手順に従って、新しい領域を/EXAVMIMAGES
ファイル・システムに追加することが重要です。
ノート:
ディスク拡張キットは、X5-2以降の2ソケットのOracle Exadata Database Machineシステムでのみサポートされています。- リリース18.1.x以降の管理ドメインでの/EXAVMIMAGESの拡張
Oracle Exadata System Softwareリリース18c (18.1.0)以降のリリースを使用している場合は、この手順を使用して、ディスク拡張キットの追加後に管理ドメインで/EXAVMIMAGES
ファイル・システムを拡張します。 - リリース12.2.xの管理ドメインでの/EXAVMIMAGESの拡張
Oracle Exadata System Softwareリリース12.2.xを使用している場合は、この手順を使用して、ディスク拡張キットの追加後に管理ドメインで/EXAVMIMAGES
ファイル・システムを拡張します。 - リリース12.2.xより前の管理ドメインでの/EXAVMIMAGESの拡張
リリース12.1.2.3.0以降で、リリース12.2.xより前のOracle Exadata System Softwareを使用している場合は、この手順を使用して、ディスク拡張キットの追加後に管理ドメインで/EXAVMIMAGES
ディレクトリを拡張します。
親トピック: Oracle VMユーザー・ドメインの管理
5.14.1 リリース18.1.x以降の管理ドメインでの/EXAVMIMAGESの拡張
Oracle Exadata System Softwareリリース18c (18.1.0)以降のリリースを使用している場合は、この手順を使用して、ディスク拡張キットの追加後に管理ドメインで/EXAVMIMAGES
ファイル・システムを拡張します。
デプロイメント中、データベース・サーバー上の使用可能なディスク領域はすべて管理ドメイン (dom0)に割り当てられ、その領域のほとんどがユーザー・ドメイン・ストレージ用の/EXAVMIMAGES
に割り当てられます。/EXAVMIMAGES
ファイル・システムが/dev/VGExaDb/LVDbExaVMImages
に作成されます。
次の例では、dm01db01
が管理ドメインの名前で、dm01db01vm01
がユーザー・ドメインです。
5.14.2 リリース12.2.xの管理ドメインでの/EXAVMIMAGESの拡張
Oracle Exadata System Softwareリリース12.2.xを使用している場合は、この手順を使用して、ディスク拡張キットの追加後に管理ドメインで/EXAVMIMAGES
ファイル・システムを拡張します。
デプロイメント中、データベース・サーバー上の使用可能なディスク領域はすべて管理ドメイン (dom0)に割り当てられ、その領域のほとんどがユーザー・ドメイン・ストレージ用の/EXAVMIMAGES
に割り当てられます。/EXAVMIMAGES
ファイル・システムが/dev/VGExaDb/LVDbExaVMImages
に作成されます。
次の例では、dm01db01
が管理ドメインの名前で、dm01db01vm01
がユーザー・ドメインです。
5.14.3 リリース12.2.xより前の管理ドメインでの/EXAVMIMAGESの拡張
リリース12.1.2.3.0以降で、リリース12.2.xより前のOracle Exadata System Softwareを使用している場合は、この手順を使用して、ディスク拡張キットの追加後に管理ドメインで/EXAVMIMAGES
ディレクトリを拡張します。
デプロイメント中、データベース・サーバー上の使用可能なディスク領域はすべて管理ドメインに割り当てられ、その領域のほとんどがユーザー・ドメイン・ストレージ用の/EXAVMIMAGES
に割り当てられます。/EXAVMIMAGES
ファイル・システムが/dev/sda3
に作成されます。
次の例では、dm01db01
が管理ドメインの名前で、dm01db01vm01
がユーザー・ドメインです。
5.15 Oracle VMクラスタの追加
Oracle Exadata Deployment Assistant (OEDA)を使用して、既存のExadata Database Machineに新しいOracle VMクラスタを作成できます。
親トピック: Oracle VMユーザー・ドメインの管理
5.16 OEDACLIを使用したOracle VMでのOracle RACクラスタの拡張
Oracle VMに既存のOracle RACクラスタは、Oracle Exadata Deployment Assistantコマンドライン・インタフェース(OEDACLI)を使用してユーザー・ドメインを追加することで拡張できます。
OEDACLIは、目的のクラスタに適した既知のバージョンのOEDA XMLファイルがある場合に優先される方法です。
ノート:
この手順の実行中、既存のOracle RACクラスタ・ノードとそのデータベース・インスタンスでは、停止時間は発生しません。この手順のユースケースは次のとおりです。
- Oracle Exadataラックのデータベース・サーバーのサブセットのみを使用する既存のOracle RACクラスタがあり、現在クラスタによって使用されていないノードが使用候補になった場合。
- データベース・サーバーを追加することで最近拡張したExadata Database Machineに既存のOracle RACクラスタがある場合。
- 完全なノード障害が発生たノードを削除して新しくイメージ化したノードに置き換えた、既存のOracle RACクラスタがある場合。
この項のステップを実行する前に、「クラスタへの新しいデータベース・サーバーの追加」の説明に従って新しいデータベース・サーバーを設定しておく必要があります。これには、次の項目も含まれます。
- 管理ドメインが含まれるネットワークに、新しいデータベース・サーバーをインストールして構成します。
- 最新のOracle Exadata Deployment Assistant (OEDA)をダウンロードします(ダウンロードするファイルのバージョンが2019年7月以降のリリースであることを確認します)。
- 既存のクラスタ構成を正確に反映したOEDA構成XMLファイルを用意します。このXMLファイルを検証するには、そのファイルからインストール・テンプレートを生成して現在の構成と比較します。OEDACLIコマンドSAVE FILESを参照してください。
- 現在のシステム構成についてのOEDAインストール・テンプレートのレポートを確認して、既存のノードのノード名とIPアドレスを取得します。新しく追加するノードのために新しいホスト名とIPアドレスが必要になります。次の新しいホスト名とIPアドレスが必要になります。
- 管理ドメインとユーザー・ドメインの管理ホスト名とIPアドレス(ADMINNETと表記します)。
- 管理ドメインとユーザー・ドメインのプライベート・ホスト名とIPアドレス(PRIVNETと表記します)。
- 管理ドメインのIntegrated Lights Out Manager (ILOM)ホスト名とIPアドレス。
- ユーザー・ドメインのクライアント・ホスト名とIPアドレス(CLIENTNETと表記します)。
- ユーザー・ドメインの仮想IP(VIP)ホスト名とIPアドレス(VIPNETと表記します)。
- 新しいノードの物理ラック番号とラック内のでの場所(
U
番号単位)
-
それぞれの管理ドメインが、既存のデータベース・サーバーで使用しているイメージと同じになるようにイメージ化またはパッチ適用しておきます。現在のシステム・イメージが、新しい管理ドメインノードの
/EXAVMIMAGES/ System.first.boot.*.img
ファイルのバージョンと一致している必要があります。ノート:
この後で参照される~/dom0_group
ファイルは、既存のノードと新しく追加するノードのすべての管理ドメインのホスト名が含まれているテキスト・ファイルです。すべての管理ドメイン間でイメージのバージョンが同じことを確認します。
dcli -g ~/dom0_group -l root "imageinfo -ver" exa01adm01: 19.2.0.0.0.190225 exa01adm02: 19.2.0.0.0.190225 exa01adm03: 19.2.0.0.0.190225
イメージのバージョンに異なるものがある場合は、そのバージョンが一致するようにノードをアップグレードする必要があります。
すべての管理ドメインの
System.first.boot
のバージョンが、前のステップで取得したイメージのバージョンと一致していることを確認します。dcli -g ~/dom0_group -l root "ls -1 /EXAVMIMAGES/System.first.boot*.img" exa01adm01: /EXAVMIMAGES/System.first.boot.19.2.0.0.0.190225.img exa01adm02: /EXAVMIMAGES/System.first.boot.19.2.0.0.0.190225.img exa01adm03: /EXAVMIMAGES/System.first.boot.19.2.0.0.0.190225.img
いずれかのノードに、現在のイメージと一致する
System.first.boot.img
ファイルがない場合は、必要なファイルを取得します。My Oracle SupportのドキュメントID 888828.1で、対象のExadataリリース用の補足READMEノートを確認し、"DomU System.img OS image for V.V.0.0.0 VM creation on upgraded dom0s"という説明文に対応するパッチ・ファイルを見つけてください。 -
klone.zip
ファイル(gi-klone*.zip
とdb-klone*.zip
)を、クラスタに追加する新しくイメージ化された管理ドメインノードの/EXAVMIMAGES
の場所に配置します。これらのファイルは、最初にシステムをデプロイした管理ドメインの/EXAVMIMAGES
ディレクトリにあります。
このステップでは、exa01adm03
という新しい管理ドメインノードを追加する方法を示します。このノードには、exa01adm03vm01
という新しいユーザー・ドメインを含めます。このステップでは、OEDACLIコマンドを使用して、既存のOracle RACクラスタをユーザー・ドメインに拡張する方法を示します。既存のクラスタには、exa01adm01
およびexa01adm02
という管理ドメインノードと、exa01adm01vm01
およびexa01adm02vm01
というユーザー・ドメイン・ノードがあります。
5.17 Oracle Grid InfrastructureおよびOracle Databaseの存在しないユーザー・ドメインの作成
ユーザー・ドメインは、システムにOracle Grid InfrastructureおよびOracle Databaseをインストールせずに作成することができます。新しいユーザー・ドメインの要素は、次の通りです。
-
オペレーティング・システム・イメージがOracle Linuxである。
-
管理ネットワーク、クライアント・ネットワークおよびInfiniBandネットワークへアクセスできる。
-
Oracle Grid InfrastructureおよびOracle Databaseがインストールされていない。
Oracle Grid InfrastructureおよびOracle Databaseの存在しないユーザー・ドメインを作成する手順は、次の通りです。
-
未使用の新規IPアドレスおよびホスト名を新しいユーザー・ドメインに割り当てます。IPアドレスおよびホスト名は、管理ネットワーク、クライアント(SCAN)ネットワークおよびプライベートInfiniBandネットワークで必要です。
ノート:
アドレスごとに
ping
コマンドを使用して、該当のInfiniBandネットワークのIPアドレスが使用されていないことを確認します。ibhosts
コマンドには、ユーザー・ドメインのエントリが含まれていないため、このコマンドを使用して、すべてのInfiniBandネットワークのIPアドレスが使用されていることを確認することはできません。 -
必要に応じて、更新されたユーザー・ドメイン(domU)システム・イメージ・ファイルを取得します。
ユーザー・ドメインを作成するために、この手順の後で実行する
exadata.img.domu_maker
コマンドには、ユーザー・ドメイン(domU)システム・イメージ・ファイルSystem.first.boot.
version
.img
が/EXAVMIMAGES
に必要です(version
は、管理ドメインのExadataソフトウェアのバージョンに一致し、管理ドメインで"imageinfo -ver
"コマンドを実行することで確認できます)。たとえば、
exadata.img.domu_maker
を実行して、新しいユーザー・ドメインを作成し、管理ドメインのExadataソフトウェアのバージョンが12.1.2.1.1.150316.2の場合、ユーザー・ドメイン(domU)システム・イメージ・ファイル/EXAVMIMAGES/System.first.boot.12.1.2.1.1.150316.2.img
が存在する必要があります。# imageinfo -ver 12.1.2.1.1.150316.2 # ls -l /EXAVMIMAGES/System.first.boot.12.1.2.1.1.150316.2.img -rw-r--r-- 1 root root 13958643712 Mar 23 12:25 /EXAVMIMAGES/System.first.boot.12.1.2.1.1.150316.2.img
ユーザー・ドメイン(domU)システム・イメージ・ファイルが存在しない場合は、My Oracle Supportから取得し、管理ドメインの
/EXAVMIMAGES
に配置する必要があります。詳細は、My Oracle Supportノート888828.1を参照してください。 -
次のコマンドを使用して、管理ドメインで、既存のXML構成ファイルをデプロイ済ユーザー・ドメインからコピーして、新しい名前のファイルにコピーします。
# cp /EXAVMIMAGES/conf/existingDomainName-vm.xml /EXAVMIMAGES/conf/newDomainName-vm.xml
前述のコマンドで、
existingDomainName
-vm.xml
は、デプロイされたユーザー・ドメインのXML構成ファイルで、newDomainName
-vm.xml
は新しいファイルの名前です。次の例では、ユーザー・ドメイン"dm01db01vm01"の構成ファイルを、
nondbdomain-vm.xml
にコピーします。# cp /EXAVMIMAGES/conf/dm01db01vm01-vm.xml /EXAVMIMAGES/conf/nondbdomain-vm.xml
-
管理ドメインで、次のようにして、新しいXMLファイルを編集します。
-
すべての
<Hostname>
タグを変更して、対応するネットワークの新しいホスト名に一致させます。 -
すべての
<IP_address>
タグを変更して、対応するネットワークの新しいIPアドレスに一致させます。 -
<virtualMachine>
タグを変更して、新しいホスト名を含めます。 -
<hostName>
タグを変更して、新しいホスト名を含めます。 -
すべてのサブ要素を含む、
<disk id="disk_2">
および<disk id="disk_3">
要素全体を削除します。開始<disk>
タグから対応する終了</disk>
の間のエントリ全体を削除する必要があります。
-
-
管理ドメインで、
/opt/exadata_ovm/exadata.img.domu_maker
コマンドを使用して、InfiniBandネットワークGUIDを新しいユーザー・ドメインに割り当てます。# /opt/exadata_ovm/exadata.img.domu_maker allocate-guids \ /EXAVMIMAGES/conf/newDomainName-vm.xml \ /EXAVMIMAGES/conf/final-newDomainName-vm.xml
-
管理ドメインで、
/opt/exadata_ovm/exadata.img.domu_maker
コマンドを使用して、新しいユーザー・ドメインを作成します。# /opt/exadata_ovm/exadata.img.domu_maker start-domain \ /EXAVMIMAGES/conf/final-newDomainName-vm.xml
親トピック: Oracle VMユーザー・ドメインの管理
5.18 ユーザー・ドメインの別のデータベース・サーバーへの移動
ユーザー・ドメインを別のデータベース・サーバーへ移動できます。
ターゲットのOracle Exadata Database Serverが、次の要件を満たしている必要があります。
-
ターゲット・データベース・サーバーに、同一リリースのOracle Exadata System SoftwareおよびOracle VMがインストールされている。
-
ターゲット・データベース・サーバーに、同一のネットワークが表示されている。
-
ターゲット・データベース・サーバーは、同一のOracle Exadata Storage Serverにアクセスできる。
-
ターゲット・データベース・サーバーで、ユーザー・ドメインの操作に必要な十分な空きリソース(メモリー、CPUおよびローカル・ディスク領域)が使用可能である。
-
仮想CPUをオーバーコミットすると、すべてのドメインに割り当てられた仮想CPUを、システム上の物理CPU数より多く割り当てることができます。CPUのオーバーコミットは、過剰に収容されたリソースへの競合するワークロードが十分理解され、同時に発生する要求が物理能力を超えない場合にのみ、実行する必要があります。
-
メモリーをオーバーコミットすることはできません。
-
ディスク・イメージをターゲット・データベース・サーバーにコピーすると、ディスク・イメージ・ファイルの領域の割当てが増加する場合があります。これは、コピーされたファイルは、OCFS2 reflinkを利用してディスク領域を省略できないためです。
-
-
ユーザー・ドメイン名は、ターゲット・データベース・サーバーで未使用の名前にする必要があります。
次の手順に従い、ユーザー・ドメインを同一のOracle Exadata System Software構成内の新しいデータベース・サーバーに移動します。この手順のすべてのステップは、管理ドメインで実行してください。
親トピック: Oracle VMユーザー・ドメインの管理
5.19 Oracle VMデプロイメントの管理ドメインとユーザー・ドメインのバックアップ
Oracle VMデプロイメントでは、管理ドメイン(dom0)とユーザー・ドメイン(domU)をバックアップする必要があります。
- スナップショット・ベースのバックアップを使用した管理ドメインdom0のバックアップ
この手順では、管理ドメインdom0
のスナップショット・ベースのバックアップを作成する方法について説明します。 - ユーザー・ドメインのバックアップ
ホスト上のすべてのユーザー・ドメインまたは個々のユーザー・ドメインのバックアップを作成できます。
親トピック: Oracle VMユーザー・ドメインの管理
5.19.1 スナップショット・ベースのバックアップを使用した管理ドメインdom0のバックアップ
この手順は、管理ドメインdom0
のスナップショット・ベースのバックアップを取得する方法を示しています。
論理ボリューム/dev/VGExaDb/LVDoNotRemoveOrUse
は、スナップショットを作成できるだけの空き領域を常に確保するためのプレースホルダです。dbserver_backup.sh
を実行すると、プレースホルダLVMがスクリプトによって削除され、それによって生まれた空き領域がスナップショットに使用され、スナップショットの作成後に再びLVMが作成されます。ここで説明する手動手順を実行する場合は、これらのタスクをすべて手動で実行する必要があります。
次のステップで示す値は、例です。root
ユーザーとして、すべてのステップを実行する必要があります。
5.19.2 ユーザー・ドメインのバックアップ
ホスト上のすべてのユーザー・ドメインまたは個々のユーザー・ドメインのバックアップを作成できます。
ユーザー・ドメインのバックアップ方法は3つあります。
-
方法1: Oracle Cluster File System (OCFS) reflinkを使用して記憶域リポジトリのすべてのユーザー・ドメインをバックアップし、一貫性のあるバックアップを取得する
この方法では、
/EXAVMIMAGES
OCFS2ファイル・システムである記憶域リポジトリをバックアップします。この方法では、方法2または3よりもより堅牢で包括的なバックアップが可能です。方法3は、特にロール別に分離された環境で、迅速で簡単なバックアップ方法が提供されます。方法1は、管理ドメイン(dom0)の管理者がユーザー・ドメインのバックアップを担当する場合に最適です。
-
方法2: Oracle Cluster File System (OCFS) reflinkを使用して記憶域リポジトリの個々のユーザー・ドメインをバックアップし、一貫性のあるバックアップを取得する
/EXAVMIMAGES
OCFS2ファイル・システムからバックアップするユーザー・ドメインを選択します。ユーザー・ドメインは、/EXAVMIMAGES/GuestImages/
userディレクトリにあります。方法2は、管理ドメイン(dom0)の管理者がユーザー・ドメインのバックアップを担当する場合に最適です。
-
方法3: スナップショット・ベースのバックアップを使用してユーザー・ドメインをバックアップする
この方法では、ユーザー・ドメイン内部からスナップショット・ベースのバックアップを作成することで、単一のユーザー・ドメインをバックアップします。
方法3は、ユーザー・ドメイン管理者がユーザー・ドメインのバックアップを担当している場合に最適です。
- 方法1: すべてのユーザー・ドメインをバックアップする
すべてのユーザー・ドメインをバックアップするには、/EXAVMIMAGES
OCFS2ファイル・システムのストレージ・リポジトリをバックアップします。 - 方法2: 個々のユーザー・ドメインのバックアップ
個々のユーザー・ドメインをバックアップするには、/EXAVMIMAGES
ファイル・システム内の特定のフォルダをバックアップします。 - 方法3: ユーザー・ドメイン内からユーザー・ドメインをバックアップする
ユーザー・ドメイン内からユーザー・ドメインのスナップショット・ベースのバックアップを取得できます。これは、ユーザー・ドメインを作業可能な状態にリストアするために使用できます。
5.19.2.1 方法1: すべてのユーザー・ドメインをバックアップする
/EXAVMIMAGES
OCFS2ファイル・システムであるストレージ・リポジトリをバックアップすることで、すべてのユーザー・ドメインをバックアップできます。
バックアップ先は、書込み可能なNFSの場所など、ローカル・マシンの外部に存在するようにし、バックアップを保持できる十分な大きさにする必要があります。バックアップに必要な領域は、システムにデプロイされるOracle VMの数に比例し、最大約1.6TBです。
この手順では、管理ドメインごとに15個以下のユーザー・ドメインがあることを前提としています。
親トピック: ユーザー・ドメインのバックアップ
5.19.2.2 方法2: 個々のユーザー・ドメインのバックアップ
/EXAVMIMAGES
ファイル・システム内の特定のフォルダをバックアップすることで、個々のユーザー・ドメインをバックアップできます。
バックアップ先は、書込み可能なNFSの場所など、ローカル・マシンの外部に存在するようにし、バックアップを保持できる十分な大きさにする必要があります。バックアップに必要な領域は、システムにデプロイされるOracle VMの数に比例し、最大約1.6TBです。
親トピック: ユーザー・ドメインのバックアップ
5.19.2.3 方法3: ユーザー・ドメイン内からユーザー・ドメインをバックアップする
ユーザー・ドメイン内からユーザー・ドメインのスナップショット・ベースのバックアップを取得できます。これは、ユーザー・ドメインを作業可能な状態にリストアするために使用できます。
すべてのステップはユーザー・ドメイン内から実行します。
ノート:
LVMスナップショットを使用してユーザー・ドメイン内からユーザー・ドメインをバックアップする方法では、リカバリ時の使用に関して制限があります。このようなバックアップは、ユーザー・ドメインがまだブート可能で、rootユーザーとしてログインできる場合のリカバリ用にのみ使用できます。これは、一部のファイルに損失または損傷が発生したが、ユーザー・ドメインがブートされ、/
(ルート)パーティションおよびブート・パーティションがマウントされた後に、tarバックアップからリストアできるような損傷です。そのような状況ではなくユーザー・ドメインをブートできない損傷の場合は、上述の方法1または2で作成したバックアップを使用してユーザー・ドメインをリカバリする必要があります。この場合は次の手順を実行して、ユーザー・ドメイン・レベルでリカバリ手順を実行する必要があります。
この手順では、次がバックアップされます。
- LVDbSys1
- LVDbOra1
/boot
パーティション- Grid Infrastructureホーム
- RDBMSホーム
rootユーザーとして、すべてのステップを実行する必要があります。
親トピック: ユーザー・ドメインのバックアップ
5.20 Oracle VMデプロイメントのリカバリ
重大な障害が発生してOracle VMが損傷した場合や、サーバー・ハードウェアを新しいハードウェアに交換した場合は、スナップショット・ベースのバックアップからOracle VMをリカバリできます。
たとえば、すべてのハード・ディスクを交換すると、システムの元のソフトウェアはトレースできません。これは、ソフトウェアの完全なシステムの交換と似ています。さらに、障害状態になる前にデータベース・サーバーが正常であったときに取得したLVMスナップショット・ベースのバックアップを使用するデータベース・サーバーの障害リカバリ方法を提供します。
この項で説明するリカバリ手順には、ストレージ・サーバーやOracle Databaseのデータのバックアップまたはリカバリは含まれていません。バックアップとリカバリ手順は定期的にテストすることをお薦めします。
- データベース・サーバーのスナップショット・ベースのリカバリの概要
Oracle VMのリカバリは、一連のタスクで構成されています。 - シナリオ1: 管理ドメインとそのユーザー・ドメインのバックアップからのリカバリ
管理ドメインとそのすべてのユーザー・ドメインは、バックアップからリカバリできます。 - シナリオ2: 管理ドメインの再イメージ化とバックアップからのユーザー・ドメインのリストア
この手順では、管理ドメインを再イメージ化し、すべてのユーザー・ドメインを再構築します。 - シナリオ3: スナップショット・バックアップからのユーザー・ドメインのリストアおよびリカバリ
この手順は、消失または損傷したユーザー・ドメインのファイルをユーザー・ドメイン内で作成したスナップショット・ベースのユーザー・ドメイン・バックアップからリストアするために使用します。
親トピック: Oracle VMユーザー・ドメインの管理
5.20.1 データベース・サーバーのスナップショット・ベースのリカバリの概要
Oracle VMのリカバリは、一連のタスクで構成されています。
リカバリ手順では、仮想CD-ROMとしてdiagnostics.iso
イメージを使用し、Integrated Lights Out Manager (ILOM)を使用してレスキュー・モードでOracle VMを再起動します。このステップの概要は、次のようになります。
-
次のものを再作成します。
-
ブート・パーティション
-
物理ボリューム
-
ボリューム・グループ
-
論理ボリューム
-
ファイル・システム
-
スワップ・パーティション
-
-
スワップ・パーティションをアクティブ化します。
-
/boot
パーティションがアクティブなブート・パーティションであることを確認します。 -
データをリストアします。
-
GRUBを再構成します。
-
サーバーを再起動します。
親トピック: Oracle VMデプロイメントのリカバリ
5.20.2 シナリオ1: 管理ドメインとそのユーザー・ドメインのバックアップからのリカバリ
管理ドメインとそのすべてのユーザー・ドメインは、バックアップからリカバリできます。
次の手順は、リカバリ・プロセスステップを示しています。システムにインストールされているOracle Exadata System Softwareのバージョンに応じて、次の手順のいずれかを選択します。
警告:
ディスクの既存のすべてのデータは、これらの手順の実行中に失われます。- 管理ドメインとそのユーザー・ドメインのリカバリ(12.2.1.1.0より前のリリース)
重大な障害が発生してdom0が損傷した場合や、サーバー・ハードウェアを新しいハードウェアに交換した場合は、スナップショット・ベースのバックアップから管理ドメインをリカバリできます。 - 管理ドメインとそのユーザー・ドメインのリカバリ(12.2.1.1.0以降のリリース)
重大な障害が発生して管理ドメインが損傷した場合や、サーバー・ハードウェアを新しいハードウェアに交換した場合は、スナップショット・ベースのバックアップから管理ドメインをリカバリできます。 - 管理ドメインとそのユーザー・ドメインのリカバリ(リリース18.1およびX7以降)
重大な障害が発生して管理ドメインが損傷した場合や、サーバー・ハードウェアを新しいハードウェアに交換した場合は、スナップショット・ベースのバックアップから管理ドメインをリカバリできます。
親トピック: Oracle VMデプロイメントのリカバリ
5.20.2.1 管理ドメインとそのユーザー・ドメインのリカバリ(12.2.1.1.0より前のリリース)
重大な障害が発生してdom0が損傷した場合や、サーバー・ハードウェアを新しいハードウェアに交換した場合は、スナップショット・ベースのバックアップから管理ドメインをリカバリできます。
このリカバリ方法を使用する場合は、「スナップショット・ベースのバックアップを使用した管理ドメインdom0のバックアップ」のステップを完了していることが前提になります。
この時点で、すべてのユーザー・ドメインがOracle Grid InfrastructureとOracle Databaseインスタンスとともに稼働します。データベース・インスタンスは、その他の残存している管理ドメイン・ノードで形成されたOracle Real Application Clusters (Oracle RAC)クラスタに参加する必要があります。
5.20.2.2 管理ドメインとそのユーザー・ドメインのリカバリ(リリース12.2.1.1.0以降)
重大な障害が発生して管理ドメインが損傷した場合や、サーバー・ハードウェアを新しいハードウェアに交換した場合は、スナップショット・ベースのバックアップから管理ドメインをリカバリできます。
このリカバリ方法を使用する場合は、「スナップショット・ベースのバックアップを使用した管理ドメインdom0のバックアップ」のステップを完了していることが前提になります。
この時点で、すべてのユーザー・ドメインがOracle Grid InfrastructureとOracle Databaseインスタンスとともに稼働します。データベース・インスタンスは、その他の残存している管理ドメイン・ノードで形成されたOracle Real Application Clusters (Oracle RAC)クラスタに参加する必要があります。
5.20.3 シナリオ2: 管理ドメインの再イメージ化およびバックアップからのユーザー・ドメインのリストア
この手順では、管理ドメインを再イメージ化し、すべてのユーザー・ドメインを再構築します。
次の手順は、修復不可能な損傷が管理ドメインで発生したときに、管理ドメインのバックアップは存在しないが、すべてのユーザー・ドメインを収容しているストレージ・リポジトリ(/EXAVMIMAGES
ファイル・システム)のバックアップが利用可能な場合に使用できます。
この時点で、すべてのユーザー・ドメインがOracle Grid Infrastructureとデータベース・インスタンスとともに起動します。ノードは、その他の残存している管理ドメイン・ノードで形成されたOracle RACクラスタに参加する必要があります。
親トピック: Oracle VMデプロイメントのリカバリ
5.20.4 シナリオ3: スナップショット・バックアップからのユーザー・ドメインのリストアおよびリカバリ
失ったまたは損傷したユーザー・ドメイン内のファイルを、ユーザー・ドメイン内で作成したスナップショット・ベースのユーザー・ドメイン・バックアップを使用してリストアするには、次の手順を使用します。
この手順を使用するには、「方法3: ユーザー・ドメイン内からユーザー・ドメインをバックアップする」の手順を使用して、ユーザー・ドメインのバックアップを作成しておく必要があります。
親トピック: Oracle VMデプロイメントのリカバリ
5.21 Oracle VMで実行するOracle RACクラスタの削除
クラスタ内で実行中のデータベースおよびこのデータベースで使用中のOracle Exadata Storage Serverで保存するすべてのデータを含む、Oracle VMクラスタのすべてのOracle RACノードを削除します。
Oracle VMクラスタの一部のユーザー・ドメインを削除する場合、次の項を参照してください。
Oracle VMクラスタを削除するステップは、主に2つあります。
-
ユーザー・ドメイン・ファイルを管理ドメインから削除する。
-
使用していないOracle Exadataグリッド・ディスクを削除する。
ノート:
Oracle Exadata Deployment Assistant xml
構成ファイルを後で再び使用する場合、削除されたユーザー・ドメインの定義がOracle Exadata Deployment Assistantファイル内に残っているため、それらの構成ファイルは同期できません。
親トピック: Oracle VMユーザー・ドメインの管理
5.22 ユーザー・ドメインの削除
Oracle VMのユーザー・ドメインは、OEDACLIまたはdomu_maker
ユーティリティを使用して削除できます。
- OEDACLIを使用したOracle VMクラスタからのユーザー・ドメインの削除
ユーザー・ドメインは、OEDACLIを使用してOracle VMクラスタから削除できます。 - domu_makerを使用したOracle VMクラスタからのユーザー・ドメインの削除
domu_maker
ユーティリティを使用すると、Oracle VMクラスタから単一のOracle RACノードを削除できます。
親トピック: Oracle VMユーザー・ドメインの管理
5.22.1 OEDACLIを使用したOracle VMクラスタからのユーザー・ドメインの削除
ユーザー・ドメインは、OEDACLIを使用してOracle VMクラスタから削除できます。
次の手順で、クラスタからユーザー・ドメインが削除されます。ユーザー・ドメインがクラスタの一部ではない場合、クラスタに関連するコマンドをスキップできます。
親トピック: ユーザー・ドメインの削除
5.22.2 domu_makerを使用したOracle VMクラスタからのユーザー・ドメインの削除
domu_maker
ユーティリティを使用すると、Oracle VMクラスタから単一のOracle RACノードを削除できます。
Oracle Exadataグリッド・ディスクは、クラスタ内に残っているノードで使用中のため、削除しないでください。
ノート:
Oracle Exadata Deployment Assistant xml
構成ファイルを後で再び使用する場合、削除されたユーザー・ドメインの定義がOracle Exadata Deployment Assistantファイル内に残っているため、それらの構成ファイルは同期できません。
親トピック: ユーザー・ドメインの削除
5.23 タグVLANインタフェースの実装
このトピックでは、Exadata上のOracle VM環境でのタグVLANインタフェースの実装について説明します。
Oracle Exadata Database Machine上のOracle VMゲストで稼働しているOracleデータベースは、Oracle Exadata Deployment Assistant (OEDA)構成ツールで定義されたクライアントEthernetネットワークを介してアクセスされます。管理ドメイン(dom0)およびユーザー・ドメイン(domU's)の両方で、クライアント・ネットワーク構成は、初回のデプロイメント中にOEDAインストール・ツールが最初のユーザー・ドメインを作成すると、自動的に実行されます。
次の図に、デフォルトの結合クライアント・ネットワーク構成を示します。
ネットワークは、次のように構成されます:
-
dom0では、OEDAで定義されて、domUクライアントへのアクセスが許可されているethスレーブ・インタフェース(たとえば、eth1とeth2またはeth4とeth5)が、検出、構成されて、起動しますが、IPは割り当てられません。
-
dom0では、bondeth0マスター・インタフェースが構成され、起動しますが、IPは割り当てられません。
-
dom0では、ブリッジ・インタフェースvmbondeth0が構成されますが、IPは割り当てられません。
-
dom0では、特定のdomU's bondeth0インタフェースにマッピングされる仮想バックエンド・インタフェース(vif)がdomUごとに1つずつ構成され、起動しますが、IPは割り当てられません。これらのvifsは、ブリッジ・インタフェースvmbondeth0の上に構成されます。dom0 vifインタフェースと、これに対応するユーザー・ドメイン・インタフェース、bondeth0の間のマッピングは、
/EXAVMIMAGES/GuestImages/user domain name
にあるvm.cfg
と呼ばれるユーザー・ドメイン構成ファイルで定義されます。
デフォルトのインストールでは、単一のbondeth0と対応するvmbondeth0ブリッジ・インタフェースは、前述で説明するようにdom0内で構成されます。このbondeth0インタフェースは、デフォルトのAccess Virtual Local Area Network (Access VLAN)に基づいています。Access VLANに対して、bondeth0を構築するスレーブ・インタフェースで使用されるスイッチ上のポートが構成されます。
VLANタグ付けの使用
Exadataの仮想デプロイメントで、ユーザー・ドメインをまたいでネットワーク分離を有効にするなど、クライアント・ネットワーク上の他のVLANにアクセスする必要がある場合、802.1QベースのVLANタグ付けにより解決できます。次の図に、VLANタグ付けをしたクライアント・ネットワーク構成を示します。
図5-2 VLANタグ付けをしたOracle Virtual EnvironmentのNICレイアウト
「図5-2 VLANタグ付けをしたOracle Virtual EnvironmentのNICレイアウト」の説明
このようなクライアント・ネットワーク上の追加のタグ付けされたVLANインタフェースの構成方法および使用方法の手順は、My Oracle Supportノート2018550.1を参照してください。これらの手順の実行の前後に、Access VLANが継続して稼働および構成されている必要があります。Access VLANが無効にされることはありません。
5.24 Exadata Database MachineでのOracle VM Oracle RACクラスタ間のInfiniBandパーティションの実装
Exadata Database MachineのOracle VMで実行しているOracle Real Application Clusters (Oracle RAC)クラスタの場合、カスタムのInfiniBandパーティション、専用のパーティション・キーおよびパーティション化表を使用することで、Oracle RACクラスタごとにInfiniBandネットワークのネットワーク・トラフィックを分離できます。
- Oracle VMで実行しているOracle RACクラスタ間のInfiniBandパーティションについて
InfiniBandパーティションでは、相互の通信を許可されるInfiniBandノードまたはメンバーのグループを定義します。 - OVM RACクラスタ間のInfiniBandパーティションを実装する際の要件
- InfiniBandパーティションのネットワーク構成について
クラスタにInfiniBandパーティションを実装したときに、クラスタpkeyインタフェースおよびストレージpkeyインタフェースで使用される各Oracle VM RACクラスタのIPアドレスとネットマスクのセットを計画して割り当てます。 - Oracle VM RACクラスタ間のInfiniBandパーティションの構成
ここでは、Oracle VMで実行するOracle RACクラスタ間のInfiniBandパーティションを構成するステップについて説明します。 - OVM RACクラスタ間のInfiniBandパーティションの実装: 制限されたメンバーシップの設定
関連トピック
親トピック: Oracle VMユーザー・ドメインの管理
5.24.1 Oracle VMで実行するOracle RACクラスタ間のInfiniBandパーティションについて
InfiniBandパーティションは、相互の通信を許可されるInfiniBandノードまたはメンバーのグループを定義します。
セキュリティの見地から、結合システムの重要な要件の1つは、結合システム内の複数の環境間のネットワーク分離です。Oracle Exadata上でOracle VM Oracle Real Application Clusters (Oracle RAC)クラスタを使用した結合では、これは、1つのOracle RACクラスタのネットワーク・トラフィックが別のOracle RACクラスタにアクセスできないようするなどの、異なるOracle RACクラスタ同士の分離を意味します。Ethernetネットワークでは、このことは、My Oracle Supportドキュメント2018550.1で説明するように、VLANタグ付けを使用して実現します。InfiniBandネットワークでは、これは、カスタムInfiniBandパーティション、専用パーティション・キーおよびパーティション化表を使用して完成します。
InfiniBandパーティションでは、一意のパーティション・キーで識別されるパーティションが作成され、マスター・サブネット・マネージャで管理されます。メンバーは、これらのカスタム・パーティションに割り当てられます。パーティション内のメンバーは、メンバー自身同士でのみ通信できます(My Oracle Supportドキュメント2018550.1のAppendix 1で説明されているように、メンバーシップにより異なります)。1つのパーティションのメンバーは、別のパーティションのメンバーとは、メンバーシップにかかわらず、通信できません。これらのラインを継続して、特定の1つのクラスタのOracle VM Oracle RACノードが、クラスタウェア通信用の1つの専用パーティションと、ストレージ・セルとの通信用の1つのパーティションに割り当てられます。このようにして、1つのOracle RACクラスタのノードは、異なるパーティションに属する別のOracle RACクラスタのノードと通信できません。それぞれのOracle RACクラスタのノードには、それらに割り当てられた異なるパーティション・キーがあります。
デフォルトで、InfiniBandサブネット・マネージャは、パーティション・キー0x7FFF (制限されたメンバーシップ)または0xFFFF (完全なメンバーシップ)により識別される単一パーティションを提供します。カスタムのInfiniBandパーティションを使用していないExadata Database Machine上のOracle VMデプロイメントでは、すべてのユーザー・ドメイン間で、パーティション・キー0xFFFFが使用されます。
図5-3 クラスタ間でInfiniBandネットワーク分離がないOracle VM Oracle RACクラスタ
「図5-3 クラスタ間でInfiniBandネットワーク分離がないOracle VM Oracle RACクラスタ」の説明
Oracle VM Oracle RACクラスタ間の分離を実装するためにデフォルト以外のカスタム・パーティションを使用する場合は、次の図に示すように構成が変化します。新しいインタフェースclib0
、clib1
(クラスタpkey用)およびstib0
、stib1
(ストレージpkey用)が、それぞれのユーザー・ドメイン(domU's)に存在します。
管理ドメイン(dom0)では、InfiniBandインタフェースの変更はありません。
図5-4 InfiniBandパーティションを使用してクラスタ間でInfiniBandネットワーク分離があるOracle VM Oracle RACクラスタ
「図5-4 InfiniBandパーティションを使用してクラスタ間でInfiniBandネットワーク分離があるOracle VM Oracle RACクラスタ」の説明
関連トピック
5.24.2 OVM RACクラスタ間のInfiniBandパーティションを実装する際の要件
InfiniBandパーティションの構成前に、次のことを確認します。
-
ExadataシステムでOVMを構成しました。
-
すべてのユーザー・ドメインとストレージ・セルで、デフォルトのパーティション・キー0xFFFFを使用しています。
-
rootユーザー用に、いずれかの管理ドメイン(dom0ノード)からすべてのOVM RACクラスタ・ノード、ストレージ・セルおよびInfiniBandスイッチへの、パスワードなしのセキュア・シェル(SSH)・アクセスを設定しました。
-
InfiniBandスイッチがファームウェア・バージョン2.0.4以上で設置されています。
-
InfiniBandパーティションについて理解しています。
5.24.3 InfiniBandパーティションのネットワーク構成について
クラスタにInfiniBandパーティションが実装されたときに、クラスタpkeyインタフェースおよびストレージpkeyインタフェースで使用される各Oracle VM RACクラスタのIPアドレスとネットマスクのセットを計画して割り当てます。
Oracle VM RACクラスタ内では、クラスタpkeyのIPアドレスおよびネットマスクは、ストレージpkeyのIPアドレスおよびネットマスクとは別のサブネット上に存在する必要があります。
参考として、次の表に、ある特定のRACクラスタのものを示します。
表5-2 既存の構成
インタフェース名 | IPアドレス | ネットマスク |
---|---|---|
ib0 |
192.168.12.153 |
255.255.248.0 |
ib1 |
192.168.12.154 |
255.255.248.0 |
次の表は、そのOracle RACクラスタにInfiniBandパーティションを実装するときにpkeyインタフェースに必要な新しいIPアドレスとネットマスクを示しています。
表5-3 pkeyインタフェースによって要求される新しいIPアドレスとネットマスク
インタフェース名 | IPアドレス | ネットマスク |
---|---|---|
clib0 |
192.168.112.1 |
255.255.248.0 |
clib1 |
192.168.112.2 |
255.255.248.0 |
stib0 |
192.168.114.1 |
255.255.240.0 |
stib1 |
192.168.114.2 |
255.255.240.0 |
5.24.4 Oracle VM RACクラスタ間のInfiniBandパーティションの構成
ここでは、Oracle VMで実行するOracle RACクラスタ間のInfiniBandパーティションを構成するステップについて説明します。
このタスクの開始前に、ファイルcreate_pkeys.tar
をダウンロードして解凍しておきます。このファイルは、「ExadataでのOVM RACクラスタ間のInfiniBandパーティションの実装(My Oracle SupportのドキュメントID 2075398.1)」からダウンロードできます。このファイルは、管理ドメイン(dom0)ノードのいずれかにダウンロードする必要があります。これは、この手順のすべてのスクリプトを実行するために使用するノードです。この手順では、このノードをdriver_dom0と表記します。
tarファイルを解凍すると、3つのファイルが表示されます。
create_pkeys_on_switch.sh
run_create_pkeys.sh
create_pkey_files.sh
5.24.5 OVM RACクラスタ間のInfiniBandパーティションの実装: 制限されたメンバーシップの設定
2016年10月の12.1.0.2データベース・バンドル・パッチでセキュリティ拡張機能が導入され、2016年10月の12.1.0.2バンドル・パッチより前に使用されていた完全なメンバーシップのかわりに、制限されたメンバーシップを使用して、データベース・ノードのGUIDをストレージpkeyに割り当てることができます。これは、ストレージpkeyインタフェースを使用するとあるRACクラスタのあるRACノードが別のRACクラスタのRACノードと通信できるセキュリティ上の問題の対策になります。
完全なメンバーシップと制限されたメンバーシップ
InfiniBandパーティションは、相互の通信を許可されるInfiniBandノードのグループを定義します。InfiniBandパーティションで、マスター・サブネット・マネージャによって管理されるカスタムまたは一意のパーティション・キーを定義して、カスタムのパーティション・キーにメンバーを割り当てます。同じパーティション・キーを持つメンバーのみが相互に通信できます。1つのパーティション・キーのメンバーは、別のパーティション・キーを持つメンバーとは、メンバーシップのタイプにかかわらず、通信できません。1つのクラスタのOVM RACクラスタ・ノードには、クラスタウェア通信用の1つのパーティション・キーと、ストレージ・セルとの通信用の別のパーティション・キーが割り当てられます。このように、RACクラスタのノードは、異なるパーティション・キーが割り当てられた別のRACクラスタのノードとは通信できません。このことは、イーサネットの分野のタグ付けされたVLANと概念的に非常に似ています。
パーティション・キー(pkey)は15ビットの整数で、0x1
から0x7FFF
の値を持ちます。追加のビットであるメンバーシップ・ビットによって、パーティションのメンバーのメンバーシップが識別されます。メンバーシップは次のとおりです。
-
完全: メンバーシップ・ビットは1に設定されます。完全なメンバーシップを持つメンバーは、相互に通信できることに加えて、同じパーティション・キー内の制限されたメンバーシップを持つメンバーと通信できます。
-
制限: メンバーシップ・ビットは0に設定されます。パーティション内の制限されたメンバーシップを持つメンバーは、相互に通信できません。ただし、同じパーティション内の完全なメンバーシップを持つ他のメンバーと通信できます。
pkeyとメンバーシップ・ビットが組み合されて16ビットの整数を構成します。最も重要なビットはメンバーシップ・ビットです。
デフォルトで、InfiniBandサブネット・マネージャは、パーティション・キー0x7FFF
(制限されたメンバーシップ)または0xFFFF
(完全なメンバーシップ)により識別される単一パーティションを提供します。
HCAポートは、最大で128個のパーティションに参加できます。それぞれのパーティション・キーで新しいIPoIBネットワーク・インタフェースが提供されます。たとえば、パーティション・キー0xa001
を持つInfiniBandポート1が新しいネットワーク・インタフェースになります。これらのインタフェースには、ifcfg-<interface>
ファイル・パラメータによって意味のある名前が付けられます。
1つのInfiniBandノードを複数のパーティションのメンバーにできます。パケットがデータベース・ノードに到着すると、パケットのパーティション・キー(pkey)がサブネット・マネージャ構成と照合されます。この検証により、データベース・ノードが、それがメンバーになっているパーティションの外部の別のデータベース・ノードと通信できなくなります。
InfiniBandファブリック内のすべてのノードには、/sys/class/infiniband/mlx4_0/ports/[1-2]/pkeys
で確認できるパーティション・キーの表があります。ノードのそれぞれのキュー・ペア(QP)には、その表の1つのエントリにマッピングされる索引(pkey)が関連付けられています。QPの送信キューからパケットが送信される場合は、索引付きのpkeyが添付されます。QPの受信キューでパケットを受信した場合は、索引付きのpkeyが受信パケットのものと比較されます。一致しない場合、パケットは警告なしで破棄されます。受信チャネル・アダプタはその到着を認識せず、同様に送信チャネル・アダプタも受信確認を取得しません。送信済パケットは単に失われたパケットとして示されます。受信パケットのpkeyがQPの受信キューの索引付きのpkeyと一致した場合にのみ、ハンドシェイクが行われてパケットが受け入れられ、送信チャネル・アダプタに確認が送信されます。このようにして、同じパーティションのメンバーのみが相互に通信でき、そのパーティションのメンバーではないホスト(つまり、パーティション表にそのpkeyを持たないホスト)とは通信できないようになっています。
次のステップで、2016年10月の12.1.0.2データベース・バンドル・パッチが適用されたpkey対応環境でこの拡張機能を設定する方法について説明します。次で説明するように、考えられるシナリオは2つあります。
ケース1.ローリング形式によるpkey対応環境での機能の実装
このケースでは、すでに2016年10月の12.1.0.2データベース・バンドル・パッチを適用しています。
次のステップを、1回に1つのノードに実行します。
-
ノードでグリッド・インフラストラクチャを停止します。
# $GI_HOME/bin/crsctl stop crs
-
このユーザー・ドメインのOVM RACクラスタ・ノードを管理するdom0 (制御ドメイン)の2つのポートのGUIDを特定します。
# /usr/sbin/ibstat | grep Port
-
SMマスターがrootとして実行されているInfiniBandスイッチにログインします。
-
InfiniBandスイッチで次のコマンドを実行します。
# /usr/local/sbin/smpartition start # /usr/local/sbin/smpartition modify -n <storage pkey name> -port <Port GUID1 of the dom0 from step 2> -m limited # /usr/local/sbin/smpartition modify -n <storage pkey name> -port <Port GUID2 of the dom0 from step 2> -m limited # /usr/local/sbin/smpartition commit
-
dom0のこのOVM RACユーザー・ドメイン・ノードの
vm.cfg
ファイルを変更します。-
rootとしてdom0にログインします。
-
/EXAVMIMAGES/GuestImages/<user domain name>/vm.cfg
を編集して、次の例に示すようにパーティション・キーを変更します。次の行を変更します。
ib_pkeys = [{'pf':'40:00.0','port':'1','pkey':[ '0xclpkey','0x<stpkey>',]},{'pf':'40:00.0','port':'2','pkey':[ '0xclpkey','0x<stpkey>',]},]
次のように変更します。
ib_pkeys = [{'pf':'40:00.0','port':'1','pkey':[ '0xclpkey','0x<mod_stpkey>',]},{'pf':'40:00.0','port':'2','pkey':[ '0xclpkey','0x<mod_stpkey>',]},]
<mod_stpkey>
は、次の式を使用して<stpkey>
から導出されます。mod_stpkey=$(echo "obase=16;ibase=2;$(expr $(echo "obase=2;ibase=16;$(echo $stpkey|tr [:lower:] [:upper:])"|bc) - 1000000000000000)"|bc|tr [:upper:] [:lower:])
前述の式の
<stpkey>
と<mod_stpkey>
は、0x
の接頭辞なしで指定されています。
-
-
ユーザー・ドメインのRACノードの
/etc/sysconfig/network-scripts/ifcfg-stib*
ファイルを変更します。次の式を使用して、これらのファイルのPKEY_IDを編集します。
mod_stpkey=$(echo "obase=16;ibase=2;$(expr $(echo "obase=2;ibase=16;$(echo $stpkey|tr [:lower:] [:upper:])"|bc) - 1000000000000000)"|bc|tr [:upper:] [:lower:])
mod_stpkeyが新しいPKEY_IDで、stpkeyが古いPKEY_IDです。
前述の式の
<stpkey>
と<mod_stpkey>
は、0x
の接頭辞なしで指定されています。 -
ユーザー・ドメインのRACノードの
/opt/oracle.cellos/pkey.conf
を変更します。ストレージ・ネットワークpkeyインタフェース(stib*)のPkeyを編集します。
変更前:
<Pkey>0xstpkey</Pkey>
変更後:
<Pkey>0xmod_stpkey</Pkey>
mod_stpkeyは、次の式を使用してstpkeyから導出されます。
mod_stpkey=$(echo "obase=16;ibase=2;$(expr $(echo "obase=2;ibase=16;$(echo $stpkey|tr [:lower:] [:upper:])"|bc) - 1000000000000000)"|bc|tr [:upper:] [:lower:])
前述の式で使用されている
stpkey
とmod_stpkey
は、0x
の接頭辞なしで指定されています。 -
OVM RACユーザー・ドメイン・ノードを再起動します。
-
rootとしてdom0にログインします。
-
次のコマンドを実行します。
# xm shutdown <user domain name> # xm create /EXAVMIMAGES/GuestImages/<user domain name>/vm.cfg
-
-
クラスタ・ノードでGrid Infrastructureスタックが完全に稼働していることを確認します。
-
残りのクラスタ・ノードに対して、1回に1つのノードでこのステップを繰り返します。
ケース2.ローリング形式による2016年10月の12.1.0.2データベース・バンドル・パッチの適用中のpkey対応環境での機能の実装
次のステップを、1回に1つのノードに実行します。
-
クラスタ・ノードで2016年10月の12.1.0.2データベース・バンドル・パッチを適用します。
-
パッチが適用されたノードで前述のケース1のステップ1から10を繰り返します。
-
次のクラスタ・ノードに進み、前述のステップ1および2を繰り返します。
ノート:
dom0のGUIDが制限されたメンバーシップに変換された後、すべての新しいクラスタのデプロイメントには、2016年10月のデータベース・バンドル・パッチが前提条件として含められるようになります。
5.25 Oracle VM環境でのOracle EXAchkの実行
Exadata Database Machineでの仮想化は、Oracle EXAchkバージョン12.1.0.2.2以降でサポートされています。
Exadata Database Machine Oracle VM環境でOracle EXAchk監査チェックの完全なセットを実行するには、Oracle EXAchkをインストールして、次のように複数の場所から実行する必要があります。
-
1つの管理ドメイン(dom0)から
-
Oracle VM Oracle Real Application Clusters (Oracle RAC)クラスタごとに1つのユーザー・ドメイン(domU)から
たとえば、4つのOracle VM Oracle RACクラスタを含む2つのデータベース・サーバー(両方のデータベース・サーバーで合計8つのdomU、クラスタごとに2つのノード)を搭載しているExadata Database Machineクオータ・ラックでは、次のようにOracle EXAchkを個別に5回実行する必要があります。
-
最初のクラスタの最初のユーザー・ドメイン(domU)でOracle EXAchkを実行します。
-
2番目のクラスタの最初のユーザー・ドメイン(domU)でOracle EXAchkを実行します。
-
3番目のクラスタの最初のユーザー・ドメイン(domU)でOracle EXAchkを実行します。
-
4番目のクラスタの最初のユーザー・ドメイン(domU)でOracle EXAchkを実行します。
-
最初の管理ドメイン(dom0)でOracle EXAchkを実行します。
Oracle EXAchkによって実行される監査チェックは、次の表に指定されています。
表5-6 Oracle EXAchkによって実行される監査チェック
Oracle EXAchkのインストールおよび実行先 | 実行される監査チェック |
---|---|
管理ドメイン(dom0) |
ハードウェアおよびオペレーティング・システム・レベルのチェック対象:
|
ユーザー・ドメイン(domU) |
ユーザー・ドメインのオペレーティング・システム・レベル・チェックおよびOracle Grid InfrastructureおよびOracle Databaseのチェック |
Oracle EXAchkコマンドラインのオプション
Oracle EXAchkには、専用のコマンドライン・オプションが不要です。Exadata Database Machine Oracle VM環境で実行されていることと、管理ドメインとユーザー・ドメインのどちらで実行されているのかを自動的に検出し、適用可能な監査チェックを実行します。たとえば、最も簡単なケースとして、コマンドライン・オプションなしでOracle EXAchkを実行できます。
./exachk
管理ドメインでOracle EXAchkを実行すると、RDMAネットワーク・ファブリックからアクセス可能なすべてのデータベース・サーバー、ストレージ・サーバーおよびRDMAネットワーク・ファブリック・スイッチで監査チェックが実行されます。
サーバーまたはスイッチのサブセットでOracle EXAchkを実行するには、次のコマンドライン・オプションを使用します。
表5-7 Oracle EXAchkのコマンドライン・オプション
オプション | 説明 |
---|---|
|
データベース・サーバーのカンマ区切りリストを指定します。 |
|
ストレージ・サーバーのカンマ区切りリストを指定します。 |
|
RDMAネットワーク・ファブリック・スイッチのカンマ区切りリストを指定します。 |
たとえば、Exadata Database Machineフル・ラックの最初のクオータ・ラックのみが仮想化用に構成されているとしても、RDMAネットワーク・ファブリック経由ですべてのコンポーネントにアクセス可能ならば、データベース・サーバーdm01adm01
から次のようなコマンドを実行できます。
./exachk -clusternodes dm01adm01,dm01adm02
-cells dm01celadm01,dm01celadm02,dm01celadm03
-ibswitches dm01swibs0,dm01sw-iba0,dm01sw-ibb0