程式師世界 >> 數據庫知識 >> DB2數據庫 >> DB2教程 >> db2 HA環境下許可證的問題

db2 HA環境下許可證的問題

編輯：DB2教程

客戶之所以選擇 IBM DB2 數據庫，是因為它能夠在難於置信的時間內實現其價值，能夠跨各種不同的環境伸縮和集成，還有其健壯性以及極少的停機時間（包括計劃內的停機和計劃外的停機）。我聽到了很多關於高可用性（high availability，HA）環境中 DB2 的許可方面的問題，高可用性環境的設計目標是減少計劃外停機（有時候也包括計劃內的停機）。通常，人們的第一層困惑的原因是：在為高可用性環境中的數據庫產品定價時，不同的供應商總是花樣百出。

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

另一個容易產生困惑的地方源自在討論出現停機事件情況時，用來描述用作故障轉移服務器的服務器的術語。例如，這種服務器可能被稱為備用（standby）或從（secondary）服務器（還有其他名稱）。如果您接觸這一方面的時間比較長，那麼很可能對描述這種服務器的功能的術語已經很熟悉了。這些術語包括：idle、active、cold、warm、hot 和 passive。

大多數情況下，IBM Software Group（IBM SWG）文獻使用 cold、warm 和 hot 這幾個術語來描述備用服務器。在 DB2 9.5 之前，在 DB2 領域情況有所不同。DB2 8 和 DB2 9 使用術語 idle 和 active 來描述備用數據服務器。因此，DB2 8 和 DB2 9 中采用的定價和許可術語可能與其他 IBM SWG 術語不同，這也是常常令客戶對高可用性許可產生困惑的源頭。

好消息是，在 DB2 9.5 中，與高可用性定價相關的許可術語已經與 IBM SWG 術語一致了。例如，如果在高可用性集群中將一個 DB2 9 數據服務器配置為 sat idle，就必須為這個服務器授予部分許可。在 DB2 9.5 中，不再需要這樣做了。如果在 DB2 9 中未啟動的服務器上安裝 DB2，那麼也必須為這個服務器授予部分許可。在 DB2 9.5 中，不需要為未啟動的數據服務器購買許可。

簡單地說，對於高可用性環境中 DB2 服務器的許可取決於您對以下這些關鍵問題的回答：

您安裝了什麼版本的 DB2 數據服務器？

它是 DB2 Express-C、DB2 Express-C FTL、DB2 Express、DB2 Workgroup 還是 DB2 Enterprise？例如，DB2 Express-C FTL 對於備用服務器沒有 hot、warm 或 cold 的概念（稍後進一步解釋）。另外，不允許用 DB2 Express-C 建立高可用性集群。

您要如何為 DB2 數據服務器頒發許可以確保高可用性？

對於主流的 DB2 9.5 數據服務器（DB2 Express、DB2 Workgroup 和 DB2 Enterprise）有以下選擇：授權用戶許可（顧名思義，這種許可要識別每個最終用戶）和稱為價值單元（Value Unit，VU）的基於 IBM SWG 處理器的指標（這樣就不需要計算用戶數量）。如果使用 DB2 Express-C FTL，就要為每個物理服務器頒發許可。（關於所有分布式 DB2 9 數據服務器的概述以及許可方式，請參見 “Which distributed edition of DB2 9.5 is right for you?”。）

當沒有出現故障時，如何使用備用機器？

是將它用作處理 DB2 事務和查詢工作的生產服務器嗎？這個服務器上的 DB2 實例啟動了嗎？這個實例可能正在執行某種形式的工作，而只是在出現故障事件時幫助啟動恢復（例如在 HADR 場景中）。簡單地說，當一切正常時備用服務器正在做什麼與如何為那個服務器上的 DB2 獲得許可有很大的關系。

簡單地說，對於高可用性環境中 DB2 服務器的許可取決於您對以下這些關鍵問題的回答：

您安裝了什麼版本的 DB2 數據服務器？

您要如何為 DB2 數據服務器頒發許可以確保高可用性？

當沒有出現故障時，如何使用備用機器？

在討論高可用性集群對 DB2 9.5 許可的影響時，首先給出與新術語相關的示例。DB2 9.5 定義了三種備用服務器： hot 、 warm 和 cold 。

hot 備用

在 hot 備用配置中，所有服務器都有用於處理用戶事務和查詢的獨立運行的 DB2 數據庫。這種配置有時候被稱作 active/active 配置，因為集群中的所有機器在所有時候都在執行某種級別的業務生產工作。如果高可用性集群中的某一個服務器出現故障，那麼集群軟件將把出故障的服務器上的工作負載轉移到集群中仍然正常的一個服務器上。

如果出現了故障，那麼負載的轉移將使 hot 備用服務器（兩節點集群中仍然正常運行的機器）的工作負載加倍，因為現在這個機器必須處理它原先的工作負載再加上出故障的服務器的工作負載。在設置任何高可用性環境時，都需要考慮這一點，在這種環境中，每個服務器互為備用，但是它們必須維持自己的服務水平。如果您是一名數據庫管理員（DBA），並且要滿足一個苛刻的服務水平協議（SLA），那麼這未必是最好的選擇（除非調整其規模或使用 Xkoto GRIDSCALE 等技術限制其影響）。

總而言之，在 DB2 中，hot 備用服務器是在正常運行期間用來處理用戶事務和查詢的機器。當集群中另一個服務器出現故障時，hot 備用服務器將接管出故障的服務器機器上的負載，同時還要處理在正常運行期間它自己所執行的工作。因為即使沒有故障出現，hot 備用機器仍用於處理用戶事務和查詢，所以它必須是獲得完全許可的。例如，假設有兩個數據庫分別安裝在兩個不同的機器上，其中一個機器上運行著一個企業資源計劃（ERP）應用程序，另一個機器運行供應鏈管理（SCM）應用程序。如果 SCM 數據庫出現故障，那麼承擔著 ERP 工作負載的機器將不得不同時為所有的 SCM 用戶提供服務。有兩個服務器，在正常運行期間，它們都用來處理事務和查詢工作負載（實心框表示在出現故障之前每個機器的工作負載，交叉線框是當兩個機器分別出現故障時，工作負載所出現的地方）。在這個場景中，當機器 2 出現故障時，它的工作負載被轉送到它的故障轉移伙伴（即機器 1）那裡。機器 1 是機器 2 的 hot 備用服務器（當您仔細觀察這個圖時，會發現反過來也是一樣的 —— 注意機器 2 上原屬於機器 1 的交叉線框）。這種類型的配置常常被稱作高可用性集群對（high-availability clustering pair）、孿生故障轉移對（twin failover pair）或 active/active 對，這在當今的 IT 環境中非常常見。有許多種在 DB2 中實現 active/active 高可用性集群的方法，根據解決方案的需求，可以使用數據庫分區特性，在互為故障轉移的每個服務器上的數據庫中結合使用 HADR，使用 active 備用服務器通過快照技術或磁盤映像拷貝執行報告功能，使用 xKoto GRIDSCALE 技術。機器 1 和機器 2 一直用於處理自己的事務和查詢工作負載，當機器 2 出現故障時，機器 2 上的 DB2 工作負載被轉移到機器 1。在這種情況下，如果沒有考慮到承擔機器 2 的工作負載而對機器 1 的資源進行適當的調整（反之亦然），那麼在出現停機並導致工作負載的轉移之後，就會引起性能問題。

對於 hot 備用機器在許可方面的考慮事項

作為一般經驗法則，active/active 配置的許可方式應該與各服務器沒有參與高可用性集群情況下的許可方式相同。接下來的小節將詳細介紹對於 DB2 數據服務器許可方式，您應該知道的一些考慮事項。

價值單元（VU）許可：

對於任何按照 VU 模型頒發許可的 DB2 數據服務器，hot 備用服務器（這個例子中是機器 1）上的所有 VU 都必須得到許可（除非使用 DB2 Enterprise 中的子容量許可功能）。這種許可方式與服務器沒有參與 HA 集群時一樣，因為服務器用來處理生產負載，所以這沒什麼奇怪的。

在圖 3 所示的例子中，假設每台機器都運行 DB2 Workgroup（這個版本將服務器的最大 VU 級別限制為 400），那麼必須購買共 800 VU 的許可：機器 1 的 400 VU 和機器 2 的 400 VU。

授權用戶許可：

對於任何按照授權用戶模型頒發許可的 DB2 服務器產品，必須按照將訪問它的授權用戶的總數購買許可，這也包含將訪問 active 主數據服務器的用戶數（因為主數據服務器有自己的應用程序，而且它們互為備用服務器）。授權用戶是一個個人（在某些情況下，如果它不代表其他用戶，那麼可以是一個應用程序或設備），他具有在公司內外有效的身份。也可以通過因特網使用這些許可（比如在線銀行應用程序），因為最終用戶是已知的，因而必須被許可明確識別。授權用戶許可擁有完全的權力；不需要像 DB2 8 中那樣另外使用服務器許可（在 DB2 8 中，用戶權力必須與基本服務器許可結合使用）。如果使用多路復用或連接集中軟件，那麼需要首先完全識別這些用戶，然後才能將這些技術應用於連接。

對於訪問數據服務器的每個用戶，都需要獲得授權用戶許可。但是，無論有多少用戶訪問數據服務器，至少要購買最低數量的授權用戶許可：DB2 Express 和 DB2 Workgroup 數據服務器要求最少 5 個授權用戶許可，DB2 Enterprise 數據服務器要求為服務器上的每 100 VU 至少購買 25 個授權用戶許可。授權用戶許可不能隨工作轉移而轉移（但是可以由於雇用關系轉移而轉移），它們只對特定的數據服務器有效。當然，因為這個示例是 active/active 配置，它們的許可方式與完全獨立的 active 服務器相同，所以這些規則的意義不大。如果有 100 個用戶需要訪問兩個 active DB2 Workgroup 數據服務器，那麼需要購買 200 個 DB2 Workgroup 授權用戶許可：2 個服務器 x 每個服務器 100 個授權用戶。即使這些用戶中只有 12 個用戶同時連接這兩個服務器之一，也必須為每個數據服務器頒發所有 100 個用戶的許可（所以這個示例需要 200 個授權用戶許可）。使用 DB2 Express 或 DB2 Workgroup，而且公司中只有 3 個用戶，那麼需要 10 個 DB2 Express 或 DB2 Workgroup 授權用戶許可（2 個服務器 x 最低授權用戶數 5 個），這樣才能滿足這些 DB2 版本對最低授權用戶數的要求。使用的數據服務器是 DB2 Enterprise，情況就不一樣了。仍然以前一段中的情況為例，如果有 100 個用戶需要訪問兩個 active DB2 Enterprise 數據服務器，那麼需要購買 200 個 DB2 Enterprise 授權用戶許可：2 個服務器 x 每個服務器 100 個授權用戶。同樣，即使這些用戶中只有 12 個用戶同時連接這兩個服務器之一，也必須為每個數據服務器頒發所有 100 個用戶的許可（所以這個示例仍然需要 200 個 DB2 Enterprise 授權用戶許可）。 DB2 Enterprise 數據服務器是 2 插槽基於 Intel x86 的雙核服務器，那麼這些服務器的總 VU 級別都是 200。如果公司中只有 3 個用戶，那麼需要 100 個授權用戶許可（2 個服務器 x 200/100 VU x 25 個授權用戶），這樣才能滿足這個 DB2 版本對最低授權用戶數的要求。但是，如果圖 3 中的服務器是 2 插槽基於 Power5+ 的雙核服務器，那麼這些服務器的總 VU 級別就是 400。所以，對於這種服務器硬件，如果公司中只有 3 個用戶，那麼需要 200 個授權用戶許可（2 個服務器 x 400/100 VU x 25 個授權用戶），這樣才能滿足這個 DB2 版本對最低授權用戶數的要求。

正如前面提到的，DB2 Express-C 不支持高可用性配置。但是，DB2 Express-C FTL 支持。在高可用性環境中為 DB2 Express-C FTL 頒發許可時，不采用本節描述的規則。因為 DB2 Express-C 是一種免費的數據服務器，而 Fixed Term License（FTL）是可以另外購買的支持和特性合約，所以采用另一種許可方式。在高可用性環境中為 DB2 Express-C FTL 頒發許可時，只需為集群中的每個服務器購買支持合約，而不管采用哪種備用類型（hot、warm 或 cold）；不需要識別服務器的活躍程度、最低用戶數、底層數據服務器的價值單元級別和其他情況：非常簡單！

warm 備用

在 warm 備用配置中，在正常運行期間，高可用性集群中至少有一個服務器上沒有為用戶事務或查詢工作負載提供服務的 DB2 數據庫。由於這個數據服務器沒有執行 “有用的” 工作，因而說它是閒置的。被歸為 “無用的” 工作（具有諷刺意味的是，這些工作實際上可能是服務器所做的最有用的工作）包括在故障轉移場景中起輔助作用的一些管理工作，比如使處於前滾暫掛狀態的數據庫支持日志傳送（log shipping）、為 HADR 環境提供事務級日志傳送支持等等。如果高可用性集群中某一個服務器出現故障，那麼集群軟件就會將工作負載轉移到 warm 備用數據服務器。

對 warm 備用配置普遍存在的一個誤解是，warm 備用機器若專用於恢復操作，那就是對資源的浪費。如此理解這種配置是不對的。實際上，warm 備用機器不僅可以擔任備用角色，還可以有很多其他用途（包括與 DB2 相關和不相關的用途）。例如，可以在 warm 備用機器上創建另一個 DB2 實例（根據要在那裡執行的和 DB2 相關的工作，其中可能牽涉到許可問題），並使用它作為測試機器，還可以將其他工作負載和功能分攤到它上面來執行。當有故障發生時，可以推掉這些工作負載，讓 warm 備用機器使用全部資源來處理出故障的服務器的負載，這樣便巧妙地解決了前面討論 hot 備用配置時提到的負載問題。例如，可以讓 warm 備用機器根據 DB2 日志進行前滾，與此同時，這台機器還可以在另一個實例中運行測試場景（或者與 DB2 無關的測試場景，例如應用程序測試等等）。當有故障發生時，只需暫停測試工作負載，讓 DB2 承擔出故障的服務器的負載，這樣就不必擔心吞吐量降低。給出一個 warm 備用場景。在這個示例中，當正常運行時，機器 2 用於處理事務和查詢工作負載（在圖中標為活動工作），而機器 1 作為機器 2 工作負載的 warm 備用，也可能支持某些額外功能，比如應用程序開發。一旦機器 2 出現故障，它的 DB2 工作負載被傳遞到它的 warm 伙伴機器 1。在這個場景中，情況很可能是這樣的：如果在出故障之前（任何類型的）所有工作在機器 1 上執行，那麼當機器 2 出現故障之後，這些工作就會收回，以便處理新的工作負載（或者，機器 1 最初確定的規模是同時支持它的工作負載和機器 2 的 DB2 工作負載，否則將出現性能問題）。由於從 DB2 的角度看來，在正常運行期間只有一台機器是活動的，而另一台在做其他事（比如准備 HADR 故障轉移伙伴），所以這種配置常常稱作 active/idle 配置。這裡要注意的重要概念是，在發生停機之前，機器 1 不做任何 “有意義” 的 DB2 工作。根據您的可用性需求、工作負載等等，warm 備用可能適合您的環境，也可能不適合；然而，首先不要忘了高可用性環境的目標 —— 減少停機之後的平均恢復（MTTR）時間。

warm 備用機器許可方面的考慮事項

價值單元（VU）許可：

對於任何按照 VU 模型頒發許可的 DB2 數據服務器，無論服務器基於哪種處理核心體系結構，都按照 100 VU 為 warm 備用服務器頒發許可。換句話說，盡管具有 4 個雙核 AMD 處理器的服務器的 VU 級別是 400，而具有 4 個雙核 Power5+ 處理器的服務器的 VU 級別是 800，但是在用作 warm 備用服務器時，只需按照 100 VU 為 DB2 軟件頒發許可。假設每台機器都運行 DB2 Workgroup（這個版本將服務器的最大 VU 級別限制為 400），那麼必須按照 500 VU 購買許可：warm 備用服務器（機器 1）的 100 VU 和機器 2 的 400 VU。

授權用戶許可：

對於任何按照授權用戶模型頒發許可的 DB2 服務器產品，只需為 warm 備用服務器購買最低數量的授權用戶許可。對於 DB2 Express 和 DB2 Workgroup，因為必須為物理服務器購買的最低授權用戶許可數量是 5 個，所以 warm 備用服務器需要 5 個授權用戶許可。在上面的示例中，如果一個 DB2 Workgroup 服務器是 hot 服務器並參與 active/idle 集群，而且您有 100 個用戶，那麼需要 105 個 DB2 Workgroup 授權用戶許可：100 個授權用戶 + warm 備用服務器所需的 5 個授權用戶（當然，如果用戶數低於最低值，那麼 hot 服務器必須滿足對授權用戶許可的最低數量要求。）

對於 DB2 Enterprise，必須為 warm 備用服務器購買 25 個授權用戶許可，這是因為在 VU 模型中一個 DB2 Enterprise warm 備用服務器按照 100 VU 頒發許可，而 DB2 Enterprise 要求每 100 VU 至少購買 25 個授權用戶許可。如果有 100 個用戶需要訪問高可用性集群中的 hot DB2 Enterprise 數據服務器，那麼需要 125 個 DB2 Enterprise 授權用戶許可：100 個授權用戶 + warm 備用服務器所需的 25 個授權用戶。服務器是 2 插槽基於 Intel x86 的雙核服務器，那麼 hot 服務器的總 VU 級別是 200。如果只有 3 個用戶訪問 hot DB2 Enterprise 數據服務器，那麼仍然需要 75 個授權用戶許可：（hot 服務器的 200/100 x 25 個授權用戶） + DB2 Enterprise warm 備用服務器的 25 個授權用戶。但是，如果服務器是 2 插槽基於 Power5+ 的雙核服務器，那麼 hot 服務器的總 VU 級別就是 400。如果只有 3 個用戶訪問 hot DB2 Enterprise 數據服務器，那麼仍然需要 125 個授權用戶許可：（hot 服務器的 400/100 x 25 個授權用戶） + DB2 Enterprise warm 備用服務器的 25 個授權用戶。

warm 備用機器許可方面的考慮事項

價值單元（VU）許可：

授權用戶許可：

cold 備用

在 cold 備用配置中，在正常運行期間，集群中至少有一個服務器上沒有為用戶事務或查詢工作負載提供服務的 DB2 數據庫。這個服務器也不執行在故障轉移場景中起輔助作用的任何管理工作，比如使處於前滾暫掛狀態的數據庫支持 HADR；實際上它甚至可能不開機。給出一個 cold 備用場景。在這個示例中，當正常運行時，機器 2 用於處理事務和查詢工作負載（在圖中標為活動工作），而機器 1 上沒有啟動 DB2 實例。一旦機器 2 出現故障，機器 1 就會啟動並通過備份映像將 DB2 數據庫恢復到某一時間點，然後繼續處理用戶事務。還可以將機器 1 配置在 TSA 高可用性集群中，但是不啟動數據庫實例。您可以看出，cold 備用配置並不是很好的可用性解決方案，因為它的 MTTR 通常比 hot 或 warm 備用配置長得多。

但是，在某些環境中 cold 備用服務器是合適的。通常，我建議客戶對應用程序的可用性需求進行多級的分類；例如，建立 Copper、Silver 和 Gold 級別。Copper 級別的應用程序可以采用 cold 備用，Silver 級別的應用程序采用 hot 配置，而 Gold 級別的應用程序采用 warm 備用。按照我的觀點，如果需要最高的可用性，就使用 warm 配置並結合使用 HADR。通過使用專用服務器，可能（但也不一定）獲得比 hot 備用配置更好的故障間平均時間（MTBF）和 MTTR（除非適當地確定其規模）。

cold 備用機器許可方面的考慮事項

從 DB2 9.5 開始，不需要為 cold 備用服務器頒發許可，因此沒有許可方面的考慮事項。判斷備用機器是否可以歸類為 cold 備用的一條經驗規則是，查看是否啟動 DB2 實例；但是，這條規則有一些例外。例如，如果從生產服務器取得了快照映像，並且只為了執行備份而啟動 DB2 備用數據服務器，執行備份之後就停機，那麼也可以認為它是 cold 備用服務器，不需要許可。

所以，采用 DB2 9.5 中新的高可用性許可規則可以幫助您節省資金。假設您要為使用 Database Partitioning Feature 的 DB2 9 環境頒發許可。這個集群由 5 個服務器組成，其中 4 個 hot 服務器的 VU 級別都是 800，它們都配置為向一個備用服務器（也是 800 VU）執行故障轉移。在 DB2 9 中，因為沒有 cold 備用服務器的概念，所以必須按照 Database Partitioning Feature 的 100 VU 和 DB2 Enterprise 的 100 VU 為備用服務器頒發許可。但是在 DB2 9.5 中，如果備用服務器上沒有啟動 DB2 實例，它就是 cold 備用服務器，就不需要支付許可費用。

與 HADR 相關的高可用性定價

當在高可用性配置中使用 HADR 時，備用服務器必須按照 warm 或 hot 服務器頒發許可（取決於是否設置了孿生 HADR 故障轉移場景）。

從 DB2 9.5 開始，HADR 被包含在 DB2 Workgroup 中（它一直是 DB2 Enterprise 的組成部分）。在 DB2 9 中，在 DB2 Workgroup 數據服務器中添加 HADR 的惟一方法是，為生產服務器和備用服務器都購買 High Availability Feature Pack！從 DB2 9.5 開始，不再需要這樣做了，所以節省了資金：只需按照上述說明，作為 warm 服務器為 DB2 Workgroup 備用服務器頒發許可。

另外，如果希望在 DB2 Express 數據服務器上使用 HADR，那麼仍然必須購買 DB2 High Availability Feature Pack；但是，從 DB2 9.5 開始，不再需要在備用機器上為 High Availability Feautre Pack 頒發許可，除非將這台機器用作 HADR 孿生集群中的 hot 備用。

最後，DB2 Express-C FTL 總是允許用 HADR 設置高可用性集群；這種配置沒有許可方面的考慮事項，只需為安裝 DB2 Express-C FTL 的每個服務器購買支持合約。