• 検索結果がありません。

PowerPoint プレゼンテーション

N/A
N/A
Protected

Academic year: 2021

シェア "PowerPoint プレゼンテーション"

Copied!
39
0
0

読み込み中.... (全文を見る)

全文

(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

VM

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)

参照

関連したドキュメント

綱伽染均 謝αo阯 硲0晒oo阯鋤4柳 蜘蜘 謝卿

いない」と述べている。(『韓国文学の比較文学的研究』、

サーバー費用は、Amazon Web Services, Inc.が提供しているAmazon Web Servicesのサーバー利用料とな

本資料は Linux サーバー OS 向けプログラム「 ESET Server Security for Linux V8.1 」の機能を紹介した資料です。.. ・ESET File Security

ことで商店の経営は何とか維持されていた。つ まり、飯塚地区の中心商店街に本格的な冬の時 代が訪れるのは、石炭六法が失効し、大店法が

Manila 19,302,901 2,586,589 Davao 1,363,337 182,687 Total 20,666,238 2,769,276..

5.2 5.2 1)従来設備と新規設備の比較(1/3) 1)従来設備と新規設備の比較(1/3) 特定原子力施設

スペイン中高年女性の平均時間は 8.4 時間(標準偏差 0.7)、イタリア中高年女性は 8.3 時間(標準偏差