Amazon EC2 AMI 的 root volume 可以直接抽換了

這個功能等了十年以上總算是出現了,Amazon EC2 的 AMI 總算是能直接抽換 root volume,不用先停掉機器:「Amazon EC2 enables easier patching of guest operating system and applications with Replace Root Volume」。

Starting today, Amazon EC2 supports the replacement of instance root volume using an updated AMI without requiring customers to stop their instance. This allows customers to easily update their applications and guest operating system, while retaining the instance store data, networking and IAM configuration.

算是 pre-container 時代會遇到的問題,後來大家都把 workaround 變成 practice 了:每次需要時候都是直接整包重新打包 (像是 Packer 這類的工具),然後用工具更新 AMI id 改開新的機器,這樣就能夠避開需要先停掉現有機器的問題...

怎麼會突然想到要回來支援這個功能 XD

Amazon EC2 的 Trn1 正式開放使用

AWS 自家研發晶片的 trn1.* 上線了:「Amazon EC2 Trn1 Instances for High-Performance Model Training are Now Available」。

先前三家雲端的廠商只有 Google Cloud PlatformTPU 可以 train & evaluate,現在 AWS 推出 AWS Trainium,補上 train 這塊的產品。其中官方宣稱可以比 GPU 架構少 50% 的計算成本:

Trainium-based EC2 Trn1 instances solve this challenge by delivering faster time-to-train while offering up to 50% cost-to-train savings over comparable GPU-based instances.

然後 PyTorchTensorFlow 都有支援:

The Neuron plugin natively integrates with popular ML frameworks, such as PyTorch and TensorFlow.

另外用 neuron-ls 可以看到 Neuron 裝置的資訊,不過沒看懂為什麼要 mask 掉 private ip 的資訊:

大型的 cluster 會使用 Amazon FSx for Lustre 整合提供服務:

For large-scale model training, Trn1 instances integrate with Amazon FSx for Lustre high-performance storage and are deployed in EC2 UltraClusters. EC2 UltraClusters are hyperscale clusters interconnected with a non-blocking petabit-scale network.

但第一波開放的區域有點少,只有萬年美東一區 us-east-1 與美西二區 us-west-2

You can launch Trn1 instances today in the AWS US East (N. Virginia) and US West (Oregon) Regions as On-Demand, Reserved, and Spot Instances or as part of a Savings Plan.

us-east-1trn1.2xlarge 的價錢是 US$1.34375/hr,但沒有實際跑過比較好像沒辦法評估到底行不行...

但總算是擺出個產品對打看看,畢竟要夠大才能去訂製這些東西。

AWS 東京區有 12TB 記憶體的機器了

月初 AWS 宣佈東京區有 u-12tb1.112xlarge 可以用了:「Amazon EC2 High Memory instances with 3, 6, 9, and 12TiB of memory are now available in Asia Pacific (Tokyo) region」。查了一下 on-demend 的價錢是 $131.733/hr,如果一個月以 720 小時來算,要 $94847.76/mo...

沒記錯的話,這種機器應該是要另外申請 limit 才能開,沒辦法說測就測。另外在公告裡面有提到 savings plan ,但沒提到 RI (reserved instance),不確定是不是還沒開 RI 讓使用者買 (不過我記得 savings plan 好像也有類似的折扣結構):

Starting today, Amazon EC2 High Memory instances with 3TiB (u-3tb1.56xlarge), 6TiB (u-6tb1.56xlarge, u-6tb1.112xlarge), 9TiB (u-9tb1.112xlarge), and 12TiB of memory (u-12tb1.112xlarge) are available in Asia Pacific (Tokyo) region. Customers can start using these new High Memory instances with On Demand and Savings Plan purchase options.

這種機器是用暴力解決問題的機器...

目前 AWS 台北區只能開 *.2xlarge 的機器

前面在「AWS 的台北區 (Local Zone) 開了」這邊有提到機器開不起來,剛剛查價錢的時候才發現只能開 {c5,g4dn,m5,r5}.2xlarge

改成 c5.2xlarge 然後就開起來了:

翻了目前所有的 local zone,看起來大多都是類似的情況,選擇性會很少... 目前只有邁阿密與洛杉磯的選擇比較多,這是邁阿密:

這是洛杉磯:

這樣目前要拿來當 VPS 取代品還不太好用,就真的是 local zone 的定位。

AWS 的台北區 (Local Zone) 開了

AWS 總算是宣佈啟用台北 Local Zone 了:「AWS Local Zones Expansion: Taipei and Delhi」,中文的公告在「AWS 宣布在台全新 AWS Local Zone 正式啟用」。

翻了一下先前的預告是六月初的時候,大概是四個月前,當時寫了「AWS 宣佈將在台灣推出 Local Zone」這篇。

看 Jeff Barr 提供的 screenshot 可以看到如同先前了解的,就是掛在東京區下面 (ap-northeast-1):

比較奇怪的地方是啟用的方式,我是在在 EC2 的 dashboard 上看到這個進去開 (然後是 Service health),在 VPC 裡面反而沒看到:

然後開了之後要等他幾分鐘啟用,不是幾秒後 refresh 就會出現,我大概等了兩分鐘,跟當初開其他 non-default region 的經驗類似:

然後再回到 VPC 裡面開 subnet,開完後再回到 EC2 上開機器,流程不是很直覺。

另外從「AWS Local Zones features」這邊可以看到目前的服務有限,另外 Jeff Barr 的公告也可以看到目前台北區支援的項目:

After you do this, you can launch Amazon Elastic Compute Cloud (Amazon EC2) instances, create Amazon Elastic Block Store (Amazon EBS) volumes,and make use of other services including Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and Amazon Virtual Private Cloud (Amazon VPC). The new Local Zones include T3, C5, M5, R5, and G4dn instances in select sizes, along with General Purpose SSD (gp2) EBS volumes.

不過這邊有不一致的地方:在 AWS 頁面上是寫 T3 是 upcoming,但 Jeff Barr 的公告則是說可以用 T3,這點晚點來測試看看才知道哪個是對的... 因為我現在連 m5.large 也開不起來:

只要把設定換到東京的 subnet 內就正常,這個錯誤訊息實在是不知道發生什麼事情 (已經設 gp2),還得繼續摸...

EC2-Classic 的狀態

Twitter 上看到這個:

2022/08/15 是 EC2-Classic 最後活著的時間,先前在「AWS 宣佈 EC2-Classic 退役的計畫」這篇也有提到。

在官方的公告文章「EC2-Classic Networking is Retiring – Here’s How to Prepare」這邊裡面有提到最後的日期:

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

不過畢竟是用 expect,應該還有客戶沒有換過去,而且 AWS 官方好像也沒有提到這個 milestone...

Amazon EC2 推出 r6a 的機種

Amazon EC2 推出了 r6a (AMD) 的機種:「New – Amazon EC2 R6a Instances Powered by 3rd Gen AMD EPYC Processors for Memory-Intensive Workloads」。

看了一下美東的價錢,r6ar5a 貴了一點點,其中 r6a.24xlarge 是 US$5.4432/hour,而 r5a.24xlarge 則是 US$5.424/hour。

官方宣稱與 r5a 相比有 35% 的 C/P 值改善:

Up to 35 percent higher price performance per vCPU versus comparable R5a instances

然後可以提供更大的機器,之前 r5a 的最大台機器是 r5a.24xlarge (96 vCPU + 768GB RAM),但 r6a 則是拉到了 r6a.48xlarge 或是 r6a.metal (192 vCPU + 1536GB RAM)。

不過目前看起來支援的地區還有限,目前工作用到的 ap-southeast-1 看起來還要再等一下:

You can launch R6a instances today in the AWS US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Mumbai) and Europe (Frankfurt, Ireland) as On-Demand, Spot, and Reserved Instances or as part of a Savings Plan.

EC2 Auto Scaling 可以透過機械學習來預開機器了

Amazon EC2 的新功能,Auto Scaling 可以透過歷史資料分析預開機器了:「Amazon EC2 Auto Scaling customers can now monitor their predictive scaling policy using Amazon CloudWatch」。

這是吃 CloudWatch 的資料做的,在「Predictive scaling for Amazon EC2 Auto Scaling」這份文件裡面有提到:

Predictive scaling uses machine learning to predict capacity requirements based on historical data from CloudWatch.

還是希望把 Auto Scaling 整合 Lambda 啦,這樣就是 turing machine 了...

Hacker News 前幾天炸很久的 root cause

前幾天 Hacker News 炸了很久,如果是從 Twitter 上的資料來看,是從 2022/07/08 14:08 UTC 這篇:

中間還原失敗 (2022/07/08 17:35 UTC):

到最後恢復 (2022/07/08 20:48 UTC):

Twitter 這邊的資料看起來差不多是六個小時多,以一個應該是只有 database 需要還原的站台來說的確是蠻久的,所以後續在「HN is up again」這邊就有在討論原因,裡面 HN 的老大 dang 也有提到 downtime 是七個小時多:

8 hours of downtime, but not data loss, since there was no data to lose during the downtime.

Last post before we went down (2022-07-08 12:46:04 UTC): https://news.ycombinator.com/item?id=32026565

First post once we were back up (2022-07-08 20:30:55 UTC): https://news.ycombinator.com/item?id=32026571 (hey, that's this thread! how'd you do that, tpmx?)

So, 7h 45m of downtime. What we don't know is how many posts (or votes, etc.) happened after our last backup, and were therefore lost. The latest vote we have was at 2022-07-08 12:46:05 UTC, which is about the same as the last post.

There can't be many lost posts or votes, though, because I checked HN Search (https://hn.algolia.com/) just before we brought HN back up, and their most recent comment and story were behind ours. That means our last backup on the ill-fated server was taken after the last API update (HN Search relies on our API), and the API gets updated every 30 seconds.

I'm not saying that's a rock-solid argument, but it suggests that 30 seconds is an upper bound on how much data we lost.

另外大家就在找 dang 的回應是什麼 (畢竟是第一手資料),用 Ctrl-F 找一下就看到有趣的猜測,從 32028511 這個節點可以看到這串有趣的討論,首先是 mikeiem

You are never going to guess how long the HN SSDs were in the servers... never ever... OK... I'll tell you: 4.5years. I am not even kidding.

然後是 kabdib 的回應:

Let me narrow my guess: They hit 4 years, 206 days and 16 hours . . . or 40,000 hours.

And that they were sold by HP or Dell, and manufactured by SanDisk.

Do I win a prize?

(None of us win prizes on this one).

接著就是 dang 說他覺得這個猜測很有可能:

Wow. It's possible that you have nailed this.

Edit: here's why I like this theory. I don't believe that the two disks had similar levels of wear, because the primary server would get more writes than the standby, and we switched between the two so rarely. The idea that they would have failed within hours of each other because of wear doesn't seem plausible.

But the two servers were set up at the same time, and it's possible that the two SSDs had been manufactured around the same time (same make and model). The idea that they hit the 40,000 hour mark within a few hours of each other seems entirely plausible.

Mike of M5 (mikiem in this thread) told us today that it "smelled like a timing issue" to him, and that is squarely in this territory.

後續他也從自家的 /newest 裡面撈了相關的資料出來,依照他撈出來的關鍵字,看起來是用 HPE 出的 SSD:

It's also an example of the dharma of /newest – the rising and falling away of stories that get no attention:

HPE releases urgent fix to stop enterprise SSDs conking out at 40K hours - https://news.ycombinator.com/item?id=22706968 - March 2020 (0 comments)

HPE SSD flaw will brick hardware after 40k hours - https://news.ycombinator.com/item?id=22697758 - March 2020 (0 comments)

Some HP Enterprise SSD will brick after 40000 hours without update - https://news.ycombinator.com/item?id=22697001 - March 2020 (1 comment)

HPE Warns of New Firmware Flaw That Bricks SSDs After 40k Hours of Use - https://news.ycombinator.com/item?id=22692611 - March 2020 (0 comments)

HPE Warns of New Bug That Kills SSD Drives After 40k Hours - https://news.ycombinator.com/item?id=22680420 - March 2020 (0 comments)

(there's also https://news.ycombinator.com/item?id=32035934, but that was submitted today)

這次 downtime 看起來很像是中了 SSD firmware bug,目前看起來先搬到 EC2 上面了:

$ host news.ycombinator.com
news.ycombinator.com has address 50.112.136.166
$ host 50.112.136.166      
166.136.112.50.in-addr.arpa domain name pointer ec2-50-112-136-166.us-west-2.compute.amazonaws.com.

看討論串應該是暫時性的?

Amazon EC2 有 Mac (M1) 機種可以租用了

2020 年年底的時候 AWS 推出用 Mac mini 配合搭建出 Mac (Intel) 機種:「Amazon EC2 推出 Mac Instance」,當初有計畫在 2021 年推出 M1 的版本:

Apple M1 Chip – EC2 Mac instances with the Apple M1 chip are already in the works, and planned for 2021.

不過就沒什麼意外的 delay 了,這次則是推出了 M1 的版本:「New – Amazon EC2 M1 Mac Instances」。

依照說明看起來還是 Mac mini,掛上 AWS Nitro System

EC2 Mac instances are dedicated Mac mini computers attached through Thunderbolt to the AWS Nitro System, which lets the Mac mini appear and behave like another EC2 instance.

然後跟 Intel 版本一樣,因為是掛進 Dedicated Hosts 的計價方式,雖然是以秒計費,但還是設定最低 24 小時的租用時間限制:

Amazon EC2 Mac instances are available as Dedicated Hosts through both On Demand and Savings Plans pricing models. The Dedicated Host is the unit of billing for EC2 Mac instances. Billing is per second, with a 24-hour minimum allocation period for the Dedicated Host to comply with the Apple macOS Software License Agreement. At the end of the 24-hour minimum allocation period, the host can be released at any time with no further commitment.

Intel 版本代號是 mac1,只有一種機種 mac1.metal,M1 版本代號是 mac2,也只有一種機種 mac2.metal

以最經典的美東一區 us-east-1 來看,mac1.metal 的 on-demand 價錢是 US$1.083/hour,mac2.metal 則是 US$0.65/hour,差不多是 60% 的價錢,便宜不少,大概是反應在硬體攤提與電費成本上了。

另外目前大家用 M1 的經驗來看,Rostta 2 未必會比原生的機器慢多少,雖然 mac1.metal 是 12 cores,mac2.metal 是 8 core,但以雲上面一定要用 Mac 跑的應用來說,馬上想的到的還是綁在 Apple 環境裡 CI 類的應用?

目前看起來主要的問題還是 24 小時的最小計費單位讓彈性低不少...