2019年1月15日 星期二

[經驗分享]找尋虛擬機磁碟I/O效能問題所在



使用 Proxmox VE 以後，隨著虛擬機器越來越多，最常遇到的效能瓶頸就是磁碟 I/O 卡住，但是當系統已經很忙的時候要怎麼知道是問題在那裡呢？

尤其是使用了 ZFS 的情況下，要如何快速得知就是一個重要的關鍵，以下分享一些自己在查修時的經驗，提供參考。





一、查看 zfspool 效能指令

先查看 zfspool 的使用情況，若有多個 zfspool，可以釐清目前是那一個比較吃重。

查看 zfspool 效能
zpool iostat


執行以後如圖，依據不同的 zfspool 顯示目前的讀寫使用頻寬。
顯示 zfspool 效能數據 

這個數據太籠統了，繼續往下看。







二、查看 zfs 磁碟效能指令

zfspool 是由多個磁碟組成，可以經由加入參數來顯示更詳細的資訊。

查看 zfspool 與磁碟效能
zpool iostat -v


執行以後如圖，依據不同的 zfspool 以及 disk 顯示目前的讀寫使用頻寬。

顯示 zfspool 與 disk 效能數據 


好了，到這裡已經可以顯示個別磁碟的使用情況，可以判斷出到底吃重或是瓶頸卡在那裡。



如何自動重新整理顯示


此時您可能會想到個問題，上面的指令都是執行一次才顯示一次，對於觀察數字改變很不直覺，能不能讓他自動重新整理顯示？

可以的，您可搭配 watch 這個指令來提升便利性。預設是每2秒重新整理一次，若您想要變更重新整理的頻率，可以在 watch 後方加入數字參數，例如：
每秒自動重新整理查看 zfspool 與磁碟效能
watch -n 1 zpool iostat -v

每秒自動重新整理查看 zfspool 與 disk 效能






三、查看磁碟效能指令

除了 zfs 的相關指令以外，其實 Linux 也有內建相關的指令，可以查看磁碟效能的數據。

查看磁碟效能
iostat -xdm


執行以後如圖，顯示每一個 disk 顯示目前的讀寫使用頻寬。

顯示 disk 效能數據 

在這張表，我們關注的是 await 與 %util 這兩個欄位。到這裡，已經能夠以指令掌握磁碟的使用情況。







四、查看磁碟效能工具

指令用久了也許會想，有沒有更方便的工具可以查看呢？

有的，筆者曾介紹過的一款工具 glances 就相當不錯。

glances 查看磁碟效能


執行 glances 以後，左下方的有一個「DISK I/O」的區塊，這裡就羅列了各個磁碟即時的讀寫速度。







五、查看磁碟效能圖形介面

雖然有了 glances 可方便查看，但是好像缺少了圖表，比較難看出不同時間下的變化？

有的，筆者曾提過的一款工具 netdata 就相當不錯。

netdata 查看磁碟效能

有了 netdata，不僅可以有秒級的圖表可以觀察時間變化，而且只需要瀏覽器就可以很方便的查看不同主機資訊，是管理者的重要幫手。



等等，講了半天都在談 disk 效能，但我到底要怎麼知道是那一個 VM 或 Process 吃掉我的效能？

以下就來提供幾個作法。







六、查看佔用磁碟效能的程序

我們希望知道是那一個程序的讀寫量大，或是它已經在等待磁碟IO (IO Delay)，要用什麼指令呢？

查看佔用磁碟效能程序
pidstat -d

pidstat 查看佔用磁碟效能程序


確實能夠看出讀寫數據與 iodelay 欄位，可是資料太多，能不能有更簡單的查看方式？

有的，請往下看。







七、查看佔用磁碟效能的程序排行榜

上面的指令資訊太多，能不能搞個排行榜最快了？最好還可以自動更新顯示？

查看佔用磁碟效能排行榜
iotop

iotop 查看佔用磁碟效能排行榜


確實能夠看出吃掉磁碟效能的排行榜，知道是那一支 Process 在作怪。

問題又來了，我使用 Proxmox VE，我想知道現在是那一個 VM 吃掉我的磁碟效能，有什麼更快的方法？








八、查看佔用磁碟效能的虛擬機

想要知道是那一個 VM 吃掉，我們可以利用 zfs 的特性。

相信各位在上面的 iostat、glances、netdata 可能都有發現一件事：一般的磁碟都是像 sda、sdb、sdc 之類的，怎麼還會跑出 zd0、zd48、zd64 之類的裝置？這是什麼東東？

其實在 zfs 上，所有 VM 的 Disk 都會被對應成一個 /dev/zdN 的裝置，我們正好可以利用這個特性衍生一個方便查出 VM 佔用磁碟的小技巧。

當我們先用 iostat -x 指令查看，對其中的 zd112 可能有點疑慮：


這時，可以使用指令做反查。

查看 zdN 所對應的 VM 磁碟
udevadm info /dev/zd112

udevadm 查看 zdN 對應 VM 磁碟


其中的資訊明確顯示，這個 zd112 是來自於 vmimage 這個 pool 下，編號為 104 虛擬機的第一個磁碟。

找出 Proxmox VE 中對應的虛擬機與磁碟


經由這樣的方式，我們就可以很明確的判斷是那一台虛擬機的那一個磁碟正面臨著大量存取所帶來的磁碟效能不足。






同場加映：查看磁碟資訊

既然發現 zdN 裝置的玩法，順便也推薦一個用在 Proxmox VE 的 Host 機上極為方便的指令。

查看 zdN 的磁碟資訊
blkid | grep zd

查看 zdN 的磁碟資訊


從結果可以看到，在 Host 機即可對 zdN 裝置取出它的 type、uuid、label 等資訊，可以快速的判斷裡面的格式為 zfs/dos/ext2... 等，也可以立即從 label 名稱判斷這是那一台虛擬機的磁碟或是其用途。 





參考






張貼者： 於
標籤： , , , , , , , ,

2019年1月7日 星期一

[經驗分享]解決ESXi 6.5以上VMDK相容問題



在多種虛擬機格式之間，VMDK 可以說是最廣泛支援的格式，過去我經常做 V2V 例如 VirtualBox、ESXi、Proxmox VE 之間的轉換，即常用 VMDK 格式進行處理。

例如，協助客戶導入開源軟體應用系統時，可以先在我自己的 Proxmox VE 或 VirtualBox 裡將虛擬機建置完成，再將虛擬機轉出 VMDK 檔案帶去客戶端匯入，節省現場建置的時間。




問題來了

在過去的時代，我只要使用 Proxmox VE 所內建的 qemu-img 工具即可輕鬆轉換格式，若是在 Windows 裡也可以下載 for Windows 的版本使用。

常用的轉換指令如下：

VMDK 轉為 QCOW2
qemu-img convert -f vmdk disk.vmdk -O qcow2 disk.qcow2

QCOW2 轉為 VMDK
qemu-img convert -f qcow2 disk.qcow2 -O vmdk disk.vmdk

VMDK 轉為 RAW
qemu-img convert -f vmdk disk.vmdk -O raw disk.raw

RAW 轉為 VMDK
qemu-img convert -f raw disk.raw -O vmdk disk.vmdk

VDI 轉為 VMDK
qemu-img convert -f vdi disk.vdi -O vmdk disk.vmdk

VHD 轉為 VMDK
qemu-img convert -f vpc disk.vpc -O vmdk disk.vmdk


一直以來都這麼使用，轉換到 ESXi 上輕鬆寫意，但自從 6.5 橫空出世以後，事情就再也不單純了，更何況接下來的 6.7。

不管是經 qemu-img 轉換而來的 VMDK，或是 VirtualBox 製作出來的 VMDK，只要丟進 ESXi 6.5 以上都會發生錯誤，錯誤的類型有相當多，以下是其中一種情況。

匯入磁碟後開機失敗


這一種情況，通常進入 [設定]，將 [控制器設定] 由 [SCSI 控制器 0] 修改為 [IDE 控制器 0] 即可開機。

修改磁碟控制器設定


雖然可以開機，但使用 IDE 模式並不是最理想的選擇，因為在效能上差異不小，我想這是絕大多數 IT 人員所無法忍受的事。




解決方法一


遇到無法以 SCSI 開啟虛擬機電源時，最簡單的方法是用 vi 或 nano 編輯器打開 VMDK 檔，將其中的這個區段做修改：

ddb.adapterType = "ide"
修改為
ddb.adapterType = "lsilogic"


或是使用 qemu-img 轉換時，增加參數 adapter_type、subformat 與 compact6

增加轉換參數
qemu-img convert 
 -f qcow2 disk.qcow2 
 -O vmdk 
 -o adapter_type=lsilogic,subformat=streamOptimized,compact6 
 disk.vmdk





解決方法二


但我們還有遇到某些情況，修改後還是有 無法匯入 或是 無法開機 等各種情況，例如：

新增磁碟發生錯誤


無法開啟虛擬機電源




經過朋友的測試結果，他提出一個解決辦法：

使用 VMware Workstation Pro 14 以上的版本開啟 VMDK 後再轉存。

在轉換之前，順帶提一下「Virtual Hardware Version」版本的對應，參考下面這個對照表就可以得知該選用什麼版本，主要應該要讓 Virtual Hardware Version 的版本號在 13 以上。



Virtual Hardware Version 對照表


雖然這個方法他說可行，但我沒有購買 VMware Workstation Pro 14 版本，也不想使用試用版，所以繼續考慮其它方案。




解決方案三


在找尋相關工具的過程中，找到了一套功能完整的磁碟格式轉換工具軟體，而且提供免費版本。

StarWind V2V Converter


StarWind V2V Converter 支援的格式不少，舉凡 VHD/VHDX、VMDK、QCOW2 以及 IMG/RAW 都在列，而且標榜支援 Hyper-V、ESXi、KVM，以免費軟體的等級來說已經相當驚人。

從 9.0.0.75 版開始，已經能夠支援至 VMware 6.5 與 6.7 格式，經過測試確實沒問題，只是選項上需要注意選擇方式。

他有一個非常方便的功能，可以直接邊轉換邊丟到 ESXi 伺服器上，甚至可以勾選轉換完成後直接附掛到指定的虛擬機上，但在我的測試下容易會失敗。



直接轉換 VMDK 並傳輸至 ESXi 6.7 失敗 



改變作法後，再經多次測試出可以用的組合，請來源與目的都選用 Local File 項目，格式均為 VMDK。








在選擇 VMDK 格式的畫面，請選擇 ESXi Server Image。




當轉換完成後，即可將相關 VMDK 檔上傳至 ESXi 伺服器進行使用。

請注意，轉出的 disk.vmdk、disk-flat.vmdk 兩個檔案都要上傳，而且要放置到該虛擬機所屬的 datastore 目錄下。


下圖是來自 VirtualBox/VirtualPC，原格式為 VHD 的虛擬機，經過轉檔後置入 ESXi 6.7 上運作的測試案例。

順利啟動的 Windows XP 虛擬機



下圖是來自 Proxmox VE，原格式為 QCOW2 的虛擬機，經過轉檔後置入 ESXi 6.7 上運作的測試案例。

順利啟動的 Windows Server 2008 虛擬機





使用 QCOW2 說明


若要以 StarWind V2V Converter 將來自於 Proxmox VE 的 QCOW2 直轉為 VMDK 給 ESXi 使用，要有前置作業先以 qemu-img 將 QCOW2 轉換為 VMDK，否則會遇到這個情況：



QCOW2 轉換失敗


這個問題主因在於 Proxmxo VE 使用的 QCOW2 版本是 1.1，而 StarWind V2V Converter 支援的是 0.10 所致。

預先用工具轉為 VMDK 再給 StarWind V2V Converter 轉換，可以減少這個困擾。

或是用 qemu-img 把 QCOW2 給降版也是可行。

QCOW2 1.1 降轉為 0.10 版本
qemu-img amend -f qcow2 disk.qcow2 -O qcow2 -o compat=0.10 disk.qcow2


註：
既然都要轉檔了，就乾脆直接 qemu-img 轉 VMDK，完成後再讓 StarWind V2V Converter 轉成 ESXi 適用的 VMDK 就好啦！





最後一招


若遇到的情況是無論如何都無法把 VMDK 讓 ESXi 掛到虛擬機器上，還有最後一招可以使用，這招效率最差也最麻煩，但我在某次專案裡真的用上了。

來源端
  1. 在虛擬機裡用 DD 把磁碟 dump 成一個 RAW 檔
  2. 用 GZIP 進行壓縮，以免檔案過大
  3. 把這個 RAW.GZ 寫進一個 ISO 檔裡面
  4. 提供兩個 ISO 檔到目的機，一個是內含 RAW.GZ 的，另外一個是 Clonezilla

目的端
  1. 把兩個 ISO 檔都掛載到 ESXi 裡的虛擬機器上
  2. 用 Clonezilla 開機，並進到指令行模式
  3. 使用指令將第二個 ISO 檔裡的 RAW.GZ 寫進 VM 的磁碟
  4. 搞定

指令碼
匯出磁碟指令
dd if=/dev/sda1 | gzip > disk.raw.gz
寫入磁碟指令
gzip -dc disk.raw.gz | dd of=/dev/sda1



參考





張貼者： 於
標籤： , , , , , , , , , , , ,

2019年1月3日 星期四

[套件介紹]支援ProxmoxVE的VPS管理套件



Proxmox VE 內建有叢集管理與強大的網頁式管理介面，不過，若要當做 VPS (Virtual Private Server，虛擬專用伺服器) 的話，就略微缺少分配權限、流量計費...等相對應的功能。

幸好，Proxmox VE 是一款完全開源的產品，所以可以非常容易的進行管理功能開發，極大程度拓展了各種可能性，充滿想像。

較為可惜的是，本次介紹的都是商業套件，而非開源軟體。


套件介紹一


第一款來自於相當知名的 VPS 管理軟體，WHMCS。


Proxmox VPS For WHMCS


做為知名套件 WHMCS 的外掛，自然也具備了豐富的管理功能與高度整合性，舉凡虛擬機建立、開機、調整、... 等，幾乎所有在 PVE WebUI 上可以做的事，都能在 WHMCS 介面上一次做完。







在官網上的介紹提到，目前支援至 Proxmxo VE 5.2，並且除了 PVE 原本 WebUI 上可以做到的功能之外，也增加了許多獨特功能，例如計費模組、IP管理等。





套件介紹二


第二款還沒釋出...但我對它充滿期待，還是必須介紹一下。

GridCP


GridCP 是一款強調視覺化設計的 Proxmox VE 管理套件，不過比較可惜的是 GridCP 著重在 KVM 的支援，暫時沒有打算將 LXC 納入管理。



圖片取自 LowEndTalk





套件介紹三 [2019/01/07 補充]


第三款套件也是一款相當流行的 VPS 管理軟體。


HostBill


介面設計上具現代化風格，一般 VPS 所需要的管理都有具備，透過加裝 Proxmox Module 擴充以後，即可將 Proxmox VE 主機納入管理。

HostBill 的授權費用較先前提到的 WHMCS 便宜，也可以納入考慮範圍。


圖片取自 HostBill


相關資料

張貼者： 於
標籤： , , , , , , ,

2019年1月1日 星期二

[議程簡報]Proxmox VE 叢集、高可用性與其它進階技巧



在伺服器虛擬化的領域中，Proxmox VE 是一款極為成熟、穩定且功能強大的套件。

我曾在 2017 年時分享過應用經驗與功能介紹，本次在 Proxmox VE 中文使用者社團 的活動中，則以 5.3 版為基礎，分享了我對 Proxmox VE 叢集、高可用性的心得以及其它進階技巧。



叢集管理


許多已經在使用 Proxmox VE 的朋友，有不少仍然是以獨立節點方式運作，還不曾跨入叢集的應用，主要是對於叢集還是有些害怕。






然而，管理的節點越來越多時，不導入叢集才是真正的災難。



叢集故障




其實，只要能克服「叢集故障」後如何恢復或救援這個議題，就不再是問題。

Proxmox VE 集合了許多優秀的開源套件而成，這也就意味了採用標準、開放的格式，在沒有封閉之下，只要對套件的認知足夠，救援並不困難。

本次關於叢集的議題，主要分成幾個項目：

  • 叢集失效操作 (p.26)
  • 切回獨立節點 (p.32)
  • 叢集網路劃分 (p.39)
  • 驗證叢集網路 (p.41)
  • 無法廣播修改 (p.46)



高可用性




叢集建立完成以後，接著可以進入高可用性的領域，提高服務自動回復的能力。

在高可用性這個議題，主要講述的重點：

  • Failover (p.52)
  • Watchdog (p.60)
  • Fencing (p.68)




進階工具




最後，介紹推薦幾款進階工具，都具有極高的實用性價值，可以用來補足目前 Proxmox VE 尚缺少的部份。

  • 巢狀虛擬化 (p.74)
  • 跨叢集遷移 (p.78)
  • VM Watchdog (p.81)
  • 排程快照 (p.84)
  • 儲存同步 (p.88)
  • 服務監測 (p.93)
  • 跨叢集管理 (p.99)



剩下的細節，請直接前往簡報平台閱讀，若您對 Proxmox VE 沒有使用經驗或一定基礎，則建議先閱讀相關資料的第二個連結，再前往觀看完整簡報。



相關資料




  
張貼者： 於
標籤： , , , , , , , , ,

2018年12月26日 星期三

[經驗分享]讓 Proxmox VE 中 VM 放本機磁碟者做線上遷移



Proxmox VE 支援線上遷移 (Online Migration) 與離線遷移 (Offline Migration)。

不過，若把 VM Disk 放在節點 (Node) 的本機磁碟 (Local Disk) 則無法做線上遷移。



先決條件

要讓放在本機磁碟的 VM 可以線上遷移，有幾件事需要注意：

  1. 來源節點與目的節點的儲存 (Storage) 名稱需要有相同的名稱存在。
     
  2. 來源節點與目的節點需在同一個叢集 (Cluster) 內。
     
  3. 建議先在來源節點的 VM 裡設定過複寫 (Replication) 並至少執行過一次，若沒有的話時間將較久。

    [2018/12/26 更正：不能有複寫過 Disk 存在目的端，會影響遷移]
     
  4. 來源節點與目的節點的儲存 (Storage) 檔案格式最好使用 ZFS。




執行指令


本機磁碟的 VM 要線上遷移只能透過指令來做，請先登入來源節點的 Console，並做如下指令：
qm migrate <vmid> <targetnode>  --with-local-disks --online


即可開始進行線上遷移。

輸入支援本地磁碟的線上遷移指令


支援本地磁碟的線上遷移完成





參考



張貼者： 於
標籤： , , , , ,

2018年11月28日 星期三

[經驗分享]LibreNMS無法取得某些FreeNAS儲存區資訊



我在機房中有一台 FreeNAS 9.10 版，但這台機器一直無法讓 LibreNMS 讀取到正確的儲存區資訊，困擾已久。



狀況

LibreNMS 可以經由 SNMP 協定取得儲存伺服器的儲存區容量，對於管理者來說可以統一管理並制訂警報發送條件，但這台一直無法抓到，困擾很久。

從一開始就懷疑是這台 FreeNAS 版本的問題，因為其它台 FreeNAS 的版本都是 9.10.2 以上，沒有這個情況存在。




完全空白的儲存區資訊




追查


直到最近，我將這台 FreeNAS 原地更新到 9.10.2-U6，沒想到情況仍然存在。

這樣看來變數就多了，我試著在 LibreNMS 用 SNMP v3 去對這台 FreeNAS 連接，一樣沒有改善。

不經意在 LibreNMS Github 的 Issue 裡瞄了一篇，提到同樣的問題：

FreeNAS 9.10 - Storage disks/mounts not discovered

沒錯，真的是 9.10 才有的問題，但我從 9.10 升級到 9.10.2-U6 還是發生，但如果是全新安裝則不會。

再往下看，這名網友分享了這個資訊：

It's definitely some bug in FreeNAS or FreeBSD. Discovery works OK when using SNMP v1. Older FreeNAS server is polled using SNMPv2, and it is working OK.


我抱著嘗試心態試了一下，改用 SNMP v1 去問這台 FreeNAS，竟然真的都出現啦！



終於正常的儲存區資訊



設定位置在 Device 裡的 SNMP 頁籤，簡單切換即可。



切換 Device 輪詢時使用的 SNMP 版本




參考

張貼者： 於
標籤： , , , , , ,

2018年11月26日 星期一

[經驗分享]基礎程式locale、ldconfig等消失事件



繼前陣子發生 MariaDB 會自己消失的離奇事件後，今天又發生另一起消失事件。



狀況

為了搞定 BookStack 套件的 PDF 中文匯出問題需要安裝 gblic 2.27 版本，但 Ubuntu 16.04 能提供到的版本是 2.23，後來搞了半天是真的把 2.23 給移除了，但結果是連許多基礎套件都幹掉了。




移除 libc-bin 時同時也移除好幾個套件




追查


本來只是為了移除 gblic 2.23，結果不僅 2.27 裝不上去，連其它基礎程式都掛了，例如 locale、apt 等很多東西都異常，類似以下的訊息

Can’t exec “locale”: No such file or directory at /usr/share/perl5/Debconf/Encoding.pm line 16. Use of uninitialized value $Debconf::Encoding::charmap in scalar chomp at /usr/share/perl5/Debconf/Encoding.pm line 17.

這下麻煩了。

翻查資料研究後，需要手動把 ldconfig 給弄回來。

apt-get download libc-bin
dpkg -x libc-bin*.deb unpackdir/
sudo cp unpackdir/sbin/ldconfig /sbin/

接著再重新安裝一次 gblic 套件。

sudo apt-get install --reinstall libc-bin 
sudo apt-get install -f

    好了，現在修復完成。

    等等，你可能會想到一件事：開頭提到的 BookStack 匯出 PDF 中文版問題需要 2.27，可是你裝回的是 2.23 還是沒解決啊？

    是的，經過爬文，需要 Ubuntu 18.04 才能使用 2.27，所以...... 我做了 do-release-upgrade 把 Ubuntu 16.04 更新到 18.04 了，結案！

    補充一下大版本更新經驗：

    • 10.04 to 12.04 = 死
    • 12.04 to 14.04 = 死
    • 14.04 to 16.04 = 系統活著，但死掉一堆套件 (那還是不能用啊)
    • 16.04 to 18.04 = 奇蹟的活下來了！



    參考




    張貼者： 於
    標籤： , , ,
    訂閱： 文章 (Atom)