Amazon EC2 的網路效能

前一篇「在 AWS 上面的 OpenVPN Server 效能」最後的問題就是 EC2 instance 本身的網路效能,畢竟是公司要用的,還是實際測一下數字,之後有人接手的時候也比較清楚是怎麼選這個大小的...

這邊拿的是 AWSap-southeast-1 (Singapore) 的 EC2 測試,直接在同一個 subnet 裡面開兩台一樣的機器跑 iperf 測試。

機器開機後會先跑這串指令 (除了安裝 iperf 的指令,其他的是出自我自己 wiki 上的 Ubuntu 這頁),然後再重開機:

sudo fallocate -l 512M /swapfile; sudo chmod 600 /swapfile; sudo mkswap /swapfile; sudo swapon /swapfile; echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab; echo -e "net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr" | sudo tee /etc/sysctl.d/99-tcp.conf; sudo sysctl -p /etc/sysctl.d/99-tcp.conf; sudo apt update; sudo apt dist-upgrade -y; sudo apt install -y apache2-utils apt-transport-https build-essential curl dnsutils dstat git jq locales moreutils most mtr-tiny net-tools p7zip-full pigz prometheus-node-exporter rsync sharutils software-properties-common sysstat unrar unzip vim-nox wget zsh zsh-syntax-highlighting zstd; sudo apt install -y iperf; sudo apt clean

接下來就是一台跑 iperf -s,另外一台跑 iperf -c 10.x.x.x -i 1 -t 3600 讓他跑一個小時看結果了。

我都有跑 tmux 再連到這些機器上,這樣可以捲回去看每一秒的傳輸速度,就可以看出來變化了,不過這邊還是簡單的只列出最高速度 (burstable) 與穩定輸出的速度 (baseline):

EC2 instance Baseline Burstable vCPU RAM Pricing (USD$)
c6g.medium 500Mbps 10Gbps 1 2GB 0.0392
c6g.large 750Mbps 5Gbps (claimed 10Gbps) 2 4GB 0.0784
c6g.xlarge 1.25Gbps 10Gbps 4 8GB 0.1568
t4g.small 125Mbps 5Gbps 2 2GB 0.0212
t4g.medium 255Mbps 5Gbps 2 4GB 0.0424
t4g.large 510Mbps 5Gbps 2 8GB 0.0848
t4g.xlarge 1Gbps 5Gbps 4 16GB 0.1696

這邊沒列出來的是 burstable 可以持續的時間,但這跟你機器吃的網路資源有關,我就決定只用 baseline 來做決策了,這樣可能會多花一點錢,但會少很多麻煩。

另外這次在處理的過程有被同事提醒各種 bandwidth overhead,所以就順便查了一下資料:

  • OpenVPN 本身的 overhead 大約是 5% (跑 UDP 的時候):「OpenVPN performance」。
  • SSH 也有些 overhead,大約是 6% (把來回的封包都算進去):「What is the overhead of SSH compared to telnet?」。
  • rsync 的部份鐵定也有 overhead,但這邊就沒找到現成的文章有統計過了。
  • 另外我自己之前做實驗發現 TCP BBR 的 retransmission algorithm 還蠻激進的,會有 10% packet loss,改用預設的 CUBIC 會好很多,大約 1% 到 2% 左右。

綜合這些測試,我自己抓了 35% 的 overhead 來推估,最後是用 c6g.large 來養 VPN server。750Mbps 的實際流量大約可以包進 550Mbps 的原始流量,大約是 68MB/sec。

不過新加坡與印尼之間的 internet bandwidth 好像還是不太夠,有時候深夜跑也跑不滿... 不過之後 VPN 上的 client 會愈來愈多,應該是不需要降...

在 AWS 上面的 OpenVPN Server 效能

這篇的後續可以參考「Amazon EC2 的網路效能」這篇。

最近在在調整跑在 Amazon EC2OpenVPN server 的效能,要想辦法把 network throughput 拉高,當作在導入 WireGuard 之前的 workaround,但看起來還是頗有用,記錄一下可以調整的部份...

在還沒灌大量流量前是用 t3a.nano (開 Unlimited mode),然後會觀察到的瓶頸是 OpenVPN 的 daemon 吃了 100% CPU loading,最高速度卡在 42MB/sec 左右。

第一個想到的是看看 OpenVPN server 有沒有可以使用多 CPU 的方式,但查了資料發現 OpenVPN server 無法使用 threading 或是 fork 之類的方法善用多顆 CPU,所以就開始想其他方法...

接著看到我們目前用的是 AES-256-CBC 了,網路上很多文章都有提到 AES-128-CBC 會快一些,但我們的 OpenVPN client 已經是設死都用 AES-256-CBC 了,這個就沒辦法了...

而第一個可行的解法是把 AMD-based 的 t3a.nano 換成 ARM-based 的 t4g.nano,還是 100% 的 CPU loading,但直接多了 50%+ 的效能,到了 69MB/sec。

第二個解法是找資料時發現的 fast-io 參數,加上去以後可以再快一些,到 77MB/sec。

有了這兩個 workaround 應該就堪用了,接下來是發現在傳大量資料跑一陣子後速度會掉下來,於是開了兩台 t4g.nanoiperf 對測了一下,發現會逐步掉速:

  • 前 15 秒可以直接到 5Gbps,就是 AWS 網頁上宣稱的最高速度,接下來降到 800Mbps 左右。
  • 到 180 秒左右後降到 300Mbps。
  • 到 210 秒左右後回到 800Mbps。
  • 到 300 秒左右後降到 500Mbps。
  • 到 300 秒左右後降到 300Mbps。
  • 到 1260 秒左右後降到 30Mbps,後面就一直維持這個速度了。

看起來 network bandwidth credit 是分階段的,但 30Mbps 真的有點低...

在換成四倍大的 t4g.small 測試後發現也只能到 40MB/sec 左右 (比較疑惑的是,居然不是四倍?),目前上了 c6g.medium,但看起來網路的部份也還是有瓶頸,在 46MB/sec 左右,要再想一下下一步要怎麼調整...

但以目前看到的情況總結,如果能用 ARM 架構就儘量用,效率與價錢真的是好 x86-64 不少...

AWS 宣佈 EC2-Classic 退役的計畫

AWS 宣佈了歷史悠久的 EC2-Classic 的退役計畫:「EC2-Classic is Retiring – Here’s How to Prepare」。

EC2-Classic 是 VPC 出來之前的產物,後來出現 VPC 的設計讓整個網路架構更有彈性,而且後來的新機種也都出在 VPC 上,EC2-Classic 算是歷史產物。

目前宣佈的幾個時間點,首先是 2013 年年底的帳號已經是 VPC-only,除非有另外開 support ticket 要求要有 EC2-Classic:

All AWS accounts created after December 4, 2013 are already VPC-only, unless EC2-Classic was enabled as a result of a support request.

接下來是今年的十月底,如果 AWS 帳號沒有使用 EC2-Classic 就會自動關閉 EC2-Classic 的權限,另外也會停止販售 EC2-Classic 的 RI:

On October 30, 2021 we will disable EC2-Classic in Regions for AWS accounts that have no active EC2-Classic resources in the Region, as listed below. We will also stop selling 1-year and 3-year Reserved Instances for EC2-Classic.

最後會希望在 2022 年八月中的時候全部轉移完:

On August 15, 2022 we expect all migrations to be complete, with no remaining EC2-Classic resources present in any AWS account.

看起來沒用完的 RI 會退錢?

Amazon VPC 允許直接把整個網段配到某台 EC2 Instance 上了

看到「Amazon Virtual Private Cloud (VPC) customers can now assign IP prefixes to their EC2 instances」這邊的消息,VPC 可以把整個網段配到某台 EC2 Instance 上了。

之前也有其他方法可以做到類似的事情:

  • 用 VPC 提供的 Routing Table 把網段指到某台 EC2 的機器上。
  • 把這台 EC2 機器的「Enable Source/Destination Check」關閉。

目前就是用這個方法搞定 VPN server 的:我們希望機器連上 VPN 後拿到 10.x.x.x 的 IP address,而且可以被 VPC 內直接存取,而不要被 NAT 掉。

好像該開張票轉移過去...

AWS 宣佈 EBS io2 的新花樣 Block Express Volumes

看到「AWS Announces General Availability of Amazon EBS io2 Block Express Volumes」這篇,在 EBSio2 上面又推出了新的花樣 Block Express Volumes:

Today AWS announced general availability of io2 Block Express volumes that deliver up to 4x higher throughput, IOPS, and capacity than io2 volumes, and are designed to deliver sub-millisecond latency and 99.999% durability.

要再提供更高的效能,在 R5b 的機種下,單個 volume 可以拉到 256k IOPS 與 4000MB/sec 的傳輸速度,以及在 well-tuned 的環境下 (應該是多個 volume) 可以拉到 260k IOPS (多一點點) 與 7500MB/sec (將近原來的兩倍) 的傳輸速度:

Using R5b instances customers can now provision a single io2 volume with up to 256,000 IOPS, 4000 MB/s of throughput, and storage capacity of 64 TiB.

R5b instances are well-suited to run business-critical and storage-intensive applications as they offer the highest EBS-optimized performance of up to 260,000 IOPS and 7,500 MB/s throughput.

是個用錢炸效能的東西,用的到的就用...

CloudFront 宣佈支援 ECDSA 的 Certificate

Amazon CloudFront 宣佈支援 ECDSA 的 certificate:「Amazon CloudFront now supports ECDSA certificates for HTTPS connections to viewers」。

用主要是讓 certificate 更小,讓 HTTPS 建立時的過程更快 (包括了傳輸的速度與計算的速度):

As a result, conducting TLS handshakes with ECDSA certificates requires less networking and computing resources making them a good option for IoT devices that have limited storage and processing capabilities.

很久以前好像有看到資料說 256 bits 的 EC 運算量跟 768~1024 bits 的 RSA 差不多,但一時間找不到資料...

目前 CloudFront 只支援 NIST P-256 (secp256r1,或稱作 prime256v1):

Starting today, you can use Elliptic Curve Digital Signature Algorithm (ECDSA) P256 certificates to negotiate HTTPS connections between your viewers and Amazon CloudFront.

但 NIST P-256 一直為人詬病,在「SafeCurves: choosing safe curves for elliptic-curve cryptography」這邊可以看到 NIST 宣稱的效率設計實際上都不是真的:

Subsequent research (and to some extent previous research) showed that essentially all of these efficiency-related decisions were suboptimal, that many of them actively damaged efficiency, and that some of them were bad for security.

但目前標準是往 NIST P-256、NIST P-384 與 NIST P-521 靠攏 (主要是受到 CA/Browser Forum 的限制),要其他 curve 的 certificate 也沒辦法生,目前可能還是繼續觀望...

在 netsplit 的統計上,Libera.Chat 已經超過 freenode 了

翻了一下「IRC Network Libera.Chat」與「IRC Network freenode」:

During last connections to Libera.Chat its servers reported an average of 40267 users and 19125 chat rooms. Use the following menu to get more information about IRC network Libera.Chat! Take a view to the generated statistics and search within the list of chat rooms for topics of your interest!

During last connections to freenode its servers reported an average of 26145 users and 23410 chat rooms. Use the following menu to get more information about IRC network freenode! Take a view to the generated statistics and search within the list of chat rooms for topics of your interest!

一陣子沒關注,發現已經甩開了...

用 Kroki 搞定 GitLab 上的 UML 圖

在「在自架 GitLab 使用 Kroki 來繪圖」這邊看到 Kroki,先把自己的 GitLab 接上去,整個流程還蠻簡單的...

Kroki uses a simple algorithm (deflate + base64) to encode your diagram in the URL:

GET /plantuml/svg/SyfFKj2rKt3CoKnELR1Io4ZDoSa70000

我跟 Heresy 用的方法不太一樣,是透過「Manual Install」這邊的方式裝,只要先把 .jar 檔抓下來放到對應的位置 (我是丟到 /usr/share/kroki/ 這邊),然後自己寫個 systemd 的 service 檔案放到 /lib/systemd/system/kroki.service 裡面:

#
[Unit]
Description=Kroki daemon
After=remote-fs.target

[Service]
ExecStart=/usr/bin/java -jar /usr/share/kroki/kroki-server-v0.13.0.jar
Restart=always
RestartSec=60
Type=simple

[Install]
WantedBy=multi-user.target

預設是 SECURE 模式 (參考「Configuration」這邊的說明),我就不加什麼特別的參數了,另外預設會跑在 port 8000,這邊會需要自己設定 nginx

然後讓 systemd 重讀設定再跑起來:

sudo systemctl daemon-reload
sudo systemctl enable kroki
sudo service kroki restart

目前跑的兩台機器都是 Ubuntu 18.04,內建的 JDK 都是 Java 8 的版本,不確定 Java 11 的環境如何。

Amazon Aurora PostgreSQL 多支援了一些 extension

Amazon Aurora PostgreSQL 多支援了一些 extension,剛好看到一些對我還蠻有用的東西。

第一個是 pg_cron,就如同名字所說的,可以拿來安排 cron job:「Amazon Aurora PostgreSQL supports pg_cron extension for scheduling database jobs」。

第二個是 pg_proctab,可以拿來看系統狀態,這在 Aurora 裡面算是沒有 shell 的替代方案:「Amazon Aurora PostgreSQL Supports the pg_proctab Extension to access PostgreSQL system stats」。

第三個是 pg_partman,可以對 serial id 切到不同的 partition:「Amazon Aurora PostgreSQL supports the pg_partman extension for managing time or serial id based table partitioning」。

這幾個在一定的量下應該都用的到...

Google Meet 可以走 443/tcp 了

Work from home 期間開會基本上就是幾個視訊軟體換來換去,Zoom 的話公司有買,自己開免費版的時候是 40mins 限制,另外 Slack 的畫面品質不怎麼樣,而 Google Meet 在疫情期間不限制時間,拿來聊天還蠻好用的。

看到「TLS support for Google Meet」這篇,文章裡面提到先前 Google Meet 是用 443/udp 跑 SRTP,這對很多公司的 firewall 需要另外開 (看到這個 UDP port 想到 QUIC 好像也是走這個 UDP port),在家裡的話應該還好,對於公司的電腦就會麻煩一些。

文章裡提到,這次支援了 TLS (over 443/tcp):

Some network setups do not work with SRTP over 443 which was preventing Meet calls from connecting. Meet now encapsulates SRTP in TLS which increases overall compatibility. This change will initially be available on the web, and will be available for mobile soon. We’ll announce it on the Google Workspace Updates blog when it’s available.

可以 fallback 回 443/tcp 走 TLS 的話穿透力應該就更好了,不過不知道免費版的有沒有也一起上,這邊只題到了 G Suite 系列會上:

Available to all Google Workspace customers, as well as G Suite Basic and Business customers

上次用 Google Meet 是在雲端聚餐聊天...