前幾天 AWS 推出 EBS-SSD (參考「AWS 推出 SSD EBS」),然後今天看到「EBS-SSD Boot AMIs For Ubuntu On Amazon EC2」。
Canonical 正式的說明在「[ubuntu-cloud] Amazon SSD backed EBS volumes」這邊可以看到,而「Amazon EC2 AMI Locator」上也新增了 EBS-SSD 的部份。
幹壞事是進步最大的原動力
前幾天 AWS 推出 EBS-SSD (參考「AWS 推出 SSD EBS」),然後今天看到「EBS-SSD Boot AMIs For Ubuntu On Amazon EC2」。
Canonical 正式的說明在「[ubuntu-cloud] Amazon SSD backed EBS volumes」這邊可以看到,而「Amazon EC2 AMI Locator」上也新增了 EBS-SSD 的部份。
EBS 是 AWS 上的 block-level storage,除了空間本身要收費以外,I/O 本身也要收費。到今天為止,EBS 只提供 Magnetic volume,也就是與傳統硬碟性質接近的 EBS。
而今天 AWS 推出了 SSD 的 EBS:「New SSD-Backed Elastic Block Storage」,價錢上當然就比傳統硬碟建立的 EBS 貴,但看起來是個可以接受的數字?
另外傳統硬碟的 Provisioned IOPS volume 也降價了,約 35% off:
We are also announcing that we are reducing the price of IOPS for Provisioned IOPS volumes by 35%.
需要效能的應用又多了一項武器...
AWS 官方公告這一波改善:「AWS Update - New M3 Sizes & Features + Reduced EBS Prices + Reduced S3 Prices」。
首先是 EC2 多了 m3.medium 與 m3.large,與 m1.medium 與 m1.large 相比很有競爭力?
以 {m1,m3}.medium 比較來看,m3 的 ECU 值比 m1 高 50% (3 vs 2),而且有 SSD 硬碟 (雖然只有 4GB),價錢又比較便宜... 拿來跑 CPU bound 的 server 看起來就很好用啊?
另外一個超大的降價是 EBS,空間費用與 i/o 的費用都直接降 50%...
該來找人討論 KKTIX 要不要 migrate 過去了...
AWS EBS 是 Amazon Web Services 平台上的永久性儲存空間 (一般開起來的空間在 crash 後會消失),不過 EBS 的效能 (速度與 IOPS) 一直讓大家很頭痛,要硬撐 IOPS 的方式是透過四個 EBS volume,上面用 mdadm 跑 RAID0...
這幾個禮拜 AWS 丟出了兩個方案出來,提供不同的選擇...
首先是帶大容量 SSD 空間的 instance,參考「AWS 推出高速 I/O 的 EC2 instance」,這對於 cache 類的應用相當適合...
而昨天則是介紹了 Provisioned IOPS 與 EBS-Optimized instances:「Fast Forward - Provisioned IOPS for EBS Volumes」。
Provisioned IOPS 是保障 IOPS 的機制,每個 volume 最高可以到 1000 IOPS。除了每 GB 的價錢比較高以外,另外每個保障的 IOPS 要再收 USD$0.1/month。(本來 EBS 的 I/O 費用還是要計算)
標準的 EBS 約提供 100 IOPS,這個 Provisioned IOPS 架構讓使用者要在上面衝 IOPS 變得更容易...
EBS-Optimized instances 是把 EBS 使用的頻寬獨立出來,目前只支援 m1.large、m1.xlarge 以及 m2.4xlarge 這三種,其中 m1.large 跑到 500Mbps (理論值 62.5MB/sec),後面兩種可以上 1Gbps (125MB/sec),使得服務與 I/O 的頻寬不會互相干擾到...
Amazon 在網頁上說明了在 4/21 美東地區 EBS/RDS 故障的原因:「Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region」。
整篇文章相當長,但整個連鎖反應是起於操作時的人為疏失。而 RDS 因為是基於 EBS 上,所以也跟著大爆炸...
另外文章最後面也提到賠償的方式:
For customers with an attached EBS volume or a running RDS database instance in the affected Availability Zone in the US East Region at the time of the disruption, regardless of whether their resources and application were impacted or not, we are going to provide a 10 day credit equal to 100% of their usage of EBS Volumes, EC2 Instances and RDS database instances that were running in the affected Availability Zone.
另外,AWS 的 SLA 中有要求當未滿 SLA 條件時,必須由使用者提出退款要求,但這次則是例外,符合條件的會主動在下次的帳單上,或是系統的頁面上看到:
These customers will not have to do anything in order to receive this credit, as it will be automatically applied to their next AWS bill. Customers can see whether they qualify for the service credit by logging into their AWS Account Activity page.
AWS EC2/EBS 從星期四 21 日下午四點開始 (+8 時區),到剛剛在「Service Health Dashboard」上看到宣佈恢復 (亮綠燈),總共花了超過三天半的時間。有些人受到影響時間比較長,有些人比較短,我是在 24 號的凌晨恢復的,受到影響時間約兩天多。這幾天應該會有比較正式的說明...
手上本來沒打算這麼早設計 failover 機制的,現在都要拉到前面做了...
這次的 AWS EC2/EBS 問題讓很多站台掛掉 (可以看「Who is affected by EC2?」這個站台,在發文的現在 US-East 還是沒完全恢復),但這次並不是每個使用 US-East 的站台都掛掉,像是 Netflix 因為一開始規劃就是「Cloud 也是會爛整片的」,所以服務並沒有中斷。在 Hacker News 上就有被提出來討論。
討論裡面也有投影片說明 Netflix 選 AWS 的原因是因為「來不及建立 Data Center」,但在建立時也同時注意到「Cloud 有可能會大規模爛掉」的情況而設計了很多機制防範:「Netflix in the cloud 2011」。
利用 AWS 在多個不同地點都有機房把架構在 AWS 上所能提供的 HA 機制發揮到極致,不過這是建立在「Cheaper than cost of being down」的想法上 (因為 Netflix 已經算是某類型的電子商務公司了)。
話說回來,繼續等美東機房恢復...
Colin Percival 前陣子公佈了 EC2 上跑 FreeBSD 9.0-CURRENT 的 ami,當時測試覺得太慢了:「在 AWS EC2 上跑 FreeBSD」,昨天他在 Twitter 上提到把 FreeBSD 8.2-RC1 也 porting 上去了:
FreeBSD 8.2-RC1 is now available on EC2 as ami-d29b6abb. http://www.daemonology.net/freebsd-on-ec2/ #merrychristmas
實際測試以後發現 8.2-RC1 還是很慢,跑 portsnap fetch
要等半個小時,跑 portsnap extract
也要再等半個小時,看起來是因為 EBS 的速度太慢?如果是這樣的話就得等非 t1.micro 的版本了 (因為 t1.micro 只能用 EBS 跑)。
以目前進度來看,8.2-RELEASE 會是第一個支援 EC2 的 production 版本?
Amazon Web Services 推出了 Amazon Linux AMI (Beta),讓想要用新版 Linux kernel 的人可以在 EC2 上測試:「Announcing the Amazon Linux AMI」。
包括了 32bits/64bits 以及 S3/EBS boot 的版本 (所以總共四種版本),基本的系統都是 Fedora。其中 EBS 版本可以直接用 t1.micro 跑起來,以目前跑起來的版本 uname -a
可以看到:
Linux domU-12-31-38-02-55-4B 2.6.34.6-54.21.amzn1.i686 #1 SMP Sun Sep 12 06:48:07 UTC 2010 i686 athlon i386 GNU/Linux
依照 kernel.org 的資料可以看到 2.6.34.6 是 2010/8/26 釋出,算是蠻新的版本了...
接下來就是要找方法把 EC2 上 Fedora 系統換成 Debian,這個倒是有不少文件,像是:「Building EC2 Images from Scratch with ec2ubuntu-build-ami」...
Update:依照 Eric Hammond 的說法,不建議使用 ec2ubuntu-build-ami 這個 script 產生 AMI,參考他在 9/18 的回覆。目前建議的方式是「Building EBS Boot and S3 Based AMIs for EC2 with Ubuntu vmbuilder」以及「Building EBS Boot AMIs Using Canonical's Downloadable EC2 Images」這兩篇。