關於自己架設 E-mail server 的事情

自己架設 E-mail server 的難處算是每過一陣子在 Hacker News 上就會冒出來討論的題目:「Ask HN: Why can't I host my own email?」。

收信只要有固定 IP,加上 ISP 沒有擋 TCP port 25 就倒不是問題,整個最難的點在於怎麼送信,因為會常常被標成 spam...

最基本要設定的東西大概是 SPF,但通常還是建議連 DKIM 一起搞定。另外 DMARC 也弄一下會比較好。

然後依照經驗,Gmail 擋信的機率低不少,微軟家擋信的情況就多很多 (包括免費的 E-mail 服務與付費的 Microsoft 365)...

目前一般建議是自用就過 Amazon SES,沒有低消所以個人用起來不貴...

去年 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 目前因為訴訟的關係,基本上都是拒絕評論...

Akamai 併購 Linode

目前在 Hacker News 首頁第一名,Akamai 併購 Linode:「Akamai To Acquire Linode to Provide Businesses with a Developer-friendly and Massively-distributed Platform to Build, Run and Secure Applications」,Linode 的新聞稿則是在「Linode and Akamai」,Hacker News 上的討論在「Akamai to Acquire Linode (akamai.com)」這邊。

併購金額與預期的時間表:

Under terms of the agreement, Akamai has agreed to acquire all of the outstanding equity of Linode Limited Liability Company for approximately $900 million, after customary purchase price adjustments. As a result of structuring the transaction as an asset purchase, Akamai expects to achieve cash income tax savings over the next 15 years that have an estimated net present value of approximately $120 million. The transaction is expected to close in the first quarter of 2022 and is subject to customary closing conditions.

好像會有記者會... 應該會有更多說明。

其他非 Google 的 Email Hosting 服務

先前在「Cloudflare 的 Email Routing 功能可以讓一般人用 (包括免費帳號)」這邊有提到,因為 Google Workspace 要廢掉免費版本,所以 Cloudflare 推出了 E-mail forwarding 的方案讓大家用,所以一種簡單的解決方法就是註冊另外一個免費的 Gmail 帳號,然後用 Cloudflare 把信件 forward 到新的帳號裡。

但如果想要避開 Google 的服務的話,在 Hacker News 上的「Ask HN: Best hosted alternative to Google Workspace for email?」這邊就有討論不少可能的替代方案,主要是付費的為主。

討論裡常被提起的方案:

我自己是很愛 Fastmail,他的 webmail 界面速度很快 (即使 www.fastmail.com 需要連到美國的伺服氣上),而且鍵盤快速鍵與 Gmail 幾乎相同,所以學習成本很低,就把其中一個 domain 掛上去用,然後把一些服務的註冊 email 都往這邊掛。

而費用的部份,除了可以月繳外,年繳與三年繳都有另外再給 discount (30GB 版本是 US$5/mo、US$50/y 與 US$140/3y),第一次用一年後,後面就是刷三年了...

如果有在用 Office 的話,Microsoft 365 應該也是個選擇方案,不過我對 Outlook 的 folder-based 的設計邏輯用不慣...

然後是 iCloud+,看討論裡面提到穩定度似乎不太行,但也有人用的好好的,我自己是只有拿來同步 Apple 裝置用,沒有用到郵件服務的部份...

另外是自己有架設 Email service,話說這年頭自己搞 Email system 超麻煩的,對於沒搞過的人 SPFDKIM 加上 DMARC 絕對會搞死自己,乖乖丟雲端服務比較省事,我純粹是要保持多路暢通而已...

Vultr 可以帶自己的 IP 位置使用

Twitter 上看到 Vultr 可以帶自己的 IP 使用:

翻了一下發現是 2015 年就提供的功能:「Announce IP Space on the Cloud with Vultr」,而旁邊的 LinodeDigitalOcean 似乎都沒翻到...

在文件「Configuring BGP on Vultr」這邊可以看到需要先驗證 IP 是你的,算是業界常見的作法,跟當初申請 AWSDirect Connect 類似的作法。

IPv4 的價錢

Hacker News 首頁上看到「IPv4 pricing (hetzner.com)」這篇,裡面的連結「IPv4 pricing」是 Hetzner 這個 hosting 通知 IPv4 將在八月漲價的資料...

可以看到「/24 IP subnet (254 usable IPs)」這組的價錢從「€ 215.13 / € 0 setup」漲到「€ 435.20 / € 4864.00 setup」,看起來是趁機漲了不少 setup fee 來綁使用者。

Hacker News 的討論裡面有提到 e-mail 的應用上還是得用 IPv4,至少 Microsoft 還是不愛 IPv6:

I remember while trying to figure out why Microsoft was blocking emails that IPv6 SMTP source addresses had a much higher risk of being blocked despite having done all the required stuff like PTR, SPF, DKIM. Microsoft's form to submit delisting an IP address does not even accept an IPv6 address: https://sender.office.com/

Stuff like this really hinders adoption.

hmmm,e-mail 的確是痛點 (尤其是 reputation 問題),但其他大多數的應用好像還好?

台灣看 Lbry/Odysee 的速度變快一些

Twitter 上看到 jkgtw 提到 Lbry/Odysee 的速度快很多:

看了一下資料,HiNetcdn.lbryplayer.xyz 的 latency 增加了,但是 packet loss 改善了不少,看起來是把本來導去新加坡的流量改導去美國:

另外走 APOL 的 cable 這邊也有類似的情況,可以看出導去美國了:

測了一下影片觀看速度,1.5x 可以看,2x 還是放不太動,的確是比以前好不少。

OVH 法國機房 SBG2 火災全毀

OVH 算是國際上很大的 Hosting 公司,昨天在法國史特拉斯堡 (Strasbourg) 的 SBG2 機房發生火災,這邊的 Octave Klaba 是 OVH 的創辦人與老闆,另外在 Hacker News 上的「Fire declared in OVH SBG2 datacentre building (ovh.net)」這邊也有討論可以看:

可以在 Threadreader 上面讀整個 thread,Octave Klaba 有一直有在 Twitter 上 update 進度與後續的計畫:「https://threadreaderapp.com/thread/1369478732247932929.html」。

新聞媒體也有一些當時的空拍圖放出來了:

出自「Strasbourg: important incendie chez OVHcloud, de nombreux sites internet indisponibles partout dans le monde」。

另外更重要的是伺服器裡面資料的部份,其中 SBG2 全毀,SBG1 毀了四間 (SBG1 總共 12 間),這些資料看起來都沒辦法救了。而 SBG3 與 SBG4 的機器還在,但目前沒有電力。

接下來的會花時間重建 SBG{1,3,4} 的電力系統與重建對外連線,看起來 20KV 的線路與 240V 的線路都有受損需要重弄。

然後也已經有廠商丟災情出來了,線上遊戲的 Rust 一開始說他們受到影響:

但更慘的是官方後續更新,直接說資料無法恢復,聽起來像是沒有備份資料,或是備份資料也在同一個機房內:

除了重建外,現在應該是等後續看起火原因,理論上機房的消防設備應該要能擋下全毀... 等原因出來後,來看看是不是會改變整個機房產業的消防設計架構。

DigitalOcean 送出 Form S-1

Hacker News Daily 上看到的消息,DigitalOcean 送出 Form S-1:「d898181ds1.htm」,在 Hacker News 上也有不少討論:「DigitalOcean S-1 (sec.gov)」。

這個消息跟 2020 年年初的裁員也可以交叉看一下:「DigitalOcean 裁員」,另外在 TechCrunch 上也有報導:「DigitalOcean’s IPO filing shows a two-class cloud market」。

Hacker News 上蠻多人在抱怨 DO 的產品,像是機器的效能,操作界面的穩定性,還有客服的反應... 不過這些跟 IPO 倒是沒什麼關係,重要的是每年的營業額有做出來:

Per its S-1 filing, DigitalOcean generated $203.1 million in 2018 revenue, $254.8 million in 2019 and $318.4 million in 2020. The company closed 2020 out with a self-calculated $357 million in annual run rate.

自己用的話應該還是偏好 VultrLinode...

Vultr 也推出 Kubernetes 服務 (Beta)

看到 Vultr 也打算要推出 Kubernetes 這個產品線了:「Announcing Vultr Kubernetes Engine!」。

這樣加上之前的 LinodeLinode Kubernetes Engine (LKE)DigitalOceanDigitalOcean Kubernetes (「DigitalOcean 也推出 Kubernetes 的服務」),比較知名的幾家 VPS 都推出 K8S 的產品線了。

對於不是 cloud provider 的 VPS provider 來說,直接拿 K8S 整合可以建了一組 mini-AWS 的架構出來,而且因為軟體還算紅,既有的 ecosystem 也可以直接拉進來,不需要另外重新學。不過因為 K8S 發展很快,還是可以常常看到各種踩雷抱怨文... XD

對於使用者來說,如果有一定的量與技術能力,加上想要省錢的話,用這些 VPS 提供的 K8S 服務看起來是個不錯的選擇。

應該找些時間更新之前自己摸索的那些東西了 (之前整理在「Kubernetes」這邊),理解底層會怎麼弄的對於在分析問題時還是蠻重要的 (i.e. 通靈),記得兩年前如果自己要弄 K8S master HA 還是 beta 功能...