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

Netflix 的 Chaos Monkey

Chaos MonkeyNetflix 丟出來的工具,這個工具的目的是希望建立超高可靠度的系統。方法則是沒事就亂關 AWS 上的 instance:「Chaos Monkey released into the wild」。

基本的想法是這樣:

  • 在 AWS 上的系統容錯率要超高。
  • 上班時間爛掉比凌晨三點被 call 起床好。
  • 所以平常就放火測試容錯率到底夠不夠高,方法就是隨機關 instance。

照 Netflix 的說法,他們不僅在開發環境測試,也在正式環境測試。利用 Chaos Monkey 看看 failure 的結果是否如預期。

Netflix 甚至建議可以排成每個上班日都隨機跑一跑:

The service has a configurable schedule that, by default, runs on non-holiday weekdays between 9am and 3pm.

只有在爆炸機率超高的系統上,設計師才會在意 failure 的問題...

AWS EBS 的改善...

AWS EBSAmazon Web Services 平台上的永久性儲存空間 (一般開起來的空間在 crash 後會消失),不過 EBS 的效能 (速度與 IOPS) 一直讓大家很頭痛,要硬撐 IOPS 的方式是透過四個 EBS volume,上面用 mdadm 跑 RAID0...

這幾個禮拜 AWS 丟出了兩個方案出來,提供不同的選擇...

首先是帶大容量 SSD 空間的 instance,參考「AWS 推出高速 I/O 的 EC2 instance」,這對於 cache 類的應用相當適合...

而昨天則是介紹了 Provisioned IOPS 與 EBS-Optimized instances:「Fast Forward - Provisioned IOPS for EBS Volumes」。

Provisioned IOPS 是保障 IOPS 的機制,每個 volume 最高可以到 1000 IOPS。除了每 GB 的價錢比較高以外,另外每個保障的 IOPS 要再收 USD$0.1/month。(本來 EBS 的 I/O 費用還是要計算)

標準的 EBS 約提供 100 IOPS,這個 Provisioned IOPS 架構讓使用者要在上面衝 IOPS 變得更容易...

EBS-Optimized instances 是把 EBS 使用的頻寬獨立出來,目前只支援 m1.large、m1.xlarge 以及 m2.4xlarge 這三種,其中 m1.large 跑到 500Mbps (理論值 62.5MB/sec),後面兩種可以上 1Gbps (125MB/sec),使得服務與 I/O 的頻寬不會互相干擾到...

在 Passion Bean 分享:System Operations for Startup

Passion Bean 的 Sting 與 ihower 邀請,到內湖用了兩個小時分享對於 Startup 公司在系統操作上的一些想法:

另外可以在 Facebook 上的活動頁 找到錄影。

一些關鍵字:

  • us-east-1:AWS 美東區的代號,位於維吉尼亞州。
  • 「萬事屋」指的是「新杰資訊科技股份有限公司」的老闆 Alex Wen。
  • Invalidation 與 Nameing Naming 是 CS 兩大難題:「TwoHardThings」。
  • 「未熟調教是一切邪惡的根源」出自劉燈「重新學C++」文章中 slzzp 的 comment

試用 HP Cloud (Compute 部分)

剛剛註冊了 HP Cloud 測試 Compute 的部分 (相對於 AWS 就是 EC2)。

先就公開的資訊來看,其實還不錯?最小的 instance 是 Extra Small,規格是 1GB RAM + 30GB Disk,收費 USD$0.04/hour,如果是 Small 則是 2GB RAM + 60GB Disk,另外在 Public Beta 期間是 50% off (半價)。

頻寬部分與 AWS 美國區的價錢相同,Inbound 不收費,Outbound 與 AWS 階梯式相同。

有提供網頁介面操作外,也有提供 CLI 可以用:「Unix Command Line Interface」,看起來是 Ruby... (沒裝起來測)

實際註冊完成後可以由從 zone 的名稱「az-1.region-a.geo-1」推敲出實際的機房位置在亞利桑那州 (實際開起來後也是如預期),HiNet 過去大約 140ms。

就 Public Beta 服務來看,要開 instance 時可以選擇的 OS image 也還算豐富:

CPU 部分,openssl speed 的數據是:「HP Cloud, openssl speed」,速度比起 EC2 的 m1.small 算是相當好的。

硬碟部分,iozone -a 的數據:「HP Cloud, iozone -a (over XFS)」,我是在跑 iozone 的時候用 dstat -at 觀察,寫入極限大約有 90MB/sec 到 100MB/sec,不過實際用 dd 測試就會發現應該是 host 有 cache,因為檔案很大的時候只有 20MB/sec 的寫入速度 XD

晚點再來測 Object Storage 與 CDN 的部分...

AWS 推出高速 I/O 的 EC2 instance

早上就看到 AWS EC2 推出 hi1.4xlarge 的消息:「New High I/O EC2 Instance Type - hi1.4xlarge - 2 TB of SSD-Backed Storage」(官方 blog)、「Expanding The Cloud – High Performance I/O Instances for Amazon EC2」(CTO Werner Vogels 的 blog)。

幾個比較重要的特性:

  • 60.5GB 記憶體
  • 10Gbps 網路
  • 1TB 的 SSD volume 兩個

前面兩個不會太意外,因為需要高速 I/O 的服務通常也都很需要用大量記憶體當作 cache 降低 I/O,也需要大量頻寬提供服務。用 SSD 也在預期的範圍內,不過提供的 SSD 空間居然這麼大...

當然,價位也不便宜,美東就要 USD$3.10/hour,冰島愛爾蘭則是 USD$3.41/hour (目前只有這兩區有提供)。如果以美東一個月 720hours 計算是 USD$2232,約台幣六萬六千多?

AWS SES 支援 DKIM

DKIM 全名 DomainKeys Identified Mail,是透過數位簽名技術確保 E-mail 的寄件人不是被偽造的,對於防止透過電子郵件網路釣魚是個還蠻有效的技術。

本來透過 AWS SES 寄信,要自己處理 DKIM 簽名的部份,不過今天 AWS 宣佈這項功能內建進 AWS SES:「Simple Email Service - Easy DomainKeys Identified Mail (DKIM) Support」。

於是,現在用 AWS SES 的人要 DKIM 只要把 SES 提供的 DNS record 設上去就可以了,比起之前自己得在 Sendmail 或是 Postfix 上弄一堆東西方便不少。

MiCloud,繼續測試...

續「MiCloud 測試...」這篇,早上再測試一次發現 MiCloud 已經修正了一些問題...

首先是開機器時 hostname 的問題已經解決了 (至少我不填,或是輸入 dash 都可以正確產生機器了,其他字元沒測試),另外同樣是 Ubuntu 10.04 LTS,這次進去沒看到 xorg 與 firefox 了。這兩個問題算是比較簡單的 (前面應該是改 input validator,後面應該是換 image)。

另外補上 ping 168.95.1.1 的數字:

--- 168.95.1.1 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 100312ms
rtt min/avg/max/mdev = 1.055/1.173/4.107/0.211 ms

以及 ping 168.95.192.1 的數字:

--- 168.95.192.1 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 100457ms
rtt min/avg/max/mdev = 1.180/6.190/115.787/18.101 ms, pipe 2

以及 www.hinet.net (202.39.224.7) 的數字:

--- 202.39.224.7 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 100893ms
rtt min/avg/max/mdev = 1.523/15.194/1609.699/119.968 ms, pipe 15

以及 www.cht.com.tw (202.39.225.136) 的數字:

--- 202.39.225.136 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 100773ms
rtt min/avg/max/mdev = 1.527/2.153/49.760/2.499 ms

很明顯有對 168.95.1.1 做處理...

另外有一點,最小台的機器提供 15GB 空間,不過系統的部份是 MiCloud 另外給 5GB 的空間放:

Filesystem            Size  Used Avail Use% Mounted on
/dev/vda1             5.0G  803M  3.9G  17% /
none                  496M  176K  496M   1% /dev
none                  500M     0  500M   0% /dev/shm
none                  500M   40K  500M   1% /var/run
none                  500M     0  500M   0% /var/lock
none                  500M     0  500M   0% /lib/init/rw
/dev/vdb1              15G  166M   14G   2% /data

其中 / 是 ext3,/data 是 ext4。

DNS 則是用 Google 提供的服務:

nameserver 8.8.8.8
nameserver 8.8.4.4

對外抓檔案的速度大約在 2.3MB/sec,包括 ubuntu.cs.nctu.edu.tw 與 ftp.speed.hinet.net。

MiCloud 測試...

2012-06-01 Update:請參考「MiCloud,繼續測試...」這篇。

昨天因為工作關係跟神通的人聊到 MiCloud,台灣少數幾個 IaaS 項目...

與國內其他 IaaS (或是說「VPS」) 比較不同的地方在於 MiCloud 與 Joyent 合作,不過我不想跑 SmartOS,所以這點沒有太大差異。另外是線上就可以直接申請信用卡付費,以小時計算,不需要傳真開機器... (這點 HiCloud 實在是...)

先把結論列出來:

  • 整體輸給 Linode 東京機房不少,除了國內的報帳需求外,沒有使用的誘因。

網站的部份:

  • micloud.tw 本身有 HTTPS (有買 SSL Certificate),但卻 redirect 到 portal.micloud.tw... (要輸入帳號密碼的地方反而沒有 SSL hmmm...)
  • 網站動線上卡卡的,常常會遇到「要按某個功能但找不到地方」,常常需要切到別的頁面才能找到...

再來開機器的時候遇到的幾個問題:

  • 最小台的機器 (1GB) 有點大台,據說有在規劃比較小台的機器。
  • 支援的 image 種類有點少,以 Ubuntu 目前只有 10.04 LTS,據說也是有規劃比較新的版本。實際升級發現可以升級到 12.04 LTS (我是 10.10、11.04、11.10、12.04 一路升上來),所以這不是大問題,但能預先提供會比使用者自己升級方便許多。
  • 開機器的頁面上說不需要設定 hostname (系統會幫你設定),但實際上不設定會出現一個看不懂的錯誤訊息... 我是著自己輸入 hostname 也是一樣,直到回家後我突然發現不能輸入 dash 後才開成功!XDDD (2012-06-01 Update:這條的兩個問題都已經解決)

開完機器後遇到的問題:

  • Ubuntu 10.04 LTS 預設的 apt server 是 us.archive.ubuntu.com,這應該要設為 tw.archive.ubuntu.com,或是 jp.archive.ubuntu.com (因為台灣 Ubuntu mirror 一向都不怎麼穩定)。
  • Ubuntu 10.04 LTS 裝的是 desktop 版本而非 server 版本?我看到整包 Firefox 在裡面... (2012-06-01 Update:現在 dpkg -l 看不到 xorg 與 firefox 了)
  • 在管理界面上看不到目前的流量使用量?

然後是網路:

  • 依照 TWNIC 上的資料來看 (2012 年 4 月),神通的機房對外主要有三組 100Mbps 的線路,分別是遠傳EBIX 以及 AGC,不過 routing 上是以遠傳以及 EBIX 為主。
  • HiNet 去回不同路,從神通到 HiNet 是走遠傳,但回程走 EBIX。
  • 同上,不知道是哪一段有問題,會發現對 HiNet 的 latency 有時會超過 20ms,於是在台灣機房的優勢就不見了...

另外附上 openssl speed 的測試數據,這是升級到 12.04 LTS 後的數據:https://gist.github.com/2832383,跟東京相比,單顆速度快一些,但東京的機器都有 4-core 可以用,所以...

Archives