1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

PowerHA スナップショットの取得と構成データ確認の記録

1
Last updated at Posted at 2026-11-01

はじめに

AIX 上で PowerHA SystemMirror を運用するにあたり、構成変更や定期保守に備えて 「クラスター・スナップショット(Cluster Snapshot)」 を取得し、生成される構成データや実際の動作を確認しました。

PowerHA のスナップショット機能は、稼働中のクラスター構成情報を丸ごと静的ファイルとして保存・復元できる便利な機能です。

この記事では、PowerHA スナップショットの概要と、CLI(clmgr)による取得手順、実行時のターミナルログ、生成された .odm ファイルの確認結果、さらには設定変更・リストア検証時に確認できた仕様や実行履歴ログ(clsnapshot.log)の追跡結果をまとめています。

powerha_snapshot.jpeg

確認できた主なポイント:

  • クラスター稼働中(STABLE 状態)でも業務無停止で安全に取得できることを確認
  • トポロジー・リソース・スクリプト定義・CAA 構成がテキスト形式(.odm)で保存されることを確認
  • CLI(clmgr add snapshot)により数秒でスムーズに取得完了
  • 取得ファイルはローカルに保存されるため、別ノードや管理端末へ tar/gz で退避可能
  • スナップショットの復元(リストア)は、全ノードでクラスターサービスが停止(オフライン)している必要がある仕様を確認
  • クラスター同期(DARE)時に PowerHA が自動的に active.0.odm というスナップショットを退避する挙動を確認
  • /usr/es/sbin/cluster/snapshots/clsnapshot.log に作成・照会・リストア試行・自動退避の全履歴が記録されることを確認

参考動画

当記事を元にした参考動画です。自身の勉強用です。


1. PowerHA スナップショットの概要

スナップショットの役割

PowerHA スナップショットは、AIX の Object Data Manager(ODM)に保持されている PowerHA クラスター定義、Cluster Aware AIX(CAA)情報、環境パラメーターなどを 静的なスナップショットファイルとしてアーカイブする機能 です。

+-----------------------------------------------------------+
|               PowerHA クラスター (ODM / CAA)              |
|  - クラスター属性 (Unicast/Multicast, タイムアウト等)    |
|  - ノード / ネットワーク / サービスIP 定義                |
|  - リソースグループ / 共有VG / マウントポイント           |
|  - アプリケーション起動・停止スクリプト定義               |
|  - リポジトリディスク情報 (CAA)                           |
+-----------------------------------------------------------+
                             │
            clmgr add snapshot (稼働中・無停止)
                             ▼
+-----------------------------------------------------------+
|          /usr/es/sbin/cluster/snapshots/                  |
|          <snapshot_name>.odm (テキスト形式)               |
+-----------------------------------------------------------+

主な用途

  1. 構成変更前のバックアップ: リソースグループやネットワーク構成の変更前の保全
  2. 保守・アップデート前の保全: AIX / PowerHA の更新や ifix 適用前の状態保存
  3. 別環境への構成複製: テスト環境や災害復旧(DR)環境への構成コピー
  4. 構成差分の比較: clmgr compare snapshot による過去構成との差分確認

業務・クラスターへの影響

  • 無停止で取得可能: クラスターが STABLE(稼働中)の状態で実行可能で、業務通信やリソースグループのフェールオーバー等への影響はありません。
  • 軽量: 生成されるファイルサイズは数十 KB 〜 数 MB 程度で、短時間で完了します。

2. スナップショットに保存される主なデータ

スナップショットファイル(デフォルト保存先: /usr/es/sbin/cluster/snapshots/)には、以下の情報がテキスト形式で記録されていました。

セクション / データ 記録されている内容
<VER> PowerHA バージョン、OS レベル、取得日時、スナップショットバージョン
<DSC> スナップショット作成時に付与した説明文
<ODM> クラスター構成(HACMPcluster)、ノード(HACMPnode)、リソース(HACMPresource)、アプリケーション定義(HACMPserver)など
<LSCLUSTER_*> CAA クラスター基本情報、リポジトリディスク情報、インターフェース状態
<CLUSTER_LSLPP> 導入済み関連ファイルセット一覧
<CLUSTER_EMGR> 適用済み ifix (Interim Fix) 一覧

3. スナップショットの取得手順と実行ログ

実際にターミナルから CLI(clmgr)で実行して確認した流れとログです。

ステップ 1: 事前確認

スナップショット取得前に、クラスターの状態が STABLE であること、参加ノード、および保存先(/usr)の空き容量を確認しました。

実行ログ(事前確認)

# ホスト名と日時の確認
# hostname
ha-node01
# date
Sat Oct 31 09:00:00 JST 2026

# クラスター状態の確認(STATE が STABLE であることを確認)
# clmgr query cluster state
CLUSTER_NAME="ha_cluster01"
CLUSTER_ID="1706xxxx53"
STATE="STABLE"
TYPE="NSC"
HEARTBEAT_TYPE="UNICAST"
REPOSITORIES="hdisk2 (00c5xxxxxxxx7568)"
VERSION="7.2.7.0"
VERSION_NUMBER="23"
EDITION="STANDARD"
UNSYNCED_CHANGES="false"
FC_SYNC_INTERVAL="10"
RG_SETTLING_TIME="300"
RG_DIST_POLICY="node"

# 参加ノードの確認
# clmgr query node
ha-node01
ha-node02

# ファイルシステム空き容量の確認(/usr に十分な空きがあるか確認)
# df -g /usr /tmp
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/hd2           4.00      1.70   58%    51461    11% /usr
/dev/hd3           0.25      0.25    2%      172     1% /tmp

ステップ 2: スナップショットの作成実行

日付と時刻を付けたスナップショット名を指定して clmgr add snapshot を実行しました。

実行ログ(スナップショット作成)

# スナップショット名を変数定義
# SNAP_NAME="snap_cluster01_$(date +%Y%m%d_%H%M%S)"
# echo "Target Snapshot Name: ${SNAP_NAME}"
Target Snapshot Name: snap_cluster01_20261031_090015

# スナップショット作成の実行
# clmgr add snapshot "${SNAP_NAME}" \
    DESCRIPTION="Snapshot of cluster ha_cluster01 created on $(date)"

clsnapshot: Creating file /usr/es/sbin/cluster/snapshots/snap_cluster01_20261031_090015.odm.

clsnapshot: Succeeded creating Cluster Snapshot: snap_cluster01_20261031_090015
# echo "Exit Code: $?"
Exit Code: 0

clmgr add snapshot を実行すると、バックグラウンドで clsnapshot ユーティリティが呼び出され、ODM 定義のエクスポートと関連システム情報の収集が自動的に行われました。


4. スナップショットの確認と内部データの閲覧

4.1 登録状況と属性の確認

作成されたスナップショットが PowerHA に正常に認識されているか確認しました。

実行ログ(クエリ確認)

# スナップショット一覧の表示
# clmgr query snapshot
snap_cluster01_20261031_090015

# スナップショットの詳細属性を表示
# clmgr query snapshot snap_cluster01_20261031_090015
NAME="snap_cluster01_20261031_090015"
DESCRIPTION="Snapshot of cluster ha_cluster01 created on Sat Oct 31 09:00:15 JST 2026"
METHODS=""
CAPTURE_DATE="Sat Oct 31 09:00:15 JST 2026"
CAPTURE_NODE="ha-node01"
CLUSTER_NAME="ha_cluster01"
CLUSTER_TYPE="NSC"
NODES="ha-node01,ha-node02"
HOSTS="ha-node01,ha-node02"
AVAILABLE_SECTIONS=""

4.2 生成された .odm ファイルの中身を確認

生成されたスナップショットの実体ファイル(/usr/es/sbin/cluster/snapshots/snap_cluster01_20261031_090015.odm)を確認したところ、拡張子は .odm ですが プレーンテキスト形式(Stanza 形式) となっており、cat や head、grep でそのまま中身を閲覧できました。

実行ログ(ファイル確認と冒頭ヘッダーの閲覧)

# 生成されたファイルサイズとパーミッションの確認
# ls -l /usr/es/sbin/cluster/snapshots/snap_cluster01_20261031_090015*
-rw-------    1 root     system        83609 Oct 31 09:00 /usr/es/sbin/cluster/snapshots/snap_cluster01_20261031_090015.odm

# ファイル形式の確認(テキストファイルとして認識)
# file /usr/es/sbin/cluster/snapshots/snap_cluster01_20261031_090015.odm
/usr/es/sbin/cluster/snapshots/snap_cluster01_20261031_090015.odm: commands text

# 冒頭部分を head で閲覧
# head -n 35 /usr/es/sbin/cluster/snapshots/snap_cluster01_20261031_090015.odm
<VER
clsnapshot_version=7.2
cluster_name=ha_cluster01
cluster_id=1706xxxx53
cluster_version=23
cluster_release=7.2
snapshot_instance=3
capture_date=Sat Oct 31 09:00:15 JST 2026
halevel=7.2.7 GA
oslevel=7300-02-02-2420
</VER

<DSC
Snapshot of cluster ha_cluster01 created on Sat Oct 31 09:00:15 JST 2026
</DSC>


<ODM

HACMPcluster:
	id = 1706xxxx53
	name = "ha_cluster01"
	nodename = "ha-node01"
	sec_level = "Standard"
	sec_level_msg = ""
	sec_encryption = ""
	sec_persistent = ""
	last_node_ids = ""
	highest_node_id = 0
	last_network_ids = ""
	highest_network_id = 0
	last_site_ids = ""
	highest_site_id = 0
	handle = 1
	cluster_version = 23
	reserved1 = 0
	reserved2 = 0
	wlm_subdir = ""
	settling_time = 300
	rg_distribution_policy = "node"
	noautoverification = 1

実行ログ(リソース定義・スクリプト定義の grep 確認)

AIX の grep -p(段落抽出)を使うことで、アプリケーション設定やリソースグループの定義箇所も容易に確認できました。

# アプリケーションサーバー定義(起動・停止スクリプト)の確認
# grep -p "HACMPserver:" /usr/es/sbin/cluster/snapshots/snap_cluster01_20261031_090015.odm
HACMPserver:
	name = "app_srv01"
	start = "/app/scripts/start_app.sh"
	stop = "/app/scripts/stop_app.sh"
	cpu_usage_monitor = "no"
	cpu_usage_monitor_interval = 10

# リソースグループに紐づくリソース定義の確認
# grep -p "HACMPresource:" /usr/es/sbin/cluster/snapshots/snap_cluster01_20261031_090015.odm
HACMPresource:
	group = "rg_app01"
	type = ""
	name = "APPLICATIONS"
	value = "app_srv01"
	id = 1
	monitor_method = ""

HACMPresource:
	group = "rg_app01"
	type = ""
	name = "SERVICE_LABEL"
	value = "svc_app01"
	id = 2
	monitor_method = ""

HACMPresource:
	group = "rg_app01"
	type = ""
	name = "VOLUME_GROUP"
	value = "datavg"
	id = 3
	monitor_method = ""

5. スナップショットの外部退避(アーカイブと圧縮)

スナップショットは取得を実行したローカルノードのディスクに配置されるため、万が一のノード障害等に備えて別サーバーへ退避できるようにアーカイブと圧縮を実施しました。

実行ログ(アーカイブ作成と圧縮)

# スナップショットディレクトリへ移動して tar 作成
# cd /usr/es/sbin/cluster/snapshots
# tar -cvf /tmp/snap_cluster01_20261031_090015.tar snap_cluster01_20261031_090015.*
a snap_cluster01_20261031_090015.odm 164 blocks

# gzip で圧縮
# gzip -f /tmp/snap_cluster01_20261031_090015.tar

# 生成された圧縮ファイルの確認(約 10 KB)
# ls -l /tmp/snap_cluster01_20261031_090015.tar.gz
-rw-r--r--    1 root     system        10451 Oct 31 09:05 /tmp/snap_cluster01_20261031_090015.tar.gz

外部転送例

# 踏み台・バックアップサーバーへの転送例
# scp /tmp/snap_cluster01_20261031_090015.tar.gz backup-admin@backup-server:/var/backups/powerha/

6. スナップショット復元(リストア)の挙動確認と実行ログ

実際にクラスターの設定を一部変更し、スナップショットからのリストア処理を試行して挙動を確認しました。

6.1 設定変更のテスト

リソースグループのセトリング時間(RG_SETTLING_TIME)を一時的に 300 秒から 200 秒に変更しました。

実行ログ(設定変更)

# セトリング時間を 300秒から 200秒へ変更
# clmgr modify cluster RG_SETTLING_TIME=200
Changing Settling time:
Old value: 300 Seconds
New value: 200 Seconds

# 設定が 200秒に変更されたことを確認
# clmgr query cluster | grep RG_SETTLING_TIME
RG_SETTLING_TIME="200"

6.2 オンライン(稼働中)でのリストア試行と確認できた仕様

この状態で、先ほど取得したスナップショット(snap_cluster01_20261031_090015)のリストアを実行してみました。

実行ログ(リストア試行時のエラー出力)

# クラスター稼働中にスナップショットのリストアを実行
# clmgr manage snapshot restore snap_cluster01_20261031_090015
clsnapshot: A snapshot cannot be applied with cluster services active on any node.

clsnapshot: A snapshot cannot be applied with cluster services active on any node. というメッセージが出力され、コマンドが安全にブロックされました。

確認できた仕様まとめ

操作 実行可能なクラスター状態 理由・動作
スナップショット取得 (add snapshot) 稼働中 (STABLE / オンライン) 業務無停止で安全に取得可能。
現在の ODM および CAA 定義を静的に読み取ってファイル出力するため。
スナップショット復元 (restore / apply) 停止中 (OFFLINE / オフライン) クラスター稼働中は実行不可(安全保護)。
リストア処理はクラスターのトポロジーやリソース定義など全 ODM オブジェクトを丸ごと置き換えるため、全ノードでクラスターデーモン(clstrmgr 等)が停止している必要があります。

6.3 スナップショットから復元する場合の正式フロー

スナップショットを用いてクラスター構成を過去の状態へ戻す場合は、以下の流れで実施します。

# 1. クラスターサービスを全ノードで停止(オフライン化)
clmgr offline cluster

# 2. スナップショットからクラスター構成を復元
clmgr manage snapshot restore snap_cluster01_20261031_090015

# 3. 構成の検証および全ノード同期
clmgr sync cluster

# 4. クラスターサービスを全ノードで再起動(オンライン化)
clmgr online cluster

6.4 設定の切り戻しと同期確認

今回はクラスター稼働中の検証であったため、変更したセトリング時間を元の 300 秒に戻し、クラスター全体の同期を実行して正常性を確認しました。

実行ログ(設定の戻しと同期)

# セトリング時間を元の 300秒に戻す
# clmgr modify cluster RG_SETTLING_TIME=300
Changing Settling time:
Old value: 200 Seconds
New value: 300 Seconds

# クラスター全体の検証・同期(Dynamic Reconfiguration)を実行
# clmgr sync cluster
Verifying additional pre-requisites for Dynamic Reconfiguration...
...completed.
Committing any changes, as required, to all available nodes...
Verification has completed normally.
cldare: Requesting a refresh of the Cluster Manager...
PowerHA SystemMirror Cluster Manager current state is: ST_STABLE
.....completed.

# クラスターが完全に STABLE かつ同期済みであることを確認
# clmgr query cluster | grep -E 'STATE|UNSYNCED_CHANGES|RG_SETTLING_TIME'
STATE="STABLE"
UNSYNCED_CHANGES="false"
RG_SETTLING_TIME="300"

7. 保存先ディレクトリと実行ログ(clsnapshot.log)の確認

一連の作業後、スナップショットが保存される /usr/es/sbin/cluster/snapshots/ ディレクトリの中身と、スナップショット機能の監査ログ clsnapshot.log を確認しました。

実行ログ(ディレクトリ一覧の確認)

# ls -la /usr/es/sbin/cluster/snapshots/
total 352
drwxr-xr-x    2 root     system          256 Oct 31 09:20 .
drwxr-xr-x   19 root     system         4096 Oct 31 09:20 ..
-rw-------    1 root     system        83670 Oct 31 09:20 active.0.odm
-rw-------    1 root     system         1895 Oct 31 09:20 clsnapshot.log
-rw-------    1 root     system        83609 Oct 31 09:00 snap_cluster01_20261031_090015.odm

ディレクトリ内の各ファイルの役割

  • snap_cluster01_20261031_090015.odm: 手動作成したスナップショットの実体ファイル。
  • active.0.odm: clmgr sync cluster(動的再構成: DARE)実行時に、PowerHA が自動的に安全策として作成したアクティブ構成のスナップショット。
  • clsnapshot.log: スナップショットの作成、照会、適用試行などの全コマンド履歴が記録されるログファイル。

clsnapshot.log の中身(実行履歴)

# cat /usr/es/sbin/cluster/snapshots/clsnapshot.log

###############################################################################
Sat Oct 31 09:00:15 JST 2026:  clsnapshot -c -n snap_cluster01_20261031_090015 -d Snapshot of cluster ha_cluster01 created on Sat Oct 31 09:00:15 JST 2026

###############################################################################
Sat Oct 31 09:01:00 JST 2026:  clsnapshot -l

###############################################################################
Sat Oct 31 09:02:10 JST 2026:  clsnapshot -v -n snap_cluster01_20261031_090015

###############################################################################
Sat Oct 31 09:15:30 JST 2026:  clsnapshot -a -n snap_cluster01_20261031_090015 -f false

###############################################################################
Sat Oct 31 09:20:00 JST 2026:  clsnapshot -c -n active.0 -o /usr/es/sbin/cluster/etc/objrepos/active -d Cluster Snapshot of active cluster configuration generated via a Dynamic Reconfiguration Event - Sat Oct 31 09:20:00 JST 2026

ログから読み取れる PowerHA の動作

  1. clsnapshot -c (Create): 09:00:15 に手動スナップショットを作成した履歴。
  2. clsnapshot -l / -v (List / View): clmgr query snapshot で一覧や属性を参照した履歴。
  3. clsnapshot -a (Apply): 09:15:30 に実行したリストア試行(オンライン中のため拒否された処理)の記録。
  4. 動的再構成(DARE)時の自動スナップショット: 09:20:00 にクラスター同期(clmgr sync cluster)を実行した際、PowerHA が自動的に active.0 を生成して構成をバックアップした記録。

8. PowerHA なのに ODM 定義が「HACMP*」のまま残っている理由

スナップショットファイル(.odm)の中身を見ると、HACMPcluster や HACMPresource、HACMPserver など、すべてのオブジェクトクラス名が HACMP から始まっています。

これは、PowerHA の旧製品名が 「HACMP(High Availability Cluster Multi-Processing)」 だったことに由来します。

製品名が「PowerHA SystemMirror」に刷新された後も、内部の ODM オブジェクトクラス名やログディレクトリ(/var/hacmp/)、SMIT パス(smit hacmp)を変更すると過去バージョンからのアップグレードや既存スクリプトの後方互換性が損なわれてしまうため、現在でも内部構造は HACMP という名称が大切に維持されています。


使用コマンドのリファレンス

本記事で使用したコマンドの IBM Documentation へのリンクです。

PowerHA SystemMirror

コマンド 本記事での用途 リファレンス
clmgr クラスター状態確認、スナップショットの作成・照会・復元、設定変更、同期、起動・停止 clmgr command / clmgr command: Quick reference
clsnapshot clmgr から内部的に呼び出されるスナップショット用ユーティリティ(clsnapshot.log の記録元) clsnapshot command

補足: clsnapshot コマンドは PowerHA SystemMirror 7.2.4 以降で非推奨となっており、スナップショット関連の操作には clmgr の使用が推奨されています。


PowerHA snapshot参考ドキュメント


AIX 基本コマンド

コマンド 本記事での用途 リファレンス
hostname ホスト名の確認 hostname Command
date 日時の確認、スナップショット名の生成 date Command
df 保存先(/usr)の空き容量確認 df Command
echo 変数・終了コードの表示 echo Command
ls スナップショットファイルの一覧・パーミッション確認 ls Command
file .odm ファイル形式の確認 file Command
head .odm ファイル冒頭部分の閲覧 head Command
cat clsnapshot.log の閲覧 cat Command
grep HACMPserver / HACMPresource 定義の抽出(-p)、出力の絞り込み grep Command
cd スナップショットディレクトリへの移動 cd Command
tar スナップショットのアーカイブ作成 tar Command

まとめ

今回、PowerHA のクラスター・スナップショットを実際に取得・確認してみて、以下の点が確認できました。

  1. 取得は無停止・数秒で完了: 稼働中のクラスターでも業務通信に影響を与えることなく短時間でバックアップが完了しました。
  2. プレーンテキストで可読性が高い: .odm ファイルを cat や grep で直接確認でき、設定値の事前チェックや監査にも扱いやすい構造でした。
  3. 安全設計に基づいたリストア仕様: スナップショットの復元(restore)はクラスターサービスがアクティブな状態では誤適用されないよう保護されており、オフライン状態で確実に全 ODM を巻き戻す設計になっていることが確認できました。
  4. clsnapshot.log による実行追跡: 作成・照会・リストア試行・動的再構成時の自動退避(active.0)の履歴がすべてタイムスタンプ付きで記録されるため、監査や運用管理が容易であることがわかりました。

クラスターのメンテナンスや構成変更を行う際は、作業前の安全策として事前にスナップショットを取得しておくと安心です。

1
0
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?