Home » Computer » Network » Archive by category "Cloud" (Page 72)

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.

看起來還要再等等...

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 被衝擊的狀況...

Blog 關掉 CloudFront CDN...

剛剛用手機看自己的 blog 發現版面亂掉,看起來是 CSS 有問題...

測了一些東西後發現,如果 W3 Total Cache 使用 CloudFront CDN,會使得 WPTouch 失效,拿掉 CDN 的部份就會恢復正常...

那只好先拿掉了,現在用手機看 blog 的人應該就正常了...

AWS API 的認證方式

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

有幾個心得與感想:

  • 文件雖然套用同一組模板 (用 frame 切開,左邊索引,右邊內容),但其中的寫法並沒有統一。理論上每個 API 都會有的 API 簽名環節在不同的文件裡可能會在不同的章節出現。
  • 認證的方式不一致:
    • 早期的服務很亂,大多都是以 SOAP 為基礎的 API,尤其是跟錢有關的這塊特別明顯 (因為 Amazon 很早就 API 化)。
    • 一開始出來的 S3 使用的是 REST 概念,簽名的值放在 HTTP Header 內,欄位名稱是 AuthorizationCloudFront 是 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」。

Archives