iT邦幫忙

2026 iThome 鐵人賽

DAY 4
0

昨天講完資料庫本身的選項。今天講的是把雲端和地端接起來的那條線。

這一步的目標很單純:讓地端的備援資料庫,能夠連到雲端的主資料庫,把資料同步回來。中間隔著一整個網際網路,所以需要 VPN。問題是 VPN 有很多種做法,而它們的價差大到有點荒謬。

三個選項

Azure 自己的 VPN Gateway。 微軟官方的服務,用的是企業級的 IPsec/IKEv2,有 99.9% 的 SLA。地端要裝一套叫 strongSwan 的軟體來對接。缺點很明確:。定價器上算出來一個月要 US$153,一年將近兩千美金。

Tailscale。 一個建在 WireGuard 上的服務,設定簡單到有點誇張,安裝、登入、跑一行指令,五到十分鐘就通了。而且不需要固定 IP,它會自動處理 NAT 穿透。免費方案支援二十台設備,對我們綽綽有餘。年費零元

用公司路由器內建的 OpenVPN。 我們的 ASUS 路由器本來就有這個功能,設定起來麻煩一點,但如果公司已經有固定 IP,額外成本也是零。

攤開來看

Azure VPN Gateway Tailscale 路由器 OpenVPN
費用 一個月 US$153 免費 若已有固定 IP,免費
設定時間 30~45 分鐘 5~10 分鐘 1~2 小時
需要固定 IP
SLA 99.9%
故障點 Azure 基礎設施 Tailscale 這家公司 自家 ISP 和路由器
第三方依賴 微軟 Tailscale

看完這張表,任何人的第一反應大概都跟我一樣:Tailscale 不是完勝嗎

免費、五分鐘搞定、效能還更好(WireGuard 比 IPsec 快),不用固定 IP,斷線自動重連。而 Azure 那個一個月要一百多美金,還得學 IPsec 和 IKE 那一整套協定,地端還要多維護一台 strongSwan。

我們本來就在用 Tailscale

而且傾向它還有一個更現實的理由:公司本來就在用了

後台管理的 dashboard,同事要連進來就是走 Tailscale。已經裝好、已經在跑、大家也習慣了,再多接一條線來做資料庫同步,看起來是最省事的選擇。但真的要往下想的時候,我發現這兩件事不太一樣。

同一個工具,兩種完全不同的需求

人在用的那條線是這樣:同事要看後台,開電腦、連上、看完就關掉。它是互動式的、短時間的。萬一斷了,重連一次就好,而且斷線的當下人就在現場,馬上知道。

資料庫複製那條線完全相反。它要一天二十四小時掛著,沒有人盯著,而斷線的後果會累積。

而且複製斷線最麻煩的地方在於它有一個期限。雲端只會把交易紀錄保留一段時間,備援必須在那個窗口之內回來把落後的部分拿走。斷太久,那段紀錄就被清掉了,複製就再也接不回去,整個備援資料庫得重灌一次

同樣叫「連線中斷」,一邊是重連一下,一邊是重建整套備援。

https://ithelp.ithome.com.tw/upload/images/20260918/201786563vFBnxSpZI.jpg

還有一個 Kubernetes 的問題

真正讓我卻步的其實是這個。我們的環境裡,Tailscale 要跑起來會是一個 Kubernetes 裡的 pod。而 pod 這種東西,會因為節點升級、擴縮、驅逐被重新排程,每一次重排,隧道就斷一次

這正是第一篇講過的同一件事:資料庫不該直接跑在 Kubernetes 裡,因為 Pod 隨時可能被重排

長時間掛著的 VPN 隧道也是有狀態的東西。把它綁在一個會被重排的 pod 上,本質上跟把資料庫放在 pod 裡是同一種風險。

https://ithelp.ithome.com.tw/upload/images/20260918/20178656O6JH57zYyX.jpg

而 Azure 的 VPN Gateway 沒有這個問題。它是託管的資源,不在我們的叢集裡;地端那側裝在一台固定的主機上,也不是 pod。整條線跟 Kubernetes 的生命週期完全沒有關係

我沒有實際測過

這裡要老實說一件事:我沒有真的架一套 Tailscale 來測它在這個用途下穩不穩

要確認它到底行不行,得重新研究一輪:pod 重排的時候隧道多久會恢復、複製會不會自己接上、節點升級那種比較久的中斷會不會超過保留窗。這些都不是查文件就有答案的,得實際跑一段時間才知道。

而那個研究本身也是成本。最後的判斷是:這條線是災害復原的命脈,我不想用一個「大概沒問題但沒驗證過」的方案去撐它。 貴的那個方案買到的,某種程度上就是「不用做這個研究」。

帶得走的東西

如果你也在比較這類方案,我覺得成本表最容易騙人的地方是它只列了看得見的錢

那張表上,Tailscale 那欄從頭到尾都是零。但零的意思是「不用付錢給 Tailscale」,不是「不用付出任何代價」。真正的代價藏在別的欄位:沒有 SLA、控制平面在別人手上、隧道跟著 pod 一起被重排、以及要花時間去驗證它到底行不行。最後這一項最容易被忽略,因為它不會出現在任何比較表上。

還有一件事我後來才想清楚:「已經在用了」不等於「這個用途也適用」。

同一個工具,用在人身上和用在機器身上,要求可以差很多。人斷線會自己重連,機器斷線沒人知道;人用的斷十分鐘只是煩,複製斷太久要重建整套備援。

所以與其問「哪個方案最好」,不如問「這條線是給誰用的、斷掉會怎樣」。答案不同,選的東西自然就不同。而我們最後的結果也確實是兩個都在用:人走 Tailscale,機器走 VPN Gateway。


明天要講的是建立這些資源時,畫面上那幾個要你填 IP 網段的欄位。它們看起來只是填數字,但填錯會讓兩個環境在地端打架,而且要等到很後面才會發現。


上一篇
Day 3:一個勾錯就要整台重建的選項
下一篇
Day 5:網段不能亂填,因為地端只有一張路由表
系列文
菜鳥工程師的 DR 告白:混合雲異地備援,與資料庫回家的那 12 分鐘5
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言