X

A blog about Oracle Technology Network Japan

  • January 25, 2018

もしもみなみんがDBをクラウドで動かしてみたら 第5回 [OCI Classic] 可用性構成を作ってみよう - Real Application Clusters 編 2018.1.26公開

Eriko Minamino
Solution Engineer

もしもみなみんがDBをクラウドで動かしてみたら Indexページ ▶▶

※本記事は2018/7時点のものになります


本記事はOracle Cloudの第一世代、Oracle Cloud Infrastrcuture - Classicの記事です。

今回から数回に分けて、Oracle Cloud Infrastructure Classic(OCI Classic)上のOracle Database Cloud Service(DBCS)の可用性機能についてご紹介します。

まずは、Oracle Databaseの機能中でサーバー障害時の可用性や性能向上観点での拡張性で定評のある Oracle Real Application Clusters(RAC)について触れていきます。


■1. Oracle CloudでのRACについて

RACは、複数のサーバで一つのデータベースを構成し、Active-Activeなシェアードエブリシング・クラスタによる可用性・拡張性で、登場以来多くの大規模エンタープライズシステムで採用頂いている機能です。このRACをご利用いただけるのがOracle Cloudになります。

RAC を使用することによって、計画外のインスタンスまたはサーバー障害時、パッチ適用などの計画停止でのローリング(順次)メンテナンスなどで、停止時間を抑えられます。

参考)
高可用性と高拡張性を両立する Oracle RAC ~ 改めて基礎からシンプルに理解する ~
「イチから学ぶデータベース最新技術 - Oracle Real Application Clusters編」

 

■2. DBCSのRAC環境構築

では、さっそくDBCSでRACを構築してみましょう。

『ソフトウェア・エディション』では、第1回: Oracle Database Cloud Serviceを使ってみようで紹介したエディションの中で、RACが利用可能な『Enterprise Edition Extreme Performance』選択します。

あとは『Database Type』で『Database Clustering with RAC』を選ぶだけで、シングル・インスタンス作成時と同様です。

img-1

シェイプ(に関しては、RACの場合は2OCPU~16OCPU(vCPUだと4~32)のシェイプが利用可能です。

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

オンプレミスで構築する場合には、Oracle Grid InfrastructureとOracle Databaseの設計・インストール・構築…と利用開始までに多くの時間が要されますが、このように数クリックでRAC環境が手に入ります。(OCI Classic DBCSの場合約1時間(2018/01現在))

 

OCI-Classic DBCS RAC環境の構築でのポイント
  • エディションは、EE-Extreme Performance
  • サービス作成時のDatabase Typeで「Database Clustering with RAC」を選ぶだけ

 

■3. DBCSのRAC環境の構成

DBCSのRAC環境は2ノード・クラスタで作成されます。

img-1

 

$ crsctl stat res -w "TYPE = ora.database.type" -t
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.em02.db
      1        ONLINE  ONLINE       minamin-rac1221          Open,HOME=/u01/app/o
                                                             racle/product/12.2.0
                                                             .1/dbhome_1,STABLE
      2        ONLINE  ONLINE       minamin-rac1222          Open,HOME=/u01/app/o
                                                             racle/product/12.2.0
                                                             .1/dbhome_1,STABLE

DBCSでは2ノードのみのため、より多くのノード数を利用したいという場合はExadata Cloud Serviceになります。

構築時に選択したシェイプのリソースは1ノードあたりのものなので、RACの場合は2ノード分つまり選択したシェイプの2倍のリソースが割り当てられます。そのため、最大36OCPUまで利用可能です。ただし、2ノードで同一シェイプである必要があるため、片ノードだけ小さいシェイプとする構成にはできませんのでご注意ください。

ストレージに関しては、Linux LVMではなく、Oracle Automatic Storage Management (ASM)とOracle ASM Cluster File System(ACFS)を使用して、クラスタを構成するノード間でのストレージ共有を行っています。

 

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_main-lv_root
                       19G  2.2G   16G  13% /
tmpfs                 7.3G  1.3G  6.0G  17% /dev/shm
/dev/xvdb1            477M   69M  379M  16% /boot
/dev/xvdc1             69G   21G   45G  32% /u01
/dev/asm/data-328      25G  3.9G   22G  16% /u02     --DATA(データファイル等)
/dev/asm/fra-257       45G  4.1G   41G  10% /u03     --FRA(バックアップファイル等)
/dev/asm/redo-362      19G  4.6G   15G  24% /u04     --REDO(オンラインREDOログ等)

$ /sbin/acfsutil registry -l
Device : /dev/asm/data-328 : Mount Point : /u02 : Options : none : Nodes : all : Disk Group: DATA : Primary Volume : DATA : Accelerator Volumes :
Device : /dev/asm/fra-257 : Mount Point : /u03 : Options : none : Nodes : all : Disk Group: FRA : Primary Volume : FRA : Accelerator Volumes :
Device : /dev/asm/redo-362 : Mount Point : /u04 : Options : none : Nodes : all : Disk Group: REDO : Primary Volume : REDO : Accelerator Volumes :

データファイル、バックアップファイル、REDOログファイルの置き場に対して、ASMのディスク・グループをACFSによってマウントされています。

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

 

RAC環境のスケールアップは

  • シェイプのスケール・アップやダウンは、両ノードに対して実施
  • ストレージのスケール・アップは、DATAもしくはFRAのディスクグループを指定し、既存ボリュームと同サイズで追加
という内容であれば拡張することが可能です。

 

OCI-Classic DBCS RAC構成のポイント

  • 同一シェイプの2ノード・クラスタ構成
  • データベース関連ファイル用のストレージは、ASMとACFSを使用した管理によるクラスタ内でのストレージ共有
 

■4. 障害時の動作

RAC環境は、Oracle Grid Infrastructure(GI)によって関連リソースの管理・監視が行われます。

そのため、インスタンス障害時などにデータベース関連のインスタンスやプロセス等の自動再起動が行われます。このあたりは、従来のオンプレミス環境でのRACやGIと同様です。

では、クラウドとして仮想マシンより下のレイヤーに関しての、障害対策はどうなっているのか。

まずは仮想マシンの障害時ですが、インフラ側で仮想マシンの稼働状況を監視していますので、異常停止を検知した場合に自動再起動が有効になっています。

そして物理サーバー障害に関してですが、もし同じ物理サーバー上に両ノードの仮想マシンが稼働していると両ノードダウンが起きてしまいます。それを防ぐために、2ノードの仮想マシンが物理的に別サーバー上で稼働するように、インフラ側できちんと制御されています。もちろんストレージもミラーリングされています。

また、アプリケーションからの接続を含めた可用性対策として、Java Cloud Service(JCS)やRACの機能を利用した環境を構築も可能です。詳細は、下記検証レポートをぜひご参照ください。

参考) Application Continuity - PSソリューションズ様とのPaaS検証の取り組み

 

OCI-Classic DBCS RACでの可用性ポイント

  • GIによる、インスタンスダウンやサーバーダウン時のデータベースインスタンスや関連リソースの監視と管理
  • 物理的に別サーバー上で仮想マシンが稼働
  • 仮想マシンの異常停止時の自動再起動
  • JCSやApplication Continuityを利用したアプリケーションを含んだ可用性対策も構築可能

 

■5.まとめ

RACはOracle Databaseを代表する機能の一つです。

シェアード・エブリシングやノード間での一貫性を維持し、シングル・インスタンス環境と同様のSQLを実行できる透過性をもっています。どの環境・構成でも同様に利用できるというのは、オンプレミスとクラウド間で同様に利用できるというOracle Cloudの思想と通じますね。

改めてRACの良さを学ばれたい方は、ぜひ下記のOracle Database Technology Nightセミナー資料をご覧ください。

Oracle Database Technology Night~集え!オラクルの力(チカラ)~


 

ページトップへ戻る▲ 

 

もしもみなみんがDBをクラウドで動かしてみたら Indexページ ▶▶

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.