Tag: availability

vCenter 的 HA 機制

在「vCenter is Still a Single Point of Failure」這篇文章裡面討論了 VMware vCenter 的 HA (High Availability) 問題。可以包括 comment 一起看，看到文章裡火氣還蠻大的...

文章後面有提到 VMware vCenter 並沒有辦法提供很高等級的 HA 機制，雖然官方提出來的 downtime 是五分鐘內，不過作者顯然對這點很不同意：

I can guarantee you that will take a hell of a lot longer than 5 minutes.

而下面 comment 有人提到至少是 20mins：

After reboot the first 20min CPU is high and vCenter Services is unable to start. 1000 VMs, 60 hosts. VM has 4 vCPU en 21GB RAM.

不過這設定看起來像是 60 台 host，每一台 384GB RAM，裡面每個 VM 都有 21GB RAM？這種環境真不錯... 不過如果量這麼大，我大概會自己弄 KVM 起來建環境？

Anyway，有用過 vCenter 的人看完這篇文章大概都有種「...」不知道要怎麼說的感覺 XD

AWS 的機房架構

這幾天 Amazon 因為 re:Invent 的關係，放出了不少資料出來，其中看到有 AWS 機房的架構：「Amazon details how it does networking in its data centers」。

有些資料還蠻有趣的，像是這張：

每個 AZ (Availability Zone) 可能會有很多 DC (Data Center)，而這些 DC 必須在 0.25ms 內。

AZ 之間是 complete graph 連接，另外對多個不同的 Transit center 出去，以確保其中一個 Transit center 掛掉時仍然有備援。

AZ 之間的 latency 會在 2ms 之間 (如果算來回的話是 300 公里)，通常會在 1ms (算來回的話是 150 公里)。

使用者的 AWS Direct Connect 則是接到 Transit center 上。

每個 DC 的機器數量在 50k 到 80k 台左右。

雖然應該用不到，但看這些資料還是蠻有趣的 :p

多資料中心的備援機制

100% 的 uptime 有點誇張啦，不過看到這篇文章有些啟發：「Multi-Home the Data Center for 100% uptime」。

這張圖裡面，如果 DC1 的 DB master 掛掉，那麼 DC2 也只能進入唯讀狀態？甚至有些應用連唯讀狀態都不能進...

不過想到 Percona XtraDB Cluster 放三個機房的方法，不過如果只放三台的話會有其他的風險就是了，本粗一點變成六台 (每個機房都兩台) 也是個方法 :o

Facebook 的 mcrouter

這也不知道積了多久，九月 Facebook 的文章，最近被同事提起來才又仔細看：「Introducing mcrouter: A memcached protocol router for scaling memcached deployments」。

memcached 應該當作普通的 cache layer 來用，拿來放掉了也沒關係的資料。如果掉了會很痛的資料應該丟到 Redis 或是 MySQL 這類 persistent storage。

但有些資料介於兩者之間，掉了會讓使用者用起來不太爽，但也不會死人... 於是總是想要在這上面做些改善。

Facebook 開發的 mcrouter 就可以拿來解這類問題。其中一個 scenario 是「寫的不多，但讀德很多」，寫的時候寫到所有機器上，但讀取時只挑一台：

而這個架構其實可以配合用在 memcached 的 HA 機制上。當有機器爛掉重開機變成空的 cache server 回來時可以暖機：

不過程式看起來並不好編，要先搞定 Facebook 的兩個 C++ 的套件後才能編...

Mobile01 的 Ryan 換 InnoDB 的筆記與心得

沒記錯的話，Mobile01 應該是去年暑假左右從 MyISAM 換成 InnoDB 的？一切的起頭應該是蔣大「現在SSD硬碟可以拿來跑資料庫嗎?」這篇。

另外同場加映，使用 Percona 的工具讓管理上更方便：

MyISAM 是 MySQL 5.0 與 5.1 預設的 storage engine (到 5.5+ 預設的 storage engine 改成 InnoDB)，讀取的效能相當好，但總是有些問題。

當時剛好有機會跟蔣大與 Ryan 聊到當時 Mobile01 遇到的問題，問了一些細節後感覺上是 MyISAM 的問題，就提了 MyISAM 與 InnoDB 的優缺點比較，以及幾個 InnoDB 的 High Availability 的解決方案 (晚上就算設備出問題也不用擔心要爬起來救機器)：

  • MyISAM 的讀寫互斥、寫入也是互斥。當有資料在讀取時無法更改資料庫內容，而有寫入時其他人不能讀取。另外同時間只能有一個人寫入。(有少數操作是例外，像是 bulk insert，這邊跳過)
  • MyISAM 不是 crash-safe storage engine。機器總是有機會爛掉，這時候除了重開機的時間外，還需要有修 table 的時間，對於網站的 uptime 比較痛。

這兩點是當時 Mobile01 遇到最痛的問題：用 iostat 看起來 I/O 明明就沒有滿，但就是會卡 SQL query，而當機後修資料庫的時間又很長。

一個是已經在業界驗證很久的解決方案 XFS + DRBD + Heartbeat，當機器發生問題時的 downtime 從 30secs 到五分鐘 (依照資料性質與大小而有差異，在切換上線後有資料庫的熱機問題)。

另外一個是當時還很新的 Percona XtraDB Cluster，可以避免資料庫的熱機問題，不過技術很新。

後來 Mobile01 用 RAID 10 的硬體，軟體的部份用 Debian + XFS + DRBD + Heartbeat 跑 Percona Server 的 XtraDB (InnoDB 的加強版)，先用 VM 做了 PoC (直接砍掉 mysqld，或是直接關掉 VM 之類的，測試整個機制夠不夠自動化)，然後就上線了 :p

記得上線那幾天跟 Ryan 聊，好像效果還不錯吧...

Percona Server 的 TokuDB 居然 GA 了...

剛剛看到 Percona 發佈的消息：「Percona Server 5.6.19-67.0 with TokuDB (GA) now available」。

好快...

可以來測試 DRBD + Heartbeat 配上 TokuDB 的穩定性如何了，另外也要與 InnoDB 比較優缺點...

然後要查一個 transaction 內是否可以 InnoDB 與 TokuDB 混用。

Percona XtraDB Cluster 5.6 GA

放長假的時候總是可以感覺到世界上其他地方是沒放假的...

Percona 宣佈 Percona XtraDB Cluster 5.6 進入 GA (General Availability)：「Percona XtraDB Cluster 5.6 GA release now available」。

Percona XtraDB Cluster 5.6 是基於 MySQL 5.6 以及 Galera Cluster 3 的版本。

其實最主要的效能改善是 Oracle 在 MySQL 5.6 上面下的功夫，比起 5.5 好不少。

Percona 官方有提到，現有的 PXC 5.5 可以在不停機的情況下升級到 5.6 (兩台輪流升級)，這是件好事 (表示有問題回報時會被處理)，但需要實際測試過才知道要怎麼做。所以就先在虛擬機裡面測試看看，沒問題就來規劃...

不過 PXC 上應該還是不能用 memcache interface 吧？之前有提到有問題，而且也沒看到有解決，所以應該還是不能用？

Percona 的 MySQL High Availability 機制比較文

Percona 發了一篇「High-availability options for MySQL, October 2013 update」，比較目前 MySQL 上常見的 High Availability 機制。

包括了五個系統：

  • Percona XtraDB Cluster (PXC)
  • Percona replication manager (PRM)
  • MySQL master HA (MHA)
  • NDB Cluster
  • Shared storage/DRBD

這些都是把 High Availability 做在 MySQL 上，讓前端的程式不需要操心的方式。都是有個固定的 IP address 保證可以讀寫。

這五個方案都不完美，看環境需求而選擇使用。

我一般給的建議還是 Heartbeat + DRBD + InnoDB，這個方法是極為成熟的方法，會遇到的問題網路上都已經討論過了。如果找 Percona 的人支援也是完全沒問題。

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+ 的硬體防火牆的價錢就貴多了... (不過比較省電？)