2019年1月31日 星期四

[經驗分享]Proxmox VE 批次遷移多台主機



Proxmox VE 提供了方便的線上遷移,點幾下滑鼠就可以讓一台主機遷移到其它節點。

若我想要某個節點能一次要遷移好幾台到另外一個節點,除了一個一個點以外,有沒有更方便的作法?






批次操作

進入 PVE WebUI 後,點選 [Node 節點] > [Bulk Actions 批次操作] > [Bulk Migrate 批次遷移]。

進入節點的批次遷移


點選以後,即可進入批次遷移的操作畫面,這個畫面很容易上手。


批次遷移操作畫面


畫面的項目說明於下。
  • Target node 目標節點:預計要遷移到的目的地節點。
     
  • Parallel jobs 平行作業:同時可以遷移幾台虛擬機,越多可同時並行效率越快,但是對網路的頻寬吃重也越大,需要衡量。
     
  • 最後,在下方表格清單勾選要遷移出去的虛擬機,即可開始進行動作。






狀態查看

開始遷移時,畫面會顯示第一批遷移的主機名稱,剛剛我們選擇平行作業為 2,所以這裡只會先顯示兩筆。

正在批次遷移兩台主機


當我們退出這畫面以後,批次遷移作業依然會繼續進行,下方的 Task 作業視窗會顯示正在進行的作業。

在下方的第三筆,就是批次遷移作業的項目,第一、二筆則是本次平行作業正在遷移的兩台主機。

批次遷移進行中作業


這些作業項目點兩下進去還可以看到詳細的資訊,例如用來遷移的 IP、使用到的設定檔名稱、已傳輸的資料量...等,若進行中的作業想要取消,可以點選 Stop 停止按鈕。

遷移作業細節與停止按鈕





結論

在 Proxmox VE 中,除了提供批次遷移,也有批次啟動、批次關機的功能,管理者可以依據情境使用,節省時間。



2019年1月30日 星期三

[經驗分享]檢測 Proxmox VE 叢集連線健康狀態



當虛擬化節點越來越多時,使用 Cluster 叢集進行管理是必要的工具。

在建置 Proxmox VE 的叢集時,網路的高穩定性、低延遲性將是確保叢集運作機制的重要關鍵,那麼我們可以用什麼方式來檢測呢?






叢集連線

第一件事要知道,PVE 的叢集連線需要使用到那些網路連接埠:



叢集運作所需連接埠號


總共需要使用三個埠號,若有經過防火牆阻擋,請予以放行。

  • UDP / 5404, 5405
  • TCP / 22


特別注意,UDP 所使用的這兩個埠號,需要使用 Multicast 廣播發送,如果 Switch 關閉了這個功能將影響叢集運作,直接斷線。

若無權限調整或無法修改廣播設定,請參考近期將發佈的另一篇文章







連線測試

確認應該使用的連接埠都有正常開啟以後,我們可以利用一支工具程式來測試,好消息是 PVE 已經直接內建,不需要再另外安裝。



omping 工具程式


這是一支開源的工具軟體,使用方式如下:
omping 指令用法
omping -c 10000 -i 0.001 -F -q ip1 ip2 ip3 ....

特別注意:
如果要檢測的叢集有三個節點,那麼在這三個節點上都要執行同樣的指令,更多的節點請依此類推。

執行以後,畫面會開始出現測試數據,我們可以參考最後的結果來判斷狀況。



omping 執行結果


從執行結果的數據,我們簡單看幾個點就能知道目前叢集溝通的情況與網路是否符合規範,重點已在上圖中紅色框線所示。

依據 PVE 官方手冊建議,第一個紅框處 Loss% 的數值,應小於 1%;第二個紅框處 Avg 的數值,應小於 2ms (更好的是連 Max 都不要超過)。上圖的數值符合規範,狀況良好。






結論

在官方手冊裡面,有提到應該把對外服務、叢集溝通與儲存設備這三者完全獨立網路,以降低各種干擾情況對運作造成影響。



官方手冊建議應將三者區隔


在實務上因為種種因素,也許是設備現況、管理程度或者是經費...等等所限,不見得可以完全做到這樣的設計,所以我個人的作法是把叢集溝通與儲存設備這兩件事切開,也就是對外服務與叢集一邊,儲存設備一邊。

不管是分成三區或是兩區,叢集的溝通一定要經過 omping 的驗證無虞再上線,以免實際運作後產生更多的問題。



參考資料



2019年1月29日 星期二

[經驗分享]Proxmox VE 管理介面快速建立 zfspool



Proxmox VE 在 5.2 某個版本起,提供了在 WebUI 上可以點選硬碟後,再選取 zpool 模式即可簡單快速建立的流程,比起以往都要完全下命令列指令,方便許多,也更能防呆。

本文介紹最快速的 WebUI zfspool 建立方式。




建立儲存

將新購硬碟插上伺服器後,先確認是否被系統所成功識別:

確認成功識別新硬碟


確認硬碟進來以後,即可以開始進行建立程序。

點選 [Node 節點] > [Disks 磁碟] > [ZFS] > [建立: ZFS]

準備建立 ZFS 程序


接下來進入 ZFS 建立畫面,填寫 Name 名稱、勾選 Add Storage 加入至儲存,RAID Level 等級依情況選擇 Single Disk 單一磁碟、Mirror 鏡像、RAID10、RAIDZ、RAIDZ2、RAIDZ3 等,最下面再勾選這次建立 zfspool 要用到那幾顆磁碟。

以本次為例,要將兩顆磁碟做成 Mirror 鏡像的 zfspool。

建立 zfspool 設定畫面


建立完成後,列表上就會出現剛剛這個 zfspool 的名稱,點兩下可以查看細節。

查看 zfspool 細節畫面


在左邊樹狀節點上,也會加入這個 Storage 儲存,點選它可以看到內容類型、可用容量等資訊。

查看 Storage 儲存資訊


這個 Storage 已經可以開始使用,例如建立 VM 所使用的 Disk 存放之用。







問題處理


已有分割區無法建立


正常情況下新購硬碟是沒有分割資訊的,但如果真的有呢?或是拿已經分割過的硬碟想分配使用,卻遇到錯誤:

沒有硬碟可以選取


哎呀,竟然連硬碟都沒得選,那該怎麼辦呢?

PVE 的 WebUI 剛剛做出建立 ZFS 的功能,其它部份例如刪除、修改等的部份還沒有像 FreeNAS 那樣的方便與完整,所以我們需要自己下指令清除這些硬碟上的既有資訊。

以這次來說要清除的是 sdc 與 sdd,指令如下:
清除硬碟上的既有資訊
dd if=/dev/zero of=/dev/sdc bs=512 count=1
dd if=/dev/zero of=/dev/sdd bs=512 count=1

執行完畢以後,即已清除相關資訊。

清除磁碟原有分割等資訊


確認清除完成以後,即可回到 WebUI 重新做 ZFS 建立程序。




改用磁碟 ID 建立 zfspool


若對於使用 sdx 格式的名稱建立 zfspool 有特殊愛好者,可以改用 by-id 的方式建立,好處是容易一眼看出型號與序號,便於管理。

首先到 WebUI 查看型號與序號資訊:

查看磁碟型號與序號


接著,請到命令列以指令方式建立。
建立與查詢 zfspool 指令
zpool create ssdpool1 mirror /dev/disk/by-id/ata-MZXXXXXXXXX_XXXXXXXX /dev/disk/by-id/ata-MZXXXXXXXXX_XXXXXXXX 
zpool status ssdpool1

執行 zpool create 後,沒有消息就是好消息,接著再用 zpool status 可以查看是否正確的以磁碟 id 建立,而不是 sdx 這類的名稱。

以 disk id 建立 zfspool 成功



以指令建立完成的 zfspool,在 PVE WebUI 上也可以正常看見,不過以這種方式建立 zfspool,需要自己增加掛載。

掛載有兩種方式 (2019/01/31 修改,加入 Block Level 與 File Level 兩種設定方式)

  • ZFS (Block Level)
    [Datacenter 資料中心] > [Storage 儲存] -> [增加] -> [ZFS],在 zfspool 欄位選取剛剛建立出來的 zfspool,以本例來說就是「ssdpool1」。不過要特別注意,做這個選取動作時,WebUI 必須直接登入到這個節點,才能在選取畫面中出現這台可以選擇的 zfspool。
     
  • Directory (File Level)
    [Datacenter 資料中心] > [Storage 儲存] -> [增加] -> [Directory],把路徑指向剛剛建立出來的 zfspool 掛載點,若 zfspool 名稱為「ssdpool1」,路徑就是「/ssdpool1」。








結論

隨著 Proxmox VE 逐步改版,已經將許多原本只有指令才能操作的功能放到 WebUI 上來,可以預期的是未來 WebUI 功能將會日益完整,讓管理者更加快速方便,也減少因為使用指令操作而發生輸入不慎造成的遺憾事件。





參考資料


2019年1月28日 星期一

[經驗分享]讓 Proxmox VE 將 USB 碟做為備份區使用



一般情況下,我們都會經由網路把 VM 備份到其它 NAS 上做保存。

但...如果買不起 NAS,或是想要臨時拿個外接 USB 碟當做備份目的地,該怎麼做呢?





驅動磁碟

請先將 USB 硬碟或隨身碟插上 PVE 實體機的 USB 插槽,接著登入 PVE WebUI 的磁碟頁籤中查看是否有正確抓到這個磁碟。

查看 PVE WebUI 磁碟資訊


正確抓到磁碟以後,記下這個磁碟的名稱 /dev/sdg (請依據您實際的磁碟代號做更換) 準備下一步使用。





掛載磁碟

本次掛載的是一顆原本搭配 Windows 使用的 USB 隨身碟,上面的磁碟分割是 NTFS 檔案系統,需要手動執行掛載指令,將他掛載進來。

在掛載之前需要先安裝 ntfs-3g 套件,不然 PVE 預載是認不得它的。
安裝 NTFS 檔案系統套件
apt install ntfs-3g
掛載 NTFS 檔案系統
mkdir /mnt/usb/backup
mount /dev/sdg1 /mnt/usb-backup

執行掛載指令以後,最後可以搭配 mount | grep usb-backup 指令查看結果

掛載 NTFS 磁區


接下來就可以讓 PVE 把這個路徑吃進來使用,並設為備份區。

點選 [Datacenter 資料中心] -> [Storage 儲存] -> [Add 增加] -> [Directory]

加入 Directory


輸入名稱 usb-backup、我們剛才掛載進來的路徑 /mnt/usb-backup,內容要選取 VZDump Backup 備份檔案,最大備份數可以設大一點,例如 20


完成 Directory 加入程序


完成以後,左邊的樹狀清單就會多出一個 usb-backup 的儲存圖示,點選進去可以顯示相關的資訊,例如可放的內容類型、使用量等等。







使用磁碟

掛載完成以後,就可以用這個 Storage 儲存來做為備份目的地。

將虛擬機備份到 USB 碟


記得在備份時,要在右方的下拉選單選取掛載進來的 usb-backup,這樣才會備份到正確的目的地。





結論

由於 PVE 底層採用了 Debian,所以我們有很多彈性可以做出各種不同的應用。

安裝 ntfs-3g 套件後支援 NTFS 檔案系統,讓我們可以簡單的備份到既有的 USB 隨身碟或隨身硬碟而不用重新格式化,這樣的好處是隨手拿一個 USB 碟都可以臨時備份,也可以快速的把備份檔拿到其它電腦上使用。

進一步可以利用 PVE 提供的排程備份功能,定期將虛擬機備份到 USB 碟上,以保存更多的歷史版本。



參考資料





2019年1月27日 星期日

[經驗分享]查看 Proxmox VE 相關服務的事件記錄



Proxmox VE 運作非常穩定,但即便如此,再怎麼樣穩定的系統仍然有機會遇到問題。

舉個例子,我有使用 LibreNMS 對 Proxmox VE 的各個系統服務做定期監測,但每天早上六點多都會有 spiceproxy 這個服務異常警報,我想要查看 spiceproxy 這個 PVE 相關服務的記錄,該怎麼做呢?




方法一

在 Linux 系統中,大部份的服務都會由 syslog 服務統一處理,路徑在 /var/log/ 裡。

系統事件記錄存放位置


以 spiceproxy 來說,記錄在 /var/log/syslog 裡面,可以使用 cat 指令列出,再搭配 grep 指令做篩選。

查看 spice 相關記錄
cat /var/log/syslog | grep spice

註:如要查詢其它服務,將 grep 後的字串代換即可,例如 pvedaemon。

執行指令以後,可以得出以下內容:

列出 spice 相關記錄內容


列是列出來了,可是怎麼只有今天的呢?

因為在於系統啟動了「Logrotate」的機制,以每天為一期將記錄檔切割出去,切割出去的會於下一次 Logrotate 時進行壓縮。

經過 logrorate 處理的 syslog 檔案


所以若要看前一期的內容,請查看 syslog.1 這個檔案。

列出 syslog.1 spice 相關記錄內容


知道怎看是一回事,但用起來有些困擾,如果要看更早的還需要先解開 .gz 檔案,有沒有更簡單的方法?



方法二

其實,在 WebUI 就有簡單方便的功能了,請點選 [Node 節點] -> [System 系統] -> [spiceproxy] -> [Syslog]。


WebUI 查看 spiceproxy Syslog 記錄


點選以後,就可以看到這個記錄清單,還可以手動調整起迄日期方便查詢。

WebUI 篩選 spiceproxy 記錄結果


提醒,這裡可以查詢的日期範圍,一樣會受限於 Logrorate 的最大天數。


方法三

在系統越來越多的情況下,統一搜集做分析查看,甚至提供告警功能,對系統管理員的負擔可以大大減輕,而且可以更長期的保存,做為日後調閱的依據。

我的作法是採用 LibreNMS 做為中央收集器,並在收到內容後,依據制定的 Rule 規則進行警報發送。

PVE 系統內所使用的 Rsyslog 套件,可以修改設定,把事件直接丟到遠端的 Syslog Server 做處理。

請開啟 /etc/rsyslog.conf 檔案,並加入一行設定,指向 LibreNMS 位置,以 192.168.1.68 為例:

加入 syslog 記錄轉送
*.*  @@192.168.1.68:514

存檔後,請重新啟用 syslog 服務生效,接下來可以登入 LibreNMS 的介面進行查看。

LibreNMS 查看 PVE Syslog


LibreNMS 可以搜集主機的各種效能資訊,若再利用 LibreNMS 做為 Syslog 伺服器,可以更全面的掌握主機的事件狀況,相當方便。

LibreNMS 搭配 Syslog 發送 Telegram 告警


上圖就是一個應用案例,若 LibreNMS 的 Syslog 收取到有登入驗證失敗的事件,LibreNMS 上的 Alert Rule 警報規則就會自動以 Telegram 推播發送給相關人員,管理者即能立刻掌握狀況。





結論

講完了三種方法,回頭看看為什麼先前提到 spiceproxy 會異常呢?

每天早上都會收到 LibreNMS 的警報推播:

spiceproxy 服務異常警告


一開始以為是個案,後來發現每一個 PVE 節點在每一天都有一樣的狀況,那可要好好查查。

經過了解,原來是 Logroate 時,會把 pveproxy、spiceproxy 這兩個服務重新啟動,推測是因為這兩個服務沒有支援 hup 功能,所以需要將服務重啟才避免咬住 log 檔。

Logrorate 時重啟兩個 PVE 服務





參考資料





2019年1月26日 星期六

[經驗分享]Proxmox VE 複製虛擬機的幾種方法



在 Proxmox VE 裡建置好虛擬機後,想要再複製一台新虛擬機還有那些方法?




方法一

最簡單的方法,是使用 WebUI 上的 Clone 複製。

複製虛擬機


點選 Clone 複製後,會帶出下一個畫面,可以進行調整。

複製到新虛擬機的選項


系統會自動編號 VMID,你需要做的是選取要放新虛擬機的節點、名稱自填、目標儲存選擇後,即可開始。







方法二

若該虛擬機曾經有做過備份,那麼從備份檔還原為新機有時是比較快的作法。

請在 WebUI 上進入 Storage 儲存的 Content 內容頁籤(而非虛擬機的 Backup 備份頁籤),選取要用來複製新虛擬機的來源虛擬機備份檔。

至儲存區用備份檔還原



按下 Restore 還原按鈕,會進入下一個設定頁面。


還原至新虛擬機的選項


選擇還原後要放置的儲存區,並輸入 VMID,若 VMID 與原本的相同,就會還原至原本的虛擬機。若輸入其它 VMID,就會還原成一台新的虛擬機。

在我的使用經驗,用還原成新機的方法,會比方法一的複製快上許多。

特別注意:
採用此方法做出來的虛擬機,名稱、網卡 MAC 位址、UUID 都會一樣,記得要回去 WebUI 的 VM 設定中修改,以免衝突






方法三


如果喜歡 CLI 指令,也可以試試手工作法。

例如我們要把 VMID 109 這一台虛擬機直接複製出一台 111,其實很容易。

複製虛擬機組態檔
cp /etc/pve/qemu-server/109.conf /etc/pve/qemu-server/111.conf

組態檔完成以後,還要將虛擬磁碟也進行複製。

依據所設定的儲存區不同,以及存取形式的不同 (File Level 或 Block Level),指令會有所區別。

指令中複製的儲存區路徑,請依實際的環境做修改,不一定會是 /vmiamge。

複製虛擬機虛擬磁碟檔 (qcow2)
mkdir /vmimage/images/111
cp /vmimage/images/109/vm-109-disk-0.qcow2 /vmimage/images/111/vm-111-disk-0.qcow2

複製虛擬機虛擬磁碟檔 (zfs)
zfs snapshot vmimage/vm-109-disk-0@copy
zfs send -Rv vmimage/vm-109-disk-0@copy | zfs receive -F vmimage/vm-111-disk-0
zfs destroy vmimage/vm-109-disk-0@copy ; zfs destroy vmimage/vm-111-disk-0@copy

虛擬磁碟也複製完成以後,還需要進入組態檔修改磁碟對應。

修改虛擬機組態檔磁碟對應 (qcow2)


修改虛擬機組態檔磁碟對應 (zfs)


修改圖中紅框處,把 109 修改為 111 後存檔,即可完成新複製的虛擬機。


特別注意:
採用此方法做出來的虛擬機,名稱、網卡 MAC 位址、UUID 都會一樣,記得要回去 WebUI 的 VM 設定中修改,以免衝突。





結論

方法一最簡單也最安全的作法。

方法三是最快速也最有彈性的作法,唯一要注意的是下達指令時千萬不要弄錯,以免造成資料遺失。

其實在 PVE 當中,還有一種稱之為「Template 樣板」的作法,但這個作法我並不是這麼推薦它,所以本次的作法中不列入介紹。





參考資料



[經驗分享]GitLab Repository 404 無法開啟問題處理



GitLab 是 Git 程式版本控管系統的優質方案,功能強大、介面美觀。

但是自己建置與維護,難免會遇到一些疑難雜症,例如 Project Repository 損毀。




問題狀況

這個問題其實有陣子了,開發人員在 git 提交上 GitLab Server 時,有時候傳到一半這台 GitLab Server 會死當,要強制關機 (Stop) 或重開 (Restart) 才能恢復。

開起來後看似完好,但登入 GitLab 點進去當機時正在提交的 Project Repository,該 Project 就顯示損毀,無法開啟。


Project Repository 無法進入



這可麻煩了,請同事以指令嘗試,也出現這樣的錯誤:

測試 git 指令
git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks fetch --prune origin

error: object file ./objects/e6/ec31eecfdfa61e0a4939f0c360f961204e75ff is empty

error: object file ./objects/e6/ec31eecfdfa61e0a4939f0c360f961204e75ff is empty



Completed successfully.





進行排除

從訊息看起來可能是檔案寫入失敗所以成為空檔,從稍早前的整機備份檔去挖這個路徑...沒這個檔案,排除此可能性。

會造成影響的檔案主要在這個路徑底下:
/var/opt/gitlab/git-data/repositories/<namespace>/<reponame>.git/objects

網路上發現也有許多人遇到類似的狀況,其中一篇是我認為可行的方案,作法如下。

切換至損毀 repository 資料夾
# cd gitlab/repositories/<namespace>/<reponame>.git

執行 git 修復指令
# git fsck

刪除無效空白檔案
# find . –size 0 –delete

執行一次 git 修復指令
# git fsck

到這以後,可以先試試 Web 介面是否可以登入 GitLab 去開啟這個 Project Repository,或是以 git 指令 push 或 fetch 看看。

在我的情況是仍然未修復,以指令操作後出現這樣的錯誤:

測試 git 指令結果
git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks fetch origin develop:develop

error: refs/heads/develop does not point to a valid object!

fatal: Couldn't find remote ref develop

fatal: The remote end hung up unexpectedly

Completed with errors, see above.


好了,看起來指的是 develop 這個分支有問題,繼續做下一步。

移除 develop 分支對照檔
# mv ./refs/heads/develop ~/

再執行一次 git 修復指令
# git fsck



接下來可以再到 Web 上登入 GitLab,進入這個 Project Repository。


修復完成正常開啟


確認可以正常開啟了,不過因最新的 develop 分支有問題而刪除,所以需要從開發機再次 commit 一次上來即可。





結論

GitLab 很棒,不過常常比較大量提交寫檔時會死掉這件事挺困擾的,當服務重新啟動時的自我檢測與恢復機制又做的不夠完善,導致管理者要較多手工來修復,相信未來的 GitLab 能夠加強這部份的機制。

至於 GitLab 伺服器這端,會先做存取效能改善,擴充儲存設備的高速讀寫能力來減少這樣的情況發生。




參考資料





2019年1月25日 星期五

[經驗分享]讓 Proxmox VE 儀表板儲存指示計正確顯示


在 Proxmox VE 的 Datacenter 資料中心,有個 Summary 概觀頁籤,可以顯示整個叢集的健康狀況與相關資訊,但你有認真的看過指示計的部份嗎?可曾注意過資訊有沒有問題呢?




使用問題

在這個 Datacenter 資料中心的 Summary 概觀的顯示上,有許多統計資料,尤其是中間三個指示計樣式的更是顯眼。

資料中心概觀頁儀表板


它會顯示整個叢集中所有節點的 CPU 數總計,Memory 記憶體同樣的也是節點的總合,但是 Storage 儲存就不是我們所想的一回事。

我所使用的是以 Share Storage 模式為主,每個節點都去掛載了三台 FreeNAS 所提供的 NFS Service 連線,其中兩台以 VM 運作的 Disk 為主,一台專門用來放 ISO 檔與備份檔。

取其中一個節點的三個掛載 Storage 畫面來看:

第一個 Share Storage 容量


第二個 Share Storage 容量


第三個 Share Storage 容量


從以上兩張圖來看,總容量應是 5.27TB + 19.59TB + 4.61TB = 29.47TB

奇怪,怎麼跟前面在 Datacenter 資料中心頁看到的總數 31.63TB 不一樣呢?





問題原因

其實這也不是什麼 Bug,單純只是計算的依據不同而產生不同的結果。


Local 儲存容量


雖然我掛載了外部 Storage 進來用,但 PVE Node 節點本機還是有儲存空間,所以前面看到的數總數,除了各個 Storage 的加總,還要加上每一個 Node 節點的本機儲存,這個數字就對上了。

真相大白,知道問題了。

但是圖表怎麼辦?這個指示計上的總數可能會令管理者做出錯誤的判斷。






解決問題

好的,只提問題不給解法一向不是我的風格,解決方法其實也非常簡單,只要你會點選滑鼠左鍵就能搞定。

請進入在 WebUI 管理介面上點選 My Settings 我的設定,畫面如下:


我的設定畫面


參考上圖中紅色框起之處,請在需要被統計的 Storage 儲存上打勾,確認完成後就會顯示正確容量 29.47TB

顯示正確總容量


特別注意,如果是同時被多個 Node 節點所掛載的 Storage 儲存,請只勾選其中一個節點就好,否則數量是直接加總上去,亦不正確。





結論

其實有些地方並不是 Bug,是因為還不夠了解 PVE 所引發的誤會。

只要深入了解相關機制,會知道是設計的方向不同所致,只要加以理解並善用才是真正重要的精神。





參考資料