2021年8月10日火曜日

(その2)Nutanix環境上にLife Keeper for Windowsを利用したOracleのHAクラスターを作成する

前回までに、Nutanix側の設定をメインに構成しました。
今回は、続きとしてWindows側の設定を行っていきます。

7.ホスト名の設定

起動した2台の仮想マシンのホスト名を設定します。ここでは、以下のとおりホスト名を設定します。

仮想マシン名ホスト名
ORACLE19C-LK01ora19cdb01
ORACLE19C-LK02ora19cdb02


以下のようにそれぞれホスト名を設定し、Windows Serverを再起動します。


8.NICの設定

まずはそれぞれのNIC名称を変更します。ここでは、Nutanix上で設定しているVLAN名のと同じ名称に変更します。


続いて、NICの設定を行います。以下のようにIPアドレスの設定を行います。

仮想マシン名NICIPアドレスネットマスクデフォルト
ゲートウェイ
メトリック
ORACLE19C-LK01
SERVICE192.168.32.91255.255.255.0192.168.32.25410
HB172.17.0.91255.255.255.248-100
iSCSI192.168.38.91255.255.255.0-200
ORACLE19C-LK02
SERVICE192.168.32.92255.255.255.0192.168.32.25410
HB172.17.0.92255.255.255.248-100
iSCSI192.168.38.92255.255.255.0-200


まず1号機「ORACLE19C-LK01」の設定を行います。

サービス系(SERVICE)のNICの設定

▼NICの設定


▼IPアドレス設定


▼メトリック値を10に設定



コミュニケーションパス(HB)のNIC設定

▼NIC設定
SMBとIPv6は利用しないため、チェックを外す


▼IPアドレスの設定


▼メトリック値を100に設定


▼DNSの登録のチェックを外す

ストレージパス(iSCSI)NICの設定

▼IPアドレスの設定
SMBやIPv6は利用しないため、チェックを外します。


▼IPアドレスの設定


▼メトリック値を200に設定


▼DNSの登録のチェックを外す

同じ設定(IPアドレス以外)を「ORACLE19C-LK02」のホストにも行っていきます。


9.メディア検出の無効化

TCP/IPのメディア検出設定を無効化します。

レジストリエディタ(regiedit.exe)を起動し、
「HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters」を開きます。

パラメーター「DisableDHCPMediaSense」をDWORDで設定し値を「1」にします。


10.Distributed Link Tracking Clientの自動起動停止

Windowsのサービスから「Distributed Link Tracking Client」を開き、スタートアップの種類を「手動」に変更します。



11.iSCSI経由でNutanix Volumesをマウント

コントロールパネルからiSCSIイニシエーターを開きます。


サービスの自動起動の確認が行われますので、「はい」をクリックします。


Nutanixで設定したDATA SERVICE IPを入力し、「クイック接続」をクリックします。


Nutanix Volumesで設定した2つのLUNが見えます。それぞれのLUNを選択し「接続」ボタンをクリックします。

同様の設定を、「ORACLE19C-LK02」側も設定を行います。


12.ストレージの設定

スタートボタンを右クリックし、「ディスクの管理」を開きます。


まずは、CDROMドライブのドライブレターを変更します。


ドライブレターをZに変えます。


同様にもう1台のCDROMドライブを変更し、YドライブとZドライブに変更します。


続いて、各ドライブをフォーマットしていきます。

まずディスク1は、仮想マシンのローカルディスクとして構成しています。初期化を行い、GPTパーティションとして設定します。



続いてシンプルボリュームでDドライブとして構成します。


ドライブレターをDドライブとして設定します。


ボリュームラベルは、「ORAHOME」と設定し、クイックフォーマットを行います。


同様にディスク2もGPTで初期化後、シンプルボリュームで作成します。

▼Oドライブ(Oracleデーターファイル配置場所)



同様にディスク3もGPTで初期化後、シンプルボリュームで作成します。

▼Pドライブ(アーカイブログ配置エリア)



次に、2台目の「ORACLE19C-LK02」のディスクの管理を開きます。

最初にCDROMドライブを1号機の「ORACLE19C-LK01」と同様に「Z」ドライブと「Y」ドライブに、ドライブレターを割り付けなおします。


続いて同様にディスク1をDドライブとして設定しラベルに「ORAHOME」として設定します。


続いて、Nutanix Volumesから見ている共有ディスクボリューム(ディスク2,ディスク3)を、オンラインにします。

ドライブレターは、1号機の「ORACLE19C-LK01」と同じレターにする必要があるため、CDROMドライブのドライブレター変更と同じ要領で、それぞれ「O」と「P」ドライブに変更します。

▼変更前

▼変更後



ここまでで基本設定は終わりました。次回は、LifeKeeperのインストールを行います。




2021年8月9日月曜日

(その1)Nutanix環境上にLife Keeper for Windowsを利用したOracleのHAクラスターを作成する

Oracle19cになって、日本では多く採用されていたOracle Standard Edition 2(SE2)でのReal Application Clusterのサポートが廃止となりました。あわせて、Windows版でのOracleクラスター構築ではおなじみであった、Oracle Fail Safeが非推奨となりました。OFSはあくまでも非推奨であり、サポートされないわけではありませんが、今後のOracleのリリースとともにOFSは廃止される可能性があります。

では、このような状況にあってOracle SE2利用時のクラスター作成はどのようにすればよいのかというご相談をいただくことが増えてきました。

今回は、OFSからの移行先の一つである、SIOS Life Keeper for Windows版をNutanix AHV上で構成した場合の導入手順についてご紹介いたします。
AHVの場合、SCSI Direct AttachでのVolumes接続も可能ですが、今回はvSphereでの設定も考慮し、iSCSI経由での設定方法をご紹介します。

環境情報は以下の通りです。

OSWindows Server 2019 Standard
ドメイン構成ワークグループ
Oracle VersionOracle SE2 19.3
共有ディスクNutanix Volumes (iSCSI)
LifeKeeper for Windows8.7.2-1
AOS6.0


構成図としては、以下の形となります。


Oracleのインスタンスの情報などは、データーベースの作成の個所でご紹介いたします。

手順としては以下の流れになります。

  1. Data Service IPの設定
  2. 仮想マシンの作成
  3. Windows Server 2019のインストール
  4. 仮想マシンのクローン
  5. Volume Groupの作成
  6. Sysprepを実行(任意)
  7. ホスト名の設定
  8. NICの設定
  9. メディア検出の無効化
  10. Distributed Link Tracking Clientの自動起動停止
  11. iSCSI経由でNutanix Volumesをマウント
  12. ストレージの設定
  13. LifeKeeperのインストール
  14. コミュニケーションパスの設定
  15. 仮想IPの作成
  16. 共有ディスクの登録
  17. 依存関係の作成
  18. Oracleユーザーの作成
  19. Oracleバイナリの展開・インストール
  20. データーベースインスタンスの作成
  21. セカンダリサーバーでのインスタンス作成
  22. 権限設定
  23. PDBの自動起動
  24. リスナー設定
  25. OracleサービスをLifeKeeperで保護する
  26. アンチアフィフィニティの設定
  27. サービス起動順序の制御


1.Data Service IPの設定

まずはNutanix VolumesでiSCSI接続ができるよう、「DATA SERVICE IP」の設定を行います。Prismの左上にあるクラスター名をクリックします。


ここで表示されるVirtul IPを設定します。Network Segmentation機能を利用していない場合は、CVMが設定されるIPアドレスと同じセグメントである必要があります。


2.仮想マシンの作成

では早速仮想マシンの作成から行っていきましょう。

今回は以下の構成で作成しています。Oracle Databaseは、用途によってCPUやメモリーを多く必要とする場合がありますので、必要に応じて構成を変更してください。

仮想マシンスペック

vCPU6
RAM12GB
ディスク構成
Cドライブ100GBWindowsインストール場所
Dドライブ100GBOracle インストール場所


Prism上で仮想マシンを作成します。
今回は、仮想マシン名を「ORACLE19C-LK01」としています。


ドライブ構成は、Cドライブ(OS領域)とDドライブ(ORACLE_HOME領域)の2つの仮想ディスクを構成します。
さらに、CDROMドライブを2つ構成し、1つは「VIrt IO Driver」を、もう1つは、「Windows Server 2019」のISOをマウントします。



続いてNICの構成ですが、LifeKeeperは、ハートビート通信のようなクラスターの裏側ネットワークとして「コミュニケーションパス」を作成する必要があります。コミュニケーションパスは、サービス系のネットワークと共にハートビート専用に別のVLANの2つを用意します。ここでは、「SERVICE」をサービス系、「HB」をコミュニケーションパス専用のハートビートネットワーク、NutanixのVolume Groupと接続するストレージパス用に「iSCSI」のそれぞれVLANを割り当てたNICを設定します。




以上の設定が出来たら、Saveで仮想マシンを保存します。
この時点で仮想マシンの作成は1台でよいです。


3.Windows Server 2019 のインストール

Windows Server 2019 Standardをインストールします。


必要なツールも併せてインストールしておきます。

OSのインストールが終わったら、一度仮想マシンをシャットダウンします。


4.仮想マシンのクローン

続いて、仮想マシンをクローンします。

PrismのVMから「ORACLE19C-LK01」を選択し、Cloneをクリックします。


仮想マシン名は「ORACLE19C-LK02」として、クローンを行います。


仮想マシンが、01と02で2台できたことがわかります。


Nutanixですからクローンは一瞬で終わると思います。
クローンが終わったら、作成した2台の仮想マシンを起動します。

5.Volume Groupの作成

次に、Volume Groupを作成します。
PrismのStorageメニューから、VolumeGroupを作成します。



今回はボリュームグループ名を「ORACLE19C-LIFEKEEPER」と設定します。
Add New Diskから、今回共有ディスクで利用する「Oドライブ」と「Pドライブ」にあたる2つの共有ボリューム(LUN)を作成します。今回はOドライブを200GB、Pドライブを100GBで構成します。

Oドライブ

Pドライブ


2つのLUN作成が終わると、以下のように200GB、100GBの順でドライブが見えるようになります。

次に、Volume Groupに接続する仮想マシンを登録します。AHVで直結の場合は、「Attach a VM」でダイレクトにSCSIバスを使った接続が可能です。今回はiSCSIを利用した接続を行うため、Clientの登録を行います。

ここでは、iSCSIのイニシエーターのIQNの登録を行います。IQNは文字列が長いため、入力間違いをする可能性もあります。そのため、Nutanix Volumesでは、IQN以外にiSCSIで接続するIPアドレス(iSCSIイニシエーターが利用するIP)を登録することで、ストレージボリュームのアクセスを許可させることが出来ます。今回はCHAP Authentificationは、利用しませんのでこのままAddします。

続いて2台目のVMのIPアドレスを登録します。登録の際にメッセージが表示されますが、これは1つのストレージボリュームを複数の仮想マシンからアクセスする場合、クラスターソフトウェアで制御する必要がある旨のメッセージが表示されます。今回はLife keeperを利用したクラスター構成を作成するため特に問題はありません。そのまま、「Allow」をクリックします。

2つの仮想マシンのIPアドレスが登録されたら、以下のように一覧に表示されます。
iSCSIで利用するIPアドレスが登録されていることを確認し、Saveをクリックし、Volume Groupの設定を終えます。


6.Sysprepの実行(任意)


今回WorkGroupでの利用のため、必要に応じてとなりますが、「ORACLE19C-LK01」クローンして、「ORACLE19C-LK02」を作成しているため、SIDが重複した状態となっています。AD参加をしない場合そこまで気にする必要はありませんが、必要に応じてSysprepを実行してください。
Sysprepについては、「Windows7以上でデバイスドライバー消さずに簡易的にsysprepを行う方法」を参考に行って下さい。


下準備は出来ましたので、次は仮想マシンの設定に入っていきます。





2021年7月23日金曜日

Nutanix LCMのおさえておきたいポイント

今まで数回にわたってLCMについて記載をしてきました。LCMは頻繁にバージョンアップが行われており、機能が常に増えております。

今日は2021年7月現在のLCMの事情とLCMの動作ポイントについてご紹介していきます。


Q.LCMとSoftware Updateはどう使い分ければ良いのですか?

最近大変多く聞かれるご質問の一つです。従来Nutanixは、ソフトウェアのアップデートを簡潔化するためOne Click Updateという名のもと、AOSやハイパーバイザーのローリングアップデート機能を提供しました。さらに、NXモデルのファームウェアアップデートなども出来るようになりました。しかし、ファームウェアーのアップデートは、自らは必要なファームウェアを外部サイトから取得し手動でアップロードすることと、対応ハードウェアがNXのみのサポートであったことから、どのハードウェアでも快適に動作するHCIソフトウェアを提供するNutanixとしては、特定のハードウェアでしか利便性を享受できないのは、ユーザーにとって選択の自由を満たしていないことから、ソフトウェア・ハードウェアを含めバージョン管理を行う仕組みとしてLCMが誕生しました。
現在Software Updateの機能は順次LCMに移動しており、現在はAHVやAOSは、LCMからのアップデートとなりました。HPE ProLiant DXは、DELL XC Coreなどのハードウェアプラットフォームのファームウェアのアップデートも対応しています。
現行Software Updateをご利用頂くケースは、vSphere ESXiのアップデートとなります。(こちらも近々にリリースされるバージョンでLCMで対応予定です)それ以外のアップデート(FilesやFoundationなど)は、LCMを最新版にすることでLCM経由でアップデート可能となりますので、まずはLCMを最新版にすることから始めて下さい。



Q.Nutanixクラスターが直接インターネットに接続していない環境では、LCMを利用するためにWebサーバーを用意しないといけないのですか?

この回答は基本的にYESなのですが、LCM2.4のバージョンアップにて一部ですがWebサーバー不要でアップデートが可能になっております。具体的には、Nutanix Support Portal経由で取得したLCM専用バイナリをLCMの画面でアップロードする形となります。
LCM2.4時点でバイナリのダイレクトアップロードに対応しているのは、以下の通りです。

  • AOS
  • AHV
  • Nutanix Files
  • File Analytics
  • Foundation
  • NCC
また、LCMにアップデートするファイルは「lcm_softwarename_version.tar.gz」の命名規約に従ったファイル名のLCMアップデート専用のバイナリが必要になります。

▼LCM2.4から搭載されたダイレクトアップロード機能




Q.1ノードクラスターはLCMは利用できないのですか?

こちらは、従来のAOSでは明確にLCMは利用できませんでしたが、AOS5.15以降で順次実装が変わっております。LCM2.4時点でのご案内としては、シングルノードにおいては、「ファームウェアのアップロードが不可」というだけで、AOSやハイパーバイザーなどのアップデートはLCMを利用したアップデートが可能となっております。なお2ノードクラスターの場合は、LCMによるファームウェアのアップデートに対応しています。
この理由ですが、LCMにてファームウェアをアップデートする際、アップデート対象ノードのブート領域にあるPhoenix領域からLinuxが起動し、その後稼働中のクラスターメンバーのCVMと疎通してバイナリファイルを取得・アップデートを行う動作をしています。1ノードのクラスターの場合、自信がPhoenixモードになると、他のCVMがクラスター内に存在していないためファームウェアを取得するCVMが存在しないため、1ノードにおけるファームウェアアップデートは未対応となります。



Q.ファームウェアのアップデートを行ったら、途中でFailし該当のノードがLinuxシェルの画面のままになっていて再起動してもハイパーバイザーは起動せずLinux(Phoenix)が起動する

基本あまりあってほしくないのですが、何らかの理由でLCMを経由したファームウェアのアップデートに失敗した事象になります。ファームウェアのアップデートに失敗する事象は様々な原因があります。たとえば、Phoenixモードになった際、他のCVMとうまく疎通が出来ずにファームウェアバイナリが取得できなかったなども要因としてあり得ます。
こういった、Phoenix(簡易Linux)で起動したものの処理が継続できない場合、このPhoenixが起動したままで、ハイパーバイザーが自動で再起動しない仕様に現在なっています。この場合、ハードウェアで強制リセットをかけてもまたPhoenixが起動し、ハイパーバイザーは起動しません。

万が一このような事態に陥った場合、Phoenixの画面から以下のコマンドを入力することで、ハイパーバイザーの起動モードに戻すことが出来ます。

python /phoenix/reboot_to_host.py

アップデートに失敗した場合、ログ取得などを行う必要もありますので、別途以下のKBも参考にしてください。

KB9437:How to restore a node from LCM firmware upgrade failure using lcm_node_recovery

KB4520:Host stuck in Phoenix after LCM firmware upgrade failure


ファームウェアアップデートにおいては特定モデルと特定のファームウェアバージョンにおいて失敗するケースが見受けられます。アップデートの際は、LCMのリリースノードを一度確認した上でのアップデートをおすすめいたします。

LCMのリリースノート
https://portal.nutanix.com/page/documents/details?targetId=Release-Notes-LCM:Release-Notes-LCM


アップデートに失敗した場合LCM側でFailと認識されますので、失敗の原因調査の上(リリースノートの確認やサポートへのCaseOpen)再度ファームウェアアップデートを実行していただくこととなります。