UPS 連動シャットダウン構成 (完成版 v2)

// UPS NUT 2-of-3 — hirame 追加済 / 最終更新: 2026-05-14

稼働中 APC Smart-UPS 1200 ×3 + 2-of-3 判定 + 復電キャンセル + 4段階停止シーケンス (Supermicro → hirame → DarkHero → R640)

構成概要

katuocloud DC では APC Smart-UPS 1200 × 3台 を用いて 2-of-3 判定による安全停止 を行う。 監視ノードは R640。 R640 が NUT (Network UPS Tools) で 3 台の UPS を SNMP 経由で監視し、 停電条件成立時に Supermicro → hirame → DarkHero → R640 の順で停止する。

UPS 一覧
UPSIP (VLAN10)NMC接続機器
UPS-A192.168.10.50AP9630通信 / Switch (12XS, 48T, RTX1300) + DarkHero + hirame
UPS-B192.168.10.51AP9630Server 系 (R640 / maguro 電源系統の一部)
UPS-C192.168.10.52AP9630Server 系 (R640 / maguro 電源系統の一部)
コンセント割当の都合: DarkHero と hirame はコンセント口数の都合で UPS-A に接続。 R640 と maguro はサーバ電源 2系統を UPS-B / UPS-C に分散して冗長化。
停止ロジック: 2-of-3

3 台の UPS のうち 2 台以上が OB (On Battery) になった場合のみ停電扱い。 単独 OB (1 台だけ) はノイズ・誤検知として無視する (例: コンセント抜けでひと UPS だけ OB になっただけ等)。

条件動作
2 台以上 OB を検知statefile 作成、 タイマー開始
5 分連続継続停止シーケンス実行
5 分以内に復電 (OB → OL に戻る)statefile 削除、 停止キャンセル
停止順序 (5分待機後)
停電検知 (2-of-3) │ │ 5min 待機 (復電チェック) ▼ ┌──────────────────────────┐ │ 1. maguro (Storage Node) │ ssh maguro ‘sudo shutdown -h now’ └──────────────────────────┘ │ sleep 20 ▼ ┌──────────────────────────┐ │ 2. hirame (Collabora) │ ssh hirame ‘sudo shutdown -h now’ └──────────────────────────┘ │ sleep 20 ▼ ┌──────────────────────────┐ │ 3. DarkHero (Windows) │ ssh darkhero ‘shutdown /s /t 30 /c …’ └──────────────────────────┘ │ sleep 40 ▼ ┌──────────────────────────┐ │ 4. R640 (Control / 自身) │ shutdown -h now └──────────────────────────┘
// 停止順序の理由
  • maguro 最優先: ストレージ (LUKS + bcache + XFS) を先に止めてデータ破損リスクを最小化
  • hirame 次: Collabora サービスを安全停止 (NC データ本体は maguro)
  • DarkHero: クライアント / 計算ノードを停止
  • R640 最後: 管理ノードは最後まで生かして停止制御を担当
NUT 構成 (R640 上)

監視ノード: R640。 SNMP (APC AP9630) で UPS 3 台を polling。

// /etc/nut/nut.conf
MODE=netserver
// /etc/nut/ups.conf
[ups-a]
driver = snmp-ups
port = 192.168.10.50
community = public
desc = "UPS-A"

[ups-b]
driver = snmp-ups
port = 192.168.10.51
community = public
desc = "UPS-B"

[ups-c]
driver = snmp-ups
port = 192.168.10.52
community = public
desc = "UPS-C"
// /etc/nut/upsd.conf
LISTEN 127.0.0.1 3493
LISTEN 192.168.10.21 3493

※ 192.168.10.21 = R640 MGMT IP

// /etc/nut/upsd.users
[upsmon]
password = (設定済み)
upsmon master
// /etc/nut/upsmon.conf
MONITOR ups-a@localhost 1 upsmon (password) master
MONITOR ups-b@localhost 1 upsmon (password) master
MONITOR ups-c@localhost 1 upsmon (password) master
通信確認 (R640 から)
# ping 確認
ping 192.168.10.50  # UPS-A
ping 192.168.10.51  # UPS-B
ping 192.168.10.52  # UPS-C

# SNMP walk 確認
snmpwalk -v1 -c public 192.168.10.50 | head
snmpwalk -v1 -c public 192.168.10.51 | head
snmpwalk -v1 -c public 192.168.10.52 | head

# NUT 状態確認
upsc ups-a@localhost
upsc ups-b@localhost
upsc ups-c@localhost

正常時ステータス例:

  • ups.status: OL (On Line)
  • battery.charge: 100
  • battery.runtime: 正常
SSH 停止経路
// maguro (Storage)
接続エイリアスssh maguro
HostName192.168.10.31 (VLAN10 MGMT)
実行ユーザーupsctl
停止権限visudo: upsctl ALL=(ALL) NOPASSWD: /usr/sbin/shutdown
authorized_keys/data/sftp/upsctl/.ssh/authorized_keys (SFTP 系構成のため通常のパス外)
安全テストssh maguro 'sudo shutdown -k now' 成功済
// hirame (Collabora) — 2026-03-31 追加
接続エイリアスssh hirame
HostName192.168.10.40 (VLAN10 MGMT)
実行ユーザーhirame
停止権限visudo: hirame ALL=(ALL) NOPASSWD: /usr/sbin/shutdown
authorized_keys/home/hirame/.ssh/authorized_keys (通常 Linux 構成)
役割Collabora Code (office.k2-o.net 関連)
電源接続UPS-A (192.168.10.50)
安全テストssh hirame 'sudo shutdown -k now' 成功済
// DarkHero (Windows)
接続エイリアスssh darkhero
HostName192.168.10.10
実行ユーザーneowa
動作確認ssh darkhero "hostname" → WAN-PC
停止コマンドshutdown /s /t 30 /c "メッセージ"
authorized_keysC:\ProgramData\ssh\administrators_authorized_keys (管理者ユーザのため)
SSH 鍵構成

UPS 自動停止専用に パスフレーズ無し鍵 を作成 (cron 実行のため)。

// 鍵ファイル (R640)
~/.ssh/id_ed25519_ups_auto
~/.ssh/id_ed25519_ups_auto.pub
// SSH config (R640)
Host maguro
    HostName 192.168.10.31
    User upsctl
    IdentityFile ~/.ssh/id_ed25519_ups_auto
    IdentitiesOnly yes

Host hirame
    HostName 192.168.10.40
    User hirame
    IdentityFile ~/.ssh/id_ed25519_ups_auto
    IdentitiesOnly yes

Host darkhero
    HostName 192.168.10.10
    User neowa
    IdentityFile ~/.ssh/id_ed25519_ups_auto
    IdentitiesOnly yes
停電判定スクリプト
// /usr/local/bin/ups-check.sh
  • UPS-A / B / C の ups.status を取得
  • OB を含む台数をカウント
  • 2 台以上なら statefile 作成 (タイマー開始)
  • 5 分継続した場合のみ停止シーケンス実行
  • 復電したら statefile 削除 → 停止キャンセル
// cron (root)
* * * * * /usr/local/bin/ups-check.sh >/dev/null 2>&1
実際の停止シーケンス
# 1) maguro (Storage)
ssh -o BatchMode=yes maguro 'sudo /usr/sbin/shutdown -h now'
sleep 20

# 2) hirame (Collabora)
ssh -o BatchMode=yes hirame 'sudo /usr/sbin/shutdown -h now'
sleep 20

# 3) DarkHero
ssh -o BatchMode=yes darkhero 'shutdown /s /t 30 /c "UPS 2-of-3 battery event: controlled shutdown from R640"'
sleep 40

# 4) R640 (自身)
shutdown -h now
復電キャンセル仕様

完成版スクリプトでは 5 分待機中に 2-of-3 条件が解除された場合は停止をキャンセル する。

// 例
  • UPS-A / B が OB
  • 3 分後に商用電源復帰 → 両方 OL に戻る
  • statefile 削除
  • 停止しない
現在の完成度
完了済
  • ✓ UPS 3 台の固定 IP 設定 (VLAN10)
  • ✓ SNMP 有効化 (community public)
  • ✓ R640 で NUT 監視
  • ✓ 2-of-3 判定スクリプト
  • ✓ 復電キャンセル仕様
  • ✓ maguro SSH 停止
  • ✓ hirame SSH 停止 (2026-03-31 追加)
  • ✓ DarkHero SSH 停止
  • ✓ cron 自動監視
運用上の注意
// ① cron 実行なので手動 ssh-agent 不要

UPS 自動停止専用鍵 id_ed25519_ups_auto は パスフレーズ無し で作成済前提。

// ② Windows 側 authorized_keys

DarkHero は管理者権限ユーザのため、 通常の ~/.ssh/authorized_keys ではなく:

C:\ProgramData\ssh\administrators_authorized_keys
// ③ maguro 側 authorized_keys

maguro は SFTP 系設定のため、 通常の /home/.../.ssh ではなく:

/data/sftp/upsctl/.ssh/authorized_keys
// ④ hirame 側 authorized_keys

hirame は通常の Linux 構成:

/home/hirame/.ssh/authorized_keys
設計評価

この構成は単純な家庭 UPS 運用ではなく、 以下を満たす:

  • 複数 UPS 監視
  • 2-of-3 停電判定 (誤検知耐性)
  • 復電キャンセル
  • ストレージ優先停止 (データ保全)
  • サービス階層別停止 (Collabora → Client → Management)
  • Windows / Linux 混在停止
  • 管理ノード最終停止
評価: 家庭ラボというより小規模 DC 設計レベル。 「ピーンと電源切れる」事態に対して 4段階で順序立てて停止 + 復電時自動キャンセルが効く。
変更履歴
日付変更内容
2026-03-xx初版作成 (Supermicro + DarkHero + R640)
2026-03-31hirame 追加 (Collabora CODE 自動停止対応)
2026-05-14R640 fresh install + ssh alias 名 (supermicro → maguro) リネーム時に config 反映確認
次にやると良いこと
  • ! 実停電を模したテスト手順書作成 (年1回の停電テスト)
  • ! UPS ごとのバッテリー健全性確認 (3年で劣化)
  • ! R640 再起動後の NUT 自動復旧確認
  • ! 復電後のノード起動順序設計 (BIOS WoL + 待機)
  • ! Telegram 通知連動 (停電検知 → 即座に通知)