ExaDB-Dを検証してみた！！

2023年6月27日 Infrastructure(IaaS)

1 はじめに
- 1.1 ExaDB-Dとは
- 1.2 ３つのポイント
2 ご紹介内容
3 さいごに

はじめに

みなさん、こんにちは。
Oracle Cloud Infrastructure検証チームです。

今回は、Oracle Cloud Infrastructure(OCI)のExadata Database Service on Dedicated Infrastructure(略称 ExaDB-D)を検証してみましたので、ご紹介したいと思います。

本記事執筆者の過去記事【OCI ストレージ・ゲートウェイ・サービスを使ってみた】も是非ご覧下さいね。

ExaDB-Dとは

ExaDB-Dとは、アプライアンス製品として提供されるExadataをパブリック・クラウド上で利用できるサービスとなります。

Exadataの高い可用性と高いパフォーマンスを発揮でき、クラウドならではの柔軟な価格体系となっています。
HW占有型のサービスですが、HW基盤の管理はオラクル社となっており、ユーザのインフラ管理の負担を減らすことができます。

３つのポイント

Exadataの占有環境

ミッションクリティカル基盤で圧倒的な実績を誇るExadata専有環境をサブスクリプションで利用可能

柔軟な価格体系

CPUリソースは柔軟に増減可能(秒単位課金)
HW/SW/サポート全て込み
全てのオプション機能が使い放題

インフラ管理の軽減

Exadata HW基盤の管理は全てオラクル社

類似のサービスであるOracle Base Database Service(略称 BaseDB)は、1つのクラスタ上に1つのデータベースのみ稼働できるという制限がありますが、ExaDB-Dは複数のデータベースを作成することができます。
システム内で多くのデータベースをクラウド上で管理する場合、ExaDB-Dを選択肢の１つとして考えて頂くと良いと思います。

ご紹介内容

今回ご紹介する内容はこちらです。

VCNの準備
Exadata Infrastructureの作成
Exadata VMクラスタの作成
データベースの作成
バックアップについて
パッチの適用について
メンテナンスについて

１．VCNの準備

ExaDB-Dではクライアント・サブネットとバックアップ・サブネットの２つのサブネットが必要となります。

クライアント・サブネットは、クライアントからのDB接続を行う際に利用するサービス・ネットワークです。
バックアップ・サブネットは、オブジェクトストレージへのバックアップに利用するネットワークです。

それぞれのサブネット必要な通信要件(セキュリティ・ルール)をまとめました。

クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール

ルール	内容	ソースタイプ/ 宛先タイプ	CIDR	IPプロトコル	詳細①	詳細②
イングレス①	任意の場所からのSSHトラフィックを許可する	CIDR	0.0.0.0/0	SSH	ソース・ポート範囲：すべて	宛先ポート範囲：22
イングレス②	Path MTU Discovery断片化メッセージを許可する	CIDR	0.0.0.0/0	ICMP	タイプ: 3	コード: 4
イングレス③	VCN内の接続エラー・メッセージを許可する	CIDR	VCNのCIDR	ICMP	タイプ: 3	コード: 4
エグレス①	すべてのエグレス・トラフィックを許可する	CIDR	0.0.0.0/0	すべて	ー	ー

クライアント・ネットワークに必要なルール

ルール	内容	ソースタイプ/ 宛先タイプ	CIDR	IPプロトコル	詳細①	詳細②
イングレス	クライアント・サブネット内からのONSおよびFANトラフィックを許可する	CIDR	クライアント・サブネットのCIDR	TCP	ソース・ポート範囲: すべて	6200
イングレス	クライアント・サブネット内からのSQL*NETトラフィックを許可する	CIDR	クライアント・サブネットのCIDR	TCP	ソース・ポート範囲: すべて	1521
エグレス	クライアント・サブネット内のすべてのTCPトラフィックを許可する	CIDR	0.0.0.0/0	TCP	ソース・ポート範囲: すべて	22
エグレス	すべてのエグレス・トラフィックを許可する(Oracle YUMリポジトリへの接続の許可)	CIDR	0.0.0.0/0	すべて	ー	ー

バックアップ・ネットワークに必要なルール

ルール	内容	宛先タイプ	宛先サービス	IPプロトコル	宛先ポート範囲
エグレス	オブジェクト・ストレージへのアクセスを許可する	サービス	OCI <利用するregion>オブジェクト・ストレージというサービスCIDRラベル	TCP	443 (HTTPS)

注意：イベント・サービスやモニタリング・サービスを利用する場合、他にも設定が必要になります。

２．Exadata Infrastructureの作成

[Exadata Infrastructureの作成]をクリックします。

入力する項目は以下の通りです。
Exadataインフラストラクチャの基本情報

コンパートメント – 利用するコンパートメントを選択
表示名 – 任意

Exadataクラウド・インフラストラクチャ・モデルの選択

今回は検証時の最新モデル[X9M-2]を選択します。

コンピュートおよびストレージ構成

データベース・サーバー – 最小の2台を選択
ストレージ・サーバー – 最小の3台を選択

今回は、検証目的なので最小構成で作成します。
必要項目を入力後、[Exadata Infrastructureの作成]をクリックすれば、完了です。

注意：画像に表示されているリソース合計のOCPU数やストレージ容量がとても大きいですが、コストに関する部分は次のVMクラスタ作成でしぼりますのでご安心を！

３．Exadata VMクラスタの作成

次にVMクラスタを作成します。
今回のモデルでは、マルチVMおよびVM Cluster Node Subsetting機能が利用できます。

Infrastructureの各DBサーバにVMをホスティングするのではなく、任意の数のVMで新しいVMクラスタをプロビジョニング可能(そして複数のVMクラスタを作成できる)
プロビジョニング時にVMクラスタサイズを小さくして開始することにより、VMごとに割り当てられるリソースのコストを削減

今回はデータベース・サーバーの数が2台のため１は検証できませんが、２によりリソースを絞ってコスト削減を行います。

[Exadata VMクラスタの作成]をクリックします。

入力する項目は以下の通りです。

コンパートメント – 利用するコンパートメントを選択
表示名 – 任意
クラスタ名 – 任意
Exadataインフラストラクチャの選択 – 「作成したInfrastructureの選択」
Oracle Grid Infrastructureのバージョン – 19.0.0.0

VMクラスタの構成

VM当たりのOCPU数 – 2
VM当たりのメモリー(GB) – 30
VM当たりのローカル・ストレージ(GB) – 200

コストに関係しますので、検証時は小さめで作成します。

Exadataストレージの構成

使用可能なExadataストレージ(TB)の指定 – 2

こちらもコストに関係しますので、検証時は小さめで作成します。

ネットワーク設定の構成
最初に用意したクライアント・サブネットとバックアップ・サブネットを選択します。

必要項目を入力したら、[Exadata VMクラスタの作成]をクリックし、作成が開始されます。

入力する項目が多くて、少し大変でしたね。
しかしVMクラスタが作成できれば、ほぼ基盤構築は完了したようなものです。(作成には4時間ほどかかります。)

これが完了すれば、Oracle Grid Infrastructureがインストールされ、クラスタやASMディスク・グループも構成された状態で仮想マシンが作成されます。
ここからは仮想マシンにopcユーザでSSH接続できますので、気になる設定はオンプレミス環境と同じようにコマンドで確認していきましょう。

４．データベースの作成

ExaDB-Dでは異なるバージョンのデータベース・ホームを複数作成することができます。
データベースの作成では、利用するホームを自由に指定することができるため本番環境/開発環境などの用途別でホームを分けて利用するのが良いでしょう。

新規作成するデータベース・ホームを利用する場合、データベース作成時に自動でホーム作成も行われるため、検証では「データベース・ホーム」作成を省きます。

OCIコンソール画面から作成したExadata VMクラスタに移動し、[データベースの作成]をクリックします。

データベースの作成時に設定できる基本項目は以下の通りです。

データベース名
一意のデータベース名　(オプション)
データベースのバージョンPDB名　(オプション)
データベース・ホームの指定　(既存のホームを指定するか新規作成するか選択できます。)
管理者資格証明　(sysのパスワード、TDEウォレットにも使用するかどうか選択)
自動バックアップの設定　(有効/無効、有効の場合はスケジュール)

また拡張オプションの設定として、以下の項目を設定できます。

Oracle SIDの接頭辞 (オプション)
文字セット
外国語文字セット (オプション)
キー管理の構成(Oracle管理キー/顧客管理キーの選択)

設定項目の入力が完了すれば、[データベースの作成]をクリックして作成が開始されます。
ExaDB-DはOSログインが可能なため、作成時に設定した項目以外の詳細設定(初期化パラメータなど)は、オンプレミス環境と同様にコマンドやSQLで行うことができます。データベースの要件に合わせて適宜設定を実施しましょう。

５. バックアップについて

ExaDB-Dにおけるバックアップについてご紹介致します。
ExaDB-Dでは、大きく分けてOS(domU)とDBの２つのバックアップを設計する必要があります。

OSのバックアップ

まずは、OSのバックアップについてご紹介します。
OS領域はOCIコンピュート・インスタンスのブートボリューム領域のことを指します。
ブートボリュームのバックアップは、オラクル社側にて週次で1世代のバックアップを取得しています。
取得タイミングはオラクル社側で管理しているため、ユーザ側で指定することはできません。またリストアに関しても、My Oracle SupportでSRを起票してリストア作業を依頼します。

このことから、自動バックアップの他に、随時での手動バックアップも検討することをお勧めいたします。
パッチの適用前、設定変更の前などメンテナンスに合わせて手動で必要なファイルをバックアップしておくことで、メンテナンス直前の状態にリストアすることが可能です。
クラウド・サービスですが、オンプレミス環境と同様に対象ファイルやディレクトリをtarでアーカイブし、zipで圧縮するバックアップ方式を採用することも可能です。バックアップの保管先などに、クラウド・サービスを利用を検討すると良いと思います！

DBのバックアップ

先程のデータベース作成のときに「自動バックアップの設定」を行いました。

こちらの機能は、OCIのオブジェクト・ストレージにスケジュール通りに自動でバックアップを取得してくれる機能です。
バックアップの内部ではRMANを使用しているため、オンラインで取得されるバックアップとなります。
バックアップの保持期間とバックアップする時間帯を設定するだけで、自動で増分バックアップを取得してくれるのでかなり便利な機能だと思います！

リストアは、OCIコンソールを用いて実施します。

Oracle Database Cloud Backup Module for OCI

自動バックアップ機能では、オラクル管理のオブジェクト・ストレージにバックアップが取得されますが、ユーザ管理のオブジェクト・ストレージにRMANバックアップを取得したい場合、「Oracle Database Cloud Backup Module for OCI」が利用できます。
※詳細はこちらのマニュアルをご参照ください。

この専用モジュールをDBサーバにインストールすることで、オブジェクト・ストレージのユーザ指定のバケットに直接RMANバックアップを取得できるようになります。
メリットとしては、オブジェクト・ストレージのクロスリージョン・レプリケーション機能などを利用して、別リージョンに二次バックアップを取得することができるため、ユーザ側で要件に合わせて設定をカスタマイズしたい場合におすすめです。

自動化したい場合は、オンプレミス環境と同様にRMANバックアップのシェルスクリプトを開発することで実現できます。

６. パッチの適用について

ExaDB-Dではパッチ適用をOCIコンソールから実施することができます。

こちらの画像で[Db System patch]がGrid Infrastructure、[Database Patch]がデータベースのそれぞれのリリース更新パッチ(RU)に該当します。
コンソールから[事前チェック]を実行し、問題がなければ[パッチの適用]をクリックすることでパッチ適用を実施することができます。
パッチの適用は再起動が発生するため、1ノードずつのローリング方式で実施されます。

ExaDB-Dではデータベース・ホームを複数作成できるため、パッチの適用もホーム個別に実施することができます。

RU以外のパッチ

RU以外のパッチとして月次推奨パッチ(MRP)と個別パッチがサポートから提供されており、オンプレミス環境と同様にopatchコマンドで適用することが可能です。
ただし、RU以外のパッチ適用はサポートの指示のもと実施して頂く必要があります。

７. メンテナンスについて

最後にメンテナンスについて紹介します。

定期メンテナンス

ExaDB-Dでは、Exadata InfrastructureとしてHWを占有するため、インフラ層に対する定期メンテナンスが存在します。
安定性・セキュリティを考慮したサービスの提供のために、インフラ層の定期メンテナンスは四半期ごとに必須で行います。
1ノードずつ行われるローリング・メンテナンスを選択することが可能なため、データベースとしてはオンラインで稼働し続ける形になり、ダウンタイムはほぼない形で実施されます。
定期メンテナンスの実施日時はオラクルから予定日時が通知されますが、メンテナンス・スケジューリング機能により事前にメンテナンス実施可能なタイミングを設定することが可能です。