2025年12月20日土曜日

Nutanix AHVクラスターにおけるHAの挙動について

Nutanixクラスターで仮想化環境を作る場合、高可用性という観点でHA機能については、誰しもが利用する機能であると思います。

このHA機能は、各ハイパーバイザーソフトウェアによって異なります。NutanixにおけるHAの構成について簡単に紹介します。


HAの検出とその方法

3Tierの場合、

  • 特定のハイパーバイザーホストの障害
  • ストレージパスの障害
  • ネットワークパスの障害
という3つの観点で、HAの発動トリガーがあるかと思います。

Nutanixの場合、ストレージパスと仮想マシンのサービスネットワークも同じイーサネットを利用する観点から、ネットワークの障害がノード間通信を妨げる障害となるため、HA発動のトリガーの1つとなる点をまず押えておく必要があります。

AHVにおけるHAのトリガー

  • ノード間の通信断
  • AHVホストの「ルート」ファイルシステムの破損問題や「ルート」ファイルシステムが読み取り専用状態になった場合
  • Libvirtデーモン(libvirtd)のダウン
  • AHV ホストエージェント (ahv-host-agent)のダウン
がHAの対象となります。

libvirtdは、KVMを利用する際には、監視が必要なプロセスであると思いますが、それ以外にNutanixは、AHVとして独自の監視エージェントがHAの挙動を左右していることがわかります。

Acropolisリーダーが孤立や障害が発生した場合、クラスタ内の正常なホストから新しいAcropolisリーダーが選出されます。クラスタが分断された場合(例:Xノードが他のYノードと通信できない場合)、稼働状態を維持しクォーラムを維持しているクラスタのホスト分でVMが再起動されます。


HAが発動するタイミング

  • Libvirtd から切断された場合、そこから 40 秒でHA発動
  • それ以外の場合は、60秒でHA発動
    (キープアライブタイムアウト期間20秒(4 * 5)とHAタイムアウト40秒を合計すると、最初のキープアライブの失敗から60秒になります。)

HAが、発動するとアラート「A1137」が発行されます。
こちらは、KB-10612を参考にすると良いと思います。


HA発動時の確認すべくログの場所

HAが発動した場合、AcropolisリーダーCVMの以下のログに記載されますので、障害調査の場合このログを参考にすると良いと考えられます。

/home/nutanix/data/logs/acropolis.out

AHV側のログは、以下の場所に保存されています。

/var/log/libvirt/libvirtd.log


Nutanixにおいて、HAが発動したりクラスターの動作の挙動がおかしくなる場合、大半ネットワーク周りの障害に起因していることが多いように感じています。

Nutanix CVM内では、定期的に他のホストやCVMに定期的にPINGを投げた結果をログとして保存しています。

/home/nutanix/data/logs/sysstats/ping_hosts.INFO

/home/nutanix/data/logs/sysstats/ping_gateway.INFO

のファイルで、ノードや各コンポーネントのログを確認すると、何らかの障害解消のヒントになる可能性があります。


(参考)KB-4636 VM High Availability (HA) on AHV














 

2025年12月15日月曜日

Nutanixコンポーネントのタイムゾーンについて

Nutanixクラスターの管理において、時刻管理は、重要なポイントです。その際に理解しておく点として、タイムゾーンの持ち方があります。本日は、タイムゾーンについて紹介します。


AHVのタイムゾーン

AHVは、UTCでタイムゾーンがセットされています。AHVは、Rocky LinuxをベースとしたOSで稼働しており、OS自体はUTCで時間を管理していますが、タイムゾーンもUTCとして動作しています。AHVのタイムゾーン変更は、原則としてサポートされていない点にも注意が必要です。

(参考)KB:6834 / NCC Health Check: ahv_time_zone_check
https://portal.nutanix.com/kb/6834


CVMのタイムゾーン

CVMのタイムゾーンは歴史的な背景があります。2018年ぐらいまでのCVMのタイムゾーンは、デフォルトPSTで構成されていました。その後、Foundation画面にタイムゾーンが指定できるようになり、この指定したタイムゾーンでCVMのタイムゾーンが設定されるようになっていました。日本においては「Asia/Tokyo」を選択することが多いと思いますので、いわゆる日本時間でCVMで時間管理されています。この構成は、AOS 6.10まででした。

AOS 7.0以降は、Foundationでタイムゾーンを指定した場合、JSTになることは確認していますが、アップグレードの際にUTC後にCVMのタイムゾーンは「UTC」で構成されているケースをいくつ確認しています。タイムゾーンは個別で1度かくにんをいただくのが良いと思われます。

なお、AOS 5.18、タイムゾーンにかかわらずNutanix関連ログは、UTCで出力されるようになっています。

(参考) KB:1050 / Procedure to Change Timezone on Nutanix CVMs and Prism Central VMs
https://portal.nutanix.com/kb/1050


仮想マシンのタイムゾーン

vSphere ESXiと感覚的に違う部分は、この仮想マシンのタイムゾーンであると思います。ESXiの場合、ハイパーバイザー自体にタイムゾーンはなく、仮想マシンはVMware Toolsによって必要な時刻が自動的に渡されていました。
Nutanix AHVの場合は、VMware Toolsのように貸そうマシンと時刻のやりとりを行うエージェントはありません。AHV上の仮想マシンは、パワーオン時にハイパーバイザーの時刻が渡されます。この際、Windows OSのようにRTCで管理するものは、BIOSの時刻がOSの時刻となるため、日本で運用する場合9時間の時差が生じます。
それをカバーするため、Nutanixで構成される仮想マシンにそれぞれ、タイムゾーンを指定することができます。このタイムゾーンは、UTCからの時差を自動計算し、時差を考慮した時間を仮想マシンに渡します。そのため、このタイムゾーンは、OS側でタイムゾーンを管理するLinux/Unix系のOSの場合は、UTCを、WindowsのようにRTCで動作するOSに関しては、稼働する地域のタイムゾーンを選択する必要があります。

▼仮想マシンで設定できるタイムゾーン


Prism Centralのタイムゾーン

Prism CentralのOSタイムゾーンは、PSTで構成されています。KBでは、UTCと記載されていますが、おそらく仮想マシン自体はUTCタイムゾーンで構成されていますが、OSは、CVMと同じくRocky Linuxベースですので、OS上のタイムゾーンは、PSTで構成されています。

CVM同様 Prism Central 2020.8 以降は、ログ自体は、UCT時刻で出力されるようになっています。


今回は、タイムゾーンについて紹介しました。たかが時間の話しですが、Nutanixにおいては分散したノードを1つのクラスターにまとめる上で時刻は非常に重要です。

今一度タイムゾーンやNTPによる時刻同期が行われているかを確認しておくことも、Nutanixクラスターを安全に稼働する上で必要な事項であると思います。