幹壞事是進步最大的原動力
分別是 identity.cloudfront.net 與 resolver-identity.cloudfront.net 的 TXT record，像是這樣：
;; QUESTION SECTION: ;identity.cloudfront.net. IN TXT ;; ANSWER SECTION: identity.cloudfront.net. 60 IN TXT "ns-nrt52-02.cloudfront.net.nrt52"
以及：
;; QUESTION SECTION: ;resolver-identity.cloudfront.net. IN TXT ;; ANSWER SECTION: resolver-identity.cloudfront.net. 10 IN TXT "210.242.135.97"
看起來是 AWS 在 forum 上回答時的 SOP 之一...
Amazon Simple Storage Service (Amazon S3) 是 AWS 第一代儲存服務。後來 S3 又提供了 Reduced Redundancy Storage，降低可靠度 (一年 99.99%) 換取價錢上的優勢，用在 cache file 之類的還蠻不錯。目前兩者在美東的價錢是 USD$0.125/GB 與 USD$0.093/GB。這兩種都是隨時可以存取的服務。
而 Amazon Glacier 則是提供超低的價錢與超高的可靠度：USD$0.01/GB 與一年 99.999999999%，而這是靠取回檔案的時間換來的。取回檔案需要排 3.5 到 4.5 小時的時間 (後面傳輸的時間另外計算)：
Retrieving archives from Amazon Glacier requires the initiation of a job. Jobs typically complete in 3.5 to 4.5 hours.
是靠著機械手臂與軌道在處理嗎？
但這樣就多了很多用途啊... Data warehouse 是個很明顯的方向。目前可以透過 AWS Import/Export 匯入大量資料：
You can also use AWS Import/Export to accelerate moving large amounts of data into Amazon Glacier using portable storage devices for transport.
之後則是會提供從 S3 搬出去與搬進去的功能：
In the coming months, Amazon Simple Storage Service (Amazon S3) plans to introduce an option that will allow you to seamlessly move data between Amazon S3 and Amazon Glacier using data lifecycle policies.
等工具完整後再來研究 :p
發現連到 AWS 首頁出現破圖，結果發現 CloudFront 的 DNS 爆炸，不管是從 HiNet 或是從 Linode 東京查都查不到：
在 AWS Developer Forums 上面也開始有人問了：
晚點應該會有說明吧...
Chaos Monkey 是 Netflix 丟出來的工具，這個工具的目的是希望建立超高可靠度的系統。方法則是沒事就亂關 AWS 上的 instance：「Chaos Monkey released into the wild」。
基本的想法是這樣：
照 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 是 Amazon 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 的 Sting 與 ihower 邀請，到內湖用了兩個小時分享對於 Startup 公司在系統操作上的一些想法：
另外可以在 Facebook 上的活動頁 找到錄影。
一些關鍵字：
剛剛註冊了 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 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)。
幾個比較重要的特性：
前面兩個不會太意外，因為需要高速 I/O 的服務通常也都很需要用大量記憶體當作 cache 降低 I/O，也需要大量頻寬提供服務。用 SSD 也在預期的範圍內，不過提供的 SSD 空間居然這麼大...
當然，價位也不便宜，美東就要 USD$3.10/hour，冰島愛爾蘭則是 USD$3.41/hour (目前只有這兩區有提供)。如果以美東一個月 720hours 計算是 USD$2232，約台幣六萬六千多？
今天看到 t1.micro 也可以開 MySQL RDS 了：「Amazon RDS MySQL Now Starting at Just $19 a Month」。
拿來堆資料應該還不賴？只要 24 小時可以塞完一天的份，而且不會影響到 t1.micro 的 EBS I/O 就可以用？:p
續「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。