簡介
在經濟復蘇的過程中，對核心業務數據的即時訪問始終是企業賴以生存，乃至獲得成功的關鍵因素。隨著越來越多的美元流入國內市場，企業需要借助具備高可用性和適用性的基礎設施來提高自己的敏捷性，以便能夠抓住新的發展機會。
大多數分布式軟件公司在營銷時都將可用性水平與“類大型機”或“5-9”可用性這樣的術語聯系在一起。這些短語都在試圖傳達業界公認的高可用性“黃金”標准（即 DB2 for z/OS ）所設定的持續可用性目標。
可用性 每年宕機時間 99.999% 5 分鐘 99.99% 50 分鐘 99.9% 8 小時 20 分鐘 99% 3 天 11 小時 18 分鐘 95% 18 天 6 小時 90% 34 天 17 小時 17 分鐘 85% 54 天 18 小時
如今，可用性並不僅僅意味著能夠從容應對組件故障並恢復正常的事務處理。如果您的服務水平協議（SLA）指定預期的查詢響應時間應在數秒之內，而服務器卻花費了 1 分鐘才返回查詢，那麼這就是可用性方面的問題。要確保可用性，您的系統不僅需要提供事務服務，還需要在 SLA 指定的期限內提供服務。
舉例來說，如果業務周期中的季節性波動造成了擴展方面的可用性問題，則真正具備可用性的架構必須能透明地增加資源，同時避免更改應用程序，以滿足不斷變化的性能需求。透明性是一個關鍵因素：在提高容量時，不應該讓應用程序具備集群感知性（應用程序知道哪些數據在哪個節點上，以避免節點之間的爭用）。企業無法投入足夠的資金來開發這些復雜的應用程序，因此無法實現合理的擴展。這是為什麼呢？首先，顯而易見的是，集群感知的應用程序需要適應數據量和分布狀態的不斷變化。集群感知的應用程序並不僅僅要求代碼隨著集群的發展而改變：這些代碼還需要經歷測試、質量保證（Q/A）、部署和認證等過程。這可能造成企業花費數周時間來進行協調，並且不可避免地會耗盡基礎設施中本應該有更好用途的資源。
用於在分布式平台（非大型機）上擴展數據庫事務的其他產品通常采用過時的架構，因此會為擴展帶來不必要的困難（比如說增加開銷），從而無法確保符合 SLA 協議。
IBM DB2 pureScale 技術（以下稱為 DB2 pureScale）可以將高可用性與真正的透明應用程序擴展結合在一個系統中，以便滿足您當前和未來對持續可用性的需求。IBM Power Systems 服務器和 IBM 存儲解決方案的整合是 DB2 pureScale 架構交付這種高價值解決方案的內在基礎。
到目前為止，“類大型機”仍然是一個引人注目的市場營銷詞匯。DB2 pureScale 標志著真正透明的擴展架構首次應用程序於分布式平台。本文將介紹 DB2 pureScale 技術的基本概念、背景信息，以及它在高可用性和透明應用程序擴展方面具備獨特優勢的奧秘。
DB2 pureScale 的基本信息
DB2 pureScale 是一種新的 DB2 可選特性，它允許您通過“雙機（active-active）”配置將數據庫擴展到一組服務器上，以便交付高水平的可用性和可伸縮性。在這種配置中，運行於各主機（或服務器）上的 DB2 副本可以同時讀取和寫入相同的數據。
共享 DB2 數據的一台或多台 DB2 服務器被稱作數據共享組。數據共享組中的 DB2 服務器是該組的成員。目前，數據共享組支持的最大成員數量是 128。
除了 DB2 成員外，PowerHA pureScale™ 組件還提供了整合的鎖管理以及針對數據分頁的全局緩存（稱作分組緩沖池）。
數據共享組中的各成員可以通過一個非常有效的 InfiniBand™ 網絡直接與 PowerHA pureScale 組件交互，如下圖所示。這意味著各成員與集中化的鎖和緩存設備之間建立了點到點（P2P）連接。
圖 1. InfiniBand 網絡直接與 PowerHA pureScale 組件交互
DB2 pureScale 的起源
您所聽到或看到的任何關於大型機級可用性的描述均指的是 DB2 for z/OS 針對可用性設定的黃金標准。事實上，世界上還沒有任何一款數據庫解決方案能在可用性方面與運行 DB2 for z/OS 的 System z 服務器相提並論。
DB2 for z/OS 數據共享所采用的底層技術可以確保服務器持續滿足 SLA 需求，因為 Coupling Facility 提供了集中化的鎖管理和全局緩存，這為快速從故障中恢復提供了保障。事實上，DB2 for z/OS 從嚴格意義上講已經實現了“5-9s”級的可用性，同時在無縫線性擴展工作負荷方面享有很高的聲望。
起 DB2 for z/OS，很多人都會想到廣泛的可伸縮性和極高的可用性。這種市場聲譽並非空穴來風，而是源於這些系統在數據庫工作負荷可用性方面的市場領先地位始終無人憾動。或許，最能佐證 DB2 for z/OS 強大功能的莫過於 Oracle 創始人兼 CEO Larry Ellison 的評論：
圖 2. Larry Ellison 的評論
圖字：我取笑過其他許多數據庫，但唯獨對大型機版本的 DB2 抱有尊重之心。它是當之無愧的一流技術。
DB2 for z/OS 究竟有何獨特之處，讓 Ellison 對它如此贊賞有加？ DB2 for z/OS 在數據共享領域中的“獨門秘笈”對其用戶來說再熟悉不過了，那就是眾所周知的 Coupling Facility。Coupling Facility 不僅為 DB2 for z/OS 賦予了線性擴展的能力，還提供了一個集中化設備來管理鎖。除此之外，它還充當髒分頁（dirty page）的全局共享緩沖池（有助於可伸縮性和可恢復性操作）。
DB2 pureScale 技術秉承了 DB2 for z/OS Coupling Facility 的傳統血脈，因此積累了諸多優勢，從而為 DB2 for z/OS 成為可用性和可伸縮性方面的“黃金”標准奠定了基礎。這是如何做到的呢？ DB2 pureScale 隨帶了一個 IBM powerHA pureScale 組件，該組件提供了同樣集中化的鎖管理和嚴格意義上的全局共享緩沖池架構。
其他供應商已經實現了采用共享磁盤架構的數據庫，其中最有影響力的是 Oracle Real Application Clusters (Oracle RAC)。但是，在開發和設計 Oracle RAC 時，分布式平台技術還不允許有效地訪問集中共享緩存。結果，Oracle RAC 的設計最終成為了一次模擬 DB2 for z/OS 的一次嘗試；這也是 Oracle RAC 的分布式鎖管理技術和分布式緩存架構的起源。Oracle RAC 在引入橫向擴展的共享磁盤架構之後也失去了 DB2 for z/OS 解決方案的簡潔性優勢。另一方面，DB2 for z/OS 和 DB2 pureScale 提供了相同的集中化資源管理，因此也解決了這些復雜的可伸縮性和可用性問題。本文將在稍後討論這方面的內容。
最根本的問題是，市場上只有一種架構交付了真正透明的應用程序可伸縮性和高可用性。隨著現代硬件在分布式平台上實現了互連，以及基於 InfiniBand 的無中斷 Remote Direct Memory Access (RDMA) 的深入發展，DB2 for z/OS 所采用的集中鎖和緩沖緩存算法已經不再是它所獨享的專利。DB2 pureScale 將這項久經行業考驗的技術引入到了分布式平台中，而這也代表了整個 IBM 家族的進步。
DB2 pureScale 實現透明的應用程序可伸縮性
在橫向擴展的數據庫環境中節省成本的關鍵是實現真正透明的應用程序擴展機制。透明的擴展意味著數據庫引擎可以為 OLTP 應用程序提供更大的吞吐量和更快的響應速度，而對數據本地性沒有要求。
數據的本地性表示應用程序所需的數據位於它所連接的服務器上，並且節點之間很少會爭用相同的數據分頁。在橫向擴展架構中，如果采用基於網絡的消息傳遞基礎設施來共享集群中的數據，則數據的本地性就顯得格外重要。
依靠本地性實現有效擴展的橫向擴展架構要求開發人員創建復雜的事務應用程序來實現集群感知性。集群感知的應用程序在開發和部署方面不僅更加復雜，而且成本更加高昂，同時當集群發生更改時還要求重新設計應用程序。一些供應商可能聲稱它們的架構能運行任何應用程序，而不需要修改；但是，如果在設計時沒有實現某種形式的集群感知性，它們就不會擴展任何應用程序。
透明的應用程序擴展意味著應用程序不需要具備集群感知性便可利用橫向擴展架構。DB2 pureScale 是分布式平台上所特有的，其高效性源於對現代網絡和硬件架構，以及 pureScale 的集中化鎖和緩存機制的利用。
為了減少集群中各節點之間的通信，以便實現鎖管理和全局緩存服務，DB2 pureScale 使用 powerHA pureScale 集群加速設備（以下簡稱為 CF）和 RDMA 技術來提供透明的應用程序可伸縮性。
RDMA 允許集群中的各個成員直接訪問 CF 中的內存，而 CF 也可以直接訪問各成員的內存。舉例來說，假定集群中的某成員（成員 1）希望讀取未存儲在本地緩沖池中的數據分頁。DB2 會分配一個代理（或線程）來執行此事務；然後，代理使用 RDMA 直接向 CF 的內存寫入數據，聲稱自己需要讀取某個特定分頁。如果成員 1 希望讀取的分頁位於 CF 的全局集中緩沖池中，則 CF 會將該分頁直接推送到成員 1 的內存中，而不是讓該成員的代理執行 I/O 操作從磁盤讀取它。通過使用 RDMA，成員 1 的代理只需向遠程服務器發起一個 memcopy（內存復制）調用，從而避免了成本較高的進程間通信、處理器中斷、IP 棧調用等。簡單來說，pureScale 允許成員的代理通過執行本地內存復制操作來執行遠程內存復制操作。
這些輕量級的遠程內存調用，連同集中緩沖池和鎖管理設備，意味著應用程序不需要連接到已經包含數據的成員。集群中的任何成員都可以有效地從全局緩沖池接收數據分頁，無論集群有多大。大多數 RDMA 調用都非常迅速，這使得發起調用的 DB2 進程在等待 CF 的響應時不需要讓出已分配的 CPU 時間，並且不需要重新調度便可完成任務。舉例來說，為了向 CF 通知某行即將更新（因此需要一個 X 鎖），某個成員的代理需要執行 Set Lock State (SLS) 請求，也就是將鎖信息直接寫入到 CF 上的內存中。CF 會確認集群中的其他成員沒有鎖定這個行，並直接修改請求成員的內存以批准鎖請求。這個 SLS 只需 15 微秒就可以完成整個過程，因此代理不需要讓出已分配的 CPU 時間。代理可以持續高效運行，而不需要像其他橫向擴展架構那樣等待 IP 中斷（避免不必要的上下文切換）。對於長時間運行的批量事務等特定操作來說，DB2 代理有必要讓出 CPU 時間，而 DB2 會自動決定是否動態讓出 CPU 時間。
DB2 pureScale 內置的針對集群成員的負載均衡機制是另一個重要的 DB2 可伸縮性特性。應用程序不需要具備集群感知性便可利用負載均衡機制。DB2 for z/OS 數據共享客戶如今所使用的客戶端驅動程序可以為 DB2 pureScale 提供集群負載均衡特性。
DB2 pureScale 實現可用性
橫向擴展架構的作用並不僅限於為容量的增加保留資源。采用這種架構設計的系統在遇到組件故障時可以繼續處理事務，從而能夠交付更高的可用性。
與分布式平台上的其他產品相比，DB2 pureScale 將可用性提升到了一個新的高度。DB2 pureScale 允許訪問所有不需要恢復的數據分頁，並且隨時可以洞察哪些分頁需要恢復，而不需要執行任何 I/O 操作。這是通過集中化 CF 的獨特功能實現的另一項重要創新。
每當成員將分頁讀取到它的緩沖池中時，CF 都會感知到這一事件並持續對其進行跟蹤。只要成員希望更新分布中的行，CF 同樣能夠知曉相關事件。當一個應用程序執行事務時，成員會將髒分頁直接寫入到 CF 的內存中。此流程允許集群中希望讀取這些經過更改的分頁的任何其他成員直接從 CF 獲取更新。更加重要的是，從恢復的角度來說，如果任何成員出現故障，CF 中會存在該失敗成員正在更新的一些分頁，同時還有一些分頁已經完成更新和提交，但尚未寫入磁盤。
任何關系數據庫管理系統（RDBMS）的恢復流程首先都需要重新執行任何已提交的事務，以確保磁盤上這些事務的分頁是最新的（此流程稱作重做恢復）。此外，任何數據庫服務器都需要撤銷任何掛起的事務，即在故障之前對磁盤數據執行了更改但尚未提交（此流程稱作撤銷恢復）。
在共享磁盤集群中，應確保集群中的其他節點沒有讀取或更新尚未恢復的磁盤中的任何分頁（恢復這些分頁之後才可以對這些行執行新的事務）。這正是 CF 的閃光之處：由於 CF 知道哪些分頁正處於故障節點的更新過程之中，並且 CF 已經將該節點提交的髒分頁保存在它的集中緩沖池中，因此 DB2 pureScale 在確定哪些分頁需要恢復時不必阻塞其他成員持續處理事務。其他架構則需要了解哪些節點占用的處理時間較多，以便根據鎖信息的分布來確定哪些節點必須恢復（詳見下文）。
從較高的層面來看，可以很容易地解釋 DB2 pureScale 環境中的這種恢復進程。每個成員都有空閒的進程，但它們都隨時准備著處理故障事件。當某個成員出現故障時，其中一個恢復進程便會激活；由於這些進程已經存在，因此操作系統不必浪費寶貴的系統時間來創建進程，為它分配內存等。此恢復進程會立即將 CF 中的髒分頁預取到它自己的本地緩沖池中。大部分恢復過程都不需要 I/O 操作，因為需要恢復的分頁已經在 CF 的集中緩沖池中了。此外，這種分頁預取機制將使用輕量級的 RDMA 在 CF 與恢復成員之間實現迅速有效的傳輸。在這段時間內，所有其他成員上的所有其他應用程序將繼續處理請求。如果它們需要從不需要恢復的任何分頁獲取任何數據，那麼它們可以
繼續執行自己事務。因此，它們可以繼續從磁盤讀取分頁，因為 CF 已經知道磁盤上的哪些分頁是干淨的，以及哪些分頁需要恢復。然後，恢復進程讀取故障成員的日志文件，以便於重放必要的事務來重做或撤銷故障成員所做的更新。
對於典型的事務工作負荷來說，從成員出現故障到故障節點未更新完的分頁可供其他事務使用的時間間隔通常在 20 秒以內。注意，這同時還包括故障檢測時間，而某些供應商在提到恢復時間時都排除了這一時間。數據庫中的所有其他分頁無時不刻（甚至在成員出現故障之後）都是完全可用的。
此外，系統中像 PowerHA pureScale 集群加速器這樣的組件是冗余的。DB2 pureScale 支持雙重 CF 功能，這樣鎖和共享緩存信息就可以存儲在兩個相互獨立的位置，以應對主 CF 出現故障的情況。
結束語
通過利用現代化的硬件架構，DB2 pureScale 可以將之前僅在 DB2 for z/OS 上可用的集中鎖和緩存功能引入到分布式平台中。對硬件和網絡的利用提高了並發性水平並顯著降低了開銷，從而提供了更高水平的可伸縮性。此外，集中鎖和分頁緩存允許 DB2 pureScale 持續感知在成員遇到故障時需要恢復哪些分頁。因此，在遇到故障時，所有不需要恢復的數據仍然能供其他應用程序使用，而故障節點正在更新的分頁將更加迅速地被恢復。
對於需要高可用性以及通過橫向發展實現成本收益的應用程序來說，DB2 pureScale 提供了一個可以滿足這些需求的解決方案，並且已經過了市場的考驗。
