smokeping

168.95.1.1 與 168.95.192.1 對 CloudFront 的差異

tl;dr 版本：目前先用 PPPoE 發出來的 DNS resolver 設定，如果要自己設定的話，用 168.95.192.1 (主) + 168.95.1.1 (次) 然後關掉 round-robin 模式。

剛剛看 SmokePing 時發現的奇怪現象，同樣都是在 HiNet 下面的機器與 DNS resolver，但 CloudFront 會給出不同的機房提供服務。

講的更仔細的是，168.95.192.1 這組會給出 tpe 系列的機房，所以 latency 會比較低，但如果你用的是 168.95.1.1 的話，就會到處丟，包括日本的 nrt 系列，與香港的 hkg 系列。

這邊拿 d36cz9buwru1tt.cloudfront.net 這組網域觀察，這是 AWS 官網用的資源，從官網的 html 原始碼裡面可以看到。

以第四台網路上面的機器上面來看 (北都，我分配到的線路是走台灣智慧光網的線路)，可以看到這邊 latency 會飄：「d36cz9buwru1tt.cloudfront.net (CloudFront)」。

看了一下 DNS 設定，第四台的 ISP 給了兩組 DNS resolver 設定給分享器，分別是 168.95.1.1 與 8.8.8.8，然後分享器的 DNS resolver 是 round-robin，所以有時候會在台灣，有時候就連出國...

不過這組不能直接說是 AWS 的問題，因為 ISP 自己不架 DNS server，還跑去用 HiNet 的，有 sub-optimal 的問題也是很正常...

另外就是確認放在 HiNet 線路上的機器，這邊 ISP 透過 PPPoE 給了 168.95.192.1 與 168.95.1.1，但因為是直接進到 /etc/resolv.conf，所以只有在第一組爛掉的時候才會導去第二組 (預設值)，所以看起來就很穩：「d36cz9buwru1tt.cloudfront.net (CloudFront)」。

實際分析從 HiNet 去 168.95.1.1 與 168.95.192.1 查時，也可以看到類似的情況，像是用這樣的 command 去看 168.95.1.1 的情況：

( repeat 1000 host d36cz9buwru1tt.cloudfront.net 168.95.1.1 ) | grep 'has address' | awk '{print $NF}' | awk -F. '{print $1 "." $2 "." $3}' | sort -u | awk '{print $1 "." 1}' | xargs -n1 host | awk '{print $NF}'

可以看到給出來的點都是日本 (nrt 與 kix)：

server-13-225-178-1.nrt57.r.cloudfront.net.
server-143-204-74-1.nrt12.r.cloudfront.net.
server-18-65-171-1.nrt57.r.cloudfront.net.
server-18-65-99-1.kix50.r.cloudfront.net.
server-54-192-254-1.nrt51.r.cloudfront.net.
server-54-230-123-1.kix56.r.cloudfront.net.
server-99-84-55-1.nrt20.r.cloudfront.net.

如果改掃 168.95.192.1 的話：

( repeat 1000 host d36cz9buwru1tt.cloudfront.net 168.95.192.1 ) | grep 'has address' | awk '{print $NF}' | awk -F. '{print $1 "." $2 "." $3}' | sort -u | awk '{print $1 "." 1}' | xargs -n1 host | awk '{print $NF}'

就會完全在台灣機房：

server-13-35-163-1.tpe50.r.cloudfront.net.
server-13-35-36-1.tpe51.r.cloudfront.net.

用先前提到的「用 Akamai 提供的 akahelp 分析 DNS Resolver 的資訊」看起來 ECS 相關資訊都被拔掉了，但不確定關聯性是怎麼樣，但可以確定的是如果你設到 168.95.1.1 的話會是 sub-optimal experience...

有人吃飯工具用 CloudFront 的 (像是公司的服務)，而且手上有 bussiness support 或是 enterprise support 的，可以自己測過確認後去開 ticket 跟 AWS 看看怎麼弄，我這邊沒這些管道 XD

AWS 的 us-west-1 與 us-west-2 炸掉

AWS 又炸了，不過這次不是死在 us-east-1，在 Hacker News 上的討論「AWS appears to be down again」可以看一看...

話說回來，前幾天在「前幾天 AWS 的 us-east-1 出事報告」才提到可以放到 us-west-2，怎麼就炸了...

手上的 SmokePing 也可以看到一些資訊，像是 HiNet 到 dynamodb.us-west-1.amazonaws.com：

HiNet 到 dynamodb.us-west-2.amazonaws.com 的：

第四台 (APOL 線路) 到 dynamodb.us-west-1.amazonaws.com 的：

第四台 (APOL 線路) 到 dynamodb.us-west-2.amazonaws.com 的：

可以看出來從網路層就了出問題，再等幾天看 AWS 出報告吧...

看起來這個月 HiNet 連外大概會不怎麼順...

在 Twitter 上看到這則障礙資料：

因 APG 海纜障礙影響 HiNet 客戶連線美國、中國及香港部份網站之連線品質
🕓 2021-10-30~2021-11-30, 2021-10-30 10:00AM

2021 年 10 月 30 日發生 APG 海纜障礙，客戶連線美國、中國及香港部份網站可能造成部分連線有少許延遲現象。https://t.co/bBapFA47He

— HiNet 網站公告 (@HiNetNotify) October 30, 2021

APG (Asia Pacific Gateway) 在 2016 年啟用，還算是新的海纜，看起來會有不少頻寬受到影響... 這點在 HiNet 上用 SmokePing 監控對 dynamodb.ap-southeast-1.amazonaws.com 的 packet loss 就很明顯的可以看出來了：

連過去封包掉的亂七八糟的，然後公司做東南亞生意，操作起來苦哈哈... 不過其他 ISP 看起來還行，應該有機會先繞過去。

當 Daemon 死掉時自動重新跑起...

以前確保 daemon 掛掉時會重新跑起來大概有幾個方式，像是用 Monit 顧，然後再用 /etc/inittab 確保 Monit 不會掛掉...

在 systemd 的年代，因為 systemd 已經被保護起來，而重跑這個功能在 systemd 裡就有支援，不需要用 Monit 這類程式了。

在 manual 裡搜尋 restart 可以看到幾個參數：

Restart=
RestartForceExitStatus=
RestartPreventExitStatus=
RestartSec=

這次是遇到 SmokePing 的 FastCGI daemon 每隔幾天會自己死掉，導致 nginx 丟出 503 然後被 UptimeRobot 偵測到而拋出警告。

但這個問題只有在一台伺服器會發生，而 log 裡也沒翻到可以繼續 debug 的錯誤訊息，試著猜測一些情境去搜尋引擎找也沒翻到... 就決定先 workaround 來處理，然後就發現現在已經不太需要用 Monit 來處理這個問題了。

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

合併 RRD 資料的工具

昨天把跑在 Raspberry Pi 上的 SmokePing 資料改用統一版本 (我在 GitHub 上公開的 smokeping-config.d 這個)，但有些節點的 naming 改變了，所以會需要將資料整在一起。

在透過 Google 搜尋後，用的工具是「A very simple script to merge multiple RRD files, since none of those available seem to work.」這個，是一隻 Python 的程式。另外可以從程式碼裡面看到他使用了 rrdtool 這個 CLI 工具 (SmokePing 用了 RRD 格式儲存資料)，所以使用這隻程式前需要先安裝 rrdtool 這個套件：

$ sudo apt install rrdtool

接下來就是照說明來轉換。由於 rrdtool 這隻程式沒有對 filename 做特殊處理 (i.e. 把 - 當作 stdin)，所以會使用到 /dev/stdin 這種特殊方式來當作 input：

./simple-rrd-merge.py input-a.rrd input-b.rrd | rrdtool restore /dev/stdin output.rrd

當然，要記得先把 SmokePing 停掉再跑會比較好 XD

生出的 RRD 檔案再覆蓋回去 (我是先備份起來，以免有意外...)，然後再把 SmokePing 跑起來就可以了。

CloudFront 持續擴建：香港

Amazon CloudFront 在香港又增加機房了，這樣就是香港的第三個機房... 畢竟還是亞洲區頻寬成本相較起來比較低的地方 (也是很多東南亞國家會交換的地區)，有對應的需求就可以擴充：「Announcing Third Edge Location in Hong Kong for Amazon CloudFront」。

不過話說回來，台灣 PoP 其實主要還是卡中華的頻寬，像這樣三個圖可以理解為那個瞬間 HiNet 與 CloudFront 之間的頻寬滿了 (分別是從 HiNet、TFN、FET 去 ping AWS 官網自己用的 d36cz9buwru1tt.cloudfront.net，取自 smokeping.kkbox.com.tw 這邊)：