リソースをスケーリング&ストレージの情報を整理する
これまででExascaleを使える環境が揃ったので、実際に使ってもらいたいと思います。
（実際に使うところは省略します）
使っていくとストレージが足りなくなって拡張したくなったり、CPU数を変更したくなったり・・
作成時に設定したリソースから変更したくなることが必ず起きると思います。
今回はそのような場合に変更する方法を紹介します。
今回検証したスケーリング項目はこちら。
VM数の変更
ECPU数の変更
VMファイル・システム・ストレージの変更
ストレージ・ボールトの変更
順番にどのような手順で変更するのか見ていきながら、それぞれの内容について確認できたことも紹介します。
VM数の変更
VMの追加
Resourceの部分から仮想マシンを選択すると現在使用しているVMの概要を一覧で確認できます。
見切れてしまっていますが、現在2台のVMを使用しています。
今回はここに3台目のVMを追加していきます。
まず、仮想マシンの追加を選択します。
何台追加するのかを入力する画面に遷移します。
今回は3台目として現在の2台に1台を追加するので、1を入力します。
VMは最大で10台までしか作成できないので、現在の作成中のVMと合わせて10台を超える数は入力できません。
(今回の場合は、1-8の範囲で入力します。)
入力が完了したら追加を選択して、VMを作成します。
このような画面を確認できたら作成が進行しているので、作成が完了するまで待ちましょう。
VMの追加作業は他のVMには影響を与えず、オンラインで実施されます。
3台目のVMのステータスが使用可能になったら、VMの追加は完了しています。
DBをデプロイ後のVM追加になるので、追加完了まで非常に時間が掛かります。
わたしが検証した際は、CDBとPDBが2つずつあるVMを追加したので、10時間くらい掛かってしまいました・・
確認したエラーの紹介
3台目を追加する際にイングレスルールのエラーが発生しました。
こちらはExascaleがあるサブネットのセキュリティリストを編集することで解消しました。
もし同じエラーになったら、参考にしてください。
VM削除
削除したいVMの1番右列にある3つのドットを選択すると、そこから削除できます。
VMの削除自体は、20分くらいで完了しました。
ECPUのスケーリング
画面上部にあるVMクラスタのスケーリングを選択すると、ECPU数を変更できる画面が出てきます。
現在の値がすでに入力されているので、この値を変更していきます。
緑で囲われた1VMあたりの値を変更します。
必要な値を入力して、変更の保存から変更を適用します。
VM再起動 or オンラインスケーリング
変更した値によって、VM再起動が必要になります。
(VM再起動のイメージについては最後に紹介)
合計ECPUが変更されるとVMが再起動します。
変更後の合計ECPUが現在の値と変更になる場合、このような画面でVMの再起動について許可を求められます。
それぞれのイメージはこちらです。
合計ECPUの変化の有無によってVM再起動が必要になり、それぞれ完了するまでの時間も異なります。
縮小・拡張に関わらず、合計ECPUが変化するとVMの再起動が必要になります。
| 合計ECPU数変化あり | 合計ECPU数変化なし | |
|---|---|---|
| 有効ECPU数拡張 | VM再起動 | オンラインスケーリング |
| 有効ECPU数縮小 | VM再起動 | オンラインスケーリング |
VMファイル・システム・ストレージの変更
こちらも1VMあたりの値を入力して変更します。
新規の値を入力できたら、変更の保存から変更を適用します。
VM再起動 or オンラインスケーリング
ECPUの変更同様に、VMファイル・システム・ストレージの変更もVMの再起動を伴う場合があります。
今回はVMファイル・システム・ストレージを以下のようにスケーリングします。
280GB/1VM →(拡張)→ 300GB/1VM →(縮小)→ 280GB/1VM
・拡張: オンラインスケーリング
・縮小: VM再起動
| 要した時間 | VM再起動 | |
|---|---|---|
| 拡張 | 約10分 | 不要 (オンラインスケーリング) |
| 縮小 | 約15分 | 必要 (VM再起動) |
ストレージ詳細
VM2台・CDB1台の環境で280GB/1VMと300GB/1VMの時のストレージを比較しました。
280GB/1VMのとき
[oracle@exascale1-orsnb ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 114G 0 disk
|-sda1 8:1 0 512M 0 part /boot
|-sda2 8:2 0 256M 0 part
`-sda3 8:3 0 113.3G 0 part
sdb 8:16 0 82G 0 disk
`-sdb1 8:17 0 82G 0 part
`-VGExaDbDisk.u01_Vmjkjyx_2_a147-LVDBDisk 252:1 0 80G 0 lvm /u01
sdc 8:32 0 104G 0 disk
`-sdc1 8:33 0 84G 0 part
`-VGExaDbDisk.u02_extra.img-LVDBDisk 252:0 0 81.9G 0 lvm /u02
exc-dev1 251:1 0 200G 0 disk /var/opt/oracle/dbaas_acfs
300GB/1VMのとき
[oracle@exascale1-orsnb ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 114G 0 disk
|-sda1 8:1 0 512M 0 part /boot
|-sda2 8:2 0 256M 0 part
`-sda3 8:3 0 113.3G 0 part
sdb 8:16 0 82G 0 disk
`-sdb1 8:17 0 82G 0 part
`-VGExaDbDisk.u01_Vmjkjyx_2_a147-LVDBDisk 252:1 0 80G 0 lvm /u01
sdc 8:32 0 104G 0 disk
`-sdc1 8:33 0 104G 0 part
`-VGExaDbDisk.u02_extra.img-LVDBDisk 252:0 0 102G 0 lvm /u02
exc-dev1 251:1 0 200G 0 disk /var/opt/oracle/dbaas_acfs
これらを比較すると、全体として20GB拡張した部分は/u02の部分の拡張になっていることがわかります。
ストレージ容量の目安
こちらはタイトル通り目安程度に考えてもらえればと思いますが、検証した環境でリソース不足になりました。
その際の構成やエラーメッセージを紹介します。
以下のような構成で、3つ目のCDBを作成しようとしました。
・VMは2つ
・1VMあたりCDBとPDBが2つずつ作成済
・確保しているVMファイル・システム・ストレージは280GB
以下のようなエラーが発生し3つ目のCDBを作成することができませんでした。
このエラーを確認すると、VMファイル・システム・ストレージの空き容量が不足しており、3つ目のCDBを作成できていないようです。
1VMあたりファイル・システム・ストレージ (OS領域)に2,500MBの空き容量が必要
この構成では、空き容量は2,107MBしかありませんでした。
データベース・ストレージ・ボールトは空き容量を確認することができますが (後ほど紹介します)、VMファイル・システム・ストレージは容量を確認することができません。
拡張はオンラインでできるので、エラーが発生したら拡張して必要な容量を確保しましょう。
ストレージ・ボールトの変更
ストレージボールトは他のExascaleとも共有できるので、ストレージの変更はボールトの詳細画面から行います。
Exascaleデータベース・ストレージの青字になっている使用中のストレージを選択します。
この画面に遷移したら、ストレージ・ボールトのスケーリングを選択してリソースの変更を行います。
ここに変更後のストレージ容量を入力します。
キャッシュの追加もこちらから行います。
キャッシュは、全体のストレージ容量に対する割合で入力します。
入力した割合から計算されるキャッシュ容量は、100GB以上である必要があります。
300GBのストレージ容量の場合、最小値は34 (=100GB)で、
500GBのストレージ容量の場合、最小値は20 (=100GB)になります。
入力するボックスの下に書かれているので、それを参照して入力しましょう。
約2-3分でスケーリングが完了します。
ここでのスケーリングは、オンラインで行われます。
ストレージ・ボールトの縮小は、VMファイル・システム・ストレージとは異なりVMの再起動を伴いません。
ストレージ・ボールトは、拡張・縮小に関わらずオンラインスケーリングで完了します。
Exascaleデータベース・ストレージ・ボールトに関連する動的パフォーマンスビュー
Exascaleのデータベース・ストレージ・ボールトの容量をコンソールからは、
空き容量・設定容量・使用容量 (= 設定容量と空き容量の差分)
しか確認できません。
さらに詳細な情報はDatabaseにアクセスして、動的パフォーマンスビューから取得する必要があります。
V$EXA_FILE, V$EXA_TEMPLATE, V$EXA_VAULTからDatabase上でストレージの情報を確認できます。
それぞれのビューでストレージの情報を確認するのに使用した項目を4つ紹介します。
V$EXA_FILE: REDUNDANCY
ドキュメントによると、以下のように定義されています。
File redundancy setting. Possible values are:
normal: Indicates 2 mirrored copies of the file data.
high: Indicates 3 mirrored copies of the file data.
今回の環境で確認できたのはHighだったので、使用している環境はデフォルトで三多重による冗長化された構成であることがわかりました。
V$EXA_FILE: CONTENT_TYPE, SIZE_IN_BYTES
ドキュメントによると、以下のように定義されています。
CONTENT_TYPE
File content type. Possible values are:
DATA
RECO
SIZE_IN_BYTES
File size in bytes.
ストレージ・ボールトとして300GB確保している今回の環境で確認すると、
CONTENT_TYPE=DATAのSIZE_IN_BYTESは281GB
CONTENT_TYPE=RECOのSIZE_IN_BYTESは18GB
で使用されている容量はこれらの合計281GBと確認できました。
ここのSIZE_IN_BYTESで確認できる容量は現在使用中の容量です。
ASMとは異なり、未使用の状態でDATA/RECOに容量を割り当てることはできません。
ストレージの使用状況に応じて、DATA/RECOの適切な領域に容量が割当てられます。
V$EXA_VAULT: HC_SPACE_USED, HC_SPACE_PROV
ドキュメントによると以下のように定義されています。
HC_SPACE_USED
Vault space used on high capacity (HC) storage media.
HC_SPACE_PROV
Vault space provisioned on HC storage media.
V$EXA_FILEのREDUNDANCYによる冗長化を反映した値を確認できます。
今回は三多重化されているため、V$EXAFILEで確認した値を3倍した値が得られます。
ストレージの容量について、今回の検証で確認した内容をまとめると以下です。
| 確認方法 | 使用容量 | 設定容量 |
|---|---|---|
| コンソール | 281GB | 300GB |
| V$EXA_FILE | SIZE_IN_BYTES: 281GB | - |
| V$EXA_VALUT | HC_SPACE_USED: 842GB | HC_SPACE_USED: 900GB |
ストレージ容量の目安
こちらもVMファイル・システム・ストレージ同様、目安程度に考えてもらえればと思います。
ストレージ・ボールト関連でもエラーが発生したので、その際の構成やエラーメッセージを紹介します。
以下のような構成で、2つ目のCDBを作成しようとしました。
・VMは2つ
・1VMあたりCDBとPDBを1つずつ作成済
・確保しているデータベース・ストレージ・ボールトは300GB
・空き容量は19GB (使用領域は281GB)
以下のようなエラーが発生し、2つ目のCDBを作成することができませんでした。
ストレージ容量不足によって、作成することができませんでした。
新規のCDBを作成する場合、88GBの空き容量が必要
ストレージ・ボールトはオンラインで拡張できるので、リソースが足りない場合には必要な容量を確保してから作成しましょう。
参考情報ですが・・
以下の構成では、ストレージ・ボールトは360GBでした。
・VMは2つ
・1VMあたりCDBとPDBを2つずつ作成
VM再起動
合計ECPUの変更を伴うECPU拡張・縮小と、VMファイル・システム・ストレージの縮小の際に生じるVM再起動の方法について最後に簡単に紹介したいと思います。
VMの再起動はローリングで行われます。
VMが2台ある場合、1台目のVMが再起動しその間2台目のVMは稼働しています。
1台目のVMが起動次第、2台目のVMが再起動します。
どちらかのVMが再起動している間は、再起動してないVMが稼働している状態になっているので、システム停止時間を最小限に抑えることができます。
しかし、アプリケーションの瞬断が生じる可能性はあるので、夜間などのシステムが停止しても問題ない時間帯に行うことを推奨します。
Application Continuityなどの必要なツールを用いて瞬断をより最小限に抑えることも可能です。
スケーリングによるVM再起動まとめ
いくつかの項目では、リソースの変更によってVMの再起動を伴うことを認識していただけたと思います。
しかし、複数のリソース変更方法を紹介したうえにVM再起動が必要な条件も単純ではないので、ここで整理してまとめます。
| 項目 | 拡張 | 縮小 |
|---|---|---|
| VM数 | オンラインスケーリング | オンラインスケーリング |
| ECPU: 合計ECPU変更あり | VM再起動 | VM再起動 |
| ECPU: 合計ECPU変更なし | オンラインスケーリング | オンラインスケーリング |
| VMファイルシステムストレージ | オンラインスケーリング | VM再起動 |
| ストレージ・ボールト | オンラインスケーリング | オンラインスケーリング |
| フラッシュ・キャッシュ | オンラインスケーリング | オンラインスケーリング |
VM再起動が必要なケース3つのみ抑えて、他はオンラインスケーリング！と覚えてもらうのが良いと思います。
#3ではリソースのスケーリング方法とそれぞれのストレージの詳細について簡単に紹介しました。
ちょっとボリューミーになってしまいましたが、要点を少しでも理解していだたければと思っています。
また#4も書きたいと思います。