Oracle 19c SEHAを3ノードで構成してみての気づき
この記事は、 JPOUG Advent Calendar 2020 8日目の記事です。
7日目は @gowatana さんの記事『Oracle Linux でエンジニアの孤独を鼓動にしてみる。』でした。
はじめに
2020/5にSEHA提供開始のアナウンスがされ、最近では構築記事やWebinarでよく目にするようになりました。私も公開されている手順を頼りに構築していました。
macchi_9 on Twitter: "遅ればせながら、19.7のSEHAを構築できました。relocateとF/Oを1回ずつやったレベルなので、いろいろ確認していこうと思います。… "
HAということで2ノード(Act-Stb)という先入観があり当時はあまり気にしていませんでしたが、改めてマニュアルを読んだところ3ノード(Act-Stb-Stb)も構築できそうということで以前の環境を使って構築することにしたのが始まりです。
Creating and Configuring an Oracle Database
※記事内の誤りなどはご指摘いただけると幸いです。
一旦結論
環境毎に運用ルールなどがあり一概に言えませんが、SEHAは素直に2ノードで構成するのがいいと感じました。
障害ポイントについて
Grid InfrastructureによるHAでインスタンスのF/Oが発生する障害ポイントは大きく以下になると思います。（プロセス障害などは置いておきます。）
- ノード障害
- サービスNW障害
- インターコネクト障害
- 共有ディスク障害
Grid Infrastructureにおいてノード障害、サービスNW障害、共有ディスク障害については、直感的な動きをしますがインターコネクト障害(スプリットブレイン時)の場合は少し違います。
※12c: スプリット・ブレイン発生時の生き残りノードについて (Doc ID 1952193.1)
ざっくり12c以降では、ノード状況に応じてどのノードが生き残るかわからないというものです。今まで、Act-ActのRACが提供されていて意識しなくてよかったポイントかと思います。11gまではノード番号の若いノードが生き残る挙動だったようです。
本記事では、インターコネクト障害にフォーカスして記載しています。
SEHA 2ノード構成の場合
良くも悪くも2ノードなため、インターコネクト障害＝スプリットブレインになります。
その際に、インスタンスが起動しているノードが生き残れないとインスタンスのF/Oが発生します。
SEHAは基本的に稼働系で動かす前提です。（10日間のフェイルオーバールールを守れば待機系のライセンス不要）
そのため、サーバーの重みベースのノード削除(12.2~)を稼働系サーバに設定(css_critical yes)することで、インターコネクト障害のみでサービスを提供できているインスタンスを不用意にF/Oさせないようにできます。
※障害時の対応は現場によって違うと思うのでこの対応が100%正しいわけではないです。（念のため）
SEHA 3ノード構成の場合
2.9.3 Enabling Standard Edition High Availability for Oracle DatabasesのNote部分に記載がありますが、以下のような設定(Configured Nodes)だと、クラスタを起動するとまずは1号機でインスタンスが起動します。
1号機をシャットダウンすると2号機へF/Oし、2号機をシャットダウンすると3号機へF/Oする流れになることを確認しました。
[oracle@sehanode1 ~]$ srvctl config database -db orcl
Database unique name: orcl
Database name: orcl
Oracle home: /u01/app/oracle/product/19.7.0/dbhome_1
Spfile: +DATA/ORCL/PARAMETERFILE/spfile.257.1047167175
Password file: +DATA/orcl/orapworcl
Domain: snet.com
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools:
Disk Groups: DATA,FRA
Mount point paths:
Services: orclsv
Type: SINGLE
OSDBA group: dba
OSOPER group: oper
Database instance: orcl
Configured nodes: sehanode1,sehanode2,sehanode3
CSS critical: no
CPU count: 0
Memory target: 0
Maximum memory: 0
Default network number for database services:
Database is administrator managed
3ノード構成になったことで、スプリットブレインしづらくなりました。インターコネクトスイッチごと落ちればスプリットブレインになりますが考えづらいです。
2ノード構成の時はいずれかのノードのインターコネクトケーブルが抜けた場合でもスプリットブレインになっていたものが、3ノード構成では1号機でインターコネクト障害が起こった場合に2号機および3号機で過半数取れているので1号機がクラスタから外れ、2号機へインスタンスがF/Oする動きになります。
このような動きだと2ノード構成の場合に比べて、稼働系サーバの設定(css_critical)を活かせない場合が多く、障害時の対応が増えたり、普段使わないスタンバイサーバを1台分多く管理することになります。
結論
- 運用はシンプルな方がいいと思うので、2ノード故障にも耐える必要があるようなシステムでEEを選択できないのであれば、SEHA+Dbvisitのようにクラスタノード増やすより、DR側に切り替えられるシステムの設計も考慮した方がよさそう。
- SDSを採用していたりしてハードウェアとして3ノードある場合でもDBノードとしては2ノード構成がよさそう。（残りはDB以外に使うなど）
- もちろんこの挙動で合意がとれるのであれば、3ノード構成でも問題ないと思います。
最後に
せっかくなのでcrsctl stat res -tを貼ります。綺麗に見えるようにrelocateしました。
環境
OS：CentOS7.8
Oracle Database / Grid Infrastructure：19.9
[grid@sehanode1 ~]$ crsctl stat res -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.LISTENER.lsnr
ONLINE ONLINE sehanode1 STABLE
ONLINE ONLINE sehanode2 STABLE
ONLINE ONLINE sehanode3 STABLE
ora.chad
ONLINE ONLINE sehanode1 STABLE
ONLINE ONLINE sehanode2 STABLE
ONLINE ONLINE sehanode3 STABLE
ora.net1.network
ONLINE ONLINE sehanode1 STABLE
ONLINE ONLINE sehanode2 STABLE
ONLINE ONLINE sehanode3 STABLE
ora.ons
ONLINE ONLINE sehanode1 STABLE
ONLINE ONLINE sehanode2 STABLE
ONLINE ONLINE sehanode3 STABLE
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup)
1 ONLINE ONLINE sehanode1 STABLE
2 ONLINE ONLINE sehanode2 STABLE
3 ONLINE ONLINE sehanode3 STABLE
ora.ASMNET2LSNR_ASM.lsnr(ora.asmgroup)
1 ONLINE ONLINE sehanode1 STABLE
2 ONLINE ONLINE sehanode2 STABLE
3 ONLINE ONLINE sehanode3 STABLE
ora.DATA.dg(ora.asmgroup)
1 ONLINE ONLINE sehanode1 STABLE
2 ONLINE ONLINE sehanode2 STABLE
3 ONLINE ONLINE sehanode3 STABLE
ora.FRA.dg(ora.asmgroup)
1 ONLINE ONLINE sehanode1 STABLE
2 ONLINE ONLINE sehanode2 STABLE
3 ONLINE ONLINE sehanode3 STABLE
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE sehanode1 STABLE
ora.LISTENER_SCAN2.lsnr
1 ONLINE ONLINE sehanode2 STABLE
ora.LISTENER_SCAN3.lsnr
1 ONLINE ONLINE sehanode3 STABLE
ora.MGMTLSNR
1 ONLINE ONLINE sehanode1 169.254.2.167 10.0.1
.41 10.0.2.41,STABLE
ora.OCR.dg(ora.asmgroup)
1 ONLINE ONLINE sehanode1 STABLE
2 ONLINE ONLINE sehanode2 STABLE
3 ONLINE ONLINE sehanode3 STABLE
ora.asm(ora.asmgroup)
1 ONLINE ONLINE sehanode1 Started,STABLE
2 ONLINE ONLINE sehanode2 Started,STABLE
3 ONLINE ONLINE sehanode3 Started,STABLE
ora.asmnet1.asmnetwork(ora.asmgroup)
1 ONLINE ONLINE sehanode1 STABLE
2 ONLINE ONLINE sehanode2 STABLE
3 ONLINE ONLINE sehanode3 STABLE
ora.asmnet2.asmnetwork(ora.asmgroup)
1 ONLINE ONLINE sehanode1 STABLE
2 ONLINE ONLINE sehanode2 STABLE
3 ONLINE ONLINE sehanode3 STABLE
ora.cvu
1 ONLINE ONLINE sehanode1 STABLE
ora.mgmtdb
1 ONLINE ONLINE sehanode1 Open,STABLE
ora.orcl.db
1 ONLINE ONLINE sehanode1 Open,HOME=/u01/app/o
racle/product/19.7.0
/dbhome_1,STABLE
ora.orcl.orclsv.svc
1 ONLINE ONLINE sehanode1 STABLE
ora.qosmserver
1 ONLINE ONLINE sehanode1 STABLE
ora.scan1.vip
1 ONLINE ONLINE sehanode1 STABLE
ora.scan2.vip
1 ONLINE ONLINE sehanode2 STABLE
ora.scan3.vip
1 ONLINE ONLINE sehanode3 STABLE
ora.sehanode1.vip
1 ONLINE ONLINE sehanode1 STABLE
ora.sehanode2.vip
1 ONLINE ONLINE sehanode2 STABLE
ora.sehanode3.vip
1 ONLINE ONLINE sehanode3 STABLE
--------------------------------------------------------------------------------
※Databaseのホームが19.7なのは、2ノードで構成したときに何も考えていなかったから。19.0.0にすればよかった。
19.9のパッチを当てた理由は、「Local Restart Prevented after adding a service to a SEHA enabled CDB (Doc ID 31146826.8)」がfixされていることを確認したかったからです。無事直っていました。
