storage

gp3 (Amazon EBS) 的 latency

昨天把手上所有的 Amazon EBS 從 gp2 換到 gp3 了：「Amazon EBS 的 gp3 可以用在開機磁碟了」，今天早上來看一下狀態，整體看起來是還 OK，不過有些地方值得注意的，像是標題寫到的 latency。

我抓了跑 GitLab 的機器來看，可以很明顯看到讀寫的 latency 都變高了：

但 AWS 又有提到這些數字資料有經過轉換，看起來是 gp2 與 gp3 的數字意義本來就不一樣，所以他必須想辦法轉換，所以也有可能是因為這個轉換導致的？

This graph has had transformations applied to it and will differ from what is natively found in CloudWatch. Due to this some functionality is reduced.

不過其他的數字倒是沒什麼變化，系統的負荷量其實也還好，就先丟著跑...

Amazon EBS 的 gp3 可以用在開機磁碟了

可以先參考「Amazon EBS 推出了 gp3」這篇，但剛出來的時候大家都有發現無論是透過 web console 還是透過 awscli，boot disk 都沒辦法改成 gp3，可是在官方的文件上又說可以用 gp3，所以就有人在 AWS 的 forum 上發問了：「EBS GP3 Boot Volume Issues」。

直到剛剛發現已經可以改成 gp3 了... 一個一個手動改當然也是 OK，但對於有一卡車 EBS 要換的人來說鐵定得弄指令來換，這邊搭配了 jq 一起改：

aws ec2 describe-volumes | jq '.Volumes[] | select(.VolumeType == "gp2") | .VolumeId' | xargs -n1 -P4 env aws ec2 modify-volume --volume-type gp3 --volume-id

這邊是把 gp2 都改成 gp3，沒有考慮到空間大小的問題 (因為超過 1TB 時 gp2 給的 IOPS 會比較多)，另外 -P4 是平行四個 process 跑，改起來會快一些...

Amazon EC2 的新機種：R5b、D3 (D3en)、C6gn、M5zn、G4ad

Amazon EC2 除了昨天放出 Mac mini 消息打頭陣以外，其他機種的更新消息也陸陸續續公佈了：

比較有趣的 (對我而言)，第一個是 ARM 架構的機器也推出 100Gbps 的 n 版本 c6gn，看起來很適合跑大流量的東西，馬上想到的就是自架的 memcached？

另外是 m5zn，使用高頻率的 Intel Xeon，主打需要單核效率的程式，不過這是掛在 m 系列下，而不是 c 系列...

再來是使用 AMD GPU 的 g4ad，官方宣稱跟 NVIDIA 的 g4dn 比起來，將會有 45% 的 C/P 值提昇，是個蘇媽跟老黃的對決：

However, when compared to G4dn the new G4ad instances enable up to 45% better price performance for graphics-intensive workloads, including the aforementioned game streaming, remote graphics workstations, and rendering scenarios. Compared to an equally-sized G4dn instance, G4ad instances offer up to 40% improvement in performance.

看起來 ARM 的消息沒有想像中的多...

Amazon EBS 的 io2 給了不少新消息...

Amazon EBS 的另外一個新推出的東西，是針對 io2 的改善：

前面兩則消息可以一起看，主要是推出了 EBS Block Express，有著效能上的提昇：

Built on our new EBS Block Express architecture that takes advantage of some advanced communication protocols implemented as part of the AWS Nitro System, the volumes will give you up to 256K IOPS & 4000 MBps of throughput and a maximum volume size of 64 TiB, all with sub-millisecond, low-variance I/O latency. Throughput scales proportionally at 0.256 MB/second per provisioned IOPS, up to a maximum of 4000 MBps per volume. You can provision 1000 IOPS per GiB of storage, twice as many as before. The increased volume size & higher throughput means that you will no longer need to stripe multiple EBS volumes together, reducing complexity and management overhead.

目前因為是 preview 階段，想要用的人需要申請測試。要注意目前支援的區域有限 (不像這次推出 gp3 的時候就是全區)，而且需要搭配 r5b 的機器：

The preview is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Europe (Frankfurt) Regions. During the preview, we support the use of R5b instances, with support for other Nitro-powered instances in the works.

第三則消息則是在講 io2 的 IOPS 的折扣，針對購買 32K IOPS 以上的部份會有 30% 折扣：

Now, with the new tiered pricing structure, the first 32,000 IOPS provisioned on a volume are charged at the current base rate ($0.065 per provisioned IOPS-mo) and the second tier between 32,001 and 64,000 is charged at a 30% lower rate ($0.046 per provisioned IOPS-mo).

針對前面提到的 preview 版本 (EBS Block Express)，因為可以超過 64K IOPS，這個部份的價錢會更低，再疊一次 30% 的折扣：

Furthermore, for customers who have even higher performance requirement than currently supported by a single io2 volume today, we are previewing io2 volumes that run on EBS Block Express, the next generation of our block storage architecture. io2 Block Express volumes can be provisioned to deliver peak IOPS of 256,000. For these volume, any IOPS provisioned over 64,000 IOPS will be charged at a further 30% lower rate than the second tier ($0.032 per provisioned IOP-mo for IOPS over 64,000). This lowers the effective rate to $0.038 per provisioned IOPS on a volume provisioned with 256,000 IOPS.

算是要衝效能的人用的，目前平常應該還是會用 gp2 或是 gp3 的 SSD...

Amazon EBS 推出了 gp3

今年的 AWS re:Invent 又開始了，不過因為疫情的關係，這次是線上為主... 這邊先來整理一下 Amazon EBS 相關的更新。

首先是推出了新的 gp3 類型，也是 SSD 類：「New – Amazon EBS gp3 Volume Lets You Provision Performance Apart From Capacity」。

每 GB 單位成本比 gp2 低 20%：

Today I would like to tell you about gp3, a new type of SSD EBS volume that lets you provision performance independent of storage capacity, and offers a 20% lower price than existing gp2 volume types.

然後直接給你 3000 IOPS 與 125MB/sec，有需要更高的話可以「加購」：

gp3 is designed to provide predictable 3,000 IOPS baseline performance and 125 MiB/s regardless of volume size. It is ideal for applications that require high performance at a low cost such as MySQL, Cassandra, virtual desktops and Hadoop analytics. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MiB/s for an additional fee. The top performance of gp3 is 4 times faster than max throughput of gp2 volumes.

但照「Amazon EBS volume types」這邊的列表可以看到，要注意 gp2 可以 burst 的 throughput (250MB/sec) 比 gp3 的 baseline (125MB/sec) 高。

也因為這樣，可以把一些 random access 比較多的 /data 這類的 EBS 換過去，但如果是要大量 sequential access 的也許就不適合了。

IOPS 的部份，1TB 以下的 gp2 換過去應該是沒什麼太大問題，因為在 gp2 的時候是 1GB 給 3IOPS，所以 1TB 以下的 gp2 都低於 3000IOPS。

轉移的部份可以在 AWS 的 console 上直接 migrate 到 gp3：

If you’re currently using gp2, you can easily migrate your EBS volumes to gp3 using Amazon EBS Elastic Volumes, an existing feature of Amazon EBS. Elastic Volumes allows you to modify the volume type, IOPS, and throughput of your existing EBS volumes without interrupting your Amazon EC2 instances.

像是這樣：

但照「Amazon EBS volume types」這邊的列表，~~gp3 可以是開機硬碟~~，但是改不過去啊 XDDD

Update：剛剛發現文件被修正了，看起來不能當開機硬碟...

不知道哪邊搞錯了，過幾天看看吧 XDDD

AWS 推出了 Amazon S3 Storage Lens 可以看 S3 使用的概況

AWS 推出了 Amazon S3 Storage Lens，可以看 S3 使用的概況：「Introducing Amazon S3 Storage Lens – Organization-wide Visibility Into Object Storage」。

要使用者個功能需要授權 Amazon S3 Storage Lens 一些權限，照著說明去 IAM 開就可以了，開好後要等他一陣子，他需要去分析記錄才能產出 dashboard。

有免費版與付費版可以用，付費版的部份目前看到都是「$0.20 per million objects monitored per month」，但沒把所有的區域都翻完，所以不確定。

我自己看了一下免費版提供的預設 dashboard，就已經給出不少好用的資訊了，像是 30 天內的物件數與空間使用率變化，可以抓到一些成長數量的感覺。

可以建議至少免費版的部份就先開起來丟著...

ZFS 租用服務

看到「zfs.rent」這個網站：

We have a couple of ZFS-based NAS systems. We wanted a simple cloud service so we could run:

$ zfs send -v -R -I pool/snapshot_034 pool/snapshot_042 |\
    ssh marvin@marvin.zfs.rent zfs recv -v -Fu pool/snapshots

看起來是用 Linux 上的 OpenZFS 架的，每個 instance 提供 4GB RAM，這個部份應該還好，但只提供 1TB 的流量 (上傳與下載都要算)，這部份看起來就有點不太夠用了，以這種服務來說蠻容易踩到 overcharge 的部份。

作業系統的部份可以選擇 Ubuntu 20.04 或是 CentOS 8.2。

以架構上來說可以當作是某種特化的 VPS (底層的 raw disk 直接掛上來)，以這個角度來看的話，機器部份的費用看起來還好，但頻寬部份會拉高整體成本。

這個服務看起來比較像是噱頭吧，看看就好...

Amazon EBS 的 Cold HDD (sc1) 降價 40%

剛剛看到 Amazon EBS 的 Cold HDD (sc1) 大幅降價 40%：「AWS announces 40% price reduction for Amazon Elastic Block Store (EBS) Cold HDD (sc1) volumes」。

Cold HDD (sc1) 主要是拿來堆資料的，直接掛上來操作比起 Amazon S3 還是方便不少，這次的降價算是懶人的福音？

現在的「Amazon EBS pricing」頁面已經更新了，想要比較的話可以從 archive.is 上面的「Amazon EBS pricing」對比。價錢的部份從十一月九號自動生效：

Amazon EBS customers automatically benefit from this new lower price, which is effective starting November 9th, 2020.

Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站

在「Chrome exempts Google sites from user site data settings」這邊看到的新聞，引用的網頁是「Chrome exempts Google sites from user site data settings」，然後這篇也有上到 Hacker News Daily 上，所以 Hacker News 上的討論也蠻熱鬧的：「Chrome exempts Google sites from user site data settings (lapcatsoftware.com)」。

作者實際在 macOS 上拿最新版的 Google Chrome (86.0.4240.75) 測試，發現就算你針對 Google 自家的網站選了「Clear cookies and site data when you quit Chrome」，只有 cookie 會清掉，但 database storage、local storage 與 service workers 都不會被清掉：

然後 Brave 那邊前陣子時做完 Sync v2 了，又是個機會看看那邊如何了... 結果發現在 2019 年的時候意外修正了一部分：「"Keep local data only until you quit your browser" only deletes cookies, not local storage #1127」、「Fixes: #870 Replaced logic to clear data with WebKit api. #883」。

PostgreSQL 13 的 B-Tree Deduplication

Hacker News 上看到「Lessons Learned from Running Postgres 13: Better Performance, Monitoring & More」這篇文章，其中有提到 PostgreSQL 13 因為 B-Tree 支援 deduplication，所以有機會縮小不少空間。

搜了一下源頭是「Add deduplication to nbtree.」這個 git commit，而 PostgreSQL 官方的說明則是在「63.4.2. Deduplication」這邊可以看到。

另外值得一提的是，這個功能在 CREATE INDEX 這頁可以看到在 PostgreSQL 13 預設會打開使用。

依照說明，看起來本來的機制是當 B-Tree index 內的 key 相同時，像是 key1 = key2 = key3 這樣，他會存 {key1, ptr1}、{key2, ptr2} 與 {key3, ptr3}。

在新的架構下開啟 deduplication 後就會變成類似 {key1, [ptr1, ptr2, ptr3]} 這樣的結構。可以看出來在 key 重複的資料很多的時候，可以省下大量空間 (以術語來說的話，就是 cardinality 偏低的時候)。

這樣看起來可以降低不少壓力...