Tag: vultr

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

Vultr 開始要收台灣的稅了...

這幾天收到 Vultr 的通知信，要收 5% 的稅了：

Dear Valued Client,

Vultr.com will start collecting a Value Added Tax (also known as VAT) for services provided after 2018 June 01 in order to comply with new Taiwan regulations. Beginning on 2018 July 1, your invoices will include an additional tax charge of 5% for customers who purchase electronic services in Taiwan. The tax is applied to comply with new Taiwan VAT legislation requiring non-residents who are providing "remote services" to begin collecting Taiwanese VAT on these services when they are provided to Taiwanese residents or persons who are not registered for VAT.

Affected customers need to submit their VAT ID to Vultr. If you don’t provide a business VAT ID, your account charges might increase.

If you have any questions about this upcoming change, please contact our support team today. Thank you again for being a customer!

The Vultr.com Team

從 2018 七月開始收...

2FA 的 QR code 與 CanvasFingerprintBlock

在「Rasmus Lerdorf 關於 VPS 的介紹測試...」這篇的留言裡，Jimmy 提到 Vultr 是有 2FA 可以用的 (當初沒找到...)，於是就花了點時間設定...

但設定的過程中發現 TOTP 的 QR code 出不來，但在 dev console 裡面卻看得到 img 元素。

這種情況前幾個月在另外一個網站上也遇過 (當下拿 Firefox 測也不行)，於是就認為他們網站的問題，開了 support ticket 也沒回，一直沒下文的情況下就丟著。現在在 Vultr 上又遇到同樣的問題的話，看起來有可能是我的問題 (或是他們兩個站台都用同樣的 library)，於是就仔細點找...

找的過程中間發現有 canvas 元素，然後 canvas 元素有個 inline css 是 display: none;，先試著把這條拿掉，就出現了... 接下來就好猜了。

在 2014 年的「用 Canvas Fingerprint 取代部份 Cookie」這篇就有提過可以用 Canvas 追蹤使用者的問題，於是就有介紹了 CanvasFingerprintBlock 這個在 Google Chrome 上的套件，阻擋 Canvas 的存取。一關掉這個套件就正常了 XDDD

為了隱私問題，套件本身還是掛著，但當遇到發現有 QR code 出不來的時候就知道去 dev console 內改掉 XDDD

然後回到原來本來以為有問題的那個網站，也是一樣進 dev console 改掉後就看得到可以掃了... 看起來這兩個站可能是用一樣的 library？找出來再去戳這兩個站好了...