DB2資料庫雙活方案設計要點

分享專家: 孔再華 資料庫架構師

具有豐富的資料庫環境問題診斷和性能調優的經驗，擅長DB2 PureScale 集群產品的項目諮詢和實施。

在兩地三中心建設過程中，我們發現採用傳統的容災技術碰到3個問題。

1. 切換時間太長，即使通過自動化實現，主切備和備切主都需要花費幾十分鐘時間。

2. 操作風險太大，比如核心系統切換涉及到20步以上的操作步驟和上百條命令，每條命令都有出錯的可能。

3. 建設成本太高，同城機房按照1比2甚至1比1 的比例進行建設，伺服器平時完全閑置，除了一次性投入，每年還要耗費大量的維護費用。

因此相對於傳統容災方式，我們希望建設一個雙活平台，解決降低RTO時間、降低成本和降低切換風險等需求。

在雙活平台的選型過程中，基於當前需求是傳統型業務(非互聯網類型)做遷移，當前資料庫base是DB2和Oracle，從平台角度發起而不想對業務開發進行改造，最終實現雙機房對等雙活等因素，我們最終發現Db2 pureScale GDPC方案最適合。

這個方案特點明顯: 高可用性，可擴展性和對應用透明。那麼選好型後，怎麼落地成了最關心的問題。因為雙活技術的複雜性，在方案設計的每個環節都需要慎重考慮，選擇最合適的方式，最終形成自己需要的方案(以下為內容分享)。

1.為什麼要基於Db2 pureScale做資料庫雙活？優勢和意義是什麼？

為了保證數據多中心部署0丟失，降低容災切換時間，減少人為操作風險，降低成本。雙活系統就是要將這幾個方面做到極致。

在選型的過程中發現其實沒有太多選擇，能做到這一點的成熟軟體和技術只有Db2pureScale集群技術和OracleRAC技術。這裡說說我們為什麼要用Db2pureScale而不是OracleRAC。

從業界經驗來說，OracleExtendRAC是面向同城雙活的資料庫產品，然而從各方了解都不推薦使用，即便是使用了這個技術的案例裡面，災備機房節點也只是作為熱備，沒有提供對等的服務，這個是與我們建設雙活的應用目標有差距的。而DB2 GDPC（地理位置上分開的pureScale集群）方案從設計之初就是為了做對等雙活，國內也已經有上線案例。從廠商支持力度上來說，IBM主推這個技術並且支持好，Oracle相比差一點。從底層技術來說，IBM的pureScale在可擴展性，對應用透明等特點上是優於Oracle的。所以建議選擇Db2GDPC方案來建設雙活環境。

2.基於Db2 pureScale的資料庫雙活方案設計，要遵循哪些重要原則？

如果將資料庫雙活平台作為未來的常規建設，應用越來越多的系統，那麼在建設初期，我們就要設定好平台的目標：

1、通用性：基於LUW開放平台，支持部署在任何廠商的存儲、伺服器和操作系統上。不能選擇一體機，大型機等不通用的設備。

2、無差別性： 雙中心交易對等，同城之間同時處理業務請求，無主次之分。只有這樣的系統才能面對失去單數據中心的風險。

3、高可用性：最下化降低同城切換時間，同城站點出問題不會影響全局業務。業務切換需要在最短時間內完成。

4、可維護性：基礎設置重大變更不停機，可以通過滾動升級的方式完成維護操作。

5、可遷移性：平台對業務系統透明，開發無需改動代碼，即可快速部署到該平台。同樣該平台部署的系統也可平滑遷移出來。

6、安全穩定運行，該平台可以實現5個9的運行目標。

基於以上目標，在Db2 pureScale的資料庫雙活方案設計裡面，我們遵循對等雙活和對應用透明的原則，克服困難，最大化雙活的高可用性優點，改善性能相關的缺點。

總體設計

3.如何選擇雙中心站點和仲裁站點的定位，仲裁站點需要什麼條件？

首選需要說明DB2GDPC方案邏輯上需要三個站點，其中兩個站點作為雙活的數據中心，第三個站點作為仲裁站點。

雙站點的定位和條件:

1.雙活站點之間需要可靠的 TCP/IP 鏈接相互通信，還需要RDMA(具有 RoCE 或 Infiniband)網路鏈接。具有成員和 CF 的兩個站點是生產站點，它們處理資料庫事務。這兩個生產站點相距應該不超過 50 公里，通過 WAN 或暗光纖（必要時還使用距離範圍擴展器）來連接這兩個站點，並且在它們之間配置了單個 IP 子網。距離更短將獲得更高性能。在工作負載相當少的情況下，可以接受更遠的距離（最多可達 70 或 80 公里）。

2.雙站點的CF和成員節點是對等的。每個生產站點都有一個 CF 以及相同數目的主機/LPAR 和成員。

3.每個生產站點都有它自己的專用本地 SAN 控制器。SAN 已分區，以便可從這兩個生產站點直接訪問用於 DB2 pureScale 實例的 LUN。在站點之間需要 LUN 之間的一對一映射，所以第一個站點上的每個 LUN 都在第二個站點上具有相同大小的對應 LUN。而GPFS同步複製用作存儲器複製機制。

4.對於RDMA網路支持RoCE和infiniband。個人建議使用RoCE，通用性和可部署性強。如果使用 RoCE 進行成員/CF 通信：使用多個適配器埠進行成員和 CF 通信，以適應其他帶寬和提供冗餘。對於以完全冗餘方式配置的總共四個交換機，在每個站點中使用雙交換機。將每個成員和 CF 中的其他綁定的專用乙太網網路介面設置為 GPFS 脈動信號網路。也就是我們說的私有TCP網路。如果使用 Infiniband 進行成員/CF 通信：

僅支持每個成員和 CF 具有單個適配器埠以及每個站點具有單個交換機。此介面用於成員和 CF 通信以及 GPFS 脈動信號網路。

第三個站點的定位和條件:

1. 單個主機（非成員主機，也非 CF 主機），專用於集群仲裁職責，與集群中的其他主機位於相同操作系統級別。可以使用虛擬機。

2. 不需要訪問兩個生產站點中的 SAN。

3.不需要RDMA通信，也不需要私有網路（RoCE的情況下使用到的TCP私網）。

需要為集群中的每個共享文件系統都需要仲裁盤，這個文件系統的仲裁盤就是從這個第三站點劃分出來的。沒有用戶數據存儲在這些設備上，因為這些設備僅用來存儲文件系統配置數據以用於恢復，並且充當文件系統磁碟配額的仲裁磁碟。這些設備的大小需求為最小需求。通常，50 到 100 MB 的設備在大多數情況下能夠滿足需求。此設備可以是本地物理磁碟或邏輯卷 (LV)。

請遵循下列準則來配置 LV:

在同一卷組 (VG) 中創建邏輯卷。為卷組至少分配一個物理磁碟。實際數目取決於所需要的邏輯卷數，而邏輯卷數又取決於共享文件系統數。如果有可能，請使用兩個物理卷以提供冗餘。

有限的條件下，例如只有兩個數據中心，仲裁站點可以放在所謂的主中心機房裡，但是硬體上要和其他節點分開。這個主中心機房的定位就是可能於此關聯的其他重要系統在這個機房，訪問更直接和快速。在存在這種定位的情況下，主CF節點，跑批的成員節點建議放在這個機房裡。

通信網路設計

4.如何規劃和設計集群內部通信網路?

在整個DB2GDPC的方案裡面，仲裁站點僅僅需要TCPIP網路通即可，不需要SAN，RDMA，私網等，所以需要重點關注雙活站點的CF和成員節點的網路設計。

1.雙站點DWDM通信硬體：建議冗餘，租用不同運營商線路。

2.乙太網對外服務：乙太網卡建議做冗餘，採用雙網卡綁定，建議是主備模式。每個乙太網的交換機也建議冗餘，使用類似VPC等虛擬綁定技術。交換機間互聯線路要求冗餘。

3.RoCE網路和私網：RoCE網卡自帶兩口，可以連接到不同的交換機上，但是這兩個口對於網卡吞吐量沒有影響。建議每個節點採用多網卡，每張網卡鏈接在不同的RoCE交換機上。RoCE網卡是不能做綁定的，都是實際的物理地址。所有的RoCE網路都劃在一個VLAN裡面。這裡還要關注一個私網，專門給GPFS走心跳和數據的網路，是TCPIP協議。

這個私網建議做多口綁定，也是主備模式，每個口連接到不同的RoCE交換機上，與RoCE網路劃分在同一個VLAN裡面。交換機的建議和乙太網交換機差不多，每個站點冗餘綁定。

共享存儲設計

5.如何設計存儲網路，仲裁站點需要存儲嗎？ NSD server怎麼配置？

通過一張圖來了解多站點GPFS複製拓撲。GPFS複製通過建立文件系統的兩個一致的副本來提供存儲器級別的高可用性；每個副本在另一個副本發生故障時都可用於恢復。

GPFS為文件系統的第一個副本和第二個副本提供了兩個單獨的存儲控制器。這些存儲控制器分別稱為冗餘組 1 和冗餘組 2。GPFS將數據和文件系統元數據都存儲在冗餘組中。

RSCT 和GPFS集群使用多數節點配額而不是仲裁磁碟配額。對於具有三個地理位置分散的站點的 GDPC，主站點和輔助站點具有相同數目的成員，並且每個站點中都有一個 CF。第三個站點中存在單個仲裁主機。仲裁主機是包含所有文件系統仲裁磁碟的文件系統仲裁冗餘組的所有者。這些磁碟僅包含文件系統描述符信息（例如，文件系統配置元數據）。

仲裁站點仲裁主機只需要通過 TCP/IP 訪問同一集群中的其他主機。它不需要訪問冗餘組 1 和冗餘組 2 中的數據。在仲裁主機上面，每個共享文件系統都需要獨立的文件系統仲裁磁碟用於文件系統配額以及進行恢復。每個磁碟最少需要 50 MB。它可以是本地物理磁碟或邏輯卷 (LV)。

擴展: 因為GPFS複製時通過在本機直接通過SAN訪問遠程磁碟來寫實現同步。當站點1和2之間網路出現問題的時候，數據複製需要停40秒（磁碟超時屬性）。這個在很多時候是不能容忍的，尤其出現網路質量差的情況下。所以我在這個地方做了些改進並在生產驗證。如圖中的db2logfs文件系統是用來放置資料庫日誌的，當資料庫日誌的io停止的時候資料庫也是會hang住，所以我將db2logfs相關遠程盤的主機映射都去掉，這樣強制db2logfs在複製的使用tcp網路。

資源設計

6. 如何分配成員和CF節點的資源。在DB2 pureScale GDPC資料庫雙活技術方案設計的資源設計環節中，我們該如何劃分及分配成員和CF節點的資源? 從哪些點方面進行入手考慮(例如並發訪問量、數據量等)，需要特別關注哪些什麼(例如寫讀比例、寫一致性、讀一致性等)？

CF和成員節點的內存主要就是CPU和內存的分布，還有就是RDMA通信網卡資源。

我們至今還沒有遇到網卡帶寬瓶頸。即便是在雙活環境出現CF和成員通信瓶頸也不是因為帶寬，而是Db2集群內部通信的機制導致。所以對於RDMA網卡，冗餘滿足高可用即可。

成員CPU的估算是基於工作負載來的，直接比較的對象是單機的資料庫資源配置。因為成員相對於傳統單機資料庫有更多的消耗，所以在同樣一個節點的負載需求情況下，建議成員CPU要比單機更多一些。 CF的CPU需求和RDMA卡有關係。IBM官方推薦一個CF的RDMA卡口對應6-8個CPU核心。

成員節點的內存也是相對於同樣工作負載下單機的資料庫內存配置來比較的。因為成員和CF之間有了更多的鎖，所以主要區別就在於成員節點的locklist需求變得更大，個人建議調整為單機資料庫的兩倍吧。CF的內存消耗主要是GBP和GLM這兩大塊。給大家一個公式:GBP大小是LOCAL BUFFERPOOL總頁面數*1.25KB*MEMBER數量。GLM就是所有member節點locklist總和吧。解決這兩大塊的估算再加一些就是整個CF的內存配置需求量了。

訪問設計

7. 客戶端採用什麼方式連接資料庫節點？

在雙活環境，怎麼最大化負載均衡並不是最主要的考慮因素，最大化性能才是需要考慮的。因為跨站點的通信延時，所以要盡量避免跨中心訪問。所以客戶端應該採用偏好鏈接的方式來訪問資料庫節點。

每個應用伺服器配置自己的數據源，通過Client Affinity的方式連接到資料庫成員節點，有效避免跨站點訪問。一旦成員節點出現故障，ACR可以自動將應用伺服器連接到其他存活的成員節點。

在這個基礎上，還有幾點需要注意:

1、跑批節點放在主CF同機房member上。

2、啟動資料庫的時候第一個啟動的成員節點要選擇和主CF在同一機房。因為有些資料庫的自動管理工作是在第一個啟動的member上完成的。

8.基於Db2 pureScale做資料庫雙活，對於重要業務需求的實現程度如何？方案的優點有哪些？

基於Db2 pureScale的資料庫雙活平台在我行已經上線三年，期間陸續遷入了6套優先順序比較高的系統。整個運行過程算是達到了預期。也經歷過網路故障等實際考驗，表現都如預期。所以這個高可用性和可維護性都得到了驗證。

但是這個方案在滿足數據0丟失，可用性非常高的情況下，還是犧牲了部分性能。因為距離的原因，寫盤和通信都不可避免延長。所以遷入地系統在跑批的時候明顯比以前長，這也是沒辦法的。

9.基於Db2 pureScale的資料庫雙活方案，有哪些局限？有什麼可以繼續改進的地方呢？

在這個方案裡面，我覺得從技術上還有比較多的地方需要改進。一方面熱點數據問題，雖然我們通過分區表隨機索引等方式打散熱點數據，但是還是需要從資料庫技術層面給出更好的改進。

另一方面是節點之間的通信，因為延時的緣故，還需要從技術上繼續減少交互。同時帶寬不是問題，通信的並發性也需要從技術上去解決。相信如果上述幾個方面能夠得到改進，這個方案將會得到更大的運用空間。

本號技術實戰和總結(20+本)

請識別小程序獲取電子書詳細信息

溫馨提示：

求知若渴, 虛心若愚

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！