Tag: cloud

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 台北的聚會...

AWS 亞太區的窗口要來台灣，本來是計畫找城邦集團內的人一起聊聊，後來跟 jnlin 提議，直接拉到社群層面辦，讓更多人跳下去用... (而且「前幾天的事情」大家應該會想要找人聊聊？XD)

飲料的部份由敝公司 PIXNET 準備，歡迎來交流。註冊的資訊在：「Amazon Web Service 台北開發者聚會」。

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

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

目前 AWS EC2 (美東機房) 出問題...

在 AWS 的「Service Health Dashboard」上可以看到美東機房從 PDT 1:41 AM (台灣時間是 4:41 PM) 開始介入，到現在五個多小時了...

下午本來要跑一堆東西，看起來得晚上做了，明天來凹一下老闆，下午再進公司好了... :o

Update：在 Service Health Dashboard 上面總算有初步的原因了：

8:54 AM PDT We'd like to provide additional color on what were working on right now (please note that we always know more and understand issues better after we fully recover and dive deep into the post mortem). A networking event early this morning triggered a large amount of re-mirroring of EBS volumes in US-EAST-1. This re-mirroring created a shortage of capacity in one of the US-EAST-1 Availability Zones, which impacted new EBS volume creation as well as the pace with which we could re-mirror and recover affected EBS volumes. Additionally, one of our internal control planes for EBS has become inundated such that it's difficult to create new EBS volumes and EBS backed instances. We are working as quickly as possible to add capacity to that one Availability Zone to speed up the re-mirroring, and working to restore the control plane issue. We're starting to see progress on these efforts, but are not there yet. We will continue to provide updates when we have them.

看起來還要再等等...

AWS 東京第二個 AZ (Availability Zone) 今天啟用...

開張不到一個月的 AWS Japan 今天宣佈啟用第二個 Availability Zone：「Adding a Second AWS Availability Zone in Tokyo」，第一個 AZ 是在 2011/03/02 宣佈啟用：「Amazon Web Services 東京！」。

好快的速度... 是因為全世界對亞洲的需求嗎？

Amazon Web Services 東京！

AWS Japan

AWS 公告了對日本的 Support：「Announcing AWS Support in Japanese」，並公告了新增東京的 Region：「Announcing the AWS Asia Pacific (Tokyo) Region」。另外「Amazon Web Services (日本語)」的網頁也同步啟用。

相較於之前的新加坡 Region，主要是對南亞與印度地區的幫助比較明顯，日本與韓國到新加坡與美西比起來並沒有太大差異。但這次在日本設點後，AWS 在亞洲的強度就好很多...

品質的部份就要繼續觀察了。另外，不論是頻寬還是租用 EC2 的價位上都比新加坡再貴了一些，不過都還是可以接受的程度，可以觀察日韓兩國的 VPS 被衝擊的狀況...

AWS API 的認證方式

Amazon Web Services 有提供很多服務，有的早在「雲端風潮」前就有，有的是最近才推出的。把 AWS Documentation library 每個服務的 API 認證方式看完一遍後，只能苦笑對使用 AWS API 的人致敬...

有幾個心得與感想：

  • 文件雖然套用同一組模板 (用 frame 切開，左邊索引，右邊內容)，但其中的寫法並沒有統一。理論上每個 API 都會有的 API 簽名環節在不同的文件裡可能會在不同的章節出現。
  • 認證的方式不一致：
    • 早期的服務很亂，大多都是以 SOAP 為基礎的 API，尤其是跟錢有關的這塊特別明顯 (因為 Amazon 很早就 API 化)。
    • 一開始出來的 S3 使用的是 REST 概念，簽名的值放在 HTTP Header 內，欄位名稱是 Authorization，CloudFront 是 S3 的延伸，所以認證方式與 S3 相同。
    • 但與 S3 同時期推出的 EC2，以及後來大多數的服務，都是以 GET 為基礎。這時候兩套系統的 API 設計邏輯就不同了。
    • 最近出的 Route53，又再引入了 REST 概念，但欄位名稱為 X-Amzn-Authorization，要放的簽名格式又改變了...

這也是為什麼沒有一套 library 可以一直吃遍 AWS 服務的關係，API 的設計讓人感覺頗疲倦... XD

Google Apps 的 Uptime 計算方式調整 (對使用者有利的方向)

Google 改變了 Google Apps 對 Uptime 的計算方式：「Google Apps Removes Scheduled Downtime Clause From SLA; Gmail Had 99% Uptime in 2010」(TC)、「Destination: Dial Tone -- Getting Google Apps to 99.99%」(Google 官方新聞稿)。

之前的條款內允許 Google 將「排定的維護停機」排除在 downtime 計算外，現在 Google 決定拿掉這條例外條款。然後在文章下面故意提到 Microsoft 的服務：

Comparable data for Microsoft BPOS® is unavailable, though their service notifications show 113 incidents in 2010: 74 unplanned outages, and 33 days with planned downtime.

有興趣看新版 SLA 的人可以連結到英文版的頁面上：「Google Apps Service Level Agreement」。

PHP 的 Heroku

在「PHP Fog Raises $1.8 Million To Be The Heroku Of PHP」裡面提到兩家：PHP Fog 與 cloudControl。

兩者都是以 PHP 為底層語言基礎的平台。其中 PHP Fog 還沒開張，而 cloudControl 已經開張了，以歐洲的 EC2 為底層。

不過 cloudControl 選用 Bazaar 為版本管理系統，這點不知道是什麼考量... (PHP 是用 Subversion)