Vultr 開大阪機房

Vultr 宣布開大阪機房:「New Cloud Data Center Location: Osaka, Japan」。

本來的東京機房從 HiNet 過去會塞,可以看到每天都會有一段時間 latency 會飄起來:

從 HiNet 過去 Vultr 東京機房是走 PCCW 的線路:

從 Vultr 東京機房回來是走 NTT 的線路:

如果是 Vultr 大阪機房的話,先用 mtr 看了一下 latency,狀況似乎是好很多?好像可以考慮把東京的機器搬到大阪看看...

Vultr 更新流量計算方式

一時間沒找到在哪邊看到的,但的確是漏掉這個消息,早上看到去翻才注意到的... Vultr 在去年 11 月底宣佈更新流量的計算方式:「Vultr Announces Reduced Bandwidth Pricing, 2 TB of Free Monthly Egress, Free Ingress, and Global Pooling」。

這波費用的更新算是跟上另外兩家 (LinodeDigitalOcean) 的算法了,先前 Vultr 的算法就很古老 XD

第一個是 inbound traffic 不算錢了 (總算):

Data ingress will now be free.

再來是 traffic pool 的概念,現在每個帳號的流量會統一計算,而非每台機器自己計算:

All customers will receive global account-level pooling of transfer across all instances and locations.

然後是每個帳號都提供 2TB 的 free outbound traffic,這點有點放送的感覺:

Every Vultr customer will now receive two terabytes (2 TB) of free outbound data transfer every month, in addition to the transfer included with each subscription.

最後是超量的部份收費也簡化了,不管什麼地區都是 $0.01/GB:

Vultr will now offer a reduced, single worldwide egress overage rate of only $0.01 per GB.

最後這點有個值得操作的點:依照他的收費標準,超量 1TB 的流量需要付 $10 的費用,但你可以多租一台 $5/mo 的機器,這個方式提供了 1TB 的流量到 traffic pool 裡面。

fp32、fp16 與 bf16

nanoGPT 這個專案下面看到 bf16 這個浮點格式:(這段在新版的 README.md 被改寫了)

Currently fp16 is much faster than bf16. Potentially revert back to using fp16 and re-introduce the gradient scaler?

翻了一下 bf16,是由 Google 的團隊所提出來的想法,主打是與 fp32 相同的表示範圍,但是犧牲精度,這樣一來既有使用 fp32 的程式很有機會可以直接換成 bf16 降低計算量 & 提昇效率 (也就是 drop-in replacement):

然後同一頁也看到各家自己推出不同的格式,這邊看起來比較像是市場競爭的關係...

Apple 使用 Cassandra 的量

Hacker News Daily 上看到的:「Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB (twitter.com/erickramirezau)。原文在 Twitter 上:

有些數字有點對不太起來,裡面提到 300K nodes + millions of QPS,但通常讀寫都算 QPS,這樣聽起來很少?所以有種可能這邊是只有算 read 的部份...

另外照片裡面提到 Over two petabytes per cluster,但有 thousands of clusters,最後卻只有 Hundreds of petabytes of data,完全對不上,就算當作平均值來算也對不上,只能猜測是最大的 cluster 而不是 per cluster。

裡面矛盾的地方太多,所以這些數字基本上沒有參考價值,現在能讀出來的只知道 Apple 有在用 Cassandra,然後不是少少幾台 PoC 等級的使用。

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 上,反正在 tab 上幾天了... 但還是附上 Hacker News 的連結:「Show HN: Data Diff – compare tables of any size across databases」,專案的位置在 GitHub 上的 datafold/data-diff

這是用 Python 寫的工具,安裝可以透過 pip 直接裝,所以也可以用 pipx 之類的工具獨立起來跑。

data-diff 會先拆成多個區塊,然後透過 checksum 的機制判斷兩邊的資料是否相同,不同的部份再取 bisection 分開下去找 (或是更多份,在 Technical Explanation 這個段落有寫到)。

在「Common use-cases」這段有提到幾個常見的使用情境,像是在自動化的環境下可以當作異常監控的工具:

Alerting and maintaining data integrity SLOs. You can create and monitor your SLO of e.g. 99.999% data integrity, and alert your team when data is missing.

另外在 troubleshooting 的情境下當然也很有幫助,可以先確認資料是否有問題,以及資料的哪邊出問題:

Debugging complex data pipelines. When data gets lost in pipelines that may span a half-dozen systems, without verifying each intermediate datastore it's extremely difficult to track down where a row got lost.

這個工具讓我想到 Percona Toolkit 裡面的 pt-table-checksum,不過 pt-table-checksum 只能處理 MySQL replication 的情境,data-diff 看起來通用多了:

目前完整測試過的是 MySQLPostgreSQLSnowflake,其他的有實做但還沒完整測試過。

看起來還在開發 (後面是商業公司 Datafold),但先寫下來,之後如果有用到的時候可以回頭看看進展...

在 Shell 下一行用 SQLite 查詢 CSV 內的資料

Simon Willison 這邊看到 command line 下用 SQLite 的技巧:「One-liner for running queries against CSV files with SQLite」。

範例指令是這樣 (整理了一下排版):

sqlite3 :memory: \
    -cmd '.import -csv taxi.csv taxi' \
    'SELECT passenger_count, COUNT(*), AVG(total_amount) FROM taxi GROUP BY passenger_count'

可以看出來這個方式是將 csv 檔先讀到 in-memory database (:memory:),再用 SQLite 下指令處理,另外也可以自己變化,應該可以透過 /dev/stdin 這樣的方式讀 pipe 的東西。

拿來簡單跑一些東西應該還不賴?

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 計費) 用服務搬了,不過要注意網路頻寬的流出部份還是有費用...

NVIDIA 開源 Linux GPU Kernel Driver

NVIDIA 宣佈開源 Linux 下的 GPU Kernel Driver:「NVIDIA Releases Open-Source GPU Kernel Modules」。

從一些描述上可以看出來,應該是因為 Datacenter 端的動力推動的,所以這次 open source 的版本中,對 Datacenter GPU 的支援是 production level,但對 GeForce GPU 與 Workstation GPU 的支援直接掛 alpha level:

Which GPUs are supported by Open GPU Kernel Modules?

Open kernel modules support all Ampere and Turing GPUs. Datacenter GPUs are supported for production, and support for GeForce and Workstation GPUs is alpha quality. Please refer to the Datacenter, NVIDIA RTX, and GeForce product tables for more details (Turing and above have compute capability of 7.5 or greater).

然後 user-mode driver 還是 closed source:

Will the source for user-mode drivers such as CUDA be published?

These changes are for the kernel modules; while the user-mode components are untouched. So the user-mode will remain closed source and published with pre-built binaries in the driver and the CUDA toolkit.

nouveau 來說,是可以從 open source driver 裡面挖一些東西出來用,不過能挖到跟 proprietary 同樣效能水準嗎?

去年 OVH 機房大火的部份情形最近被揭露

去年三月在「OVH 法國機房 SBG2 火災全毀」這邊有提到 OVH 的機房大火事件,最近有些情況總算被揭露出來了。

Hacker News 上看到「OVHcloud fire report: SBG2 data center had wooden ceilings, no extinguisher, and no power cut-out」這篇這個月月初的報導,裡面題到了一些情形。另外對應的討論在「OVHcloud fire: SBG2 data center had no extinguisher, no power cut-out (datacenterdynamics.com)」這邊可以看到。

其中一個是在講消防隊花了三個小時才把電力切斷,因為電力室外面有非常強力的電弧:

According to the report firefighters on the scene found electrical arcs more than one meter long flashing around the door to the power room, and it took three hours to cut off the power supply because there was no universal cut-off.

另外電力室本身的設計也不利於防火 (木造天花板?),而且電力管道也沒有隔離:

The power room had a wooden ceiling designed to withstand fire for one hour, and the electrical ducts were not insulated.

另外因為節能的設計,他們設計了多個通道讓外部的空氣容易進入 data center 交換熱量,但這也導致了火苗很不容易熄滅:

Once the fire escaped from the power room, it grew rapidly. The report says that "the two interior courtyards acted as fire chimneys". JDN claims the spread of fire may have been accelerated by the site's free cooling design, which is designed to encourage the flow of outside air through the building to cool the servers.

OVH 目前因為訴訟的關係,基本上都是拒絕評論...