AOS6.0.1からサポートされたReplication Factor 1を試してみる

前回、AOS6.0.1からサポートされたRF1(Replication Factor 1)についてご紹介しました。前回は、うまく仮想マシンを作成できずに終わったのですが、今回RF1環境で仮想ディスクを作成することが出来ましたので、今回は、RF1での実際の動作についてご紹介します。

仮想ディスクにRF1のストレージコンテナを選択した場合

仮想マシンを作成時に、RF1のストレージコンテナの仮想ディスクを割り当てた仮想マシンは、Prismの仮想マシン一覧にも「RF1」と表示されます。

なお、通常のRFのストレージコンテナの仮想ディスクを割り当てている仮想マシンに、RF1のストレージの仮想ディスクを割り当てても、同様にこの「RF1」が表示されます。

Volume Groupの作成は可能か？

VolumeGroupで、RF1のストレージコンテナは選択可能かを試してみました。サラッと作成可能です。なお、仮想マシンと同様に一覧表示でRF1であることを確認することが出来ます。

RF1で作成した仮想マシンは、Live Migration可能か？

ホストに紐付いたストレージにデーターが書き込まれることを考えると、Live Migrationによる仮想マシンの稼働ホストを変更するのは無理かと思ったのですが、実はLive Migrationできます。あくまでもデーターが保存される場所が特定ホストに限定されるだけであり、このRF1のストレージは、共有ディスクで提供され、Nutanixクラスター内の各ホストにLive Migrationすることができます。

仮想ディスクをRF2のコンテナに移動できるか？

AOS 5.19からAHVに搭載された、仮想ディスクのストレージコンテナ間移動を利用して、RF1のストレージコンテナにある仮想ディスクをRF2のストレージコンテナに移動するコマンドを実行した場合どうなるかを試してみました。

vm.update_container RF1-TESTVM container=DEFAULT_CONTAINER wait=false

実行すると、コマンド自体はエラーもなく通ります。しかし、タスク自体はキューに入ったままで処理されることはありません。（ずっとタスクに残ったままになります）

ということで、ちょっとロックの仕方が甘い気もしますが、仕様通りRF1で作成した仮想ディスクを他のストレージコンテナに移動することは出来ないということになります。

DataProtectionでRF1の仮想ディスクを持った仮想マシンは保護できるのか？

仕様上、RF1の仮想マシンはスナップショット作成はサポートされていないという記載があります。実際にProtection Domainで保護を行おうとしたのですが、仮想マシンの一覧候補画面から、RF1の仮想マシンが除外される設定になっています。そのため、RF1の仮想マシンを保護対象に入れることは出来ません。

では、RF2のストレージコンテナの仮想ディスクを割り当てた仮想マシンを、Protection Domainに入れ、その後その仮想マシンにRF1の仮想ディスクを割り当てた場合はどうなるのでしょうか？
結論としては、仮想マシン自体のProtection Domainに該当の仮想マシンが残ったままとなりますが、Take Snapshotで意図的にスナップショットを作成しようとした場合、処理自体は実行されますが、実際にはスナップショット処理はスキップされた旨のアラートが発生します。

では、Protection DomainAHVの仮想マシンスナップショットではどうなるのかを確認したところ、スナップショットエラーのメッセージが表示されます。

スナップショットはRF1の場合、Protection Domainであっても、普通の仮想マシンスナップショットであってもいずれも取得できないということになります。

RF1ストレージコンテナのホスト上にあるCVMをシャットダウンした場合どのような動作になるか？

RF1の場合、特定のホストのストレージにしかデーターが書き込まれませんので、該当ホストのCVMがいなくなるとホストのSSDやHDDにアクセスできなくなるので、I/O処理が出来なくなるはずです。RF2など通常のストレージコンテナで動作しいている仮想マシンは、CVMがいなくなると、自動的にハイパーバイザーが別のCVMにパスを切り替えてI/Oを継続させる仕組みとなっているため影響はありません。
今回はCVMを正常にシャットダウンする、「cvm_shutdown -P」コマンドを実行してみます。

nutanix@NTNX-21SM9C999999-A-CVM:192.168.XXX.171:~$ cvm_shutdown -P now
2021-08-27 12:29:23,979Z INFO MainThread zookeeper_session.py:193 cvm_shutdown is attempting to connect to Zookeeper
2021-08-27 12:29:23,984Z INFO Dummy-1 zookeeper_session.py:625 ZK session establishment complete, sessionId=0x27b86ada51404b1, negotiated timeout=20 secs
2021-08-27 12:29:24,032Z INFO MainThread lcm_genesis_utils.py:47 Rpc to [192.168.XXX.172] for LCM [LcmFramework.is_lcm_operation_in_progress] is successful
2021-08-27 12:29:24,033Z INFO MainThread cvm_shutdown:174 No upgrade was found to be in progress on the cluster
2021-08-27 12:29:24,197Z INFO MainThread cvm_shutdown:91 Acquired shutdown token successfully
2021-08-27 12:29:24,438Z CRITICAL MainThread cvm_shutdown:206 Found powered on VMs with RF1 disks managed by the current CVM. Please proceed to shutdown with --auto_shutdown_rf1_vms flag, and the system will attempt to shut them down before proceeding with CVM shutdown. RF1 VMs: RF1-TESTVM

どうやら、RF1の仮想マシンがいるためシャットダウンが出来ない旨が表示されています。合わせて「--auto_shutdown_rf1_vms」というパラメーターが出てきました。

では、「shutdown -P now --auto_shutdow_rf1_vms」を実行してみましょう。

nutanix@NTNX-21SM9C999999-A-CVM:192.168.XXX.171:~$ cvm_shutdown -P now --auto_shutdown_rf1_vms
2021-08-27 12:36:40,467Z INFO MainThread zookeeper_session.py:193 cvm_shutdown is attempting to connect to Zookeeper
2021-08-27 12:36:40,472Z INFO Dummy-1 zookeeper_session.py:625 ZK session establishment complete, sessionId=0x17b86ada50204e9, negotiated timeout=20 secs
2021-08-27 12:36:40,512Z INFO MainThread lcm_genesis_utils.py:47 Rpc to [192.168.XXX.172] for LCM [LcmFramework.is_lcm_operation_in_progress] is successful
2021-08-27 12:36:40,513Z INFO MainThread cvm_shutdown:174 No upgrade was found to be in progress on the cluster
2021-08-27 12:36:40,560Z INFO MainThread cvm_shutdown:91 Acquired shutdown token successfully
2021-08-27 12:36:40,842Z INFO MainThread cvm_shutdown:217 Found powered on VMs with RF1 disks managed by the current CVM. The system will attempt to automatically shut them down before proceeding with the CVM shutdown. RF1 VMs: RF1-TESTVM
2021-08-27 12:36:40,842Z INFO MainThread cvm_shutdown:116 Validating command arguments.
2021-08-27 12:36:40,842Z INFO MainThread cvm_shutdown:119 Executing cmd: sudo shutdown -k -P now
2021-08-27 12:36:41,005Z INFO MainThread cvm_shutdown:99 Setting up storage traffic forwarding
2021-08-27 12:36:41,016Z WARNING MainThread genesis_utils.py:145 Deprecated: use util.cluster.info.get_factory_config() instead
2021-08-27 12:36:41,021Z INFO MainThread genesis_utils.py:3192 Verifying if route is set for 192.168.XXX.171
2021-08-27 12:36:41,445Z INFO MainThread genesis_utils.py:3197 HA Route is not yet set for 192.168.XXX.171
2021-08-27 12:36:43,824Z INFO MainThread genesis_utils.py:3197 HA Route is not yet set for 192.168.XXX.171
2021-08-27 12:36:46,249Z INFO MainThread zookeeper_session.py:193 cvm_shutdown is attempting to connect to Zookeeper
2021-08-27 12:36:46,253Z INFO Dummy-2 zookeeper_session.py:625 ZK session establishment complete, sessionId=0x37b86b195f204c9, negotiated timeout=20 secs
2021-08-27 12:36:46,266Z INFO MainThread genesis_utils.py:1948 The CVM 192.168.XXX.171 is not in maintenance mode
2021-08-27 12:36:46,281Z INFO MainThread cluster_upgrade.py:824 ZK path /appliance/logical/genesis/rf1_vms is empty for SVM 3
2021-08-27 12:36:46,310Z INFO MainThread ahv_rf1_api_impl.py:258 Sending acropolis task HandleRf1VmBeforeAosMaintenance to SVM ID 3 to listed RF1 VMs, task_uuid 7fc7b917-d161-49a6-bc17-9dbdef499e05
2021-08-27 12:36:46,313Z INFO Dummy-3 client.py:232 Creating stub for Ergon on 192.168.XXX.171: 2090
2021-08-27 12:36:46,688Z INFO MainThread cluster_upgrade.py:844 Setting RF1 VM list into the ZK path /appliance/logical/genesis/rf1_vms for SVM 3, VM UUID list: ['90ba4083-ad15-40d2-8434-a1d299bacdd0']
2021-08-27 12:36:46,713Z INFO MainThread ahv_rf1_api_impl.py:258 Sending acropolis task HandleRf1VmBeforeAosMaintenance to SVM ID 3 to shut down RF1 VMs, task_uuid bbcd24f6-3ec2-4fed-b71e-d444fa2320de
2021-08-27 12:37:18,329Z INFO MainThread cluster_upgrade.py:851 Successfully complete handling RF1 VMs task before CVM 3 shutdown
2021-08-27 12:37:18,340Z INFO MainThread genesis_utils.py:1810 Adding entry of planned_outage in planned_outage_history
2021-08-27 12:37:18,341Z INFO MainThread genesis_utils.py:1870 Planned outage entry is start_time: 1630067838

reason: "CVM shutdown"

2021-08-27 12:37:18,348Z INFO MainThread configuration_validator.py:962 Did Configuration Validator succeed : True
2021-08-27 12:37:18,394Z INFO MainThread genesis_utils.py:1826 Configured CVM 192.168.XXX.171 with maintenance mode status True
2021-08-27 12:37:18,399Z INFO MainThread cluster_upgrade.py:905 Stopping all services before reboot
2021-08-27 12:37:18,399Z INFO MainThread cluster_upgrade.py:905 Stopping all services before reboot
2021-08-27 12:37:54,131Z INFO MainThread cluster_upgrade.py:914 Attempting to stop any remaining services forcefully!
2021-08-27 12:37:54,141Z INFO MainThread service_utils.py:1097 No process has lock_path /home/nutanix/data/locks/catalog open
...

RF1の仮想マシンが自動でシャットダウンされた後、CVMは正常にシャットダウンされました。

なお、CVMが復活すると自動でシャットダウンされたRF1の仮想マシンが起動します。この動作からすると、アンチアフィニティルールが指定されている仮想マシンが、ハイパーバイザーのアップデートなどでライブマイグレーションが出来ない仮想マシンをシャットダウンし、アップデート完了後に起動する動作と同じ挙動のように思われます。

では、RF1で作成したVolume Groupを他のホストでRF2で稼動中の仮想マシンにSCSI Direct Attachすると、この仮想マシンもシャットダウンされるのかも確認してみたところ、SCSIダイレクトアタッチでVolumeGroupのディスクをマウントした仮想マシンは正常にシャットダウンされました。（おそらくiSCSI経由の接続の場合、OS制御が出来ませんので無視してシャットダウンされると思われます）

少しだけですが、RF1の挙動について調べてみました。Nutanix上ではRF1の利用は制約があることから制約のロックもそれぞれUIレベルで行われていることが分かりました。

PrismのData Resiliency Status部分には、RF1の仮想ディスクが幾つ存在するかも数量が表示されています。

RF1は、検証等々では便利ですが、制約が多いので、ご利用は計画的に。

AOS6.0.1からサポートされたReplication Factor 1について

先日AOS 6.0リリースの紹介をしましたが、AOS6.0.1から新たにサポートされる機能があります。それは「Replication Factor 1」です。

本来、データーの冗長性から考えてデーターを二重化（ないしは三重化）しないというのは、大事なデーターを保存する上であり得ない話しですが、逆に言うと大事ではないデーターを二重化するのは、ストレージ容量がもったいないと考えることも出来ます。極端な話し消えても問題ないデーターを保存する際に、このRF1を活用するという物です。

かといって、RF1を多用すると確実に事故が発生しますので、Nutanixでは、RF1の利用について厳しく制限が設けられております。

• RF1コンテナは、レプリケーション係数の増加をサポートしていません。
  （RF1からRF2への変更）
• RF1コンテナは、AHVイメージサービスで利用するISOやDISKの保存をサポートしていません。
• RF1コンテナでは、Reserved Capacityの設定は許可されていません。
• ホストのメンテナンス作業を行う場合、RF1の仮想マシンは停止する必要があります。（RF1の仮想マシンは、ライブマイグレーションできません）
• AHV/ESXi環境のみをサポートします。HyperV環境はサポートされていません。
• パフォーマンス上の理由から、SSD層の容量がクラスター容量の6％未満であるクラスターにRF1ストレージを構成することはお勧めしません。
• RF1の仮想マシンは、スナップショットやレプリケーションはサポートされていません。
• ESXiクラスターをAHVクラスターに変更は､サポートされません。
• イレイジャーコーディングや重複排除は、RFストレージコンテナではサポートされません。
• ストレージコンテナのゴミ箱機能はサポートされず削除したデーターは即座に削除されます。
• RF1 vDiskを備えたVMは、DRおよびMetro-Clusters環境ではサポートされていません。
• 以下のメンテナンスを行う場合、RF1の仮想マシンはシャットダウンする必要があります。
• ワンクリックのAOSアップグレード
• CVMのシャットダウン
• ホストのメモリの更新
• ESXワンクリックハイパーバイザーのアップグレード
• ネットワークセグメンテーションワークフロー
• ローリングリブートフレームワーク（AHVでの仮想スイッチサポートの有効化）
• ホストブートディスクの交換

ここで重要なことは、AOSのアップグレードであっても、RF1の仮想マシンはシャットダウンしなければいけないというのは、気になる表現です。

これは、RF1のストレージコンテナは、ノード毎に作成されるという仕様に起因しています。そのため、RF1で作成した仮想マシンはノードのローカルストレージで動作している形になりますので、ライブマイグレーションが出来ないという制限事項があります。

そのため、以下のような制限が発生します。

• ノードの削除-RF1のあるノードをクラスターから削除すると、RF1vDiskとコンテナーに削除されます
• ノードの一部のディスクやフラッシュが故障し交換した場合、RF1の仮想マシンは削除されます。
• ストレージ専用ノードを搭載したクラスターの場合、コンピュートノードのにのみRF1のストレージコンテナを作成できます。

Nutanixの各アプリケーションもサポート可否が明確に記載されています。

Nutanix Era / Files / Carbon /Objects  / Prism Central

RF1ストレージコンテナを領域の一部で利用することや、仮想アプライアンス自体をRF1のストレージコンテナに展開することはサポートされていません。

もはやここまで制限されると何の意味があるのかと思う気もしますが、先程記載したとおり、データーを保存する領域ではなく、データーベースのテンポラリーやAI,機械学習のデーターの学習用データーの保存場所としての活用が考えられます。

では、RF1のストレージコンテナの作成方法をご紹介します。

PrismのSettingsから「Redundancy State」を選択し、「Enable Replication Factor 1」にチェックを入れます。

RF1の制限事項が表示されますので確認してYesをクリックします。

元の画面に戻ったら「Save」ボタンをクリックし設定を終えます。

PrismのStorageメニューに進み、「+ Storage Container」をクリックします。

REPLICATION FACTORを選択し「1」を選択します。

すると、ドロップダウンリストが追加されます。このストレージコンテナをどのノードで作成するかの選択肢が追加されます。

予約は出来ないと言う制限がある一方でRESERVED CAPACITYが入力できますが、こちらは値を入れると、設定保存できません。なお、Advatized Capacityは設定可能です。
重複排除やイレイジャーコーディングは、明確に画面上にロックがかかっています。

Saveすればこれでストレージコンテナの作成は完了です。制約事項を除けば、通常のストレージコンテナ作成と何も変わりません。

では、仮想マシンを作成する際にこのRF1のストレージコンテナをどのように選択するのでしょうか？

通常通り仮想マシン画面から「+ Add New Disk」をクリックし、仮想ディスクを作成したいストレージコンテナをドロップダウンリストから一覧を表示させると、RF1のストレージコンテナは、横側にホスト名が表示されます。

AOS 6.0.1は、AOS 6.0.1.1として、8/27にリリース予定となります。

今回AOS6.0.1の環境でRF1の仮想ディスクを作成しようとしたところ、正しく作成が出来ませんでしたので、おそらくAOS6.0.1.1でここも修正されるのではないかと思います。
（本当は仮想ディスク作成後の動作もご紹介したかったのですが...）

RF1の利用は限定的ですが、テンポラリーの仮想マシンや検証用の仮想マシンですぐに削除する物であれば、RF1はリソースの削減として利用可能と思います。（とくに容量単価が高いオールフラッシュの場合は、コスト面のメリットもあります）

ただ、あくまでもデーターの冗長性がないので、データーベースなど大事なデーターを保存する場合には、くれぐれも利用しないようにしてください。

（その６）Nutanix上にWindows+Oracle SEHA環境を構築する

前回までにOracleの構築は完了しました。最後に仕上げの設定とクライアントからの接続テストを行いたいと思います。

26.アンチアフィフィニティの設定

今回アクティブのサーバーとスタンバイのサーバー２台の仮想マシンを作成しましたが、２台の仮想マシンが、同一のNutanix上で稼動するホストで動作していた場合、物理ホストに障害が発生すると、ハイパーバイザーのHAが稼動し別のホストで仮想マシンが再起動します。別にこれであっても問題があるわけではありませんが、２台のサーバーが同時に落ちてしまい、ハイパーバイザーのHAでOSから再起動する時間を考えると、２台の仮想マシンは別のホストで稼働し、仮にアクティブなサーバーが稼動する物理ホストが落ちてもすぐに他の物理ホストで稼動していたスタンバイサーバーに切り替わる方が、より早くサービス復旧が可能となります。

このような、２台のサーバーを同じ物理ホストで稼働させない設定を行うことが出来ます。
vSphereの場合、Enterprise Plusに搭載されるDRSの中にある機能で、AHVの場合は、ADSの機能でそれぞれアンチアフィニティールールで設定を行います。

今回は、AHVでの設定をご紹介します。

まず、CVMにSSHで接続します。

SSHでacliコマンドレットに入り、以下のコマンドを入力します。

acli

vm_group.create oraseha

vm_group.add_vms oraclelk vm_list=ORA19CSEHA01,ORA19CSEHA02
#保護対象の「ORA19CSEHA01」と「ORA19CSEHA02」をグループに入れる

vm_group.antiaffinity_set oraseha

exit

これで、「ORACLE19C-LK01」と「ORACLE19C-LK02」が同一のサーバーで稼動しない設定が完了しました。

27.クライアントからの接続

今回は、Grid Infrastructureで、SCAN-VIPを設定しましたので、TNSNAMESにSCANでの登録を行います。

サービス名を設定します。

ホスト名はSCAN名をFQDNで入力します。

あとは、SQL*PLUSで接続し、接続が成功すればOKです。

これで設定は完了です。

Oracle SEHAは、Grid Infrastructureに紐付いているため、Oracle RACの知識があれば比較的同じスキルで構築可能であると思います。

一方で、ドメイン参加が必要な点など一部考慮する点はありますが、これはOracle Fail SafeであってもWSFCの仕様でドメイン参加が必要でしたのであまり変わりは無いと思います。

Oracleの冗長化について、ご紹介してきましたが、NutanixはLifeKeeperであってもOracle　SEHAであっても、ましてはOracle RACであっても正常に稼動します。

今回はWindows版で構成しましたが、Linux版であってもNutanix上で問題なく動作します。

（その５）Nutanix上にWindows+Oracle SEHA環境を構築する

前回までの、Oracle Database インスタンスの作成が完了しました。
残りの作業もあとわずかです。早速、2号機にOracle Database Softwareを導入します。

21.addonnodeコマンドで、2台目のサーバーを設定

1号機マシンでコマンドプロンプトを開き、以下のコマンドを入力します。

SET ORACLE_HOME=d:\app\oracle\product\19.0.0\dbhome_1
%ORACLE_HOME%\addnode\addnode.bat -silent CLUSTER_NEW_NODES=ora19cseha02

2号機にバイナリーのコピーが行われます。

22.LISTNERの設定変更

DB作成時のローカルリスナーをGrid Infrastructureのリスナーに変更します。

1号機のサーバーで以下のコマンドを入力し、現行のリスナー情報を確認します。

d:\app\oracle\product\19.0.0\dbhome_1\bin\sqlplus / as sysdba
/* 以下はSQL*PLIUS内で入力 */
show parameter local_listener;
alter system reset local_listener;
exit

Show Parameterで、ローカルリスナーが存在していることを確認し、alter systemコマンドで、local_listenerをリセットします。

続いて、データーベースを再起動します。

d:\app\19.0.0\grid\bin\srvctl stop database -db orcl
d:\app\19.0.0\grid\bin\srvctl start database -db orcl

再び、SQLPLUSでログインし、リスナーの状態を確認します。
Grid Infrastructureから自動で割当られたリスナーになっていることを確認します。

d:\app\oracle\product\19.0.0\dbhome_1\bin\sqlplus / as sysdba
/* 以下はSQL*PLIUS内で入力 */
show parameter local_listener;
exit

これで、リスナーの設定は完了です。

23.コンテナDBの自動起動

コンテナデーターベースが自動で起動するように以下の設定を入れます。

d:\app\oracle\product\19.0.0\dbhome_1\bin\sqlplus / as sysdba
/* 以下はSQL*PLIUS内で入力 */
/* コンテナDBを起動 pdbはコンテナDB名 */
alter pluggable database pdb open;
/* 自動起動(現在のステータスを記憶) */
alter pluggable database all save state;
exit

これで、インスタンスの起動と同時にコンテナDBも自動起動します。

24.ノードの追加

現状では、データーベースインスタンスは、1号機でしか稼働していません。
これを2号機でも稼働するように設定します。

コマンドプロンプトで以下のコマンドを入力します。

d:\app\19.0.0\grid\bin\srvctl modify database -db orcl -node ora19cseha01,ora19cseha02
d:\app\19.0.0\grid\bin\srvctl config database -db orcl

構成されたノードに「ora19cseha01」と「ora19cseha02」が入っていることを確認します。

これで、SEHAの構成は完了です。

25.オペレーションの紹介

リロケート（インスタンス稼働ホストを切り替える）
※2号機への切り替えの場合

srvctl relocate database -db orcl -node ora19cseha02

「crsctl stat res -t」コマンドを利用して、インスタンスの場所を確認します。

指定したサーバーでのインスタンス起動

srvctl start database -db orcl -node ora19cseha01

「crsctl stat res -t」コマンドを利用して、インスタンスの場所を確認します。

各種オペレーションは、Oracle RACと同じオペレーションが可能です。
（シャットダウンや起動方法も同様に）

（その４）Nutanix上にWindows+Oracle SEHA環境を構築する

前回までにGrid Infrastructureのインストールを終えました。今回は、Grid Infrastructureのパッチ適用とOracle Databaseのインストール、パッチ適用を行います。

17.Grid Infrastructureのパッチ適用

まず、現行のサービスの稼動状態を確認します。
こちらは、2台のサーバーそれぞれ両方で作業を行ってください。

コマンドプロンプトを起動し、「d:\app\19.0.0\grid\bin」ディレクトリに移動し、以下のコマンドを実行します。

crsctl stat res -t

各サービスがサーバー2台で動作していることを確認します。

パッチを適用するため、以下のコマンドを入力しサービスを停止します。

crsctl stop crs -f

全てのサービスが終了したことを確認します。

Windowsのサービスで起動している2つのサービスを手動で停止します。

まずこの作業までを2台のサーバーそれぞれで予め行ってください。

まず、完全にプロセスが終了しているかを確認します。

crsctl stat res -t -init

実行後、

CRS-4639: Oracle高可用性サービスと通信できませんでした
CRS-4000: コマンドstatusは失敗したか、またはエラーのある状態で完了しました。

が出力されればOKです。

これからパッチの適用を行います。
パッチの適用は、パッチと共に提供されるReadmeを参考にパッチを適用してください。

以下のコマンドを入力します。

SET ORACLE_HOME=d:\app\19.0.0\grid
%ORACLE_HOME%\crs\install\roothas.bat -prepatch

続いて1号機のサーバーに以下の手順でパッチを適用します。

cd d:\app\bu\32409153\32409154
SET ORACLE_HOME=d:\app\19.0.0\grid
d:\app\19.0.0\grid\opatch apply -local

画面の指示に従い、パッチを適用します。

続いて、FenceDriverを更新します。

%ORACLE_HOME%\bin\crssetup.exe deinstallfence
%ORACLE_HOME%\bin\crssetup.exe installfence

パッチの適用が終わったら、以下のコマンドでパッチが適用されたかを確認します。

d:\app\19.0.0\grid\opatch\opatch lsinventory

パッチ「32409154」が適用されていることを確認します。

パッチ適用が完了したら、以下のコマンドを実行します。

%ORACLE_HOME%\crs\instal\rootcrs -postpatch

2号機のサーバーは、Oracleのパッチファイルが展開されていませんので、手順12のOracleのソフトウェアバイナリ部分に記載されているOracleのパッチを展開する部分の作業を行ってください。

パッチ配置後、Opacheを使ってパッチを適用します。

なお、OPatch適用における注意点をお伝えします。

まず1つは、「OPatch faild with error code = 73」です。こちらは、なにかしOPatchでアップデートが必要なファイルが開かれている状態の時に表示されます。

Windowsの場合、OSの様々なシステムプロセスとの依存があり、Oracle系のサービスを全て停止した上でもこのエラーコード73が出てパッチが適用できないケースがあります。
この場合、Oracleに関連するサービスを自動起動から手動にした上で、OSを再起動して再度試してみてください。
大半は、サービス停止でこのエラーは出なくなりますが、それでも状況が改善しない場合、MSConfigツールから、セーフブートでOSを起動し、OPatchを適用してください。

もう1つの課題は、パッチ適用後、「CRS-6706: Oracle Clusterwareリリース・パッチ・レベル('1389892003')はソフトウェア・パッチ・レベル('0')と一致しません。Oracle Clusterwareを起動できません。」や「CRS-4000: コマンドStartは失敗したか、またはエラーのある状態で完了しました。 」が表示され、Clusterwareが起動しないケースです。

こちらの場合は、以下のコマンドを実行します。

%GI_HOME%\bin\clscfg -localpatch

（参考）Oracle Clusterwareの起動に失敗した場合のパッチの適用

今回、GI_HOMEは、「d:\app\19.0.0\grid」になります。

このコマンドを実行後、「d:\app\19.0.0\grid\bin\crsctl start crs -wait」でクラスターサービスを実行します。

これで2台のGrid Infrastructureの起動が完了しました。

18.Oracle Databaseのインストール

では、1号機のサーバーにOracle Databaseのインストールを行います。
引き続き、ユーザーは、ドメインユーザーの「oracle」にて操作を行います。

ORACLE_HOMEである、「d:\app\oracle\product\19.0.0\dbhome_1」の「setup.exe」を実行します。

ウィザードがスタートします。ここでは、ソフトウェアのみをインストールします。

Grid Indrastructureがインストールされているため自動で、RAC構成が選択されますが、SEHAは、RACではありませんので、「単一インスタンス・データーベースのインストール」を選択します。

SEHAは、Standard Edition 2に提供される機能ですので、「Standard Edition 2」を選択し、次に進みます。

Orackeホームユーザーの設定は、Grid Infrastructureの時と同じ、ドメインユーザーの「orahome」ユーザーを指定します。

続いてORACLE_BASEを設定します。ここでは「d:\app\oracle」を指定します。

サマリー場表示されますので、確認後「インストール」をクリックします

インストールが行われます。インストールが完了したら、ウィザードを終了させてください。

19.Oracle Databaseへのパッチ適用

Clusterwareを含め一度、Oracle関連のソフトウェアをすべて停止します。

d:\app\19.0.0\grid\bin\crsctl stop crs -f

サービスを含めOracle関連のプログラムが起動していないことを確認して下さい。

続いて以下のコマンドからOpatchでパッチ適用を行います。

set ORACLE_HOME=d:\app\oracle\product\19.0.0\dbhome_1
cd d:\app\bu\32409154\32409154
d:\app\oracle\product\19.0.0\dbhome_1\opatch\opatch apply

OPatch successfulとなったら、パッチ適用完了です。

20.Oracle Database インスタンスの作成

では、Databaseのインスタンスを作成します。

まずは、2台のノードでパッチ適用のためシャットダウンしたGrid Indrastructure関連のサービスを起動します。（2台のサーバーでそれぞれ実行してください）

d:\app\19.0.0\grid\bin\crsctl start crs -wait

各サービスが起動したことを確認します。

ASM構成アシスタントを起動します。

d:\app\19.0.0\grid\bin\asmca

ディスク・グループを選択し、「作成」をクリックします。

ディスクグループを「DATA」にし、冗長性を「外部」にします。
そして、スタンプ済みの「DATA」を選択します。
（もし、DATAというディスクが出てこない場合、LUNに対してラベルが設定されていないことが考えられます。「d:\app\19.0.0\bin\asmtoolg」を実行し、ボリュームのスタンプを行った後でもう一度、asmcaを実行し設定を行います）

作成した「DATA」のディスクグループが見えていることを確認し、終了します。

これでASMCAの設定は終わりです。

Database Configuration Assistantを以下のコマンドを実行し、起動します。

d:\app\oracle\product\19.0.0\bin\dbca

ウィザードが表示されます。「データーベースの作成」を選択し、次に進みます。

データーベースの作成は、拡張構成で行います。「拡張構成」を選択し、次に進みます。

データーベースは「Oracle単一インスタンス・データーベース」を選択し、「カスタム・データーベース」を選択し次に進みます。

ここでは、サービス名を「orcl.toriten.oita」SIDを「orcl」とし、コンテナデーターベースとして「pdb」を作成します。

データーベースの記憶域属性を「自動ストレージ管理（ASM）」を選択し、参照ボタン苦をクリックします。

先ほどASMCAで作成した「DATA」のディスクグループを選択し、「OK」をクリックします。

データーベース・ファイルの位置が「+DATA\{DB_UNIQUE_NAME}」になっていることを確認し、次に進みます。

今回は、高速リカバリ領域の指定を行います。（FRAを利用します）
高速リカバリ領域が「+MGMT」になっていますので、今回は、「＋DATA」を選択します。

参照ボタンをクリックします。

DATAを選択します。

高速リカバリ領域が「+DATA」になったことを確認し、次に進みます。

LISTENERは、Grid Infrastructureで設定したLISTNERを選択し、次に進みます。

データーベースコンポーネントを選択します。今回はすべてのチェックを外して次に進みます。（画面が隠れて Oracle Database Extended for .NETが見えてないことがありますので、ウィンドウサイズを下に広げてください）

構成オプションは、画面のように設定しています。こちらも利用するデーターベースによって異なりますので、必要な要件通りに設定を行ってください。
(今回は、キャラクタ・セットに「JA16SJISTILDE」を指定しています）

今回は、Enetrprise Manager Database Expressの構成のチェックを外します。
（今回はEMは作成しません）

パスワードは「すべてのアカウントに同じパスワードを使用」を選択し、パスワードに「Nutanix4u-」を入力します。
Oracleホームのユーザー・パスワードは、Active Directoryで作成した「orahome」ユーザーのパスワードを指定し、次に進みます。

データーベースの作成にチェックを入れ、「次へ」をクリックします。

サマリーが表示されますので、終了ボタンをクリックします。

データーベースを作成が完了するまでしばらく時間がかかります。

データーベースの作成が完了したら、「閉じる」をクリックします。

これでインスタンスの作成も完了しました。次は、2号機のサーバーにOracle Databaseソフトウェアの展開と、SEHAのクラスター構成を行っています。