引言
本文將指導您完成 IBM Operational Decision Management (ODM) V8 部署環境的安裝和配置 。本文將介紹理解高度可用的、可伸縮的 WebSphere Application Server Network Deployment 環境需要掌 握的一些基本概念，還將介紹 ODM 服務器組件，並解釋這些組件中影響分布式環境中的部署決策的特性或約 束條件。
除了討論 WebSphere Application Server 單元拓撲中這些組件的布局之外，我們還將介紹 從開發階段到生產階段采用 ODM 解決方案所需的其他部署環境。最後，我們會帶您逐步完成 ODM 參考或 “ 黃金” 拓撲的安裝和配置。
在本文中，我們將使用術語 ODM 來表示 IBM Operational Decision Manager V8.0.1 和以前的 WebSphere Operational Decision Manager V8.0.0.1，但在這些上下文中，必須 有一個特定於產品版本的參考。
背景
IBM WebSphere Application Server Network Deployment V8.0是一個強大的、高度可用的、與 Java? EE 兼容的中間件環境。它提供一個用於托管和管理 企業應用程序的平台，用戶可以使用這個平台來配置和訪問這些應用程序的相關資源。WebSphere Application Server 是一個 IBM ODM 的可能部署環境之一。
WebSphere Application Server 配置包 含相關的應用服務器、HTTP 服務器、節點、群集、單元和其他資源（如數據庫），稱之為拓撲。對於某一類 的方案（這種方案設計為實現最佳做法並介紹術語以及所做出的決策），推薦使用黃金拓撲。
為了介 紹 ODM 的黃金拓撲，我們將介紹在本文中使用的與拓撲相關的術語。
ODM 拓撲使用了兩種類型的服務 器：
應用服務器是 WebSphere Application Server 提供的 Java 虛擬機 (JVM)，該服務器運行應用程序並提 供服務。
Web 服務器路由 Web 應用程序中的內容請求，而且可以調用在應用服務器上運行的應用程序。IBM HTTP Server for WebSphere Application Server插件提供了該功能，而且還可以實現高可用性策略和工作負載平 衡。
當一個環境中有多台服務器時，可以配置一個邏輯組織來簡化管理，以及更有效地訪問資源。節點 是一組 服務器，托管節點 具有能夠管理其服務器的節點代理。節點的配置記錄在其配置文件中，預先定義的配置文 件更新被稱為擴展 (augmentation)。單元中的節點組 是具有相同可用資源的、獨立的服務器配置以及群集配 置的節點集合。
單元 是托管節點的管理域。向單元中添加節點的過程稱為聯合。部署管理器 是單元 中一個特殊的節點，該節點可提供對單元中所有部分進行管理控制的一個中心節點。當使用部署管理器更改單 元的配置時，必須對所有節點代理執行同步過程。
群集 通常是跨不同托管節點的單元中的一組托管服 務器。群集能夠對應用程序進行工作負載平衡，以便提高性能或者提供高度可用的環境。由於群集的應用程序 部署只有一個邏輯部署目標，因此非常簡單。
群集中的服務器被稱為群集成員，不在群集中的服務器 被稱為獨立服務器。通常部署到獨立服務器的應用程序類型包括那些不需要或者不會從工作負載平衡或高可用 性策略中大量獲益的應用程序。這種情況可能由於以下原因造成的：訪問應用程序的風格、與其他應用程序相 比該應用程序相對重要，或者是應用程序設計的限制。
向 WebSphere Application Server 環境中部 署資源或應用程序應該在某個特定作用域上進行。作用域 是一個層次概念，例如，選擇單元作用域會在該單 元中的群集成員和獨立服務器上部署資源或應用程序。部署作用域非常重要，因為在同一服務器上部署相關應 用程序能夠減少本地 EJB 調用的開銷（與跨服務器調用相比）。
部署作用域 對於在 WebSphere Application 服務器單元中定義可伸縮性非常有用。這個概念通常會定義兩個主線：
單元的水平可伸縮性允許通過復制節點提供其他處理能力，以便增加每個群集中的成員數量。這種類型的 可伸縮性假定是在群集作用域執行部署。工作負載平衡可以利用這個額外的處理能力來創建高度可用的環境， 或者提高應用程序性能。
單元的垂直可伸縮性取決於各個節點的處理能力。這種類型的可伸縮性決定每個節點上可用的處理能力數 量，它可能會限制節點上可用的資源、群集成員、獨立服務器和作為組成部分的應用程序的數量。
為了處理這些可伸縮性問題，我們引入了單元拓撲的概念。單元拓撲 通常可以使用單元拓撲圖（其中兩個 圖在本文的後面部分）來簡明扼要地進行描述，它還針對以下方面介紹了一個單元中的可伸縮配置：
在群集和獨立服務器中部署應用程序
群集中服務器的成員
獨立服務器的標識
獨立服務器和群集到節點的映射
訪問不同作用域上的資源
更加復雜的系統可能需要多個單元，這些單元通過訪問資源、高可用性策略或者業務流程連接在一起。例 如，在准備將應用程序部署到生產單元之前，可以在不同的單元中開發和測試應用程序。我們將引入一個環境 拓撲，在這個拓撲中，每個組件單元都引用了一個特殊的單元拓撲。
為了陳述和解釋 ODM 黃金拓撲， 我們現在將引入 ODM 的組件以及應用它們部署的約束條件。
介紹 ODM 組件和約束條件
ODM 是 IBM 的業務規則、事件管理以及處理系統的實現。有關 ODM 組件的完整介紹，請參閱 ODM 信息中心。通過聯 合存儲庫中存儲的不同用戶角色，可以控制對 ODM 組件的訪問。本文中只是簡要地介紹一下用戶訪問管理。
ODM 包含兩個主要組件：
決策中心 (DC) 能夠進行業務規則設計和生命周期管理，並且由社交媒體框架提供支持。
決策服務器 (DS) 能夠通過它的子組件 “決策服務器規則” 和 “決策服務器事件” 進行業務規則和事 件的配置和處理。
“決策服務器規則” 包含業務規則配置和處理功能。它的 “規則執行服務器 (RES)” 是一個業務規則執 行平台，該平台能夠通過其規則引擎處理 RuleApps 及其構成規則集。RES eXecution Unit (XU) 提供了 Java EE Connector Architecture (JCA 1.5) 和 Service Provider Interface (SPI) 系統級別合約，這兩 個合約允許服務器連接到規則引擎。可以在節點作用域中將 XU 資源適配器存檔 (RAR) 部署到 WebSphere 應 用服務器，或者將其封裝在某個規則應用程序內。
在本文中，我們假定將 XU RAR 部署在 WebSphere 應用服務器中。XU RAR 的安裝和部署是在節點作用域中進行的，因此，可以對節點中的任何群集成員或獨立 服務器進行訪問；它變得可用於多個應用程序，並且可以控制它的 JCA 連接池大小。在單元中使用 Management Bean (MBean) 管理 XU，對此部署它的服務器作用域上必須存在對 MBean JAR 的類路徑引用，或 者必須將 MBean JAR 復制到 WebSphere Application Server lib 目錄中。我們不考慮 XU 獨立於管理模型 運行的情況。到 ODM V8.0.1 為止，除了 JMX API 之外，還必須可以使用 Representational State Transfer (REST) API 來簡化遠程管理。
XU 包含多個支持企業應用程序存檔 (EAR) 文件。需要兩個 EAR 文件來處理 Message Driven Bean (MDB) 和 Enterprise Java Bean (EJB) 規則會話。需要另一個 EAR 文件來處理 Hosted Transparent Decision Services (HTDS)，它將決策服務器規則的規則執行功能顯示為 Web 服務。所有這三個 EAR 文件都必須與 XU 搭配。
圖 1. 決策服務器規則組件
RES 控制台允許執行管理任務，而且在獨立服務器作用域可以部署為企業應用程序。RES 控制台不應 該被大量使用，通常一次只有一個規則管理員訪問它。不運行該控制台也能操作 XU，因此，不應該將它視為 一個重要的故障點。
自從發布 ODM V8.0.1 PureApplication 系統模式以來，推薦使用的另一種方法 是，將 RES 控制台放置在一個群集中，以確保該組件的高可用性。這種方法的缺點是，在執行手動同步之前 ，同時工作在兩個 RES Web 控制台實例上的兩個管理員可能無法看到完全相同的數據。
決策服務器的 另一個組件是 Scenario Service Provider (SSP)，該組件允許測試和模擬 RuleApps，並且實現一個 Decision Validation Service (DVS)。當使用遠程 SSP 時，這個企業應用程序必須與 XU RAR 所在的服務器 搭配。
Decision Server Events 包含一組不同的組件以及與 Decision Server Rules 的關系。事件 運行時是用於企業事件協作、監視和執行的企業應用程序。它部署在獨立服務器上或群集作用域，而且它不能 與應用程序一起打包。假定您的規則和事件項目彼此引用，那麼本地調用的性能優勢為：事件運行時和 XU 可 在同一群集中使用。我們還建議每個事件運行時部署只有一個分配給它的事件項目。
事件運行時提供 了一個管理控制台作為企業應用程序的一部分。由於該控制台通常不會大量使用或者不會一次由多個用戶使用 ，所以，對於部署和使用事件運行時，並沒有施加額外的約束條件。
事件檢測和操作是使用技術連接 器（如文件、用戶控制台和 JDBC 連接器）執行的。當上傳事件項目或者啟動服務器時，會檢測事件應用程序 所需的特殊技術連接器，而且，在與相關事件運行時相同的作用域上，可以將它們部署為企業應用程序。
事件運行時還需要使用一個單元內的消息傳遞基礎架構。如何配置這樣一個消息傳遞基礎架構有很大 的靈活性，我們延遲了消息傳遞提供程序（例如 WebSphere MQ）的選擇，並讓讀者選擇垂直和水平可伸縮性 的一些實現選項。對於在規則應用程序中使用的 MDB 會話，也可以使用消息傳遞基礎架構。通常，本地調用 的性能優勢意味著應該讓該基礎架構可以在與事件運行時和 XU 相同的群集中獲得使用。
當從某個事 件調用規則集時，項目規則運行時和事件運行時必須位於相同的服務器上。
決策服務器的最後一組組 件是 Rule Designer 和 Event Designer。這些是基於 Eclipse 的集成開發環境 (IDE)，提供了一個可以構 造規則和事件項目並且可以部署到 Rule Execution Server 和事件運行時的用戶界面。Rule Designer 和 Event Designer 位於台式計算機上，並在該計算機上運行，盡管它們已經連接到基於服務器的組件，但對於 黃金拓撲而言，它們仍然位於外部。
與決策服務器相比，決策中心的子組件比較少。它的 Business Console 和 Enterprise Console 被用作一個企業應用程序，共同部署在獨立服務器上或群集作用域上。創建 業務規則時，Business Console 能夠在業務用戶之間進行協作，而 Enterprise Console 的功能更多，包括 運行模擬、將產品部署到決策服務器和存儲庫控制。Enterprise Console 還連接到 Rule Solutions for Office，它能夠在 Microsoft Office 文檔中編輯業務規則。預計這些控制台會得到連續大量的使用，因此將 它們部署在群集作用域中會比較好。
在 ODM V8.0.0.1 IBM Business Space（它由一組部署在獨立服 務器或群集作用域的企業應用程序組成）中，需要利用決策中心和事件小工具。Business Space 小工具和一 個隨附的事件測試企業應用程序都部署在與事件運行時相同的服務器上。自 ODM V8.0.1 起，決策中心和事件 小工具就已經被替換為一個 JEE 應用程序，不再需要 Business Space。
ODM 需要訪問若干個數據庫 。Decision Server Rules 使用了以下數據庫：
Decision Server Rules (RES) 數據庫，該數據庫存儲結構為 RuleApps、Rulesets 以及相關的 Java eXecutable Object Models (XOM) 的可執行規則產品。
Decision Warehouse 數據庫，該數據庫存儲規則執行跟蹤信息。
Decision Center 有自己的數據庫，用於暫存業務規則產品和 DVS 報告。此外，Decision Server Events 和 Business Space（在 ODM V8.0.0.1 中）也有自己的數據庫。
這些數據庫的配置（就可伸縮性和高 可用性而言）不在本文的討論范圍之內。用於連接到這些數據庫的數據源應該部署在節點作用域內，以便與節 點相關的資源（如數據庫連接 JAR 的磁盤上的位置）可以得到正確配置，同時還要確保從 ODM 組件和其他企 業應用程序訪問數據源的寬度。
黃金拓撲的描述和實現
以下部分描述 ODM 黃金拓撲並介紹設 計決策背後的動機：
Operational Decision Manager 拓撲（在 ODM V8.0.0.1 中被稱為 Decision Management 拓撲）提供了 在一個單元內進行規則與事件的創作、測試和執行的全部功能。
Decision Server 拓撲允許在一個單元內進行規則與事件的測試和執行，無需提供 Decision Manager 拓 撲的創作功能。
利用這些推薦的拓撲可在應用程序部署方案的各個階段構建環境，從開發階段到測試和生產階段。
設計拓撲的目的是最大程度地提高性能、提供工作負載平衡，以及提供 ODM 的所有功能。我們首先詳細地 介紹一下 Decision Manager 拓撲，然後在本文的後面部分介紹了實用的分步部署說明。
Operational Decision Manager 黃金拓撲
Operational Decision Manager 黃金拓撲，如圖 2 所示，提供了規則與 事件的創作、測試和執行的全部功能。
圖 2. Operational Decision Manager 黃金拓撲
在此拓撲中，每個節點（部署管理器除外）都包含一個 Decision Center 群集和一個 Decision Server 群集。由於 RES 控制台不是此拓撲的重要組件，因此它沒有任何可伸縮性要求，它在其中一個節點上 的獨立服務器中運行。工作負載平衡是通過使用 WebSphere Application Server 的 IBM HTTP Server 和 Web Server 插件實現的。故障轉移或其他高可用性策略的實現不在本文的討論范圍之內。
設計 Decision Server 群集的目的是利用統一服務器中本地 EJB 調用的效能，以便最大程度提高規則與事件的執 行、測試和模擬性能。因此，所有規則與事件的測試、模擬和執行都是在此群集內執行。出於同樣的原因，此 處還提供了用於事件處理的消息傳遞基礎架構（也可以通過 MDB 規則會話使用）以及使用規則和事件的應用 程序。此群集中構成 ODM 的組件包括 SSP、EJB、MDB、HTDS、事件運行時，以及各種事件連接器企業應用程 序。
在節點作用域內部署 XU RAR 和數據源。在 Decision Manager 拓撲中，對於位於節點內任何服 務器中的應用程序來說，這些資源非常有用。此外，將 XU RAR 部署到節點作用域還允許從事件運行時和其他 Decision Server 群集企業應用程序進行有效的本地調用。
Decision Center 控制台的性能和可伸縮 性要求與 Decision Server 群集中所提到組件的性能和可伸縮性要求有所不同。因此，它們的企業應用程序 已經轉移到單獨的 Decision Center 群集中。此方法在設計拓撲時允許有一定的靈活性；如果您不需要創作 功能或者希望最大程度地減少硬件資源的使用，那麼您可以考慮刪除此群集（在 Decision Server 拓撲中建 議這樣做）。
由於可能會有多個用戶同時訪問服務和應用程序，所以我們建議調整 XU、事件運行時、 消息傳遞基礎架構、數據源和 HTDS（通過 Ruleset 屬性 ruleset.xmlDocumentDriverPool.maxSize）的並發 選項，以便提供更高的性能。
Decision Server 黃金拓撲
圖 3. Decision Server 黃金拓撲
Decision Server 拓撲（如圖 3 所示）與 Operational Decision Manager 拓撲類似，但不包含 Decision Center 群集。因此，該拓撲允許進行規則與事件的測試和執行，但沒有創作功能（Rule Designer 和 Event Designer 提供的那些功能除外，它們單獨在一個台式計算機上運行）。
環境拓撲
將 您的生產環境與不同單元中的測試和其他環境分離（如中所述）有幾個好處，例如，提供了專門的測試環境， 而且有助於防止出現災難性故障。環境拓撲是一個分階段的部署拓撲，它由映射到連續部署階段的五個單元組 成：
開發單元：在該單元中，首先會開發規則和事件應用程序。
測試單元：在該單元中執行模擬和集成測試
暫存單元：在該單元中，業務用戶可以編輯規則和事件項目
預生產單元：該單元與生產階段的配置完全相同
生產單元：在該單元中，會對生產數據進行規則和事件處理
這個由五個階段組成的示例是隨後要進行討論的參考。例如，您可以選擇只提供三個階段或單元，或者開 發環境只是一個獨立服務器。我們的目標是幫助您選擇一個滿足您的特定要求和資源限制的環境拓撲。
圖 4 就是環境拓撲光譜（范圍從集中管理到最大程度隔離）中極限情況的一個例子。
圖 4. 集中決策管理
上面所示的集中管理方法的優缺點概況如下：
優點：
可以將業務創作的某一點部署到所有環境上
可以利用 Decision Center 分支和合，並在任何選定的 Decision Server 上部署可執行的規則
具有 Decision Center 和 Decision Server 群集環境的高可用性
隔離創作和執行工作負載
缺點：
不允許專門為每個階段自定義 Decision Center
共享的 Decision Center 存儲庫變為創作和部署的單點故障，除非該數據庫已針對高可用性進行了配置
需要調整作用域授權操作的訪問權限
沒有用於測試維護活動以及其他高磁盤更改的副本 Decision Manager 環境
相對的極限情況，如圖 5 所示，它由所有階段的隔離管理和執行單元組成。
圖 5. 分階段決策管 理
優點：
各個開發生命周期階段之間完全隔離。所有 ODM 運行時都位於一個單元中
根據階段和單元隔離進行創作和執行
在每個單元中可以采用不同方式自定義 Decision Center，包括安全自定義
具有 Decision Centers 和 Decision Servers 群集的高可用性
缺點：
要配置和管理更多 JVM 和 Decision Center 數據庫
必須跨各個單元同步 Decision Center 存儲庫內容，從開發單元到生產單元
為了舉例說明選擇環境拓撲之後的整個過程，我們考慮一個方案，在該方案中，前三個階段單元都包含一 個 Operational Decision Manager 拓撲，後兩個階段（預生產和生產）具有相同的拓撲，即 Operational Decision Manager 拓撲或 Decision Server 拓撲。後兩個階段的單元拓撲的選擇取決於您是否需要在生產環 境中使用 Decision Center 的創作功能。預生產階段單元提供在到達生產階段之前識別規則和事件應用程序 意外行為的最後機會。
在前三個階段中，當應用程序進度通過這些階段時，它會使用規則設計器、事 件設計器或決策中心企業控制台，從一個階段單元中的決策中心提升到下一個階段單元中的決策中心。在每個 階段單元內，都會將應用程序從決策中心部署到決策服務器。將每個階段分離，以便向應用程序中添加特定於 階段的自定義和測試。
如果預生產階段和生產階段也包含 Operational Decision Manager 拓撲，則 會在決策中心群集之間繼續提升規則和事件項目。當分離各個階段時，可以簡化用戶訪問管理，此外，當對共 享決策服務器沒有依賴時，會更容易測試 ODM 更新（如修復包）。但是，就多個決策中心群集所需的硬件資 源而言，該實現過於昂貴。而且，這些分離的群集的管理、自定義和同步都可能會涉及其他成本。
或 者，如果預生產階段和生產階段都包含決策服務器拓撲，那麼暫存階段單元的決策中心群集會在後三個階段的 決策服務器群集之間有效共享。當應用程序進度通過這些階段時，在每個階段單元中將其從決策中心部署到決 策服務器。這種實現的主要好處就是可以通過集中處理來簡化各個階段之間 RuleApp 版本的管理。
這 種實現的局限性包括：由於將應用程序部署在多個單元中，所以增加了用戶訪問管理的復雜度，尤其是在敏感 的生產單元中。暫存階段單元要求對它的共享決策中心群集精心管理並盡可能提供額外的資源，以便決策中心 保持可用並且能夠響應。此外，由於它的決策中心數據庫變成了單點故障，因此需要尤為注意確保它的可用性 （通過復制或其他方式）。
在 ODM V8 中部署決策管理器拓撲
本節介紹了如何利用 WebSphere ODM V8.0.0.1 中包含的配置文件擴展和腳本設置決策管理器黃金拓撲的步驟。如果忽略特定於業務空間的任 務，那麼該操作同樣適用於 IBM ODM V8.0.1。
主要步驟如下：
創建和擴展配置文件
創建和配置群集
安裝和配置 IBM HTTP 服務器以及 WebSphere 應用服務器 Web 服務器插件。
先決條件
創建部署拓撲之前，確保在每個節點中安裝了下列軟件：
WebSphere Application Server Network Deployment V8.0.0.3（使用業務空間）
WebSphere eXtreme Scale V7.1.1.1（如果使用 Event Server 組件）
WebSphere ODM 8.0.0.1 Decision Center
WebSphere ODM 8.0.0.1 Decision Server（使用 Event Server 組件，如果需要）
創建和擴展配置文件
大多數 ODM 用戶都會使用隨產品一起提供的腳本默默地創建和擴展配置文件 。但對於本文，我們選擇使用配置文件管理工具（Profile Management Tool，PMT）來執行此操作，因為第一 次使用它的用戶能夠看到所有所需的步驟和輸入參數。
創建部署管理器配置文件
注意：如果您 創建過部署管理器配置文件，那麼可以跳過這一部分。
每個單元都有一個部署管理器節點和一個部署 管理器配置文件。創建部署管理器配置文件的步驟如下：
啟動配置文件管理工具 (PMT) 並選擇 Create。
選擇 WebSphere Application server => Management，如圖 6 所示，然後單擊 Next。
圖 6. 選擇 部署環境
選擇 Deployment Manager 作為服務器類型，如圖 7 所示。
圖 7. 選擇服務器類型
單擊 Next，然後選擇 Typical profile creation 選項並單擊 Next。（除非您想更改默認名稱和端口， 在這種情況下，您應選擇 Advanced profile creation。）
在 Administrative Security 頁面上，選擇 Enable administrative security 並提供您的安全憑據，如 圖 8 所示。
圖 8. 啟用管理安全
單擊 Next。系統將為您提供一個與圖 9 中所示內容類似的配置文件創建摘要。單擊 Create。
圖 9. 配置文件創建摘要
創建配置文件之後，您可以選擇 First steps 來驗證安裝並啟動部署管理器。在將單元中的其他節點聯合 到該部署管理器中之前，需要啟動部署管理器。
創建自定義節點配置文件
在我們的拓撲中，部署管理器位於與群集成員節點不同的計算機上，因此 ，我們不會在部署計算機上創建自定義配置文件。對於單元中的其他每個節點，我們將創建一個自定義配置文 件。自定義配置文件用於將節點聯合到部署管理器；它能夠通過節點代理讓部署管理器在該節點上創建和管理 應用服務器。若要創建自定義配置文件，請執行以下操作：
通過啟動配置文件管理工具來創建自定義節點。選擇 Create，然後選擇 WebSphere Application Server => Custom profile，如圖 10 所示。
圖 10. 創建自定義配置文件
單擊 Next 並選擇 Typical profile creation。
在下一個頁面上，指定將該節點聯合到部署管理器所需的參數：部署管理器主機名、部署管理器 soap 端 口和部署管理器身份驗證憑據，如圖 11 所示，然後單擊 Next。確保部署管理器已啟動。注意：通常最佳做 法是僅在配置文件擴展之後聯合節點，但在本例中，在此階段聯合節點沒有問題。
圖 11. 指定節點聯合參 數
在下一個頁面上，單擊 Create。
對單元部署管理器將要管理的所有節點重復步驟 1-4。
擴展部署管理器和自定義配置文件
下一步是擴展部署管理器配置文件以及具有 ODM 配置文件的所 有自定義配置文件。如果使用業務空間，那麼還需要使用業務空間來擴展部署管理器配置文件。
ODM 黃金拓撲要求您使用決策中心、決策服務器和決策服務器事件更新部署管理器配置文件。僅使用決策服務器事 件更新自定義配置文件，如表 1 所示。
若要擴展配 置文件，請執行以下操作：
停止部署管理器。
使用決策中心擴展部署管理器配置文件，方法是在 Augment Selection 對話框中選擇相應的更新選項，如 圖 12 所示，然後單擊 Next。
圖 12. 選擇擴展選項
指定 ODM 安裝位置（在我們的示例中是 /opt/IBM/WODM80）。
單擊 Next 並在下一個頁面上單擊 Augment。
采用類似的方法，使用決策服務器擴展部署管理器配置文件。
使用決策服務器事件擴展部署管理器配置文件的步驟如下：
選擇擴展並提供 ODM 安裝位置。
在 Database Configuration 頁面上（如圖 13 所示）提供所需的數據庫參數，並單擊 Next。建議您在 繼續到下一步之前，測試數據庫連接。
圖 13. 指定數據庫參數
在下一個頁面上，選擇消息傳遞提供程序（我們接受默認值），然後單擊 Augment。該操作還執行 eXtreme Scale 擴展。您應該已完成四個部署管理器配置文件的擴展，如圖 14 所示。
圖 14. 已擴展的配置文件
使用業務空間擴展部署管理器配置文件。
使用決策服務器事件擴展自定義節點（該操作還執行 eXtreme Scale 擴展）。
創建決策管理器群集
接下來，您需要創建決策管理器群集：決策中心和決策服務器。
創 建決策中心群集
創建和配置決策中心群集的最快速方法是運行 Configure DC Cluster 腳本 (configureDCCluster.sh)，該腳本位於部署管理器的 bin 目錄中。除了創建該群集之外，該腳本還執行以下 操作：
啟動部署管理器服務器（如果尚未啟動）。
在群集級別安裝決策中心應用程序 (teamserver)。部署應用程序時，會將用戶映射到應用程序組。
在節點級別配置 JDBC 提供程序和數據源*。
配置安全性。
創建 rtsAdmin、rtsInstaller、rtsUser1 和 rtsConfig 用戶。
配置用戶和組。
將用戶和組映射到角色。
啟動群集、服務器和應用程序。
* 此版本提供的腳本僅為一個節點創建定義，這個節點由參數 -targetNodeName 標識。您可以通過更改 目標節點名稱再次為其他所有節點運行該腳本，或者也可以手動配置其他節點。
完成以下步驟，以便 使用該腳本創建群集：
運行該腳本之前，您需要打開 WAS_Installdir/profiles/Dmgr01/bin/rules/configureDCCluster.properties 文件並提供群集配置屬性， 如以下示例所示。
#
# Cluster base configuration
#
wodm.dsrules.clusterName=DecisionCenterCluster
wodm.dsrules.rulesMgrServerName=RulesMgrSrv
#
# Database configuration
# Supported database type:
# - DB2
# - Oracle
# - MSSQL
#
wodm.dsrules.db.type=DB2
wodm.dsrules.db.jdbcDriverPath=
/opt/IBM/WebSphere/AppServer/jdbcdrivers/DB2
wodm.dsrules.db.name=WODMDC
wodm.dsrules.db.hostname=ilogds01.hursley.ibm.co,
wodm.dsrules.db.port=50000
wodm.dsrules.db.user=db2inst1
wodm.dsrules.db.password=xxxx
設置 WODM_HOME（例如，通過發出命令 export WODM_HOME=/opt/IBM/WODM80）。
轉到 WAS_Installdir/profiles/Dmgr01/bin 目錄並運行 configureDCCluster 腳本，如以下示例所示：
./configureDCCluster.sh -dmgrAdminUsername admin -dmgrAdminPassword admin -clusterPropertiesFile ./rules/configureDCCluster.properties -dmgrHostName ilogds01.hursley.ibm.com -dmgrPort 8879 -targetNodeName ilogds02Node02
完成該腳本後，您應該看到以下消息： [wsadmin] GBRPC0028I: The cluster is up and running!
選擇 WebSphere application server clusters => DecisionCenterCluster => Cluster members 並選擇 New，以創建新的群集成員。在我們的示例中，將創建名為 dm.dc02 和 dm.dc03 的兩個新成員，一個 在 ilogds02 節點上，另一個在 ilogds03 節點上，如圖 15 所示。
圖 15. 創建新的群集成員
創建群集成員後，確保節點代理已啟動，然後啟動決策中心群集。
創建決策服務器群集
若要創建決策服務器群集，請執行以下操作：
打開 WAS_Installdir/profiles/Dmgr01/bin/rules/configureDSCluster.properties 文件並提供決策服 務器群集配置屬性，如圖 17 所示。請注意，我們正在為規則執行服務器控制器創建一個額外的服務器，名為 RulesMgrSrv。
#
# Cluster base configuration
#
wodm.dsrules.clusterName=DecisionServerCluster
wodm.dsrules.rulesMgrServerName=RulesMgrSrv
#
# Database configuration
# Supported database type:
# - DB2
# - Oracle
# - MSSQL
#
wodm.dsrules.db.type=DB2
wodm.dsrules.db.jdbcDriverPath=
/opt/IBM/WebSphere/AppServer/jdbcdrivers/DB2
wodm.dsrules.db.name=WODMDS
wodm.dsrules.db.hostname=ilogds01.hursley.ibm.co,
wodm.dsrules.db.port=50000
wodm.dsrules.db.user=db2inst1
wodm.dsrules.db.password=xxxx
使用類似於以下內容的命令運行 configureDSCluster 腳本：
./configureDSCluster.sh -dmgrAdminUsername admin -dmgrAdminPassword admin -clusterPropertiesFile ./rules/configureDSCluster.properties -dmgrHostName ilogds01.hursley.ibm.com -dmgrPort 8879 -targetNodeName ilogds03Node02
該腳本執行以下操作：
在節點級別安裝 JDBC 提供程序、執行單元 (XU) JCA 連接器以及數據源。
創建一台不屬於任何群集的服務器，並在該服務器上安裝 Rule Execution Server 控制台。
配置安全性。
創建 resAdmin、resDeployer、resMonitor 用戶和各個組。
將 HTDS 和 Scenario Service Provider (SSP) 部署到群集成員。部署應用程序時用戶映射到應用程序組 。
啟動部署管理器服務器（如果尚未啟動）。
啟動群集、服務器和應用程序。
運行該腳本之後，您可以在其他節點中手動配置 XU 適配器和數據源。或者，您也可以對每個不同的目標 節點運行該腳本。該腳本會識別已經執行的操作，並且僅在每個節點上創建數據源和 XU 定義。如果出錯，可 以通過使用 -uninstall 參數運行相同的命令來卸載所有群集定義。
最後，采用與決策中心群集所使用的類似方式，創建決策服務器群集成員。此時，單元拓撲應該如圖 16 所示。
圖 16. 得到的本地拓撲
這是前面所述的有效的 Operational Decision Manager 黃金拓撲，但您仍然需要完成決策服務器事件的 配置。
配置決策服務器事件
在決策服務器群集中安裝和配置決策服務器事件組件。針對該群集 中的個群集成員（應用服務器），執行以下操作：
創建一個新的 wbe.home Java 自定義屬性（選擇 Servers => Server Types => WebSphere application servers => server-name => Java and Process Management => Process Definition => Java Virtual Machine => Custom properties），該屬性指向 ODM 安裝目錄（例 如，/opt/IBM/WODM80）。
增加 JVM 堆大小。至少（假定 64 位計算機）將初始堆大小設置為 768，將最大堆大小設置為 1024。
選擇 WebSphere application server clusters => DecisionServerCluster => Cluster members => dm.ds02 => Container services => Startup beans service，然後選擇 Enable service at server startup。
現在，您需要將決策服務器群集配置為服務集成總線的成員。為此，首先需要為該消息存儲創建數據庫和 數據源，如下所示：
創建一個數據庫，例如 DSEME。
在決策服務器群集中創建一個群集級別的 JDBC 提供程序。
創建一個數據源（使用 JNDI 名稱，如 jdbc/eventsme）。
現在，對決策服務器事件總線執行以下配置步驟：
選擇 Service integration => Buses => WbeBus => Bus members 並單擊 Add。選擇 Cluster ，然後從下拉列表中選擇 DecisionServeCluster。
在下一個頁面上，選擇消息傳遞引擎策略類型。以下示例使用 High Availability，如圖 17 所示，但是 ，對於可伸縮的生產環境，建議使用 Scalability with high availability。
圖 17. 選擇策略類型
在下一個頁面上，為消息暫存選擇 Data store。
單擊 Next，然後選擇消息傳遞引擎的名稱。指定 JNDI 名稱（如 jdbc/eventsme）並選擇一個相應的身份 驗證別名。確保已選中 Create tables 並單擊 Next。
根據需要更改堆大小，然後單擊 Finish。
下一步是執行所需的 WbeBus 和 JMS 配置。執行該過程的第 7 步至第 13 步。此外，在 WbeBus 上，創 建以下主題空間目標：Default.Topic.Space、WbeHistoryTopicSpace 和 WbeTopicSpace。
對於生產環境，還應該考慮至少配置三個 Websphere eXtreme Scale 目錄服務器：一個在部署管理器節點 中，另個兩個在兩個節點代理節點中。
由於要將連接器部署到群集，因此您將需要選擇 Resource environment entries => WbeSrv01 => Custom properties 並創建以下條目：
值為 cluster 的 com.ibm.wbe.ca.deploy.target.type
值為 DecisionServerCluster 的 com.ibm.wbe.ca.deploy.target.name（它是要在其上部署連接器應用程 序的群集的名稱）
安裝並配置 IBM HTTP 服務器和 WebSphere Application Server 的 Web 服務器插件
我們的拓撲 包括一台 IBM HTTP 服務器，該服務器擁有 WebSphere Application Server 的 Web 服務器插件，該服務器 用於路由傳入的 HTTP 請求，並對該請求進行負載平衡。在生產系統中，將在單獨的計算機上安裝一台或多台 HTTP 服務器。為了簡便起見，我們只使用同一物理服務器上安裝的 HTTP 服務器的一個示例作為部署管理器 。由於部署管理器計算機上沒有托管節點，因此采用與 HTTP 服務器安裝在遠程計算機上相同的方法配置該插 件。若要設置該配置，請執行以下操作：
安裝 IBM HTTP 服務器。
安裝 WebSphere Application Server Web 服務器插件。
安裝 WebSphere Customization Toolbox。
注意：上面的組件是 WebSphere Application Server Supplements 程序包的一部分，因此可以使用 IBM Installation Manager 進行安裝。
啟動 WebSphere Customization Toolbox 並選擇 Web Server Plug-ins Configuration Tool。
單擊 Add 添加您安裝的插件的位置。
在 Web Server Plug-in Configurations 選項卡上，單擊 Create。
選擇 IBM HTTP Server V8 並單擊 Next。
選擇 64-bit 並單擊 Next。
提供 Web 服務器配置文件位置和端口（在我們的示例中，分別為 /opt/IBM/HTTPServer/conf/httpd.conf 和 80）。
單擊 Next 並為 Web 服務器設置一台管理服務器（這是可選的）。
提供惟一的 Web 服務器定義名稱（我們接受默認值 webserver1）並單擊 Next。
由於前面所解釋的原因，選擇 Remote supply 並指向部署管理器計算機。
單擊 Next 並選擇部署管理器配置文件。
單擊 Next，然後單擊 Configure and Finish。
將生成的 configurewebserver1.sh 文件從插件的 bin 目錄復制到應用服務器的 bin 目錄，並運行此命 令：configurewebserver1.sh Dmgr01 admin admin（假定部署管理器配置文件名稱為 Dmgr01，WebSphere Application Server 用戶 id 和密碼為 admin）。
從部署管理器的管理控制台中，選擇 System administration => Save Changes to Master Repository => Synchronize changes with Nodes 並單擊 Save。
選擇 Servers => Server Types => Web servers。選擇 Web 服務器，然後單擊 Generate Plug-in 。
成功生成插件配置文件 (plugin-cfg.xml) 之後，單擊 Propagate Plug-in 將配置文件傳播到插件的配置 目錄（在我們的示例中為 /opt/IBM/WebSphere/Plugins/config/webserver1）。
最後一步是確保所有 Web 模塊也都映射到 Web 服務器。
現在，您應該能夠指向 <webserver host name>/teamserver 以訪問 Decision Center Enterprise 控制台。同樣，指向 <webserver host name>/res 可訪問 RES 管理控制台。
我們將保留業務空間的配置，作為需要使用 ODM 業務空間小 工具的 ODM V8.0.0.1 用戶的練習之用。請注意，自從 ODM V8.0.1 起，ODM 不再需要業務空間。
黃 金拓撲的適用性
本文中提供的適用於群集部署的建議和說明僅與 ODM 和 WebSphere Application Server ND V8.x 有關。有關其他版本的有關其他版本的 ODM 和 WebSphere Application Server 的信息，請 參閱它們的產品信息中心。此外，本文並未考慮任何 SupportPac 產品；有關群集部署的相關信息，請參閱 SupportPac 附帶的文檔。
本文中所述的黃金拓撲適用於需要使用 ODM 提供的所有規則和事件執行、 測試和模擬功能的方案。並非決策服務器群集的所有功能都與您的特定要求有關。例如，您的項目可能未涉及 任何事件處理，或者您的環境拓撲的生產階段可能沒有要求 SSP。我們建議對每個拓撲進行自定義，以便刪除 不需要的組件，從而最大程度地降低資源使用，尤其在性能和可靠性非常關鍵的情況下。
業務空間和 決策服務器事件對於群集部署和測試產品有一些特殊限制，以下小節將對這些限制進行介紹。
業務空 間和決策服務器事件的限制
其中一個限制是每個事件運行時部署只能有一個與其關聯的事件項目。我 們還建議，在一個單元內，只能執行一個事件運行時部署。如果您有多個事件項目，則需要對這些項目進行組 合，或者每個事件項目需要一個已部署事件運行時的單獨單元。
建議不要在群集環境中使用事件測試 程序企業應用程序和業務空間小工具。同樣，也不支持在適用於 z/OS 群集的 WebSphere Application Server 上對事件運行時進行群集部署，必須將事件運行時部署在一台服務器上。
如果需要使用這些功 能，則拓撲內一個單獨的獨立服務器可以部署這些組件及其依賴性。例如，將事件測試企業應用程序移動到一 台獨立服務器也將需要移動事件運行時，因為它們必須搭配使用，我們建議僅在一個單元中部署一個事件應用 程序。如果將組件從決策服務器群集移動到一台獨立服務器，則必須考慮一些注意事項，即應用程序和資源仍 然可以進行本地調用，以及隨之而來的性能懲罰。以下部分將詳細討論消息傳遞的關注事項。
可伸縮 性、高可用性以及性能
本文中所述拓撲的很多實現細節已留給讀者去選擇。在決策管理器拓撲的部署 說明中，工作負載平衡策略以及消息傳遞基礎架構的設計都面向高可用性。有關高可用性、可伸縮性策略以及 資源隔離與進行本地調用的性能優勢之間的權衡。
性能監視
監視您的環境的性能和可靠性，這 對於確定是否需要采取提高水平或垂直縮放的措施極為重要。某些常見的瓶頸包括 CPU、內存、磁盤訪問以及 其他資源訪問（如數據庫或隊列）。有關監視 WebSphere Application Server 環境的指南不在本文的討論范 圍之內，但可以使用 WebSphere 性能監視基礎架構和 IBM Tivoli Composite Application Manager 產品系 列執行。
結束語
在本文中，我們學習了有關 Operational Decision Manager 組件的知識，以 及這些組件如何安裝和配置為 WebSphere Application Server ND 部署拓撲，從而獲得高可用性和水平可伸 縮性。我們還了解了決策管理解決方案各個階段，以及支持每個階段所需的部署環境類型。最後，逐步完成了 安裝和配置 Operational Decision Manager 黃金拓撲的步驟。
