Tag: vultr

Vultr 開大阪機房

Vultr 宣布開大阪機房：「New Cloud Data Center Location: Osaka, Japan」。

本來的東京機房從 HiNet 過去會塞，可以看到每天都會有一段時間 latency 會飄起來：

從 HiNet 過去 Vultr 東京機房是走 PCCW 的線路：

從 Vultr 東京機房回來是走 NTT 的線路：

如果是 Vultr 大阪機房的話，先用 mtr 看了一下 latency，狀況似乎是好很多？好像可以考慮把東京的機器搬到大阪看看...

Vultr 更新流量計算方式

一時間沒找到在哪邊看到的，但的確是漏掉這個消息，早上看到去翻才注意到的... Vultr 在去年 11 月底宣佈更新流量的計算方式：「Vultr Announces Reduced Bandwidth Pricing, 2 TB of Free Monthly Egress, Free Ingress, and Global Pooling」。

這波費用的更新算是跟上另外兩家 (Linode 與 DigitalOcean) 的算法了，先前 Vultr 的算法就很古老 XD

第一個是 inbound traffic 不算錢了 (總算)：

Data ingress will now be free.

再來是 traffic pool 的概念，現在每個帳號的流量會統一計算，而非每台機器自己計算：

All customers will receive global account-level pooling of transfer across all instances and locations.

然後是每個帳號都提供 2TB 的 free outbound traffic，這點有點放送的感覺：

Every Vultr customer will now receive two terabytes (2 TB) of free outbound data transfer every month, in addition to the transfer included with each subscription.

最後是超量的部份收費也簡化了，不管什麼地區都是 $0.01/GB：

Vultr will now offer a reduced, single worldwide egress overage rate of only $0.01 per GB.

最後這點有個值得操作的點：依照他的收費標準，超量 1TB 的流量需要付 $10 的費用，但你可以多租一台 $5/mo 的機器，這個方式提供了 1TB 的流量到 traffic pool 裡面。

Vultr 可以帶自己的 IP 位置使用

Twitter 上看到 Vultr 可以帶自己的 IP 使用：

翻了一下發現是 2015 年就提供的功能：「Announce IP Space on the Cloud with Vultr」，而旁邊的 Linode 與 DigitalOcean 似乎都沒翻到...

在文件「Configuring BGP on Vultr」這邊可以看到需要先驗證 IP 是你的，算是業界常見的作法，跟當初申請 AWS 的 Direct Connect 類似的作法。

Vultr 也推出 Kubernetes 服務 (Beta)

看到 Vultr 也打算要推出 Kubernetes 這個產品線了：「Announcing Vultr Kubernetes Engine!」。

這樣加上之前的 Linode 的 Linode Kubernetes Engine (LKE) 與 DigitalOcean 的 DigitalOcean Kubernetes (「DigitalOcean 也推出 Kubernetes 的服務」)，比較知名的幾家 VPS 都推出 K8S 的產品線了。

對於不是 cloud provider 的 VPS provider 來說，直接拿 K8S 整合可以建了一組 mini-AWS 的架構出來，而且因為軟體還算紅，既有的 ecosystem 也可以直接拉進來，不需要另外重新學。不過因為 K8S 發展很快，還是可以常常看到各種踩雷抱怨文... XD

對於使用者來說，如果有一定的量與技術能力，加上想要省錢的話，用這些 VPS 提供的 K8S 服務看起來是個不錯的選擇。

應該找些時間更新之前自己摸索的那些東西了 (之前整理在「Kubernetes」這邊)，理解底層會怎麼弄的對於在分析問題時還是蠻重要的 (i.e. 通靈)，記得兩年前如果自己要弄 K8S master HA 還是 beta 功能...

架設 MTProxy 加快 Telegram 的速度

在台灣如果是透過 HiNet 連 Telegram 是沒什麼問題 (不需要翻牆)，不過連結的 preview 以及圖片影片讀取的速度實在很慢，試著在 GCP (彰濱機房) 跟 Vultr (東京機房) 上架 Proxy 測試看看，發現速度都改善很多...

這邊用的是官方提供的 MTProxy，我把安裝的懶人包放在自己的 wiki 上了：「MTProxy」，在 AWS 或是 GCP 上安裝時，因為網卡拿到的是 Private IP 而非對外的 Public IP，需要指定 --nat-info 告訴 MTProxy 要針對協定裡面的 IP address 另外處理。

跑一陣子再來看看有什麼可以調整的...

在 DHCP 的情境下強制指定 DNS servers

我在 Vultr 上的 Trac 自動開票程式有時候會爛掉，沒把票開出來，把 stderr 輸出到檔案後發現是找不到 hostname：

socket.gaierror: [Errno -3] Temporary failure in name resolution

看了看 /etc/resolv.conf 發現系統使用的 DNS server 設定是透過 DHCP 取得設定的。但 Vultr 只有提供一組 DNS server，當查不到東西時就爆掉了... 所以找了一下，看到「How to override the DHCP-provided nameserver?」這篇，但裡面是用「增加到前面的方式」，跟我想要改成只用 1.1.1.1 與 1.0.0.1 不太一樣。

知道目錄後拿關鍵字去 dhclient.conf 的 manpage 裡面找，就可以看到四種設定方式：

        default [ option declaration ] ;
        supersede [ option declaration ] ;
        prepend [ option declaration ] ;
        append [ option declaration ] ;

這四組看名字就大概知道用途了。接下來就是把對應的 interface 查出來以後，用 supersede 就搞定了：

    supersede domain-name-servers 1.1.1.1, 1.0.0.1;

重開機測試可以確認 /etc/resolv.conf 的內容改變了。接下來再來觀察看看還會不會有狀況...

Vultr 推出 $3.5/m 的方案

在 Twitter 上看到 Vultr 推出了 USD$3.5/month 的方案：

這規格與價錢明顯就是對 Amazon Lightsail 的新方案反應...

最早的時候 Vultr 提供了 USD$2.5/month 的類似方案，但後來限制到只有紐約與邁阿密有，最近則是限制到只有 IPv6 address 沒有 IPv4 address (會需要靠 Cloudflare 這類服務幫忙 proxy)，而且限制只能開兩台。

這次推出的方案跟 USD$2.5/month 的規格一樣，不過是有 IPv4 address，所以多了 USD$1/month。

Amazon Lightsail 試用兩天的心得...

前幾天在「Amazon Lightsail 降價...」這篇文章提到了 Lightsail 這波降價還蠻有競爭力的，但之前看過「Is the fact that Lightsail instances are just renamed T2 instances that run on CPU credits actually documented anywhere?」這篇，大概知道 Lightsail 後面其實就是 t2 系列的機器，只是在這次 t3 出來後的改版不知道有沒有順便一起改...

前幾天直接把 blog + wiki 整個搬過去看看。本來在 Vultr 的主機是 1GB RAM，就挑了對應的方案搬過去... 如果還是 t2 的話，應該就會是 t2.micro 的機器。

由於搬家前面一天都在弄各種環境，所以應該累積了不少 CPU credit，實際的情況還是要等 DNS 指過來超過一天後才會知道。在剛剛跑了一整天，把 CPU credit 吃差不多後確認了，應該還是 t2.micro，baseline 在 10% (被降速了)：

這樣的話就維持在 Vultr 好了... CPU 資源看起來還是用超過了。

Vultr 又開放 USD$2.5/month 的機器了，限制 IPv6 only...

今天被提到說 Vultr 開放 USD$2.5/month 的機器又開放了，但是限制 IPv6 only：

對於網站來說，可以在前面擋個 Cloudflare 之類的服務當作 IPv4 proxy 來解，應該是還不錯...

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