轉載:【Oracle 集羣】RAC知識圖文詳細教程(一)--集羣概念介紹

文章導航

轉載自：http://www.cnblogs.com/baiboy/p/orc1.html\html

轉載目的：便於本人對看到的好文章進行分類整理，及根據實際須要進行進行適當的調整或補充，不用於適合商業用途。node

集羣術語須知

服務硬件：指提供計算服務的硬件，好比 PC 機、PC 服務器。mysql

服務實體：服務實體一般指服務軟體和服務硬體。sql

節點（node）：運行 Heartbeat 進程的一個獨立主機稱爲節點，節點是 HA 的核心組成部分，每一個節點上運行着操做系統和Heartbeat 軟件服務。數據庫

資源（resource）：資源是一個節點能夠控制的實體，當節點發生故障時，這些資源可以被其餘節點接管。如：磁盤分區、文件系統、IP 地址、應用程序服務、共享存儲緩存

事件（event）：事件也就是集羣中可能發生的事情，例如節點系統故障、網絡連通故障、網卡故障和應用程序故障等。這些事件都會致使節點的資源發生轉移，HA 的測試也是基於這些事件進行的。安全

什麼是集羣

集羣（cluster）就是一組計算機，它們做爲一個總體向用戶提供一組網絡資源，這些單個的計算機系統就是集羣的節點（node）。集羣提供瞭如下關鍵的特性。服務器

(一) 可擴展性。集羣的性能不限於單一的服務實體，新的服務實體能夠動態的加入到集羣，從而加強集羣的性能。網絡

(二) 高可用性。集羣經過服務實體冗餘使客戶端免於輕易遭遇到「out of service」警告。當一臺節點服務器發生故障的時候，這臺服務器上所運行的應用程序將在另外一節點服務器上被自動接管。消除單點故障對於加強數據可用性、可達性和可靠性是很是重要的。架構

(三) 負載均衡。負載均衡能把任務比較均勻的分佈到集羣環境下的計算和網絡資源，以便提升數據吞吐量。

(四) 錯誤恢復。若是集羣中的某一臺服務器因爲故障或者維護須要而沒法使用，資源和應用程序將轉移到可用的集羣節點上。這種因爲某個節點中的資源不能工做，另外一個可用節點中的資源可以透明的接管並繼續完成任務的過程叫作錯誤恢復。

分佈式與集羣的聯繫與區別以下：

(一) 分佈式是指將不一樣的業務分佈在不一樣的地方。

(二) 而集羣指的是將幾臺服務器集中在一塊兒，實現同一業務。

(三) 分佈式的每個節點，均可以作集羣，而集羣並不必定就是分佈式的。而分佈式，從狹義上理解，也與集羣差很少，可是它的組織比較鬆散，不像集羣，有必定組織性，一臺服務器宕了，其餘的服務器能夠頂上來。分佈式的每個節點，都完成不一樣的業務，一個節點宕了，這個業務就不可訪問了。

集羣主要分紅三大類：

HA：高可用集羣（High Availability Cluster）。

LBC：負載均衡集羣/負載均衡系統（Load Balance Cluster）

HPC：科學計算集羣（High Performance Computing Cluster）/高性能計算（High Performance Computing）集羣。

爲何搭建數據庫集羣

隨着經濟的高速發展，企業規模的迅猛擴張，企業用戶的數量、數據量的爆炸式增加，對數據庫提出了嚴峻的考驗。對於全部的數據庫而言，除了記錄正確的處理結果以外，還面臨着如下幾方面的挑戰。

l 如何提升處理速度，實現數據庫的均衡負載。
l 如何保證數據庫的可用性、數據安全性、以及如何實現數據集羣可擴性。
l 怎麼綜合解決這些問題成爲衆多企業關注的焦點。

在數據庫上，組建集羣也是一樣的道理，主要有如下幾個緣由：

(一) 伴隨着企業的成長，業務量提升，數據庫的訪問量和數據量快速增加，其處理能力和計算速度也相應增大，使得單一的設備根本沒法承擔。

(二) 在以上狀況下，若扔掉現有設備，作大量的硬件升級，勢必形成現有資源的浪費，並且下一次業務量提高時，又將面臨再一次硬件升級的高額投入。因而，人們但願經過幾箇中小型服務器組建集羣，實現數據庫的負載均衡及持續擴展；在須要更高數據庫處理速度時，只要簡單的增長數據庫服務器就能夠獲得擴展。

(三) 數據庫做爲信息系統的核心，起着很是重要的做用，單一設備根本沒法保證系統的下持續運行，若發生系統故障，將嚴重影響系統的正常運行，甚至帶來巨大的經濟損失。因而，人們但願經過組建數據庫集羣，實現數據庫的高可用，當某節點發生故障時，系統會自動檢測並轉移故障節點的應用，保證數據庫的持續工做。

(四) 企業的數據庫保存着企業的重要信息，一些核心數據甚相當繫着企業的命脈，單一設備根本沒法保證數據庫的安全性，一旦發生丟失，很難再找回來。因而，人們但願經過組建數據庫集羣，實現數據集的冗餘，經過備份數據來保證安全性。

數據庫集羣的分類

數據庫集羣技術是將多臺服務器聯合起來組成集羣來實現綜合性能優於單個大型服務器的技術，這種技術不但能知足應用的須要，並且大幅度的節約了投資成本。數據庫集羣技術分屬兩類體系：基於數據庫引擎的集羣技術和基於數據庫網關（中間件）的集羣技術。在數據庫集羣產品方面，其中主要包括基於數據庫引擎的集羣技術的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基於數據庫網關（中間件）的集羣技術的 ICX-UDS 等產品。

通常來說，數據庫集羣軟件側重的方向和試圖解決的問題劃分爲三大類：

l 負載均衡集羣（Load Balance Cluster，LBC）側重於數據庫的橫向擴展，提高數據庫的性能。
l 高可用性集羣（High Availability Cluster，HAC）側重保證數據庫應用持續不斷。大部分的數據庫集羣側重與此。
l 高安全性集羣（High Security Cluster，HSC）側重於容災。

只有 Oracle RAC 能實現以上三方面

可擴展的分佈式數據庫架構

(一) Oracle RAC：

其架構的最大特色是共享存儲架構（Shared-storage），整個 RAC 集羣是創建在一個共享的存儲設備之上的，節點之間採用高速網絡互聯。OracleRAC 提供了很是好的高可用特性，好比負載均衡和應用透明切塊（TAF），其最大的優點在於對應用徹底透明，應用無需修改即可切換到RAC 集羣。可是RAC 的可擴展能力有限，首先由於整個集羣都依賴於底層的共享存儲，因此共享存儲的 I/O 能力和可用性決定了整個集羣的能夠提供的能力，對於 I/O 密集型的應用，這樣的機制決定後續擴容只能是 Scale up（向上擴展）類型，對於硬件成本、開發人員的要求、維護成本都相對比較高。Oracle顯然也意識到了這個問題，在 Oracle 的 MAA（Maximum Availability Architecture）架構中，採用 ASM 來整合多個存儲設備的能力，使得 RAC 底層的共享存儲設備具有線性擴展的能力，整個集羣再也不依賴於大型存儲的處理能力和可用性。

RAC 的另一個問題是，隨着節點數的不斷增長，節點間通訊的成本也會隨之增長，當到某個限度時，增長節點可能不會再帶來性能上的提升，甚至可能形成性能降低。這個問題的主要緣由是 Oracle RAC 對應用透明，應用能夠鏈接集羣中的任意節點進行處理，當不一樣節點上的應用爭用資源時，RAC 節點間的通訊開銷會嚴重影響集羣的處理能力。因此對於使用 ORACLE RAC 有如下兩個建議：

l 節點間通訊使用高速互聯網絡；
l 儘量將不一樣的應用分佈在不一樣的節點上。

基於這個緣由，Oracle RAC 一般在 DSS 環境（決策支持系統Decision Support System ，簡稱DSS)中能夠作到很好的擴展性，由於 DSS 環境很容易將不一樣的任務分佈在不一樣計算節點上，而對於 OLTP 應用（On-Line Transaction Processing聯機事務處理系統），Oracle RAC 更多狀況下用來提升可用性，而不是爲了提升擴展性。

(二) MySQL Cluster

MySQL cluster 和 Oracle RAC 徹底不一樣，它採用無共享架構Shared nothing（shared nothing architecture）。整個集羣由管理節點(ndb_mgmd)，處理節點(mysqld)和存儲節點(ndbd)組成，不存在一個共享的存儲設備。MySQL cluster 主要利用了 NDB 存儲引擎來實現，NDB 存儲引擎是一個內存式存儲引擎，要求數據必須所有加載到內存之中。數據被自動分佈在集羣中的不一樣存儲節點上，每一個存儲節點只保存完整數據的一個分片(fragment)。同時，用戶能夠設置同一份數據保存在多個不一樣的存儲節點上，以保證單點故障不會造成數據丟失。MySQL cluster 主要由 3 各部分組成：

l SQL 服務器節點
l NDB 數據存儲節點
l 監控和管理節點

這樣的分層也是與 MySQL 自己把 SQL 處理和存儲分開的架構相關係的。MySQL cluster 的優勢在於其是一個分佈式的數據庫集羣，處理節點和存儲節點均可以線性增長，整個集羣沒有單點故障，可用性和擴展性均可以作到很高，更適合 OLTP 應用。可是它的問題在於：

l NDB（「NDB」是一種「內存中」的存儲引擎，它具備可用性高和數據一致性好的特色。）存儲引擎必需要求數據所有加載到內存之中，限制比較大，可是目前 NDB 新版本對此作了改進，容許只在內存中加載索引數據，數據能夠保存在磁盤上。
l 目前的 MySQL cluster 的性能還不理想，由於數據是按照主鍵 hash 分佈到不一樣的存儲節點上，若是應用不是經過主鍵去獲取數據的話，必須在全部的存儲節點上掃描，返回結果處處理節點上去處理。並且，寫操做須要同時寫多份數據到不一樣的存儲節點上，對節點間的網絡要求很高。

雖然 MySQL cluster 目前性能還不理想，可是 share nothing 的架構必定是將來的趨勢，Oracle 接手 MySQL以後，也在大力發展 MySQL cluster，我對 MySQL cluster 的前景抱有很大的期待。

(三) 分佈式數據庫架構

MySQL 5 以後纔有了數據表分區功能（Sharding）， Sharding 不是一個某個特定數據庫軟件附屬的功能，而是在具體技術細節之上的抽象處理，是水平擴展(Scale Out，亦或橫向擴展、向外擴展)的解決方案，其主要目的是爲突破單節點數據庫服務器的 I/O 能力限制，解決數據庫擴展性問題。好比 Oracle 的 RAC 是採用共享存儲機制，對於 I/O 密集型的應用，瓶頸很容易落在存儲上，這樣的機制決定後續擴容只能是 Scale Up（向上擴展）類型，對於硬件成本、開發人員的要求、維護成本都相對比較高。Sharding 基本上是針對開源數據庫的擴展性解決方案，不多有據說商業數據庫進行 Sharding 的。目前業界的趨勢基本上是擁抱 Scale Out，逐漸從 Scale Up 中解放出來。

Sharding 架構的優點在於，集羣擴展能力很強，幾乎能夠作到線性擴展，並且整個集羣的可用性也很高，部分節點故障，不會影響其餘節點提供服務。Sharding 原理簡單，容易實現，是一種很是好的解決數據庫擴展性的方案。Sharding 並非數據庫擴展方案的銀彈，也有其不適合的場景，好比處理事務型的應用它可能會形成應用架構複雜或者限制系統的功能，這也是它的缺陷所在。讀寫分離是架構分佈式系統的一個重要思想。很多系統總體處理能力並不能同業務的增加保持同步，所以勢必會帶來瓶頸，單純的升級硬件並不能一勞永逸。針對業務類型特色，須要從架構模式進行一系列的調整，好比業務模塊的分割，數據庫的拆分等等。集中式和分佈式是兩個對立的模式，不一樣行業的應用特色也決定了架構的思路。如互聯網行業中一些門戶站點，出於技術和成本等方面考慮，更多的採用開源的數據庫產品(如 MYSQL)，因爲大部分是典型的讀多寫少的請求，所以爲 MYSQL 及其複製技術大行其道提供了條件。而相對一些傳統密集交易型的行業，好比電信業、金融業等，考慮到單點處理能力和可靠性、穩定性等問題，可能更多的採用商用數據庫，好比 DB2、Oracle 等。就數據庫層面來說，大部分傳統行業核心庫採用集中式的架構思路，採用高配的小型機作主機載體，由於數據庫自己和主機強大的處理能力，數據庫端通常能支撐業務的運轉，所以，Oracle 讀寫分離式的架構相對MYSQL 來說，相對會少。讀寫分離架構利用了數據庫的複製技術，將讀和寫分佈在不一樣的處理節點上，從而達到提升可用性和擴展性的目的。最一般的作法是利用 MySQL Replication 技術，Master DB 承擔寫操做，將數據變化複製到多臺 Slave DB上，並承擔讀的操做。這種架構適合 read-intensive 類型的應用，經過增長 Slave DB 的數量，讀的性能能夠線性增加。爲了不 Master DB 的單點故障，集羣通常都會採用兩臺 Master DB 作雙機熱備，因此整個集羣的讀和寫的可用性都很是高。除了 MySQL，Oracle 從 11g 開始提供 Active Standby 的功能，也具有了實現讀寫分離架構的基礎。讀寫分離架構的缺陷在於，無論是 Master 仍是 Slave，每一個節點都必須保存完整的數據，如果在數據量很大的狀況下，集羣的擴展能力仍是受限於單個節點的存儲能力，並且對於 Write-intensive 類型的應用，讀寫分離架構並不適合。

採用 Oracle 讀寫分離的思路，Writer DB 和 Reader DB 採用日誌複製軟件實現實時同步； Writer DB 負責交易相關的實時查詢和事務處理，Reader DB 負責只讀接入，處理一些非實時的交易明細,報表類的彙總查詢等。同時，爲了知足高可用性和擴展性等要求，對讀寫端適當作外延，好比 Writer DB 採用 HA 或者 RAC 的架構模式，目前，除了數據庫廠商的集羣產品之外，解決數據庫擴展能力的方法主要有兩個：數據分片和讀寫分離。數據分片(Sharding)的原理就是將數據作水平切分，相似於 hash 分區的原理，經過應用架構解決訪問路由和Reader DB 能夠採用多套，經過負載均衡或者業務分離的方式，有效分擔讀庫的壓力。

對於 Shared-nothing 的數據庫架構模式，核心的一個問題就是讀寫庫的實時同步；另外，雖然 Reader DB只負責業務查詢，但並不表明數據庫在功能上是隻讀的。只讀是從應用角度出發，爲了保證數據一致和衝突考慮，由於查詢業務模塊可能須要涉及一些中間處理，若是須要在數據庫裏面處理(取決與應用需求和設計)，因此Reader DB 在功能上仍然須要可寫。下面談一下數據同步的技術選型問題：

能實現數據實時同步的技術不少，基於 OS 層(例如 VERITAS VVR)，基於存儲複製(中高端存儲大多都支持)，基於應用分發或者基於數據庫層的技術。由於數據同步可能並非單一的 DB 整庫同步，會涉及到業務數據選擇以及多源整合等問題，所以 OS 複製和存儲複製多數狀況並不適合作讀寫分離的技術首選。基於日誌的 Oracle 複製技術，Oracle 自身組件能夠實現，同時也有成熟的商業軟件。選商業的獨立產品仍是 Oracle 自身的組件功能，這取決於多方面的因素。好比團隊的相應技術運維能力、項目投入成本、業務系統的負載程度等。

採用 Oracle 自身組件功能，無外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，對比來講，Stream 最靈活，但最不穩定，11g Physical Standby 支持恢復與只讀並行，但因爲並非日誌的邏輯應用機制，在讀寫分離的場景中最爲侷限。若是技術團隊對相關技術掌握足夠充分，而選型方案的處理能力又能支撐數據同步的要求，採用 Oracle 自身的組件徹底可行。選擇商業化的產品，更多出於穩定性、處理能力等考慮。市面上成熟的 Oracle 複製軟件也無外乎幾種，不管是老牌的 Shareplex，仍是本土 DSG 公司的 RealSync 和九橋公司的 DDS，或是 Oracle 新貴 Goldengate，都是可供選擇的目標。隨着 GoldenGate 被 Oracle 收購和推廣，我的認爲 GoldenGate 在容災、數據分發和同步方面將大行其道。固然，架構好一個可靠的分佈式讀寫分離的系統，還須要應用上作大量設計，不在本文討論範圍內。

(四) CAP 和 BASE 理論

分佈式領域 CAP 理論：

l Consistency(一致性), 數據一致更新，全部數據變更都是同步的
l Availability(可用性), 好的響應性能
l Partition tolerance(分區容錯性) 可靠性

定理：任何分佈式系統只可同時知足二點，無法三者兼顧。

忠告：架構師不要將精力浪費在如何設計能知足三者的完美分佈式系統，而是應該進行取捨。

關係數據庫的 ACID 模型擁有高一致性 + 可用性很難進行分區：

l Atomicity 原子性：一個事務中全部操做都必須所有完成，要麼所有不完成。
l Consistency 一致性. 在事務開始或結束時，數據庫應該在一致狀態。
l Isolation 隔離層. 事務將假定只有它本身在操做數據庫，彼此不知曉。
l Durability. 一旦事務完成，就不能返回。

(五) 跨數據庫事務

2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，也就是說傳統關係型數據庫要想實現一個分佈式數據庫集羣很是困難，關係型數據庫的擴展能力十分有限。而近年來不斷髮展壯大的 NoSQL（非關係型的數據庫）運動，就是經過犧牲強一致性，採用 BASE 模型，用最終一致性的思想來設計分佈式系統，從而使得系統能夠達到很高的可用性和擴展性。那麼，有沒有可能實現一套分佈式數據庫集羣，既保證可用性和一致性，又能夠提供很好的擴展能力呢？

BASE 思想的主要實現有按功能劃分數據庫 sharding 碎片BASE 思想主要強調基本的可用性，若是你須要 High 可用性，也就是純粹的高性能，那麼就要以一致性或容錯性爲犧牲，BASE 思想的方案在性能上仍是有潛力可挖的。

l 共同點：都是關係數據庫 SQL 之外的可選方案，邏輯隨着數據分佈，任何模型均可以本身持久化，將數據處理和數據存儲分離，將讀和寫分離，存儲能夠是異步或同步，取決於對一致性的要求程度。
l 不一樣點：NOSQL 之類的 Key-Value 存儲產品是和關係數據庫頭碰頭的產品 BOX，能夠適合非 Java 如 PHP RUBY等領域，是一種能夠拿來就用的產品，而領域模型 + 分佈式緩存 + 存儲是一種複雜的架構解決方案，不是產品，但這種方式更靈活，更應該是架構師必須掌握的。

目前，已經有不少分佈式數據庫的產品，可是絕大部分是面向 DSS 類型的應用，由於相比較 OLTP 應用，DSS 應用更容易作到分佈式擴展，好比基於 PostgreSQL 發展的 Greenplum，就很好的解決了可用性和擴展性的問題，而且提供了很強大的並行計算能力。對於 OLTP 應用，業務特色決定其要求：高可用性，一致性，響應時間短，支持事務和 join 等等。數據庫和 NoSQL當愈來愈多的 NoSQL 產品涌現出來，它們具有不少關係型數據庫所不具有的特性，在可用性和擴展性方面均可以作到很好。

第一，NoSQL 的應用場景很是侷限，某個類型的 NoSQL 僅僅針對特定類型的應用場景而設計。而關係型數據庫則要通用的多，使用 NoSQL 必須搞清楚本身的應用場景是否適合。

第二，利用關係型數據庫配合應用架構，好比 Sharding 和讀寫分離技術，一樣能夠搭建出具有高可用和擴展性的分佈式數據庫集羣。

第三，關係型數據庫廠商依然很強大，全世界有大量的用戶，需求必然會推進新的產品問世。

第四，硬件的發展突飛猛進，好比閃存的技術的不斷成熟，將來閃存能夠做爲磁盤與內存之間的 cache，或者完全替代磁盤。而內存價格愈來愈低，容量愈來愈大，In-memory cache 或 database 的應用愈來愈普遍，能夠給應用帶來數量級的性能提高。數據庫面臨的 IO 問題將被極大改善。

轉載自：http://www.cnblogs.com/baiboy/p/orc1.html\

轉載目的：便於本人對看到的好文章進行分類整理，及根據實際須要進行進行適當的調整或補充，不用於適合商業用途。