>> 連載トップページに戻る

 

もしもみなみんがDBをクラウドで動かしてみたら

第4回: 必要な時に必要な分だけ – リソース拡張


著者紹介


南野 英梨子 (みなみの えりこ)

日本オラクルに新卒で入社。以来、Oracle Databaseの製品担当として、主にOracle Maximum Availability Architecture(MAA)に関わる機能や製品を担当。特に好きなのは、Oracle Active Data Guard や Oracle GoldenGate。Oracle Database の魅力やベストプラクティス、そしてそれを簡単に使えるOracle Cloudの魅力をお客様に伝えようと、日々邁進中。


第4回: 必要な時に必要な分だけ – リソース拡張

(本内容は、2017/12時点のOracle Cloud Infrastructure Classic DBCSの情報になります)


クラウドのメリットの一つとして、必要な時に必要な分の利用が可能・簡単に拡張可能という特徴がありますよね。

今回は、Oracle Database Cloud Service(DBCS)を使っている中で、リソースを拡張したいという時にどうやるのかを説明していきます。


■ 1. DBCSのリソース拡張について

DBCSインスタンスのリソースとしては、CPU/メモリ、ストレージがあります。それらに対する拡張(スケーリング)する作業は、サービス・コンソールもしくはREST APIから実施可能です。

まずは、現在のリソースの割り当て状況をService Overviewページで確認しましょう。

①はサービス・インスタンス全体、②はノードごとの状態です。

img-1

サービス・コンソールで実施する場合、対象のサービス・インスタンスの詳細ページで、サービス名もしくはノードの右にあるアイコン>『スケール・アップ/ダウン』をクリックします。

img-2

『サービスのスケール・アップ/ダウン』の画面で、各リソース拡張の内容を設定します。この一画面で拡張作業が完結しちゃうので、とても簡単ですね。

img-3

DBCSにおける拡張でのポイント

  • ・メンテナンスモードになりサービス・インスタンス再起動(今回対象のOracle Cloud Infrastructure Classicの場合)
  • ・拡張による構成変更は自動で設定されるため、再起動する際に手動アタッチは不要
  • ・変更は仮想マシンに対して行われるため、DB関連の設定への自動変更はされない

「DB関連の設定への自動変更はされない」、ということですので、拡張対象のリソースに関係するデータベースのパラメータ(SGA_TARGETやDB_RECOVERY_FILE_DEST_SIZEなど)の変更が必要な場合は、手動で変更しましょう。

では、各リソースの拡張を実行してみましょう。

■2.CPUやメモリの拡張

DBCSは、コンピュート・シェイプというCPU数とメモリの組み合わせから、利用するOCPUとメモリのサイズを選択します。

汎用 ハイメモリ
コンピュート・シェイプ OCPU メモリ コンピュート・シェイプ OCPU メモリ
OC3 1 7.5 GB OC1M 1 15 GB
OC4 2 15 GB OC2M 2 30 GB
OC5 4 30 GB OC3M 4 60 GB
OC6 8 60 GB OC4M 8 120 GB
OC7 16 120 GB OC5M 16 240 GB

参考) マニュアル Oracle Database Cloud Serviceの使用 『計算能力』


そのため、現在のコンピュート・シェイプからCPU数やメモリ数を増やす場合には、このコンピュート・シェイプの変更をします。

①変更後のコンピュート・シェイプを選択して、②『はい、サービスをスケール・アップ/ダウンします』をクリックします。

img-5

ジョブが実行されるとサービスがメンテナンスモードになり、ジョブが完了するとコンピュート・シェイプが変更された仮想マシンが利用可能になりますので、Service Overviewページを更新してリソースの割り当て状況を確認してみてください。

CPUやメモリの拡張についてのポイント

  • コンピュート・シェイプ(OCPU数とメモリ数の組み合わせ)の変更
  • ・スケール・アップもスケール・ダウンも可能
  • ・Real Application Clusters(RAC)の場合は、ノード一括シェイプ変更(全ノードで同一シェイプ)
  • ・Data Guardの場合は、ノード毎で異なるシェイプへの変更が可能

■3.ストレージの拡張

DBCSインスタンスには 第2回: Oracle Database Cloud Service の中身をみてみよう で紹介したように、初期構築時点で5つのストレージ・ボリュームがアタッチされています。

ストレージの拡張方法としては、下記2種類の方法があります。

  • 1)新規ストレージ・ボリュームの作成: 新しく作成したストレージ・ボリュームをアタッチ
    • 1-1)永続的なボリューム追加: DBCSサービス・コンソールから実施。データやバックアップ領域等
    • 1-2)一時的なボリューム追加: Compute Cloudサービス・コンソールから実施。データロード用ファイル領域等
  • 2)既存ストレージ・ボリュームの拡張: アタッチ済みのデータやバックアップ領域のストレージ・ボリュームを拡張

一時的なボリューム追加に関してはまた別の回で詳しく触れますので、今回は1-1)新規ストレージ・ボリューム追加(永続的)と2)既存ストレージ・ボリュームの拡張をやってみましょう。


と、その前に、今回の環境のストレージ・ボリュームの現状を、OSコマンドで確認しておきます。

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_main-lv_root
                       19G   12G  5.8G  67% /
tmpfs                 3.7G     0  3.7G   0% /dev/shm
/dev/xvdb1            477M   69M  379M  16% /boot
/dev/xvde1             59G   20G   37G  35% /u01   --Oracleのソフトウェアバイナリ
/dev/mapper/dataVolGroup-lvol0
                       25G  5.3G   19G  23% /u02     --DATA(データファイル等)
/dev/mapper/fraVolGroup-lvol0
                       42G   30G  9.9G  75% /u03     --FRA(バックアップファイル等)
/dev/mapper/redoVolGroup-lvol0
                       26G  3.3G   21G  14% /u04     --REDO(オンラインREDOログ等)

参考) マニュアル Oracle Database Cloud Serviceの使用『ストレージ・ボリュームとファイル・システムのレイアウト』

1-1)新規ストレージ・ボリュームの作成

DBCSの機能で実施する新規ストレージ・ボリュームは、永続的なボリュームの追加になり、1~2048GBのサイズで作成が可能です。作成されたストレージ・ボリュームは、新しい/u0xのマウント・ポイントでマウントされます。基本的には、データやバックアップ用の領域など、常に必要となる領域として利用します。

①『ストレージの追加』で『新規ストレージ・ボリュームの作成』を選択し、②にサイズ(GB)を入力したら、③『はい、サービスをスケール・アップ/ダウンします』をクリックします。

img-6

では、新規ストレージ・ボリュームがアタッチされたか確認しましょう。

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_main-lv_root
                       19G   12G  5.8G  67% /
tmpfs                 3.7G     0  3.7G   0% /dev/shm
/dev/xvdb1            477M   69M  379M  16% /boot
/dev/xvde1             59G   20G   37G  35% /u01  
/dev/mapper/dataVolGroup-lvol0
                       25G  5.3G   19G  23% /u02     
/dev/mapper/fraVolGroup-lvol0
                       42G   30G  9.9G  75% /u03     
/dev/mapper/redoVolGroup-lvol0
                       26G  3.3G   21G  14% /u04
/dev/xvdh1             25G   44M   24G   1% /u05  --追加したストレージ・ボリューム   

新規で追加したストレージ・ボリュームが、/u05でマウントされていますね。以降のサービス・インスタンス再起動時にも自動でマウントされるのか、念の為/etc/fstabを確認してみましょう。

...
LABEL=DB_BITS        /u01  ext4  defaults,nodev  0 0
LABEL=DB_DATA        /u02  ext4  defaults,nodev  0 0
LABEL=DB_FRA         /u03  ext4  defaults,nodev  0 0
LABEL=DB_REDO        /u04  ext4  defaults,nodev  0 0
LABEL=ADDVOL_u05     /u05  ext4  defaults        0 0   --追加したストレージ・ボリューム

新規で追加したストレージ・ボリュームの分も、自動で追記されていますね。こういった設定ファイルの更新やフォーマットなどの作業も自動で行われるのが良さですね。

2)既存ストレージ・ボリュームの拡張

既存ストレージ・ボリュームの拡張としては、データ(/u02)もしくはバックアップ=FRA(/u03)に対して実施します。

①『ストレージの追加』で『データ・ストレージ・ボリュームの拡張』もしくは『バックアップ・ストレージ・ボリュームの拡張』を選択し、②にサイズ(GB)を入力したら、③『はい、サービスをスケール・アップ/ダウンします』をクリックします。

img-7

ストレージの拡張についてのポイント

  • ・1つのストレージ・ボリュームのサイズは最大2TB(2048GB)まで(GB単位で指定)
  • ・サービス・インスタンスに最大10個のストレージ・ボリュームをアタッチ可能で、初期構成で5個がアタッチ済み
  • ・RAWストレージの最大8%は、ファイルシステム構成やその他のオーバーヘッドとして使用される
  • ・永続的なストレージ・ボリュームとして一度追加したものは、デタッチや削除は不可

上記からDBCSで利用可能なデータベースのサイズは最大で約11TBということになりますね。

■4.拡張してもリソースが足りない場合

DBCSでコンピュートごとに利用可能なリソースのサイズをまとめると、

  • ・OCPU: 1~16(vCPUだと2~32)
  • ・メモリ: 7.5GB~240GB
  • ・ストレージ: ~約11TB

になります。これよりさらにリソースが必要な場合は、

  • ・シングル・インスタンスを利用している場合、RACやData Guard構成など2ノード分のリソースが利用可能な環境への変更検討
  • 他のサービス (Exadata Cloud Service、Infrastructure as a ServiceでのBYOL利用など) の利用を検討

などで、より大きい構成/サービスへの変更を検討してみましょう。

■5.まとめ

実際に、みなさんがデータベース環境のリソース拡張をしたいのは、どういった時でしょうか。

データの増加によるストレージ枯渇、CPUやメモリ不足によるパフォーマンス劣化、利用機能の追加によるリソース追加(Database In-Memory利用時のメモリ追加)などで、リソース拡張の検討をすると思います。特に開発・検証においては、実施している中で必要なサイズを見積もるなど、使いながらキャパシティ・サイジングをする利用が多いのではないでしょうか。

また、通常時は少ないリソースで利用しながら、処理量が多くなる・負荷が高くなる時だけリソース拡張し、全体のコストを抑えることも可能です。

こういった利用ケースで使われることも多いクラウド環境では、やはりリソース拡張がすぐに・簡単に行えるのは大事ですよね。

ぜひ、必要な時に必要な分のリソースを割りあてながら、DBCSを利用してみてください。

参考) マニュアル Oracle Database Cloud Serviceの使用『データベース・デプロイメントのスケーリング』