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

Mozilla 推薦的 jsDelivr?

Mozilla 在「jsDelivr – The advanced open source public CDN」這篇文章裡面推薦 jsDelivr 這個服務:

Similar to Google Hosted Libraries, jsDelivr is an open source CDN that allows developers to host their own projects and anyone to link to our hosted files in their websites.

GitHub 當作 origin server,前端目前利用 CloudFlareMaxCDN,配合 Cedexis 的 openmix 服務,綜合這兩家 CDN 提供服務。

既有的 cdnjs.com 是由 CloudFlare 贊助的服務,那 jsDelivr 呢?

看了老半天得到這些訊息:jsDelivr 是由 @jimaek 所發起的服務,而 @jimaek 受雇於 MaxCDN。再加上 Mozilla 上的文章也是 @jimaek 發表,而且只發表過這一篇 (參考 Articles by Dmitriy Akulov),這邊的目的也太明顯...

應該可以每幾天就看一下下面的 comment,不知道什麼時候會引爆利益衝突的問題...

Elastic Load Balancing 總算實做 access log...

AWSElastic Load Balancing 總算想起來這個欠了許久的功能,access log:「Access Logs for Elastic Load Balancers」。

原文裡有提到用 Hive 分析的部份,挑出最前面的欄位名稱就可以看出提供什麼資訊:

CREATE EXTERNAL TABLE elb_raw_access_logs (
     Timestamp STRING,
     ELBName STRING,
     RequestIP STRING,
     RequestPort INT,
     BackendIP STRING,
     BackendPort INT,
     RequestProcessingTime DOUBLE,
     BackendProcessingTime DOUBLE,
     ClientResponseTime DOUBLE,
     ELBResponseCode STRING,
     BackendResponseCode STRING,
     ReceivedBytes BIGINT,
     SentBytes BIGINT,
     RequestVerb STRING,
     URL STRING,
     Protocol STRING
)

裡面還有些資訊沒包含在上面,像是 availability zone。因為這個資訊是包含在檔名內:

In addition to the bucket name and the prefix that you specified when you configured and enabled access logs, the log file name will also include the IP address of the load balancer, your AWS account number, the load balancer's name and region, the date (year, month, and day), the timestamp of the end of the logging interval, and a random number (to handle multiple log files for the same time interval).

接下來應該要把現有的 ELB 都開起來 XD

CloudFront 支援 SNI,不需額外每個月 USD$600 的費用...

剛剛看到 Amazon CloudFront 支援 SNI,而且不像 Dedicated IP Custom SSL 需要每個月 USD$600 的費用:「New Features for Amazon CloudFront: Server Name Indication (SNI) and HTTP Redirection」。

目前最大的問題只剩下 Windows XP + IE8 不支援 SNI,台灣還有 19.86% 的人使用 IE8 (不知道 Windows XP + IE8 實際佔多少):


(出自 http://gs.statcounter.com/#browser_version-TW-monthly-201302-201402)

但至少行動裝置上的主力平台都支援了,如果大多數用戶是行動裝置,這個方式可以兼顧 custom SSL domain 與花費...

在 S3 上儲存大量資料時要注意的事情

印象中要在 Amazon S3 上面存大量資料時需要注意 key 的命名,用 Google 找了找發現官方的「Request Rate and Performance Considerations」這篇。

文章中有提到這是對有大量存取需求時才需要注意的事項:

The guidelines in this section apply if you are routinely processing 100 or more requests per second. If your typical workload involves only occasional bursts of 100 requests per second or more, you don't need to follow the guidelines in this section.

不過平常即使沒有需要大量存取,還是可以照著做,因為應該不會有負面影響。如果能照著上面的方式先做,之後也許會受益...

由於 Amazon S3 是使用 key-prefix 當作 partition 的依據,所以 prefix 的值對於效能很重要。官方推薦的幾種方法都是對 key-prefix 下手:

  • 對整個 path + filename 的字串 hash 後當作 prefix。舉例來說,examplebucket/2013-26-05-15-00-00/cust1234234/photo1.jpg hash 後加到前面,名稱變成 examplebucket/232a-2013-26-05-15-00-00/cust1234234/photo1.jpg
  • 將最前面一段 reverse string。像是把 2134857/data/start.png 變成 7584312/data/start.png

AWS ELB 加強安全性...

AWS ELB 加強對 SSL 安全性的功能:「Elastic Load Balancing – Perfect Forward Secrecy and Other Security Enhancements」。

第一個是支援 PFS (Perfect Forward Secrecy),愈大多數的實做相同,是使用 ECDH

第二個是 Server Order Preference,由 server 這邊決定最終的 cipher。

最重要的是第三個,也就是「懶人包」。推出新的 security policy ELBSecurityPolicy-2014-01,把上面兩個都設進去了。

這次的升級是對安全性的提昇...

DigitalOcean 建立新加坡機房...

今天 DigitalOcean 宣佈新加坡資料中心營運 (SGP1):「We're Excited To Announce Our Singapore Datacenter (SGP1)」。

要測試 latency 或是要看 routing 的人可以用 DigitalOcean 提供的 speedtest-sgp1.digitalocean.com 測。

中華電信 HiNet 光世代動態 IP、PPPoE 固定 IP,以及三重的重新機房到 speedtest-sgp1.digitalocean.com 都是 90ms~100ms 左右。

台灣固網內湖機房約 75ms 左右。

而目前看到數字最好的是遠傳的機房的 60ms 左右,ISP 直接進香港 NTT 後就轉入新加坡 NTT,最後進 DigitalOcean。

在 comment 裡也有提到目前的 peering 還不完整,最近會一直調整:

In regards to the latency that people may be experiencing in Singapore: We are sorry to hear that you are having latency issues at this time. Some of our peering is delayed and we will be improving generally connectivity around Asia in the coming weeks.

以後要測試就拿這個點了!XD

猜測 AWS ELB 內的架構...

AWS Elastic Load Balancing (ELB) 是 AWS 在雲端上推出的 Load balancer。

在非雲端的架構上會使用 Layer 4 Switch (像是 F5Alteon),或是使用 open source 的 HAProxy

從實驗猜測 ELB 是這樣做的:

  • ELB 是 Amazon 自己開發的「軟體」,而非硬體。可能就是跑在 EC2 上,也可能為了 billing 的需求是跑在另外一個 cluster 上。
  • 在每一個有 instance 需要服務的 availability zone 上都會開一台 ELB instance 起來。
  • 每一個 ELB instance 會有一個 public IP 對外,在 ELB domain 解出來的 IP 可以查出來。

所以 ELB 的文件上會警告「每一個 AZ 的運算能力要盡可能接近」:

By default, the load balancer node routes traffic to back-end instances within the same Availability Zone.

To ensure that your back-end instances are able to handle the request load in each Availability Zone, it is important to have approximately equivalent numbers of instances in each zone.

這是因為不同 AZ 的平衡是靠 DNS round robin 處理,所以下面的例子就有建議儘量打平:

For example, if you have ten instances in Availability Zone us-east-1a and two instances in us-east-1b, the traffic will still be equally distributed between the two Availability Zones.

As a result, the two instances in us-east-1b will have to serve the same amount of traffic as the ten instances in us-east-1a.

As a best practice, we recommend that you keep an equivalent or nearly equivalent number of instances in each of your Availability Zones.

So in the example, rather than having ten instances in us-east-1a and two in us-east-1b, you could distribute your instances so that you have six instances in each Availability Zone.

而量大到一個 ELB instance 撐不住的時候,AWS 就會自動開出第二台:(目前都只放在同一個 zone 上)

;; ANSWER SECTION:
lb-guesschocolate-1791292202.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.249.68.121
lb-guesschocolate-1791292202.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.238.240.61

以這樣的架構,當量夠大的時候,AWS 應該要有能力生出足夠多的 ELB instance 打散?之後再來觀察看看好了... 還有很多煩惱要處理 ~_~

Archives