はじめに

Ubuntuを搭載したEdge PCを24時間365日、無人で運用する場合、

OSが起動する
Dockerが起動する
Applicationが起動する
Cloudへ接続できる

だけでは十分ではありません。

実際の長期運用では、

時刻がずれる
DNSの状態が変わる
Routeが戻らない
Firewall / NATの状態が崩れる
NICが正常に復帰しない
Update後にRebootが必要になる
Container Runtimeの状態が変わる
電源断後に一部だけ正常に戻らない

といった問題も考える必要があります。

そこで今回のEdge PCでは、

異常を一度も発生させないことを目指すのではなく、異常が発生しても正常状態へ戻りやすい構成にする

という方針にしました。

その中心として使用したのが、

systemd service
systemd timer

です。

この記事では、Ubuntu Edge PCを24/365で無人運用するために実際に採用した、

定期Maintenance
処理時間の分散
定期Reboot
Boot後の自己復旧
NTP / DNS / Route / NAT / Firewall確認
UpdateとRebootの分離
NIC復旧
systemd timerの監視
外部監視との役割分担

について整理します。

結論：無人Edge端末は「壊れない」より「戻れる」ようにする

今回の構成を先にまとめると、

① 壊れにくくする
    ↓
② 壊れたら正常状態へ戻す
    ↓
③ 戻せなければ外部から検知する

という3段階です。

具体的には、

予防
├─ Version管理
├─ Security Update
├─ 定期Maintenance
└─ Maintenance時間の分散

自己復旧
├─ 定刻Reboot
├─ Boot後のRoute確認
├─ Firewall / NAT確認
├─ DNS確認
├─ NTP同期
├─ NIC復帰
└─ 必要時Reboot

外部検知
├─ Ping
├─ Heartbeat
├─ Telemetry
├─ rsyslog
└─ netconsole

という構成にしました。

ポイントは、

一つの強力な仕組みで安定させようとしない

ことです。

1. 「正常に起動した」だけでは24/365運用にならない

開発時には、

Power ON
↓
Ubuntu起動
↓
Docker起動
↓
Azure IoT Edge起動
↓
Application起動
↓
Cloud接続

まで確認できれば、正常に見えます。

しかし、無人運用で重要なのはその瞬間ではありません。

1日後
1週間後
1か月後
Update後
Network断後
Power Failure後

にも、同じ正常状態へ戻れる必要があります。

そのため今回の設計では、

正常状態を最初に作る

だけでなく、

正常状態を定期的に作り直す

ことを重視しました。

例えば、

一時的なNetwork異常
Router / DHCP側の変化
時刻ずれ
Package Update
Process停止
予期しないReboot
Power Failure

などは、Edge PCだけでは完全には防げません。

そこで、

異常を完全に防ぐ

という考え方から、

現在状態を確認
↓
正常なら何もしない
↓
異常なら修復
↓
Normal Stateへ戻す

という考え方へ変更しました。

2. Maintenance処理を巨大な1本のScriptにしない

最初に避けたのが、

毎晩01:00

NTP確認
DNS確認
Network再設定
Package Update
Container Restart
Reboot

のように、すべてを1本のScriptで処理する構成です。

確かにFile数は少なくできます。

しかし障害時に、

どこで失敗したのか分からない
一つ失敗すると後続処理まで止まる
Network処理とUpdateが衝突する
Rebootされると原因を追いにくい

という問題があります。

そこで役割ごとに、

NTP
NAT
DNS
IoT Edge Update
OS Reboot判定
IoT Edge Reboot判定
NIC復帰
Route修復
Firewall確認
Diagnostic

を分離しました。

3. systemd serviceとtimerで「実行時刻」と「処理」を分ける

Ubuntuでは、

systemd service
+
systemd timer

を使っています。

基本構成は、

.timer
↓
いつ実行するか

.service
↓
何を実行するか

です。

例えばNTP同期なら、

mdlinkage-ntp-sync.timer
↓
mdlinkage-ntp-sync.service
↓
NTP同期処理

という形です。

Timer自体の状態は、

systemctl status mdlinkage-ntp-sync.timer

で確認できます。

実際に実行された処理は、

journalctl -u mdlinkage-ntp-sync.service

で確認できます。

この構成のメリットは、

「いつ動かすか」と「何をするか」を分離できる

ことです。

4. 実際のMaintenance Schedule

今回のEdge PCでは、主なMaintenanceを次のように分散しました。

00:15
定刻Reboot

00:45
NTP Sync
NAT確認

01:00
DNS確認・再設定

01:30
IoT Edge / Moby Patch確認

02:30
OS Updateによる
reboot-required確認

03:30
IoT Edge / Moby Update後の
Reboot Flag確認

04:30
NIC状態確認・復帰

さらにBoot後にも、

Route
NAT
Firewall
NIC
Network関連設定
NTP

を再確認します。

重要なのは、

すべてを同時に実行しないこと

です。

5. Maintenance時間をずらす理由

例えば同じ時刻に、

NTP同期
Package Update
DNS変更
Container Restart
Network再設定
Reboot

を実行したとします。

一つ一つは正常でも、組み合わせによって、

Networkが一時的に切れる

Update途中でRebootする

DNS確認中にNICがRestartする

Container確認中にRuntimeが更新される

といった問題が発生する可能性があります。

また障害が起きても、

NTP？
DNS？
Update？
Network？
Reboot？

と原因を切り分けにくくなります。

そこで、

処理A
↓
時間を空ける
↓
処理B
↓
時間を空ける
↓
処理C

としています。

Maintenance処理同士も障害原因になり得る

という前提です。

6. 定期Rebootを入れるなら「Reboot後に戻れること」が前提

今回の構成では、

00:15

に定刻Rebootを実行しています。

目的は、

長時間動作による一時的な状態蓄積
Application / Runtimeの状態変化
Network Stackの一時的な異常
Processの想定外状態

などを一度CleanなBoot状態へ戻すことです。

ただし、

定期Rebootを入れれば安定する

という意味ではありません。

例えばReboot後に、

Networkが戻らない
Routeがない
Firewallが戻らない
NATがない
NICがDown
IoT Edgeが起動しない

となれば、Rebootそのものが障害原因になります。

そのため、

Reboot
↓
Ubuntu Boot
↓
Network Ready
↓
Route確認
↓
Firewall / NAT確認
↓
NIC確認
↓
NTP同期
↓
Application復旧

までを一つのRecovery設計として考えます。

7. Recovery Scriptは「正常なら何もしない」

Boot後のRoute確認では、

現在のRoute確認
↓
正常
↓
OKとして終了

とします。

異常な場合だけ、

現在のRoute確認
↓
Route不足
↓
期待状態へ修復

します。

FirewallやNATも同様です。

現在のRule確認
↓
正常
↓
何もしない

または、

現在のRule確認
↓
不足・異常
↓
期待状態へ戻す

です。

つまり、

Timer起動
↓
毎回設定を書き直す

のではありません。

Timer起動
↓
現在状態を確認
↓
正常なら終了
↓
異常なら修復

としています。

Maintenance処理は、

何度実行しても正常状態を壊しにくいこと

が重要です。

8. NTP / DNSも「最初に設定したからOK」ではない

NTP

Edge Gatewayでは時刻も重要です。

時刻がずれると、

TLS Certificate
Log時刻
Cloud通信
障害解析
複数端末間のLog比較

などへ影響します。

特にTroubleshootingでは、

Edge PC Log
Network Log
Cloud Log

を時系列で比較するため、各機器の時刻がずれていると解析が難しくなります。

今回の構成では、

00:45
NTP Sync

に加え、

Boot
↓
Network Ready
↓
NTP Sync

も行っています。

DNS

Cloud接続ではDNSも重要です。

例えば、

IP通信
↓
OK

DNS Resolve
↓
NG

なら、Network Interface自体が正常でもAzure IoT Hubへ接続できません。

利用者から見ると、

Networkはつながっている

でも

CloudへDataが送れない

という状態です。

そのためDNSも一度設定して終わりではなく、定期的に確認します。

切り分けも、

NIC
↓
Network
↓
Route
↓
DNS
↓
Cloud

のようにLayerごとに分けて考えます。

9. Update処理とReboot処理を分離する

無人運用では、

Update
↓
即Reboot

という構成にはしていません。

例えばUbuntu側でKernelや重要Packageが更新されると、

/var/run/reboot-required

が生成される場合があります。

今回の構成では、

Update完了
↓
時間を空ける
↓
02:30
↓
reboot-required確認
↓
あり → Reboot
なし → 何もしない

としています。

つまり、

Updateする処理とRebootする判断を分離する

構成です。

10. IoT Edge / Container RuntimeのUpdateも専用処理にする

Azure IoT Edge / Container Runtimeについても、OS Maintenanceとは分離しました。

01:30

に、

Installed Version確認
↓
Candidate Version確認
↓
同一世代か確認
↓
Dry-run
↓
依存関係確認
↓
条件を満たせばPatch
↓
Health Check

という専用の処理を通します。

UpdateによってRebootが必要になった場合は、

IoT Edge / Moby Update
↓
pending-iotedge-reboot

のようにFlagを残します。

その後、

03:30
↓
Flag確認
↓
条件確認
↓
必要ならReboot

します。

これにより、

Update
↓
即Reboot

ではなく、

Update
↓
Flag
↓
Maintenance Window
↓
Reboot

という制御ができます。

また複数台のEdge PCを想定し、

RandomizedDelaySec

も利用しています。

これにより全端末が完全に同じ瞬間にMaintenanceを開始することを避けます。

11. Maintenanceの最後にNICも確認する

ApplicationやContainerが正常でも、

NIC Down

であればGatewayとしては動作できません。

そのため、

04:30
NIC状態確認

も行います。

今回の設計では、

Application
Container
OS
Network Interface

を別々のLayerとして考えています。

Application正常
+
Container正常
+
OS正常
+
NIC異常

であれば、

Gatewayとしては異常

です。

12. 定期MaintenanceだけでなくBootをRecovery Triggerにする

Timerを毎日設定していても、

Power Failureが、

00:30

に発生した場合、次の定期Maintenanceまで待つわけにはいきません。

そこで一部の処理では、

OnBootSec

を使っています。

対象は例えば、

NTP
NAT
Route
NIC
Firewall

です。

つまり、

Power Failure
↓
Power Restore
↓
Ubuntu Boot
↓
Recovery処理開始

として、

BootそのものをRecovery Triggerにする

設計です。

13. `Persistent=true`は処理によって使い分ける

systemd timerには、

Persistent=true

があります。

例えば01:00に予定していた処理の時間にPCが停止していた場合、

01:00
PC OFF
↓
処理できない
↓
次回Boot
↓
未実行処理を実行

とできます。

ただし、すべてのTimerで有効にするわけではありません。

例えば毎日00:15の定刻Rebootについて、

昨日00:15
PC OFF
↓
今日Boot
↓
昨日Rebootできなかったので今Reboot

とする必要はありません。

そのため、

実行漏れをBoot後に補う処理

と、

実行漏れを補わない処理

を分けます。

重要なのは、

Persistent=trueを使うかどうかではなく、その処理の目的

です。

14. Timerを作っただけではなく「実際に動いた証拠」を確認する

無人端末では、人が画面を見て処理成功を確認できません。

そのためLogを残します。

Service単位のLogは、

journalctl -u mdlinkage-ntp-sync.service

で確認できます。

Timer全体は、

systemctl list-timers --all

で確認できます。

Maintenance用Timerだけ確認するなら例えば、

systemctl list-timers --all | grep -E \
'mdlinkage|mdl-|reboot-if'

のように確認できます。

見るべきなのは、

Timer Fileが存在する

だけではありません。

enabledか
activeか
期待する時刻になっているか
実際にServiceが実行されたか
Exit Codeが正常か

まで確認します。

今回のAcceptance Checkでは、

00:15 定刻Reboot

00:45 NTP

00:45 NAT

01:00 DNS

01:30 IoT Edge Patch

02:30 OS Reboot Check

03:30 IoT Edge Reboot Check

04:30 NIC Wakeup

が期待どおり登録されているか確認します。

さらにBoot後には、

Route
NTP
NAT
Firewall
NIC

などが、

現在のBoot Sessionで実際に実行された証拠

まで確認します。

設定Fileが存在することと、実際に動作したことは別です。

15. 自己復旧だけでは検知できない障害もある

ここまでの仕組みによって、

時刻
DNS
Route
Firewall
NAT
NIC
IoT Edge
Container Runtime
Reboot Requirement

など、多くの状態をEdge PC自身で確認できます。

しかし、Edge PCそのものが完全にFreezeした場合は別です。

Edge PC
↓
Freeze
↓
CPU / Kernel / Network停止

となれば、

systemd timer
Health Check
Log保存
Recovery Script

自体が動きません。

そこで、

Edge PC自身
↓
正常状態を維持
異常なら自己復旧

と、

External Monitor
↓
Edge PCが本当に生きているか
外側から確認

を分けました。

外部監視側では、

Ping
Heartbeat
Telemetry
rsyslog
netconsole

など複数の経路を使います。

これによって、

Applicationだけ停止

Networkだけ停止

OS全体がFreeze

Kernel Crash

などの切り分けをしやすくします。

16. 24/365無人Edge端末の設計を整理する

今回の設計をまとめると、3つのLayerになります。

① 予防
────────────────

Version管理
Security Update
定刻Maintenance
Maintenance時間の分散


② 自己復旧
────────────────

定刻Reboot
Boot後のRoute確認
Firewall / NAT確認
DNS確認
NTP同期
NIC復帰
必要時Reboot


③ 外部検知
────────────────

Ping
Heartbeat
Telemetry
rsyslog
netconsole

つまり、

壊れにくくする
↓
壊れたら戻す
↓
戻せなければ外から検知する

という構成です。

まとめ

24/365の無人Edge端末を安定稼働させるために、特別なTechnologyを一つ導入したわけではありません。

使用しているのは、

systemd
systemd timer
journal
nftables
Shell Script
Health Check

など、Linuxでは一般的な仕組みです。

重要だったのは、

どの異常に対して

どのLayerで

いつ確認して

どこまで自動復旧し

どこから外部監視へ任せるか

をSystem全体として設計することでした。

そしてRecovery処理についても、

毎回設定を書き直す

のではなく、

現在状態を確認
↓
正常なら何もしない
↓
異常なら期待状態へ戻す

ようにしています。

24時間365日の無人運用では、「止まらないこと」だけではなく、「正常状態へ戻れること」と「戻れなかったことを検知できること」が重要です。

次回は、Edge PC自身が完全にFreezeした場合に備えて、

監視対象とは別のLinux端末からEdge PCを監視する構成

について整理します。

Edge PC
↓
Ping
Heartbeat
Telemetry
rsyslog
netconsole
↓
External Monitor

自己復旧できない障害を、どのように外側から検知し、Freeze直前の情報を残すかを紹介します。