The Operations Loop 03 — 障害切り替えと復旧の検証

EdwardMoon

検証の基準は、画面が開くかどうかではなく、データとパスが実際につながっているかどうかだ。この記事では、2026-09-20のVirtualBox実習で実行したタスクと観測結果を記録する。設計上の期待、実際のテスト、まだ実施していない範囲を区別する。

この記事の流れ

1. 検証環境と判定基準
2. 実際の正常オンボーディング記録
3. 正常なパスに至るまでに発見し修正した問題
4. バックアップと隔離復元
5. 中央ノード障害テスト
6. Proxy切断と遅延データの再送
7. 資産データの保護とパス検証
8. インターネットのない環境でのターゲットインストールとパッケージ検証
9. アーキテクチャ画面検証
10. 検証チェックリストと境界
関連資料と構成情報

1. 検証環境と判定基準

Rocky Linux 10.2、Zabbix 7.0.30 LTS、NetBox 4.7.1、AWX 24.6.1を使用した。中央の2台のVMとクォーラム、Gateway、Provision、3つの環境のProxy/Bastionを構成した。すべてのVMは1台の物理PCのメモリ、CPU、ストレージを共有する。

正常なオンボーディングは、PXEインストール → 承認されたSSHパス → 実際の資産収集 → NetBoxネイティブIPAM → Zabbix登録 → NetBoxベースのAWX inventory sync → 実際の最新値の確認まで、すべて成功して初めて合格となる。API登録のレスポンスと最新データの受信は別のチェック項目である。

2. 実際の正常オンボーディング記録

PRODは空の32GiBディスクと内部ネットワークNIC1つでインストールした。踏み台経由のSSHでRocky Linux 10.2、管理IP 10.77.20.101/24、SELinux Enforcing、PXE完了マーカーを確認した。インストール後にメモリを4GiBから1GiBへ変更した。

証拠	観測結果
AWX Workflow	22, successful
Onboard Job	23, successful
NetBox inventory update	24, successful
Verify Job	26, successful
Git コミット	58bb87b9842c159b1986784062916c4d9eb97c00
NetBox アセット	VM ID 1, fml-prod-app-01
IP 関係	VM Interface ID 1 → IPAddress ID 1 → primary_ip4 10.77.20.101/24
収集状態	complete, collection_errors 空の配列
Zabbix	hostid 10683, proxyid 1, templateid 10343
実際の収集	system.uptime itemid 50799, state 0, エラーなし

検証ジョブで実際の最新稼働時間データの受信を確認した。登録成功だけでなく、監視データの収集まで動作することを合格条件とした。

NetBoxには vCPU 1、ゲスト使用可能メモリ 954MiB、ディスク 32768MiB、Rocky Linux 10.2、仮想化タイプ virtualbox、管理 NIC enp0s3、PROD環境と実際のパーティション構造が保存された。ゲストのメモリ観測値 954MiB と VirtualBox 割り当て値 1024MiB は異なる値である。

AWX の NetBox inventory には ansible_host=10.77.20.101, ansible_user=labadmin, fml_environment=prod, fml_subnet=20 が取り込まれた。単にアセット名だけを同期したのではなく、管理 IP と Bastion 経路の計算に必要な環境変数を一緒に確認した。

DEVも空ディスクからPXEで導入し、Workflow 30を実行した。登録31、インベントリ更新32、検証34がすべて成功した。監視対象10684はDEV Proxy 2に接続され、PRODと分離した経路で収集できた。

STG はインストールの完了検出により自動実行

STG の最初の SSH 信頼を VirtualBox serial console の公開鍵・fingerprint で承認した後、インストール RAM を 4GiB から 1GiB に減らした。インストール完了コントローラーが承認キー、インストールマーカー、hostname・machine ID を確認し、SCM・bootstrap inventory を同期した。その後、手動の Workflow 実行なしに Job 38 を開始した。

STG の証拠	結果
Workflow 38	正常動作を確認
Onboard / inventory / Verify	39 / 40 / 42 すべて successful
Git コミット	8877198864680095a1a8b5684d3382b9034237e9
NetBox	VM 3 → Interface 3 → IPAddress 3, 10.77.40.101/24
収集状態	complete、collection_errors 空の配列
Zabbix	host 10685、proxy 3、uptime item 51005
検証データ	実際の最新監視データを受信
コントローラーの状態	該当のmachine IDとWorkflow 38をsuccessfulとして保存

STGでも実際の最新監視データを確認した。AWXには3環境のホストと管理IP・環境変数が反映された。最初のSSH身元承認は管理者の確認手順として維持し、未承認の鍵を回避して接続しなかった。

3. 正常な経路まで発見して修正した問題

実行	失敗地点	原因と修正
Workflow 7 / Job 8	Agent RPM metadataのダウンロード	Minimal ISOにBaseOS/AppStreamパスがなく404。実際のMinimalリポジトリに変更
Workflow 12 / Job 13	NetBox APIローカルタスク実行前	インベントリの権限昇格変数がdelegate_to localhostにも適用され、EEにないsudo呼び出し
Workflow 17 / Job 18	同じローカル作業	既存のinventory変数の影響まで考慮し、task varsのansible_become=falseとEE Pythonパスを明示
Workflow 22 / Jobs 23・26	全体的なフロー	資産・IPAM・監視登録、インベントリ更新、実際の収集検証に成功

失敗した作業も削除しなかった。修正コミットと次のJob結果を比較できるように残した。NetBox/Zabbix登録前に失敗した場合を、実際の資産が重複生成された状況と混同しない。

4. バックアップと分離復元

NetBox DBをpg_dumpでバックアップし、運用DBと別の検証用DBへpg_restoreで復元した。復元先でfml-prod-app-01と代表管理IPの関連が維持されていることを確認した。

バックアップのSHA-256は06914eb419d88edb97245ed435177b396309a625b65eb14b72ae9fb627667390である。既存DBを上書きせず、別途の検証DBを使用した。この結果はNetBox論理DB復元テストであり、すべてのVM・メディア・AWX・Gitを一度に復旧するディザスターリカバリテストではない。

5. 中央ノード障害テスト

最初のテスト直前、PostgreSQL leaderはops02、ops01はsync standbyであり、レプリケーションラグは0だった。Zabbixはops01 active、ops02 standbyだった。1号機の電源を強制的に落とし、VMの電源損失を再現した。

VIP 10.77.10.10は2号機に移動した。しかし、切り替え区間でNetBox backendが500を返し、VIPは503を返した。Zabbixはその後2号機でactive作業を開始し、3つのプロキシからの接続を受け付けた。このテストを「無停止HA成功」とは判定しなかった。

観測ツールの最初のログファイルは、SELinuxポリシーに合致しないパスのため作成されなかった。したがって、そのテストで精密なRTOは算出しない。ログ記録パスを/var/logの下に移し、正常な記録を確認した後に再テストを行った。

初期試験ではキャッシュ接続の再試行によってNetBoxの応答復旧が遅れた。設定コードを確認し、ローカルSentinelの優先照会と接続・再試行の制限を適用して再試験した。

修正後、DB・Redis・Zabbixがアクティブな2号機の電源損失

PostgreSQL・Redis・Zabbixの稼働側である中央2号機を強制停止し、1号機への役割移行とサービス応答を確認した。切り替え中には一時的な応答エラーが発生したため、無停止切り替えとは判定しなかった。

項目	検証結果
PostgreSQL ops01 primary	正常動作を確認
NetBox既存資産API照会	正常動作を確認
Zabbix API応答	正常動作を確認
AWX ping	正常動作を確認
障害以降に収集時刻を持つZabbixの値	正常動作を確認

2号機の停止中にNetBox資産へテスト用情報を書き込み、読み出した後に元へ戻した。資産と管理IPが維持され、生存DBへの書き込みも確認できた。AWXの状態応答復旧は実行中ジョブの無停止を証明しない。

2号機の再起動後、PostgreSQLが同期スタンバイへ復帰し、NetBoxも正常化した。サービスの継続と、障害ノードが予備能力として復帰することを分けて確認した。

修正後VIP・DB・Zabbixアクティブ1号機の電源喪失

逆方向として1号機も強制停止した。2号機で共通サービスIPとDB書き込み役割が維持され、NetBox資産照会と新しいZabbixデータの収集が再開した。資産識別と管理IPも維持された。

AWXは1号機だけに配置されているため、その停止中は利用できなかった。1号機を再起動するとAWX、DB複製、NetBoxが復旧した。これは元のサーバーの復旧であり、AWXのHA成功ではない。

両方のテストにおいて、切り替え区間のタイムアウト・HTTP 500/503が含まれる。「無停止」とは記載しない。類似のテストにおける改善前後の数値は、当時のDBのアクティブ位置や負荷が異なるため、単純な割合で性能改善効果を断定しない。

6. Proxyの切断と遅延データの再転送

GatewayでPROD Proxy 10.77.20.10から中央への監視転送経路TCP 10051だけを遮断した。SSH、Agentのローカル収集、DEV経路は維持した。中央のPROD更新は止まったがDEV収集は継続した。

PROD ProxyのDBを読み取り専用で確認し、中央へ未送信のデータが保存されていた。送信済みで整理前の行も残り得るため、全行数を未送信件数とは扱わなかった。

一時遮断ルールは期限設定後も残っていたため、明示的に削除して通信復旧を確認した。以後もタイマーだけに依存せず、実際のルール解除を確認する。

通信復旧後、蓄積データが元の収集順序と間隔で中央履歴へ反映され、最新値の更新も再開した。検証範囲は一時的な転送断と復旧であり、長期保管、ディスク枯渇、Proxy VM自体の障害は別途検証する。

7. 資産データの保護と経路検証

実際のPROD収集結果を基準に、同じNetBox登録を再度実行した。VM ID 1とIPAddress ID 1が維持され、同じ名前・アドレスがそれぞれ1つずつ存在した。収集時刻の更新と重複資産の生成を区別した。

注入した条件・実際の経路	判定
PROD資産へのDEV管理IPの伝達	API変更前に拒否、mutation 0
既存のアセットと異なるmachine IDを渡す	API変更前に拒否、mutation 0
別のアセットで使用中のIPを渡す	新規アセット作成前に拒否、mutation 0
CPU・ディスク・ネットワークの収集失敗を明示的に注入	既存のCPU・パーティション・製品フィールドを保持し、partialを表示
正常な収集結果を再適用	complete状態を復元
異なるmount namespaceの製品プロセス	ホストのバージョン実行ファイル・JARの参照を呼び出さない
中央 → PROD対象直接SSH	拒否
中央 → 各環境Bastion SSH	許可
PROD → DEV SSH	拒否
PROD → 外部 1.1.1.1:443	拒否
PROD → ローカルProxy・内部RPMリポジトリ	許可

部分的な収集失敗はテスト用に作成した入力であり、実際のディスク故障事例として紹介するものではない。拒否条件を先検査した後に変更し、一部のAPIのみ成功した状況では成功したオブジェクトを無条件に削除せず、再実行につながるようにした。

8. インターネットのない対象へのインストールとパッケージ検証

PXE対象はInternal Network NICを1つだけ持ち、NAT・ブリッジNICはない。OSはProvisionのRocky 10.2 Minimalインストールツリーから取得した。PRODのAgent RPMキャッシュをクリアした後、内部リポジトリ2つだけを有効化してzabbix-agent2 7.0.30を再インストールした。実際の6.4MBのダウンロードとGPG検証、サービスのactiveを確認した。

外部接続が拒否された同一の対象で、内部repo metadataとCA検証を使用するNetBox HTTPSが200を返した。中央全体の新クローズドネットワーク再インストールは別範囲である。今回確認したのは、インターネットのない対象のOSインストール・Agentデプロイ、および内部API連携である。

9. アーキテクチャ画面検証

画面・機能	結果
1920×1080 フルスクリーン	中央サービスと3環境の12ノード、タブ・説明・下部フローが画面内に表示
画面合わせ倍率	graph-scroll client 1590×740、scroll 1590×740。デフォルト倍率で切れなし
本文幅 784px	全体構造を表示、説明パネルのみ独立スクロール
モバイル 390×844	本文の横方向のはみ出しなし、小さな構成要素も下部の説明エリアに配置
全体 / 自動化 / モニタリング / 障害	タブとNetBox・IPAMの段階、Witness/NFSの障害説明を確認
拡大・復帰	125%拡大、全体表示100%、全画面表示の開始・終了を確認
ブラウザエラー	収集されたconsole errorなし

アーキテクチャの障害状態とフローの再生は説明用である。サーバーにコマンドを送信したり実際の状態を表示したりする運用ダッシュボードではない。

10. 検証チェックリストと境界

点検項目	結果・根拠
Rocky実インストール / SELinux Enforcing	PROD・DEV・STGの実ゲスト確認
NetBox詳細フィールド・IPAM・primary IP	実資産・Interface・IPAddressの関係確認
NetBoxベースのAWX inventory	Workflowのsource updateと接続変数の確認
Zabbix API登録以降の実データ	PROD・DEV・STGのuptime・lastclock確認
インストール完了検知 → AWX自動実行	承認者確認後、STG Workflow 38自動実行・成功
資産再実行・アドレス競合・識別子変更	重複なし、競合入力変更前は拒否
部分的な収集失敗時の既存値保存	障害注入テスト通過後、正常観測に復元
中央アクティブノードの電源喪失	DB昇格・API再開・新しい監視データ・書き込み確認
障害ノードの復帰	PostgreSQL sync standby、lag 0、App healthy
Proxy送信切断	SQLite保管と中央履歴のbackfill確認
環境通信制限 / Bastion経路	許可・拒否経路別の接続確認
内部RPMダウンロード / 署名	キャッシュをクリアした実際の再ダウンロード・再インストール成功
NetBox 論理DBバックアップ・復元	別DBでの同一資産・IP参照確認
フルスクリーン・モバイルアーキテクチャ	FHD 1920×1080、本文784px、モバイル390px確認
物理サーバー UEFI/BMC/RAID	未実施
中央全体の新規定常閉域再構築	手順作成、全体再インストール試験未実施
NFS・quorum・Gateway・Proxy VMの単体障害	影響分析、該当障害インジェクションは未実施
全体システムのディザスタリカバリ・負荷・長時間耐久試験	未実施

実際の物理サーバーのUEFI PXE、BMC・RAID自動化、2つの物理ホスト間の障害、ストレージ全体障害、すべての商用DB/WAS製品バージョンの検出は、このVM実習で検証されたとはみなさない。各機能の実装と実際の試験範囲を分離する。

オンライン初期インストールと、インターネットのない環境へのインストール・エージェント配布も区別する。中央全体を新しい閉域網で最初から再インストールする試験には、持ち込みバンドルの依存関係検証も含める必要がある。既存サービスの外部NICを切断しただけの結果をもってこれに代えることはできない。

本実習で通過した項目と次の検証課題を同じ表にまとめた。個人のPC1台の結果を、運用SLAやあらゆる障害におけるデータ損失なしの保証として表現してはならない。