為了觀察自己的應用程式能否在容錯移轉叢集的環境中正常運作,便以 Hyper-V 裝了兩個虛擬機器來做點小實驗。
聲明:我是這方面的新手,事前又沒有做太多功課,除了請同事協助提點有關 iSCSI Cake 的部分,其餘大都是上網爬文囫圇吞棗之後亂 try 的。文中的一些見解或使用的方法,不見得全都正確。若有錯誤之處,請多多指正。
前言
這個小實驗的目的在於觀察自己寫的程式能否在容錯移轉叢集的環境中正常運作,而所謂的「正常運作」,指的是當容錯移轉叢集(failover clusters;以前叫做 server clusters)的其中一個節點(機器)掛掉,或者應用程式本身掛掉時,系統會自動切換到另一台機器,由那台機器上的應用程式接著提供對外服務。這當中的換手動作,用戶端並不知情(短暫延遲還是免不了的)。
先說結論吧。底下是自己實驗之後的一點粗淺想法。
從「應用程式需要額外的操作或程式碼」的角度,我是把容錯移轉分成三種層次來看:
注意:這幾種「層級」名稱是我自己取的,有點囉嗦,純粹方便自己理解,不是正統說法。
接著是一點凌亂的筆記,將來也許會再補充修正。目前的話....就先湊和吧!
環境需求
需要的軟體和作業環境有:
在動手建立容錯移轉叢集之前,最好先做點功課,了解 什麼是 iSCSI,以及一些相關的專有名詞,像是叢集仲裁( cluster quorum)、見證磁碟(witness disk)、啟動器(initiator)、目標(target)等等。
建立容錯移轉叢集
安裝和設定的步驟挺多,很多細節我已經忘得差不多了,所以還是直接參考現有的教學文章吧:
將應用程式加入叢集環境
要讓 Windows Service 或一般的 Windows 應用程式運行於容錯移轉叢集環境,有兩個選項:
我還不會寫叢集感知程式,所以這裡只提第一種做法。
設定 Generic Application
這裡有篇圖文並茂的教學文章:Creating and Configuring a Generic Application Resource,只要照著裡面的指示和圖片操作,就能讓你的應用程式在容錯移轉叢集上運行。微軟網站上也有技術文章可以參考,只是沒有圖片而已:Configure a Service or Application for High Availability。
可是,作業系統怎麼知道我們的應用程式掛掉了呢?根據官網的說明:
If you run an application as a Generic Application, the cluster software will start the application, then periodically query the operating system to see whether the application appears to be running. If so, it is presumed to be online, and will not be restarted or failed over.
叢集服務在啟動你的應用程式之後,會定期向作業系統詢問你的應用程式「看起來」是不是還在正常運作。如果是的話,叢集服務就不會嘗試重啟你的應用程式,或者進行容錯移轉。
Generic Service 的運作也是類似上述方式,叢集服務會向 Service Controller 查詢你的 Windows Service 程式是否還正常。
測試容錯移轉
將你的應用程式設定成 Generic Application 之後,當然就要實際測試一下,看看會不會容錯移轉。你可以將其中一台節點關機,看看另一台節點有沒有立刻接手,但這樣太麻煩了。Failover Cluster Manager 有提供測試的功能,讓你可以指定應用程式要由哪個特定節點來執行:在 Failover Cluster Manager 視窗左方的樹狀區域找到並展開你的叢集,在 Services and applicatios 之下會列出所有已設定的應用程式,然後在想要測試的應用程式上面點右鍵,再選擇要移轉到哪個目標節點就行了。參考下圖:
註:上述測試動作並不限定要在哪一台機器上進行,任意一台容錯移轉的節點都可以。
圖中顯示,我加入了兩個應用程式,但其實我是把同一個應用程式複製到不同的資料夾,然後設定成兩個 Generic Application。這是為了想要試試看:讓一個應用程式執行於 node 1,另一個應用程式執行於 node 2 的情況。
我用來測試的應用程式也很簡單,它是個 TCP Socket 應用程式,分為 client 端與 server 端兩個程式。,Server 端程式會監聽指定的 port,然後把用戶端送進來的資料寫入某個 log 檔。藉由觀察兩個節點上的 log 檔案內容,可確認是哪一個節點上的應用程式正在提供服務。
小結
我沒有特別去研究細節,純粹只是為了評估應用程式是否需要這樣的作業環境。結論是:對我們的應用程式來說,網路負載平衡(Network Load Balance;簡稱 NLB)技術可能比容錯移轉叢集更重要。
參考資料
聲明:我是這方面的新手,事前又沒有做太多功課,除了請同事協助提點有關 iSCSI Cake 的部分,其餘大都是上網爬文囫圇吞棗之後亂 try 的。文中的一些見解或使用的方法,不見得全都正確。若有錯誤之處,請多多指正。
前言
這個小實驗的目的在於觀察自己寫的程式能否在容錯移轉叢集的環境中正常運作,而所謂的「正常運作」,指的是當容錯移轉叢集(failover clusters;以前叫做 server clusters)的其中一個節點(機器)掛掉,或者應用程式本身掛掉時,系統會自動切換到另一台機器,由那台機器上的應用程式接著提供對外服務。這當中的換手動作,用戶端並不知情(短暫延遲還是免不了的)。
先說結論吧。底下是自己實驗之後的一點粗淺想法。
從「應用程式需要額外的操作或程式碼」的角度,我是把容錯移轉分成三種層次來看:
- 機器層級的容錯移轉:在 Windows 2008 環境上建立好叢集之後,隸屬同一叢集的節點(機器)就有了容錯移轉的能力。比如說,如果我建了一個叢集,包含兩個節點,分別是 Node1 和 Node2,而且這兩個節點都會綁到同一個對外的 IP 位址(建立叢集的時候會讓你綁 IP)。假設目前提供服務的節點是 Node1,那麼當 Node1 關機之後,Node2 就會接手。由於對外是同一個 IP 位址,用戶端應用程式只要有重新連線的動作(例如開啟一個 TCP Socket 連線),就會被導向至 Node2。當然,如果用戶端應用程式是採用持續連線的方式(一旦建立連線就不斷開),這樣還是不行的,因為實體連線已經在系統關機時結束了。若只需要這種程度的容錯移轉,基本上,應用程式啥都不用做。
- 應用程式層級的容錯移轉:我們可以將寫好的應用程式(或 Windows Service)透過設定的方式(稍後會提)變成一個叢集資源(cluster resource),由叢集服務來監視我們的應用程式是否還「活著」。這種監視是比較粗略的健康偵測,沒辦法做到百分百--本來嘛,你自己健康與否,自己心裡最明白,不是嗎?這種程度的容錯移轉,只需要一些設定的工夫,應用程式無須撰寫額外的 code。而且,你可以透過設定的方式,分別讓 Node1 的 App2 和 Node2 的 App1 分別成為作用中的應用程式(即控制的粒度細到應用程式層級,而非整台機器上的應用程式全部切換到另一台)。
- 更細緻的應用程式層級的容錯移轉:應用程式需要撰寫額外的 code,來跟底層的叢集服務溝通。比如說,你的應用程式可以跟叢集服務說:「我這邊出問題了,請切換到另一台機器,由我在那邊的分身來繼續服務用戶端。」這個部分會比較麻煩一些,可能還需要用到 C/C++(因為要直接呼叫底層的 Failover Cluster API)。這類能夠與叢集服務溝通的應用程式,有個正式名稱,叫做叢集感知(cluster-aware)應用程式。
注意:這幾種「層級」名稱是我自己取的,有點囉嗦,純粹方便自己理解,不是正統說法。
環境需求
需要的軟體和作業環境有:
- Windows Server 2008 Enterprise 版或 Datacenter 版。這兩個版本才有提供容錯移轉叢集的功能;Standard 版沒有。
- Active Directory 伺服器。
- iSCSI 伺服器軟體:這裡用的是免費的 SCSI Cake。
- iSCSI Initiator:Windows Sever 2008 內建功能,可在[程式集>系統管理工具]中找到。
在動手建立容錯移轉叢集之前,最好先做點功課,了解 什麼是 iSCSI,以及一些相關的專有名詞,像是叢集仲裁( cluster quorum)、見證磁碟(witness disk)、啟動器(initiator)、目標(target)等等。
建立容錯移轉叢集
安裝和設定的步驟挺多,很多細節我已經忘得差不多了,所以還是直接參考現有的教學文章吧:
- Using iSCSI Cake with Windows 2008 Cluster - 這是 iSCSI Cake 網站上提供的技術文件,還蠻清楚的,對於容錯移轉叢集的新手來說,會有一些幫助。
- Windows 2008 R2 Failover Clustering 建立初探 - 這篇是用 Microsoft iSCSI Software Target,而不是 iSCSI Cake。
容錯移轉叢集建立好之後,接著要試試看如何讓應用程式跑在叢集環境上。
要讓 Windows Service 或一般的 Windows 應用程式運行於容錯移轉叢集環境,有兩個選項:
- 將應用程式設定成 Generic Service 或 Generic Application。
- 應用程式要撰寫叢集感知(cluster-aware)的程式碼。
我還不會寫叢集感知程式,所以這裡只提第一種做法。
設定 Generic Application
這裡有篇圖文並茂的教學文章:Creating and Configuring a Generic Application Resource,只要照著裡面的指示和圖片操作,就能讓你的應用程式在容錯移轉叢集上運行。微軟網站上也有技術文章可以參考,只是沒有圖片而已:Configure a Service or Application for High Availability。
可是,作業系統怎麼知道我們的應用程式掛掉了呢?根據官網的說明:
If you run an application as a Generic Application, the cluster software will start the application, then periodically query the operating system to see whether the application appears to be running. If so, it is presumed to be online, and will not be restarted or failed over.
叢集服務在啟動你的應用程式之後,會定期向作業系統詢問你的應用程式「看起來」是不是還在正常運作。如果是的話,叢集服務就不會嘗試重啟你的應用程式,或者進行容錯移轉。
Generic Service 的運作也是類似上述方式,叢集服務會向 Service Controller 查詢你的 Windows Service 程式是否還正常。
測試容錯移轉
將你的應用程式設定成 Generic Application 之後,當然就要實際測試一下,看看會不會容錯移轉。你可以將其中一台節點關機,看看另一台節點有沒有立刻接手,但這樣太麻煩了。Failover Cluster Manager 有提供測試的功能,讓你可以指定應用程式要由哪個特定節點來執行:在 Failover Cluster Manager 視窗左方的樹狀區域找到並展開你的叢集,在 Services and applicatios 之下會列出所有已設定的應用程式,然後在想要測試的應用程式上面點右鍵,再選擇要移轉到哪個目標節點就行了。參考下圖:
註:上述測試動作並不限定要在哪一台機器上進行,任意一台容錯移轉的節點都可以。
圖中顯示,我加入了兩個應用程式,但其實我是把同一個應用程式複製到不同的資料夾,然後設定成兩個 Generic Application。這是為了想要試試看:讓一個應用程式執行於 node 1,另一個應用程式執行於 node 2 的情況。
我用來測試的應用程式也很簡單,它是個 TCP Socket 應用程式,分為 client 端與 server 端兩個程式。,Server 端程式會監聽指定的 port,然後把用戶端送進來的資料寫入某個 log 檔。藉由觀察兩個節點上的 log 檔案內容,可確認是哪一個節點上的應用程式正在提供服務。
小結
我沒有特別去研究細節,純粹只是為了評估應用程式是否需要這樣的作業環境。結論是:對我們的應用程式來說,網路負載平衡(Network Load Balance;簡稱 NLB)技術可能比容錯移轉叢集更重要。
參考資料
沒有留言: