分享專家: 孔再華 數(shù)據(jù)庫架構(gòu)師

文章來源: 轉(zhuǎn)自talkwithtrend 公眾號

具有豐富的數(shù)據(jù)庫環(huán)境問題診斷和性能調(diào)優(yōu)的經(jīng)驗，擅長DB2 PureScale 集群產(chǎn)品的項目咨詢和實施。

在兩地三中心建設(shè)過程中，我們發(fā)現(xiàn)采用傳統(tǒng)的容災(zāi)技術(shù)碰到3個問題。

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

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

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

因此相對于傳統(tǒng)容災(zāi)方式，我們希望建設(shè)一個雙活平臺，解決降低RTO時間、降低成本和降低切換風(fēng)險等需求。

在雙活平臺的選型過程中，基于當(dāng)前需求是傳統(tǒng)型業(yè)務(wù)(非互聯(lián)網(wǎng)類型)做遷移，當(dāng)前數(shù)據(jù)庫base是DB2和Oracle，從平臺角度發(fā)起而不想對業(yè)務(wù)開發(fā)進行改造，最終實現(xiàn)雙機房對等雙活等因素，我們最終發(fā)現(xiàn)Db2 pureScale GDPC方案最適合。

這個方案特點明顯: 高可用性，可擴展性和對應(yīng)用透明。那么選好型后，怎么落地成了最關(guān)心的問題。因為雙活技術(shù)的復(fù)雜性，在方案設(shè)計的每個環(huán)節(jié)都需要慎重考慮，選擇最合適的方式，最終形成自己需要的方案(以下為內(nèi)容分享)。

1.為什么要基于Db2 pureScale做數(shù)據(jù)庫雙活？優(yōu)勢和意義是什么？

為了保證數(shù)據(jù)多中心部署0丟失，降低容災(zāi)切換時間，減少人為操作風(fēng)險，降低成本。雙活系統(tǒng)就是要將這幾個方面做到極致。

在選型的過程中發(fā)現(xiàn)其實沒有太多選擇，能做到這一點的成熟軟件和技術(shù)只有Db2pureScale集群技術(shù)和OracleRAC技術(shù)。這里說說我們?yōu)槭裁匆肈b2pureScale而不是OracleRAC。

從業(yè)界經(jīng)驗來說，OracleExtendRAC是面向同城雙活的數(shù)據(jù)庫產(chǎn)品，然而從各方了解都不推薦使用，即便是使用了這個技術(shù)的案例里面，災(zāi)備機房節(jié)點也只是作為熱備，沒有提供對等的服務(wù)，這個是與我們建設(shè)雙活的應(yīng)用目標(biāo)有差距的。而DB2 GDPC（地理位置上分開的pureScale集群）方案從設(shè)計之初就是為了做對等雙活，國內(nèi)也已經(jīng)有上線案例。從廠商支持力度上來說，IBM主推這個技術(shù)并且支持好，Oracle相比差一點。從底層技術(shù)來說，IBM的pureScale在可擴展性，對應(yīng)用透明等特點上是優(yōu)于Oracle的。所以建議選擇Db2GDPC方案來建設(shè)雙活環(huán)境。

2. 基于Db2 pureScale的數(shù)據(jù)庫雙活方案設(shè)計，要遵循哪些重要原則？

如果將數(shù)據(jù)庫雙活平臺作為未來的常規(guī)建設(shè)，應(yīng)用越來越多的系統(tǒng)，那么在建設(shè)初期，我們就要設(shè)定好平臺的目標(biāo)：

1、通用性：基于LUW開放平臺，支持部署在任何廠商的存儲、服務(wù)器和操作系統(tǒng)上。不能選擇一體機，大型機等不通用的設(shè)備。

2、無差別性： 雙中心交易對等，同城之間同時處理業(yè)務(wù)請求，無主次之分。只有這樣的系統(tǒng)才能面對失去單數(shù)據(jù)中心的風(fēng)險。

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

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

5、可遷移性：平臺對業(yè)務(wù)系統(tǒng)透明，開發(fā)無需改動代碼，即可快速部署到該平臺。同樣該平臺部署的系統(tǒng)也可平滑遷移出來。

6、安全穩(wěn)定運行，該平臺可以實現(xiàn)5個9的運行目標(biāo)。

基于以上目標(biāo)，在Db2 pureScale的數(shù)據(jù)庫雙活方案設(shè)計里面，我們遵循對等雙活和對應(yīng)用透明的原則，克服困難，最大化雙活的高可用性優(yōu)點，改善性能相關(guān)的缺點。

總體設(shè)計

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

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

雙站點的定位和條件:

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

2.雙站點的CF和成員節(jié)點是對等的。每個生產(chǎn)站點都有一個 CF 以及相同數(shù)目的主機/LPAR 和成員。

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

4.對于RDMA網(wǎng)絡(luò)支持RoCE和infiniband。個人建議使用RoCE，通用性和可部署性強。如果使用 RoCE 進行成員/CF 通信：使用多個適配器端口進行成員和 CF 通信，以適應(yīng)其他帶寬和提供冗余。對于以完全冗余方式配置的總共四個交換機，在每個站點中使用雙交換機。將每個成員和 CF 中的其他綁定的專用以太網(wǎng)網(wǎng)絡(luò)接口設(shè)置為 GPFS 脈動信號網(wǎng)絡(luò)。也就是我們說的私有TCP網(wǎng)絡(luò)。如果使用 Infiniband 進行成員/CF 通信：

僅支持每個成員和 CF 具有單個適配器端口以及每個站點具有單個交換機。此接口用于成員和 CF 通信以及 GPFS 脈動信號網(wǎng)絡(luò)。

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

1. 單個主機（非成員主機，也非 CF 主機），專用于集群仲裁職責(zé)，與集群中的其他主機位于相同操作系統(tǒng)級別?？梢允褂锰摂M機。

2. 不需要訪問兩個生產(chǎn)站點中的 SAN。

3.不需要RDMA通信，也不需要私有網(wǎng)絡(luò)（RoCE的情況下使用到的TCP私網(wǎng)）。

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

請遵循下列準(zhǔn)則來配置 LV:

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

有限的條件下，例如只有兩個數(shù)據(jù)中心，仲裁站點可以放在所謂的主中心機房里，但是硬件上要和其他節(jié)點分開。這個主中心機房的定位就是可能于此關(guān)聯(lián)的其他重要系統(tǒng)在這個機房，訪問更直接和快速。在存在這種定位的情況下，主CF節(jié)點，跑批的成員節(jié)點建議放在這個機房里。

通信網(wǎng)絡(luò)設(shè)計

4. 如何規(guī)劃和設(shè)計集群內(nèi)部通信網(wǎng)絡(luò)? 

在整個DB2GDPC的方案里面，仲裁站點僅僅需要TCPIP網(wǎng)絡(luò)通即可，不需要SAN，RDMA，私網(wǎng)等，所以需要重點關(guān)注雙活站點的CF和成員節(jié)點的網(wǎng)絡(luò)設(shè)計。

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

2. 以太網(wǎng)對外服務(wù)：以太網(wǎng)卡建議做冗余，采用雙網(wǎng)卡綁定，建議是主備模式。每個以太網(wǎng)的交換機也建議冗余，使用類似VPC等虛擬綁定技術(shù)。交換機間互聯(lián)線路要求冗余。

3. RoCE網(wǎng)絡(luò)和私網(wǎng)：RoCE網(wǎng)卡自帶兩口，可以連接到不同的交換機上，但是這兩個口對于網(wǎng)卡吞吐量沒有影響。建議每個節(jié)點采用多網(wǎng)卡，每張網(wǎng)卡鏈接在不同的RoCE交換機上。RoCE網(wǎng)卡是不能做綁定的，都是實際的物理地址。所有的RoCE網(wǎng)絡(luò)都劃在一個VLAN里面。這里還要關(guān)注一個私網(wǎng)，專門給GPFS走心跳和數(shù)據(jù)的網(wǎng)絡(luò)，是TCPIP協(xié)議。

這個私網(wǎng)建議做多口綁定，也是主備模式，每個口連接到不同的RoCE交換機上，與RoCE網(wǎng)絡(luò)劃分在同一個VLAN里面。交換機的建議和以太網(wǎng)交換機差不多，每個站點冗余綁定。

共享存儲設(shè)計

5. 如何設(shè)計存儲網(wǎng)絡(luò)，仲裁站點需要存儲嗎？ NSD server怎么配置？

通過一張圖來了解多站點GPFS復(fù)制拓撲。GPFS復(fù)制通過建立文件系統(tǒng)的兩個一致的副本來提供存儲器級別的高可用性；每個副本在另一個副本發(fā)生故障時都可用于恢復(fù)。

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

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

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

擴展: 因為GPFS復(fù)制時通過在本機直接通過SAN訪問遠程磁盤來寫實現(xiàn)同步。當(dāng)站點1和2之間網(wǎng)絡(luò)出現(xiàn)問題的時候，數(shù)據(jù)復(fù)制需要停40秒（磁盤超時屬性）。這個在很多時候是不能容忍的，尤其出現(xiàn)網(wǎng)絡(luò)質(zhì)量差的情況下。所以我在這個地方做了些改進并在生產(chǎn)驗證。如圖中的db2logfs文件系統(tǒng)是用來放置數(shù)據(jù)庫日志的，當(dāng)數(shù)據(jù)庫日志的io停止的時候數(shù)據(jù)庫也是會hang住，所以我將db2logfs相關(guān)遠程盤的主機映射都去掉，這樣強制db2logfs在復(fù)制的使用tcp網(wǎng)絡(luò)。

資源設(shè)計

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

CF和成員節(jié)點的內(nèi)存主要就是CPU和內(nèi)存的分布，還有就是RDMA通信網(wǎng)卡資源。

我們至今還沒有遇到網(wǎng)卡帶寬瓶頸。即便是在雙活環(huán)境出現(xiàn)CF和成員通信瓶頸也不是因為帶寬，而是Db2集群內(nèi)部通信的機制導(dǎo)致。所以對于RDMA網(wǎng)卡，冗余滿足高可用即可。

成員CPU的估算是基于工作負載來的，直接比較的對象是單機的數(shù)據(jù)庫資源配置。因為成員相對于傳統(tǒng)單機數(shù)據(jù)庫有更多的消耗，所以在同樣一個節(jié)點的負載需求情況下，建議成員CPU要比單機更多一些。 CF的CPU需求和RDMA卡有關(guān)系。IBM官方推薦一個CF的RDMA卡口對應(yīng)6-8個CPU核心。

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

訪問設(shè)計

7. 客戶端采用什么方式連接數(shù)據(jù)庫節(jié)點？

在雙活環(huán)境，怎么最大化負載均衡并不是最主要的考慮因素，最大化性能才是需要考慮的。因為跨站點的通信延時，所以要盡量避免跨中心訪問。所以客戶端應(yīng)該采用偏好鏈接的方式來訪問數(shù)據(jù)庫節(jié)點。

每個應(yīng)用服務(wù)器配置自己的數(shù)據(jù)源，通過Client Affinity的方式連接到數(shù)據(jù)庫成員節(jié)點，有效避免跨站點訪問。一旦成員節(jié)點出現(xiàn)故障，ACR可以自動將應(yīng)用服務(wù)器連接到其他存活的成員節(jié)點。 

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

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

2、啟動數(shù)據(jù)庫的時候第一個啟動的成員節(jié)點要選擇和主CF在同一機房。因為有些數(shù)據(jù)庫的自動管理工作是在第一個啟動的member上完成的。

8.基于Db2 pureScale做數(shù)據(jù)庫雙活，對于重要業(yè)務(wù)需求的實現(xiàn)程度如何？方案的優(yōu)點有哪些？

基于Db2 pureScale的數(shù)據(jù)庫雙活平臺在我行已經(jīng)上線三年，期間陸續(xù)遷入了6套優(yōu)先級比較高的系統(tǒng)。整個運行過程算是達到了預(yù)期。也經(jīng)歷過網(wǎng)絡(luò)故障等實際考驗，表現(xiàn)都如預(yù)期。所以這個高可用性和可維護性都得到了驗證。

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

9.基于Db2 pureScale的數(shù)據(jù)庫雙活方案，有哪些局限？有什么可以繼續(xù)改進的地方呢？

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

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