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

AWS 在歐洲開第二個資料中心了:德國

上次開 us-west-1 (Ireland) 是 2008 年 12 月了,離這次 eu-central-1 (Frankfurt) 開在德國差了快八年:「Now Open - AWS Germany (Frankfurt) Region - EC2, DynamoDB, S3, and Much More」。

六月的時候有人發現 eu-central-1 這個代碼:「Amazon AWS builds a data center in Germany: Nice idea!」。

比較有趣的是,公告雖然出來了,但有些地方好像還沒完全搞定:

價錢的部份比 eu-west-1 貴一點點而已,對於要符合歐盟法令將資料留在歐盟地區,並且希望有遠距離異地建設的服務來說,解決了相當多的問題 :p

剛剛踹了 ec2.eu-central-1.amazonaws.com 這個 domain,看起來目前亞洲地區都還是從美國西岸再一路過去,不知道之後會不會再最佳化這塊,走俄羅斯或是有辦法走東歐過去...

CloudFront 統計資料繼續改善...

半年多前 CloudFront 在 web console 上實做了統計資訊:「Amazon CloudFront 可以從 Web Console 上看到統計資料了」,而今天可以看到更多東西了:「CloudFront Update - Trends, Metrics, Charts, More Timely Logs」。

首先是確保收到 log 的時間差,目前可以確保一個小時內會收到 log:

With these changes, the newest log files in your bucket will reflect events that have happened as recently as an hour ago.

再來是多了 cache 分析:

以及熱門物件統計資訊:

也是其他 CDN 業者都已經有的功能,算是在補 :p

查看各家 CDN 在各地的狀態

Cedexis 的「Real time data for real time decisions」蒐集了各家 CDN 在各地的連線資訊,包括了 response time、throughput 這些資訊,能夠解讀的話對於事前分析會很有幫助。

舉個例子來說,泰國地區 2014/10/20 的數字如下圖。

先從 latency 的部份開始看,可以看到 AkamaiCDNetworks 的速度分別是 52ms 與 63ms,可以合理猜測都是在泰國當地有 PoP 直接服務。而 LimelightCloudFront 要 98ms 與 111ms,看起來最少是新加坡或是香港?

而 availability 的部份也可以看出來國內線路的優勢,只要一跨國就不好維持。

這樣就可以針對需求而決定要找哪幾家 CDN 業者來談。在找 CDN 業者實際測試前,先看看這邊的資料會是很不錯的資訊,可以省下不少白工。

Amazon 的 Xen 安全性更新

AWS 上租一卡車機器的人最近應該都有收到重開機的通知,目前雖然沒有明講編號,但看起來是 10/01 會公開的 XSA-108:「EC2 Maintenance Update」。

不過 Slashdot 上的「Amazon Forced To Reboot EC2 To Patch Bug In Xen」這篇的第一個 comment 很精彩:

It's funny for me to read that Amazon is notifying its users of an impending reboot.

I've been suffering with Azure for over a year now, and the only thing that's constant is rebooting....

My personal favorite Azure feature, is that SQL Azure randomly drops database connections by design.

Let that sink in for a while. You are actually required to program your application to expect failed database calls.

I've never seen such a horrible platform, or a less reliable database server...

這要怎麼說呢... 就使用雲端服務的人,設計上的確要這樣沒錯,但就提供雲端服務的供應商,應該還是要保持 VM 的穩定性吧... XDDD

EMR 對 S3 Consistency 的補強

今年一月的時候,Netflix 曾經寫過一篇關於對 S3 的 Eventually Consistency 的問題:「Netflix 對 S3 的 Eventually Consistency 的補強...」,當時 Netflix 的作法是實做 s3mper 以確保一致性。

過了半年,AWS 的人在 EMR 上實做了類似的功能:「Consistent View for Elastic MapReduce's File System」。

看文章的說明,應該是用到 DynamoDB 負責 S3 上資料的狀態,而 DynamoDB 的資料並不會砍掉,所以在使用時要注意這點 :o

水樹奈奈的官方網站放到 Route53 + S3 + CloudFront 上...

剛剛才意外發現的,是 Route53 + S3 + CloudFront 的組合:

;; ANSWER SECTION:
www.mizukinana.jp.      60      IN      A       54.239.176.113
www.mizukinana.jp.      60      IN      A       54.239.176.150
www.mizukinana.jp.      60      IN      A       54.230.214.85
www.mizukinana.jp.      60      IN      A       54.230.214.89
www.mizukinana.jp.      60      IN      A       54.230.215.52
www.mizukinana.jp.      60      IN      A       54.230.215.91
www.mizukinana.jp.      60      IN      A       54.230.215.156
www.mizukinana.jp.      60      IN      A       54.239.176.88

這些 IP 是台灣的 CloudFront 節點。從 whois 可以看到至少是三月就這樣了?

Domain Information:
[Domain Name]                   MIZUKINANA.JP

[Registrant]                    Most Company Co., Ltd.

[Name Server]                   ns-290.awsdns-36.com
[Name Server]                   ns-1966.awsdns-53.co.uk
[Name Server]                   ns-1265.awsdns-30.org
[Name Server]                   ns-579.awsdns-08.net
[Signing Key]                   

[Created on]                    2005/09/13
[Expires on]                    2014/09/30
[Status]                        Active
[Last Updated]                  2014/03/28 12:36:18 (JST)

Netcraft 上沒有記錄到什麼時候換的:「Site report for www.mizukinana.jp」。

不過 archive.org 上可以看到改版的記錄,應該是 migration 的時候順變換過去的?看 2014/02/10 版本以及 2014/05/18 版本的差異,連結從 mizukinana.jp 變成了 www.mizukinana.jp

所以應該是三月改的?

意外的先進... XD

用 Amazon S3 送 301 重導

參考「Configure a Bucket for Website Hosting」這邊的說明就可以了,拿 test-redirect.abpe.org 當範例,先是 CNAMES3 的 website endpoint 上:(這個 bucket 我是放在 us-west-2 上,所以會指到 us-west-2 的 website endpoint)

;; ANSWER SECTION:
test-redirect.abpe.org. 7200    IN      CNAME   test-redirect.abpe.org.s3-website-us-west-2.amazonaws.com.

然後 S3 上指定 redirect rule:

  <RoutingRules>
    <RoutingRule>
    <Condition>
      <KeyPrefixEquals>img/</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <HostName>www.example.com</HostName>
      <ReplaceKeyPrefixWith>img/</ReplaceKeyPrefixWith>
    </Redirect>
    </RoutingRule>
  </RoutingRules>

也就是像是這樣:

也就是說,如果是 simple redirect 的話,可以善用 S3 的這個功能而不用自己架設 web server (自己架設需要另外考慮 High Availability),還算蠻方便的?

Route 53 的大改版

Amazon Route 53 的大改版:「Route 53 Update - Domain Name Registration, Geo Routing, and a Price Reduction」。

首先是可以註冊 domain,除了 web console 外,還可以透過 API 註冊:「Actions on Domain Registrations」。

看起來 privacy protection 的部份是跟 Gandi 合作:

Turns privacy protection on or off for the domain, determining whether WHOIS queries return contact information specified in the registrar record. If privacy protection is enabled, the query returns contact information for our registrar partner, Gandi, instead of the contact information that is specified in the registrar record.

沒看到可以註冊的 tld 的 API,但是網站 web console 連進去可以看到其實相當多... (不過目前沒看到 .tw)

另外一個大功能是 Geo Routing,可以選擇洲別,或是地區別。不過「美國本土」(海外的部份有另外分區) 與「中國」這兩個網路大國都各只有一區,而不是把再依照各州或各省細分... (有不少 CDN 所提供的 DNS 服務是把美國依照各州列出設定...)

但至少補上了這一塊,這樣可以用 Route53 配合 multi-CDN 的機制,而不需要自己刻了...

然後最後是 query 的價錢降價 20%:

Last, but certainly not least, I am happy to tell you that we have reduced the prices for Standard and LBR (Location-Based Routing) queries by 20%.

是該看看要不要撤掉 Zerigo,因為目前這塊最大的成本其實是報帳以及帳號控管,而非單純租用成本 :o

AWS 的 ELB 可以自訂 HTTP/HTTPS Timeout 時間了

Elastic Load Balancing 之前的 timeout 時間是預設值 60 秒,現在可以自訂時間了:「Elastic Load Balancing Connection Timeout Management」。

文章裡有提到好處:

Some applications can benefit from a longer timeout because they create a connection and leave it open for polling or extended sessions. Other applications tend to have short, non- recurring requests to AWS and the open connection will hardly ever end up being reused.

目前可以設定 1 秒到 3600 秒,預設值是 60 秒。

Archives