Home » Posts tagged "ec2" (Page 15)

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 的問題...

AWS 推出高速 I/O 的 EC2 instance

早上就看到 AWS EC2 推出 hi1.4xlarge 的消息:「New High I/O EC2 Instance Type - hi1.4xlarge - 2 TB of SSD-Backed Storage」(官方 blog)、「Expanding The Cloud – High Performance I/O Instances for Amazon EC2」(CTO Werner Vogels 的 blog)。

幾個比較重要的特性:

  • 60.5GB 記憶體
  • 10Gbps 網路
  • 1TB 的 SSD volume 兩個

前面兩個不會太意外,因為需要高速 I/O 的服務通常也都很需要用大量記憶體當作 cache 降低 I/O,也需要大量頻寬提供服務。用 SSD 也在預期的範圍內,不過提供的 SSD 空間居然這麼大...

當然,價位也不便宜,美東就要 USD$3.10/hour,冰島愛爾蘭則是 USD$3.41/hour (目前只有這兩區有提供)。如果以美東一個月 720hours 計算是 USD$2232,約台幣六萬六千多?

AWS USD$50 的優惠...

Colin PercivalTwitter 上看到的:

Looks like Amazon Web Services is giving away $50 credits which can be used for running FreeBSD on EC2: http://aws.amazon.com/solutions/global-solution-providers/microsoft/aprilcredit/

活動的網址在「$50 AWS Service Credit for Microsoft Windows Server Instances Running on Amazon EC2」這裡。照說明是用在 AWS EC2 的 Microsoft Windows Server 上,不過把 code 輸入進去後寫了一堆 product:

有打算用 FreeBSD 的人應該是不會有問題 (參考「FreeBSD on EC2」這個頁面的說明),其他的服務不知道會不會也能用到,下個月就知道了 XD

AWS EC2 全面支援 64bits,並補上產品線...

之前用 AWS EC2 的人常遇到的狀況是,t1.micro 記憶體太小會常常 out of memory (用 EBS 硬撐當 swap 效能不好),但 m1.small 只能跑 32bits,為他做完整的 32bits image 維護成本實在不划算,因為等到之後變大後又得改做一份 64bits 的 image,如果從 t1.micro 改用 m1.large 又嫌太大台...

現在這個問題總算是解決了:「Announcing three new Amazon EC2 features」,EC2 這次提供新功能包括:

  • 推出新的 instance 種類 m1.medium,收費是 m1.small 的兩倍,所以規格大致上也是 m1.small 的兩倍,其中記憶體是 3.5GB RAM。
  • m1.small 與 m1.medium 除了可以跑 32bits 以外,也可以跑 64bits。

於是本來的問題可以用不同方向解決:

  • 本來做的 32bits image 當 m1.small 不夠用時也可以先拿 m1.medium 擋著。
  • 既然所有 EC2 instances 都可以跑 64bits,以後只要做 64bits image 就好了。
  • 同樣的,現在用 m1.large 嫌太大台的可以降到 m1.medium 或是 m1.small。

另外這次提供 Java SSH client,可以讓你直接在 Web Console 上面一貫作業,這個就比較用不到了...

AWS EC2 (以及使用 EC2 的加值服務) 降價,以及提昇存取 AWS S3 的效能...

AWS 宣佈 EC2 以及使用 EC2 的服務 (包括 RDS 與 ElastiCache) 降價:「New, lower pricing for Amazon EC2, RDS, and ElastiCache」,降價幅度在 Reserved Instances 比較大,但 On Demand Instances 的部份也有降一些。

Amazon.com 的 CTO Werner Vogels 也寫了一篇「Driving Compute Cost Down for AWS Customers」可以看看。

另外在「Amazon S3 Performance Tips & Tricks + Seattle S3 Hiring Event」這邊有 Doug Grismore (Director of Storage Operations for AWS) 寫了一篇客座文章,說明當量很大的時候要怎麼提昇對 AWS S3 存取的效能。這篇文章裡面有提到一些內部實做的結構,藉著了解這些內部結構,規劃檔案名稱,藉此提昇效能。

Amazon 詳細說明 AWS EBS/RDS 故障的原因...

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 用了三天半時間恢復...

AWS EC2/EBS 從星期四 21 日下午四點開始 (+8 時區),到剛剛在「Service Health Dashboard」上看到宣佈恢復 (亮綠燈),總共花了超過三天半的時間。有些人受到影響時間比較長,有些人比較短,我是在 24 號的凌晨恢復的,受到影響時間約兩天多。這幾天應該會有比較正式的說明...

手上本來沒打算這麼早設計 failover 機制的,現在都要拉到前面做了...

這次的 AWS EC2/EBS 問題...

這次的 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 已經算是某類型的電子商務公司了)。

話說回來,繼續等美東機房恢復...

Archives