Percona XtraDB Cluster 上用 keepalived 實作高可靠度架構

Percona 的人寫了一篇「Using keepalived for HA on top of Percona XtraDB Cluster」,是用 Keepalived 實作高可靠度架構。

目前常見的文章是透過 HAProxy 達成,但 HAProxy 本身就會成為 SPOF,所以一般人的想法就是在 HAProxy 上跑 Keepalived,保持可靠度。但這個問題我之前就抱怨過,既然要跑 Keepalived (我的例子裡是 Heartbeat),為什麼不在 Percona XtraDB Cluster 上跑就好,load balance 的任務則可以透過 DNS round robin 達成:

We would standardly use keepalived to HA HAproxy, and keepalived supports track_scripts that can monitor whatever we want, so why not just monitor PXC directly?

不過我還是偏愛 Heartbeat,因為 Heartbeat 的功能多了一些,不過架構還是很簡單,實際用起來也發現不容易出問題。

另外 Heartbeat 不論是在 Linux 還是 FreeBSD 上都跑得很好,我連內部機器用的 DNS resolver (跑 Unboound) 都上 Heartbeat。

另外也因為 Keepalived 目前不支援 FreeBSD (參考「About "ipvs" and "keepalived"」這篇文章),所以也沒打算花時間測試了... :o

用 pfSense 架設 Firewall (以及 NAT)

pfSense 是一套很不錯的 firewall 以及 NAT 服務,上面還可以跑一切服務 (像是 OpenVPN 或是 Squid),不過後來都是用商用的硬體方案來處理...

看到「Build your own pro-grade firewall」這篇突然想到要查 pfSense 是否可以 High Availability,如果做的夠好的話,其實可以用兩台機器來跑,成本相對低很多。

結果查到這篇官方文件「Configuring pfSense Hardware Redundancy (CARP)」,裡面有幾個關鍵字,像是 XMLRPC Sync 似乎暗示了設定也可以同步?


官方文件裡的配置圖。

該測試看看了,兩台 server 也才十萬,但兩台能跑到 500Mbps+ 的硬體防火牆的價錢就貴多了... (不過比較省電?)

MySQL HA 的選擇...

Percona 把常見的 MySQL High Availability 選擇整理後發表成 Webinar,投影片在這裡可以看到 (以及下載):「Choosing a MySQL High Availability Solution」。

沒有太多新的東西,主要還是再次描述 MySQL HA 這塊目前沒有萬靈丹,常見的這幾個方案各有自己的優缺點,會依照環境與需求而產生不同的選擇。裡面連 manual failover + 24x7 NOC 都出現了... XD

對於不清楚有哪些 HA 架構的人,可以透過這份投影片先抓出關鍵字。對於聽過一堆 HA 架構的人,想要複習各種方式的優缺點,也可以花時間看看。至於想要找萬靈丹的人就不用花時間了,目前沒這東西 :p

Galera Cluster + Heartbeat

我一向不太喜歡 Galera Cluster + HAProxy 的設計。有四個理由:

  • MySQL server 看不到 client 的 IP。
  • HAProxy 本身就是 SPoF。
  • HAProxy 會增加 latency,並且限制 bandwidth。
  • 通常需要額外的機器跑 HAProxy。

我把跑了超過半年的 Galera Cluster + Heartbeat 的經驗貼到 Codership 的 Group 上,裡面包括了設定與 script,希望能有些迴響:「HA solution - Galera Cluster with Heartbeat」。

Netflix 的 Chaos Monkey

Chaos MonkeyNetflix 丟出來的工具,這個工具的目的是希望建立超高可靠度的系統。方法則是沒事就亂關 AWS 上的 instance:「Chaos Monkey released into the wild」。

基本的想法是這樣:

  • 在 AWS 上的系統容錯率要超高。
  • 上班時間爛掉比凌晨三點被 call 起床好。
  • 所以平常就放火測試容錯率到底夠不夠高,方法就是隨機關 instance。

照 Netflix 的說法,他們不僅在開發環境測試,也在正式環境測試。利用 Chaos Monkey 看看 failure 的結果是否如預期。

Netflix 甚至建議可以排成每個上班日都隨機跑一跑:

The service has a configurable schedule that, by default, runs on non-holiday weekdays between 9am and 3pm.

只有在爆炸機率超高的系統上,設計師才會在意 failure 的問題...

Percona 把 Galera Cluster 標為 General Availability 了...

前幾天讓人吃驚的新聞,Galera Cluster 離第一次 Percona alpha 測試 (Percona Server 5.1 with Galera replication) 才九個月就進入 GA 了 (相當於九個月內就過完 Beta + RC 階段):「Announcement of Percona XtraDB Cluster 5.5.20 GA release」。

大家最大的問題還是「這能用嗎」... 不過既然進入 GA 狀態,加上是 Percona,好像可以期待?