Centos6下 db2 9.7 HA環境虛擬機下載

本博主配置好的Centos6下 db2 9.7 HA環境虛擬機下載,鏈接:https://pan.baidu.com/s/147REuu6SrnF5iTUZTzDCmw
提取碼:67p7 下載後,用Vmware workstation打開 即可以正常使用

高可用性(HA)集群通過一組計算機系統提供透明的冗餘處理能力,從而實現不間斷應用的目標。

高可用性(High Availability,簡稱HA)集群是共同為客戶機提供網絡資源的一組計算機系統。其中每一台提供服務的計算機稱為節點(Node)。當一個節點不可用或者不能處理客戶的請求時,該請求會及時轉到另外的可用節點來處理,而這些對於客戶端是透明的,客戶不必關心要使用資源的具體位置,集群系統會自動完成。

HA集群系統硬件拓撲形式

基於共享磁盤的HA集群系統通過共享盤櫃實現集群中各節點的數據共享,包含主服務器、從服務器、存儲陣列三種主要設備,以及設備間的心跳連接線。

而基於磁盤鏡像的HA集群系統不包含存儲陣列。集群中兩種服務器的本地硬盤通過數據鏡像技術,實現集群中各節點之間的數據同步,從而實現集群的功能。

實際應用中,將節點1配置成「主服務器」,節點2配置成「從服務器」,主從服務器有各自的IP地址,通過HA集群軟件控制,主從服務器有一個共同的虛擬IP地址,客戶端僅需使用這個虛擬IP,而不需要分別使用主從IP地址。這種措施是HA集群的首要技術保證,該技術確保集群服務的切換不會影響客戶IP層的訪問。

公網(Public Network)是應用系統實際提供服務的網絡,私網(Private Network)是集群系統內部通過心跳線連接成的網絡。

心跳線是HA集群系統中主從節點通信的物理通道,通過HA集群軟件控制確保服務數據和狀態同步。不同HA集群軟件對於心跳線的處理有各自的技巧,有的採用專用板卡和專用的連接線,有的採用串並口或USB口處理,有的採用TCP/IP網絡處理,其可靠性和成本都有所不同。近幾年,基於TCP/IP技術的心跳線因其成本低、性能優異而被廣泛採用。具體實現中主從服務器上至少各需配置兩塊網卡。

HA集群軟件體系結構

HA集群軟件是架構在操作系統之上的程序,其主要由守護進程、應用程序代理、管理工具、開發腳本等四部分構成,應用服務系統是為客戶服務的應用系統程序,比如MS SQL Server,Oracle,Sybase,DB2 UDB,Exchange,Lotus Notes等應用系統軟件。

不是每一個應用程序都能夠實現HA集群管理,也不是每一個HA集群軟件可以管理所有的應用程序,這是因為其代理模塊(Agent)有不同的功能。HA軟件的代理模塊一般支持使用頻度最高的軟件,如上述所列舉的數據庫系統和郵件系統,但為了能夠支持更多應用實現HA集群,有的HA軟件開放二次開發接口。

主從節點資源配置

HA集群軟件的本質是當主服務器出現故障時,從服務器及時接管主服務器的資源,這些資源包括處理器、內存進程和磁盤數據。接管進程意味着接管該服務進程的內存數據列表,採用共享磁盤技術方式的集群無需做存儲數據接管,採用磁盤鏡像技術方式的集群則使用本機的存儲數據。

主從服務器的資源(處理器、內存、磁盤)配置具有科學性和技巧性。系統物理內存過低,會使系統頻繁使用效率低下的「虛擬內存」,導致系統反應遲鈍,也使得客戶端響應緩慢,甚至出現「系統服務超時(Timeout)」形態的系統報錯,沒有達到高可靠的目的。所以,HA集群系統要求從服務器(故障切換節點)的內存容量應不小於主服務器的內存容量,其內存配置應該至少為應用系統對內存的基本需求。

從節點服務器需要的CPU數量應以不間斷客戶服務為目的。其CPU處理能力應不小於主服務器的CPU處理能力,若板卡、CPU等型號相同,從服務器的CPU個數應不少於主服務器的CPU個數。

採取磁盤鏡像的從服務器存儲空間應不小於主服務器存儲空間。

總之,從節點資源的各項指標應該不低於主節點資源的各項指標。若系統採用多個主節點向一個從節點容災時(N+1模式),從節點資源的配置策略需要依據系統管理員對整個系統定義的容災安全級別來確定。假如主節點的個數為M,從節點的個數為1,系統管理員定義允許同時容忍N(N≤M)個主節點宕機,那麼從節點的資源配置應為最大前N個主節點資源的各項指標之和。

HA集群部署模式

主/主 英文名稱「Active/Active」,這是最常用的集群模型。它提供了高可用性,並且在只有一個節點在線時提供可以接受的性能。該模型允許最大程度利用硬件資源。每個節點都通過網絡對客戶機提供資源,每個節點的容量被定義好,使得性能達到最優,並且每個節點都可以在故障轉移時臨時接管另一個節點的工作。所有的服務在故障轉移後仍保持可用,但是性能通常都會下降。

主/從 英文名稱「Active/Standby」,或者「Active/Passive」。為了提供最大的可用性,以及對性能的最小影響,「主/從」模型需要一個節點在正常工作時處於備用狀態,主節點處理客戶機的請求,而備用節點處於空閑狀態。當主節點出現故障時,備用節點會接管主節點的工作,繼續為客戶機提供服務,並且不會有任何性能上的影響。

本博主配置好的Centos6下 db2 9.7 HA環境虛擬機下載,鏈接:https://pan.baidu.com/s/147REuu6SrnF5iTUZTzDCmw
提取碼:67p7 下載後,用Vmware workstation打開 即可以正常使用

混合型(Hybrid) 是上面兩種模型的結合,只針對關鍵應用進行故障轉移,這樣可以對這些應用實現可用性的同時讓非關鍵的應用在正常運作時也可以在服務器上運行。當出現故障時,出現故障服務器上的不太關鍵的應用就不可用了,但是那些關鍵應用會轉移到另一個可用的節點上,從而達到性能和容錯兩方面的平衡。

不同HA集群軟件支持不同的部署模式,一般有以下三種情況:

雙機模式 非常普遍使用的一種方式,俗稱「雙機熱備」。使用在應用系統單一、要求可用性高的環境中,由一個主服務器、一個從服務器和一個存儲陣列等三個設備組成。

1+I模式 系統由一個主節點、若干個(I個)從節點以及一些輔助設備(存儲陣列)等組成。使用在應用系統單一,要求可用性能極高的核心業務系統中。

N+I模式 系統由多個主節點、若干個從節點以及一些輔助設備(存儲陣列、交換機)等組成。在實際應用中,一些用戶並不滿足上述兩種模式,認為「冗餘設備」太多,需要多個主節點(N個)可以災備到任意多個(I個)節點上。根據應用的級別,調整從節點的數量,可以為一個,也可以為多個。主節點的數量可以為一個或者多個,根據應用需要隨時調整搭配,但主節點為多個並不是同一個應用的「並行處理」,而是不同的應用。

集群系統狀態監測和故障響應

1 網卡故障

集群結構中每個節點都通過雙網卡與工作網絡相連,即一主(H)一備(B)兩條鏈路。在各節點正常工作的時候,工作網絡除用於傳遞工作數據外,也用於傳遞H-B信號。同時心跳網絡只傳遞H-B信號。即每隔一段時間各節點之間相互傳遞H-B信號,確認各節點都處於正常工作狀態。

因此,有了H-B後,集群可以很輕易地發現節點的網卡故障,因為一旦某塊網卡發生故障,發往該塊網卡的H-B就會丟失。此時節點上的集群管理軟件會產生一個網卡互換的事件,即將主備網卡互換,包括各種地址的互換和工作狀態的互換。並通知集群中各節點及工作網絡。網卡互換通常在幾秒內就可完成,並且這種轉換對應用來說是透明的,只發生延遲但連接並不中斷。

2 網絡故障

如果發往某一個節點雙網卡上的H-B包全都丟失,而心跳網絡上的H-B仍然存在,那麼集群軟件可以斷定集群節點仍然正常,是工作網絡發生故障。此時集群軟件則只能發出告警,並提供系統一個中斷入口,可以通過該入口確定系統執行其他網絡恢復的操作。

3 節點故障

如果不僅工作網絡上的H-B信號全部丟失,而且心跳網絡上的H-B也丟失,那麼集群軟件將斷定該節點發生故障。放在共享存儲上的資源將由其他節點接管(根據N節點配置和N+1節點配置的不同,接管的節點將不同),接管的操作將由集群軟件和節點的操作系統共同配合來完成。

當整個節點發生故障時,集群軟件將故障節點的工作地址轉移到接管節點上,對於網絡上的Client來講,服務地址沒有發生變化。

高可用性是重要數據庫應用程序的關鍵需求。IBM DB2 9.7 提供了很多特性來滿足這一需求。如果您對分佈式平台上的 DB2 還不是很了解,或者已經使用過一陣子,您可能會發現這組處理可用性的特性令人困惑。什麼時候使用哪個特性,當使用特性時,您希望完成什麼目標?

在開始之前,我們先來定義術語高可用性(HA)的意義。HA 是指要求在依賴性應用程序需要數據時能夠提供數據。其目的是消除或盡量避免停機。與 HA 相關的一個術語是災難恢復(Disaster Recovery,DR),DR 與 HA 的不同之處在於,它側重於保護數據,防止因災難性故障導致數據丟失。本文只關注 HA。

術語和客戶機/服務器數據庫架構

術語和客戶機/服務器數據庫架構

我們首先討論一些術語和概念,這對理解高可用性十分重要。

一個數據庫解決方案包括三個部分的軟件:

·用戶應用程序

·客戶機軟件

·數據庫引擎

除了軟件,要得到一個有效的解決方案,還必須擁有一些其他資源:

·服務器硬件

·網絡連接

·磁盤存儲

·操作系統

當設計一個 HA 解決方案時,必須考慮所有這些方面。僅僅使數據庫引擎高度可用未必就能創建出一個 HA 解決方案。HA 解決方案的設計並不完全是一個技術問題,它還必須考慮其他一些因素,例如解決方案的成本、技能需求以及管理需求。

數據庫應用程序是基於客戶機/服務器的。應用程序能否產生一致的結果,取決於數據庫軟件的完整性。雖然這一點是顯而易見的,但是它在選擇和設計解決方案時十分重要。

SQL 事務可分為兩種類型:讀和寫。讀事務是不需要插入、更新或刪除活動的選擇語句。而寫事務則要更改至少一個數據庫。讀事務需要數據的一致視圖 —— 即當同時提交兩個讀事務時,如果它們選擇相同的數據範圍,那麼應該產生一致的結果集。寫事務要求提交的數據庫更改被持久化,即使出現故障時也是如此。業務需求會影響到什麼 HA 解決方案是可用的或者是最適合的。通常,HA 解決方案的設計由兩個因素驅動,正常運行時間(uptime)需求和事務一致性。如果業務要求更高的可用性,並且讀一致性不是很重要,那麼選擇異步可能是更經濟的方法。另一方面,如果事務一致性是關鍵需求,那麼則需要選擇更加同步的解決方案。如果事務一致性和可用性都是必需的,那麼將進一步縮小可選擇的範圍。

本博主配置好的Centos6下 db2 9.7 HA環境虛擬機下載,鏈接:https://pan.baidu.com/s/147REuu6SrnF5iTUZTzDCmw
提取碼:67p7 下載後,用Vmware workstation打開 即可以正常使用

以下文章點擊率最高

Loading…

     

如果這文章對你有幫助,請掃左上角微信支付-支付寶,給於打賞,以助博客運營