PowerPoint プレゼンテーション

(1)

Oracle ExadataとOVM

ベスト・プラクティスの概要

(2)

学習内容

➢

ユースケース

➢

Exadata OVMソフトウェアの要件

➢

Exadataの分離に関する考慮事項

➢

Exadata OVMのサイズ設定および前提条件

➢

Exadata OVMデプロイメントの概要

➢

Exadata OVMの管理および運用のライフ・サイクル

➢

移行、

HA、バックアップ/リストア、アップグレード/パッチ適用

➢

監視、リソース管理

(3)

Exadata Virtual Machine

仮想化された高パフォーマンスのデータベース・

プラットフォーム

• VMは、統合ワークロードのため、CPU、メモリ、OS、sysadminの

分離を提供

–

ホスティング、クラウド、部門間統合、テスト

/開発、データベー

ス以外またはサード・パーティのアプリケーション

• Exadata VMは、ほぼ本来のハードウェア・パフォーマンスを提供

–

I/Oはハイパーバイザーをバイパスし、高速InfiniBandに直行

• ExadataネットワークおよびI/O優先順位付けと組み合わせて独自

のフル・スタック分離を実現

追加コストなし

X7-2、X6-2、X5-2

X4-2、X3-2、X2-2

DB 11.2および12c

Or acl e D atab ase In -Me

財務

営業

(4)

Exadataの統合オプション

1台のサーバーに

多数の

DB

Database 12cマル

チテナント

仮想マシン

専用の

DB

サーバー

• VMは分離性が高いが、効率が低く管理の負担大

–

VMは独立したOS、メモリ、CPUを使用。パッチ適用も独立

–

DBA、システム管理者に頼る必要のない分離

• 単一

OSでのデータベース統合は高効率だが分離性

が低い

–

DB Resourceマネージャの分離は追加のオーバーヘッドなし

–

リソースの共有がより動的に可能

–

ただし、システムを正しく構成するよう管理者に頼る必要あり

• 最良の戦略は、データベースのネイティブ統合と

VMと

の組み合わせ

–

VM内に複数の信頼済みDBまたはプラガブルDB

–

サーバーあたりの

VM数を抑え、CPU/メモリ/パッチ適用の断

片化によるオーバーヘッドを抑制

VM

分離性がよ

り

高い

効率性がよ

り

高い

(5)

データベース・サーバー：ベア・メタル

/物理とOVMの比較

ソフトウェア・アーキテクチャの比較

OVMデータベース・サーバー

dom0

Exadata（Linux、

Xen、fw）

domU-3

ベア・メタル

/物理データ

ベース・サーバー

Oracle GI/DB

ホーム

Exadata（Linux）

Oracle GI/DBホーム

Exadata（Linux、fw）

domU-2

Oracle GI/DB

ホーム

Exadata（Linux）

Oracle GI/DB

ホーム

Exadata（Linux）

domU-1

(6)

物理マシンと

OVMのおもな違い

• 詳しくは以降のスライドで紹介

トピック

OVMが物理マシンと違う点

ハードウェア・サポート

2ソケットのみ

クラスタ構成

システムは

1つ以上のVMクラスタで構成。各クラスタは個別のGI/RAC/DBをインストール

Exadataストレージ構成

各

VMクラスタに独立したグリッドディスク/DATA/RECO。DBFSディスク・グループなし。

Dbnodeディスク構成

VMのファイルシステム・サイズは小。GI/DBで独立したファイルシステム。

ソフトウェア・アップデート

Dbnodesはdom0（Linux+fw）およびdomU（Linux）の独立したpatchmgrアップデートが必要

Exachk

dom0/cells/ibswitchesに対し1回実行。VMクラスタごとに1回実行

(7)

Exadata VMの用途

• Exadata上のVMはデータベースの統合にフォーカス

• Exadata VMは、Oracle Linuxの認定済みバージョンでのみ実行可能

–

Windows、RedHat、およびその他のゲスト・オペレーティング・システムには非対応

• 利便性向上のため、他の軽量製品の仮想化に

Exadata VMを使用可能

–

例：軽量アプリ、管理ツール、

ETLツール、セキュリティ・ツールなど

• Exadata VMは重いアプリケーションには非推奨

–

例：

E-business SuiteまたはSAPアプリケーション層

(8)

Exadata OVMの要件

• ハードウェア要件

–

Exadata X7-2、X6-2、X5-2、X4-2、X3-2、X2-2をサポート

• ソフトウェア要件

–

Exadata ソフトウェア12.1.2.2.0以降

• 付属ソフトウェア（

patchmgrでアップデート。MOS 888828.1参照）

–

domUおよびdom0が物理マシンと同じUEK kernelを実行（4.1.12-94.6.6.el6uek（ueknano）for

18.1.0.0.0）

–

domUが物理マシンと同じOracle Linux（OL）を実行（OL 6.9 for 18.1.0.0.0）

–

dom0がOracle VM Server（OVS） 3.x （OVS 3.4.3 for 18.1.0.0.0）を実行

–

Grid Infrastructure /データベース

(9)

Exadata のセキュリティ上の分離に関する考慮事項

• VM RACクラスタはそれぞれ、自身のためのExadataグリッド・ディスクとASMディスク・

グループを保持

–

Oracle Exadata Storage ServerにOracle ASM-Scoped Securityをセットアップ

• クライアントおよび管理イーサネット・ネットワーク向けに

802.1Q VLANタギング

–

デプロイ時に

OEDAとともにDbnodeを構成（デプロイ前にスイッチの構成が必要）

–

または、デプロイ後に手動で構成

• クライアント・ネットワーク－

MOS 2018550.1

管理ネットワーク－

MOS 2090345.1

• InfiniBand partitioning（Exadata Private Network用にPKEYを使用）

–

デプロイ時に

OSおよびInfiniBandスイッチをOEDAとともに構成

(10)

Exadata OVMのサイズ設定に関する推奨事項

• Reference Architecture Sizing Toolを使用し、データベースごとに必要なCPU、メモリ、

ディスク領域を決定

–

OEDAが希望のVM構成を自動化された簡単な方法でデプロイするため、デプロイ前にサイズ設

定の評価が必要。

–

変更はデプロイ後も可能だが、より多くの手順が必要

–

DOM0およびVMごとの追加のシステム・リソースの場合を除き、サイズ設定の方法は実際

には変わらず

–

サイズ設定ツールは現在、仮想システムのサイズは設定しない

• Dom0は自動的にサイズ設定（2コア/4 vCPU、8 GB－変更

しない

でください）

–

Dom0 vCPU 割当てはVM間で共有。Dom0が通常使用するvCPUは4個未満、ただしシステム・

ワークロードに応じて最大

4個のvCPUを使用可

(11)

メモリサイズ設定の推奨事項

• 物理メモリを過剰にプロビジョニングしない

–

全

VMとdom0が使用するメモリの合計が物理メモリを超えることはできない

–

現状と今後のメモリ使用をふまえ

dom0に48 GBを設定（現状に8 GB、今後に40 GB）

• 初期データベースに加え、

OS、Java、GI/ASMなどをサポートするためVMごとに最低16 GB必要

–

より大きなデータベースまたは追加データベース（

DBプロセス、PGA、SGA）向けにVMメモリを増加

• 1 VMあたり最大720 GB（メモリを拡張したX6-2/X7-2）

• VMメモリはオンラインでは変更不可（バルーニングなし）。メモリのサイズ変更は再起動が必要

• OEDA VMテンプレートのデフォルト（構成時に調整可能）

–

小－

16 GB、中－32 GB、大–64 GB

(12)

CPUサイズ設定の推奨事項

• CPUのオーバープロビジョニングが可能

–

ただし、すべての

VMがフルにアクティブになった場合、

ワークロード・パフォーマンスの競合が生じる可能性あり

–

Dom0は2コアを割当て（vCPU x 4）

• 1 VMあたりの最小数は1コア（vCPU x 2）

–

1 vCPU==1ハイパースレッド、1コア==2ハイパースレッド==2 vCPU

• 1 VMあたりの最大数は、dom0に割当てのコア数から2を引く

–

例：

X7-2での最大数は、1 VMにつき46コア（dom0の計48から2を引く）

• VMに割り当てるvCPUの数はオンラインで変更可能

• OEDA VMテンプレートのデフォルト（構成時に調整可能）

(13)

ローカル・ディスクのサイズ設定における推奨事項

• VMの総ローカル・ディスク領域は1.6 TB（X4以降）。ディスク拡張キットの使用で3.7 TB

• デプロイ時に各

VMで使用されるディスク領域は、OEDAで選択したVMサイズに依存

–

小

190 GB、中 210 GB、大 230 GB（OEDAで選択可能。ただし、調整不可）

• 70 GB システム（root sys1/sys2、スワップ）

• 100 GB ソフトウェア・ホーム（50 GB GIhome、50 GB DBhome）

• ユーザー

/u01－小テンプレート 20 GB、中テンプレート 40 GB、大テンプレート 60 GB

–

最初に実際に割り当てられる

domUディスク・イメージの領域は、スパース・ファイルおよび共有可能な参照リンク

が理由で大幅に少なくなっているが、

domUの使用とともに共有領域が分岐し、スパース・ファイル領域が少なくな

るため拡大

• ディスクのオーバープロビジョニングは、

dom0領域がなくなった場合、VM内部で予測不能な領域不足エラーにつながる可能性あり

• VMバックアップのリストアにより、節約した領域が減少（削除の可能性）。オーバープロビジョニングに頼ると、完全なVMリストアが妨げられる

可能性あり

• 長期稼働

/本番用VMには領域をフルに割り当てるべき（スパース・ファイルおよび共有可能な参照リンクの恩恵がないと想定）

• 短期稼働のテスト

/開発VMには、100 GBの割当てを想定

(14)

データベース・サーバーのディスク拡張

• 2ソケットのデータベース・サーバーには8つのディスク・ベイがあり、

出荷時は

4箇所だけ使用

• 仮想マシンは、データベース・サーバー上により多くのストレージが必要

• X7-2、X6-2、X5-2データベース・サーバーが8 x 600 GB HDDをサポート

–

4ドライブまたは8ドライブの構成のみをサポート

–

サーバーは

4ドライブのみで出荷。使用場所でさらに4ドライブ追加可能

(15)

Exadataストレージの推奨事項

• 初期

VMクラスタにおけるDATA/RECOのサイズは、その後のVM追加を考慮するべき

–

最初にすべての領域を使用してしまうと、新規

DATA/RECOの追加前に既存のものを縮小する必要あり

• すべてのセルのすべてのディスクにまたがって各

VMクラスタのDATA/RECOを拡張

–

DBFSディスク・グループなし

• ASM-Scoped Securityを有効化して、グリッド・ディスク・アクセスを制限

VM クラスタクラスタ・ノードグリッド・ディスク（全セルのすべてのディスク上の全クラスタ用DATA/RECO）

clu1

db01vm01

db02vm01

DATAC1_CD_{00..11}_cel01 RECOC1_CD_{00..11}_cel01

DATAC1_CD_{00..11}_cel02 RECOC1_CD_{00..11}_cel02

DATAC1_CD_{00..11}_cel03 RECOC1_CD_{00..11}_cel03

(16)

ハードウェア

X2-2

X3-2

X4-2

X5-2

X6-2

X7-2

メモ

リ

ノードあたりの物理容量

（デフォルト

/最大）

72 GB

144 GB

256 GB

512 GB

256 GB

512 GB

256 GB

768 GB

256 GB

1.5 TB

384 GB

1.5 TB

domUあたり最小

最小

16 GB+追加のDBまたはアプリ用メモリ

domUあたり最大

96 GB

464 GB

720 GB

OEDAテンプレートのデフォルト

小

–16 GB、中–32 GB、大–64 GB（構成時に調整可能）

CPU*

ノードあたりのコア数

*

12

16

24

36

44

48 VMあたりの最小

1コア（vCPU x 2）

VMあたり最大

コア数から

2を引く（dom0は2コア/4 vCPUを割当て）

OEDAテンプレートのデフォルト

小－

2コア、中－4コア、大－8コア（構成時に調整可能）

デ

ィスク

全

domUにおけるノードあたりの総利用

可能ディスク領域

700 GB

1.6 TB

1.6 TB（DB Storage Expansion Kit使用の場合

3.7 TB）

デプロイ時の使用ディスク（

1 domUあた

り）

（

OEDAテンプレートがベース）

小

190 GB、中 210 GB、大 230 GB（構成時には調整不可）

最初に実際に割り当てられる

domUディスク・イメージの領域は、スパース・ファイルおよび共有

可能な参照リンクが理由で大幅に少なくなっているが、

domUの使用とともに共有領域が分岐し、

デプロイメントの仕様および制約

(17)

デプロイメントの概要

• OEDAはExadata上にVMを作成するために使用する唯一のツールです。

1. OEDA Configuration Toolを使用して構成を作成

2. OEDAデプロイメントのためのカスタマー環境を準備

–

DNSを構成、VLANのためスイッチを構成（必要な場合）

3. OEDAデプロイメントのためExadataシステムを準備

–

switch_to_ovm.sh、reclaimdisks.sh、applyElasticConfig.sh

4. OEDA Deployment Toolでシステムをデプロイ

(18)

OEDA構成ツール

高度なネットワーク構成

• イーサネット・ネットワーク

802.1Q

VLANタギング

–

OVMの場合、VM固有のVLAN IDを

クラスタ構成ページ（後述）で定義

–

イーサネット・スイッチ（カスタマーおよび

Cisco）

は、

OEDAデプロイの前にVLANタグ構成を行う

必要あり

• InfiniBand Network Partitioning

（

PKEYS使用）

(19)

OEDA構成ツール

ノードの識別

• OVMか物理マシンかを決定する

ためのスクリーニング

–

すべて

OVM

–

すべて物理マシン

–

一部

OVM、一部物理マシン

(20)

OEDA構成ツール

クラスタの定義

• 決定事項

–

作成する

VMクラスタ数

–

VMクラスタを構成する

Dbnodeおよびセル

• すべてのセルの使用を推奨

• 「

VMクラスタ」とは？

–

Oracle GI/RACを実行し、それぞれ

が同じ共有

Exadataストレージ

（

ASMが管理）にアクセスする、異

なるデータベース・サーバー上の

1つ以上のユーザー・ドメイン

(21)

OEDA構成ツール

クラスタの構成

• VMクラスタはそれぞれ専用の

構成ページあり

–

VMのサイズ（メモリ、CPU）

–

Exadataソフトウェアのバージョン

–

ネットワークの構成

–

OSのユーザーとグループ

–

GI/DBのバージョンと場所

–

初期データベースの構成

(22)

OEDA構成ツール

クラスタの構成

• 仮想ゲストのサイズ

–

デプロイ時に構成される

CPUとメモ

リを定義

–

デフォルトを変更して調整

–

1 vCPU==1ハイパースレッド

–

1コア==2ハイパースレッド==2 vCPU

–

/u01の“ローカル・ディスク”サイズは固定

• 小

20 GB、中 40 GB、大 60 GB

• GI/DBホームは独立したfs（/u01とは別）

(23)

OEDA構成ツール

クラスタの構成

• 各

VMにインストールされたグリッド・

インフラストラクチャ（

VMクラスタが

「所有する」グリッド・ディスク）

–

クラスタ

1－DATAC1 / RECOC1

（すべてのセルに展開）

–

クラスタ

2－DATAC2 / RECOC2

（すべてのセルに展開）

–

サイズ設定時に今後のクラスタを考慮

–

DBFSは構成されない

–

ASM-Scoped Securityにより、クラスタは自身

(24)

OEDA構成ツール

クラスタの高度なネットワーク構成

• イーサネット

VLAN IDおよびIPの詳細

–

複数

VMにまたがったイーサネット・トラフィックを分ける

ため、各クラスタについて個別の

VLAN IDとIPを使用

• InfiniBand PKEYおよびIPの詳細

–

通常は

OEDAのデフォルトを使用するだけ

–

コンピューティング・クラスタ・ネットワーク（

dbnode間のRACトラ

フィック用）。各クラスタについて、個別の

Cluster PKEYとIPサブ

ネットを使用して

IBトラフィックを分離

–

ストレージ・ネットワーク（

dbnode－セル間またはセル－セル

間のトラフィック用。すべてのクラスタに同じ

PKEY/サブネット）

(25)

OEDA構成ツール

「

Review and Edit」

• このページは、すべての

VMクラス

タにおける各

VMゲストのネットワー

(26)

OEDA構成ツール

「

Installation Template」

• 「

Installation Template」

ですべての

VMクラスタ

について適切な設定を

確認し、デプロイ前に

環境（

DNS、スイッチ、

VLANなど）が正しく構

成されるようにする

(27)

OEDA構成ツール

ネットワークの要件

構成要素

ドメイン

ネットワーク

ホスト名の例

データベース・サーバー

dom0

Mgmt eth0

dm01dbadm01

（データベース・サーバー

ごとに

1つ）

Mgmt ILOM

dm01dbadm01-ilom

Mgmt eth0

dm01dbadm01vm01

domU

Client bondeth0

dm01client01vm01

（データベース・サーバー

Client VIP

dm01client01vm01-vip

ごとに

1つ以上）

_{Client SCAN}

_{dm01vm01-scan}

Private ib

dm01dbadm01vm01-priv1

(28)

Exadata OVMの基本的なメンテナンス

• 『

Exadata Database Maintenance Guide:Managing Oracle VM

Domains on Oracle Exadata Database Machine』を参照

–

実行中ドメインの表示、監視、起動、シャットダウン

–

ユーザー・ドメイン自動スタートの無効化

–

ユーザー・ドメインのメモリ、

CPU、ローカル・ディスク領域を修正

–

RAC VMクラスタの削除/作成

–

Oracle RAC VMクラスタの拡張

–

Grid Infrastructureなしのユーザー・ドメインを作成（例：App VM）

–

ユーザー・ドメインを別のデータベース・サーバーに移動

(29)

Exadata OVMの基本的なメンテナンス

–

Oracle VMユーザー・ドメイン上のOracleデータベースのバックアップとリストア

–

Oracle VM Oracle RACクラスタの作成

–

アプリ用に

GIおよびデータベースのないOracle VMの作成

–

Oracle VMにおいてOracle RACノードを追加またはドロップ

–

データベース・サーバーのディスク拡張後、ユーザー・ドメインの

/EXAVMIMAGESを拡張

–

タグ付けされた

VLANインタフェースの実装

–

Oracle Exadata上のOVM RACクラスタ全体にInfiniBand Partitioningを実装

–

Oracle Virtual Serverデプロイメントに管理ドメイン（dom0）

およびユーザー・ドメイン（

domU）のバックアップを作成

(30)

OEDACLIによるメンテナンス操作の実行

• OEDAコマンドライン oedacli（Doc ID 2293678.1）

–

OEDA August 2017にて初めてリリース－最新/最良の状態にするため常に最新版を使用すること

–

デプロイに使用する、元の

OEDA構成/XMLファイルに依存

• VMによるデプロイ後の操作をサポート（2017年9月時点）

–

ノードの追加

/削除

–

データベースの追加

/削除

–

データベース・ホームの追加

/削除

–

ストレージ・セルの追加

/削除

–

ASMディスク・グループのサイズ変更

–

Oracle Clusterware 12.1.0.2を12.2.0.1にアップグレード

(31)

Exadata OVMの移行

• 物理マシンから仮想マシンに変更する動的またはオンラインの方法

–

Data Guardまたはバックアップをデータベースの移動に使用可能－最小の停止時間

–

1つのノードまたはノードのサブセットを一度に仮想ノードに変換

• 仮想マシンの使用には既存の

Exadata物理ラックの移行が必要

–

既存のデータベースのバックアップを作成し、既存のハードウェアを

OEDAで再デプロイし、

その後データベースをリストア

–

既存の

Exadata OVM構成にデータベースを複製

–

ソースから新しいターゲットに移動する場合、標準的な

Exadata移行プラクティスを適用可能。

『

Best Practices for Migrating to Exadata Database Machine

』参照

(32)

Exadata OVMの移行

• 以下のいずれかの手順を使用し、物理マシンを仮想マシンに

変更する動的またはオンラインの方法

–

既存のベア・メタル

Oracle RACクラスタを使用し、停止時間ゼロでOVM RACクラスタに移行

–

新規

OVM RACクラスタの作成により、最小の停止時間でOVM RACクラスタに移行

–

Oracle Data Guardの使用により、最小の停止時間でOVM RACクラスタに移行

–

RMANのバックアップとリストアの使用により、完全な停止時間を費やしてOVM RACクラスタに移行

(33)

仮想化された環境のバックアップ

/リストア

• Dom0－外部への標準的なバックアップ/リストアのプラクティス

• DomU－2種類の方法

–

Dom0からのバックアップ：VMイメージのスナップショットを作成し、スナップショットを外部にバックアップ

–

DomUからのバックアップ：標準的なOSのバックアップ/リストアのプラクティスを適用

–

ローカル・ディスク領域をオーバープロビジョニングした場合－

VMバックアップのリストアにより、節約した

領域が減少（削除の可能性）。オーバープロビジョニングに頼ると、完全な

VMリストアが妨げられる可能性あり

• データベースのバックアップ

/リストア：

Exadata

または

ZFS

ストレージに対し、

標準的な

Exadata MAAバックアップ/リストアのプラクティスを適用可能

• Exadata Maintenance Guideを参照

–

『

Backing up the Management Domain (dom0) and User Domains (domU) in an Oracle Virtual Server Deployment

』

–

『

Recovering in an Oracle Virtual Server Deployment

』

(34)

ソフトウェアの更新

更新する構成要素方法

ストレージ・

サーバー

物理マシンと同じ－すべてのセルに対し

sshアクセスで任意のサーバーからpatchmgrを実行。また

は

Storage Server Cloud Scale Software Update機能（18.1以降）を使用

InfiniBand

スイッチ

物理マシンと同じ－すべてのスイッチに対し

sshアクセスでdom0からpatchmgrを実

行

データベース・

サーバー－

dom0

すべての

dom0に対しsshアクセスで任意のサーバーからpatchmgrを実行。Dom0更新によりデータベース・

サーバーのファームウェアをアップグレード。

Dom0のリブートには、すべてのローカルdomUの再起動が必

要。

DomUソフトウェアはdom0の更新中は更新されない。dom0/domUは同じバージョンを実行する必要な

し。ただし、特定の順序で更新が必要な場合あり（

888828.1参照）

データベース・

サーバー－

domU

すべての

domUに対しsshアクセスで任意のサーバーからpatchmgrを実行。通常、VMクラスタ単位で実行

（例：すべてのノードの

vm01に実行、次にvm02…）、または、1つのサーバー上のすべてのVMを次のサー

バーに進む前に更新

(35)

ヘルス・チェックと監視

• Dom0とDomUでExachkを実行（セルとIBスイッチのチェックをDom0で実行）

–

すべての

dom0、セル、スイッチのために1つのdom0で実行

–

各

VMクラスタのすべてのdomU、GI/DBを対象に、そのクラスタの1つのdomUで実行

• EM Monitoringのサポート（MOS 1967701.1）

–

EM Framework 12.1.0.4（12.1.0.5を推奨）、Exadata Plugin 12.1.0.6、VI Plugin 12.1.0.1が必要

• Dom0およびDomUでExawatcherを実行

• データベース

/GIの監視プラクティスを適用可能

• 考慮事項

–

Dom0固有のユーティリティ（xmtop）

(36)

Exadata MAA/HA

• Exadata MAA障害/修復プラクティスを適用可能。

『

MAA Best Practices for Oracle Exadata Database Machine

』を参照

• OVM Live Migrationは非サポート－RACを使用し、

(37)

リソース管理

• Exadata Resource Managementプラクティスを適用可能

–

Exadata IOおよびフラッシュのリソース管理はすべて適用可能かつ有用

• VM内およびクラスタ内で、データベース・リソース管理プラクティスが適用可能

–

VM内の複数データベースについて、CPU数はデータベースのインスタンス・レベルで設定する必要あり。

推奨は

2以上

• ローカル・ディスクのリソース管理および優先順位付けは無し

–

IOの多いワークロードではローカル・ディスクの使用を避けるべき

–

より高いパフォーマンスと帯域幅のため、

ExadataまたはNFS上でACFSまたはDBFSを使用

• Exadataセルを共有するすべてのデータベースに一意のDB_UNIQUE_NAMEが必要

（異なるクラスタにまたがる場合も含む）。

(38)

(39)