簡介 在任何情況下
僅僅交付一個具有豐富功能集的高質量應用程序是不夠的
在越來越多的時候
它還必須滿足高可用性標准
您是否因為群集技術看起來過於高深
難於理解和使用而沒有使應用程序再提高一個層次？ 隨著 Microsoft 的群集服務在 Windows NT?
中引入以及在 Windows Server
系列中正式提供
開發人員可使用一些簡單工具在群集環境中部署應用程序
這些工具能夠將群集中的應用程序登記為一般應用程序
並且能夠通過編寫 Windows 腳本的方式來控制應用程序的配置
群集將兩個或多個服務器連接在一起
使其對客戶端呈現為單個計算機
在一個群集中連接服務器可以分擔工作負載
實現單點操作/管理
並為滿足增長的需求進行相應的調整提供了一種途徑
因此
通過群集可以產生具有高可用性的應用程序
本文著重介紹三種支持群集的 Microsoft 服務器技術之一
群集服務
我們將說明如何在群集環境中對應用程序輕松執行性能檢查
而無需更改應用程序代碼
三種群集技術 Microsoft 服務器提供了三種支持群集的技術
網絡負載平衡 (NLB)
組件負載平衡 (CLB) 和 Microsoft 群集服務 (MSCS)
網絡負載平衡
網絡負載平衡充當前端群集
用於在整個服務器群集中分配傳入的 IP 流量
是為電子商務 Web 站點實現增量可伸縮性和出色可用性的理想選擇
最多可以將
個運行 Windows Server
系列產品的計算機連接在一起共享一個虛擬 IP 地址
NLB 通過在群集內的多個服務器之間分配其客戶端請求來增強可伸縮性
隨著流量的增加
可以向群集添加更多的服務器
任何一個群集最多可容納
個服務器
NLB 在為用戶提供連續服務的同時還提供了高可用性
即自動檢測服務器故障
並在
秒內在其余服務器中重新分配客戶端流量
組件負載平衡
組件負載平衡可以在多個運行站點業務邏輯的服務器之間分配負載
它在最多包含八個等同服務器的服務器群集中實現了 COM+ 組件的動態平衡
在 CLB 中
COM+ 組件位於單獨的 COM+ 群集中的服務器上
激活 COM+ 組件的調用是平衡到 COM+ 群集中的不同服務器的負載
CLB 通過作用於多層群集網絡的中間層與 NLB 和群集服務配合工作
CLB 是作為 Application Center
的特性提供的
可與 Microsoft 群集服務在同一組計算機上運行
群集服務 群集服務充當後端群集
可為數據庫
消息傳遞以及文件和打印服務等應用程序提供高可用性
當任一節點（群集中的服務器）發生故障或脫機時
MSCS 將嘗試最大程度地減少故障對系統的影響
圖 三種支持群集的 Microsoft 服務器技術 通過 Microsoft 群集服務實現故障轉移 MSCS 故障轉移功能是通過群集中連接的多個計算機中的冗余實現的
每台計算機都具有獨立的故障狀態
為了實現冗余
需要在群集中的多個服務器上安裝應用程序
但在任一時刻
應用程序只在一個節點上處於聯機狀態
當該應用程序出現故障或該服務器停機時
此應用程序將在另一個節點上重新啟動
Windows Server
數據中心版支持在一個群集中最多包含
個節點
每個節點都具有自己的內存
系統磁盤
操作系統和群集資源的子集
如果某一節點出現故障
另一個節點將接管故障節點的資源（此過程稱為
故障轉移
）
然後
Microsoft 群集服務將在新節點上注冊資源的網絡地址
以便將客戶端流量路由至當前擁有該資源的可用系統
當故障資源恢復聯機狀態時
MSCS 可配置為適當地重新分配資源和客戶端請求（此過程稱為
故障恢復
）
要使應用程序恢復到發生故障轉移時的那一點
節點必須能夠訪問保持應用程序狀態的共享存儲區
請注意
Microsoft 群集服務旨在提供高可用性
而不是真正的容錯功能
容錯
一詞通常用於描述提供更高級別恢復功能的技術
容錯服務器通常使用結合了特定軟件的高級硬件或數據冗余
提供從單個硬件或軟件故障近乎瞬時的恢復
這類解決方案的成本遠遠高於群集解決方案
因為您必須購買冗余硬件
而冗余硬件只不過閒置在那裡用於故障恢復
Microsoft 群集服務使用價格適宜的標准硬件提供出色的高可用性解決方案
同時最大程度地利用計算資源
Microsoft 群集服務基於無共享的群集模型
無共享模型規定
雖然群集中有多個節點可以訪問設備或資源
但該資源在一個時刻只能由一個系統占有和管理
（在 MSCS 群集中
資源是指任何可以聯機或脫機
可在群集中進行管理
一個時刻只能以一個節點作為宿主並可以在節點之間移動的物理組件或邏輯組件
）
圖 Microsoft 群集服務 群集服務結構
Microsoft 群集服務由三個主要組件構成
群集服務
資源監視器和資源 DLL
此外
還可以利用群集管理器創建提供管理功能的擴展 DLL
群集服務
群集服務是核心組件
並作為高優先級的系統服務運行
群集服務控制群集活動並執行如下任務
協調事件通知
加速群集組件之間的通信
處理故障轉移操作和管理配置
每個群集節點都運行自己的群集服務
資源監視器
資源監視器是群集服務和群集資源之間的接口
並作為獨立進程運行
群集服務使用資源監視器與資源 DLL 進行通信
DLL 處理所有與資源的通信
因此 DLL 以資源監視器為宿主可以保護群集服務免受運行不正常或停止工作的資源造成的影響
資源監視器的多個副本可以在單個節點上運行
從而可以將無法預測的資源與其他資源隔離開
群集服務在需要對資源執行操作時
向分配給該資源的資源監視器發送請求
如果資源監視器的進程中沒有可以處理該類型資源的 DLL
則使用注冊信息加載與該資源類型相關聯的 DLL
然後
將群集服務的請求傳遞至其中一個 DLL 的入口點函數
資源 DLL 將處理操作的細節
以滿足資源的特定需要
資源 DLL
第三個關鍵的 Microsoft 群集服務組件是資源 DLL
資源監視器和資源 DLL 使用資源 API 進行通信
資源 API 是用於管理資源的入口點
回調函數和相關結構及宏的集合
對於群集服務而言
資源是任何可進行管理的物理組件或邏輯組件
例如磁盤
網絡名
IP 地址
數據庫
Web 站點
應用程序以及任何其他可以聯機和脫機的實體
資源可按類型進行組織
資源類型包括物理硬件（例如磁盤驅動器）和邏輯項（例如 IP 地址
文件共享和一般應用程序）
每個資源都使用資源 DLL
它主要是資源監視器和資源之間的被動轉換層
資源監視器調用資源 DLL 的入口點函數來查看資源的狀態
使資源聯機和脫機
資源 DLL 負責通過任何方便的 IPC 機制與其資源進行通信
以實現這些方法
實現其自身資源 DLL 與群集服務通信的應用程序以及使用群集 API 請求和更新群集信息的應用程序都被定義為識別群集的應用程序
不使用群集或資源 API 以及群集控制代碼函數的應用程序和服務都不識別群集
也不知道群集服務在運行
這些不識別群集的應用程序通常作為一般應用程序或服務進行管理
識別群集的應用程序和不識別群集的應用程序都可以在群集節點上運行
並且都可以作為群集資源進行管理
但是
只有識別群集的應用程序可以利用群集服務通過群集 API 提供的功能
開發識別群集的應用程序需要建立自定義資源類型
通過自定義資源類型
開發人員可以使其應用程序在群集內發生各種事件（例如
節點即將脫機
因此會關閉數據庫連接）時
作出響應並采取必要的措施
對於大多數需要在群集中運行的應用程序
最好投入一些時間和資源開發自定義資源類型
不過
可以先在群集環境中對應用程序進行測試
而不必修改應用程序的代碼或創建新的資源類型
在 Windows Server
系列中
未經修改的應用程序可以作為
不識別群集的
應用程序以基本級別運行
群集服務專為此用途提供了一般應用程序資源類型
群集管理器擴展 DLL 群集管理器擴展 DLL 在群集管理器內提供特定於應用程序的管理功能
允許用戶以同樣的方式管理他們的應用程序
無論該應用程序是在群集內部運行還是在群集外部運行
開發人員可以在群集管理器的框架內提供應用程序管理功能
或只是將這些功能鏈接到現有的管理工具
開發人員可以通過編寫擴展 DLL 來擴展群集管理器的功能
群集管理器應用程序通過一組已定義的 COM 接口與擴展 DLL 進行通信
擴展 DLL 必須實現一組特定的接口並且在群集的每個節點上都進行注冊
圖 關鍵組件 群集服務資源監視器和資源 DLL 不識別群集的應用程序 不提供其自身資源 DLL 的應用程序或服務仍可以在群集環境中進行配置
Windows Server
系列中的群集服務包括僅用於此目的的一般資源 DLL
一般應用程序資源 DLL 和一般服務資源 DLL
群集服務將這些應用程序或服務看作是不識別群集的一般應用程序或服務
一般資源 DLL 只提供最基本的控制
例如
一般應用程序資源 DLL 通過確定應用程序的進程是否仍然存在來檢查應用程序是否發生故障
並通過終止進程使應用程序脫機
但它並不依賴於其他資源
而是提供一個在群集環境中測試應用程序的簡單方法
高可用性記事本 並非所有應用程序都能在群集中高效地工作
最有效的評估方式就是在群集中實際部署應
From:http://tw.wingwit.com/Article/os/xtgl/201311/9492.html
