雲端上跑有用到 GPU 的 VM

去年底有個有趣的案子，一個 campaign 網頁會用到一些機器學習的東西，所以弄了 tensorflow，在 GCP 上跑了有 NVidia Tesla T4 的 VM。

一開始跑都沒啥問題，但是過了一陣子，伺服器就會抓不到 GPU，下 nvidia-smi 會說

Failed to initialize NVML: Driver/library version mismatch

然後整個服務就是爛掉的。當時想應該是 auto security upgrade 還是 auto package upgrade 之類的東西搞得鬼，所以找了方式去擋，都是看跟 apt 相關的，用 apt-mark hold 這個指令標了一堆套件，叫它不要升級。擋了 cuda、libcudnn、nvidia driver、libnvinfer…

但是過了一段時間後，還是一樣，一直爛掉，當時的感覺是有漏網之魚，所以越加越多…不過過一段時間，又再度發生。

這在我們的部署設定沒有很好 debug，因為我們跑在 GCP 的 Managed Instance Group 底下，有設 healthcheck，所以如果 fail 一段時間，MIG 會把 Instance 直接終結然後用之前的 image 重開一台機器，所有證據都灰飛煙滅！

不過我想當初懷疑的方向應該是正確的，再研究了一下，似乎是某些套件升級的時候，DKMS 會重新編譯 NVidia 的 kernel module，做完之後要 reboot（或是要 reload 什麼東西），才會正常。但因為是 auto package upgrade（其實那東西叫做 unattended-upgrade），所以更新完了不會 reboot。

我後來想想，覺得設定應該放 unattended-upgrade 才對，而不是 apt，因為我如果是手動連進來做 apt-get upgrade ，我其實人為操作我就可以自行 reboot，但如果是 unattended-upgrade，我根本不知道它什麼時候執行，執行時有沒有重編 kernel module 要不要重新開機，所以感覺是設定讓 unattended-upgrade 不要升 nvidia & kernel 相關的東西。

所以後來我是在 /etc/apt/apt.conf.d/50unattended-upgrades 裡面下了這兩行

Unattended-Upgrade::Package-Blacklist {
  "linux-";
  "nvidia-";
};

kernel 跟 nvidia 的都不要透過 unattended-upgrades 升級。

當初因為是用 GCP 的 Managed Instance Group，所以上面有一堆歷史 Image，後來測試就是拿好幾個月前的 Image，開一台機器，跑 apt-get upgrade 看有沒有效，或是 apt-mark hold xxx hold 住一堆 packages，然後跑 unattended-upgrade -d 看會發生什麼事；設定 Blacklist，再跑跑 unattended-upgarde -d 看有沒有用，慢慢 trial and error。

目前為止好像都還 ok（fingers crossed）。