OpenVZ虛擬應用範本：Koha / OpenVZ Virtual Application Template: Koha 3.16

我在Turnkey Linux的LAMP虛擬應用範本上安裝了圖書館自動化系統Koha 3.16，並打包成OpenVZ虛擬應用範本的格式分享給大家使用，讓大家更容易架設Koha。

I have packaged Koha 3.16 to an OpenVZ virtual application template which is based on Turnkey Linux LAMP. In this article, I share this template and show how to start it.

Koha: 圖書館自動化系統 / Koha: A Library System

• Koha官方網站
• Koha臺灣官網
• Koha臺灣代理商碩陽

Koha是一個開放原始碼的圖書館自動化系統，可供大家免費下載、架設與使用。Koha是使用Perl (CGI)，運作在Apache上，資料庫使用MySQL。這些組合都是開放原始碼授權。

Koha本身具備了兩大界面，一個是供讀者查詢館藏用的OPAC，另一個是供館員管理用的Intra內部網頁。兩者會架設在同一台伺服器上，用不同的連接埠來區隔開來。

雖然Koha可以免費取得，但是作為一個複雜的圖書館自動化系統，通常需要經過訓練才能順利使用Koha。因此有許多公司提供Koha服務來收費，例如Koha使用訓練。

下載Koha虛擬應用範本 / Download

這是一個OpenVZ的虛擬應用範本檔案 (或稱之為虛擬應用樣板，請看我之前的介紹)，檔案名字是「koha_3.16.04.000_20141014.tar.gz」，雖然看起來很像是tar.gz的壓縮檔案，但這檔案本身就是一個虛擬應用範本，不需要解壓縮即可使用。

• MEGA空間下載
• Box空間下載：Part. 1, Part. 2, Part. 3, Part. 4, Part. 5
  (請使用7-Zip或HaoZip合併檔案)

安裝Koha虛擬機器 / Install

關於安裝的方法，請參考我之前寫的Proxmox VE 3安裝與建立OpenVZ虛擬機器，或是從架設OpenVZ虛擬機器這一串教學開始看起。

架設完成之後大致上長這樣子。

登入界面 / Login

初始化安裝的時候，我預設的密碼都是password，Linux使用的帳號是root、Koha使用的帳號是koha_library。

OPAC界面 / OPAC Interface

一般讀者使用。

• 網址：http://your-koha-server-ip:8081/

Intra 內部管理界面 / Intra Administration

• 網址： http://your-koha-server-ip:8080/
• 登入帳號：koha_library
• 登入密碼：password

修改主要密碼 / Change Master Password

為了大家方便使用，除了Linux中root帳號使用的密碼會在建立OpenVZ時指定之外，Koha中預設的安裝密碼都是password。若要正式使用，請修改預設的密碼。

修改方法請參考How to change master password of Koha ?。做法如下：

1. 以root身份登入Koha伺服器的命令列
2. 進入MySQL管理界面，更改koha_library的密碼：
   mysql -u root -h localhost -p  
[請輸入預設MySQL的root帳號的密碼 password]
use mysql;
SET PASSWORD FOR 'koha_library'@'localhost' = PASSWORD('新密碼');
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('新密碼');
flush privileges;
quit;
3. 然後修改koha-conf.xml的密碼：
   nano /etc/koha/sites/library/koha-conf.xml
4. 密碼的位置在最下面，請找到「<pass>password</pass>」，然後吧password替換成你要的新密碼即可。nano編輯器的操作方式請參考鳥哥的教學。
    

開始使用Koha / How to Start Use Koha

我雖然把Koha架設起來了，可是老實說我也沒有仔細研究過怎麼使用。以下我整理一些Koha的使用教學，提供需要的使用者進一步閱讀。

• Koha臺灣官網文件：包含編目、查詢、流通、期刊管理、讀者管理、系統管理、OPAC等使用手冊。
• Koha圖書館管理系統上機操作教學

不過在開始之前，有幾件工作需要進行：

• 中文化：可以看一下Koha Translation Project的漢語(臺灣)，研究一下如何安裝
• 機讀格式：預設安裝時Koha提供了MARC21跟UNIMARC兩種格式，但沒有臺灣特製的CMARC。我安裝時使用的是MARC21。如果需要CMARC要另外想辦法。

有問題可以請教臺灣的Koha啟蒙大師：天主教輔仁大學圖書資訊學系的毛慶禎教授。

結語：更多的虛擬應用範本 / Conclusion: To Create More Virtual Application Template

之前有個想法，由於我覺得OpenVZ這種輕量級的虛擬化技術，運作Koha這種網頁管理系統真的是非常適合，因此讓我開始想要將許多系統打包成OpenVZ的形式來運作，所以就出現了這次的Koha虛擬應用範本。

其實這個是為了最近的圖書館領導人才菁英碩士學分班準備的內容。我想在大家面前展示一下，只要簡單的幾個操作就能夠架設一個Koha系統，這種感覺應該讓平常總是在跟幾十萬的圖書館自動化系統奮鬥的圖書館從業人員感到印象深刻吧。(雖然Koha原本的安裝方式也不能說很難就是了)

我的目的只是展示而已，所以做完後就沒有打算進一步深入研究了。有人需要就拿去用吧，有什麼感想或建議歡迎於下面留言發表。

(more...)

Proxmox VE增加第二顆硬碟 / Add Another Hard Disk in Proxmox VE

Proxmox VE預設安裝時只會使用一顆硬碟，不過我們也可以手動把其他顆硬碟加入到Proxmox VE中，加大可使用的空間。

This article show you how to add another hard disk as Proxmox VE's storage.

操作環境 / Proxmox VE Environment

本文章是以Proxmox VE 3.2為例子。

• Proxmox VE 官方網站
• Proxmox VE 下載
• Proxmox VE 3.2 64位元ISO光碟映像檔備份：實驗室備份檔案 / Box.net備份檔案：因為檔案很大，我用HaoZip分割成3份：01, 02, 03

不過這個Proxmox VE實際上是架設在VirtualBox之中，方便我練習。

我先安裝了一台Proxmox VE。關於安裝方法，請參考我之前寫的安裝教學。然後我再為這台Proxmox VE加上了一顆80GB的SATA硬碟，以擴充這台Proxmox VE的可用空間。

注意硬碟的類型，此例中用的是SATA，這會影響接下來要加入硬碟時所需要指定的裝置路徑。

準備好了話，我們就要來開始安裝第二顆硬碟囉。

安裝第二顆硬碟 / Install Anothor Hard Disk

STEP 1. 進入Shell / Enter Proxmox VE’s Shell

以下操作我們都得用指令列，以root的身份來進行。一般教學會用SSH或在本機端操作，還好Proxmox VE還提供了方便的功能，可以讓我們用Shell直接以root身份進入伺服器指令列端操作。

Shell是透過Java Applet來使用，因此通常它會先問一些安全性問題。這時候直接按下Continue即可。

進來指令列端了，開始進行接下來的操作吧。

STEP 2. 確認磁碟路徑 / Finding Hard Disc’s Device Path

這一步是Linux基本操作，操作指令細節可以查看鳥哥的Linux磁碟與檔案系統管理，以下我僅列出主要操作步驟。

首先，我們要先確定要新增加的硬碟的路徑。簡單地方法可以用ls指令來確認，這是SATA硬碟的確認方法：

root@proxmox:~# ls /dev/sd*

如果安裝的硬碟是IDE (PATA)類型，那路徑一般是以/dev/hd*開頭，查詢方式為：

root@proxmox:~# ls /dev/hd*

上圖是查詢結果。你可以注意到只有/dev/sdb後面沒有接數字。這表示這顆磁碟尚未被分割，也就是我們剛剛加入的新硬碟。

STEP 3. 磁碟分割 / Create Hard Disk Partition

接下來我們要用fdisk來把該硬碟分割成可以用的磁區。/dev/sdb請替換成你硬碟的路徑。

root@proxmox:~# fdisk /dev/sdb

然後會進入fdisk操作界面，以下我只列出需要輸入的操作，大多動作都是使用預設值，直接按下enter跳過即可：
Command (m for help): n
Select (default p): (直接按下enter)
Partition number (1-4, default 1): (直接按下enter)
First sector (2048-167772159, default 2048): (直接按下enter)
Last sector, +sectors or +size{K,M,G} (2048-167772159, default 167772159): (直接按下enter)
Command (m for help): w

上面訊息中sector會隨著你的硬碟大小而改變，直接採用預設值按下enter就可以不用理會囉。

分割完成之後的路徑就是 /dev/sdb1。

STEP 4. 硬碟格式化 / Format Partition

Proxmox VE使用的硬碟格式是ext3，在此我們也使用mkfs來把硬碟分割格式化為ext3格式。以下路徑請使用剛剛分割完磁碟之後的磁碟分割路徑：

root@proxmox:~# mkfs -t ext3 /dev/sdb1

格式化需要花點時間，中間沒有任何要操作的動作，請耐心等待回到指令列即可。

沒有什麼特別要確認的訊息，這樣就格式化完了。

STEP 5. 掛載磁碟 / Mount Hard Disk

Linux的硬碟要掛載之後才能使用，首先我們先建立掛載路徑的目錄。在此我直接用磁碟分割的編號 sdb1 來做為路徑名稱：

root@proxmox-01:~# mkdir -p /mnt/sdb1

然後把開機掛載訊息寫入/etc/fstab：

root@proxmox-01:~# echo /dev/sdb1 /mnt/sdb1 ext3 defaults 1 2 >> /etc/fstab

(此處有變更過，原本的做法會導致無法在開機時自動啟用虛擬機器，參考了鳥哥的fstab說明之後更正)

接著用reboot指令重開機：

root@proxmox-01:~# reboot

用df指令確認是否有掛載上去：

root@proxmox-01:~# df /mnt/sdb1

有看到/mnt/sdb1就表示成功了。

STEP 6. 建立Proxmox VE的Storage / Create Storage in Proxmox VE

接下來我們回到Proxmox VE的網頁管理界面操作。

 

先到「Datacenter」，進入「Storage」，然後「Add」增加「Directory」磁碟目錄。

填入以下資訊，磁碟編號跟路徑則是要參考上面設定的結果：

• ID: sdb1
• Directory: /mnt/sdb1
• Content: Images, ISO, Templates, Backups, Containers (全部選擇)
• Nodes: proxmox-01 (只選擇你安裝硬碟的Proxmox VE節點)

按下Add。

proxmox-01節點下就會多出一個新的Storage「sdb1」，未來在建立虛擬機器、備份、下載虛擬應用範本時，就可以使用這顆新加入的硬碟囉。

 

雖然這方法很簡單，但寫著寫著赫然發現步驟挺複雜的。難得有機會整理一下供大家參考也好啦。

(more...)

修復Proxmxo VE：虛擬機器無法進入終端畫面 / Fix Proxmox VE: How to Enter OpenVZ Container’s Console?

Proxmox VE改版之後，很多OpenVZ範本都無法進入終端畫面(Console)。其實可以開啟節點(Node)的終端畫面(Shell)，然後以「vzctl enter [VMID]」來進入OpenVZ虛擬機器中。

This article describes the problem of Proxmox VE Cluster: How to enter OpenVZ container’s console? A proposed solution to the problem is use vzctl enter [VMID] command, or modify template. Following are the problem description and solutions.

問題狀況 / Problem Description

Proxmox VE提供了方便的管理工具，可以讓管理者直接在Proxmox VE中點選「Console」(終端頁面)來顯示OpenVZ虛擬機器(又稱為container，CT)的終端畫面，如上圖。

可是由於早期的OpenVZ虛擬應用範本，特別是CentOS，在開啟Console的時候，只會顯示以下訊息：

Attached to CT 101 (ESC . to detech)

什麼都看不到，而且什麼都無法操作。

問題原因 / Causes of Problem

這是因為早期OpenVZ虛擬應用範本檔案中輸出Console的終端設定跟現在Proxmox VE版本的設定不合。導致OpenVZ虛擬機器雖然可以顯示開機與關機資訊，但真正讓人可以操作的訊息卻顯示不到console使用的Java Applet上。

應急的解決方案是從節點(node)直接進入虛擬機器的手動解決方案，長期的話就修改範本設定。我們現在已經使用了很多虛擬機器，也不是常常在進入伺服器。在此先介紹短期內直接進入的手動解決方案。

手動解決方案 / Manual Solution

參考Proxmox VE OpenVZ Console的Troubleshooting，做法如下：

1. 先進入Proxmox VE管理介面。找到無法進入Console端的虛擬機器，確認VMID編號為101。
   
2. 回到該機器的節點「puli-openvz」，進入右上角的Shell。
   
3. 接下來會顯示節點伺服器的終端畫面。
   
4. 輸入以下指令進入虛擬機器：
   # vzctl enter [VMID]
   以VMID 101的虛擬機器為例，指令如下：
   # vzctl enter 101
   
5. 接著就可以進入虛擬機器內了。
   

由於這個方法跟直接點選console按鈕比起來也不會耗費太多功夫，所以很推薦大家來使用。

自動解決方案 / Automatic Solution

當然，最好的方式是修改虛擬應用範本，以避免每次都還要繞路才能開啟Console的困擾。

CentOS 6的解決方法 / Solution for CentOS 6

根據Proxomx VE Modifying your templates的說明，我試著在centos-6-standard_6.3-1_i386.tar.gz上修改成功。

加入tty.conf / Add tty.conf

做法是在該虛擬機器範本中加入 /etc/init/tty.conf 檔案，檔案內容如下：

# This service maintains a getty on tty1 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]

respawn
exec /sbin/agetty -8 tty1 38400

然後以 reboot 指令重新啟動虛擬機器，這樣就可以用console登入了。

下載tty.conf / Download tty.conf

為了方便起見，我把這些動作寫成以下指令。只要在無法直接進入console端的虛擬機器直接執行即可：(感謝aleroot對wget覆寫指令的解說)

# mkdir –p /etc/init; cd /etc/init; wget -q http://goo.gl/nx13fz –-no-check-certificate; reboot

然後就等待重開機吧。

CentOS 5的解決的方法 / Solution for CentOS 5

CentOS 5的做法不一樣，請輸入以下指令：

# echo "1:2345:respawn:/sbin/agetty tty1 38400 linux" >> /etc/inittab; reboot

登入終端界面 / Login in Console

剛進去的時候是全黑的，請先按一次「enter」鍵。然後才會顯示文字訊息。

不過似乎第一次登入還是要輸入帳號密碼的樣子，這部分就難免了。

重設虛擬機器的root密碼 / Reset Root Password

由於使用vzctl enter [VMID]的方式可以進入任何OpenVZ虛擬機器裡面，而且是以root身份進入，因此可以用這個方式重設root的密碼。

做法概述如下：

1. 從節點(node)的Shell進入
2. # vzctl enter [VMID]
3. 以root身份登入虛擬機器
4. 變更密碼指令：
   # passwd root
然後輸入你要變更的密碼

完成。

正式的做法則是參考OpenVZ論壇中maratrus的講解，在節點的Shell中使用vzctl中的—userpasswd，指令如下：

# vzctl set [VMID] --userpasswd root:[newpasswd] --save

兩種方法都可以喔。

(more...)

Proxmox VE 3.2已經修復的備份鎖定問題 / Proxmox VE 3.2 Fixed Problem: Backup Lock

Proxmox VE在備份時會設定虛擬機器的備份鎖，位於/var/lib/vz/lock/[VMID].lck。在Proxmox VE 3.2版本中，備份異常中斷、或是有其他備份仍在進行中的時候，備份功能依然可以正常運作。

When Proxmox VE start a backup job, it will create a lock file at /var/lib/vz/lock/[VMID].lck. In Proxmox VE 3.2 version, when previous backup job got error or not finished, current current backup job will not crash.

舊版本的錯誤 / Problem of Older Version

備份時所產生的備份鎖，在舊版本的Proxmox VE中不會自動解除。例如這篇「backup failed - command 'qm set 101 --lock backup' failed with exit code 255」就遇到了這個問題，發問者doknet的錯誤訊息如下：

vm1:~# vzdump --dumpdir /var/lib/vz/dump/  --snapshot  101

INFO: starting new backup job: vzdump --dumpdir /var/lib/vz/dump/ --snapshot 101

INFO: Starting Backup of VM 101 (qemu)

INFO: stopped

INFO: status = stopped

INFO: setting parameters failed - VM is locked (backup)

ERROR: Backup of VM 101 failed - command 'qm set 101 --lock backup' failed with exit code 255

INFO: Backup job finished with errors

這時候由於備份時產生的備份鎖無法自動解除，所以必須要管理者手動刪除檔案。以VMID 101的虛擬機器為例：

rm -f /var/lib/vz/lock/101.lck

刪除該鎖之後，備份就可正常進行。

備份機制的運作方式 / The Survivability of Backup

在Proxmox VE 3.2版本中，備份時常發生的錯誤都不會影響備份任務的心情。常遇到的錯誤如下：

其他備份任務尚未完成 / Another Backup Job Is Still Not Completed

備份任務一次只能進行一個。較晚執行的備份任務會先等待其他任務完成，顯示訊息為：

INFO: trying to get global lock – waiting…

這時候備份任務會進行等待，然後當其他備份任務完成時，這個任務就會開始進行備份。

在這個情況下會連續製作備份檔案，請自行注意。

之前的備份任務異常中斷 / Previous Backup Job Is Crashed

如果之前的備份任務因為斷電、斷網等各種因素導致無法順利進行，那後來的備份任務也不會因此被鎖住，而可以直接開始備份。

備份空間不足的問題 / No Space Left When Backup

在各種試誤中，最後我只有找到了「No space left on device」的錯誤。如文字所示，這純粹是硬碟空間不足而已，也不是備份功能的問題。

如果大家在備份時有遇到被鎖住的錯誤情況，請再跟我分享。

(more...)

修復Proxmox VE：節點無法加入集叢 / Fix Proxmox VE: Pvecm Add Failed

本篇是修復Proxmox VE的集叢(Cluster)中遇到「authentication key already exists」的錯誤。這個錯誤是因為該節點(node)已經在集叢(cluster)中，所以無法再加入集叢。加入-force參數之後可以讓節點強制加入集叢。以下說明造成錯誤的原因以及解決方法。

This article describes the problem of Proxmox VE Cluster: “'authentication key already exists” when add a node to cluster. A proposed solution to the problem is append “-force” option to “pvecm add [NODE_ADDRESS]”. Following are the problem description and solutions.

問題狀況 / Problem Description

由於你的集叢一直發生錯誤，你想要重新建立起集叢，再把目前這個節點加入到新的集叢時，使用了pvecm add [節點網路IP]的指令，例如：

pvecm add 10.1.0.1

但是這時候卻出現了以下錯誤訊息，讓你加入節點失敗：

authentication key already exists

於是集叢依然無法運作，節點也無法加入到新的集叢中，錯誤無法解決。這一個問題我也在「Proxmox VE集叢重新加入節點」一篇中提及過，現在總算找到解決方法。

問題原因 / Causes of Problem

可能是以下幾種原因，你會想要把一臺Proxmox VE伺服器節點(node)加入到一個集叢中。

1. 你的集叢發生了no quorum錯誤。這是因為集叢未啟動，解法請參考這篇。
2. 你的集叢一直跳出登入視窗。這是因為節點伺服器時間不正確，解法請參考這篇。
3. 你這臺節點Node A原本隸屬於集叢Cluster A，現在要加入Node B的Cluster B中。

前面兩個原因都無法靠重新加入節點來解決，請參考我另外的解決方案來處理。這篇主要處理的是第三種情況，也已經就是要把節點換到另一個集叢的時候。

造成無法加入集叢的原因有兩個：

1. 節點自身已經隸屬於某一集叢
2. 新的集叢本身已經有該節點的資料：這是當你用我這篇的方法，刪除節點自身的集叢設定(decluster)，卻沒刪除新集叢對該節點設定時的問題。真要刪除節點可以用pvecm delnote [NODE NAME]，不過以下方法更簡單一點。

解決方案 / Solution

解決方法就是在pvecm add時加上「-force」參數。舉例來說就是：

$ pvecm add 10.1.0.1 -force

這樣Proxmox VE會強制複寫原本的設定，就不會出現「authentication key already exists」錯誤訊息。

然後再來要重新啟動cman跟pve-cluster服務，以確保載入新的集叢資訊：

$ service cman restart

$ service pve-cluster restart

我把這些步驟寫成了腳本pve-add_node_force.sh，下載、加入執行權限之後，就能夠用以下方法加入集叢：

$ ./pve-add_node_force.sh 10.1.0.1

就拿這個方案來取代原本的pvecm add指令吧。

(more...)

修復Proxmox VE：連續要求登入 / Fix Proxmox VE: Endless Login

本篇是修復Proxmox VE的集叢(Cluster)中遇到不斷跳出「Proxmox VE Login」登入視窗的錯誤。這個錯誤是因為節點的時間不一致，使用ntpdate網路校時之後可以解決。以下說明造成錯誤的原因以及解決方法。

This article describes the problem of Proxmox VE Cluster: when you do anything on other nodes, Proxmox VE Login form prompted again and again. A proposed solution to the problem is correcting the time of every node by using ntpdate. Following are the problem description and solutions.

問題狀況 / Problem Description

有時候在進行Proxmox VE集叢中任何操作時，明明之前已經登入過了，但是現在卻又跳出了「Proxmox VE Login」登入表單。即使你再一次登入，這個登入表單依然會跳出來。就算網頁重新整理，這個它依然會跳出這個表單。

如果用Google Chrome來檢查錯誤主控臺，你會發現大量的「401 (No ticket)」，例如：

Failed to load resource: the server responded with a status of 401 (No  ticket)

這大概是Proxmox VE使用者遇到最頭痛的問題了，一堆人都在網路上拼命地找尋這個問題的解決方法。但是這個問題本身不在於Proxmox VE集叢本身，而是在於伺服器上。

問題原因 / Causes of Problem

造成這個問題的原因是因為節點伺服器自己的時間不一致。

以下幾種情況可能會造成伺服器時間錯亂：

• 伺服器本身因為停電、長時間未通電使用等各種情況，導致伺服器本身記錄時間的電池沒電，時間被重置。
• 使用虛擬機器建置Proxmox VE節點，但是因為使用快照(Snapshot)與還原(restore)，讓機器本身的時間與現實時間不一致。
• 因為任何原因設定了Linux系統的時間，例如用date工具。

你可以執行date指令來查詢伺服器現在的時間：

root@proxmox-02:~# date

Thu Aug  7 20:47:01 CST 2014

如果這個時間附和現實時間，那沒有問題。但通常有問題的節點的時間都會與現實時間不同。

當兩個節點的時間不一致時，維持正確時間的節點去查看延遲錯誤時間的節點時，大概兩者只要相差5分鐘，就會導致這個錯誤發生。

手動解決方案 / Manual Solution

要解決伺服器時間錯誤，最簡單的方法是使用網路校時ntpdate。Proxmox VE預設沒有安裝ntpdate，我們要先更新apt-get，然後再用apt-get安裝。接著就能夠跟NTP伺服器pool.ntp.org進行網路校時。

安裝ntpdate的做法如下：

apt-get update

apt-get install -y ntpdate

進行網路校時的指令如下：

ntpdate -u pool.ntp.org

自動解決方案 / Automatic Solution

要自動解決這個問題的方法是固定每天都進行網路校時，確保伺服器的時間一直保持正確。

我將以上指令寫成了腳本pve-ntpdate.sh，請下載到/root/dlll-cias/pve/scripts/pve-ntpdate.sh：

wget http://goo.gl/vKyjnQ  -o /root/dlll-cias/pve/scripts/pve-ntpdate.sh

加入執行權限：

chmod +x /root/dlll-cias/pve/scripts/pve-ntpdate.sh

然後在crontab加入以下設定：

echo “0 2 * * * root /root/dlll-cias/pve/scripts/pve-ntpdate.sh”

這樣每天清晨2點的時候，伺服器會自動進行網路校時，以確保時間的正確性。

(more...)

修復Proxmox VE：無法刪除虛擬機器 / Fix Proxmox VE: Destroy Virtual Machine Failed

本篇是修復Proxmox VE的集叢(Cluster)中遇到「'vzctl destroy [VMID]’ failed: exit code 41」的錯誤。這個錯誤是因為虛擬機器未成功建立，刪除設定檔之後可以解決。以下說明造成錯誤的原因以及解決方法。

This article describes the problem of Proxmox VE Cluster: “'vzctl destroy [VMID]’ failed: exit code 41”. A proposed solution to the problem is deleting the configuration file of the VMID. Following are the problem description and solutions.

問題狀況 / Problem Description

有些虛擬機器呈現灰色未開機的狀態。這些機器無法啟動，也無法備份、遷移，甚至刪除。整臺機器彷彿被鎖定一樣無法操作。

以虛擬機器ID (VMID) 100為例，刪除動作會失敗，而且出現以下錯誤訊息：

stat(/var/lib/vz/root/100): No such file or directory

Container is currently mounted (umount first)

TASK ERROR: command ‘vzctl destory 100’ failed: exit code 41

問題原因 / Causes of Problem

造成這個問題的原因在於虛擬機器未完成建立(create)或從備份檔案重建(restore)，虛擬機器應該要有的檔案位置尚未建立好相對應的檔案，導致刪除等任何動作的失敗。

通常遇到的情況是：

• 由於虛擬應用範本或是備份檔案過大，導致建置虛擬時間過長。
• 建置過程途中被使用者按下「Stop」停止建置命令，或是因為斷電、斷網等任何異常，讓虛擬機器尚未建立完成。
• 因此該虛擬機器就不能運作了。

手動解決方法 / Manual Solution

要移除無法運作的虛擬機器，做法是刪除該虛擬機器的設定檔案。以VMID為100的虛擬機器為例，刪除指令為：

rm -f /etc/pve/nodes/*/*/100.conf

我做成腳本pve-destroy_vm.sh，請下載、加入執行權限，然後可以這樣做：

./pve-destroy_vm.sh 100

這樣就能夠強制刪除虛擬機器了。

有待找尋自動解決方法 / Need for Automatic Solution

上述的手動解決方案必須每次都要登入伺服器操作，不能同一在網頁操作上進行，比較不方便。

因此自動解決方法應該是去修改網頁端刪除的指令。如果取得了exit code 41，那就用上述的方法強制刪除。

只是Proxmox VE的網頁比較麻煩，他是用Perl寫成，而且前端使用了ext js這個鷹架，整體來說非常複雜。這部分仍有待研究。

(more...)

修復Proxmox VE：集叢未啟動 / Fix Proxmox VE: Cluster Not Ready

本篇是修復Proxmox VE的集叢(Cluster)中遇到「TASK ERROR: cluster not ready – no quorum?」的錯誤。這個錯誤是因為集叢未正常啟動，以下說明造成錯誤的原因以及解決方法。

This article describes the problem of Proxmox VE Cluster: “TASK ERROR: cluster not ready – no quorum?”. A proposed solution to the problem is executing “pvecm expected 1”. Following are the problem description and solutions.

問題狀況 / Problem Description

在Proxmox VE是在集叢的狀況下，在節點(Node)操作的時候進行虛擬機器的建立(create)、刪除(remove)、備份(backup)、遷移(migrate)時，有時候會出現以下錯誤訊息：

TASK ERROR: cluster not ready – no quorum?

在這個狀態底下，將不能對虛擬機器進行任何操作。而虛擬機器本身則可以繼續運作，不會中斷。

你也可以用pvecm status指令來查詢看看現在的狀態：

請Proxmox VE節點伺服器上執行以下指令

pvecm status

Proxmox VE會顯示集叢現在的狀態，例如：

Version: 6.2.0

Config Version: 3

Cluster Name: dlll-cias

Cluster Id: 52033

Cluster Member: Yes

Cluster Generation: 144

Membership state: Cluster-Member

Nodes: 1

Expected votes: 3

Total votes: 1

Node votes: 1

Quorum: 2 Activity blocked

Flag:

Ports Bound: 0

Node name: proxmox-02

Node ID: 2

Multicast addresses: 239.192.203.13

 

其中你可以注意到「Quorum: 2 Activity blocked」這段訊息，表示你的集叢是在鎖定的狀態。

問題原因 / Causes of Problem

發生這個問題是因為Proxmox VE的集叢沒有正常運作。quorum是集叢中重要的一個服務元件，如果集叢有任何設定錯誤，都會導致quorum無法正常啟動。因此遇到這個問題時，並不是去啟動quorum，而是要先解決造成集叢錯誤的原因。

造成集叢錯誤的原因中，最常見的就是節點之間網路的斷線，集叢中節點數量低於2時，集叢就會被鎖住。如果集叢中有pmox1、pmox2、pmox3三臺伺服器，然後把pmox3網路中斷。接著過不久之後，pmox3就會陷入「no quorum」的狀態。這是因為Proxmox VE Cluster預設期待集叢中必須要有2個節點(Node)以上，可是因為網路斷線的緣故，pmox3只能偵測得到一臺Node，這時候集叢就會把pmox3鎖住。因此才會出現「Quorum: 2 Activity blocked」這個狀態。

手動解決方法 / Manual Solution

解決方法是暫時把集叢的期待數量從2降低為1。做法如下：

pvecm expected 1

這個步驟會讓集叢改為只期待1個節點正常運作。

service pve-cluster restart

這個動作會重新載入集叢設定，而虛擬機器不受影響。

再使用pvecm status查詢時，會發現Quorum已經變成1，而Activity blocked狀態已經解除。接著就能夠進行虛擬機器的新增、刪除、備份、遷移。而當該節點與集叢正常運作時，節點設定不需要任何修改。

自動解決方法 / Automatic Solution

為了避免網路異常時集叢每次都會把自己鎖定，我們可以每天定時去檢查集叢的狀態。如果陷入「Activity blocked」的時候，就自動進行解除的動作。

1. 建立/root/pulipuli_scripts目錄：
   mkdir /root/pulipuli_scripts
2. 請把cluster_is_activity_blocked.sh跟cluster_disable_activity_blocked.sh兩個檔案下載到該目錄底下：
   wget http://goo.gl/6gyDnH -O /root/pulipuli_scripts/cluster_is_activity_blocked.sh
wget http://goo.gl/r37ySO -O /root/pulipuli_scripts/cluster_activity_unblocked.sh
3. 新增可執行權限：
   chmod +x /root/pulipuli_scripts/*.sh
4. 加入crontab排程：
   crontab -e
   新增以下設定：
   # 定期解除Proxmox VE Cluster鎖定狀態
0   3  *  *  * /root/pulipuli_scripts/cluster_activity_unblocked.sh

這樣子每天凌晨3點的時候，Proxmox VE都會檢查集叢，然後嘗試解除被鎖定的狀態。

(more...)

DLLL-CIAS介紹 / DLLL-CIAS Introduction

這篇發佈我在2014年6月底的「雲端科技與圖書館行動服務研習班」中課程「雲端平台基礎設施建置實務──DLLL-CIAS介紹」的課程投影片。

This article is the slide of my course “Cloud Technology and Library Mobile Service Workshop” in July, 2014. Finally is my thought of this workshop.

DLLL-CIAS是什麼？ / What is DLLL-CIAS

DLLL-CIAS是政大圖檔所數位圖書館與數位學習實驗室中我所開發的開放原始碼雲端平台方案。主要目的是希望能夠讓經費不多的中小型單位也能夠用現有伺服器資源架設好用的IaaS雲端平台。其他介紹請看「DLLL-CIAS雲端平台架設與使用專題目錄」。

課程投影片 / Course Slide

• OneDrive投影片下載
• Box.net投影片下載

Google Drive的原始版本投影片 / Slide Original Version on Google Drive

另外值得一提的是，這篇投影片是一開始是以Google Drive投影片製作。

• Google Drive投影片連結

雖然Google Drive投影片製作起來並不如Power Point一般的精緻（另一方面也是因為這個版本是供列印用的，所以特別以高對比黑白相間的範本製作），但是Google Drive投影片製作功能卻是相當足夠使用。更重要的是，Google Drive的協同製作跟註解(comment)完全贏過Windows的OneDrive。

這學期我大量使用Google Drive的協同編輯功能，像是跟人一起編修論文計劃書、規劃投影片內容，這份投影片也是從Google Drive開啟編輯起。我先規劃投影片大綱，記錄每一張投影片欲講述的內容，以及相關參考資料的來源。然後各張投影片的內容則是跟實驗室各位助理一起填寫資料，接著我再重整資料內容。當投影片內容確定之後，最後我再下載成Power Point檔案作進一步的排版美化。

最後排版而成的版面就是這樣子了。

Google Drive與Power Point轉換編輯注意事項 / Difference Between Google Drive and Power Point

使用Google Drive製作投影片跟Power Point製作投影片有幾個重點差異需要注意：

• Power Point匯入到Google Drive時樣式容易跑掉，但相反的從Google Drive匯入到Power Point問題卻不大。
• Google Drive不支援投影片頁碼、不支援陰影、不支援連接線的折線。這幾種功能都是投影片常用的重要特色，請自行斟酌。
• 請善加利用「投影片母片」(Power Point用詞)、「主投影片」(Google Drive用詞)，可以保持投影片格式一致。

有機會我再詳細聊一下Google Drive協同編輯的心得吧。

結語：終於把研習班課程完成了 / Conclusion: The Experience of Workshop

這份投影片發佈之後，研習班的工作總算是告一段落了。

這次研習班跟其他研習班最大的差異，就是在於有很多實作的內容，而不是一直坐著聽老師授課。這次研習班主要兩個實作課程，一個是KALS合作標註閱讀學習，另一個則是這個DLLL-CIAS實作，這兩個實作都讓我煞費苦心。DLLL-CIAS要架設許多虛擬機器伺服器這點顯而易見，而KALS要弄到讓學員能夠在系統上順利操作，這背後其實也修改了許多細節。之前去IMLF 2014時就已經拖延了許多工作，然後之後投入在這研習班上，課程的部分就有點顧不住了，真是對不起老師啊。

雖然期末與這研習班整個像是災難一樣鋪天蓋地而來，但最後總算能夠過去。上課過程中有些兵荒馬亂，感謝各位助理大力相挺，沒有你們我一個人真的完成不了這些東西，這也包括了之前寫的幾篇DLLL-CIAS的細部操作文章。

研習班上課過程中，我本來以為這麼硬的內容，應該會讓大家聽到一片瞌睡。結果時候聽完還蠻多人跑來跟我比較他們圖書館使用的VMware方案之間的差異，也有平時不碰技術的人跟我表達這堂課讓他獲益，有些人甚至想要在自己家裡架起這套方案。即使是客套話，我也覺得很開心。

希望下次能夠吸取這次的經驗，然後再帶給大家更好的課程內容吧。

(more...)

第四版DLLL-CIAS架構規劃 / DLLL-CIAS Version 4 Structure Planning

在整理DLLL-CIAS第三版教學的時候，我發現現有架構中有許多缺陷。因此我著手規劃DLLL-CIAS第四版的架構，目標是達到去中心化、分散式儲存、高可用、腳本自動化安裝，讓IaaS管理更為簡單。以下則是記錄到目前為止的規劃內容。

In order to impove some disadvantages in DLLL-CIAS version 3, I want to plan the next version with decentralized network structure, distributed storage, high availibity and setup script. Following is the next DLLL-CIAS structure draft.

系統架構 / System Architecture

這一張圖用來說明目前規劃DLLL-CIAS第四版(以下簡稱v4)的系統架構。跟DLLL-CIAS第三版(以下簡稱v3)的架構不同，虛擬機器管理伺服器(以下簡稱Proxmox)的功能大幅上升、網路管理伺服器(以下簡稱Zentyal)改以虛擬機器架設、而資料儲存伺服器(以下簡稱NAS)則是非必備的元件，在此圖中省略。主要元件只剩下1. 虛擬機器管理伺服器(Proxmox VE)之MASTER；2. 其他虛擬機器管理伺服器；3. 網路管理伺服器。以下先說明網路架構，再說明這三個元件的功能。

硬體需求 / Hardware Requirments

v4架構要求每一個Proxmox節點都能夠擔任身為MASTER的工作，因此硬體需求為：

• 至少一台伺服器，最多可以擴增到1270台
• CPU：64位元，必須支援Intel VT或AMD-V
• 記憶體：8GB以上
• 硬碟：80GB以上，建議每台伺服器都有2到4顆硬碟
• 網路卡：1張

不支援以上最低需求的伺服器，再安裝時應該把Keepalive的HA優先度降低為0，以避免自己被輪到擔任Master Proxmox。

網路架構 / Network Topology

v3架構中是以網路管理伺服器(Zentyal)作為網路閘道路由器來連接內外網，在v4架構中則改成所有的節點都可直接連到對外網路。v4的所有節點仍維持原本的區域網路設定，僅有真正對外的伺服器以虛擬網路卡(Virtual Interface)掛載上可對外連線的網路設定。

在這個架構中至少四個對外IP。一個是給Master Proxmox實際對外連線的IP，其他3個是Zentyal上供管理Proxmox、NAS與虛擬機器的IP，其中管理虛擬機器的IP最多可以設定到250個。

設定舉例如下：

• Master Proxmox IP位址：192.168.56.101
• Zentyal上的設定：
• 管理Proxmxo IP位址：192.168.56.102 （必須事先獲得上層DNS授權）
• 管理NAS IP位址：192.168.56.103
• 管理虛擬機器的IP位址：192.168.56.104

廣域網路其他設定：

• Netmask 子網路遮罩：255.255.255.0
• Gateway 網路閘道：192.168.56.1
  

v4在區域網路中的設定也跟v3不一樣：

• Master Proxmox：10.254.0.254
  ※ 以虛擬IP掛載，同時會掛載Proxmox對外IP位址
• Zentyal的IP位址：10.0.0.254
  ※ 同時會掛載Zentyal對外IP位址與兩個管理用IP
• 每一台Proxmox：10.254.{1..5}.{1..99}
  
• 每一台NAS：10.253.{1..5}.{1..99}
• 虛擬機器：10.{1..250}.{1..5}.{1..254}

區域網路其他設定：

• Netmask 子網路遮罩：255.0.0.0
• Gateway 網路閘道：10.0.0.254
  

元件(1): 虛擬機器管理伺服器 / Component (1): Virtual Machine Management Server

跟v3架構中Proxmox僅作為Proxmox VE Cluster的一個節點不同，在v4架構中Proxmox還加上了高可用、分散式儲存等多項功能。

網路設定 / Network Configuration

Proxmox僅在區域網路中連線，網路設定為：

• IP: 10.254.{1..5}.{1..99}
• Netmask: 255.0.0.0
• Gateway: 10.0.0.254

Proxmox Hostname設定規則為：

• pve.master-rack.a.1-1.example.com

以下說明hostname設定規則：

• pve: 這是一個Proxmox VE伺服器
• master-rack：所在機架代號
• a：機架上的位置編號
pve: 這是一個Proxmox VE伺服器
• 1-1: IP位址的第三部分與第四部分
• example.com：依據單位各自狀態設定

在這個架構下，舊節點捨棄之後，新的節點不取代舊節點的IP，直接往上新增。例如節點10.254.1.1毀損之後，新機器不設定10.254.1.1，而是設定10.254.1.2。

特別是Hostname必須不同，不能取代舊節點的Hostname，不然Proxmox VE Cluster會發生錯誤。

功能 / Functions

v4架構中每一台Proxmox都具備一樣的工作，以下分項目敘述。

Proxmox VE Cluster跟v3架構一樣，只有Storage多掛載一個目錄：

• 每一台Proxmox都是Proxmox VECluster的節點
• 以下設定只有第一台需要設定：
• 建立Proxmox VE Cluster，名稱為DLLL-CIAS
• Storage 掛載 /mnt/mfs 為 a_mfs，Max Backup設定為1。關於/mnt/mfs下面會說明。
• 再到Storage 掛載 /mnt/mfs 為 mfs-backup，Max Backup設定為5，僅有Backup功能。
• 排程備份VMID 100到mfs-backup，時間為每週一凌晨2:00，備份模式為snapshot，壓縮為none。
• 排程備份除了VMID 100之外的虛擬機器到a_mfs，時間為每週日凌晨2:00，備份模式為snapshot，壓縮為gzip最佳。
• 第二台之後設定以下：
• 加入Proxmox VE Cluster

高可用：

• keepalived套件
• 每一台都擔任BACKUP角色
• keepalived中使用notify_master的腳本keepalived_to_master.sh：當該節點升格成MASTER角色時執行的動作。細節在下面的「情結：切換MASTER」會說明。
• 開機自動啟動keepalived

分散式儲存：

• MooseFS套件
• 設定/etc/hosts：10.254.0.254 cias-pve-master
• 除了安裝Proxmox所在硬碟之外的所有硬碟，全部格式化為ext3，掛載到/data/底下。例如/dev/sdb掛載到/data/sdb
• master套件：安裝完成，預設不啟動，縮短垃圾桶時間，限制只能10.254.0.0/16連線
• metalogger套件：監控cias-pve-master (原本預設是mfsmaster，在此做修改)
• chunkserver套件：提供/data底下的資料夾給cias-pve-master當做儲存空間
• mfsmount (mfs-client端)：在/mnt/mfs掛載cias-pve-master
• 以上都開機自動啟動、開機自動掛載

Zentyal備份到本機端：

• 用crontab，在每週一凌晨4:00，從/mnt/mfs/dump/vzdump-qemu-100-*_*_*-*_*_*.*，複製並重新命名到/var/lib/vz/dump/zentyal.tar.vma，覆蓋舊檔案

停電斷線自動關機：

• 使用crontab，每3分鐘確認是否可連線到8.8.8.8。如果無法連線，表示可能對外網路已經斷線，預約15分鐘後進行關機
• 若恢復連線，則取消關機動作。

元件(2): MASTER虛擬機器管理伺服器 / Component (2): Master Virtual Machine Management Server

在v4架構中只會有一台Proxmox擔任Master，以下簡稱Master Proxmox。這台Master Proxmox在以Keepalived實作的高可用集叢（High Availability Cluster，以下簡稱HA）中，可由任何一台Proxmox擔任。Keepalived會依照優先權決定擔任Master的Proxmox，在安裝Proxmox的時候可以設定優先權。

網路設定 / Network Configuration

Master的Promxox同時具有對外網路與對內網路連線，Keepalived會自動幫擔任Master的Proxmox設定好額外的網路設定。Master的網路設定都是用虛擬IP的方式設定，並不影響原本Proxmox本身的網路設定。

廣域網路設定如下，請根據現實環境來修改：

• IP: 192.168.56.101
• Netmask: 255.255.255.0
• Gateway: 192.168.56.1

區域網路設定如下：

• IP: 10.254.0.254
• Netmask: 255.0.0.0
• Gateway: 10.0.0.254

Hostname為：cias-pve-master。但實際上並不設定在伺服器本身，僅在/etc/hosts記錄。

功能 / Functions

Master的Proxmox基本功能都跟其他Proxmox一樣，只是額外具有以下功能：

• 負責給其他Proxmox加入Cluster用
• Keepalived的status為MASTER
• MooseFS的mfsmaster跟mfscgiserv皆啟動，可用9425連接埠觀看
• 自身運作著Zentyal虛擬機器
• 定時匯出虛擬機器列表到mfs管理目錄中
• 定期檢查節點是否存活，如果沒有存活則自動將該節點進行情節(6)移除節點的腳本

元件(3): 網路管理伺服器 Zentyal / Component (3): Network Management Server

Zentyal的工作跟v3時差不多，但是把管理區域區隔開來，這部份會在雲端網路模組中改進。

網路設定 / Network Configuration

Zentyal的網路設定跟v3一樣有兩張網卡。對外廣域網路網卡上基本設定了一個IP，然後再用虛擬IP掛載至少兩個管理用IP。對內區域網路網卡則只會有一個設定。

廣域網路的設定請根據現實環境來修改。管理Proxmox的IP如下，這同時也是Zentyal Web GUI的連線設定，也必須是擁有DNS授權的功能：

• IP: 192.168.56.102
• Netmask: 255.255.255.0
• Gateway: 192.168.56.1

然後以下兩個廣域IP是用虛擬IP的方式設定：

• 管理NAS用：192.168.56.103。整合到雲端網路模組設定。
• 管理虛擬機器用：192.168.56.104。此類型IP可以增加到240個。整合到雲端網路模組設定。

區域網路設定只有一個，設定如下：

• IP: 10.0.0.254
• Netmask: 255.0.0.0
• Gateway: 10.0.0.254

Hostname為cias-router。

功能 / Functions

Zentyal使用KVM虛擬機器，主要工作為基本的閘道器跟雲端網路模組這兩種。

以KVM虛擬機器架設Zentyal設定為：

• 硬碟：4 GB
• 記憶體：2 GB
• 網路卡：1張virtio高速網卡

該虛擬機器會預先配置好以下動作：

• 安裝好Zentyal 3.0，僅安裝最小需要的元件：DNS Server、DHCP Server
• 啟用模組
• 配置區域網路設定：10.0.0.254/8
• 安裝好雲端網路模組
• 網路設定：SSH僅供10.254.0.254連線，其餘禁止
• 設置DHCP Server：提供範圍是10.251.{0..254}.{1..254}
• 設置腳本：新增Zentyal帳號與密碼 (create_user.sh)、設定Proxmox管理IP (setup_ip_proxmox.sh)、設定NAS管理IP (setup_ip_nas.sh)、設定虛擬機器管理IP (setup_ip_vm.sh)
• 開發用腳本：清除log設定 (dev_clean.sh)

基本網路閘道器角色功能為：

• DNS Server：可以設定註冊新的Domain Name
• DHCP Server：給區域網路暫時取得IP使用

雲端網路模組包括：

• PVE Back End：Proxmox連線管理：固定使用原本的IP，給Proxmox做連接埠轉遞跟反向代理伺服器(reverse proxy，以下簡稱RP)來連線管理
• NAS Back End：NAS連線管理：指定一個IP給NAS用，給NAS做連接埠轉遞管理跟RP來連線管理
• VM IP：虛擬機器管理IP對應編號設定：設定IP與區域網路第二部分對應，對應編號範圍為{0..250}。舉例來說，192.168.56.104對應設定0，對應的區域網路範圍就是10.0.{1..5}.{1..99}，對應VMID為{1..5}{01..99}。虛擬機器VMID與區域網路IP對應請看後面的介紹。
• VM Back End：虛擬機器連線管理：給虛擬機器做連接埠轉遞跟RP。直接設定VMID，由VMID轉換成區域網路IP對應。虛擬機器VMID與區域網路IP對應請看後面的介紹。
• 其他：URL Redirect、DNS，功能跟v3相同，只是IP使用的是給Proxmox管理用IP。

元件(4): 資料儲存伺服器 NAS / Component (4): Storage Server

NAS在v4架構中不是必須的，但如果有多的NAS想納入架構的話，在v4中依有NAS的位置。跟v3一樣，NAS的功能主要的工作是擺放備份檔案、ISO跟虛擬應用範本。許多人會拿NAS來放置KVM的映像檔，然後運作KVM，但是在DLLL-CIAS中並不這樣做。DLLL-CIAS的虛擬機器預設都會運作在a_mfs上。

網路設定 / Network Configuration

NAS的網路設定都是區域網路，僅提供DLLL-CIAS內部使用，對外連線則是由Zentyal的NAS管理IP來控制。

• IP: 10.253.{1..5}.{1..99}
• Netmask: 255.0.0.0
• Gateway: 10.0.0.254

NAS的Hostname設定規則與Proxmox類似：

• nas.master-rack.a.1-1.example.com

以下說明Hostname設定規則：

• nas: 這是一台NAS
• master-rack：所在機架代號
• a：機架上的位置編號
• 1-1: IP位址的第三部分與第四部分
• example.com：依據單位各自狀態設定

功能 / Functions

在v4中的NAS只會使用它的NFS功能，分享的NFS名稱同Hostname，讓它掛載到Proxmox VE Cluster的Storage中，掛載名稱也跟Hostname相同。

虛擬機器VMID與區域網路IP對應規劃 / Virtual Machine ID and Local IP Address Mapping

為了確保虛擬機器與區域網路IP的一致性，v4架構中在雲端網路模組改以強制設定VMID，而非以往的設定區域網路IP。VMID與IP的對應規則如下：

VMID 100為特殊VMID，僅給zentyal使用。

VMID的組合基本上為3~6碼，分成前三碼跟後三碼兩個部分，前三碼為虛擬機器管理對外IP對應編號，範圍為{0..250}，對應到區域網路IP的第二部分；後三碼為連接埠轉遞的編號，範圍為{101..199}、{201..299}、{301..399}、{401..499}、{501..599}，連接埠轉遞編號第一碼對應到區域網路IP的第三部分、後兩碼對應到區域網路IP的第四部分。

舉例來說：

• VMID 101：對外IP編號0，連接埠轉遞101xx，區域網路IP 10.0.1.1，這是VMID範圍的最小值。
• VMID 10501：對外IP編號10，連接埠轉遞501xx，區域網路IP 10.10.5.1
• VMID 250599：對外IP編號250，連接埠轉遞599xx，區域網路IP 10.250.5.99，這是VMID範圍的最大值。

在這樣的規劃下，v4的虛擬機器最大數量為495連接埠轉遞*250對外IP編號共123000 (12萬3千)台，此時需要250個給虛擬機器用的對外IP，加上其他元件的需求，總共需要253個對外IP。

若以最低對外IP的條件來看，以最少4個對外IP的規劃中，虛擬機器最大數量即為495台。

管理情節 / Management Scenario

v4的架構中有許多管理情節，主要會用到的有以下幾項，並概述情節中會進行的動作。

情節(1)：安裝 / Scenario (1): Install Master

v4架設需要一台伺服器跟一片Proxmox VE 3.2光碟，你可以從這邊下載。安裝動作只需要執行一次，簡稱為Master安裝，只要有Master Proxmox在，其他伺服器應該執行擴增動作。

以下是手動的部份，[M]表示Master安裝中特別會做的動作：

• 安裝Proxmox VE 3.2
• [M] 安裝過程中設定對外Master IP
• 從網路下載dlll_cias-setup.sh腳本
• 增加執行權限並執行dlll_cias-setup.sh腳本

腳本首先先蒐集設定資訊：

• 腳本檢查網路可否連線，不可連線則提示訊息後退出
• 詢問Keepalived的優先度，範圍是{0..100}，預設值是50，數字越大越可能擔任Master Proxmox。
• 腳本檢查是否有Master在，來決定是否是Master安裝模式。
• [M] 腳本詢問給Zentyal的帳號與密碼
• [M] 腳本詢問給Zentyal網路設定：Proxmox管理IP、NAS管理IP、虛擬機器管理IP、netmask、gateway
• 腳本提示準備開始安裝，按enter確認。

腳本先保存管理資訊跟下載必要檔案，保存到/data/cias管理目錄中：

• [M] 保存Master Proxmox的對外IP、Zentyal的Proxmox網路設定到一個管理連線設定檔
• [M] 下載keepalived需要的keepalived.conf等必要腳本
• [M] 根據對外IP來調整keepalived設定檔
• [M] 製作手動切換的keepalived設定檔
• [M] 下載MooseFS必要的設定檔案
• [M] 下載Zentyal虛擬機器即必要腳本
• [M] 下載DLLL-CIAS管理用的必要腳本
• [M] 根據此Proxmox VE安裝中設定的管理者email，設定通知設定檔
• [M] 調整腳本權限

腳本接著進行網路設定與Keepalived的安裝：

• 安裝Keepalived必要元件
• 從管理目錄複製必要設定到指定位置
• 根據現在網路卡數量，將所有網路卡都bonding到vmbr0上
• [M] 修改vmbr0網卡設定為10.254.0.1
• 啟用Keepalived
• [M] 此時vmbr0應該會額外被掛上Master對外IP跟10.254.0.254的虛擬IP
• 設定開機自動執行

腳本接著進行MooseFS安裝：

• 新增10.254.0.254 cias-pve-master設定到/etc/hosts
• 安裝MooseFS所需元件(包括更新fuse)
• 從管理目錄複製必要設定檔到指定位置
• 啟用metalogger
• [M] 啟用master
• 確認cias-pve-master可連線
• 格式化Proxmox VE安裝外的其他磁碟，並進行掛載
• 依據磁碟數量調整chunk設定檔
• 啟用chunk
• 掛載mfsmount
• 設定開機自動執行
• [M] 把需要共用的檔案放到 /mnt/mfs/cias 中

如果是Master安裝模式，則腳本進行以下動作：

• [M] 新增Promxox VE Cluster
• [M] 新增Cluster的Storage，掛載MooseFS
• [M] 新增Cluster的排程備份

如果是Master安裝模式，則腳本接著進行Zentyal的安裝：

• [M] 從管理目錄還原Zentyal虛擬機器
• [M] 開機Zentyal
• [M] 以預設帳號cias與預設密碼dlll@nccu連線到Zentyal （預設IP為10.0.0.254）
• [M] 設定Zentyal的管理用IP
• [M] 新增Zentyal帳號與密碼
• [M] 在背景執行備份Zentyal
• [M] 在背景執行備份Zentyal到Local

腳本新增排程工作：

• 設定排程，定期將Zentyal備份檔案備份到Local硬碟中
• 設定排程，定期偵測斷線自動關機腳本
• [M] 設定排程，定期將現有節點上所擁有的虛擬機器的VMID儲存到/mnt/mfs/cias/pve_master_vmid.conf中
• [M] 每隔5分鐘確認所有節點可連線狀態，若一節點無法連線，則等待30分鐘，若30分鐘後仍然無法連線，執行情節(6)移除此節點

腳本提示安裝完成訊息：

• 安裝完成
• 根據/mnt/mfs/cias/cias-network.conf，顯示Proxmox VE管理IP跟Zentyal網頁管理IP

以上安裝完成，這時候應該會持續備份Zentyal虛擬機器，就讓它跑吧。

情節(2)：擴增 / Scenario (2): Extend Slave

v4架構下，擴增時需要一台伺服器跟一片Proxmox VE 3.2光碟，你可以從這邊下載。若已經架設好Master Proxmox，則其他伺服器則是用擴增的方式安裝，簡稱Slave安裝。

以下是手動的部份，[S] 表示擴增使用

• 安裝Proxmox VE 3.2
• [S] 安裝過程中設定區域網路IP 10.254.{0..254}.{2..254} （因為10.254.0.1給Master Proxmox使用了）
• 從網路下載dlll_cias-setup.sh腳本
• 增加執行權限並執行dlll_cias-setup.sh腳本

腳本首先先蒐集設定資訊：

• 腳本檢查網路可否連線，不可連線則提示訊息後退出
• 詢問Keepalived的優先度，範圍是{0..100}，預設值是50，數字越大越可能擔任Master Proxmox。
• 腳本檢查是否有Master在，來決定是否是Master安裝模式。因為有Master在了，所以以下是Slave安裝。
• [S] 詢問Master Proxmox的連線密碼，並測試連線到Master Proxmox以確認金鑰
• 腳本提示準備開始安裝，按enter確認。

腳本從Master Proxmox複製管理資訊：

• [S] 用rsync複製Master Proxmox的管理目錄底下的檔案到本機的管理目錄

腳本接著進行MooseFS安裝：

• 新增10.254.0.254 cias-pve-master設定到/etc/hosts
• 安裝MooseFS所需元件(包括更新fuse)
• 從管理目錄複製必要設定檔到指定位置
• 啟用metalogger
• 確認cias-pve-master可連線
• 格式化Proxmox VE安裝外的其他磁碟，並進行掛載
• 依據磁碟數量調整chunk設定檔
• 啟用chunk
• 掛載mfsmount
• 設定開機自動執行

腳本接著進行網路設定與Keepalived的安裝：

• 安裝Keepalived必要元件
• 根據現在網路卡數量，將所有網路卡都bonding到vmbr0上
• 從管理目錄複製必要設定檔到指定位置
• 啟用Keepalived
• 設定開機自動執行

如果是Slave安裝模式，則腳本進行以下動作：

• [S] Proxmox VE Cluster加入到Master Proxmox中

腳本新增排程工作：

• 設定排程，定期將Zentyal備份檔案備份到Local硬碟中
• 設定排程，定期偵測斷線自動關機腳本
• [S] 以背景執行從Zentyal備份檔案備份到Local硬碟中

腳本提示安裝完成訊息：

• 安裝完成
• 根據/mnt/mfs/cias/cias-network.conf，顯示Proxmox VE管理IP跟Zentyal網頁管理IP

以上安裝完成，這時候應該會持續備份Zentyal虛擬機器，就讓它跑吧。

情節(3)：自動切換Master Proxmox / Scenario (3): Automatically Swtich Master Proxmox

由於Keepalived工具提供的高可用集叢，當Master Proxmox無法連線時，Keepalived會自動挑選其中一台Proxmox，把它當作Master Proxmox，並進行以下切換的動作。

以下Keepalived會自動設定：

• 掛載對外Master Proxmox對外網路
• 掛載cias-pve-master 10.254.0.254

然後進行MooseFS高可用設定：

• metalogger復原master資料：mfsmetarestore -a
• 啟動master

虛擬機器的高可用：

• 一一檢查/mnt/mfs/cias/pve_master_vmid.conf中的VMID
• 如果集叢中VMID 100虛擬機器存在且可用，試著Migrate到這個節點上
• 如果集叢中無法取得該虛擬機器，則嘗試從備份檔案中還原虛擬機器
• VMID 100是Zentyal，從本機端取得還原檔案
• 其他VMID則從mfs取得檔案還原，選擇負載量最低且非Master Proxmox的節點去還原
• 確認虛擬機器的auto_start=1下正常開機

通知：

• 寫信給現在mfs管理目錄中設定的管理者

情節(4)：手動切換Master Proxmox / Scenario (4): Manual Swtich Master Proxmox

有些情況下我們希望手動指定Master Proxmox到特定伺服器上，而若該伺服器沒有被Keepalived指名，我們可以用以下的指令來手動切換Master Proxmox。

• 到管理目錄執行 dlll_cias-swtich_to_master.sh

該腳本會先進行以下動作

• 將原本keepalived.conf改成keepalived.conf.temp
• 把調高權限的keepalived.conf複製到此位置：此設定中預設status為MASTER，priotity為999。
• 重新啟動Keepalived，此時因為設定的關係，會將其他節點上的Master Proxmox狀態搶到自己身上
• 自動執行情境(3)的腳本
• 刪除調高權限的設定檔，復原原本的keepalived.conf設定檔

情節(5)：手動退出集叢 / Scenario (5): Proxmox Escape From Cluster

此節點預備要退出集叢，則在要此節點上執行此腳本：

• 設定遷移完畢之後的通知email
• 取得本機上的虛擬機器列表
• 每一台虛擬機器進行以下動作
• 根據每一台Proxmox的RAM使用量，決定移到負荷量最低且非Master Proxmox的Proxmox
• 遷移虛擬機器，除了VMID 100
• 如果自己是Master Proxmox
• 更新本機端虛擬機器檔案
• 重新啟動Keepalived，此時其他節點會搶走MASTER狀態，並把VMID 100 Zentyal遷移到他身上去
• 每隔5分鐘確認VMID 100是否遷移完成
• 全部遷移完成之後，脫離Cluster
• 發信通知管理者，以及mfs管理目錄中的管理者
• 實體伺服器關機

情節(6)：移除Proxmox節點 / Scenario (6): Delete Proxmox Node

如果某一個節點因為意外斷線，則必須重建該節點上面的虛擬機器，並移除該節點。這個情節是由Master Proxmox定時運作，此腳本工作為：

• 取得參數：指定要移除的節點
• 確認該節點是否可連線
• 如果可連線，則在該節點上執行情節(5)
• 如果不可連線，則讀取該節點的虛擬機器列表
• 選擇最低負載量與非Master Proxmox，從mfs備份檔案中還原
• 全部還原完成之後，將此節點從cluster中移除
• 寫信通知email

注意事項 / Attention Notes

v4的架構在使用的時候有一些地方需要特別注意。

網路連線安全性 / Network Security

為了讓網路管理伺服器去中心化，所有的節點都暴露在對外網路中。這個意思是，如果該網域底下有人自行設定網路為Master Proxmox的10.254.0.254或任一10.x.x.x的IP，v4架構就會很容易發生錯誤或是被入侵。但是比起v3時會有網路管理伺服器Zentyal單點故障導致整體無法運作的問題，去中心化的設計只是在安全性與便利性上的取捨。

額外的便利性是任一虛擬機器都可以設定成對外IP，提供直接連線。

Master Proxmox的高負荷量 / High Loading of Master Proxmox

目前Master Proxmox主要只有做高可用，可是其本身負擔著大量的工作，最主要的就是Zentyal跟Mooster的mfsmaster。Zentyal必須處理大量連線，而mfsmaster在檔案數量大增的時候對於RAM的需求也很高。

即使可以手動指定負載能力最高的伺服器擔任Master Proxmox，但還是沒辦法讓其他人分擔Master Proxmox的工作量。目前我想不到是否有其他的好辦法，留待下一版DLLL-CIAS再看看有沒有更好的方案吧。

待研究事項 / To-Do

這篇只是v4的架構草案，目前還有許多地方未經確認與實作，仍有待繼續研究。目前主要需要確認的問題包括：

• 網路卡實作bonding的技術還沒實作過
• Proxmox VE Cluster節點只剩下一台的時候，會因為cluster not ready而限制很多操作，包括下一個問題。
• 新master還原虛擬機器zentyal時，會因為舊節點還沒移除而被卡住：理論上，在cluster上會保留斷線的節點以及上面的虛擬機器設定，而禁止在同一個cluster不同節點上新增同樣的VMID。這部份一定得想辦法克服才行。
• Zentyal在最小安裝與合理負荷之間的平衡：只有實際上架設過後才能知道了
• Zentyal腳本操作可行性：我記得Zentyal可以用腳本來操作，可是一時間找不到說明文件

可能比較不會是問題，但是需要研究如何撰寫的腳本：

• 依據磁碟數量來做格式化的腳本
• metalogger復原master還沒實作過
• 改進雲端網路模組的功能
• 確認虛擬機器在Cluster中存在的腳本
• 遷移虛擬機器到本機端的腳本

實作上面的待辦事項：

• 架設開發用的Zentyal：要注意硬體設定
• 各種腳本與設定檔的撰寫

結語：Proxmox VE Cluster依然是大難關 / Conclusion: Problems With Proxmox VE Cluster

以上規劃了DLLL-CIAS第四版的架構，基於第三版的架構之上再納入網路管理伺服器去中心化、分散式儲存、虛擬機器高可用與腳本簡化安裝等想法，並改進了雲端網路模組的設計，讓可同時運作的虛擬機器上限提高。

但是其實最根本的問題還沒解決：Proxmox VE Cluster仍有高度不穩定性的問題。

如果一開始都把Proxmox VE Cluster架設好、加入集叢，然後每個節點放著正常運作，這樣子Cluster沒有問題。若是節點以正常的方式關機，Cluster依然沒有問題。

但問題會出現在節點以非正常方式斷線或關機，或是節點數量只剩下一台時，這樣會導致整個Cluster運作失靈。要移除節點或是用相同Hostname加入Cluster時，好像也有可能導致Cluster毀損。

當Cluster毀損時，不管點任何動作，都會被要求登入，而且除了自己節點之外的其他節點都無法顯示任何訊息。

目前修復Proxmox VE Cluster的方法仍然不明，要如何避免Cluster毀損的方法也還沒有摸熟，這些都是要在發展v4之前必須搞懂得部分。

我們之前修復的方式是以不同名字重建Cluster，然後從NFS中取得備份檔案來還原。手動作業耗費了相當多的時間，我覺得這是相當大的一個問題。

之後有機會會再針對這部份進行深入的研究，至少要確保Cluster正常運作，DLLL-CIAS才算是一個穩定的方案吧。

(more...)