專利名稱：生成高可用性組的方法、設備及系統(tǒng)的制作方法
技術領域：
本發(fā)明總體上涉及信息技術(IT)領域內的面向服務的體系結構(S0A， Service-Oriented Architecture)開發(fā)框架，并且尤其涉及SOA開放框架內的高可用性 (HA, High Availability)方案的構造、部署和配置技術。
背景技術：
目前，由于越來越多的企業(yè)的業(yè)務得到了 IT(信息技術)的支持并且借助于IT實 現(xiàn)了自動化，所以高度可用的企業(yè)IT基礎設施變得異常重要，這是因為公司難以負擔得起 不期望的停機時間(downtime)，尤其是對于那些關鍵的服務而言更是如此。停機時間不僅 將導致難以承受的收入損失和客戶的不滿意問題，而且還將嚴重地影響公司聲譽甚至導致 公司倒閉。例如，以在線B2C(BusinesS to Customer，企業(yè)到用戶的電子商務模式)購書系 統(tǒng)、諸如Amazon為例，當系統(tǒng)崩潰時，公司在停機時間期間將損失潛在的收入，而且更嚴重 的是，客戶遭遇到不可用的業(yè)務服務的受挫體驗將導致客戶的滿意度降低、客戶丟失、甚至 導致品牌聲譽受損。因此，為了確保業(yè)務服務是高度可用的，IT基礎設施的高可用性是保 證。通常，高度可用的IT基礎設施通過基于冗余的HA方案來實現(xiàn)，其中基于冗余的HA方 案從IT管理角度來說是主要的可用性量度?；谌哂嗟腍A方案通過將關鍵數據和應用從 崩潰的IT系統(tǒng)故障轉移(failover)到另一個對等的系統(tǒng)中來為客戶提供連續(xù)不間斷的服 務，因此降低了服務的停機時間和相應的損失?；谌哂嗟腍A方案是高度可用的IT基礎設施的必要組成部分。但是，與此同時， 所要求的冗余的IT資源使其變得昂貴，并且多個IT系統(tǒng)應當交叉配置的要求使得其復雜 化。因此，在IT基礎設施中怎樣有效地設計和執(zhí)行HA方案變得極其重要。傳統(tǒng)地，業(yè)務人 員首先對各個業(yè)務服務詳細說明可用性要求，然后IT設計師或者甚至是HA專家判斷出何 處應當應用以及如何應用HA方案，在HA體系結構確定下來之后，IT技術人員將配置和提 供遵循體系結構判定的具體HA方案。但是，這種HA方案的傳統(tǒng)構造和實現(xiàn)方案是基于經 驗的，并且要求相關人員具備很高的專業(yè)技術能力，從而進一步導致高的IT資源和運作成 本。如何根據體系結構判定實現(xiàn)具體HA方案的設計、構造、部署和配置的自動化是當 前面臨的一大挑戰(zhàn)。傳統(tǒng)地，這些行為是人工執(zhí)行的。例如，在HA體系結構試圖對DB2數 據庫應用HA方案時，通?？梢詰脦追NHA方案，例如HADR(High Availability Disaster Recovery，高可用性災難恢復)和熱備用(hot standby)，其中將DB2數據庫文件放置在共 享存儲區(qū)中并且可以被兩個DB2實例訪問，IT技術員需要首先選擇一個具體方案，這要求 理解這些種HA方案并進行折衷，對于具有較少HA知識的IT技術員來說這通常相當困難。 而且，即使選定了具體的HA方案，配置和提供這樣一個具體的HA方案仍然是一項復雜的工 作，因為具體的HA方案通常涉及跨越多個IT資源、許多相互依賴和限制的復雜的配置，以 保證本方案能夠正確且最優(yōu)地工作。例如，配置DB2 HADR方案涉及主OS(操作系統(tǒng))、主 DB2實例、主數據庫、備用0S、備用DB2實例和備用數據庫，而且這些交叉組件的配置應該滿足多于50項限制。如果這些行為由人工執(zhí)行，將是非常勞動密集的、易于出錯的且高專業(yè) 技術要求的，這將會進一步導致高的IT運作成本。

發(fā)明內容
在下文中給出了關于本發(fā)明的簡要概述，以便提供關于本發(fā)明的某些方面的基本 理解。應當理解，這個概述并不是關于本發(fā)明的窮舉性概述。它并不是意圖確定本發(fā)明的 關鍵或重要部分，也不是意圖限定本發(fā)明的范圍。其目的僅僅是以簡化的形式給出某些概 念，以此作為稍后論述的更詳細描述的前序。為了解決現(xiàn)有技術的上述問題，本發(fā)明的目的是提供一種根據用戶的HA需求生 成高可用性(HA)組的方法、設備和系統(tǒng)，其能夠至少部分地解決現(xiàn)有技術中存在的上述缺 陷。為了實現(xiàn)上述目的，根據本發(fā)明的一個方面，提供了一種根據用戶的HA需求生成 HA組的方法，其包括依據對用戶的HA需求進行HA需求分析的結果，檢索可應用的HA模 式；基于所檢索到的HA模式，生成初始的HA組；對初始的HA組中的成員單元進行上下文重 置，以得到初步配置的HA組；根據可從用戶的HA需求中獲得的HA組冗余度，針對初步配置 的HA組生成基于成員單元的HA組變體；以及對所生成的HA組變體中的成員單元執(zhí)行結構 配置和屬性配置，從而得到滿足用戶HA需求的HA組。根據本發(fā)明的另一個方面，還提供了一種根據用戶的HA需求生成HA組的設備，其 包括HA模式檢索裝置，用于依據對用戶的HA需求進行HA需求分析的結果，檢索可應用的 HA模式；初始HA組生成裝置，用于基于HA模式檢索裝置所檢索到的HA模式，生成初始的 HA組；上下文重置裝置，用于對初始的HA組中的成員單元進行上下文重置，以得到初步配 置的HA組；HA組變體生成裝置，用于根據可從用戶的HA需求中獲得的HA組冗余度，針對 初步配置的HA組生成基于成員單元的HA組變體；以及配置裝置，用于對所生成的HA組變 體中的成員單元執(zhí)行結構配置和屬性配置，從而得到滿足用戶HA需求的HA組。根據本發(fā)明的另一個方面，還提供了一種根據用戶的HA需求生成HA組的系統(tǒng)，其 包括HA需求分析裝置，用于對用戶的HA需求進行HA需求分析；以上所述的根據用戶的HA 需求生成HA組的設備；以及預先存儲有多種可適用的HA模式的HA模式儲存庫。依據本發(fā)明的其它方面，還提供了相應的計算機可讀存儲介質和計算機程序產品。本發(fā)明的優(yōu)點在于，通過利用根據本發(fā)明的根據用戶的HA需求生成高可用性 (HA)組的方法、設備和/或系統(tǒng)，可以降低HA組配置的復雜度，并且實現(xiàn)了 HA組的設計、構 造、部署和配置的自動化，從而利于降低成本。通過以下結合附圖對本發(fā)明的最佳實施例的詳細說明，本發(fā)明的這些以及其他優(yōu) 點將更加明顯。


本發(fā)明可以通過參考下文中結合附圖所給出的描述而得到更好的理解，其中在所 有附圖中使用了相同或相似的附圖標記來表示相同或者相似的部件。所述附圖連同下面的 詳細說明一起包含在本說明書中并且形成本說明書的一部分，而且用來進一步舉例說明本發(fā)明的優(yōu)選實施例和解釋本發(fā)明的原理和優(yōu)點。在附圖中圖1和圖2分別示出了用于表征HA方案的HA組(將在下文中更為詳細地闡述) 的兩種單系統(tǒng)視圖(即，SSI集群的單系統(tǒng)視圖和HA故障轉移組的單系統(tǒng)視圖)的一個例 子；圖3是示出了根據本發(fā)明實施例的、根據用戶的HA需求生成HA組的方法的應用 場景的示意圖；圖4示出了在圖3所示的應用場景下利用根據本發(fā)明實施例的方法得到的HA組 的單系統(tǒng)視圖的兩個例子；圖5是示出了根據本發(fā)明實施例的、根據用戶的HA需求生成HA組的方法的示意 性流程圖；圖6是示出了在圖5的步驟S520中如何生成初始HA組的處理的示意性流程圖；圖7是示出了在執(zhí)行圖6中所示的步驟S650 (即，創(chuàng)建HA能力元素)之前和之后 的SSI集群(圖中所示為WAS集群)的單系統(tǒng)視圖的一個例子；圖8是示出了在圖5的步驟S530中如何執(zhí)行HA組中成員單元的上下文重置的處 理的示意性流程圖；圖9是示出了 HA專家如何編寫HA模式的過程的示意圖；圖10是示出了在圖8的步驟S850中如何調用上下文重置處理程序進行HA組中 成員單元的上下文重置的處理的示意性流程圖；圖11是示出了在圖5的步驟S540中如何生成基于成員單元的HA組變體的處理 的示意性流程圖；圖12是示出了根據本發(fā)明實施例的根據用戶的HA需求生成HA組的系統(tǒng)的結構 的示意性框圖；以及圖13是示出了其中可以實現(xiàn)本發(fā)明實施例的通用個人計算機的示例性結構的示 意性框圖。本領域技術人員應當理解，附圖中的元件僅僅是為了簡單和清楚起見而示出的， 而且不一定是按比例繪制的。例如，附圖中某些元件的尺寸可能相對于其他元件放大了，以 便有助于提高對本發(fā)明實施例的理解。
具體實施例方式在下文中將結合附圖對本發(fā)明的示范性實施例進行描述。為了清楚和簡明起見， 在說明書中并未描述實際實施方式的所有特征。然而，應該了解，在開發(fā)任何這種實際實施 例的過程中必須做出很多特定于實施方式的決定，以便實現(xiàn)開發(fā)人員的具體目標，例如，符 合與系統(tǒng)及業(yè)務相關的那些限制條件，并且這些限制條件可能會隨著實施方式的不同而有 所改變。此外，還應該了解，雖然開發(fā)工作有可能是非常復雜和費時的，但對得益于本公開 內容的本領域技術人員來說，這種開發(fā)工作僅僅是例行的任務。在此，還需要說明的一點是，為了避免因不必要的細節(jié)而模糊了本發(fā)明，在附圖中 僅僅示出了與根據本發(fā)明的方案密切相關的裝置結構和/或處理步驟，而省略了與本發(fā)明 關系不大的其他細節(jié)。在結合附圖描述本發(fā)明的實施例之前，為了便于理解，下面先對本文中涉及的某些技術術語和背景進行簡單的說明。為了提高IT資源的高可靠性能力(capability)，應用基于冗余的HA方案是主要 措施，其通過將發(fā)生故障的IT組件故障轉移到它的可工作的對等組件而實現(xiàn)高可用性?；谌哂嗟腍A方案可分為活動-活動方式(active-active mode)和活動-不活 動方式(active-passive mode)兩類，其相對應的通用HA模式是HA集群(HACluster)模 式和故障轉移組O^iloverGroup)模式。在活動-活動方式的HA方案中，兩個或更多個對 等的活動節(jié)點可分別處理請求，當其中一個節(jié)點發(fā)生故障時，另外一個對等活動節(jié)點將接 管該發(fā)生故障的節(jié)點上的客戶端請求以實現(xiàn)連續(xù)處理。應用服務器集群是一個這樣的典型 示例。在活動-不活動方式的HA方案中，一些活動節(jié)點用于處理客戶請求，而另一些節(jié)點 處于備用狀態(tài)。當活動節(jié)點發(fā)生故障時，激活備用節(jié)點以接受發(fā)送至發(fā)生故障的活動節(jié)點 的請求。DB2HADR是一個這樣的典型示例。在經過大量的調查和分析后可以觀察到HA方案具有共享特性。首先，大多數的 HA方案試圖為它的駐留應用(hosting application)提供單系統(tǒng)視圖(single system view)。以應用服務器集群為例，從應用級來說，它可以被認為是單個應用服務器而不是若 干個相互連接的應用服務器。其次，HA方案應當能夠提供下述通用功能(1)狀態(tài)/數據的同步/共享。在基于冗余的HA系統(tǒng)中，如果對等組件能夠接管 來自發(fā)生故障的組件的工作負荷，則它應當能夠為接管的請求恢復或者重建上下文。同步 和共享通常用于這個目的。(2)故障檢測。在基于冗余的HA系統(tǒng)中，應當使用監(jiān)視機制來檢測活動節(jié)點是否 發(fā)生故障，由此對等節(jié)點能夠開始接管處理。通常，心跳機制是廣泛使用的監(jiān)視機制。(3)故障轉移。即使狀態(tài)/數據是同步的并且能夠檢測到發(fā)生故障，對等節(jié)點仍然 應當能夠自動地接管來自發(fā)生故障的節(jié)點的請求。前端工作負荷重定向是這樣的一種頻繁 使用的機制。同時，還能夠安裝和配置附加的HA軟件以提供這個能力?；谏鲜鲇^察，為了表征HA方案，定義了一種新的建模機制HA組(HAGroup)， 其用于對多個同構或異構的成員單元進行分組以便提供HA方案的單系統(tǒng)視圖。至于HA組 能夠對多少個成員進行分組，在此引入了基數機制(cardinality mechanism)以限制上限 和下限?；鶖禉C制被定義為一個附屬于HA組上的范圍約束，例如[2，16]，它表示HA組中的 成員數目應當大于1并且小于17。從駐留和依賴的IT組件的角度來說，HA方案能夠通過HA組機制被建模為可用單 系統(tǒng)視圖表示的系統(tǒng)(也可以簡稱為單視圖系統(tǒng))。就單系統(tǒng)視圖而言，HA組應當具有其具 體IT組件成員(也可以稱之為成員單元或成員)的能力。因此，為了得到HA組的單系統(tǒng)視 圖(也可簡稱為HA單系統(tǒng)視圖)，引入了能力提升機制(capability move-up mechanism), 以便為HA組創(chuàng)建IT組件成員的功能性能力元素(即，將IT組件成員的功能性能力元素提 升到HA組上)，由此HA組能夠像其成員IT組件那樣被視為單視圖系統(tǒng)。以多個應用服務 器構成的集群式HA組為例，應用服務器的能力元素將被提升到集群式HA組上。由此，集群 式HA組能夠作為應用服務器來駐留應用。然而，對于更復雜的、其中HA組可以包含不同類型的類似成員的情形，能力提升 機制不能直接創(chuàng)建成員的能力元素和將其附屬于HA組，這是因為能力元素隨不同成員類型而改變。對于這種情形，例如，可以另外引入超類型(super-type)能力提升機制，它創(chuàng)建 成員的共有超類型能力元素(將在下文中更為詳細地說明)，然后將其附屬于HA組上，從而 將HA組中成員單元共有的超類型能力元素提升到HA組上。在建模類型系統(tǒng)中，不同的類型 之間存在一定關系，其中繼承關系就是一種表示繼承類型具有被繼承類型的所有特性。在 此，在類型系統(tǒng)中找到成員單元的多個能力元素所共有的超類型，稱之為共有超類型。如果 確定HA組中的成員單元對于某一類型都具有其對應的子類型能力元素，則超類型能力提 升機制就將該類型視為HA組的成員單元的共有超類型能力元素(在下文中將結合例子更 為詳細地說明)。除了 HA組可以被表示為單視圖系統(tǒng)并且能夠將具體IT組件成員的能力元素提升 到HA組上外，HA組在用單系統(tǒng)視圖呈現(xiàn)時還應當具有它自己的能力元素。如上文中已經 討論的那樣，一個完整的HA方案還應當具有執(zhí)行數據/狀態(tài)同步、資源監(jiān)視和故障檢測、以 及自動故障轉移的能力。因此，為了表示HA方案的這種能力，應當建模和提供新的能力元 素。目前，主要提供了三個主要的HA能力元素同步能力元素，檢測能力元素和故障轉移能 力元素。取決于HA模式是HA集群模式還是故障轉移組模式，HA組的單系統(tǒng)視圖(也可以 簡稱為單系統(tǒng)視圖)可以分為兩種典型類型SSI (單系統(tǒng)鏡像，Single System Image)集 群(SSI Cluster)的單系統(tǒng)視圖，和HA故障轉移組(HA Failover Group)的單系統(tǒng)視圖。其中，SSI集群用于規(guī)定資源集群的開發(fā)。例如，出于可用性目的，客戶可能希 望開發(fā)由“相同”資源構成的集群，而且依賴于這種資源的應用不希望(直接地)應對 集群中資源的多樣性。為此，在SSI集群中，所有資源都是相同的(即同構的)，資源的 能力元素可作為概念性能力元素(cone印tual capability)被指定給集群。在此，一個 概念性能力元素相當于一個接口，不具備實際的能力，而且必須利用適當的技術、例如負 載均衡器(如sprayer)等來實現(xiàn)。負載均衡器在HA方案中通常扮演代理的角色，使得 通過它向外界元素請求HA組提供的服務。有關負載均衡器的更多內容可參見下述網址 或文獻http://en. wikipedia. org/wiki/Load_balancing_(computing) ；Tony Bourke 所著的"Server Load Balancing” (0 ' Reilly 出版，ISBN 0-596-00050-2) ；Chandra Kopparapu 所著的"LoadBalancing Servers, Firewalls & Caches，，(Wiley 出版，ISBN 0-471-41550-2) ；Robert J. ShimonsKi PJf ^^ "ffrindows SerVer 2003 Clustering&Loa dBalancing" (Osborne McGraw-Hill 出片反，ISBN 0-07-222622-6) ；JeremyZawodny> Derek J. Balling 所著的 “High Performance MySQL”(0' Reilly 出版，ISBN 0-596-00306-4)； Matthew syme、Philip Goldie 所著的"Optimizing Network Performance with Content Switching :Server,Firewall and Cache Load Balancing，，(Prentice Hall PTR出版，ISBN 0-13-101468-5)等。HA故障轉移組用于提供對不可集群化的(non-clusterable)資源的HA操作。大 多數的數據庫系統(tǒng)因讀/寫狀態(tài)數據的量很大而不能被集群化。在故障轉移配置中配置 “熱備用(hot standby)”能夠提高可用性。依賴于資源的應用不希望(直接地)應對故障 轉移配置。HA故障轉移組實質上是選項組(Choice Group)和SSI集群的混合體，因此可以 與SSI集群類似地進行建模，包括將概念性能力元素附屬于HA故障轉移組本身上，而且由 于客戶端直接面向當前活動的資源實例，因此概念性能力元素的實現(xiàn)更類似于選項組。
圖1和圖2分別示出了 SSI集群的單系統(tǒng)視圖和HA故障轉移組的單系統(tǒng)視圖的 一個例子。如圖1所示，SSI集群(圖1中示出為WAS集群，是SSI集群中的一種)中包括2 個彼此相同的成員單元、即圖中所示的WAS應用服務器，每個WAS應用服務器上具有若干與 外界進行交互的接口、例如J2EE容器(container)、JSP容器、EJB容器等。這些J2EE容器 (container)、JSP容器、EJB容器是所有WAS應用服務器所共有的能力元素，因此應當借助 于能力提升機制而將其提升到WAS集群上。作為整體從外部來看，WAS集群就像單個WAS應 用服務器那樣操作。在圖2中所示的HA故障轉移組(圖中所示為數據庫故障轉移組)的單系統(tǒng)視圖例 子中，在試圖提供具有高可用性的數據庫服務的HA故障轉移組中存在DB2數據庫(作為主 要的活動節(jié)點)和Oracle數據庫(作為備用節(jié)點)兩個成員單元，而且DB2數據庫能力元 素和Oracle數據庫能力元素并不是所有成員單元所共有的，因此不應當被附屬于HA組，但 是它們的超類型能力原始、即數據庫能力元素則應當借助于超類型能力提升機制而被附屬 于HA故障轉移組上。作為整體從外部來看，數據庫故障轉移組就像單個數據庫那樣操作。另外，為了進一步簡化HA組的配置，在HA模式架構中提供了兩種HA模式變 換方式UTP(單元到HA模式，Unit To HA Pattern)和GTS(通用到具體，Generic To Specific)。其中，UTP支持從一個成員單元到其可應用的HA模式(可以是通用HA模式或者 具體HA模式)的變換，即從一個成員單元到滿足用戶HA需求的、包含該成員單元的HA組 的變換。在HA模式的表示中，已經定義了可應用單元類型。實際上，這種變換基于集成的 HA組配置，但是是在將HA模式應用到IT組件單元的上下文中進行的。除配置之外，在此變 換中還引入了特殊的替換機制，由于HA組可以被看作是單視圖系統(tǒng)，所以HA模式將會在部 署拓撲結構中直接替換可應用單元，并且相應地將該可應用單元的所有關聯(lián)關系配置到HA 組中。采用此變換方式，將HA模式應用于部署單元上就如同替換操作一樣簡單，而且?guī)缀?不需要具備HA知識和進行HA配置。GTS支持將通用HA模式變換為具體HA模式。這種變換的動機是在建模過程中， 如果部署操作者不確定將使用哪一種具體的HA方案，則他可以先用通用模式來構造HA體 系結構，在確定了具體HA模式之后，可以執(zhí)行進一步的變換來完成具體的配置。這種變換 只能在目標具體HA模式屬于源通用HA模式類別的情況下應用。它與UTP類似，也可以看 作是替換操作。但是，它們的應用環(huán)境和動機是不同的。下面結合圖3至圖11對根據本發(fā)明實施例的、根據用戶的HA需求生成HA組的方 法(其可以實現(xiàn)上述的UTP和GTS這兩種HA模式變換方式)的處理過程進行說明。其中， 圖3是示出了根據本發(fā)明實施例的根據用戶的HA需求生成HA組的方法的應用場景的示意 圖，圖4示出了在圖3所示的應用場景下根據本發(fā)明實施例得到的HA組的單系統(tǒng)視圖的兩 個例子，而圖5的示意性流程圖示出了根據本發(fā)明實施例的根據用戶的HA需求生成HA組 的方法500的處理。如圖3所示，通過應用根據本發(fā)明實施例的、根據用戶(例如，系統(tǒng)設計人員)的 HA需求生成HA組的方法，可以根據通過對用戶關于所期望得到的HA方案的HA需求(即對 于所期望構建的HA組的HA需求)進行HA需求分析的結果，將原始方案(As is solution)(例如，非HA的方案或通用HA模式的方案)變換為滿足所述HA需求的HA方案(也可以稱 之為目標HA方案)。如圖5所示，在步驟S510中，依據對用戶的HA需求進行HA需求分析的結果，從例 如預先存儲有多種HA模式的HA模式儲存庫中檢索可應用的HA模式。其中，有關HA需求分 析的細節(jié)可參見例如由 Lei Xie, Jing Luo, Jie Qiu,Pershing J. A. ,Ying Li 和 Ying Chen 所著的"Availability ‘Weak Point'Analysis over an SOA Deployment Framework"(參 B 2008IEEE Network Operations and Management Symposium(N0MS 2008), Vol. 1,2008 年4月7 11日，第473 480頁)。為了說明書的簡潔起見，在此就不再對HA需求分析 的具體過程進行描述了。然后，在步驟S520中，基于步驟S510中檢索到的HA模式，生成初始HA組。如上 所述，取決于所檢索到的HA模式是HA集群模式還是故障轉移組模式，生成初始的SSI集群 或HA故障轉移組(在此統(tǒng)稱為初始HA組)。在此，初始HA組的生成過程僅僅是利用HA組 這個模型以容器的形式簡單地將HA組成員包含進來。例如，取決于用戶輸入的不同，可以存在如下幾種生成初始HA組的方式(1)如果 用戶選定模型圖(其中，模型圖是在對用戶的HA需求進行HA需求分析的過程中由用戶輸 入的，有關它的更多細節(jié)可參見上文中所提到的“Availability ‘Weak Point’ Analysis over an SOA D印loymentFramework”)上的某一資源元素，則該資源元素將被作為組成員 包含進來，從而形成初始HA組；(2)如果用戶選定模型圖上的幾個兼容的資源元素(資源 元素是否兼容根據HA模式中定義的約束確定)，則這些資源元素將被作為組成員包含進 來，形成初始HA組；(3)用戶也可以直接在模型圖中創(chuàng)建一個空的HA組模型元素作為初始 HA組。接下來，在步驟S530中，對初始HA組中的成員單元執(zhí)行上下文重置，以得到 初步配置的HA組。在此，“上下文”指的是HA組成員單元的輸入的依賴性(incoming dependency)。然后，在步驟S540中，根據可從用戶的HA需求中獲得的HA組冗余度，針對 初步配置的HA組生成基于成員單元的HA組變體，并在步驟S550中對所生成的HA組變體 中的成員單元執(zhí)行結構配置和屬性配置(可利用下文所提到的HA模式中記錄的結構配置 組件和屬性配置組件來實現(xiàn))，從而得到用戶所期望的滿足HA需求的HA組。例如，在圖4中所示的例1中示出了利用上述方法得到的SSI集群(圖中所示為 WAS集群)的單系統(tǒng)視圖，在圖4中所示的例2中示出了利用上述方法得到的HA故障轉移 組(圖中所示為數據庫故障轉移組)的單系統(tǒng)視圖。下面結合圖6至圖11對圖5中所示的步驟S520至S550中的具體處理過程進行 詳細的描述。其中，圖6是示出了在步驟S520中如何生成初始HA組的處理的示意性流程 圖，圖7是示出了在執(zhí)行圖6中所示的步驟S650 ( S卩，創(chuàng)建HA能力元素)之前和之后的SSI 集群(圖中所示為WAS集群)的單系統(tǒng)視圖的一個例子，圖8是示出了在圖5的步驟S530 中如何執(zhí)行HA組中成員單元的上下文重置的處理的示意性流程圖，圖9是示出了 HA專家 如何編寫HA模式的過程的示意圖，圖10是示出了在圖8的步驟S850中如何調用上下文重 置處理程序進行HA組中成員單元的上下文重置的處理的示意性流程圖，而圖11是示出了 在圖5的步驟S540中如何生成基于成員單元的HA組變體的處理的示意性流程圖。圖6所示的流程圖中示出了圖5中的步驟S520 ( S卩，生成初始HA組)的具體處理過程。如圖6所示，在步驟S610中，根據步驟S510中檢索到的HA模式，確定HA組中的一 個或多個成員單元是否是同構的。如果步驟S610的判斷結果為是的話，則在步驟S620確 定HA組中成員單元的共有功能性能力元素(例如，對于圖4中的例1來說，可以確定所有 成員單元的共有功能性能力元素包括J2EE容器、JSP容器和EJB容器)；否則，在步驟S630 中確定HA組中成員單元的共有超類型功能性能力元素(例如，對于圖4中的例2來說，可 以確定所有成員單元的共有超類型功能性能力元素包括數據庫)。然后，在步驟S640中，為HA組創(chuàng)建在步驟S620或者步驟S630中確定的功能性能 力元素(也就是說，將所確定的功能性能力元素提升到HA組上)。例如，對于圖4中的例1， 借助于能力提升機制為WAS集群創(chuàng)建J2EE容器、JSP容器和EJB容器(也就是說，將J2EE 容器、JSP容器和EJB容器提升到WAS集群上)，而對于圖4中的例2，借助于能力提升機制 (即，超類型能力提升機制)為數據庫故降轉移組創(chuàng)建數據庫(也就是說，將數據庫提升到 數據庫故障轉移組上)。接下來，在步驟S650中，為HA組創(chuàng)建HA能力元素，其中可以包括為HA組提供和 配置狀態(tài)或數據的同步能力元素、提供和配置故障檢測能力元素、提供和配置故障轉移能 力元素等，從而得到初始HA組。例如，圖7示出了在創(chuàng)建HA能力元素之前和之后的WAS集 群的單系統(tǒng)視圖的一個例子。圖8所示的流程圖示出了圖5中的步驟S530 (即，執(zhí)行HA組中成員單元的上下文 重置)的具體處理過程。如圖8所示，在步驟S810中，確定HA組中的各個成員單元是否有 輸入的依賴性(例如，可根據模型圖來確定)。在此，例如以圖4中的例1為例，“依賴性” 是指WAS集群中的各個WAS應用服務器與外界之間的關系，而“輸入”的依賴性是指外界對 WAS應用服務器的依賴關系。如果在步驟S810中確定有成員單元具有輸入的依賴性，則在步驟S820中獲得該 成員單元的依賴源類型(即，依賴于該成員單元的外部源單元的類型)，然后處理進行到步 驟S840 ；否則，結束步驟S530的處理(即，無需執(zhí)行上下文重置處理)。如圖所示，在步驟S830中，基于步驟S510中檢索到的HA模式確定HA組是否為HA 透明的。如果確定結果是否定的，即如果確定目標HA組不是HA透明的，則處理進行到步驟 S840 ；否則，結束步驟S530的處理(即，無需執(zhí)行上下文重置)。在HA組的軟件或者硬件本身提供了自動的故障接管機制的情況下，在將一個單 元變換成一個HA組時，不需要額外的配置來進行上下文重置。這時，從輸入依賴者的角度 來看，HA組是透明的，也就是說，使用或者不使用HA方案對上下文沒有影響。通常，HA模 式是不是能提供HA透明的能力，取決于該HA模式所采用的軟件，也就是說，在HA專家編寫 HA模式時就已經根據其使用的軟件進行了記錄，以確定HA組是否是HA透明的。如圖所示，當滿足“HA組不是HA透明的”且“成員單元有輸入的依賴性”時，在步 驟S840中，從例如處理程序儲存庫(handler repository)中查找適當的上下文重置處理 程序以供調用(例如，可以參照圖9中所示的表格、根據依賴源類型來查找適當的上下文重 置處理程序)。其中，上下文重置處理程序是這樣的功能服務，其根據要變換單元的上下文來設 置變換后的HA組中成員單元的上下文，使得在生成HA組的過程中不會丟失上下文。例如， 將會把與要變換單元的依賴關系重置到所要變換成的HA組中。通常，上下文重置處理程序由HA專家編寫，并且根據其類別類型而存儲在處理程序儲存庫中。當編寫HA模式時，將基 于依賴的源單元來記錄HA上下文重置處理程序。上下文重置處理程序主要可以分為如下三類(1)基于配置的處理程序；(2)基于 文件的處理程序；和C3)基于代理的處理程序。對于基于配置的上下文重置處理程序來說， 要求在依賴源單元處具有特定配置，并且通常需將特殊的組件(該組件通常由特定的HA軟 件提供)部署到依賴源單元上。一般來說，數據庫特定的HA方案會涉及這一類處理程序。 對于基于文件的上下文重置處理程序來說，在依賴源單元處應當重新生成和部署有特定文 件，而且也需要特殊的組件(它通常是外部資源)但是通常它已經被部署了。而對于基于代 理的上下文重置處理程序來說，在依賴源單元和HA組之間需要有中間單元(其充當代理)。為了便于理解，圖9中示意性地示出了 HA專家編寫HA模式的過程示例。如圖9 所示，為了編寫HA模式，HA專家首先記錄上下文重置處理程序，例如，可以參照圖中所示的 表格格式將依賴源類型與上下文重置處理程序關聯(lián)起來，以形成上下文重置組件。然后，HA 專家記錄屬性，例如，可以參照圖中所示的表格格式存儲“名稱”、“類型”和“缺省值”等，以 形成屬性配置組件。此外，HA專家還會記錄約束。這樣，如圖中所示，編寫好的HA模式中 會記錄有上下文重置組件、屬性配置組件、結構配置組件和約束。另外，處理程序儲存庫例如可以與上文中提到的HA模式儲存庫分離地存儲在不 同的存儲設備上，但是它們被存儲在同一存儲設備上也是可能的。返回參見圖8。在步驟S850中，調用步驟S840中查找到的上下文重置處理程序。 圖10中的流程圖詳細地示出了步驟S850(調用上下文重置處理程序)的處理過程。如圖10所示，在步驟S1010中，獲得步驟S840中找到的上下文重置處理程序的類 型，并在步驟S1015中確定上下文重置處理程序的類型是基于配置的、基于文件的和基于 代理的處理程序中的哪一種。如果在步驟S1015中確定上下文重置處理程序是基于配置的，則在步驟S1020中 檢測在依賴源單元處的重路由組件，并在步驟S1025中確定該重路由組件是否已被部署 (即，是否部署到HA組中)。如果尚未部署，則在步驟S1030中將所述重路由組件配置到HA 組中，然后處理流程進行到步驟S1035 ；否則，處理流程直接進行到步驟S1035。在步驟S1035中，調用HA模式中記錄的上下文重置組件來對重路由組件進行重新 配置。其中，有關重路由組件的更多細節(jié)可參見例如由IBM InternationalTechnical Support Organization 1^1 "High Availability and ScalabilityGuide for DB2 on Linux, UNIX, and Windows (Redbooks) ”(例如參見其中第 5 章)(其可從 www, ibm. com/ redbooks/下獲得)，在此為了說明書的簡潔起見就不再詳沭了。如果在步驟S1015中確定上下文重置處理程序是基于文件的，則在步驟S1040中 生成依賴源單元的文件資源，然后在步驟S1045中用新生成的文件資源代替HA單系統(tǒng)視圖 中的相應成員單元的當前文件資源。如果在步驟S1015中確定上下文重置處理程序是基于代理的，則在步驟S1050中 調用HA模式中記錄的上下文重置組件來部署中間資源(部署到HA組中)，然后在步驟 S1055中基于上下文重置處理程序來配置中間資源。這樣，在執(zhí)行了步驟S1035、S1045或者S1055之后，就完成了 HA組中成員單元的13上下文重置過程。圖11是詳細地示出了圖5中的步驟S540 (生成基于成員單元的HA組變體)的具 體處理過程的示意性流程圖。如圖11所示，在步驟SlllO中，根據用戶設定的HA組冗余度(其可從用戶輸入的 HA需求中獲得)而確定是否存在對成員變體的請求(在此，為了簡單起見，僅僅考慮了 HA 組中成員單元的數目的變化)。如果沒有的話，則結束處理，即無需生成基于成員單元的HA 組變體。如果在步驟SlllO中確定存在對成員變體的請求(即，確定存在改變成員數目的 請求)，則在步驟S1120中向HA組中添加成員單元或者從HA組中刪除成員單元。在此，添 加或者刪除成員單元的數目取決于改變成員數目的請求。然后，在步驟S1130中確定當前 成員單元的數目是否滿足關于成員數目的約束(其如圖9所示的那樣預先記錄在HA模式 中)。如果在S1130中確定已經滿足了約束，則在步驟S1140中對HA組進行重新配置，然后 結束處理。如果在S1130中確定不滿足約束，則在步驟S1150中取消上述添加或刪除成員 單元的動作，然后處理流程返回步驟S1110，以確定是否還存在對成員變體的請求，并且在 確定還存在所述請求時重復執(zhí)行上述步驟SlllO S1150，直至沒有對成員變體的請求為 止。以上結合圖3至圖11描述了根據本發(fā)明實施例的根據用戶的HA需求生成HA組 的方法的具體處理過程，但是本領域技術人員在閱讀了以上的描述后可以很容易地根據實 際需要對以上所描述的處理過程進行修改或改進。例如，圖5所示的方法500還可以包含將HA組以單系統(tǒng)視圖的形式呈現(xiàn)給用戶的 步驟(圖中未示出)，使得用戶可以獲得對于所生成的HA組的直觀認識，便于用戶進行后續(xù) 操作?？梢栽诜椒?00的整個執(zhí)行過程中以單系統(tǒng)視圖的形式向用戶呈現(xiàn)HA組，從而可以 使用戶直觀地了解在方法500的每個步驟中所得到的HA組。當然，也可以根據實際需要進行其他的修改或改進。在此，為了說明書的簡潔起見 就不再一一詳述了。圖12是示出了根據本發(fā)明實施例的、根據用戶的HA需求生成HA組的系統(tǒng)1200 的結構的示意性框圖。如圖12所示，系統(tǒng)1200中主要包括HA需求分析裝置100、HA組生成設備200和 HA模式儲存庫300。其中，HA需求分析裝置100用于對用戶的HA需求進行HA需求分析， HA組生成設備200可以如以上所描述的那樣根據用戶的HA需求生成HA組，HA模式儲存庫 300中預先存儲有多種可適用的HA模式。如圖所示，HA組生成設備200進一步包括HA模式檢索裝置210、初始HA組生成裝 置220、上下文重置裝置230、HA組變體生成裝置240和配置裝置250。其中，HA模式檢索裝置210用于依據對用戶的HA需求進行HA需求分析的結果， 從HA模式儲存庫300中檢索可應用的HA模式；初始HA組生成裝置220用于基于HA模式 檢索裝置210所檢索到的HA模式，生成初始HA組(即，初始的SSI集群或者HA故障轉移 組)；上下文重置裝置230用于對初始HA組生成裝置220所生成的初始HA組中的成員單 元執(zhí)行上下文重置，以得到初步配置的HA組；HA組變體生成裝置240用于根據可從用戶的 HA需求中獲得的HA組冗余度，針對初步配置的HA組生成基于成員單元的HA組變體；以及配置裝置250用于對所生成的HA組變體中的成員單元執(zhí)行結構配置和屬性配置，從而得到 用戶所期望的滿足用戶HA需求的HA組。其中，初始HA組生成裝置包括用于根據所檢索到的HA模式確定HA組中的一個 或多個成員單元是否同構的裝置；用于在成員單元同構的情況下確定HA組中成員單元的 共有功能性能力元素，以及在成員單元不同構的情況下確定HA組中成員單元的共有超類 型功能性能力元素的裝置；用于為HA組創(chuàng)建所確定的所述功能性能力元素的裝置；以及用 于為HA組創(chuàng)建包括狀態(tài)或數據的同步能力元素、故障檢測能力元素和故障轉移能力元素 的HA能力元素從而得到初始的HA組的裝置。其中，上下文重置裝置包括用于確定HA組中的各個成員單元是否有輸入的依賴 性的裝置；用于在確定有成員單元具有輸入的依賴性的情況下獲得該成員單元的依賴源類 型的裝置；用于基于所檢索到的HA模式確定HA組是否為HA透明的裝置；用于在確定HA 組不是HA透明的且有成員單元具有輸入的依賴性的情況下查找適當的上下文重置處理程 序以供調用的裝置；以及用于調用所查找到的上下文重置處理程序來執(zhí)行上下文重置的裝 置。其中，用于調用所查找到的上下文重置處理程序來執(zhí)行上下文重置的裝置進一步 包括a)用于獲得所查找到的上下文重置處理程序的類型的裝置；b)用于在上下文重置處 理程序是基于配置的處理程序的情況下執(zhí)行下述處理的裝置檢測在成員單元的依賴源單 元處的重路由組件，并確定該重路由組件是否已被部署在HA組中，如果未部署，就將重路 由組件配置到HA組中，然后調用HA模式中記錄的上下文重置組件來對重路由組件進行重 新配置；c)用于在上下文重置處理程序是基于文件的處理程序的情況下執(zhí)行下述處理的 裝置生成依賴源單元的文件資源，然后用新生成的文件資源代替HA組中的相應成員單元 的當前文件資源；以及d)用于在上下文重置處理程序是基于代理的處理程序的情況下執(zhí) 行下述處理的裝置調用HA模式中記錄的上下文重置組件來向HA組中部署中間資源，然后 基于上下文重置處理程序來配置中間資源。由于以上已經結合流程圖對如何實現(xiàn)上述各個裝置的功能的過程進行了描述，所 以在此就不再對各裝置的功能實現(xiàn)進行詳述了。通過以上的描述不難看出，通過利用以上所描述的根據用戶的HA需求生成HA組 的方法、設備和/或系統(tǒng)，可以降低HA組配置的復雜度，并且實現(xiàn)了 HA組的設計、構造和配 置的自動化，從而利于降低成本。另外，通過利用以上所描述的根據用戶的HA需求生成HA組的方法、設備和/或系 統(tǒng)，由于降低了 HA組配置的復雜度，使得IT技術人員無需像以往那樣具有很高的HA專業(yè) 技能，從而降低了對技術人員的專業(yè)技能要求，因而有助于降低成本。此外，顯然，根據本發(fā)明的上述方法的各個操作過程也可以以存儲在各種機器可 讀的存儲介質中的計算機可執(zhí)行程序的方式實現(xiàn)。而且，本發(fā)明的目的也可以通過下述方式實現(xiàn)將存儲有上述可執(zhí)行程序代碼的 存儲介質直接或者間接地提供給系統(tǒng)或設備，并且該系統(tǒng)或設備中的計算機或者中央處理 單元(CPU)讀出并執(zhí)行上述程序代碼。此時，只要該系統(tǒng)或者設備具有執(zhí)行程序的功能，則本發(fā)明的實施方式不局限于 程序，并且該程序也可以是任意的形式，例如，目標程序、解釋器執(zhí)行的程序或者提供給操作系統(tǒng)的腳本程序等。上述這些機器可讀存儲介質包括但不限于各種存儲器和存儲單元，半導體設備， 磁盤單元例如光、磁和磁光盤，以及其它適于存儲信息的介質等。另外，計算機通過連接到因特網上的相應網站，并且將依據本發(fā)明的計算機程序 代碼下載和安裝到計算機中然后執(zhí)行該程序，也可以實現(xiàn)本發(fā)明。圖13是示出了其中可以實現(xiàn)本發(fā)明的通用個人計算機1300的示例性結構的框圖。如圖13中所示，中央處理單元(CPU) 1301根據只讀存儲器(ROM) 1302中存儲的程 序或從存儲部分1308加載到隨機存取存儲器(RAM) 1303的程序執(zhí)行各種處理。在RAM 1303 中，也根據需要存儲當CPU 1301執(zhí)行各種處理等等時所需的數據。CPU 130UR0M 1302和RAM 1303經由總線1304彼此連接。輸入/輸出接口 1305 也連接到總線1304。輸入/輸出接口 1305與下述部件相連接輸入部分1306，包括鍵盤、鼠標等等；輸 出部分1307，包括顯示器，比如陰極射線管(CRT)、液晶顯示器(LCD)等等，和揚聲器等等； 存儲部分1308，包括硬盤等等；和通信部分1309，包括網絡接口卡比如LAN卡、調制解調器 等等。通信部分1309經由網絡比如因特網執(zhí)行通信處理。根據需要，驅動器1310也連接到輸入/輸出接口 1305。可拆卸介質1311比如磁 盤、光盤、磁光盤、半導體存儲器等等根據需要被安裝在驅動器1310上，使得從中讀出的計 算機程序根據需要被安裝到存儲部分1308中。在通過軟件實現(xiàn)上述系列處理的情況下，從網絡比如因特網或存儲介質比如可拆 卸介質1311安裝構成軟件的程序。本領域的技術人員應當理解，這種存儲介質不局限于圖13所示的其中存儲有程 序、與設備相分離地分發(fā)以向用戶提供程序的可拆卸介質1311?？刹鹦督橘|1311的例子 包含磁盤(包含軟盤(注冊商標))、光盤(包含光盤只讀存儲器(⑶-ROM)和數字通用盤 (DVD))、磁光盤(包含迷你盤(MD)(注冊商標))和半導體存儲器?；蛘撸鎯橘|可以是 ROM 1302、存儲部分1308中包含的硬盤等等，其中存有程序，并且與包含它們的設備一起 被分發(fā)給用戶。在此，需要指出的是，執(zhí)行上述系列處理的步驟可以自然地按照說明的順序按時 間順序執(zhí)行，但是并不需要一定按照時間順序執(zhí)行。某些步驟可以并行或彼此獨立地執(zhí)行。此外，還需要說明的是，在本文中，術語“包括”、“包含”或者其任何其他變體意在 涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些 要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個......”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。以上雖然結合附圖詳細描述了本發(fā)明的實施例，但是應當明白，上面所描述的實 施方式只是用于說明本發(fā)明，而并不構成對本發(fā)明的限制。對于本領域的技術人員來說，可 以對上述實施方式作出各種修改和變更而沒有背離本發(fā)明的實質和范圍。因此，本發(fā)明的 范圍僅由所附的權利要求及其等效含義來限定。
權利要求
1.一種根據用戶的高可用性HA需求生成HA組的方法，包括以下步驟 依據對用戶的HA需求進行HA需求分析的結果，檢索可應用的HA模式； 基于所檢索到的HA模式，生成初始的HA組；對初始的HA組中的成員單元進行上下文重置，以得到初步配置的HA組； 根據可從用戶的HA需求中獲得的HA組冗余度，針對初步配置的HA組生成基于成員單 元的HA組變體；以及對所生成的HA組變體中的成員單元執(zhí)行結構配置和屬性配置，從而得到滿足用戶HA 需求的HA組。
2.如權利要求1所述的方法，其中，生成初始的HA組包括根據所檢索到的HA模式，確定HA組中的一個或多個成員單元是否是同構的； 如果成員單元是同構的，則確定HA組中成員單元的共有功能性能力元素，否則確定HA 組中成員單元的共有超類型功能性能力元素；為HA組創(chuàng)建所確定的所述功能性能力元素；以及為HA組創(chuàng)建HA能力元素，從而得到初始的HA組，其中HA能力元素包括狀態(tài)或數據的 同步能力元素、故障檢測能力元素和故障轉移能力元素。
3.如權利要求2所述的方法，其中，為HA組創(chuàng)建HA能力元素包括為HA組提供和配 置狀態(tài)或數據的同步能力元素，提供和配置故障檢測能力元素，以及提供和配置故障轉移 能力元素。
4.如權利要求1所述的方法，其中，對初始的HA組中的成員單元進行上下文重置包括確定HA組中的各個成員單元是否有輸入的依賴性；如果確定有成員單元具有輸入的依賴性，則獲得該成員單元的依賴源類型，否則就結 束上下文重置的處理；基于所檢索到的HA模式確定HA組是否為HA透明的；如果確定HA組是HA透明的，則結束上下文重置的處理，否則查找適當的上下文重置處 理程序以供調用；以及調用所查找到的上下文重置處理程序來執(zhí)行HA組中成員單元的上下文重置。
5.如權利要求4所述的方法，其中，調用所查找到的上下文重置處理程序來執(zhí)行HA組 中成員單元的上下文重置包括獲得所查找到的上下文重置處理程序的類型；如果上下文重置處理程序是基于配置的，則檢測在成員單元的依賴源單元處的重路由 組件，并確定該重路由組件是否已被部署在HA組中，如果未部署，就將重路由組件配置到 HA組中，然后調用HA模式中記錄的上下文重置組件來對重路由組件進行重新配置；如果上下文重置處理程序是基于文件的，則生成依賴源單元的文件資源，然后用新生 成的文件資源代替HA組中的相應成員單元的當前文件資源；以及如果上下文重置處理程序是基于代理的，則調用HA模式中記錄的上下文重置組件來 向HA組中部署中間資源，然后基于上下文重置處理程序來配置中間資源。
6.如權利要求4或5所述的方法，其中，所述適當的上下文重置處理程序是從預先存儲 有多種上下文重置處理程序的處理程序儲存庫中查找到的。
7.如權利要求1所述的方法，其中，生成基于成員單元的HA組變體包括a)在根據用戶的HA需求確定存在改變成員數目的請求的情況下，向HA組中添加成員 單元或者從HA組中刪除成員單元，其中添加或者刪除成員單元的數目取決于所述改變成 員數目的請求；b)確定HA組中當前成員單元的數目是否滿足關于成員數目的約束；c)如果確定已經滿足了約束，則對HA組進行重新配置；以及d)如果確定不滿足約束，則取消上述添加或刪除成員單元的動作，并確定是否還存在 改變成員數目的請求，在確定還存在改變成員數目的請求時，重復執(zhí)行上述步驟a)至d)， 直至沒有改變成員數目的請求為止。
8.如權利要求1至7中任意一項所述的方法，進一步包括以單系統(tǒng)視圖的形式向用 戶呈現(xiàn)所述HA組。
9.如權利要求1至7中任意一項所述的方法，其中，可應用的HA模式是從預先存儲有 多種HA模式的HA模式儲存庫中檢索的。
10.如權利要求1至7中任意一項所述的方法，其中，利用HA模式中記錄的結構配置組 件和屬性配置組件來實現(xiàn)HA組中成員單元的結構配置和屬性配置。
11.一種根據用戶的高可用性HA需求生成HA組的設備，包括HA模式檢索裝置，用于依據對用戶的HA需求進行HA需求分析的結果，檢索可應用的 HA模式；初始HA組生成裝置，用于基于HA模式檢索裝置所檢索到的HA模式，生成初始的HA組；上下文重置裝置，用于對初始的HA組中的成員單元進行上下文重置，以得到初步配置 的HA組；HA組變體生成裝置，用于根據可從用戶的HA需求中獲得的HA組冗余度，針對初步配置 的HA組生成基于成員單元的HA組變體；以及配置裝置，用于對所生成的HA組變體中的成員單元執(zhí)行結構配置和屬性配置，從而得 到滿足用戶HA需求的HA組。
12.如權利要求11所述的設備，其中，初始HA組生成裝置包括用于根據所檢索到的HA模式確定HA組中的一個或多個成員單元是否同構的裝置；用于在成員單元同構的情況下確定HA組中成員單元的共有功能性能力元素，以及在 成員單元不同構的情況下確定HA組中成員單元的共有超類型功能性能力元素的裝置；用于為HA組創(chuàng)建所確定的所述功能性能力元素的裝置；以及用于為HA組創(chuàng)建包括狀態(tài)或數據的同步能力元素、故障檢測能力元素和故障轉移能 力元素的HA能力元素從而得到初始的HA組的裝置。
13.如權利要求11或12所述的設備，其中，上下文重置裝置包括用于確定HA組中的各個成員單元是否有輸入的依賴性的裝置；用于在確定有成員單元具有輸入的依賴性的情況下獲得該成員單元的依賴源類型的 裝置；用于基于所檢索到的HA模式確定HA組是否為HA透明的裝置；用于在確定HA組不是HA透明的且有成員單元具有輸入的依賴性的情況下查找適當的上下文重置處理程序以供調用的裝置；以及用于調用所查找到的上下文重置處理程序來執(zhí)行上下文重置的裝置。
14.如權利要求13所述的設備，其中，用于調用所查找到的上下文重置處理程序來執(zhí) 行上下文重置的裝置包括用于獲得所查找到的上下文重置處理程序的類型的裝置；用于在上下文重置處理程序是基于配置的處理程序的情況下執(zhí)行下述處理的裝置檢 測在成員單元的依賴源單元處的重路由組件，并確定該重路由組件是否已被部署在HA組 中，如果未部署，就將重路由組件配置到HA組中，然后調用HA模式中記錄的上下文重置組 件來對重路由組件進行重新配置；用于在上下文重置處理程序是基于文件的處理程序的情況下執(zhí)行下述處理的裝置生 成依賴源單元的文件資源，然后用新生成的文件資源代替HA組中的相應成員單元的當前 文件資源；以及用于在上下文重置處理程序是基于代理的處理程序的情況下執(zhí)行下述處理的裝置調 用HA模式中記錄的上下文重置組件來向HA組中部署中間資源，然后基于上下文重置處理 程序來配置中間資源。
15.一種根據用戶的高可用性HA需求生成HA組的系統(tǒng)，包括HA需求分析裝置，用于對用戶的HA需求進行HA需求分析；如權利要求10至13中任意一項所述的設備；以及預先存儲有多種可適用的HA模式的HA模式儲存庫。
全文摘要
公開了一種根據用戶的高可用性(HA)需求生成HA組的方法、設備及系統(tǒng)。所述方法包括依據對用戶的HA需求進行HA需求分析的結果，檢索可應用的HA模式；基于所檢索到的HA模式，生成初始的HA組；對初始的HA組中的成員單元進行上下文重置，以得到初步配置的HA組；根據可從用戶的HA需求中獲得的HA組冗余度，針對初步配置的HA組生成基于成員單元的HA組變體；以及對所生成的HA組變體中的成員單元執(zhí)行結構配置和屬性配置，從而得到滿足用戶HA需求的HA組。通過利用所述方法、設備和/或系統(tǒng)，可以降低HA組配置的復雜度，并且實現(xiàn)了HA組的設計、構造和配置的自動化。
文檔編號H04L29/08GK102055779SQ200910207780
公開日2011年5月11日 申請日期2009年10月30日 優(yōu)先權日2009年10月30日
發(fā)明者小約翰·A·珀欣, 李影, 羅景 申請人:國際商業(yè)機器公司