在兩地三中心建設(shè)過程中，我們發(fā)現(xiàn)采用傳統(tǒng)的容災(zāi)技術(shù)碰到3個問題。 1. 切換時間太長，即使通過自動化實(shí)現(xiàn)，主切備和備切主都需要花費(fèi)幾十分鐘時間。 2. 操作風(fēng)險(xiǎn)太大，比如核心系統(tǒng)切換涉及到20步以上的操作步驟和上百條命令，每條命令都有出錯的可能。 3. 建設(shè)成本太高，同城機(jī)房按照1比2甚至1比1 的比例進(jìn)行建設(shè)，服務(wù)器平時完全閑置，除了一次性投入，每年還要耗費(fèi)大量的維護(hù)費(fèi)用。 因此相對于傳統(tǒng)容災(zāi)方式，我們希望建設(shè)一個雙活平臺，解決降低RTO時間、降低成本和降低切換風(fēng)險(xiǎn)等需求。 在雙活平臺的選型過程中，基于當(dāng)前需求是傳統(tǒng)型業(yè)務(wù)(非互聯(lián)網(wǎng)類型)做遷移，當(dāng)前數(shù)據(jù)庫base是DB2和Oracle，從平臺角度發(fā)起而不想對業(yè)務(wù)開發(fā)進(jìn)行改造，最終實(shí)現(xiàn)雙機(jī)房對等雙活等因素，我們最終發(fā)現(xiàn)Db2 pureScale GDPC方案最適合。 這個方案特點(diǎn)明顯: 高可用性，可擴(kuò)展性和對應(yīng)用透明。那么選好型后，怎么落地成了最關(guān)心的問題。因?yàn)殡p活技術(shù)的復(fù)雜性，在方案設(shè)計(jì)的每個環(huán)節(jié)都需要慎重考慮，選擇最合適的方式，最終形成自己需要的方案(以下為內(nèi)容分享)。
為了保證數(shù)據(jù)多中心部署0丟失，降低容災(zāi)切換時間，減少人為操作風(fēng)險(xiǎn)，降低成本。雙活系統(tǒng)就是要將這幾個方面做到極致。 在選型的過程中發(fā)現(xiàn)其實(shí)沒有太多選擇，能做到這一點(diǎn)的成熟軟件和技術(shù)只有Db2pureScale集群技術(shù)和OracleRAC技術(shù)。這里說說我們?yōu)槭裁匆肈b2pureScale而不是OracleRAC。 從業(yè)界經(jīng)驗(yàn)來說，OracleExtendRAC是面向同城雙活的數(shù)據(jù)庫產(chǎn)品，然而從各方了解都不推薦使用，即便是使用了這個技術(shù)的案例里面，災(zāi)備機(jī)房節(jié)點(diǎn)也只是作為熱備，沒有提供對等的服務(wù)，這個是與我們建設(shè)雙活的應(yīng)用目標(biāo)有差距的。而DB2 GDPC（地理位置上分開的pureScale集群）方案從設(shè)計(jì)之初就是為了做對等雙活，國內(nèi)也已經(jīng)有上線案例。從廠商支持力度上來說，IBM主推這個技術(shù)并且支持好，Oracle相比差一點(diǎn)。從底層技術(shù)來說，IBM的pureScale在可擴(kuò)展性，對應(yīng)用透明等特點(diǎn)上是優(yōu)于Oracle的。所以建議選擇Db2GDPC方案來建設(shè)雙活環(huán)境。
如果將數(shù)據(jù)庫雙活平臺作為未來的常規(guī)建設(shè)，應(yīng)用越來越多的系統(tǒng)，那么在建設(shè)初期，我們就要設(shè)定好平臺的目標(biāo)： 1、通用性：基于LUW開放平臺，支持部署在任何廠商的存儲、服務(wù)器和操作系統(tǒng)上。不能選擇一體機(jī)，大型機(jī)等不通用的設(shè)備。 2、無差別性： 雙中心交易對等，同城之間同時處理業(yè)務(wù)請求，無主次之分。只有這樣的系統(tǒng)才能面對失去單數(shù)據(jù)中心的風(fēng)險(xiǎn)。 3、高可用性：最下化降低同城切換時間，同城站點(diǎn)出問題不會影響全局業(yè)務(wù)。業(yè)務(wù)切換需要在最短時間內(nèi)完成。 4、可維護(hù)性：基礎(chǔ)設(shè)置重大變更不停機(jī)，可以通過滾動升級的方式完成維護(hù)操作。 5、可遷移性：平臺對業(yè)務(wù)系統(tǒng)透明，開發(fā)無需改動代碼，即可快速部署到該平臺。同樣該平臺部署的系統(tǒng)也可平滑遷移出來。 6、安全穩(wěn)定運(yùn)行，該平臺可以實(shí)現(xiàn)5個9的運(yùn)行目標(biāo)。 基于以上目標(biāo)，在Db2 pureScale的數(shù)據(jù)庫雙活方案設(shè)計(jì)里面，我們遵循對等雙活和對應(yīng)用透明的原則，克服困難，最大化雙活的高可用性優(yōu)點(diǎn)，改善性能相關(guān)的缺點(diǎn)。
首選需要說明DB2GDPC方案邏輯上需要三個站點(diǎn)，其中兩個站點(diǎn)作為雙活的數(shù)據(jù)中心，第三個站點(diǎn)作為仲裁站點(diǎn)。 雙站點(diǎn)的定位和條件: 1.雙活站點(diǎn)之間需要可靠的 TCP/IP 鏈接相互通信，還需要RDMA(具有 RoCE 或 Infiniband)網(wǎng)絡(luò)鏈接。具有成員和 CF 的兩個站點(diǎn)是生產(chǎn)站點(diǎn)，它們處理數(shù)據(jù)庫事務(wù)。這兩個生產(chǎn)站點(diǎn)相距應(yīng)該不超過 50 公里，通過 WAN 或暗光纖（必要時還使用距離范圍擴(kuò)展器）來連接這兩個站點(diǎn)，并且在它們之間配置了單個 IP 子網(wǎng)。距離更短將獲得更高性能。在工作負(fù)載相當(dāng)少的情況下，可以接受更遠(yuǎn)的距離（最多可達(dá) 70 或 80 公里）。 2.雙站點(diǎn)的CF和成員節(jié)點(diǎn)是對等的。每個生產(chǎn)站點(diǎn)都有一個 CF 以及相同數(shù)目的主機(jī)/LPAR 和成員。 3.每個生產(chǎn)站點(diǎn)都有它自己的專用本地 SAN 控制器。SAN 已分區(qū)，以便可從這兩個生產(chǎn)站點(diǎn)直接訪問用于 DB2 pureScale 實(shí)例的 LUN。在站點(diǎn)之間需要 LUN 之間的一對一映射，所以第一個站點(diǎn)上的每個 LUN 都在第二個站點(diǎn)上具有相同大小的對應(yīng) LUN。而GPFS同步復(fù)制用作存儲器復(fù)制機(jī)制。 4.對于RDMA網(wǎng)絡(luò)支持RoCE和infiniband。個人建議使用RoCE，通用性和可部署性強(qiáng)。如果使用 RoCE 進(jìn)行成員/CF 通信：使用多個適配器端口進(jìn)行成員和 CF 通信，以適應(yīng)其他帶寬和提供冗余。對于以完全冗余方式配置的總共四個交換機(jī)，在每個站點(diǎn)中使用雙交換機(jī)。將每個成員和 CF 中的其他綁定的專用以太網(wǎng)網(wǎng)絡(luò)接口設(shè)置為 GPFS 脈動信號網(wǎng)絡(luò)。也就是我們說的私有TCP網(wǎng)絡(luò)。如果使用 Infiniband 進(jìn)行成員/CF 通信： 僅支持每個成員和 CF 具有單個適配器端口以及每個站點(diǎn)具有單個交換機(jī)。此接口用于成員和 CF 通信以及 GPFS 脈動信號網(wǎng)絡(luò)。 第三個站點(diǎn)的定位和條件: 1. 單個主機(jī)（非成員主機(jī)，也非 CF 主機(jī)），專用于集群仲裁職責(zé)，與集群中的其他主機(jī)位于相同操作系統(tǒng)級別。可以使用虛擬機(jī)。 2. 不需要訪問兩個生產(chǎn)站點(diǎn)中的 SAN。 3.不需要RDMA通信，也不需要私有網(wǎng)絡(luò)（RoCE的情況下使用到的TCP私網(wǎng)）。 需要為集群中的每個共享文件系統(tǒng)都需要仲裁盤，這個文件系統(tǒng)的仲裁盤就是從這個第三站點(diǎn)劃分出來的。沒有用戶數(shù)據(jù)存儲在這些設(shè)備上，因?yàn)檫@些設(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ù)，而邏輯卷數(shù)又取決于共享文件系統(tǒng)數(shù)。如果有可能，請使用兩個物理卷以提供冗余。 有限的條件下，例如只有兩個數(shù)據(jù)中心，仲裁站點(diǎn)可以放在所謂的主中心機(jī)房里，但是硬件上要和其他節(jié)點(diǎn)分開。這個主中心機(jī)房的定位就是可能于此關(guān)聯(lián)的其他重要系統(tǒng)在這個機(jī)房，訪問更直接和快速。在存在這種定位的情況下，主CF節(jié)點(diǎn)，跑批的成員節(jié)點(diǎn)建議放在這個機(jī)房里。
在整個DB2GDPC的方案里面，仲裁站點(diǎn)僅僅需要TCPIP網(wǎng)絡(luò)通即可，不需要SAN，RDMA，私網(wǎng)等，所以需要重點(diǎn)關(guān)注雙活站點(diǎn)的CF和成員節(jié)點(diǎn)的網(wǎng)絡(luò)設(shè)計(jì)。 1. 雙站點(diǎn)DWDM通信硬件：建議冗余，租用不同運(yùn)營商線路。 2. 以太網(wǎng)對外服務(wù)：以太網(wǎng)卡建議做冗余，采用雙網(wǎng)卡綁定，建議是主備模式。每個以太網(wǎng)的交換機(jī)也建議冗余，使用類似VPC等虛擬綁定技術(shù)。交換機(jī)間互聯(lián)線路要求冗余。 3. RoCE網(wǎng)絡(luò)和私網(wǎng)：RoCE網(wǎng)卡自帶兩口，可以連接到不同的交換機(jī)上，但是這兩個口對于網(wǎng)卡吞吐量沒有影響。建議每個節(jié)點(diǎn)采用多網(wǎng)卡，每張網(wǎng)卡鏈接在不同的RoCE交換機(jī)上。RoCE網(wǎng)卡是不能做綁定的，都是實(shí)際的物理地址。所有的RoCE網(wǎng)絡(luò)都劃在一個VLAN里面。這里還要關(guān)注一個私網(wǎng)，專門給GPFS走心跳和數(shù)據(jù)的網(wǎng)絡(luò)，是TCPIP協(xié)議。 這個私網(wǎng)建議做多口綁定，也是主備模式，每個口連接到不同的RoCE交換機(jī)上，與RoCE網(wǎng)絡(luò)劃分在同一個VLAN里面。交換機(jī)的建議和以太網(wǎng)交換機(jī)差不多，每個站點(diǎn)冗余綁定。
通過一張圖來了解多站點(diǎn)GPFS復(fù)制拓?fù)?。GPFS復(fù)制通過建立文件系統(tǒng)的兩個一致的副本來提供存儲器級別的高可用性；每個副本在另一個副本發(fā)生故障時都可用于恢復(fù)。 GPFS為文件系統(tǒng)的第一個副本和第二個副本提供了兩個單獨(dú)的存儲控制器。這些存儲控制器分別稱為冗余組 1 和冗余組 2。GPFS將數(shù)據(jù)和文件系統(tǒng)元數(shù)據(jù)都存儲在冗余組中。 RSCT 和GPFS集群使用多數(shù)節(jié)點(diǎn)配額而不是仲裁磁盤配額。對于具有三個地理位置分散的站點(diǎn)的 GDPC，主站點(diǎn)和輔助站點(diǎn)具有相同數(shù)目的成員，并且每個站點(diǎn)中都有一個 CF。第三個站點(diǎn)中存在單個仲裁主機(jī)。仲裁主機(jī)是包含所有文件系統(tǒng)仲裁磁盤的文件系統(tǒng)仲裁冗余組的所有者。這些磁盤僅包含文件系統(tǒng)描述符信息（例如，文件系統(tǒng)配置元數(shù)據(jù)）。 仲裁站點(diǎn)仲裁主機(jī)只需要通過 TCP/IP 訪問同一集群中的其他主機(jī)。它不需要訪問冗余組 1 和冗余組 2 中的數(shù)據(jù)。在仲裁主機(jī)上面，每個共享文件系統(tǒng)都需要獨(dú)立的文件系統(tǒng)仲裁磁盤用于文件系統(tǒng)配額以及進(jìn)行恢復(fù)。每個磁盤最少需要 50 MB。它可以是本地物理磁盤或邏輯卷 (LV)。 擴(kuò)展: 因?yàn)镚PFS復(fù)制時通過在本機(jī)直接通過SAN訪問遠(yuǎn)程磁盤來寫實(shí)現(xiàn)同步。當(dāng)站點(diǎn)1和2之間網(wǎng)絡(luò)出現(xiàn)問題的時候，數(shù)據(jù)復(fù)制需要停40秒（磁盤超時屬性）。這個在很多時候是不能容忍的，尤其出現(xiàn)網(wǎng)絡(luò)質(zhì)量差的情況下。所以我在這個地方做了些改進(jìn)并在生產(chǎn)驗(yàn)證。如圖中的db2logfs文件系統(tǒng)是用來放置數(shù)據(jù)庫日志的，當(dāng)數(shù)據(jù)庫日志的io停止的時候數(shù)據(jù)庫也是會hang住，所以我將db2logfs相關(guān)遠(yuǎn)程盤的主機(jī)映射都去掉，這樣強(qiáng)制db2logfs在復(fù)制的使用tcp網(wǎng)絡(luò)。
CF和成員節(jié)點(diǎn)的內(nèi)存主要就是CPU和內(nèi)存的分布，還有就是RDMA通信網(wǎng)卡資源。 我們至今還沒有遇到網(wǎng)卡帶寬瓶頸。即便是在雙活環(huán)境出現(xiàn)CF和成員通信瓶頸也不是因?yàn)閹?，而是Db2集群內(nèi)部通信的機(jī)制導(dǎo)致。所以對于RDMA網(wǎng)卡，冗余滿足高可用即可。 成員CPU的估算是基于工作負(fù)載來的，直接比較的對象是單機(jī)的數(shù)據(jù)庫資源配置。因?yàn)槌蓡T相對于傳統(tǒng)單機(jī)數(shù)據(jù)庫有更多的消耗，所以在同樣一個節(jié)點(diǎn)的負(fù)載需求情況下，建議成員CPU要比單機(jī)更多一些。 CF的CPU需求和RDMA卡有關(guān)系。IBM官方推薦一個CF的RDMA卡口對應(yīng)6-8個CPU核心。 成員節(jié)點(diǎn)的內(nèi)存也是相對于同樣工作負(fù)載下單機(jī)的數(shù)據(jù)庫內(nèi)存配置來比較的。因?yàn)槌蓡T和CF之間有了更多的鎖，所以主要區(qū)別就在于成員節(jié)點(diǎn)的locklist需求變得更大，個人建議調(diào)整為單機(jī)數(shù)據(jù)庫的兩倍吧。CF的內(nèi)存消耗主要是GBP和GLM這兩大塊。給大家一個公式:GBP大小是LOCAL BUFFERPOOL總頁面數(shù)*1.25KB*MEMBER數(shù)量。GLM就是所有member節(jié)點(diǎn)locklist總和吧。解決這兩大塊的估算再加一些就是整個CF的內(nèi)存配置需求量了。
在雙活環(huán)境，怎么最大化負(fù)載均衡并不是最主要的考慮因素，最大化性能才是需要考慮的。因?yàn)榭缯军c(diǎn)的通信延時，所以要盡量避免跨中心訪問。所以客戶端應(yīng)該采用偏好鏈接的方式來訪問數(shù)據(jù)庫節(jié)點(diǎn)。 每個應(yīng)用服務(wù)器配置自己的數(shù)據(jù)源，通過Client Affinity的方式連接到數(shù)據(jù)庫成員節(jié)點(diǎn)，有效避免跨站點(diǎn)訪問。一旦成員節(jié)點(diǎn)出現(xiàn)故障，ACR可以自動將應(yīng)用服務(wù)器連接到其他存活的成員節(jié)點(diǎn)。 在這個基礎(chǔ)上，還有幾點(diǎn)需要注意: 1、跑批節(jié)點(diǎn)放在主CF同機(jī)房member上。 2、啟動數(shù)據(jù)庫的時候第一個啟動的成員節(jié)點(diǎn)要選擇和主CF在同一機(jī)房。因?yàn)橛行?shù)據(jù)庫的自動管理工作是在第一個啟動的member上完成的。
基于Db2 pureScale的數(shù)據(jù)庫雙活平臺在我行已經(jīng)上線三年，期間陸續(xù)遷入了6套優(yōu)先級比較高的系統(tǒng)。整個運(yùn)行過程算是達(dá)到了預(yù)期。也經(jīng)歷過網(wǎng)絡(luò)故障等實(shí)際考驗(yàn)，表現(xiàn)都如預(yù)期。所以這個高可用性和可維護(hù)性都得到了驗(yàn)證。 但是這個方案在滿足數(shù)據(jù)0丟失，可用性非常高的情況下，還是犧牲了部分性能。因?yàn)榫嚯x的原因，寫盤和通信都不可避免延長。所以遷入地系統(tǒng)在跑批的時候明顯比以前長，這也是沒辦法的。
在這個方案里面，我覺得從技術(shù)上還有比較多的地方需要改進(jìn)。一方面熱點(diǎn)數(shù)據(jù)問題，雖然我們通過分區(qū)表隨機(jī)索引等方式打散熱點(diǎn)數(shù)據(jù)，但是還是需要從數(shù)據(jù)庫技術(shù)層面給出更好的改進(jìn)。 另一方面是節(jié)點(diǎn)之間的通信，因?yàn)檠訒r的緣故，還需要從技術(shù)上繼續(xù)減少交互。同時帶寬不是問題，通信的并發(fā)性也需要從技術(shù)上去解決。相信如果上述幾個方面能夠得到改進(jìn)，這個方案將會得到更大的運(yùn)用空間。 |
|
|
