Home » Posts tagged "network"

Amazon EFS 開放東京區使用,提供 Provisioned Throughput

兩篇 Amazon EFS 的消息:「Amazon Elastic File System (Amazon EFS) Available in Asia Pacific (Tokyo) Region」、「Amazon EFS Now Supports Provisioned Throughput」。

ap-northeast-1 等很久的功能終於上線了,另外本來 EFS 對速度是有限制的,現在則是提供付費方案讓你可以確保效能... (採用 credit 架構,不過一般是夠用的... 空間在 1TB 以下可以 burst 到 100MB/sec,參考「Throughput Modes」這篇的說明)

這樣有蠻多架構可以花錢來解了...

在家裡 (???) 建立 HA 的網路環境...

Brad Fitzpatrick 在他家裡弄的 HA 架構,對一般人來說是有點誇張了 (看起來主要還是玩得開心),但對網路公司來說是個可以參考的方式,降低網路與設備故障帶來的業務衝擊... 先前在弄辦公室連外網路時也有弄過類似的架構,還蠻有趣的。

然後發現原來西雅圖的電這麼便宜,一度大約 NTD$3:

The whole setup including all APs and switches draws about 220 watts idle. Power is pretty cheap in Seattle. Washington State (as of April 2018) has the cheapest electricity in the United States, at $0.0974/kWh.

其他技術的東西反而是看看而已 XD

GCP 的 f1-micro 的使用心得...

這幾天在弄備援跳板機,不想弄在日本 (latency),所以就想到 Google Cloud Platform (GCP) 在台灣有機房,而 Compute Enginef1-micro,類似 AWSEC2 提供的 t2.nano 的機器。而這兩天玩了玩,大概有些事情值得記錄起來。

CPU 相關的部份:

  • EC2 的 t2 系列可以透過 API 或是在 web console 看到 CPU credit 剩下多少,GCE 沒找到在哪邊可以看。
  • EC2 的 t2 系列在 CPU credit 用完後是變慢運行,除非你打開 T2 Unlimited 同意 AWS 多收錢。而 GCE 的則是沒得選,相當於一定要開 T2 Unlimited。
  • GCE 的 f1-micro 是 0.2 vCPU,但我在上面跑 Ubuntu 18.04,平常沒事就已經是 15% 左右。這數字比預期的高不少,還在找是什麼原因...

網路相關的部份:

  • 因為要用台灣的機房,網路的部份只有 Premium 等級可以選 (Standard 等級目前只在美國有),也就是會先走 Google 佈建的網路再出去,所以流出的費用會隨著 destination 地區而有差異 (i.e. 封包送到美國與送到中國是不同計價)。
  • 但 Premium 等級實測品質真的很不一樣,到香港居然在 15ms 以下,以前在固網機房內沒看過這個數字...

其他的部份:

  • 硬碟空間方面,Standard provisioned space 比 EBSgp2 便宜不少,而且還包括了 i/o 費用 (AWS 會另外收費)
  • 連續使用就會有 discount 了,也可以 commit 買一年或是三年取得更深的 discount。而 AWS 則是得買 Reserved Instance 拿到 discount。

來看看一個月會有多少帳單產生吧...

HiNet 與 DigitalOcean、Linode、Vultr 的封包情況

先說結論,綜合網路與 CPU 的情況,我剛好跟下面提到的文章給出相反的選擇 (i.e. 完全不會選 DigitalOcean)。如果是需要 latency 低的品質我會選 Linode 的東京新機房 Tokyo 2,如果不需要 latency 的我會選 Vultr 的 USD$2.5/month 方案 (目前只在邁阿密與紐約有)。

看到「2018/06 台灣 5USD 虛擬主機網路延遲測試」這篇就來推廣一下 SmokePing 這個工具。這個工具可以做很多事情,但最常看到的用途還是做網路品質監控,先前在 K 社的時候就有個做個公開的站台可以看,後來接手的人也繼續維護著 (畢竟看這些圖有種治癒感?):「smokeping.kkbox.com.tw」。

不過 K 社的 SmokePing 裡面大多數是從固網機房端監控,而固網機房端的 Internet 品質一般來說都會比家用型的好很多,尤其是國際頻寬的部份。所以我也在我家裡用 PPPoE 版本的固定 IP 做了一份:「https://home.gslin.org/smokeping/」,這邊的設定檔放在 GitHub 上的 gslin/smokeping-config.d 上。

而我剛好有把這三家 VPS 的 SmokePing 都做起來:「SmokePing Latency Page for DigitalOcean」、「SmokePing Latency Page for Linode」、「SmokePing Latency Page for Vultr」。

我這邊看到的情況是這樣。以各家離台灣最近的點來看:

  • 第一張圖的 DigitalOcean 沒有東京的點,而新加坡的 latency 在這幾個月其實變差不少,現在大約要 90ms (扣掉光世代的 10ms)。
  • 第二跟第三張圖的 Linode (分別是 Tokyo 1 與 Tokyo 2) 其實可以看到新機房 Tokyo 2 的 latency 比舊機房 Tokyo 1 還好。
  • 第四張圖的 Vultr 則是狀況變化很多,但不管怎麼走,latency 大致上都還是比新加坡好。

另外第五張的 Vultr 則是紐約的點,latency 超高 (畢竟繞了半個地球),但 packet loss 不高,品質還算穩定。


speedtest-sgp1.digitalocean.com (DigitalOcean Singapore 1)


speedtest.tokyo.linode.com (Linode Tokyo)


speedtest.tokyo2.linode.com (Linode Tokyo 2)


hnd-jp-ping.vultr.com


nj-us-ping.vultr.com

另外是之前有痛到的部份,先前因為需求而需要在 PHP 5.6 上跑 WordPress,真的實際跑起來後發現超慢 (畢竟這兩個要快得想不少辦法),去找問題後發現 DigitalOcean 機器的 CPU 真的太慢,後來把這組需求搬去 Linode (在 CPU 與網路之間取個合理的平衡點)。

在各家 VPS 上用 Ubuntu 16.04 跑 openssl speed md5 可以看出一些資料:

DigitalOcean:

Doing md5 for 3s on 16 size blocks: 5465798 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 3761125 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 1835218 md5's in 2.99s
Doing md5 for 3s on 1024 size blocks: 582162 md5's in 2.96s
Doing md5 for 3s on 8192 size blocks: 102995 md5's in 2.97s
Doing md5 for 3s on 16384 size blocks: 47177 md5's in 2.99s

Linode:

Doing md5 for 3s on 16 size blocks: 11510700 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 8361353 md5's in 2.99s
Doing md5 for 3s on 256 size blocks: 3751929 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 1169457 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 157678 md5's in 2.99s
Doing md5 for 3s on 16384 size blocks: 78874 md5's in 3.00s

Vultr (這是 USD$2.5/month 的方案):

Doing md5 for 3s on 16 size blocks: 14929209 md5's in 2.97s
Doing md5 for 3s on 64 size blocks: 9479563 md5's in 2.97s
Doing md5 for 3s on 256 size blocks: 4237907 md5's in 2.98s
Doing md5 for 3s on 1024 size blocks: 1320548 md5's in 2.98s
Doing md5 for 3s on 8192 size blocks: 161940 md5's in 2.96s
Doing md5 for 3s on 16384 size blocks: 86592 md5's in 2.98s

然後補一個 AWS 的 t2.nano (在還有 CPU credit 可以全速跑的情況下),不過這不公平,參考用而已:

Doing md5 for 3s on 16 size blocks: 19257426 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 11168752 md5's in 2.99s
Doing md5 for 3s on 256 size blocks: 4959879 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 1518690 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 203910 md5's in 3.00s
Doing md5 for 3s on 16384 size blocks: 102321 md5's in 2.99s

Facebook 觀察 IPv6 的使用情況

Facebook 是在六年前啟用了 IPv6 服務,然後分析了現在各地區 IPv6 使用的情況:「How IPv6 deployment is growing in U.S. and other countries」,另外提供了統計系統的資料給大家查 (不過看起來只有二月以後的?):「Facebook IPv6」。

然後被提到台灣區的成長在這幾個月很快速,主要原因是中華電信的導入:

We are also seeing countries and regions with less mature internet infrastructure start to transition to IPv6. Although overall deployment is still low, recent growth in some places has been exponential. Taiwan, for example, has gone from less than 1 percent in February 2018 to more than 10 percent as of May 28, 2018. Taiwan's rapid growth directly corresponds to recent IPv6 initiatives by Chunghwa, Taiwan's largest ISP.

先前在 Twitter 上有提到中華在 www.ipv6.hinet.net 網站上的跑馬燈有公告關於 IPv6 的導入,所以到這個月月底,使用比率應該都還會有明顯的提昇:

因為 Windows 7 以上的系統直接 PPPoE 的應該都會拿到 IPv6 address,但如果是 IP 分享器的就不一定支援了,不然應該會更高...

另外行動網路的部份也陸陸續續在轉移了,像我的 blog 上可以看到有 emome-ip6.hinet.net 的訪客,而且 Google 搜尋也可以看到一些資訊了:「"emome-ip6.hinet.net" - Google 搜尋」。

CloudFront 在東京開到第八個點了...

看到 Amazon CloudFront 宣佈在東京開到第八個點了:「Amazon CloudFront launches eighth Edge location in Tokyo, Japan」。

Amazon CloudFront announces the addition of an eighth Edge location in Tokyo, Japan. The addition of another Edge location continues to expand CloudFront's capacity in the region, allowing us to serve increased volumes of web traffic.

這個成長速度有點驚人,一月才加了兩個,現在又要再加一個... 不過大阪還是維持一個。

Microsoft 啟用自己的 CDN 了...

在朋友的 tweet 裡看到微軟啟用自己的 Azure CDN 了,先前應該是提供 AkamaiEdgeCast 的服務:「Announcing Microsoft's own Content Delivery Network」。

看圖似乎是有台灣的點,不過我找不到可以測試 traceroute 的 endpoint,頁面上用的圖還是 EdgeCast 的啊 XDDD

;; ANSWER SECTION:
azurecomcdn.azureedge.net. 1604 IN      CNAME   azurecomcdn.ec.azureedge.net.
azurecomcdn.ec.azureedge.net. 3404 IN   CNAME   cs9.wpc.v0cdn.net.
cs9.wpc.v0cdn.net.      3404    IN      A       117.18.232.200

然後公測期間優惠價 50%:

Azure Content Delivery Network Standard from Verizon (S1) and Akamai (S2) and Microsoft (S3)*
*S3 is currently in public preview. CDN rates will be 50% of the stated price during this period.

Cloudflare 推出 Spectrum:65535 個 TCP Port 都可以轉的 Proxy...

Cloudflare 推出了 Spectrum,文章標題提到的 65533 應該是指 80 & 443 以外其他的 port:「Introducing Spectrum: Extending Cloudflare To 65,533 More Ports」。

然後因為 TCP proxy 不像 HTTP proxy 與 WebSocket proxy 可以靠 Host header 資訊判斷,在 TCP proxy 需要獨占 IP address 使用 (i.e. 一個 IP address 只能給一個客戶用),而因為 IPv4 address 不夠的關係,這個功能只開放給 Enterprise 客戶用:

Today we are introducing Spectrum, which brings Cloudflare’s security and acceleration to the whole spectrum of TCP ports and protocols for our Enterprise customers.

雖然現在限定在 Enterprise 客戶,但 Cloudflare 還是希望看看有沒有其他想法,目前提出來的選項包括了開放 IPv6 address 給所有人用,或是變成獨立付費項目:

Why just Enterprise? While HTTP can use the Host header to identify services, TCP relies on each service having a unique IP address in order to identify it. Since IPv4 addresses are endangered, it’s quite expensive for us to delegate an IP per application and we needed to limit use. We’re actively thinking about ways to bring Spectrum to everyone. One idea is to offer IPv6-only Spectrum to non-Enterprise customers. Another idea is let anyone use Spectrum but pay for the IPv4 address. We’re not sure yet, but if you prefer one to the other, feel free to comment and let us know.

類似的產品應該是 clean pipe 類的服務,但一般 clean pipe 是透過 routing 重導清洗流量,而非像 Cloudflare 這樣設計... 不知道後續會有什麼樣的變化。

Cloudflare 推出 Argo Tunnel

Cloudflare 推出了 Argo Tunnel,可以將內部網路與 Cloudflare 之間打通:「Argo Tunnel: A Private Link to the Public Internet」。

Cloudflare 在去年推出了 Wrap (可以參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」這篇),這次其實只是改名:

During the beta period, Argo Tunnel went under a different name: Warp. While we liked Warp as a name, as soon as we realized that it made sense to bundle Warp with Argo, we wanted it to be under the Argo product name. Plus, a tunnel is what the product is so it's more descriptive.

看起來沒有什麼新的玩意... 純粹改名字 :o

Archives