網管人雜誌
本文刊載於 網管人雜誌第 67 期 - 2011 年 8 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
1、前言2、iSCSI Initiator 主機設定
啟動 iSCSI Initiator 服務
新增 iSCSI Target 儲存資源 IP 位址
設定 VMware ESX 掛載 iSCSI Target 儲存資源
3、災難測試
測試一、手動切換叢集節點
測試二、交換器/網路卡損壞或網路線被踢掉
測試三、虛擬主機運作中切換叢集節點
4、叢集主機硬體維護
正確關機流程
正確開機流程
5、結語
1、前言
在 建置高可用性 iSCSI 儲存設備 (上) 及 建置高可用性 iSCSI 儲存設備 (中) 內容中，已經設定好將 iSCSI Taraget 的儲存資料透過網路鏡像同步技術，即時地將儲存資料進行同步，並設定高可用性容錯機制中的 IP 位址接管技術，套用於屆時的 iSCSI 高可用性服務上。本文將實作 iSCSI Initiator 主機如何存取 iSCSI Target 所分享的儲存資源，並且在 iSCSI 高可用性服務上線之前進行相關的災難演練測試，以便災難真的發生時不致手忙腳亂，並且藉著災難演練，建立企業的相關災難回復標準作業流程 (SOP)，同時當遇到特殊情況須要將兩台叢集主機都關機 (例如 更換機房) 的情況時，叢集主機應如何正確關機及開機流程，以確定叢集服務運作無誤。
2、iSCSI Initiator 主機設定
啟動 iSCSI Initiator 服務
此次實作中，我們採用的軟體式 iSCSI Initiator 為 VMware vSphere Hypervisor 中的 iSCSI Software Adapter，在 VMware vSphere Hypervisor 主機中除了預設的 Service Console 之外由於必須存取 iSCSI Target，所以您必須建立 VMkernel Port 用來存取 iSCSI Target 儲存資源的 IP Storage 網路 (若採用 VMware ESXi 版本則不需要再建立 VMkernel Port)，待建立 VMkernel Port 完成後便可以接著啟動VMware vSphere Hypervisor 上的 iSCSI Initiator 服務，啟動 iSCSI Initiator 方式如下：- 執行 VMware vSphere Hypervisor 控制台軟體 【VMware vSphere Client】。
- 登入 VMware vSphere Hypervisor 後請先點選【Configuration】頁籤接著點選 Hardware 項目清單中的【Storage Adapters】項目。
- 接著於右邊 Storage Adapters 視窗中點選 iSCSI Software Adapter 內【vmhba33】介面卡，接著點選【Properties】以便查看iSCSI Software Adapter設定內容。
- 在彈出的 iSCSI Initiator (vmhba33) 介面卡設定內容中請點選【General】頁籤後按下【Configure】按鈕。
- 在彈出的 General 設定內容視窗中勾選 Status 下的【Enabled】項目後按下【OK】即可啟動 iSCSI Initiator 服務。
圖1、選擇 iSCSI Software Adapter 介面卡準備啟動 iSCSI Initiator 服務
圖2、啟動 iSCSI Initiator 服務
新增 iSCSI Target 儲存資源 IP 位址
成功啟動 VMware vSphere Hypervisor 主機上的 iSCSI Initiator 服務後接著便是指定 iSCSI Target 儲存資源的 IP 位址，設定方式如下：- 執行 VMware vSphere Hypervisor 控制台軟體 【VMware vSphere Client】。
- 登入 VMware vSphere Hypervisor 後請先點選【Configuration】頁籤接著點選 Hardware 項目清單中的【Storage Adapters】項目。
- 接著於右邊 Storage Adapters 視窗中點選 iSCSI Software Adapter 內【vmhba33】介面卡，接著點選【Properties】以便查看iSCSI Software Adapter設定內容。
- 在彈出的 iSCSI Initiator (vmhba33) 介面卡設定內容中請點選【Dynamic Discovery】頁籤後按下【Add】按鈕來新增 iSCSI Target 儲存資源的 IP 位址。
- 在彈出的 Target Server 設定視窗中請輸入 iSCSI Target IP 位址【10.10.25.135】後按下【OK】鍵，即完成新增 iSCSi Target 儲存資源的動作。
- 此時系統會提示您要進行系統資源重新掃描 (Rescan) 的動作，此時請按下【Yes】 進行掃描，掃描完成後便可看到 iSCSI Target 資源。
圖3、新增 iSCSI Target 儲存資源 IP 位址
圖4、iSCSI Initiator 裝置成功偵測到 iSCSI Target 儲存資源
設定 VMware ESX 掛載 iSCSI Target 儲存資源
上述存取 iSCSI Target 儲存資源前置作業完畢後便可以設定 VMware vSphere Hypervisor 掛載 iSCSI Target 儲存資源，將該儲存資源掛載成為 VMware vSphere Hypervisor 資源池 Datastore 來使用，屆時虛擬主機 (VM) 也將運作於此儲存資源池內，設定方式如下：
- 執行 VMware vSphere Hypervisor 控制台軟體 【VMware vSphere Client】。
- 登入 VMware vSphere Hypervisor 後請先點選【Configuration】頁籤接著點選 Hardware 項目清單中的【Storage】項目。
- 接著於右邊 Datastores 視窗中點選【Add Storage】準備新增 iSCSI Target 儲存資源至 Datastores 內。
- 在彈出的視窗中首先為選擇將要新增儲存資源種類，請選擇【Disk/LUN】項目並按下【Next】繼續後續的動作，此時系統將開始透過剛才設定的 iSCSI Initiator 服務及設定的Dynamic Discovery 去偵測 iSCSI Target 儲存資源。
- 因為相關設定皆正確因此系統順利偵測到 iSCSI Target 儲存資源出現在視窗中，請選擇儲存資源項目【IET iSCSI Disk 9 GB】後按下【Next】繼續後續的動作。
- 此時系統會提示您要將剛才選擇的儲存資源進行格式化為 vmfs 檔案系統的動作，請按下【Next】繼續後續的動作。
- 格式化完成後請輸入屆時您在 Datastore 中要辨識此儲存資源的名稱，此例我們輸入名稱為【iSCSI】，並按下【Next】繼續後續的動作。
- 接著則是選擇格式化此檔案系統時的Block size，此設定值為屆時可儲存的單一檔案大小極限值為何，此次設定中我們採用預設值即可，請按下【Next】繼續後續的動作。
- 上述設定都確定後最後則是按下【Finish】按鍵確定新增 iSCSI Target 儲存資源掛載至系統的動作。
圖5、VMware ESX 掛載 iSCSI Target 儲存資源成功
當 VMware ESX 成功掛載 iSCSI Target 儲存資源之後，您便可以開始將虛擬主機 (VM) 建立於該儲存資源內，另外您可以在 Primary Node 上執行 tgtadm 指令搭配 show 的參數來查看有誰掛載 iSCSI Target 儲存資源，如下所示您可以看到iSCSI Initiator資訊為 VMware ESX (iqn.1998-01.com.vmware:esx41-13338d08)。
# tgtadm --lld iscsi --op show --mode target //查看 iSCSI Target 儲存資源狀態
Target 1: iqn.2011-03.org.weithenn:iscsi.storage
System information:
Driver: iscsi
State: ready
I_T nexus information:
I_T nexus: 1
Initiator:
iqn.1998-01.com.vmware:esx41-13338d08 //VMware ESX 掛載成功
Connection: 0
IP Address: 10.10.25.133 //VMkernel Port IP 位址
LUN information:
LUN: 0
Type: controller
SCSI ID: IET 00010000
SCSI SN: beaf10
Size: 0 MB
Online: Yes
Removable media: No
Backing store type: rdwr
Backing store path: None
LUN: 1
Type: disk
SCSI ID: IET 00010001
SCSI SN: beaf11
Size: 9664 MB
Online: Yes
Removable media: No
Backing store type: rdwr
Backing store path: /storage/iscsi
Account information:
ACL information:
10.10.25.0/243、災難測試
以下透過手動切換叢集節點、交換器/網路卡損壞或網路線被踢掉、虛擬主機運作中切換叢集節點等三種方式來進行災難測試。測試一、手動切換叢集節點
高可用性容錯機制，首先測試利用手動方式來切換叢集節點待容錯機制測試成功後，再著手進行更進一步的災難測試，假設情境為當您需要將 Primary Node 主機關機進行硬體維護 (例如更換損壞的記憶體)，但是又想保持其上的服務持續運作時便可以使用手動切換叢集節點的方式來處理，當要手動切換叢集節點時只要在 Primary Node (Active Node) 上將 Heartbeat 服務重新啟動即可。您可以同時開啟二個遠端登入視窗一個登入 Node1 主機另一個登入至 Node2 主機，Node2 主機先執行 watch –n 1 service drbd status 指令來即時查看叢集運作狀態，接著在登入 Node1 主機上的視窗執行 Heartbeat 服務重新啟動的指令 service heartbeat restart 即可叢集服務切換節點主機的運作狀態變化，提醒您再此次實作中當原來的 Primary Node 上的 Heartbeat 服務再次啟動後並不會將主動權搶回，因為在 Heartbeat 通訊設定檔 /etc/ha.d/ha.cf 中錯誤後回復機制設定值 auto_failback 為 off，若您在 Heartbeat 通訊設定檔中 auto_failback 設定值為 on 則當原來的 Primary Node (現在為 Secondary Node 角色) 其 Heartbeat 服務再次啟動後便會將主動權搶回再次成為 Primary Node (Active Node)。
[root@node1 ~]# service heartbeat restart
Stopping High-Availability services:
[ OK ]
Waiting to allow resource takeover to complete:
[ OK ]
Starting High-Availability services:
2010/11/03_11:31:41 INFO: Resource is stopped
[ OK ]當 Heartbeat 服務重新啟動指令執行時您會看到 Node2 主機中執行觀察的 DRBD 狀態變化其 Node1 主機狀態為 Primary/Secondary >> Secondary/Secondary >> Secondary/Primary，當 Heartbeat 服務重新啟動指令執行完成後此時在 Node2 主機上您可以看到已經接手 Primary Node 角色及相關服務：
- 系統掛載 /dev/drbd0 (iSCSI Target 儲存資源 /storage/iscsi)
- 接手 iSCSI Target 服務 (tgtd)
- 產生虛擬叢集網卡 (bond0:0) 及 IP 位址 10.10.25.136
[root@node2 ~]# service drbd status //Node2 主機接手 (成為 Active Node)
drbd driver loaded OK; device status:
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build
by mockbuild@builder10.centos.org, 2010-06-04 08:04:16
m:res cs ro ds p mounted fstype
0:ha Connected Primary/Secondary UpToDate/UpToDate C /storage ext3
[root@node2 ~]# service tgtd status //順利接手 iSCSI Target 服務
tgtd (pid 10128) is running...
[root@node2 ~]# ifconfig bond0:0 //順利接手 Cluster IP
bond0:0 Link encap:Ethernet HWaddr 00:03:FF:1E:7B:82
inet addr:10.10.25.136 Bcast:10.10.25.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:11 Base address:0xc000測試二、交換器/網路卡損壞或網路線被踢掉
因為此次實作的叢集架構中不管是網路服務線路或叢集主機之間用來互相偵測的心跳線皆有使用二片實體網路卡及網路線分接不同的網路交換器進行容錯保護，因此在此測試中我們首先測試當一片實體網路卡或一台網路交換器損壞的情況下先前所設定的網卡綁定模組 (Bonding) 是否正常運作進行容錯切換，接著才測試當 Primary Node 叢集主機上用於同一服務的二片實體網路卡都損壞的情況下是否會自動將服務切換到 Secondary Node。由於先前設定網路卡綁定模組其運作機制為網卡容錯方式，也就是平時只有一片實體網路卡會進行資料傳輸而另一片為待命狀態，待 Active 網路卡傳輸發生異常時 Backup 網路卡才接手傳輸工作 (Active / Backup 由系統自動處理及判斷)，因此我們可以將二片虛擬網路卡 bond0、bond1 中的實體網路卡成員中拔掉接於其中一片網路卡的網路線 (或者將該網路卡停用也可以) 來測試看看網卡容錯機制是否運作，此測試動作為在 Primary Node 叢集主機上拔掉接於 eth0、eth3 實體網路卡上的網路線，而 Secondary Node 叢集主機上則拔掉接於 eth1、eth2 實體網路卡上的網路線看看網路連線及叢集服務是否都正常運作，當然您也可以執行如下指令在叢集主機上來關閉指定的網路卡而省略到實體主機前面拔線的動作。
[root@node1 ~]# ifdown eth0 //Node1 主機停用 eth0 網卡
[root@node1 ~]# ifdown eth3 //Node1 主機停用 eth3 網卡
[root@node2 ~]# ifdown eth1 //Node2 主機停用 eth1 網卡
[root@node2 ~]# ifdown eth2 //Node2 主機停用 eth2 網卡上述測試實體網路卡及網路線脫落的情況皆通過並恢復環境後，接著您可以嘗試將其中一台網路交換器關閉來測試叢集是否正常運作，當上述情況都通過測試後我們可以把接於 Primary Node 叢集主機 bond0 虛擬網卡上的 eth0、eth1 網路線拔掉模擬當主機服務線路斷線時的狀況，當主機服務線路斷線超過 15 秒鐘後 Secondary Node仍然無法偵測到對方主機存活時是否會判定 Primary Node 主機失效並觸發錯誤後轉移機制 (Failover) 進而將相關服務及儲存資源接手過來，筆者測試的結果當然是 Secondary Node 會正確接手相關服務及儲存資源。
測試三、虛擬主機運作中切換叢集節點
上述基本容錯測試都完成後我們緊接著進行最後的容錯機制測試，由於我們此次建置的高可用性 iSCSI Target 儲存資源是提供運作於 Hypervisor 之上的虛擬主機，因此我們在此測試項目中為當虛擬主機在運作的情況下儲存資源發生災難後虛擬機是否仍然可以存取及提供服務。測試方式為同時開啟二個遠端登入視窗一個登入 Primary Node 主機另一個為 Secondary Node 主機，先於 Secondary Node 執行watch –n 1 service drbd status 指令來即時查看叢集運作狀態，接著開啟【vSphere Client】選擇運作於 iSCSI-Target 的虛擬主機後按下右鍵選擇【Open Console】以便等一下叢集節點切換時我們可以在切換期間測試虛擬主機操作是否正常，另外也開一個視窗來持續 Ping 該虛擬主機 IP 位址，並且開啟【Datastore Browser】上傳檔案至VMware vSphere Hypervisor 資源池內，以上測試條件準備完成後則是進入重頭戲將 Primary Node 主機直接進行關機的動作 (更甚者可以直接把電源線拔掉!! 但這樣的測試動作請盡量減少)。
當 Primary Node 主機執行關機的動作之後，一方面觀察已登入 Secondary Node 視窗其叢集運作狀態是否正將相關服務及儲存資源接手過來，另一方面請對虛擬主機進行相關操作 (例如 新增/刪除/複製檔案…等動作) 同時間觀察持續 Ping 視窗在叢集節點切換期間是否有遺失封包的情況，當然還有上傳檔案至 VMware vSphere Hypervisor 資源池的狀況。
於筆者的測試環境條件下叢集節點切換時間約 35 秒左右，在節點期間虛擬主機仍然可進行相關操作只是反應速度會比平常緩慢，至於持續 Ping 虛擬主機的動作則是沒有遺失任何封包的情況發生，而上傳檔案的視窗在節點切換期間並沒有斷掉而是持續嘗試連接且傳輸預估時間拉長而以，待節點切換完成恢復高速傳輸後則是再衝全速把檔案傳輸完畢，至此災難測試完美結束。
4、叢集主機硬體維護
企業使用的伺服器硬體雖然原廠在設計上皆為可供長時間持續運作，但實際上隨著運作時間日子一久難免會遇到部份零件損壞或其它因素而需要關機檢修的情況，當然若是僅僅是單台叢集主機需要關機進行檢修時我們可以利用重新啟動 Heartbeat 服務於 Primary Node 將相關服務及儲存資源切換到備援叢集節點接手，但是若遇到特殊情況需要將二台叢集主機都進行關機檢修或者機器要轉移放置地點 (例如 更換機房) 的情況下，叢集主機如何的正確關機及開機以確定叢集服務運作無誤其標準作業流程是必要的，以下便是簡述此流程：正確關機流程
- 請先將運作於 Hypervisor 之上的虛擬主機全部關機。
- 於 Primary Node 叢集主機上執行 Heartbeat 服務重新啟動的指令，以便將相關服務及儲存資源轉由 Secondary Node主機接手。
- 確認 Secondary Node 叢集主機接手成功後即可將 Primary Node 主機關機，此時在Secondary Node 看到的 DRBD 狀態應為 Primary/Unknown。
- 確認無人存取 iSCSI Target 資源後即可將 Secondary Node (現為 Primary Node) 主機 iSCSI Target 服務強制停止後即可關機，因為此時雖然沒有任何的 iSCSI Initiator 發出存取要求，但是因為 iSCSI Initiator 已經掛載 iSCSI Target 儲存資源了，因此若先不強制停止 iSCSI Target 服務 (將 iSCSI Initiator 連線斷開) 便進行關機動作的話則系統可能會在關機程序中卡住。
- 此時 Primary/ Secondary Node 皆已經關機完成，之後再依下面提到的正確開機流程進行開機的動作即可恢復高可用性的 iSCSI Target 儲存資源。
[root@node1 ~]# service heartbeat restart //切換叢集節點
[root@node1 ~]# sync;sync;sync;halt -p //將 Node1 主機關機
[root@node2 ~]# service drbd status //此時 DRBD 狀態
drbd driver loaded OK; device status:
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build
by mockbuild@builder10.centos.org, 2010-06-04 08:04:16
m:res cs ro ds p mounted fstype
0:ha WFConnection Primary/Unknown UpToDate/Outdated C /storage ext3
[root@node2 ~]# /etc/init.d/tgtd forcedstop //停止 iSCSI Target 服務
Force-stopping target framework daemon
[root@node2 ~]# rm -f /var/lock/subsys/tgtd //刪除程序檔案正確開機流程
- 先將 Primary Node 開機約莫等待 1分鐘後再將 Secondary Node 開機。
- 當 Primary Node 開機程序運作至 DRBD 啟動程序時會倒數 60 秒等待 Secondary Node 回應，在倒數讀秒期間 Secondary Node 運作至 DRBD 啟動程序時此時二台叢集主機會先確認 區塊裝置 /dev/drbd0 內所儲存的資料是否同步一致，確認同步一致之後繼續完成開機動作。
- 二台主機皆開機完成後請先登入至 Primary Node 查看相關服務及儲存資源是否正常運作，意即 Primary Node 主機是否成功掛載 /dev/drbd0 至 /storage、啟動 iSCSI Target 服務(tgtd)、擁有叢集虛擬網路卡 bond0:0 及叢集虛擬 IP 位址 10.10.25.136。
- 由於VMware ESX Host 每隔一段時間就會自動檢查是否可以存取掛載的資源池，因此您會發現先前因為叢集主機關機遷移時導致 Hypervisor 偵測到 iSCSI Target 儲存資源發生暫時失聯的情況 (如圖七、圖八)，而此時叢集服務已經恢復運作因此您可以開啟 【vSphere Client】 >> 選擇【Configuration】 >> 選擇 Hardware 下【Storage】 >> 按下【Refresh】即可回復 iSCSI Target 儲存資源池，請注意!! 不要按下 Add Storage 來新增 iSCSI Target 儲存資源因為此舉有可能會造成您不小心將儲存於 iSCSI Target 內的資料清除 (格式化) 掉。
- 當 Hypervisor 內的 iSCSI Target 資源池恢復存取後即可將虛擬主機 (VM) 開機並確定運作於虛擬主機上的相關服務是否運作正常。
- 至此開機流程完成，高可用性 iSCSI Target 儲存資源恢復運作。
圖6、Hypervisor 偵測到 iSCSI Target 儲存資源失聯的情況
圖7、Hypervisor 偵測到 iSCSI Target 儲存資源失聯導致存取路徑不通
若您將叢集主機開機後仍然發生 iSCSI Target 服務並未自動把相關儲存資源掛載起來的話請您查看 系統記錄檔內容 (/var/log/messages) ，查看記錄檔內容中是否有 「Could not open /storage/iscsi, No such file or directory」 相關訊息，此一錯誤訊息表示系統無法掛載 iSCSI Target 儲存資源導致這個錯誤的原因在於雖然 DRBD (啟動順序 S70)、Heartbeat (啟動順序 S75) 服務的啟動順序早於 /etc/rc.local (啟動順序 S99)，但是因為 DRBD、Heartbeat 服務於啟動之後需要執行一些前置作業 (例如檢查二台叢集主機節點之間區塊裝置 /dev/drbd0 資料是否同步完成) 因此需要花費一些檢查時間，而在此同一時間很有可能會發生 DRBD、Heartbeat 服務還沒啟動完成 (尚未掛載 /dev/drbd0 至 /storage) 的情況下但是系統已經執行 /etc/rc.local 中的內容了，此時就會造成無法掛載 iSCSI Target 儲存資源的情況，在筆者的測試環境中延遲 60 秒的時間便以相當足夠，若在您的環境中系統還是發生來不及掛載 iSCSI Target 儲存資源的問題的話請您查看系統記錄檔內容中的服務啟動訊息來決定在您的環境中到底應該延遲多少時間之後進行調整即可。
如下列系統記錄檔 /var/log/messages 內容中我們可以看到30分58秒時系統已經運作到執行 /etc/rc.local 的內容了，但是此時系統仍然尚未發現 iSCSI Target 儲存資源檔案 (因為尚未掛載 /dev/drbd0 至 /storage，當然無法發現 /storage/iscsi 檔案)，系統一直到 31分10秒時系統才執行掛載 /dev/drbd0 至 /storage 的動作 (此時 DRBD、Heartbeat 服務才整個啟動完成)，所以由記錄檔中我們知道再此環境中至少需要延遲 12 秒以上後再執行 iSCSI Target 儲存資源開機自動掛載 Script (/usr/local/sbin/tgtd_boot.sh)。
Apr 7 17:30:29 node1 tgtd: Target daemon logger with pid=3354 started!
Apr 7 17:30:58 node1 tgtd: backed_file_open(92) Could not open /storage/iscsi, No such file or directory
Apr 7 17:31:10 node1 ResourceManager[4047]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /storage ext3 start
Apr 7 17:31:10 node1 Filesystem[4390]: INFO: Running start for /dev/drbd0 on /storage5、結語
虛擬化趨勢就目前看來已經鋪天蓋地而來勢不可擋了，而虛擬化技術之所以如此熱門其原因在於導入虛擬化解決方案之後對於 IT 管理上有諸多好處例如： 伺服器合併之後高集縮比為企業所帶來的立即效益是減少以往過多設備資源閒置的情況、設備耗費電力降低、設備產生的熱能減少、機房的冷房能力負擔降低、設備佔用機櫃空間減少、網路佈線的環境單純化…等進而減少企業 IT 整體成本，並且當企業需要建置新系統環境、佈署研發測試環境、系統備援環境、系統災難復原環境上都將比以往更能省下內部採購流程時間及佈署系統環境時所花費的人力物力及成本，最後則是虛擬化技術可以在不需要作業系統或應用程式支援的情況下即可為企業服務達成高可用性的目標，並且可以視企業需要隨時進行將虛擬主機進行線上遷移至別台主機以便檢查實體伺服器或進行歲修。然而要建置具備高效率及高穩定性的虛擬化架構通常就必須採用光纖作為傳輸媒介的儲存區域網路 (FC-SAN)，也就是除了高效能的伺服器外通常至少還要採購 FC HBA 卡及 SAN 交換器並配合 SAN 儲存設備，但是如此的高額建置成本對於一般中小企業來說卻是筆沈重的預算且遙不可及的，但是是否就要如此放棄了呢？ 答案是否定的!! 托 IP-SAN 技術的福一般中小企業得以採用花費相對較為便宜的解決方案來為企業導入虛擬化技術。
本文便是採用自由軟體作業系統 CentOS 來架設 IP-SAN 儲存設備，並配合企業內部常見的網路交換器及安裝於伺服器上的一般網路卡來進行資料傳輸，並且採用免費版本的 Hypervisor 來承載虛擬機器提供服務，當然為了確保資料的一致性及高可用性我們也導入了自由軟體中知名的 DRBD 及 Heartbeat 套件來達成這樣的目標，希望能藉由此架構為一般中小企業提供具備資料保全及高穩定性卻又便宜的伺服器合併高集縮比的虛擬化環境解決方案。