從FreeNAS 遷移到TrueNAS Scale
我並不是很想遷移，但是看起來IXsystems 已經失去了初衷，開始進入和Synology，Qnap這種廠商競爭的賽道，儘管這些家用產品銷量很大，但是Vulnerability和Bug頻出，最重要的一點是，雖然這兩間公司都聲稱自己是台灣公司，但其中一間公司的軟體開發團隊在中國深圳。
FreeNAS基於FreeBSD 的軟體版本一直停留在已經EOL的13.1-RELEASE，他們致力於開發基於Debian 的TrueNAS Scale 而放棄了Community Version FreeNAS，是的，對於基於FreeBSD 版本的Enterprise Support 他們並沒有停止。
從長遠看來，IXsystems 似乎並沒有意願繼續在FreeBSD 上開發，因為找到一個Debian 的開發者，比找到一個FreeBSD 的開發者，從機會上來說，大得多，從成本上來說，小得多，作為一間商業公司，發展路徑的選擇是可以理解的。
而我對Debian 的信心是足夠的，從歷史來看，他經過了考驗，不像Centos 的升級那麼糟糕，所以我決定進行遷移，雖說只是click 幾下而已。
這台基於AMD Opteron(tm) X3421 APU 和32G ECC memory 的HPE MicroServer Gen10 當前從使用上來講並沒有問題，由四塊8tb 的Toshiba MG08 HDD組成Raidz2 通過Rsync 為critical data進行備份以及通過NFS/CIFS 進行data share，兩塊1tb 的Crucial MX500 SSD 組成Raid1 通過iSCSI share 為ESXi 提供vmfs和為BSD Jail提供空間，兩塊SK Hynix nvme SSD 為zfs 提供read cache 和write log，雖然我知道沒有電池的write log意義不大，但是，再塞一塊帶PLP 的2.5寸SSD，確實也塞不進去。
不過4槽位的nvme PCIE 卡上確實還有兩個空槽位，於是買了兩塊Kioxia Exceria G2 2tb，因為他在pchome 的價格莫名的低，在將他們替換Crucial MX500之後，似乎就可以加入PLP SSD 了。
一個Samsung 的64G USB drive 運行底層OS，為什麼是Samsung，因為經過實驗，其他的牌子比如Sandisk 或者Kingston 都會壞，好在FreeNAS 的 boot volume 壞掉並不會影響dataset，reinstall 一遍然後把備份的dat file 導入就可以。
主要的問題有兩個，Jails和Rsyncd。
第一，FreeBSD jail 只存在於BSD 上，與TrueNAS Scale 上的docker 是完全不同的東西，我需要先把jail 遷移到ESXi，升級完成後，再將ESXi 上的vm workload 遷移回docker。
在FreeNAS 上我運行了三個jails，其中一個是database，包括mysql，redis，memecached，一個是nginx+php 的webserver，一個是resilio-sync 的數據同步。其實原本PLEX 也運行在jail，但是後來電影越來越多，裝不下啦，用舊的WD My Cloud EX2 Ultra 塞進兩塊16tb 的TOSHIBA MG08ACA16TE HDD然後nfs export給運行在ESXi 上的PLEX。
database 比較好遷移，因為他沒有使用到任何本地的掛載點，而webserver 和resilio-sync 使用了本地的掛載點，這些掛載點都需要使用nfs export 然後從ESXi 的vm 中重新進行掛載。
尚且容易，在ESXi 中啟動新的OS，設置IP地址，環境變量，安裝必要的組件，mount nfs，設置fstab，設置啟動程式，重啟測試，不到兩個小時就將三個jails 完全轉變爲vms，早年FreeBSD 很不常更新的時候，nginx 和php的版本都很陳舊，我通常會自行compile 來安裝，從FreeBSD 12開始似乎他們更新得更頻繁，可以直接從pkg 來安裝最新版本，也就簡化了很多。
第二，是TrueNAS Scale 刪除了原本存在於FreeNAS 中的Rsyncd 服務，變成了Docker 中的一個app，這一部分也還算容易，因為原本我在FreeNAS 上運行的Rsyncd 就只是要接受從BuyVM 和DigitalOcean 的webserver 每天同步過來的網站備份，重新設置一下modules ，IP whitelist 就可以。
當完成Jails的遷移後，就可以開始進行從FreeNAS 到TrueNAS Scale 的遷移啦。
首先切換要升級的目標類型，彈出警告，吧啦吧啦，大概就是上面那些，請參閱官方文件：
https://www.truenas.com/docs/scale/22.12/gettingstarted/migrate/migratingfromcore
AFP share 最重要的大概就是用到TimeMachine 的MacOS，但是Apple 已經拋棄AFP而且TimeCapsule 也後繼無人，畢竟其他的產品沒有一個能打的，應該是後無來者才對。
升級的過程絲滑無痛，我原本預計LACP 會有一些問題，畢竟跨OS 的配置完全不一樣，並不像ZFS pool 一樣可以隨意的導入導出，沒想到從FreeBSD 到Debian 可以這麼絲滑。
但SMB share 遇到一些問題，FreeBSD 上的www 用戶和用戶組，賦權給/www 的share dir，但是遷移後，www 用戶並未被遷移過來，将share 的用户和组修改为www-data 解决，這個問題看起來很奇怪，畢竟連LACP的配置他都讀了，為什麼他沒有讀取passwd 的配置呢？
接下來就是要把workload 從ESXi 遷移回到TrueNAS Scale 的Docker 上，在24.10 版本之前使用的是kubernetes ，這導致我檢索到很多的資訊都是錯誤的，請參閱官方文件：
https://www.truenas.com/docs/truenasapps
順便把原本的Docker 服務都遷移過來，一些服務只需要把目錄copy 到新的安裝中就可以，例如grafana，一些服務需要dump and import，例如mysql-server，一些服務直接啟動新的container，因為data 都在database 中，例如zabbix。
比較難搞的是n8n，因为有很多个workflow 和credential 需要export，查阅了一下官方文件，实际操作起来很简单，因为n8n 的container 里面什么command 都有……
###n8n
https://docs.n8n.io/hosting/cli-commands/#workflows
docker exec -it fc6082cbfddc sh
mkdir backup
n8n export:workflow --backup --output=backup/
tar -czf backup.tgz backup
mkdir credentials
n8n export:credentials --all --decrypted --output=credentials.json
scp backup.tgz ken@server:/tmp
scp credentials.json ken@server:/tmp
login to the new n8n:
cd /tmp
wget http://server/backup.tgz
wget http://server/credentials.json
n8n import:workflow --separate --input=backup/
n8n import:credentials --input=credentials.json需要注意的是下面两个env，缺少第二个会导致无法正确读写NAS 上的host path。
N8N_SECURE_COOKIE false
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS true到這裡就結束了，因為NFS/CIFS share 沒有任何變化，Rsyncd 也正常運作，Cloud Sync push 到Amazon S3 以及從Dropbox pull 到本地的sync tasks 也正常，並沒有太多額外需要改動的東西。
整體來說，從FreeNAS 升級到TrueNAS Scale 的過程沒有遇到什麼困難，FreeBSD 到Debian 的跨度被IXsystems 整合得相當無縫，我想這比我預期的情形要好得多，雖然直接重灌然後import zfs pool 的方式不是不可以，但如果遷移的問題過多，就會影響到眾多家用客人繼續使用的意願，說不定就直接棄用了。
兩塊2tb 的nvme ssd 不到5分鐘就rebuild 好了raid1，還是順序替換的，但是，似乎現在的nvme ssd變厚了，把硅脂導熱墊拿掉才蓋上散熱片，不知道是不是因為這個原因，他們的運行溫度維持在了59度左右，不過以告警溫度78攝氏度來看，這應該是一個正常的溫度。
