原來 ISC 自己已經不用 ISC license 了

查資料的時候翻到「ISC Software Licenses」這頁,發現從 2015 年開始 ISC 就打算換掉原先的 ISC license,陸陸續續都轉移到 MPL 2.0...

在維基百科的頁面上可以看到一些說明,包括 KeaBINDISC DHCP 都已經換完了:

In 2015, ISC announced they would release their Kea DHCP Software under the Mozilla Public License 2.0, stating, "There is no longer a good reason for ISC to have its own license, separate from everything else". They also preferred a copyleft license, stating, "If a company uses our software but improves it, we really want those improvements to go back into the master source". Throughout the following years, they re-licensed all ISC-hosted software, including BIND in 2016 and ISC DHCP Server in 2017.

不過 INN 還是維持著 ISC license,應該是因為不算是 ISC 的正式產品?

AWS DataSync 支援 GCP 與 Azure 上的 Storage 上的資料了

AWS DataSync 宣佈支援 GCP 與 Azure 上的 Storage 了:「New for AWS DataSync – Move Data Between AWS and Other Public Locations」,比較特別的是,文章的 URL 有提到這兩家的產品,但在標題上反而就沒提到...

這測的重點就是支援 Google CloudMicrosoft Azure 的 object storage 產品:

Today, we added to DataSync the capability to migrate data between AWS Storage services and either Google Cloud Storage or Microsoft Azure Files.

之前大家都是自己開機器手動搬,現在可以直接付錢 (依照 GB 計費) 用服務搬了,不過要注意網路頻寬的流出部份還是有費用...

25Gbps 下 HTTPS 的效率

作者家裡拉了 25Gbps 的 Internet 後 (可以參考先前寫的「25Gbps 的家用 Internet」這篇),然後發現 Internet 上好像拉不動 25Gbps 的量,所以自己在家裡先測試了現在 HTTPS 的極限速度:「25 Gbit/s HTTP and HTTPS download speeds」。

Client 是 AMD 的 5600X,算是目前最新的世代;Server 則是 Intel 的 9900K,目前最新應該是 12 代;測試用 35GB 的檔案來測,然後使用 TCP BBR (這邊沒有特別講,目前 kernel 內建的還是 v1)。

在單條 HTTP 的情況下 curl + nginx 與 curl + caddy 都可以直接跑滿 (23.4Gbps),Gonet/http 會卡在 20Gbps 左右。

如果是多條 HTTP 的話都可以跑滿 23.4Gbps。

但到了 HTTPS 的情況下最快的是 Go + net/http,可以跑到 12Gbps;curl + nginx 剩下 8Gbps;接下來 curl + caddy 的部份只有 7.5Gbps,而 go + caddy 只有 7.2Gbps。

上到多條 HTTPS 的情況大家都可以跑滿 23.4Gbps,除了 go + caddy 只能跑到 21.6Gbps。

另外作者試著用 kTLS 把 TLS 的工作丟進 kernel,就不需要全部在 nginx 內處理,速度基本上沒有太大變化,主要是降低了 CPU loading:

In terms of download speeds, there is no difference with or without KTLS. But, enabling KTLS noticeably reduces CPU usage, from ≈10% to a steady 2%.

算是一個有趣的發現,如果目前的 HTTPS 想要在 25Gbps 上面單線直接跑滿,還需要再 tune 不少東西...

Amazon EC2 支援 NitroTPM 與 UEFI Secure Boot

也是在清 RSS reader 的時候翻到的公告,在兩個禮拜前 AWS 宣佈 Amazon EC2 支援 NitroTPMUEFI Secure Boot:「Amazon EC2 Now Supports NitroTPM and UEFI Secure Boot」。

NitroTPM 相容於 TPM 2.0 的界面,所以有支援 TPM 2.0 的軟體都可以利用 (像是 Windows 11):

Nitro Trusted Platform Module (NitroTPM) is a virtual device that is provided by the AWS Nitro System and conforms to the TPM 2.0 specification.

之前在研究 LUKS 的時候也有看到 TPM 相關的資料:

Linux Unified Key Setup (LUKS) or dm-verity on Linux are examples of OS-level applications that can leverage NitroTPM too.

然後支援的平台有些限制,只有 IntelAMD 的平台有支援,而且還要扣掉 Xen、Mac 以及 bare metal 的機種:

At the moment, we support all Intel and AMD instance types that supports UEFI boot mode. Graviton1, Graviton2, Xen-based, Mac, and bare-metal instances are not supported.

ARM 那邊有自己的一套,不太玩 TPM 大概可以理解,Xen 大概是不想支援 (停止開發新功能之類的原因),Mac 可能是 Apple 的硬體限制,最後的 bare metal 是因為沒辦法虛擬化?

然後這個功能不另外收費,看起來幾乎是全球性一次更新:

There is no additional cost for using NitroTPM. It is available today in all AWS Regions, including the AWS GovCloud (US) Regions, except in China.

GCP 推出 AlloyDB,一套相容 PostgreSQL 協定的資料庫服務

也是在清 RSS reader 的時候翻到的,看起來是在今年的 Google I/O 上發表的服務,AlloyDB:「AlloyDB for PostgreSQL under the hood: Intelligent, database-aware storage」,值得提的是這篇有中文版可以看:「適用於 PostgreSQL 的 AlloyDB 隆重登場:從此擺脫成本高昂的老舊資料庫」。

另外還有一篇比較偏 PR 的文章也可以看看:「Introducing AlloyDB for PostgreSQL: Free yourself from expensive, legacy databases」,這篇就比較針對的提到了與 AWS 的服務相比,但畢竟是 PR 稿沒有明講 (出事會比較好打模糊戰),但我猜測是與 Aurora 對比:

AlloyDB was also two times faster for transactional workloads than Amazon’s comparable service.

宣稱在 OLTP 上快了兩倍 (原來的三倍?),但應該都是以 PostgreSQL 下去改,猜測可能是底層的 storage 與 replication 比較好?

AlloyDB 設計上是考慮了 HTAP (Hybrid transactional/analytical processing) 的使用,所以同時可以提供 OLAP 與 OLTP 的應用:

[...] This makes AlloyDB a great fit for business intelligence, reporting, and hybrid transactional and analytical workloads (HTAP).

直接在一個資料庫內處理 OLAP 與 OLTP 這點的確會讓 AlloyDB 比 AWS 目前能提供的方案方便不少 (然後想一下 BigQuery 團隊...)。

目前在 AWS 對應的方案應該是透過 Redshift 來解決,另外一個方案是透過 Athena 來跑。

最後來看價錢,如果效能變成兩倍但價錢也是兩倍的話,就代表在價格上沒優勢。

先看機器的部份,如果是拿 Aurora 這邊 Intel-based 的 db.r5.24xlarge (96 vCPU + 768 GB RAM) 來算的話是 US$13.92/hr,而如果換算到 AlloyDB 的話是 US$14.94528/hr,相除是 0.9314,大約 7% 的差距,可以算是同一個級距。

如果 Aurora 這邊是拿 ARM-based 的 db.r6g.16xlarge (64 vCPU + 512 GB RAM) 來算的話是 US$8.306/hr,換算到 AlloyDB 的話是 US$9.96352/hr,相除是 0.8336,這邊就差超過 16% 了...

(這邊剛好回顧一下 "Amazon’s comparable service" 這段,不確定他是跟 Intel-based 比還是跟 ARM-based 比,畢竟 ARM 除了比較便宜外,還有效能的提昇)

但最大的差異應該是在 storage 相關的部份。其中 Aurora 這邊的空間與 I/O 是分開收費的,以 us-east-1 來說,storage 是 US$0.10/GB/mo,而 I/O 是 US$0.20/million-requests,在 AlloyDB 這邊來說,Regional cluster storage 是 US$0.0004109/GB/hr (us-east4),變成是 US$0.295848/GB/mo,兩邊相比後可以算出來對等的計價會是 AWS 的 storage 加上 AWS 給你 1.47M 的 I/O (per GB)。

這樣算起來把資料丟 S3 跑 Athena 可能不會比較貴... (當然效能是另外的主題了)

光就檯面上的資料來看,看起來是個不錯的東西,等後續有人跳進去用看看感想...

DigitalOcean 全面漲價

清 RSS reader 的時候才翻到的,DigitalOcean 宣佈漲價:「New DigitalOcean Pricing」,在 Hacker News 上有對另外一篇「公告」也有些討論:「New $4 Droplet and updated pricing」、「DigitalOcean: New $4 Droplet and updated pricing (digitalocean.com)」。

如果就比例來說,VPS 裡漲最多的就是一般性的產品線 Basic Droplets 這組,直接漲了 20%,其他的翻了一下舊的 pricing 頁面,看起來大多在 20% 以下,除了 IPv4 的費用 (這個倒是知道發生什麼事情)。

VPS 的 $5/mo 1GB 競爭算是很激烈的,算是頂標,這次 DigitalOcean 主動漲價,沒意外應該是會有不少人開始規劃搬家?接下來應該看看另外兩家的動作...

看了一下另外兩家最近的情況,Linode 在二月被 Akamai 買走之後目前主要是推出了 Managed Databases 這個服務,看起來速度慢下來不少。(不過 Linode 推新產品的速度本來就不快)

Vultr 還是照慣例丟了一堆東西出來,在新的據點開機房,以及一些產品線...

話說回來,查資料的時候發現 DigitalOcean 有 581 人 (2020/12),Linode 則是 200+,Vultr 則是 75 (2022,engineering only),看起來 DigitalOcean 的組織頗肥的啊...

HTTPS Everywhere 將在明年一月 (2023/01) 停止運作

在「Set Up HTTPS by Default in Your Browser」這頁看到的東西:

Note: HTTPS Everywhere will sunset in January 2023.

我把他 submit 到 Hacker News 上:「HTTPS Everywhere will sunset in January 2023 (eff.org)」,裡面有一些有趣的討論,像是這跟 Google 硬幹 Manifest v2 也有關:

It doesn't seem to be mentioned by the EFF, but coincidentally, January 2023 is when Manifest v2 extensions stop working in Google Chrome: https://developer.chrome.com/blog/mv2-transition/

但查了一下,目前好像沒有好的技術標準可以確保第一次的 HTTPS request。馬上想的到的是透過 DNS 的方式指定,這樣就可以透過 DNSSEC 保護不被竄改,但看起來沒有這個標準...

Starlink 推出 RV 版本

Starlink 推出了 RV 版本:「STARLINK FOR RVs」。

這塊市場看起來不賴,不是每個地區都有 4G network 可以用,但基本上沒有 4G network 的地區應該夠空曠可以收衛星訊號?看起來目前有 coverage 的地區都支援...

另外一個是 billing 的部份:

Starlink for RVs provides the ability to pause and un-pause service at any time and is billed in one-month increments, allowing users to customize their service to their individual travel needs.

不過本來好像就沒有綁約...

AWS 推出 c7g 機種

AWSAmazon EC2 產品線上推出了新一代的 ARM 產品,AWS Graviton3 架構,c7g 系列機種:「New – Amazon EC2 C7g Instances, Powered by AWS Graviton3 Processors」。

Graviton3 宣稱比 Graviton2 多 25% 的一般性效能,以及多了一倍的浮點效能,還有 DDR5 的頻寬優勢:

Our next generation, Graviton3 processors, deliver up to 25 percent higher performance, up to 2x higher floating-point performance, and 50 percent faster memory access based on leading-edge DDR5 memory technology compared with Graviton2 processors.

在「FreeBSD on the Graviton 3」這邊也可以看到一些效能數據 (雖然是跑在 FreeBSD 上),可以看到基本上符合 AWS 的宣稱。

目前只有 us-east-1us-west-2 有這個機種,不過 Graviton 系列一直都是 AWS 的強主打項目,其他區域應該很快就會看到:

C7g instances are initially available in US East (N. Virginia) and US West (Oregon) AWS Regions; other Regions will be added shortly after launch.

價位上比 c6g 貴了一些,在 us-east-1c7g.16xlarge (64 vCPU + 128 GB RAM) 是 US$2.32/hour,而 c6g.16xlarge 是 US$2.176/hour,大約貴了 6.6%,但如果是 CPU bounded 的應用來說,應該還是蠻划算的。

另外一方面是等後續的 m7gr7g 系列出現...

GitHub 可以在 Markdown 文件裡寫 TeX 語法了

Hacker News 首頁上看到 GitHub 上的「Render mathematical expressions in Markdown」這個公告:

You can now use LaTeX style syntax to render math expressions within Markdown inline (using $ delimiters) or in blocks (using $$ delimiters).

其中 TeX rendering 這塊是透過 MathJax 產生的:

GitHub's math rendering capability uses MathJax; an open source, JavaScript-based display engine.

我記得 MathJax 的效能好像不怎麼樣... 反正是跑在使用者端的 javascript?XD