Percona XtraDB Cluster 5.7 (Galera Cluster)

Percona 放出 PXC 5.7 了:「Percona XtraDB Cluster 5.7.14-26.17 GA is now available」。

主要的效能提昇還是基於 MySQL 5.7 上面,不過要注意的是有些預設值有改變 (尤其是 5.6 -> 5.7 最有名的 sync_binlog 設定),如果當初沒有特別指定的話,效能會掉不少,這點 Percona 整理了不少資料出來,可以翻一下 Percona 網站得到結果。

不過整體上改善了不少,在 5.6 需要一些手動設定的值以確保在 heavy loading 時不會拖垮系統效能 (也就是常說的「卡 query」),在 5.7 變得自動化了。像是 innodb_thread_concurrency 之前的建議都是設在 CPU logical threads 數量以確保當 threads 數量破千時還是有慢慢消化的能力 (讓 DBA 可以不用介入),在 5.7 不需要設定就跑得不錯了。

Akamai 與 Microsoft Azure CDN 合作的方案進入 GA (General Availability)

先是在 Akamai 的網站上看到說明:「Microsoft Azure CDN from Akamai Enters General Availability」,另外裡面有提到 Microsoft 的公告:「Microsoft announces general availability of Azure CDN from Akamai」。

所以 Microsoft Azure 現在提供三個不同的 CDN 方案:

  • Azure CDN Standard from Verizon
  • Azure CDN Standard from Akamai
  • Azure CDN Premium from Verizon

其中 Standard 方案的價錢都相同,而 Verizon 的 Premium 方案大約是兩倍價錢,沒猜錯的話應該是 Verizon ACCELERATE?以前 EdgeCast 的 ADN 產品線?

AWS Lambda 可以在 VPC 裡面執行了

AWS Lambda 可以存取 VPC 內的資源了:「New – Access Resources in a VPC from Your Lambda Functions」。

這包括了 RDSElastiCache 這類放資料或是狀態的資源。以往有些要自己處理 High Availability 但又不怎麼大的功能,可以改寫成 AWS Lambda 往上丟了...

AWS 上 MySQL + MHA、Galera Cluster、Amazon RDS for Aurora 的比較

Twitter 上看到的文章,對三套有 High Avaiilability 能力的 MySQL 系統比較:「AWS Aurora Benchmarking - Blast or Splash?」。

測試的項目包括了 MySQL + MHAGalera Cluster 以及 Amazon RDS for Aurora 三種,包括了 failover 的各種速度以及資料庫效能的比較。

測試的結果可以看到 Galera Cluster 有不少優勢,不過我必須說 Galera Cluster 並不好搞,初期要使用的話乾脆用 Aurora 就好,failover 的確是比較慢,而且效能也沒有 Galera Cluster 好,但管理上輕鬆很多啊...

DigitalOcean 提供 Floating IP 功能

DigitalOcean 推出的新功能,可以註冊 IP 並且動態掛到某個 droplet 上:「Floating IPs: Start Architecting Your Applications for High Availability」。

如果沒有掛到 droplet 上會收取 USD$0.006/hour 的費用,以一個月 720 小時來計算,大約是 USD$4.32/month。另外也限制在同一個 data center 內才能換來換去。

類似的功能在 Linode 很久前就有了 (2007 年底),雖然不是完全一樣:「Support for High Availability / IP Failover」,但 Amazon EC2 的 Elastic IP 功能幾乎就相同了,在 2008 年初開放:「New EC2 Features: Static IP Addresses, Availability Zones, and User Selectable Kernels」,所以只能算是補產品線,把大家都有的功能實作出來...

以往只能用 DNS 做 High Availability 的,現在可以用這種方法做,使得 downtime 可以更低。另外這樣做也可以架設 proxy server,使得對外的 IP 不變,讓 firewall 設定變得單純。

跨區決定最低價的 Spot Instance

看到 Amazon EC2 可以跨區取最低價的 Spot Instance 了:「Spot fleet launches Spot instances in the lowest priced Availability Zone」。

先前必須指定 AZ (Availability Zone),現在則可以讓系統更動態選擇了...

以後有沒有機會讓系統透過 AWS Lambda 來決定定價策略?

AWS 北京開了第二個 AZ

官方的公告在這邊:「更新:AWS中国北京区域推出第二个EC2可用区」。

我以為每個地區都是直接開兩個以上的 AZ?(就之前其他地區看到的經驗) 沒想到北京現在才開第二個 AZ...

目前還是在 Limited Preview,要申請的人要自己找管道去要...

EC2 instance Auto Recovery 功能全區開放

Twitter 上看到公告:「Announcement: EC2 instance Auto Recovery now available in 8 more AWS Regions」。

也就是 C3、C4、M3、R3、T2 這五種 instance 都可以開 Auto Recovery,而且必須在 VPC 內的 EBS-only instance。

在某種程度上的 High Availability 機制可以直接用這個功能解決掉。

Oracle 對 MySQL HA 方案的介紹

Oracle 的 Andrew Morgan 前幾天辦了場 Webinar,投影片以及一些說明有放出來讓大家事後可以參考:「Choosing the right MySQL High Availability Solution – webinar replay」。

其中第七頁的開頭「Don’t assume 99.999% HA needed for all apps」這句帶出了一個重點:99.999% 的每一個九都是成本,而且不是可以簡單帶過去的成本。

第八頁與第九頁給出了不同 HA 層級中的每個方案 (要注意到這是以 Oracle 的觀點來看),至於最後面將近五十頁的產品介紹看看就好... XD

建立 Amazon VPC 的 High Availability NAT 架構

Amazon VPC 的架構裡最讓人碎碎唸的一個架構:NAT instance。

Amazon VPC 分成 Public Network 與 Private Network。

前者的 Public Network,裡面的機器除了會有 Private IP 外,需要申請 Public IP (可以是隨機分配,也可以是 Elastic IP) 透過 Intenet Gateway (沒有 NAT 功能) 連外,這邊問題比較小,因為 Routing Table 設一下就好了,High Availability 以及 Scalablility 的問題 AWS 會自己解決掉。

後者 Private Network 因為需要自己架設 NAT instance,所以要自己處理 High Availability 以及 Scalability 問題,由於把機器丟在後面,前面用 ELB 是蠻常見的架構,AWS 一直沒推出 NAT service 讓人感覺很疑惑...

目前一般在處理 Private Network 的 HA NAT 架構是參考「High Availability for Amazon VPC NAT Instances: An Example」這篇文章,但這篇文章的作法有點複雜。

我可以接受有一些 downtime 時間以及一些小狀況,相對的,我想要換取極低的管理成本。

研究了一陣子,最後決定的作法是受到「An Alternative Approach to “HA” NAT on AWS」這篇的啟發,這篇也只講了很簡單的概念,實際上還是要自己研究。

目前是做在 us-west-2 (Oregon) 的 1b 與 1c 兩個 AZ 上。下面討論時就不說明這點了。

規劃的想法是 1b 與 1c 兩個 AZ 各建立一個 auto scaling group,透過 auto scaling 各跑一台 NAT instance 處理自己 AZ 的 NAT traffic (所以不是手動跑)。然後我不想要自己建 image 寫太多 hard code 進去,最好是現成的用一用就好 XD

所以有幾個重點:

  • NAT instance 拿現成的 amzn-ami-vpc-nat 使用,寫這篇文章時是用 2014.09 版。
  • 由於官方的 NAT instance 支援 userdata 在開機時執行指令,所以完全透過 userdata 指定需要的做動就好。
  • 由於 Amazon 官方給的 instance 有 aws 這隻工具 (aws-cli),而這隻工具在有掛上 IAM Role 時會去 http://169.254.169.254/ 上取得對應的 IAM Role 權限,所以都不需要寫太多 hard code 的東西進去。

機器開起來以後希望做幾件事情:

  • 把自己的 Source/Destination IP check 關閉。
  • 把傳進來的 Route Table 的 0.0.0.0/8 設成自己。這邊需要傳進來是由於 NAT instance 是跑在 Public Network 裡,我不會知道要改哪個 Route Table。

所以就有兩個重點,一個是 userdata,其中粗體是要修改的 route table id:

#!/bin/bash
ROUTE_TABLE_ID=rtb-1a2b3c4d
INSTANCE_ID=$(curl http://169.254.169.254/latest/meta-data/instance-id)
aws ec2 modify-instance-attribute \
    --region us-west-2 \
    --instance-id "${INSTANCE_ID}" \
    --no-source-dest-check
aws ec2 replace-route \
    --region us-west-2 \
    --route-table-id "${ROUTE_TABLE_ID}" \
    --destination-cidr-block 0.0.0.0/0 \
    --instance-id "${INSTANCE_ID}" || \
aws ec2 create-route \
    --region us-west-2 \
    --route-table-id "${ROUTE_TABLE_ID}" \
    --destination-cidr-block 0.0.0.0/0 \
    --instance-id "${INSTANCE_ID}"

最前面事先抓 instance_id,然後修改 Source/Destination 檢查,最後面的指令是先試著 ReplaceRoute,如果失敗就 CreateRoute (注意到 shell 的 || 操作)。

另外的重點是 IAM Role,這台機器對應的 IAM Role 權限要開三個:

{
  "Statement": [
    {
      "Action": [
        "ec2:CreateRoute",
        "ec2:ReplaceRoute",
        "ec2:ModifyInstanceAttribute"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

拿 t2.medium 測試,burst 可以到 200Mbps 左右,應該還算夠用?反正不夠用就自己挑其他機器開吧 XD

最後討論一下 Availability 的情況。這樣的架構可能會有七八分鐘的 downtime,也就是當 instance 掛了,被 auto scaling 重新拉一台新的起來。這邊不做 cross-zone NAT 是因為這樣比較簡單,這邊的 downtime 我還可以接受。

至於某個 zone 掛掉,應該 cross-zone NAT 趕快導到另外一區的問題... 整個 zone 都滅了就沒有這個問題啊 XDDD