AWS 將新的 Nitro 架構回過投來支援以前 Xen 的機種

Twitter 上看到 Jeff Barr 提到的這篇,講 AWS 決定讓新的 Nitro 架構支援舊的 Xen 機種:

原文是「Xen-on-Nitro: AWS Nitro for Legacy Instances」這篇,裡面雖然很美化的在講這件事情,但提到了幾個很現實的問題,第一個是仍然有大量使用者 (120 萬) 在用 Xen 架構的機器:

Today, we still have over 1.2 Million unique customers using Xen-based instances.

但這些機器其實愈來愈難維護,一方面是 Nitro 讓 AWS 省下很多軟體上的維護,另外一方面是幾乎不會有新的使用者用這些舊機種,在採購上面也會是問題。

However, the underlying hardware is old and it’s getting increasingly difficult to maintain support for these older hypervisor systems.

所以 EC2 的團隊把 Nitro 的 Xen 相容架構給實做出來,從 2022 年開始就可以全部都用 Nitro 系統,這樣對 EC2 團隊的維護成本就會大幅下降:

All of these innovations enable us to continue to offer many of our older instance types well past the lifetime of the original hardware. Starting in 2022, customers launching M1, M2, M3, C1, C3, R3, I2 and T1 instances will land on Nitro supported instances hardware and existing running instances will also be migrated.

技術債沒辦法消失,就用這種方式降低維護成本耗 XD

AWS 要推出 Graviton3 的機種了

AWS 打算要推出 Graviton3 的機種了,目前還在 preview 階段:「Join the Preview – Amazon EC2 C7g Instances Powered by New AWS Graviton3 Processors」。

目前是宣稱與前一代的 Graviton2 相比有 25% 的效能提昇,另外在浮點數與密碼相關的運算上面也會有改善 (這個效能提昇的數字應該是有指令集的幫助):

In comparison to the Graviton2, the Graviton3 will deliver up to 25% more compute performance and up to twice as much floating point & cryptographic performance. On the machine learning side, Graviton3 includes support for bfloat16 data and will be able to deliver up to 3x better performance.

另外提到了 signed pointer,可以避免 stack 被搞,不過這邊需要 OS 與 compiler 的支援,算是針對 stack 類的攻擊提出的防禦方案:

Graviton3 processors also include a new pointer authentication feature that is designed to improve security. Before return addresses are pushed on to the stack, they are first signed with a secret key and additional context information, including the current value of the stack pointer. When the signed addresses are popped off the stack, they are validated before being used. An exception is raised if the address is not valid, thereby blocking attacks that work by overwriting the stack contents with the address of harmful code. We are working with operating system and compiler developers to add additional support for this feature, so please get in touch if this is of interest to you.

然後是使用 DDR5 的記憶體:

C7g instances will be available in multiple sizes (including bare metal), and are the first in the cloud industry to be equipped with DDR5 memory. In addition to drawing less power, this memory delivers 50% higher bandwidth than the DDR4 memory used in the current generation of EC2 instances.

現在還沒看到價錢,不過有可能是跟 c6g 一樣的價位?但考慮到記憶體換架構,也有可能是貴一些的?

另外翻了一下資料,ARM 有發表過新聞稿提到 Graviton2 是 ARM 的 Cortex-M55 機種:「Designing Arm Cortex-M55 CPU on Arm Neoverse powered AWS Graviton2 Processors」,這次的 Graviton3 應該在之後完整公開後會有更多消息出來...

Amazon VPC 支援純 IPv6 的網段了

Amazon VPC 支援純 IPv6 的網段了:「Amazon Virtual Private Cloud (VPC) customers can now create IPv6-only subnets and EC2 instances」。

先前機器都還是要設一個 IPv4 位置,所以網段都必須有 IPv4 network space,這次推出使得機器可以跑在 IPv6-only network 上了,不過 Linux 裡面應該還是會有個 lo127.0.0.1...

短時間應該用不到,不過可以先玩看看感覺一下...

Auto Scaling 就不能綁個 Lambda 嗎...

看到 AWS 宣佈 Amazon EC2 的 auto scaling 有新花樣:「New – Attribute-Based Instance Type Selection for EC2 Auto Scaling and EC2 Fleet」。

你都有 Lambda 了,就不能整合 Lambda 每分鐘跑一次,讓使用者直接用個 turing complete 的方式自己設計要的 policy 嗎... 會用到 auto scaling 的使用者不會在意 Lambda 的那幾毛錢的。

這樣做對 OKR 是比較好沒錯啦,但用的人已經懶的看了...

在 AWS Summit Taiwan 2021 上講的 HashiCorp Vault

今年的 AWS Summit Taiwan 2021 是線上的形式,早在前一個月前就先預錄好,但開始的時候就忘記要宣傳一下了... 結果是在找資料的時候發現其他人有提到:「AWS實作紀錄 #2:高可用性保管服務 (2021 AWS Summit Taiwan)」。

投影片與影片如果有興趣的人可以去 AWS 活動頁面上看,或者上面提到的那篇。

這次講的主題是想要在雲端上面搭建 Vault,但又不希望自己搞一堆 High Availability 的架構,最好是雲端服務本身就有提供... 而既然是在 AWS 的場子,主要都還是以 AWS 的服務來搭建。

在這次的設計裡,Vault 的資料是放在 DynamoDB 上,然後透過 KMS 管理加密用的,這兩個服務本身都有 High Availability,所以直接用就可以了。

接下來是跑 Vault 程式的部份,這部份得自己處理 High Availability 的架構,我是用兩台很小台的 EC2 instance (t4g.nano) 在跑,這邊也可以換成 ECS 或是 EKS 的 container。

接下來把這兩台 EC2 instance 掛起來的也都是 High Availability 服務:在 EC2 instance 前面用 ELB 擋住提供 HTTP API 服務,另外這邊即使是內部用,也可以上 HTTPS (透過 ACM 掛上 HTTPS 的憑證)。

在 ELB 上看到只有一台機器活著是正常的,因為兩台機器之間是 active-standby 架構,同時間只會有一台機器在運作,而 lock 的機制是 Vault 透過 DynamoDB 實做的,不需要另外處理。

其實裡面大多數的元件都可以抽換,像是 DynamoDB 也可以用其他的服務來當儲存層,馬上可以想到的是 RDSMySQL 或是 PostgreSQL

概念上不算困難,所以投影片上主要就是給設定檔,這樣方便大家抄,不用在自己摸指令摸半天...

Amazon EC2 推出 VT1 Instance

看到 Amazon EC2 推出新機種 vt1,專門為影片壓縮而推出的 family type:「New – Amazon EC2 VT1 Instances for Live Multi-stream Video Transcoding」。

主要是透過 Alveo U30 Data Center Accelerator Card 這張卡加速,號稱比 GPU 機器還要省 30% 的費用 (CPU 的話可以到 60%):

These VT1 instances feature Xilinx® Alveo™ U30 media accelerator transcoding cards with accelerated H.264/AVC and H.265/HEVC codecs and provide up to 30% better price per stream compared to the latest GPU-based EC2 instances and up to 60% better price per stream compared to the latest CPU-based EC2 instances.

看規格支援 H.264H.265,不過看起來沒支援 royalty-free 的 VP9AV1...

另外這跟 AWS Elemental MediaConvert 以及 AWS Elemental Live 好像稍微有點打對台?另外專利的費用不知道怎麼算...

Amazon EC2 上的一些小常識

Twitter 上看到 Laravel News 轉發了「Mistakes I've Made in AWS」這篇,講 Amazon EC2 上面的一些小常識。

在 EC2 中,T 系列的機器 (目前主要是 t2/t3/t3a/t4g) 對於開發很好用,甚至對於量還不大的 production system 也很好用,加上 Unlimited 模式可以讓你在 CPU credit 用完時付錢繼續 burst。

文章裡面有討論到,使用 T 系列機器時,常常是不怎麼需要大量 CPU 資源的情境,這時候 AMD-based 的 t3a 通常都是個還不錯的選擇,大概會比 Intel-based 的 t3 省 10% 的費用。另外如果可以接受 ARM-based 的話,t4g 也是個選項,價錢會更便宜而且在很多應用下速度會更快。不過同事有遇到 Python 上面跑起來的行為跟 x86-64-based 的不同,這點就得自己琢磨了...

另外就是目前的 EBS 預設還是會使用 gp2,而在 gp3 出來後其實大多數的情況下應該可以換過去,主要就是便宜了 20%,加上固定的 3000 IOPS。

不過也是有些情境下是不應該換的,主要是 gp2 可以 burst 到 250MB/sec,但 gp3 只給了 125MB/sec。雖然 gp3 可以加價買 throughput,但加價的費用不低,這種需求改用 gp2 應該會比較划算。

不過這邊推薦比較技術的作法,可以掛兩個 gp3 (也可以更多) 跑 RAID0 (像是在 Linux 上可以透過 mdadm 操作),這樣 IOPS 與 throughput 都應該可以拉上來...

Amazon EC2 推出 m6i 的機器

AWS 給了公告,在 Amazon EC2 上面推出了 m6iIntel-based 新機種:「New – Amazon EC2 M6i Instances Powered by the Latest-Generation Intel Xeon Scalable Processors」。

這好像是第一次看到 Intel-based 機種加上了 i 的 suffix...

這次比較大的兩個差異,與 m5 相比,多出了 m6i.32xlarge

A larger instance size (m6i.32xlarge) with 128 vCPUs and 512 GiB of memory that makes it easier and more cost-efficient to consolidate workloads and scale up applications.

另外看了一下 us-east-1 上的單價,看起來與 m5 系列的機器價錢一樣,但是效能提昇了 15% (然後很假掰的寫了 price/performance?):

Up to 15% improvement in compute price/performance.

單以數字看起來的話還是 m6g 系列會比較香?當然如果只有 x86-64 binary 的話看起來還是可以考慮換到 m6i 上跑...

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 會愈來愈多,應該是不需要降...