網管人雜誌
本文刊載於 網管人雜誌第 66 期 - 2011 年 7 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
1、DRBD 運作原理說明叢集主機修改 DRBD 設定檔
初始化 Node1 叢集主機的 sdb 硬碟資料 (僅 Node1 設定)
格式化 sdb 磁碟資料 (僅 Node1 設定)
啟動 iSCSi Target 服務並測試資料寫入 (僅 Node1 設定)
2、Heartbeat 技術運作原理
設定 Heartbeat 通訊設定檔
設定 Heartbeat 資源設定檔
設定 Heartbeat 驗證設定檔
設定 Heartbeat 監控服務設定檔
新增 Heartbeat 為系統服務
3、開機自動掛載iSCSI Target資源 (僅 Node1 設定)
4、結語
1、DRBD 運作原理說明
DRBD (Distributed Replicated Block Device) 技術其設計概念，為採用即時同步二端主機間「區塊裝置 (Block Device)」 資料內容的資料保全解決方案，簡言之您可以把 DRBD 技術理解為二端主機中硬碟的鏡像同步技術 (RAID-1) ，只是其資料同步的技術是透過乙太網路進行交換而非儲存設備控制器所以稱為網路鏡像同步技術 (Network RAID-1) 將更為貼切。如下 DRBD 運作架構圖中我們可以看到二台主機透過 DRBD 技術所建構的資料保全解決方案中每台主機包含了 Linux 核心 (Kernel)、檔案系統 (File System)、緩衝區快取 (Buffer Cache)、磁碟讀寫調度器 (Disk Scheduler)、磁碟驅動程序 (Disk Driver)、實體網路卡及TCP/IP 協定，其中透過箭頭方向可以清楚了解到 DRBD 技術是如何透過網路傳輸進而同步二台主機之間區塊裝置 (硬碟) 內的資料。
圖片來源： DRBD 官網 - What is DRBD
圖 1、DRBD 技術運作示意圖
叢集主機修改 DRBD 設定檔
安裝相關套件完畢後首先請修改 DRBD 設定檔 (/etc/drbd.conf)，此次實作採用的 CentOS 為 32 位元版本因此設定檔中指定的 heartbeat 執行檔資料夾其路徑為 /usr/lib/heartbeat，若您採用的 CentOS 為 64 位元版本則 heartbeat 執行檔資料夾的路徑為 /usr/lib64/heartbeat，請注意若 DRBD 設定檔內容中 heartbeat 執行檔資料夾路徑指定錯誤，則屆時將造成因為叢集服務找不到相對應的執行檔而造成叢集運作失效的狀況發生，下列修改 DRBD 設定檔內容叢集主機 Node1、Node2 都相同。# vi /etc/drbd.conf
global {
minor-count 64;
usage-count yes;
}
common {
syncer { rate 1000M; }
}
resource ha {
protocol C;
handlers {
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
local-io-error "/usr/lib/drbd/notify-local-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
fence-peer "/usr/lib/heartbeat/drbd-peer-outdater -t 5";
pri-lost "/usr/lib/drbd/notify-pri-lost.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
}
startup {
wfc-timeout 60;
degr-wfc-timeout 120;
outdated-wfc-timeout 2;
}
disk {
on-io-error detach;
fencing resource-only;
}
syncer {
rate 1000M; //資料同步速率
}
on node1.weithenn.org { //Node 1 主機資訊
device /dev/drbd0;
disk /dev/sdb1; //同步的 Block 裝置代號
address 192.168.1.1:7788; //Node 1 主機 Heartbeat IP 位址
meta-disk internal;
}
on node2.weithenn.org { //Node 2 主機資訊
device /dev/drbd0;
disk /dev/sdb1; //同步的 Block 裝置代號
address 192.168.1.2:7788; //Node 2 主機 Heartbeat IP 位址
meta-disk internal;
}
}DRBD 設定檔修改完成後請調整 DRBD 相關執行檔案的權限以便後續步驟在建立 DRBD 資源時執行的指令能夠順利執行而不致發生錯誤，請注意若此調整 DRBD 檔案權限的步驟省略的話後續操作過程將會出現錯誤，此一調整檔案權限的動作叢集主機 Node1、Node2 都必須調整。
# chgrp haclient /sbin/drbdsetup
# chmod o-x /sbin/drbdsetup
# chmod u+s /sbin/drbdsetup
# chgrp haclient /sbin/drbdmeta
# chmod o-x /sbin/drbdmeta
# chmod u+s /sbin/drbdmeta檔案權限調整完畢後接著使用 modprobe 指令來載入 DRBD 模組至作業系統中並配合 lsmod 指令來檢查模組是否載入完成，待確認載入 DRBD 模組的動作完成後我們必須先執行 dd 指令將一些資料寫入到 sdb 硬碟內否則後續要執行 drbdadm 指令建立 DRBD 資源時會發生錯誤訊息並且無法繼續後續的操作步驟，請執行指令 drbdadm create-md 來建立 DRBD 資源由於我們在 DRBD 設定檔中指定其資源名稱為 ha 所以此處指令參數便輸入 ha，下列執行指令建立 DRBD 資源的動作叢集主機 Node1、Node2 都必須執行。
# modprobe drbd //載入 drbd 模組
# lsmod|grep drbd //確認 drbd 模組是否載入
drbd 228528 0
# dd if=/dev/zero of=/dev/sdb1 bs=1M count=100 //塞資料到 sdb 內
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.918917 seconds, 114 MB/s
# drbdadm create-md ha //建立 drbd 資源
--== Thank you for participating in the global usage survey ==--
The server's response is:
you are the 8529th user to install this version
Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.
success當 Node1及 Node2 叢集主機都完成 DRBD 資源建立後便可以準備啟動 DRBD 服務，當啟動 DRBD 服務時請先於 Node1 主機啟動 DRBD 服務此時 DRBD 服務會進入 60 秒讀秒倒數等待 (等待在 DRBD 設定檔中另一台叢集主機)，此時再切換至 Node2 主機啟動 DRBD 服務若二台節點 主機設定正確無誤便皆可順利啟動 DRBD 服務，完成啟動 DRBD 服務後請記得設定 DRBD 服務於開機時自動啟動。
# service drbd start //啟動 drbd 服務
Starting DRBD resources: [
ha
Found valid meta data in the expected location, 10733953024 bytes into /dev/sdb1.
d(ha) s(ha) n(ha) ]... //Node1 先啟動，會等待，此時 Node2 再啟動
# chkconfig drbd on //設定 drbd 開機時自動啟動啟動 DRBD 服務完成後可以分別至 Node1、Node2 主機查看目前 DRBD 的運作狀態，若上述動作您未同時在二台節點主機啟動服務而是當 Node1 主機啟動 DRBD 服務而 Node2 未啟動服務，則當 Node1 主機讀秒倒數完畢 (timeout) 時會發現其 DRBD 狀態為 Secondary/Unknown，必須要等到 Node2 主機啟動 DRBD 服務後狀態才會轉變為 Secondary/Secondary，其中 ds 欄位狀態資訊為 Inconsistent 表示二台叢集主機區塊裝置 (/dev/drbd0) 資料尚未進行同步。
# service drbd status
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 Secondary/Secondary Inconsistent/Inconsistent C 初始化 Node1 叢集主機的 sdb 硬碟資料 (僅 Node1 設定)
當確定 Node1 及 Node2 主機都可以互相偵測到對方主機存在 (Secondary/Secondary) 後，我們便可以執行 drbdadm 指令配合 primary 參數來把 Node1 主機提升為 Primary Node (屆時的 Active Node) 並啟動二台叢集主機開始同步 sdb 硬碟資料 (也就是 /dev/drbd0)，當執行同步資料的動作開始後您可以透過指令 watch -n 1 service drbd status 來即時查看 DRBD 運作狀態了解二台主機同步硬碟資料的百分比及進度，請注意!! 此一執行 drbdadm 指令的操作動作僅於 Node1 主機執行即可不需要於 Node2 主機執行 (也就是 Node2 主機的區塊資料及同步的來源為 Node1 主機)。# drbdadm -- --overwrite-data-of-peer primary ha //開始同步二台主機 sdb 硬碟
# watch -n 1 service drbd status //查看同步資料百分比及進度 (每秒更新)
Every 1.0s: service drbd status
Wed Apr 6 15:30:25 2011
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
... sync'ed: 6.2% (9612/10236)M delay_probe:
0:ha SyncSource Primary/Secondary UpToDate/Inconsistent C當二台叢集主機同步作業完成後此時再度查看 DRBD 狀態，可以發現二台主機的 ds 欄位狀態資訊已經由原本的 Inconsistent 轉變為 UpToDate，此狀態資訊即表示二台叢集主機之間的區塊裝置其資料已經同步完成二台叢集主機擁有相同且最新的資料。此時在 Node1 主機所看到 DRBD 狀態可以知道目前 Node1 主機為 Primary Node (也就是 Active Node)，在 Node2 主機看到的狀態為 Secondary Node (也就是 Standby Node)。
[root@node1 ~]# service drbd status //Node1 主機 (Primary 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
[root@node2 ~]# service drbd status //Node2 主機 (Secondary 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 Secondary/Primary UpToDate/UpToDate C格式化 sdb 磁碟資料 (僅 Node1 設定)
Node1 及 Node2 二台主機之間完成資料同步作業後 (即 /dev/drbd0 已經完成初始化)，接著便可以使用指令 mkfs.ext3 指令來格式化 /dev/drbd0 區塊裝置，待格式化動作完成後請於根目錄 (/) 下建立 storage 資料夾並將 /dev/drbd0 裝置掛載至剛才建立的 /storage 資料夾，並且於掛載後使用指令 df 來確保系統是否掛載成功，請注意!! mkfs.ext3 格式化指令僅於 Node1 主機執行即可不需要於 Node2 主機執行 (因為二台叢集主機區塊裝置已經同步完成，因此一台主機執行格化即可)。# mkfs.ext3 /dev/drbd0 //格式化 drbd0
# mkdir /storage //於根目錄下建立 storage 資料夾
# mount /dev/drbd0 /storage //掛載 drbd0 至 storage 資料夾
# df -h //查看系統掛載點資訊
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
5.8G 3.0G 2.5G 55% /
/dev/sda1 99M 16M 79M 17% /boot
tmpfs 1014M 0 1014M 0% /dev/shm
/dev/drbd0 9.9G 151M 9.2G 2% /storage啟動 iSCSi Target 服務並測試資料寫入 (僅 Node1 設定)
作業系統掛載 /dev/drbd0 裝置完成後便可以啟動 iSCSI Target 服務並於啟動服務完成後檢查系統是否有正確開啟相關的服務 Port 3260，並且記得設定系統開機後自動啟動 iSCSI Target 服務，接著使用 dd 指令來建立指定大小 9GB 的檔案於 /storage 資料夾內，此檔案也就是屆時 iSCSI Initiator (VMware vSphere Hypervisor) 所要掛載的共用儲存空間 Datastore，您或許會疑惑為何不直接使用 /storage 這個掛載點來擔任共用儲存空間就好了？ 因為此次實作為採用軟體式的 iSCSI Target 若直接使用該分割區擔任共用儲存空間則屆時當 iSCSI Initiator 欲掛載該儲存空間時將會發生掛載失敗的現象，請注意!! 啟動 iSCSI Target 服務及 dd 指令僅於 Node1 主機執行即可不需於 Node2 主機執行。# service tgtd start //啟動 iSCSI Target 服務
Starting SCSI target daemon: Starting target framework daemon
# chkconfig tgtd on //設定開機自動啟動 iSCSI Target 服務
# netstat -tnulp |grep tgtd //檢查系統是否開啟 iSCSI Target 服務 Port
tcp 0 0 0.0.0.0:3260 0.0.0.0:* LISTEN 5795/tgtd
tcp 0 0 :::3260 :::* LISTEN 5795/tgtd
# dd if=/dev/zero of=/storage/iscsi bs=1M count=9216 //建立 9GB 的檔案
9216+0 records in
9216+0 records out
9663676416 bytes (9.7 GB) copied, 562.398 seconds, 17.2 MB/s接著建立 iSCSI Target 儲存資源的 iSCSI 認證名稱 (iSCSI Qualifier Name，IQN) 及指定使用剛才建立的 9GB 大小作為其儲存空間，最後則是設定 ACL 存取限制清單只允許 10.10.25.x網段的主機才可以掛載這個 iSCSI Target 所分享的共用儲存資源 (當然也指定允許單一 IP 位址或是網域名稱)，其中 iSCSI 認證名稱為 iSCSI Initiator 與 iSCSI Target用來互相識別之用，即屆時iSCSI Initiator 前端設備發起存取儲存資源的要求時 iSCSI Target 便能依照相關設定回應其存取要求，而 IQN 名稱的命名格式為 「iqn + 日期 + 反向網域名稱 + 主機名稱」 此次實作的 IQN 名稱為 iqn.2011-03.org.weithenn:iscsi.storage，請注意!! 啟動建立 iSCSI Target 儲存資源的指令僅於 Node1 主機上執行即可不需於 Node2 主機執行。
# tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2011-03.org.weithenn:iscsi.storage //建立 IQN 名稱
# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /storage/iscsi //指定儲存空間為檔案
# tgtadm --lld iscsi --op bind --mode target --tid 1 -I 10.10.25.0/24 //指定可存取資源的網段
# 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:
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/24當確定 iSCSI Target (tgtd) 服務可以將 /storage/iscsi 檔案順利掛載為儲存資源後，便可以準備設定高可用性服務 Heartbeat 部份但請在設定以前先將 Node1 主機中 iSCSI Target 服務停止並把 /dev/drbd0 區塊裝置進行卸載的動作，並且把 Node1 主機先行降級為 Secondary Node 以避免設定高可用性服務過程中受到影響，請注意!! 此動作僅於 Node1 主機執行即可不需於 Node2 主機執行。
# service tgtd stop //停止 iSCSI Target 服務
Stopping SCSI target daemon: Stopping target framework daemon [ OK ]
# umount /dev/drbd0 //卸載 drbd0
# drbdadm secondary ha //將 Node1 主機降為 Secondary Node
# service drbd status //確認二台主機都為 Secondary 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 Secondary/Secondary UpToDate/UpToDate C2、Heartbeat 技術運作原理
高可用性的容錯機制 「錯誤後轉移 (Failover)」 通常有三種方式分別是 動態 DNS、IP 位址接管、MAC 位址接管，其中動態 DNS 為透過更新 DNS 設定將網域名稱所對應的 IP 位址指向備援的節點主機達到容錯機制，而 MAC 位址接管則為當主要節點主機發生問題時備援節點主機將本身的 MAC 位址修改為原先的 ARP 快取所記載的主要節點主機 MAC 位址達到容錯機制。此次高可用性服務實作所採用的容錯技術為第二種也就是 「IP 位址接管」的方式來達成，即叢集主機中 Active Node 將會產生一組虛擬叢集 IP 位址 (Cluster IP Address) 來提供服務，當 Client 端送出存取服務要求時擁有虛擬叢集 IP 的 Primary Node (Active Node) 便會回應 Client 端的回應(如運作圖中上半部圖)，而當 Primary Node 出現問題時運作於其上的 Heartbeat 服務便會自動將服務切換至 Secondary Node (Standby Node) 此時它便會擁有虛擬叢集 IP 位址同時修改 ARP Cache 內該虛擬叢集 IP 位址所對應的 MAC 位址進而順暢無誤的接手後續 Client 端相關服務 (如運作圖中下半部圖)
若您希望具備「錯誤後回復 (Failback)」機制，也就是當 Primary Node 出現問題時將服務自動轉移給 Secondary Node，但是當 Primary Node 排除錯誤並修復完成後重新回到叢集網路時便又自動地將主動權再度搶回的機制，此次採用的 Heartbeat 高可用性套件也具備此一機制，但是這樣的錯誤後回復機制到底好不好其實見人見智以筆者來說便不建議如此設定，其原因在於這樣的錯誤後回復機制有可能會造成「叢集節點抖動」？
怎麼說呢 例如當 Primary Node 伺服器所處的電力迴路不穩定時便可能造成這樣的狀況，當電力迴路供電不穩定時 Heartbeat 將服務自動切換給 Secondary Node 進行服務接手的動作，待電力恢復穩定後 Primary Node 此時又將主動權搶回並且當電力再度不穩定時又再次將服務切換給 Secondary Node 接手，雖然切換叢集主機節點之間所耗費的時間並不長，但是若造成高頻率的叢集節點抖動切換對於使用者來說仍會感覺到服務不順暢，因此筆者會建議您不要設定錯誤後回復機制而是設定當錯誤後轉移的狀況發生時系統自動切換服務並且通知管理者，待管理者了解叢集主機切換的原因並排除後再評估是否要讓 Primary Node 搶回主控權。
圖片來源： DRBD 官網 - What is HA
圖2、Heartbeat 技術運作示意圖
設定 Heartbeat 通訊設定檔
此次實作的 Heartbeat 通訊設定檔 (/etc/ha.d/ha.cf) 內容中設定每 2 秒鐘叢集主機便會透過 Heartbeat 線路 (bond1) 使用 ICMP 協定中的 Ping 來互相偵測對方是否仍然存活，當超過 5 秒鐘仍然無法偵測到對方主機存活時則會將警告訊息寫入指定的記錄檔中 (/var/log/ha-log)，當超過 15 秒鐘後仍然無法偵測對方主機存活時則判定為對方主機失效系統將會觸發錯誤後轉移機制 (Failover) Secondary Node 將準備接手相關服務及儲存資源。當發生叢集節點主機無法偵測對方主機是否存活時會先執行 Ping 指定的 IP 位址例如此次實作中採用的 Gateway IP 位址 (10.10.25.254)，這樣的機制是防止叢集主機之間的 Heartbeat 線路若發生中斷的情況時造成二台節點主機都以為對方主機失效爭相要接手為 Active Node 進而造成裂腦 (Split-Brain) 的情況發生，設定檔中最後一行 auto_failback off 則是設定不啟用錯誤後回復機制 (Failback)。
Node1 及 Node2 主機在通訊設定檔中內容不同處僅為 ucast 所指定的 IP 位址其餘都相同，並且要注意的是 Node1 主機指定的 bond0、bond1 IP 位址為 Node2 主機的 IP 位址而非自已主機上的 bond0、bond1 IP 位址 (因為這裡的 IP 位址為用來偵測對方主機是否存活之用)。
叢集主機 Node1 設定
- ucast bond0 IP 位址：10.10.25.138
- ucast bond1 IP 位址：192.168.1.2
叢集主機 Node2 設定
- ucast bond0 IP 位址：10.10.25.137
- ucast bond1 IP 位址：192.168.1.1
# vi /etc/ha.d/ha.cf
debugfile /var/log/ha-debug //heartbeat 除錯記錄檔
logfile /var/log/ha-log //heartbeat 記錄檔
logfacility local0 //記錄檔的記錄等級
autojoin none
ucast bond0 10.10.25.138 //指定 Node2 主機的 IP (Node1 主機設定)
ucast bond1 192.168.1.2 //指定 Node2 主機的 IP (Node1 主機設定)
ping 10.10.25.254 //當網路或 Heartbeat 失效時測試連線狀態用
respawn hacluster /usr/lib/heartbeat/ipfail
respawn hacluster /usr/lib/heartbeat/dopd
apiauth dopd gid=haclient uid=hacluster
udpport 694 //使用 UDP Protocol 及 694 Port 來通訊
warntime 5 //網路斷線時告警時間 5 秒
deadtime 15 //網路斷線發生 15 秒後判定網路出問題
initdead 60
keepalive 2 //每 2 秒 Node 主機互相偵測對方
node node1.weithenn.org
node node2.weithenn.org
auto_failback off //Active Node 不會搶回主控權設定 Heartbeat 資源設定檔
接下來為設定 Heartbeat 資源設定檔 (/etc/ha.d/haresources)，此資源設定檔內容於 Node1 及 Node2 主機中皆一模一樣，此一資源設定檔內容表示 Heartbeat 服務預設將使用 Node1 主機擔任 Primary Node 角色，此設定檔內容可以分為五個區段來看其意義如下：- 指定 Primary Node 的 FQDN： node1.weithenn.org
- 指定虛擬叢集 IP 位址 (Cluster IP)： 10.10.25.136
- 指定叢集資源名稱 (Cluster Resource Name)： drbddisk::ha
- 指定叢集裝置 (Cluster Device)、掛載點 (Mount Point)、檔案系統格式(File System Type)： Filesystem::/dev/drbd0::/storage::ext3
- 指定高可用性服務名稱 (Heartbeat Service)： iscsi-target
此次實作的 Heartbeat 資源設定檔內容如下：
# vi /etc/ha.d/haresources
node1.weithenn.org 10.10.25.136 drbddisk::ha Filesystem::/dev/drbd0::/storage::ext3 iscsi-target設定 Heartbeat 驗證設定檔
此 Heartbeat 驗證設定檔 (/etc/ha.d/authkeys) 為叢集主機節點 (Cluster Node) 之間的驗證密碼檔案，也就是叢集主機節點都必須具備此一驗證密碼檔才會被認為是身處於同一個叢集中的節點，此次實作中採用 sha1 編碼方式並配合 urandom 指令將一堆亂數寫入 Heartbeat 驗證設定檔內當作叢集驗證密碼，最後記得將此驗證設定檔設定權限為 600 (只能 root 能讀寫) 否則屆時 Heartbeat 服務將因為此驗證設定檔安全性不足而啟動失敗，此驗證設定檔內容於 Node1 及 Node2 主機中皆一模一樣，您可在 Node1 主機執行完成後利用 scp 指令將此驗證設定檔複製到 Node2 主機中以便保持密碼檔案及權限設定一致。# ( echo -ne "auth 1\n1 sha1 "; dd if=/dev/urandom bs=512 count=1 | openssl md5) > /etc/ha.d/authkeys
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000222366 seconds, 2.3 MB/s
# cat /etc/ha.d/authkeys //查看 Heartbeat 驗證設定檔內容
auth 1
1 sha1 71461fc5e160d7846c2f4b524f952128
# chmod 600 /etc/ha.d/authkeys //變更 Heartbeat 驗證設定檔權限
# scp /etc/ha.d/authkeys node2:/etc/ha.d/ //複製 Heartbeat 驗證設定檔至 Node2 主機設定 Heartbeat 監控服務設定檔
因為預設的 Heartbeat 服務設定檔中並沒有給 iSCSI Target 服務用的範例設定檔，因此我們只好自行編寫此監控服務設定檔 (/etc/ha.d/resource.d/iscsi-target)，此監控服務設定檔為屆時當 Primary Node 發生問題而 Secondary Node 欲接手相關服務時 Heartbeat 服務便是依據此監控服務設定檔內容決定要在 Secondary Node 啟動什麼服務進而接手哪個虛擬叢集 IP 位址、掛載哪些叢集資源及裝置，設定完此監控服務設定檔後記得給予 755 的權限以便 Heartbeat 服務能夠執行該啟動服務檔案，此監控服務設定檔內容於 Node1 及 Node2 主機中皆一模一樣，您可以在 Node1 主機執行完成後利用 scp 指令將此驗證設定檔複製到 Node2 主機中以便保持監控服務設定檔及權限設定一致，下列為監控服務設定檔內容：# cat /etc/ha.d/resource.d/iscsi-target //監控服務設定檔內容
#!/bin/bash
. /etc/ha.d/shellfuncs
case "$1" in
start)
res=`/etc/init.d/tgtd start`
ret=$?
ha_log $res
/usr/local/sbin/tgtd.sh
exit $ret
;;
stop)
res=`/etc/init.d/tgtd forcedstop`
ret=$?
ha_log $res
rm -rf /var/lock/subsys/tgtd
exit $ret
;;
status)
if [[ `ps -ef | grep '[t]gtd'` > 1 ]]; then
echo "running"
else
echo "stopped"
fi
;;
*)
echo "Usage: tgtd {start|stop|status}"
exit 1
;;
esac
exit 0
# chmod 755 /etc/ha.d/resource.d/iscsi-target //變更檔案權限
# cd /etc/ha.d/resource.d //切換路徑
# scp iscsi-target node2:/etc/ha.d/resource.d //複製 Heartbeat 設定檔至 Node2 主機由於單單啟動 iSCSI Target 服務並不會將相關設定載入例如 設定 IQN 名稱、掛載 /storage/iscsi、設定 ACL 存取清單，因此為了配合上面的 Heartbeat 監控服務設定檔在 Secondary Node 接手服務後能自動掛載 iSCSI Target 儲存資源，我們將相關掛載 iSCSI Target 的動作撰寫為 Script (/usr/local/sbin/tgtd.sh) 來自動化執行，此掛載 iSCSI Target資源設定檔內容於 Node1 及 Node2 主機中皆一模一樣，您可以在 Node1 主機上執行完成後利用 scp 指令將此設定檔複製到 Node2 主機，當然在傳送檔案以前別忘了設定檔案權限為 755 後再進行傳送的動作，建立的 Script 檔案內容如下：
# vi /usr/local/sbin/tgtd.sh //編寫掛載 iSCSI Target 資源
#!/bin/sh
tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2011-03.org.weithenn:iscsi.storage
tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /storage/iscsi
tgtadm --lld iscsi --op bind --mode target --tid 1 -I 10.10.25.0/24
# chmod 755 /usr/local/sbin/tgtd.sh //變更檔案權限
# cd /usr/local/sbin //切換路徑
# scp tgtd.sh node2:/usr/local/sbin //複製 iSCSI Target 設定檔至 Node2 主機新增 Heartbeat 為系統服務
接下來是將 Heartbeat 服務新增至系統服務中除了日後便於管理之外也將於系統開機時自動啟動 Heartbeat 服務，請注意 Heartbeat 服務必須要比 DRBD 服務還要慢啟動才行否則系統在啟動過程中會因為 DRBD 服務尚未啟動 (/dev/drbd0 尚未掛載) 進而造成 Heartbeat 服務啟動失敗系統因而產生錯誤，此新增 Heartbeat 為系統服務的動作在 Node1 及 Node2 主機都必須執行，新增為系統服務後記得於 Node1 及 Node2 主機啟動 Hertbeat 服務。# chkconfig --add heartbeat //新增 Heartbeat 至系統服務
# ll /etc/rc{3,5}.d/S7* //查看 Runlevel 3,5 的系統服務
lrwxrwxrwx 1 root root 14 Apr 6 15:28 /etc/rc3.d/S70drbd -> ../init.d/drbd
lrwxrwxrwx 1 root root 19 Apr 6 16:24 /etc/rc3.d/S75heartbeat -> ../init.d/heartbeat
lrwxrwxrwx 1 root root 14 Apr 6 15:28 /etc/rc5.d/S70drbd -> ../init.d/drbd
lrwxrwxrwx 1 root root 19 Apr 6 16:24 /etc/rc5.d/S75heartbeat -> ../init.d/heartbeat
# chkconfig heartbeat on //開機自動啟動 Heartbeat 服務
# service heartbeat start //啟動 Heartbeat 服務
Starting High-Availability services:
2011/04/06_16:27:22 INFO: Resource is stopped [ OK ]3、開機自動掛載 iSCSI Target 資源 (僅 Node1 設定)
因為 iSCSI Target 儲存設定在預設情況下重新開機後相關設定便會消失不見，所以我們要把 iSCSI Target 儲存資源的的設定檔 (/usr/local/sbin/tgtd_boot.sh) 寫在 /etc/rc.local 內以便系統開機時會順便幫我們將 iSCSI Target 儲存資源掛載完成，但是此 Script 檔案與先前所撰寫的 /usr/local/sbin/tgtd.sh 執行檔內容有點小小不同的地方在於必須要延遲 60 秒左右後再執行設定掛載 iSCSI Target 儲存資源的動作，請注意!! 此一開機用的執行檔僅在 Node1 主機上設定即可 Node2 主機不需設定，此執行檔內容如下：# vi /usr/local/sbin/tgtd_boot.sh //編寫開機掛載 iSCSI Target 資源
#!/bin/sh
sleep 60
tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2011-03.org.weithenn:iscsi.storage
tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /storage/iscsi
tgtadm --lld iscsi --op bind --mode target --tid 1 -I 10.10.25.0/24
# chmod 755 /usr/local/sbin/tgtd_boot.sh //變更檔案權限
# echo "/usr/local/sbin/tgtd_boot.sh" >> /etc/rc.local //開機執行此 Script4、結語
本文中我們已經設定好屆時 iSCSI Target 的儲存資料透過網路鏡像同步技術 (Network RAID-1) 也就是資料保全解決方案 DRBD，即時地將儲存資料進行同步以達到資料保全的目的，並且設定高可用性容錯機制「錯誤後轉移 (Failover)」中的 IP 位址接管技術套用於屆時的 iSCSI 高可用性服務上，並且設定當叢集主機需要硬體檢休或歲休而需要關機時能夠在開機時自動掛載 iSCSI Target 相關資源並自動運作起來。至此 iSCSI Target 的設定已經完成並且正常運作，在下篇文章中我們將實作 iSCSI Initiator 主機如何存取 iSCSI Target 所分享的儲存資源，並且在 iSCSI 高可用性服務上線之前進行相關的災難演練測試以便屆時災難真的發生時不致手忙腳亂，也可以藉著災難演練時建立企業的相關災難回復 SOP， 同時當遇到特殊情況需要將二台叢集主機都關機時 (例如更換機房) 的情況下，叢集主機如何的正確關機及開機以確定叢集服務運作無誤其標準作業流程在下篇文章中也將詳細討論到此細節。
