AWS 推出 Thin Client

AWS 推出自家的 Amazon WorkSpaces Thin Client:「New Amazon WorkSpaces Thin Client provides cost-effective, secure access to virtual desktops」。

好久沒聽到這個詞彙了,翻了英文版維基百科「Thin client」,在 History 那個部分可以看到以前的各種方案,現在在網路速度比起十年前快不少的前提下,AWS 這次用雲端的基礎建設與一個便當盒搭配起來。

不過... 還是有不少挑戰?

一個主要的問題還是費用,這個機子要將近 $195 或是 $280 (如果要接第二個螢幕需要多買一個 Hub),然後還有 $6/mo 的費用,以及 Amazon WorkSpaces 的費用:

Pricing – Devices are priced at $195, or $280 with an optional hub that allows you to use a second monitor. There’s a $6 per month fee to manage, maintain, and monitor each device, and you also pay for the underlying virtual desktop service.

隨便翻了一下 Amazon 上面的商品,用 N100 當關鍵字找機器,第一個結果就可以看到這台 $199 可以接兩個 4K/60Hz 的 HDMI 的便當盒:「Beelink Mini PC, Mini S12 Pro Intel 12th N100(4C/4T, Up to 3.4GHz), 16GB DDR4 500GB M.2 SSD, Mini Desktop Computer Support 4K@60HZ Dual HDMI Display/WiFi6/BT5.2/USB3.2/1000Mbps/LAN/WOL Micro PC」。

就算先把費用的部分放到一旁,如果管理成本有下降的話,應該也會是蠻多企業願意花錢的方向,但一般商用辦公室網路的穩定度應該會使得 Thin Client 的弊端遠大於利益?

目前看起來比較像是 AWS 內某個 BU 找主題試看看...?

Georgi Gerganov 給了在 AWS 上面用 GPU instance 跑 llama.cpp 的說明

Georgi Gerganov 寫了一篇怎麼在 AWS 上面用 GPU instance 跑 llama.cpp 的說明:「Using llama.cpp with AWS instances #4225」。

先跳到最後面的懶人套件,直接提供了 shell script 幫你弄完:

bash -c "$(curl -s https://ggml.ai/server-llm.sh)"

回到開頭的部分,機器的選擇上面,他選了一台最便宜的 4 vCPU + 16GB RAM + 16GB VRAM 的機器來跑。

然後他提到了 OpenHermes-2.5-Mistral-7B 這個模型最近很紅,也許有機會看一下:

We have just 16GB VRAM to work with, so we likely want to choose a 7B model. Lately, the OpenHermes-2.5-Mistral-7B model is getting some traction so let's go with it.

用 llama.cpp 裡面的 server 跑起 API server:

./server -m models/openhermes-7b-v2.5/ggml-model-q4_k.gguf --port 8888 --host 0.0.0.0 --ctx-size 10240 --parallel 4 -ngl 99 -n 512

接著就可以用 cURL 測試:

curl -s http://XXX.XXX.XXX.XXX:8888/v1/chat/completions \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer no-key" \
    -d '{
        "model": "gpt-3.5-turbo",
        "messages": [
            {
                "role": "system",
                "content": "You are ChatGPT, an AI assistant. Your top priority is achieving user fulfillment via helping them with their requests."
            },
            {
                "role": "user",
                "content": "Write a limerick about python exceptions"
            }
        ]
    }' | jq

都包好了...

Amazon EFS 漲價,再推出給更「冷」的資料儲存的空間:Amazon EFS Archive

Amazon EFS 這次推出的是再多推出一個 storage class:「Optimize your storage costs for rarely-accessed files with Amazon EFS Archive」。

先前應該是 2019 的時候推出了 IA:「Amazon EFS 的 IA Storage Class」,現在的 Archive 就是新的 storage class,儲存成本更便宜,但取用成本更高。

us-east-1 的價錢來看,可以到 Archive 的成本是 IA 的一半:

Standard (GB-Month)	$0.30
Infrequent Access (GB-Month)	$0.016
Archive (GB-Month)	$0.008
Backup - Warm / Cold (GB-Month)	$0.05 / $0.01

讀取成本則是 IA 的三倍:(這邊的 Tiering 指的是自動化的搬遷的服務)

All storage classes - Reads (per GB transferred)	$0.03
All storage classes - Writes (per GB transferred)	$0.06
Infrequent Access - Reads (incremental charge per GB transferred)	$0.01
Infrequent Access - Tiering (per GB transferred)*	$0.01
Archive - Reads (incremental charge per GB transferred)	$0.03
Archive - Tiering (per GB transferred)*	$0.03

基本上就是 Amazon S3 那套分級方法陸陸續續搬過來的感覺。

然後注意到這個「Regional (Multi-AZ) with Elastic Throughput」是新的計價方案,就算是 Standard storage class,I/O 是要算錢的。

在舊的方案「Regional (Multi-AZ) with legacy throughput modes」裡面,Standard 的 I/O 是不用額外付費,已經包在裡面,除非你直接購買 Provisioned (保證速度):

Standard (GB-Month)	$0.30
Infrequent Acces (GB-Month)	$0.025
Backup - Warm / Cold (GB-Month)	$0.05 / $0.01
Provisioned Throughput (MB/s-Month)	$6.00
Infrequent Access - Reads (per GB transferred)	$0.01
Infrequent Access - Tiering (per GB transferred)*	$0.01

翻了一下 Internet Archive 可以確認前幾天 2023/11/26 的 pricing 頁面還是舊的,也就是說這是這次推出來的改變:「Amazon EFS Pricing」。

看了一下目前 blog 上最近掛 Amazon EFS 類別的三篇都沒提到這件事情 (「New – Announcing Amazon EFS Elastic Throughput」、「Optimize your storage costs for rarely-accessed files with Amazon EFS Archive」以及「Replication failback and increased IOPS are new for Amazon EFS」),要用的人自己注意一下?

AWS 推出 32TB RAM 的機種 u7in-32tb.224xlarge

最近是 AWS re:Invent 2023,會有蠻多消息陸陸續續冒出來。

剛剛看到「Introducing Amazon EC2 high memory U7i Instances for large in-memory databases (preview)」這個,AWS 推出了 u7in-32tb.224xlarge,896 vCPU + 32TB RAM 的機器。

先前最大的應該是 u-24tb1.112xlarge,448 vCPU + 24TB RAM 的機器 (包括 vCPU 數量與記憶體大小),所以這次 vCPU 數量多一倍,記憶體多 50%。

很理所當然的又拿 SAP 來介紹了:

The new U7i instances are designed to support large, in-memory databases including SAP HANA, Oracle, and SQL Server.

比較特別的是 us-east-1 沒有在第一波的名單,反而是 us-west-2 以及其他的區域,不確定當初怎麼決定的:

Powered by custom fourth generation Intel Xeon Scalable Processors (Sapphire Rapids), the instances are now available in multiple AWS regions in preview form, in the US West (Oregon), Asia Pacific (Seoul), and Europe (Frankfurt) AWS Regions, as follows[.]

因為是 preview 階段,可能是這些區域有大客戶有需求,所以先佈到這幾區?

Gitea 推出了自己的 Cloud 版本:Gitea Cloud

Gitea 推出了 Gitea Cloud:「Gitea Cloud: A brand new platform for managed Gitea Instances」。

費用是 $19/user/mo 或是 $190/user/y,這個價位會對應到 GitHub 裡 Enterprise 等級的費用 ($21/user/mo 或是 $231/user/y)。GitLab 的話 Premium 的費用是 $348/user/y,高出不少...

依照官方的說明,看起來是 instance 直接拆開,所以也可以選擇 region:

Dedicated instances, full control in your hand:

Chose your cloud provider and region

這應該算是架構面上與其他兩家最大的差異了,走的應該是 multi-tenancy 的模式。但市場接受度不曉得如何...

用 bubblewrap (bwrap) 針對特定程式抽換 /etc/resolv.conf

我家裡的桌機有兩個有線網路,一個是 HiNet 光世代,另外一個是社區網路 (其實出去也是光世代),像是這篇提到的架構 (只是當時還住在後山埤,另外那條是北都的第四台網路):「Ubuntu 下面搞 Multi-home 架構」。

我在上面那篇提到要怎麼以 source ip address 來決定 routing,然後我就可以跑 Squid,並且在 Squid 上面指定 source ip 來達到目標。

後來有做了一些改變,最主要是換成 microsocks

一個原因個是 Squid 比較「重」(heavy),microsocks 比較清量;第二個是 Squid 走的 CONNECT 支援的程式比較少,SOCKS 支援度高一些。

不過當 HiNet 線路有問題的時候,會發現 DNS 的查詢失敗,主要的原因是 microsocks 會讀 /etc/resolv.conf 的資料,裡面是 168.95.192.1168.95.1.1,而且 microsocks 呼叫的 getaddrinfo() 沒有 IP binding,還是會試著走原來的線路出去。

所以這邊就得想辦法把 /etc/resolv.conf 換成我們自己加工的版本,這邊我用了 bubblewrap 來做:

/usr/bin/bwrap --unshare-all --share-net --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 --ro-bind ~/microsocks/resolv.conf /etc/resolv.conf /usr/sbin/microsocks -i 0.0.0.0 -p 11080 -b 192.168.2.123

先把所有東西都隔開 (--unshare-all),再把網路開通 (--share-net),接著把 /usr/lib 以及 /lib64 掛上來 (因為 microsocks 需要這些 library),然後 /etc 下的東西只掛了一個自己建的 /etc/resolv.conf 上來,裡面指到 router 上 (我的 router 有 DNS proxy):

nameserver 192.168.2.254

這邊因為是 subnet traffic,自動選定的 source ip 會是本機 192.168.2.x 的 IP,就剛好避開這個問題,這樣無論 HiNet 線路的情況都不會影響到 microsocks 了。

這邊有個小插曲,因為追問題所以用 strace 看了半天才發現一開始我用 bubblewrap 時是這樣寫:

/usr/bin/bwrap --bind / / --bind ~/microsocks/resolv.conf /etc/resolv.conf /usr/sbin/microsocks -i 0.0.0.0 -p 11080 -b 192.168.2.123

結果發現 microsocks 第一次讀 /etc/resolv.conf 的時候的確是讀到 ~/microsocks/resolv.conf,但網路斷掉後 (/etc/resolv.conf 會被改動) 他會讀到原始的 /etc/resolv.conf (i.e. 沒有被替換掉),判讀 strace log 到這邊的時候差點罵出來... @_@

沒有往下追的太細,但猜測可能是 --bind / /--bind ~/microsocks/resolv.conf /etc/resolv.conf 有處理上的衝突?總之我後來改成 --unshare-all,再把要掛的東西掛上去,就沒這個問題了...

Spotify 在 Google Play 上面不需要付 15% 的過路費

Google 的大頭在與 Epic 的訴訟案中被要求揭露了實際的數據:「A secret Google deal let Spotify completely bypass Android’s app store fees」。

如果是透過 Spotify 自家的金流平台,就完全不用付錢給 Google,如果是透過 Google 的平台則是 4%,遠低於一般上架商家的 15% (超過 $1M/y 的部分則會到 30%):

On the stand, Google head of global partnerships Don Harrison confirmed Spotify paid a 0 percent commission when users chose to buy subscriptions through Spotify’s own system. If the users picked Google as their payment processor, Spotify handed over 4 percent — dramatically less than Google’s more common 15 percent fee.

來看後續法院以及歐盟會怎麼出手?這應該會是蠻重要的證據資料...

微軟出手直接讓 Sam Altman 與 Greg Brockman 成立新團隊

不算太意外的一步,Satya Nadella (微軟的 CEO) 直接宣佈讓 Sam AltmanGreg Brockman 加入微軟,包含了其他的 team member,另外還特別講了一句會儘快提供需要的資源:

X (Twitter) 上的全文:

We remain committed to our partnership with OpenAI and have confidence in our product roadmap, our ability to continue to innovate with everything we announced at Microsoft Ignite, and in continuing to support our customers and partners. We look forward to getting to know Emmett Shear and OAI's new leadership team and working with them. And we’re extremely excited to share the news that Sam Altman and Greg Brockman, together with colleagues, will be joining Microsoft to lead a new advanced AI research team. We look forward to moving quickly to provide them with the resources needed for their success.

微軟與 Satya Nadella 在這次爆炸後,災難處理接近最完美的劇本了?

讓 Sam Altman 回去 OpenAI 大概不是好方案,很明顯已經有嫌隙了,尤其是直接被 Greg Brockman 點名過的 Ilya Sutskever

把 Sam Altman 與 Greg Brockman 放出去找 VC 開新的公司,不如還是讓直接微軟吃下來。

現在變成全部都還是在微軟的帝國裡面。

這個方法 Satya Nadella 完全可以對董事會交代,也能對微軟自家內部合作的團隊交代。

另外推文裡有提到 Emmett Shear 接手 Interim CEO,這樣看起來 Mira Murati 應該也是會過去 Sam Altman 那邊了。

後續應該就是看團隊元氣大傷後可以恢復多快了,少掉的 Ilya Sutskever 這塊要怎麼補?

PostgreSQL 的 Logical Replication 還有很多限制...

雖然之前提過很多次 PostgreSQL 的 logical replication,但最近總算是有空實際架設起來測試,發現目前的 logical replication 還在進化的過程,只能算是階段性的產品。

PostgreSQL 16 的「31.6. Restrictions」裡面有列出了目前 logical replication 的限制。

第一條其實是最痛的,不支援各種 DDL 操作,所以像是 CREATE TABLE 或是 ALTER TABLE 都不會同步,這牽扯到 DBOps 的動作需要配合,DB schema 的改變會變得很詭異,需要 case by case 處理,甚至 application 端可能也會需要配合。

The database schema and DDL commands are not replicated.

另外一個頭痛的點是 sequence 資料居然不會同步,這個工具常被用到 SERIAL 類的設計 (雖然 SERIAL 被 deprecated 了),這代表當偵測到 master 掛掉時無法直接 failover,除非有另外處理 sequence 的資料:

Sequence data is not replicated.

翻了資料發現官方 wiki 上有「Logical replication of DDLs」,裡面有今年六月的投影片:「Logical Replication of DDLs」,看起來 DDL 的部分有已經 patch 丟出來 (對 PostgreSQL 15 的 patch),但看了 PostgreSQL 16 的 release notes 裡面還沒看到,看起來還要等...

所以 logical replication 看起來還在演進的過程,目前的限制使得 logical replication 還不到能用的成熟度。

可以繼續觀察看看...

AWS 的 VPC 開放自訂 IPv6 CIDR 了,但還是有 4 的倍數的限制...

AWS 的公告,VPC 裡的 IPv6 可以自訂 CIDR 了:「VPCs and subnets now support more sizes for IPv6 CIDRs」。

不過還是有限制,首先是 VPC 的大小必須是 /44/60 中 4 的倍數,也就是只有 /44/48/52/56 以及 /60 這五個可以用,而 subnet 也有類似的限制,但從 /44/64,所以剛好就是多了 /64 可以用:

Amazon VPC allows customers to create VPCs and subnets of different sizes using IPv6 CIDRs. With this capability, customers can now create VPCs in sizes between /44 and /60, and subnets in sizes between /44 and /64, in increments of /4.

先前的限制是 VPC 只能給 /56 以及 subnet 只能給 /64 的搭配,是個「可以動」但總是覺得「...」的設計:

Before today, AWS supported one standard IPv6 CIDR block size of /56 for VPC and /64 for subnet, whereas IPv4 CIDR block size were flexible for both VPCs and subnets.

不過我實際在 ap-northeast-1 上測試,發現如果是 AWS 發的 IPv6 address,固定就是 /56 的大小,然後 subnet 在選擇的時候可以選 /56/60/64

這邊提到 VPC 可以選擇大小,應該是其他方式帶進來的 IPv6 address?

另外這次的 /4 的遞增限制,我猜是 AWS 裡面 SDN 上面的限制?IPv4 的 CIDR 有 33 個大小 (/0/32),IPv6 上面如果也處理 33 個的話,反過來設計剛好是 /4 遞增的 workaround?

不過話說回來,我記得前陣子 AWS 公佈要收 Public IPv4 address 的費用時 (參考「AWS 將開始收取 IPv4 的 Public IP 費用」),Hacker News 上有人抱怨還是有很多 AWS 的服務是 IPv4 only,在純 IPv6 network 上面是不太會動的;把這些服務的 IPv6 endpoint 生出來應該要趕快放到 roadmap 上...