もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶
※本記事は2019/05に公開。2022/06/03最終更新時点の内容になります
こんにちは！今年のゴールデンウィークは長かったですが、皆様いかがでしたでしょうか。
今年のゴールデンウィーク前後は、オンプレミス版Oracle Database 19c(19.3) のLinux版がリリースされ、待望の第２世代のオラクル・クラウドOracle Cloud Infrastructure(OCI) の東京リージョンがオープンしたりと、私としては嬉しいニュースがいっぱい出てきました！
早速、東京リージョンにOracle Exadata Database Cloud/Oracle Base Database Cloud/Autonomous Databaseを作ってみました。サクサク動いているので、ぜひ使ってみてください。
今回は、そんな東京リージョンのExadata Database Serviceでも実施した、スケール・アップ/ダウンについて解説したいと思います。
■1. Exadata Database Service のスケール・アップ/ダウンの対象は？
Exadata Database Service のスケーリングの対象は、2種類あります。１つは、割り当てられているH/Wリソース内で利用可能な、OCPU(CPUコア)数のスケール・アップ/ダウン。このCPUコアというのは、コンピュート(VM)の”OS”側で認識しているActiveなコアを指します。データベースや仮想マシンを再起動することなく、処理を継続したままオンラインで変更可能です。また、VMクラスタ全体に対しての変更になります。そのため、例えばノード毎にCPUコア数を変えることはできないので、仮想マシン数の倍数が指定可能になります。もう１つは、インフラストラクチャー部分のデータベース・サーバーとストレージ・サーバーのスケール・アップ(ダウンは不可)。こちらは、X8M以降のモデルで可能で、CPU・メモリ・ストレージなどH/W的に割り当てられている専有リソースを増やしたい場合に、オンラインで追加が可能です。
・マニュアル(以降は最新情報である英語マニュアルをポイントしていきます)
日本語 Oracle Cloud Infrastructure Documentation > Database
英語 Oracle Cloud Infrastructure Documentation > Database > Exadata Database Service > How-to Guides > Manage VM Clusters > Scaling an Exadaa Cloud Infrastructure Instancve
■2. スケール・アップ/ダウンしてみよう – コンソール編
では、実際にスケール・アップ/ダウンする方法を、まずはコンソール画面で見てみましょう。
OCPUのスケーリング
まずは、OCPUのスケーリングからです。
対象のDBシステムの詳細ページに行き、『DBシステム情報』に表示されている現在の『CPUコア数』を確認しましょう。
前回の記事でも触れましたが、このCPUコア数はDBシステム(サービス・インスタンス)全体での有効なCPUコア数です。つまり、今回の環境のシェイプはQuarter=コンピュート2台のため、コンピュートあたり33CPUコアが有効になっています。
確認したら、システム名の下にある『スケール・アップ/ダウン』のボタンをクリック。
『CPUコア数』を指定するボックスが表示されるので、現在のリソース数から変更したいCPUコア数を入力します。
今回は、66から88に変更してみます。
ステータスが『スケーリング進行中』から『使用可能』になると、リソースの内容も変わり、スケーリング成功です。
なお、オンラインでのスケーリングなので、ステータスがスケーリング進行中でもサービスの使用は可能です。
・マニュアル 英語 To Scale CPU Cores in an Exadata Cloud Infrastructure Cloud VM Cluster or DB systems
インフラストラクチャーのスケーリング
次に、データベース・サーバーとストレージ・サーバーのスケール・アップをしてみます。
スケール・アップは、それぞれ一台ずつ可能で、インフラストラクチャーとして追加した後に、実際に利用しているVMクラスタへの追加が必要なので、２ステップ必要となります。
1-1. データベース・サーバーの追加
Exadata インフラストラクチャーの管理ページで、『Exadata Infrastructureのスケーリング』をクリックします。『データベース・サーバー』のラジオボタンをクリックし、『データベース・サーバー』の追加する台数を入れます。一回のスケーリング操作で追加できるのは最大4台までです。『スケール』をクリックします。
1-2. ストレージ・サーバーの追加
Exadata インフラストラクチャーの管理ページで、『Exadata Infrastructureのスケーリング』をクリックします。『ストレージ・サーバー』のラジオボタンをクリックし、『ストレージ・サーバー』の追加する台数を入れます。一回のスケーリング操作で追加できるのは最大6台までです。『スケール』をクリックします。
2. VMクラスタへの追加
VMクラスタの管理ページで、『VMクラスタのスケーリング』をクリックします。出てきた画面の『容量を追加』のチェックボックスをクリックし、『更新』ボタンで更新します。これにより、VMクラスタ内のOracle Real Application Clusters (RAC)やOracle Clusterware、Oracle Automatic Storage Management(ASM) など、環境全体をクラスタリングしているコンポーネントへの追加が行われます。
■3. スケールアップ/ダウンしてみよう – CUI編
CLI(OCI CLI/REST/Terraformなど)でもスケール・アップ/ダウンは可能です。今回は、OCI CLIでの方法を紹介します。
<事前準備>
1. OCI CLIのセットアップ
今回はセットアップは完了している前提ですすめますが、まだこれからという方は下記をご参考にセットアップしてみてください。
・マニュアル
Oracle Cloud Infrastructure Documentation > コマンド・ライン・インターフェース > クイックスタート
・Oracle Cloud 公式ブログ コマンドライン(CLI)でOCIを操作する – Oracle Cloud Infrastructureアドバンスド
ちなみに、Oracle Cloud Developer ImageというOracle Cloudを利用する開発者向けのツールが全部入りのイメージが、マーケットプレイスから入手できるので、こちらを利用するとすぐにOCI CLIを使える状態になっているので簡単ですよ。
・参考 [OCI]Oracle Cloud Developer Imageの発表 (2019/04/02)
2. db-system-idの確認
スケール・アップ/ダウンのコマンドで、対象リソースの識別子としてインスタンス(DBシステム)のOCIDの情報が必要になります。
・OCI CLIでの確認
$ oci db system list --compartment-id <コンパートメントのOCID> \
--query 'data[?"display-name"==`<表示名>`].{"display-name":"display-name","id":"id"}'
例
$ oci db system list --compartment-id <xxxxx> \
--query 'data[?"display-name"==`ExaCS`].{"display-name":"display-name","id":"id"}'
[
{
"display-name": "ExaCS",
"id": "ocid1.dbsystem.oc1.ap-tokyo-1.<xxxxxx>"
}
]
<スケール・アップ/ダウン>
まずは、OS側とデータベース側で認識しているCPUコア数を確認してみます。
-- OS側で認識しているActiveなコア数 #/bin/grep -c processor /proc/cpuinfo 66 -- DBインスタンス側で認識しているActiveなコア数 SQL> col name for a15 SQL> col value for a20 SQL> select inst_id,name,value from gv$parameter where name='cpu_count' INST_ID NAME VALUE ---------- -------------------- -------------------- 1 cpu_count 66 2 cpu_count 66
ハイパースレッディングが有効なので、各コンピュート/DBインスタンスで66コアが認識されていますね。
では、OCI CLIでスケール・アップしてみましょう。
$ oci db cloud-vm-cluster update --cpu-core count <core number#> --cloud-vm-cluster-id <cloud-vm-cluster-id>
例
--1.現在のOCPU数を確認 $ oci db cloud-vm-cluster get --cloud-vm-cluster-id xxx --query 'data.{"1.Name":"display-name","2.shape":"shape","3.cpu-core-count": "cpu-core-count"}' { "1.Name": “<system name>", "2.shape": "Exadata.Quarter2.92", "3.cpu-core-count": 44 } --2.66 OCPUにスケール・アップ $ oci db cloud-vm-cluster update --cpu-core-count 66 --cloud-vm-cluster-id xxx … --3.変更されたか確認 $ oci db cloud-vm-cluster get --cloud-vm-cluster-id xxx --query 'data.{"1.Name":"display-name","2.shape":"shape","3.cpu-core-count": "cpu-core-count"}' { "1.Name": “<system name>", "2.shape": "Exadata.Quarter2.92", "3.cpu-core-count": 66 }
再度、OS側とデータベース側で認識しているCPUコア数を確認してみます。
#/bin/grep -c processor /proc/cpuinfo
88
SQL> col name for a15
SQL> col value for a20
SQL> select inst_id,name,value from gv$parameter where name='cpu_count'
INST_ID NAME VALUE
---------- -------------------- --------------------
1 cpu_count 66
2 cpu_count 66
OS側だけではなく、DBインスタンス側でも認識しているコア数が増えていることがわかりますね。
ちなみに、oci db system-shape list コマンドで、各シェイプ毎の利用可能な最大OCPU数・スケーリングの単位(=ノード数)などが確認可能です。
$ oci db system-shape list --compartment-id <xxx> --availability-domain EWVY:AP-TOKYO-1-AD-1 \
--query 'sort_by(data,&"available-core-count") [?contains("shape",`Exadata`)]\
.{"1.shape":shape,"2.available-core-count":"available-core-count","3.core-count-increment"\
:"core-count-increment"}' --output table
+---------------------+------------------------+------------------------+
| 1.shape | 2.available-core-count | 3.core-count-increment |
+---------------------+------------------------+------------------------+
| Exadata.Quarter2.92 | 92 | 2 |
| Exadata.Half2.184 | 184 | 4 |
| Exadata.Full2.368 | 368 | 8 |
....
+---------------------+------------------------+------------------------+
・マニュアル OCI CLI Command Reference DB > system > update
■4. スケール・アップ/ダウンの影響は？
Exadata Database Cloud でのスケーリングは、オンライン(データベースや仮想マシンの再起動なし)で行われます。そのため、実行中のトランザクションが中止されたり、セッションが切れるということがなく、必要な時=処理中にリソース不足している状態でも簡単にスケーリング可能です。
CPUスケーリングには関しては、繰り返しになりますがOS側で認識しているActiveなコア数が変更されます。3章でだした例では、データベース側で認識する利用可能なコア数も動的に自動で変わりましたが、これはデータベース側の設定次第になります。デフォルトではデータベース側で利用可能なコア数は、OS側で認識しているコア数になります。これはデータベースのCPU_COUNTパラメータが0の場合です。CPU_COUNTパラメータに明示的に数値を設定する、インスタンス・ケージング機能を利用している場合、そのインスタンスで利用可能なコア数を明示的に設定されている状態なので、OS側で利用可能なコア数が増減したとしても、インスタンス側で利用可能なコア数は固定されている状態です。そのため、インスタンス・ケージングを利用している場合は、CPUコアのスケール・アップ/ダウンをした後にデータベース側のCPU_COUNTを変更しないとデータベース側で利用するリソースは増減しないので、ご注意ください。
・マニュアル Oracle Database データベース・リファレンス > CPU_COUNT
CPUコア数を0にスケール・ダウンした場合は、利用可能なリソースがゼロ＝全仮想マシンが停止状態=OS停止になります。スケール・ダウンとは別にコンピュートの停止機能もありますが、状態としては同じものの課金の部分が異なります。コンピュートの停止はただコンピュートが停止されるだけで課金は継続されますが、スケール・ダウンでCPUコア数を０にした場合は課金もコンピュートも停止します。そのため、OCPU部分の課金を停止したい場合には、コンピュートの停止ではなくCPUコア数を０にスケール・ダウンしてください。
■5. まとめ
今回はOracle Exadata Database Cloudでのスケール・アップ/ダウンについて解説しました。
スケール・アップ/ダウンの機能は、「使いたい時に使いたいだけ」リソースを柔軟に増減できるクラウドならではのメリットなので、利用されたい方も多い機能だと思います。特にCLIについては、スケジューリングしたい場合や、スタンバイとしてOracle Exadata Database Cloudを利用しているケースで切り替え時にCPUを本番同等にするのに簡単にスクリプト化しておきたい場合など、色々なケースで利用可能かと思います。
また、OCPUのスケーリングに関しては、仮想マシン内にツールをセットアップすることで自動スケーリングも可能です。下記をご参照ください。
MOS Doc ID 2719916.1: (ODyS) Oracle Dynamic Scaling engine – Scale-up and Scale-down automation utility for OCI DB System (ExaCS/ExaC@C)
サービスによってもスケール・アップ/ダウンの対象のリソースや動作に差がある場合があるので、利用するサービスごとに確認してくださいね。次回は、Autonomous Databaseでのスケール・アップ/ダウンについて解説しますので、ぜひそちらも見てみてください。