Tag: cloud

AWS 上資安產品試用...

前幾天 AWS 公佈了「Evaluate Security Products With no Software Charges by Using AWS Marketplace」，在 5/15 前有六個資安產品可以試用 120 小時。

有 WAF、Firewall，也有 UTM，另外還有 data encryption 的方案。找機會來測試看看好了，不知道是擋在哪一層...

AWS 大降價

在「AWS Price Reduction #42 - EC2, S3, RDS, ElastiCache, and Elastic MapReduce」這邊看到 AWS 降價的消息，明顯是被 Google 壓著推出來 :p

降價的範圍包括 EC2 instance、EC2 的 reserved instance、S3，以及對應的 RDS、ElastiCache、Elastic MapReduce。

前幾天買了兩台 us-west-2 c1.xlarge 的三年 RI，結果從 USD$2804 降到 USD$2524，現虧 USD$280 (XDDD)，而每小時單價從 USD$0.124 降到 USD$0.112，也就 9.7% 左右。

另外 S3 的部份則是直接從 USD$0.085/GB 一次殺到 USD$0.03/GB 了，隨著使用量的增加的 discount 差不多都消失了。

等下再來研究好了，計畫永遠趕不上變化...

AWS Elastic Load Balancing 服務支援 Connection Draining

AWS Elastic Load Balancing 支援 Connection Draining 功能了：「ELB Connection Draining - Remove Instances From Service With Care」。

由於 Connection Draining 是自創名詞，所以 AWS 的人解釋了一大堆。其實對比較熟悉的人用「graceful shutdown」就應該能了解 Connection Draining 想要做什麼事情。

技術上的細節是，當 instance 從 ELB 內被移除 (無論是暫時性的還是永久性的)，新的 request 將不會被送到該 instance 裡，而既有的連線將不會斷掉，直到 client 完成或是超時 (timeout)。

這個功能在一般商用的 load balancing solution 都會提供，而且是對於服務品質其實還蠻重要的功能。

話說回來，這陣子 ELB 動了不少東西？不查資料可以直接想到的就包括了：

  • HTTPS 支援 PFS。
  • 支援 access log 下載。

再加上今天的 graceful shutdown。每次都改善一些東西，累積起來就是驚人的財產...

Amazon CloudFront 可以從 Web Console 上看到統計資料了

官方這篇「Announcing Amazon CloudFront Usage Charts for Web Distributions - Track Trends in Requests & Data Transfer」公告說明 Amazon CloudFront 可以透過 Web Console 看到統計數據了：

最近好像補了不少 log 與統計的功能，CloudFront 也趕上這波了 XD

Vagrant 1.5

Vagrant 1.5 出了：「Vagrant 1.5 and Vagrant Cloud」。

最大的亮點是前陣子就有寫「Feature Preview: Vagrant Share」的 Vagrant Share，可以讓其他人很方便的連到自己的 Vagrant 機器上。

Vagrant Cloud 則是產品面上的整合，算是社群功能？

最近拿 Vagrant 與 Docker 測試的次數愈來愈頻繁了，之前拿 Amazon EC2，但開機速度太慢，而 DigitalOcean 開機速度雖然快很多，但不是很容易透過 cli 操作...

而這兩套各有優缺點。Docker 速度快，但環境相容性沒有 Vagrant 好，另外 Vagrant 畢竟是包著 VirtualBox 這種全虛擬化環境，除了 Linux 以外也可以測其他的作業系統。

反正都是熱門的軟體，之後看社群發展出什麼功能再看要怎麼用 :p

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

AWS 的 Elastic 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

猜測 AWS ELB 內的架構...

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

在非雲端的架構上會使用 Layer 4 Switch (像是 F5、Alteon)，或是使用 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 打散？之後再來觀察看看好了... 還有很多煩惱要處理 ~_~

AWS EC2 更新以及降價，以及 EBS 降價...

AWS 官方公告這一波改善：「AWS Update - New M3 Sizes & Features + Reduced EBS Prices + Reduced S3 Prices」。

首先是 EC2 多了 m3.medium 與 m3.large，與 m1.medium 與 m1.large 相比很有競爭力？

以 {m1,m3}.medium 比較來看，m3 的 ECU 值比 m1 高 50% (3 vs 2)，而且有 SSD 硬碟 (雖然只有 4GB)，價錢又比較便宜... 拿來跑 CPU bound 的 server 看起來就很好用啊？

另外一個超大的降價是 EBS，空間費用與 i/o 的費用都直接降 50%...

該來找人討論 KKTIX 要不要 migrate 過去了...