Windows 11を搭載したEdge PCで、原因の特定が難しい完全フリーズが発生していました。
これまで、
- 不要なDriverを減らす
- Intel Graphic Driverを見直す
- Windows UpdateによるDriver更新を抑える
- 不要なDeviceを無効化する
といった対策を行い、安定性には改善が見られました。
しかし、それでも一つ問題が残りました。
原因がWindows側なのか、Hardware側なのか切り分けられていない
という点です。
そこで、同じHardwareを使ったまま、
Windows 11
↓
Ubuntu 24.04 LTS
へOSを変更して検証しました。
この記事では、Windows 11で原因不明のフリーズが発生したEdge PCに対して、
USBからLinuxを起動
↓
Linux単体で動作確認
↓
SSDへUbuntuをインストール
↓
IoT Edge / Applicationを追加
↓
オンサイト環境で検証
という順番で、OS・Driver・Hardwareのどこに原因があるのかを切り分けた方法をまとめます。
この記事でやったこと
今回の目的は、
WindowsからLinuxへ移行すること自体ではなく、フリーズ原因を切り分けること
です。
基本的な考え方はシンプルです。
Hardwareは変えない
Applicationも最終的には同じものを使う
OSだけを変更する
この状態でWindowsとLinuxを比較します。
例えば、
Windows → Freezeする
Linux → Freezeしない
のであれば、
Windows
Driver
電源管理
OS固有のSoftware
などを疑う材料になります。
一方、
Windows → Freezeする
Linux → Freezeする
のであれば、
BIOS
Firmware
Hardware
電源
SSD
Memory
CPU
など、OSより下位のレイヤーを優先して調査できます。
環境
今回検証したEdge PCは、Windows 11 Proで運用していた小型PCです。
Linux側では、
Ubuntu 24.04 LTS
を使用しました。
最終的には、このPC上で、
Ubuntu
↓
Container Runtime
↓
Azure IoT Edge
↓
Edge Application
を動かします。
ただし、最初からすべてをインストールすることはしませんでした。
1. Windows上だけで調査しても切り分けきれなかった
Windows 11上では、すでに複数の対策を実施していました。
例えば、
不要なDriverを削除
Graphic Driverを変更
不要なDeviceを無効化
Driverの自動更新を抑制
などです。
これによって動作は改善しました。
しかしWindowsには、
Windows Update
PnP / Device Driver
電源管理
Graphic Stack
Background Service
Security機能
自動Maintenance
など、多数の仕組みがあります。
不要なDriverやApplicationを削除しても、
Windows自体の動作を完全に取り除いて比較することはできません。
そこで、OSそのものを変更して比較することにしました。
2. いきなりSSDへLinuxをインストールしない
Linuxを試すからといって、最初からSSDを初期化してUbuntuをインストールしたわけではありません。
最初に行ったのは、
USBメモリからLinuxを起動する
ことです。
構成は次のようになります。
Edge PC
│
├─ 内蔵SSD
│ └─ Windows 11
│
└─ USB Memory
└─ Linux
この方法であれば、
CPU
Memory
NIC
Graphic Device
Motherboard
BIOS
などのHardware条件を変えずに、OSだけを変更できます。
つまり、
Hardware
↓
Windows
と
Hardware
↓
Linux
を比較できます。
3. USB起動したLinuxではApplicationを入れない
USBからLinuxを起動した段階では、Edge Applicationを入れませんでした。
最初に確認したかったのは、
Linuxだけを起動した状態でもフリーズするのか
という点だからです。
この段階では、できるだけ、
Hardware
↓
Linux
↓
標準Driver
に近い状態にします。
まだ、
Azure IoT Edge
Container
Edge Application
Monitoring Tool
などは追加しません。
変更点を増やしてしまうと、フリーズした場合に何が原因なのか分からなくなるためです。
4. Linux単体で安定するか確認する
LinuxをUSB起動したら、まずOS単体で動作を確認します。
確認する項目は例えば、
- 正常に起動するか
- 再起動できるか
- Networkが安定しているか
- 長時間稼働できるか
- Freezeしないか
です。
この段階でフリーズするのであれば、
Applicationより先に、
Linux Kernel
Driver
BIOS
Firmware
Hardware
などを調査する必要があります。
逆にLinux単体では安定しているのであれば、次の構成へ進めます。
5. SSDへUbuntu 24.04 LTSを最小構成でインストールする
USB起動で大きな問題が見られなかったため、次に内蔵SSDへ、
Ubuntu 24.04 LTS
をインストールしました。
ここでも重要なのは、
最初からすべてのSoftwareを入れないこと
です。
まずは、
Hardware
↓
Ubuntu
だけの状態を作ります。
そして、
起動
再起動
Network
長時間稼働
Freeze有無
を確認します。
6. 安定したらSoftwareを1段ずつ追加する
Ubuntu単体で問題がなければ、次に実際のEdge環境を構築します。
概念的には、
STEP 1
Hardware
↓
Ubuntu
から、
STEP 2
Hardware
↓
Ubuntu
↓
Container Runtime
↓
Azure IoT Edge
へ進めます。
さらに、
STEP 3
Hardware
↓
Ubuntu
↓
Container Runtime
↓
Azure IoT Edge
↓
Edge Application
と段階的に追加します。
こうすることで、
どの変更を加えたタイミングで問題が発生したのか
を追いやすくなります。
7. Azure IoT EdgeとEdge Applicationを導入する
OS単体での動作を確認した後、実際に使用するEdge Applicationを導入します。
今回の環境では、Edge PC上で複数のContainerが動作します。
例えば、
edgeAgent
edgeHub
Relay / Conversion系Module
TCPServer
SendAzure
localstorage
などです。
構成としては、
Device
↓
Edge PC
├─ edgeAgent
├─ edgeHub
├─ TCPServer
├─ Application Module
├─ SendAzure
└─ localstorage
↓
Azure
となります。
ここまで導入すると、単純なPCの動作確認ではなく、
実際の運用に近いCPU・Memory・Network負荷を与えた状態
で検証できます。
8. Applicationが動いても検証完了ではない
開発環境で数時間正常に動いたからといって、
Ubuntuなら問題ない
と判断するのは早すぎます。
Lab環境と実際のオンサイト環境では条件が異なります。
例えば、
Network環境
接続Device
通信量
Firewall
Cloudとの通信状態
電源環境
連続稼働時間
再起動回数
温度
などです。
特にEdge PCでは、
数時間動くことと、数か月無人で動き続けることは別の問題
です。
そのため最終的には、実際のオンサイト環境へ持ち込んで長期試験を行います。
9. フリーズ原因を切り分けるときは「一度に1つだけ変える」
今回もっとも重要だったのは、WindowsからLinuxへ変更したことそのものではありません。
重要なのは、
変更する条件を一度に増やしすぎない
ことでした。
例えば、
WindowsでFreeze
↓
Ubuntuをインストール
↓
Dockerをインストール
↓
IoT Edgeをインストール
↓
Applicationをインストール
↓
Kernel設定変更
↓
Monitoring Tool追加
を一気に行ってしまうと、その後安定しても、
何が効いたのか？
が分かりません。
逆に問題が再発した場合も、
Ubuntu
Kernel
Driver
Docker
IoT Edge
Application
のどれが原因なのか分からなくなります。
そのため、
① LinuxをUSB起動
② Ubuntuのみ
③ Container Runtime追加
④ Azure IoT Edge追加
⑤ Edge Application追加
⑥ オンサイト環境へ投入
という形で、条件を少しずつ増やしました。
10. 今回の切り分けフロー
全体をまとめると、次のようになります。
Windows 11
│
│ Freeze発生
│
├─ Driver削減
│
├─ Device構成変更
│
├─ Graphic Driver見直し
│
└─ Driver Update抑制
│
▼
それでも原因を完全には特定できない
│
▼
OS自体を切り分ける
│
▼
USBからLinux起動
│
▼
Ubuntu単体で確認
│
▼
SSDへUbuntuをインストール
│
▼
Container Runtime
│
▼
Azure IoT Edge
│
▼
Edge Application
│
▼
オンサイト試験
この順番で確認すると、
どのレイヤーまでは正常だったか
どの変更後から問題が起きたか
を追跡しやすくなります。
WindowsでもLinuxでもフリーズする場合
Linuxへ変更しても同じような完全フリーズが発生するのであれば、
Windows固有の問題ではない可能性が高くなります。
その場合は、
BIOS
Firmware
Memory
SSD
CPU
Motherboard
電源
温度
Kernel
Hardware固有Driver
など、より下位のレイヤーを調査する必要があります。
重要なのは、
Linuxならフリーズしないはず
と考えることではありません。
Linuxへの変更は、
原因候補を減らすための比較試験
として使います。
まとめ
Windows 11上で原因不明のフリーズが発生した場合、DriverやApplicationだけを調べ続けても、原因を切り分けきれないことがあります。
その場合、
同じHardware
+
別のOS
で比較することで、
OS / Driver側なのか
Hardware / BIOS側なのか
を判断するための材料を増やせます。
今回行った流れは、
WindowsでFreeze
↓
USBからLinuxを起動
↓
Linux単体で確認
↓
Ubuntuを最小構成でインストール
↓
Softwareを1つずつ追加
↓
IoT Edge / Applicationを導入
↓
実際のオンサイト環境で検証
です。
ポイントはLinuxへ変更することではなく、
一度に変更する条件をできるだけ1つにすること
です。
原因不明のFreezeを調査するときには、この考え方が非常に重要でした。
次回：Linuxを「動くOS」から「止まりにくいEdge環境」へ
Ubuntu上でEdge Applicationが正常に動いたとしても、それだけで24時間365日の無人運用ができるわけではありません。
実際のEdge端末では、
Software Version管理
OS / Package Update
自動再起動
Network復旧
Maintenance処理
障害検知
Cloudからの監視
なども設計する必要があります。
そこで次回からは、
Linuxを24/365の無人Edge端末として安定稼働させるための設計
についてまとめます。
まず次回は、
Azure IoT EdgeのVersionを固定しながらPatchを取り込む設計
について紹介します。