為高可用性環境中分布式 DB2 Universal Database (DB2) Version 8

做HA+DB2的項目倒是有，但是從來也不考慮license，也沒做那么復雜的項目，倒是分區功能想嘗試一下，哈。

簡介
客戶之所以選擇 IBM® DB2® Universal Database™，是因為它能夠在難于置信的時間內體現其價值，能夠在各種不同的環境之間伸縮和整合，還有其健壯性以及極少的停機時間（包括計劃內的停機和計劃外的停機）。在本文中，我們將重點討論 DB2 的高可用性，但不是從功能的角度來談（這方面已經有很多的文章了），而是從許可的角度來談。要得到關于高可用性環境中 DB2 技術方面的好資料，我們建議您購買一本由 Chris Eaton 和 Enzo Cialini 合著的 The High Availabilty Guide for DB2 （ISBN 0131448307）。（注意：這本書沒有包括新的高可用性增強，例如 DB2 V8.2 中具備的 High Availability Disaster Recovery，要了解更多關于這方面的信息，請參閱 DB2 V8.2網頁。）

我們聽到了很多關于高可用性（high availability，HA）環境中 DB2 的許可方面的問題，高可用性環境的設計目標是解決意外停機（有時候也包括計劃內的停機）情況下的配置問題。通常，人們的第一層困惑是：在為自己的高可用性環境中數據庫產品定價時，不同供應商總是花樣百出。令人高興的是，IBM 在許可方面采取更為體諒的做法，所以更有可能為您的企業節省資金。

另一層困惑主要集中在討論高可用性時所使用的術語方面。例如術語 集群。有時候 IT 界將高可用性環境稱作集群。而我們不喜歡再使用這個術語，因為該術語用到后來已經有點被用濫的感覺，集群可以指可伸縮性方面的集群（例如 DB2 Enterprise Server Edition 中具備的數據庫分區特性（DPF）），也可以指可用性方面的集群（例如，在一組 Windows 服務器上使用 Microsoft Cluster Server）。盡管我們不喜歡這個術語，但還是用了它。因此，對于本文，當提到術語 集群時，我們指的是高可用性方面的集群（另行注明的除外）。為簡單起見，在與客戶、同事等討論集群時，我們建議在術語集群前面加上 高可用性或 可伸縮性。

另一個容易產生困惑的地方源自在討論出現停機事件情況下，用來描述將用作故障轉移服務器的服務器的術語。如果您接觸這一方面的時間比較長（并不是說您年齡比較大，而只是說您在這方面有數年的職業生涯），那么很可能對描述這種服務器的術語已經很熟悉了。這些術語包括： idle、 active、 cold、 warm、 hot、 passive等。

大多數情況下，IBM eServer 文獻使用 cold、 warm和 hot這幾個術語來描述備用（standby）服務器。不過，在 DB2 這一領域有所不同。DB2 使用術語 idle和 active來描述備用數據庫服務器。因此，DB2 中采用的定價和許可方面的術語可能與其他 IBM 軟件產品有所不同。這也是常常令客戶產生困惑的源頭。因此，通過閱讀本文可以幫助您分清這些術語，并 知其內情。

在 圖 1中，我們將大多數常見的用于描述 HA 環境的術語映射為 DB2 術語：

圖 1. 業界高可用性術語與 DB2 術語的對照

在前面的圖中，我們在每種類別下面添上了一條 一般經驗法則（general rule of thumb ），但是在讀完本文之后，這些法則對您來說就是一目了然了。而且要記住，這是一般法則，對于某臺機器，您可能在 DB2 中稱之為 idle備用機器，而在其他地方又稱之為 hot備用機器。

對于高可用性環境中 DB2 的許可取決于您對一些關鍵問題的回答，這些問題包括：

• 您安裝了什么版本的 DB2 服務器？它是 DB2 Express、DB2 Workgroup Server Edition (DB2 WSE)、DB2 Workgroup Server Unlimited Edition (DB2 WSUE) 或者 DB2 Enterprise Server Edition (DB2 ESE) 中的哪一種？
• 您要怎樣為 DB2 服務器頒發許可？這取決于您所購買的 DB2 的版本，您可以有這樣幾種選擇：并發用戶（功能）許可，注冊用戶/指定用戶許可，或者處理器許可。（如果您想看到關于所有分布式 DB2 服務器以及如何為它們頒發許可的概述，請參閱 Paul Zikopoulos 所著的 哪一個分布式 DB2 UDB V8 版本適合您？。）
• 當出現 has not故障時，如何使用備用機器？是將它用作 DB2 事務和查詢工作的生產服務器嗎？它是不是空閑并等待故障的發生？也許它正在執行某種級別的工作，而只是在出現故障事件時幫助啟動恢復？簡言之，當一切正常時，備用服務器正在做什么與如何為那臺服務器上的 DB2 獲得許可有很大的關系。
• 您是否正在使用 DB2 V8.2 中新的 High Availability Disaster Recovery (HADR) 產品？

最適合用來開始我們的討論的地方是術語 —— 我們大家的看法都是一致的。如前所述，DB2 定義了兩種類型的備用服務器： active 和 idle 。

active standby
在 active standby這種配置中，所有服務器都有用于服務用戶事務和查詢的、獨立的、運行著的 DB2 數據庫。這種配置有時候被稱作 active/active配置，因為集群中的所有機器在所有時候都在執行某種級別的有用工作。如果集群中的某一臺服務器出現故障，那么集群軟件將把出故障的服務器上的工作負載轉移到集群中仍然正常的一臺服務器上。

如果出現了故障，那么資源的轉移將使 active 備份服務器（仍然正常運行的機器）的工作負載加倍，因為現在這臺機器必須處理它原先的工作負載再 加上出故障的服務器的工作負載。因此，在設置高可用性 active/active 環境時，需要考慮這一點。如果您是一名數據庫管理員（DBA），并且您所仰仗的只是一個苛刻的服務水平協議（SLA），那么這未必是最好的選擇（除非調整其規模）。

總而言之，在 DB2 中，active 備用服務器是在正常運行期間用來進行服務用戶事務和查詢的機器。當集群內另一臺服務器出現故障時，active 備用服務器將接過出故障機器上的負載，同時還要處理在正常運行期間它自己所執行的工作。因為 active 備用機器仍被用于用戶事務和查詢，即使沒有故障出現， 它也必須是被完全許可的。例如，假設有兩個數據庫分別處在不同的機器上，其中一臺機器上運行著一個 ERP 包，另一臺機器處理一些 SCM 工作。如果 SCM 數據庫出現故障，那么運行著 ERP 工作負載的機器將不得不同時為所有的 SCM 用戶提供服務。

圖 2展示了一個 active/active standby 場景。在這個例子中，有兩臺服務器，在正常運行期間，它們都被用來處理事務和查詢工作負載（實心框表示在出現故障之前每臺機器上的工作負載，交叉線框是當兩臺機器分別出現故障時，工作負載所出現的地方）。當機器 2 出現故障時，它的工作負載被轉送到它的故障轉移伙伴（即機器 1）那里。在這個場景中，相對于機器 2，機器 1 是一臺 active 備用服務器（當您仔細觀察這個圖時，您會發現反過來也是類似的，注意機器 2 上原屬于機器 1 的交叉線框）。這種類型的配置常常被稱作 高可用性集群對（high-availability clustering pair），在當今的 IT 界，這是很常見的。

機器 1 和機器 2 一直都被用于自己的事務和查詢工作負載管理，當機器 2 出現故障時，機器 2 上的 DB2 工作負載被傳送到機器 1。同樣，在這種情況下，如果沒有考慮到承擔機器 2 出故障的工作負載而對機器 1 的資源進行調整（反之亦然），那么在出現停機情況并導致工作負載的轉移之后，就會引起性能問題。

圖 2. 機器 1 是相對于機器 2 的 active standby。當機器 2 出現故障時，機器 2 的工作負載被轉移到機器 1

對于 active 備用機器在許可方面的考慮
作為一般經驗法則，active/active 配置的定價方式應該與各服務器沒有參與高可用性集群情況下的定價方式相同（也存在一些例外，我們在后面會講到）。接下來的小節將詳細介紹對于不同的 DB2 服務器許可方式，您應該知道的一些許可方面的考慮事項。

處理器許可：對于任何按照 處理器許可模型頒發許可的 DB2 服務器產品（例如 DB2 Express、DB2 WSUE 和 DB2 ESE），active 備用服務器（這個例子中是機器 2）上的處理器都必須得到許可。

在 圖 2展示的例子中，假設每臺機器在一個雙 CPU 的服務器上運行 DB2 Express，則必須獲得的許可為： 2 個服務器 x 2 個處理器= 4 個處理器。

并發用戶：對于按照 并發用戶模型進行許可的 DB2 服務器產品（這一次，DB2 WSE 是惟一按此方式進行許可的 DB2 服務器），則必須用一個 DB2 服務器許可 以及將在正常運行期間（即出現故障 之前）訪問 active 備用服務器 （機器 2）的并發用戶的數量，來對 active 備用服務器頒發許可（如果您要使用連接集中軟件或多路器，那么必須在連接被集中 之前算出用戶的數量）。在故障期間，可以將出故障的服務器上的并發許可免費移交給 active standby （機器 1）。簡言之，每臺服務器只需為各自的工作負載環境發放許可，當出現故障時，可以將并發用戶許可免費移交給仍然正常運行的機器。

在 圖 2展示的例子中，如果每臺 DB2 WSE 服務器要為 50 個并發用戶發放許可，那么您將需要： (2 臺服務器 x 50 個并發用戶) = 100 個并發用戶許可 + 2 個 DB2 WSE 服務器許可（每臺服務器一個許可）。

在機器 2 停機期間，active 備用服務器（在這個例子中是機器 1）為 100 個并發用戶獲得許可。也就是說，原本屬于機器 1 的 50 個并發許可再加上從機器 2 那里得到的另外 50 個并發許可。當兩臺機器都正常運行時，每臺服務器各有 50 個并發用戶的許可。

注冊用戶或指定用戶：對于按照 指定用戶模型（例如 DB2 Express）或者 注冊用戶模型（例如 DB2 WSE）頒發許可的任何 DB2 服務器產品，必須用服務器許可來為 active 備用服務器發放許可。（這里澄清一下，DB2 Express 指定用戶許可與 DB2 WSE 注冊用戶許可是一回事）。DB2 注冊用戶和指定用戶許可是為特定個體提供的權利，使他們可以訪問公司中任何為指定用戶或注冊用戶許可的 DB2 服務器。例如，您可以讓一個指定用戶訪問您環境中的十個不同的 DB2 數據庫服務器，條件是這些服務器按照指定用戶或注冊用戶方式頒發許可。

在 圖 2展示的例子中，如果您有 100 個注冊用戶和兩個 DB2 WSE 服務器，那么您將需要： 100 個注冊用戶 + 2 個 DB2 WSE 服務器許可。請記住，注冊用戶和指定用戶許可只是為特定用戶提供的，不能在連接時像并發用戶許可那樣動態地移交許可。

如果您要使用 DB2 V8.2 中新的 HADR 特性，那么還有一些 High Availability Disaster Recovery (HADR) licensing 方面的考慮是您需要知道的，我們將在本文的后面講到。

Idle standby
在 idle standby這種配置中，在正常運行期間，高可用性集群中的某一臺服務器 沒有一個服務用戶事務或查詢工作負載的 DB2 數據庫。這臺服務器安裝了 DB2 服務器軟件，這個軟件可能被啟用，也可能沒有被啟用，但是它一直處于閑置狀態，并沒有執行“有用的”工作。屬于“無用”（實際上，這種工作可能反而是最有用的）的工作有：在 failover/HA 場景中的管理動作，例如使一個數據庫處于 rollforward pending 狀態來支持日志傳送，產生一個 DB2 數據庫的 flash 副本，然后在另一臺服務器上執行該副本的數據庫備份，為 HADR 環境提供事務傳送支持等。如果在高可用性集群中有某一臺服務器出現故障，那么集群軟件會將其工作負載轉移到 idle 備用數據庫服務器上。

對于 idle standby 配置有一種很常見的誤解，那就是 idle 備用機器只用于恢復運行，因而是一種資源浪費。其實這是對這種配置的一種不正確理解。實際上，除了作為備用機器以外，idle 機器還有很多用途（既包括與 DB2 相關的用途，也包括與 DB2 無關的用途）。例如，您可以在 idle 機器上創建一個新的 DB2 實例（取決于您選擇在那里執行什么樣的 DB2 相關工作，它可能隱含許可），并將它用作測試機器，或者將其他工作負載和功能轉移到這臺機器上。出現故障時，您可以縮減工作負載，允許備用機器用它所有的資源來處理出故障的機器上的負載，從而繞過了在討論 active standby 配置時提到的關于負載的顧忌。例如，您可以讓 idle 備用機器沿著 DB2 日志前滾，與此同時，它在運行另一個實例中的測試場景（或者非 DB2 目的的場景，例如應用程序測試等）。當出現故障時，只需靜態測試工作負載并讓 DB2 承擔出故障的服務器上的負載，而不必考慮吞吐率是否會下降。

客戶們采用各種不同的方式來使用備用機器。我們建議在考慮備用機器的使用時，對目標和業務需要劃定優先級。例如，有些客戶可能會選擇在一臺備用機器上設立一個日志傳送環境。與此同時，他們還想將同一個備用數據庫用于當前某個只讀的生產機器 —— 這樣可以在越來越多的資源之間分攤成本（會計人員確實很喜歡看到這種情況）。大多數供應商將這種模型限制為 either/or 形式 —— 即，當您在讀數據庫的時候，就不能沿著日志前滾（如果不是 eithyer/or 形式，那么對于前滾過程所能保持的速度要有所折扣，就像在邏輯備用服務器中一樣）。此后，由于只讀操作要延續一段時間，而讓數據庫保持打開狀態，這增加了故障的修復時間：這正是設計這種配置時希望避免的問題。我們的建議是，如果要突出可用性特征，那么應該將可用性作為首要目標來對環境進行定價和調整。如果您可以承受更長的停機時間，那么可以在考慮備用機器的使用時有更多的選擇。

最后，在很多情況下，在 active/idle 環境中許可 DB2 要比其他供應商的 active/active 環境更為廉價（即使 包括硬件，也是如此），這決不是什么營銷時的夸夸其談。DB2 V8.2 for Linux 還包括 Tivoli System Automation for Linux 的一個免費的 2 節點（2-node）許可，后者可以提供 20 種輔助故障轉移場景，而復雜性卻很?。◤碗s性的減少是件了不起的事情）。除此之外，不要忘了 所有DB2 服務器都有 HA-licensing，而不僅僅是 Enterprise 版才有。

圖 3展示了一個 idle standby 場景。在這個例子中，在正常運行期間，機器 2 被用于事務和查詢工作負載（在圖中被標為 active 工作），而機器 1 則被當作機器 2 的工作負載的 idle standby，可能還支持其他一些功能，例如應用程序開發，或者干脆將其關閉。當機器 2 出故障時，它的 DB2 工作負載被傳遞給它的 idle 伙伴，也就是機器 1。在此場景中，很可能出現的情況是，如果在出故障之前有什么工作（包括任何類型的工作）在機器 1 上執行，那么該工作將被縮減，以便處理機器 2 出故障之后到來的新工作負載（或者機器 1 被調整到初始規模，以支持其工作負載，包括 DB2 工作或非 DB2 工作，同時還有機器 2 的工作負載 —— 否則就會有性能問題。）

在圖 3 中，從 DB2 的角度來看，在正常運行期間只有一臺機器是 active 的，而另一臺機器在處理其他事情，因而這種配置常常被稱作 active/idle配置。（注意，根據 idle 備用機器上所執行的工作，您可能需要購買附加的 DB2 許可：例如，如果將一臺機器用作 idle standby，同時開發人員又要使用這臺機器作為 DB2 應用程序開發環境，那么您可能要為開發人員選擇購買 DB2 Universal Developer Edition 許可。）這里要注意的一個重要概念是，在出現停機情況之前，機器 1 沒有做任何有意義的 DB2 工作。

圖 3. 機器 2 的工作負載被傳送到 idle 備用服務器，即機器 1

同樣，在選擇環境時，idle standby 不一定是正確的選擇，這取決于可用性需求、工作負載等方面。但是別忘了您為什么將高可用性環境放在第一位 —— 為了減少故障修復的時間。

對于 idle 備用機器在許可方面的考慮
處理器許可：對于按照 處理器許可模型頒發許可的任何 DB2 服務器產品，（例如 DB2 Express、DB2 WSUE 或 DB2 ESE），出于高可用性目的，idle 備用服務器只要求一個處理器是必須頒發許可的。在上面的例子中，假設每臺機器在 2 路 CPU（2-way）服務器上運行 DB2 WSUE，那么您需要的許可為： (1 臺 active 服務器 x 2 個處理器) + 1 臺 idle 備用機器上的 1 個處理器 = 3 個處理器。

分區數據庫：對于分區數據庫環境中的 idle 備用機器，許可這一術語在 DB2 Version 8.1 中發生了變化。idle 備用機器與 Database Partitioning Feature（DPF）一起使用，DPF 是 DB2 Enterprise - Extended Edition 在 DB2 Version 7 中提供的一個特性，在這里，idle 備用機器的許可方式與沒有分區的服務器的許可方式是一樣的。而在 DB2 V8.1 之前，必須對 DB2 EEE 環境中所有的故障轉移處理器頒發許可。

例如，如果您有 4 臺 8 CPU 的服務器，并在其中 3 臺服務器上安裝了 DB2 ESE，將它們用作生產型服務器，同時將剩下的一臺服務器作為備用服務器（帶有 DPF 特性），那么您需要的許可為： (3 臺 active 服務器 x 8 個處理器) + 1 個 idle 備用機器上的處理器 = 25 個處理器（在這個例子中，我們假設您認為一個處理器許可等于一個 DB2 ESE 處理器許可加上每個處理器為 DPF 特性支付的額外費用）。

并發用戶：對于任何按照 并發用戶模型頒發許可的 DB2 服務器（例如，DB2 WSE），只需用一個服務器許可就可以獲得 idle 備用服務器的許可，因為在故障轉移期間，可以將出故障的服務器上的并發用戶許可動態地轉交給 idle 備用機器。

在前面的例子中，如果您在兩臺機器上都安裝了 DB2 WSE，并為 50 個并發用戶授予 active 服務器的權限，那么您將需要： 2 個服務器許可（一個用于生產，一個用于 failover） + 50 個并發用戶許可。

請記住，DB2 WSE 是通過使用每個服務器許可加上一個用戶的費用（并發用戶或注冊用戶）來獲得許可的。在故障轉移之后，idle 備用服務器將獲得 50 個并發用戶的許可，這些許可是機器 2 上原有的 50 個并發許可。

注冊用戶或指定用戶：對于任何按照 指定用戶模型（例如 DB2 Express）或者 注冊用戶模型（例如 DB2 WSE）獲得許可的 DB2 服務器，只需用一臺服務器來為 idle 備用服務器頒發許可。（更確切地說，DB2 Express 可以用一個指定用戶許可來獲得許可，而 DB2 WSE 可以用一個注冊許可來獲得許可，其實這是一回事）。DB2 注冊用戶許可和指定用戶許可是為特定個體提供的一種權利，使他們可以訪問公司中任何為指定用戶或注冊用戶頒發許可的 DB2 服務器。

在前面的例子當中，如果您有 100 個指定用戶，還有一個生產 DB2 Express 服務器，那么您將需要： 2 個 DB2 Express 服務器許可 + 100 個指定用戶許可。由于指定用戶許可可以訪問環境中的多臺服務器，因此不需要將指定用戶權利劃分給每臺服務器。

提示：在這種環境中，如果將 idle 備用機器作為 active 備用機器來使用，不會影響許可成本（由于與指定用戶或注冊用戶相關的術語和條件），所以，您可以從注冊用戶許可或指定用戶許可中獲得更大的價值。但是，當出現停機情況時，備用機器上將引入負載，因此您必須仔細權衡這種方法的優缺點。簡言之，可以直接在 active/active 配置中使用為注冊用戶或指定用戶許可的 idle 備用機器，無需再去考慮許可問題。

如果您要使用 DB2 V8.2 中新的 HADR 特性，那么還有一些 HADR licensing 方面的考慮事項是必須知道的，我們將在下一節中講到它們。

關于 HADR 的高可用性定價
DB2 V8.2 引入了一種叫做 High Availability Disaster Recovery (HADR) 選項的新的可用性產品。HADR 產品使 DB2 能夠從日志緩沖區交付事務，而在此之前的很長一段時間里，DB2 是從日志文件交付事務的。這種增強為一個更豐富的、更有粒度的、齊全的數據丟失預防環境提供了支持，這種環境帶有多種擴展選項，例如無需停機便可更新操作系統的能力。HADR 有三個數據丟失預防級別，其中一個級別保證零丟失事務環境。將所有這些包裝起來的是一個功能完備的 GUI，這種 GUI 使得 HADR 環境的建立十分便捷。下面的 圖 4展示了一個 HADR 的例子：

圖 4. HADR 環境中的 DB2

對 HADR 技術細節的討論超出了本文的范圍。請訪問 DB2 V8.2網頁，以獲得更多信息。

DB2 ESE 附帶了 HADR 選項，這個選項沒有另外收費，還可以將該選項作為 DB2 Express、DB2 WSE 和 DB2 WSUE 服務器的附帶產品 —— 如果您正計劃與 ESE 服務器一起使用 HADR，那么只需遵從本文中給出的指南，并跳過此節即可。

購買用于 DB2 Express、DB2 WSE 和 WSUE 的 DB2 High Availability Disaster Recovery 選項的惟一方式是通過一個處理器許可。DB2 服務器上的每個 active 處理器都必須獲得 HADR 許可，備用機器獲得 HADR 許可的方式應該與您用一個處理器許可為備用機器獲得 DB2 服務器許可的方式相同（這取決于備用機器的 active 或 idle 狀態）。

如果您使用并發用戶、指定用戶或注冊用戶為 DB2 服務器獲得許可，那么仍然必須通過服務器上處理器的數量來獲得 HADR 選項許可。換句話說，對 DB2 HADR 選項的許可總是基于處理器的數量，而不管 DB2 服務器本身是如何獲得許可的。例如，如果您有一臺 DB2 WSE 服務器，服務器有 10 個并發用戶，并且是在一個 active/idle standby 集群中使用該服務器，同時該集群在一臺 2 CPU 的服務器上帶有 DB2 HADR Option 產品，那么您將需要： 2 個 DB2 WSE 服務器許可 + 10 個并發用戶許可 +（（active 機器上的 2 個 DB2 HADR Option 處理器許可）+ idle 機器上的 1 個 DB2 HADR Option 處理器許可 = 3 個 HADR 處理器許可）。

前一個例子是否讓您失去警惕呢？其中可能有些撲朔迷離。我們將為您加以簡化。在這個例子中，您有 2 臺服務器，每臺服務器有 2 個處理器（在集群中一共有 4 個處理器）。其中一臺機器是 active 機器，做一些有意義的工作。另一臺機器是 idle 機器，它一般做一些其他的工作，但是從 DB2 的角度來看，它只是做一些工作來幫助故障恢復等。由于我們有兩臺服務器，并且選擇使用并發用戶模型來為 DB2 WSE 頒發許可，所以我們需要 2 個 DB2 WSE 服務器許可。此外，由于 active 機器每次有不超過 10 個的并發用戶，因此您將需要 10 個并發用戶許可（這里不需要用于 idle 機器的并發用戶許可，因為在出現停機情況時，可以動態轉移并發用戶許可）。最后，由于您要使用 HADR，因此，對于 active 服務器，需要有 2 個 HADR 處理器許可，而對于備用服務器，需要有一個 HADR 處理器許可。