Linode WordPress 三台 Web HA 架構：NodeBalancer、Object Storage 與單一寫入實戰

386 瀏覽

2026-09-06 更新

WordPress 要從單台 VPS 走到高可用，最容易犯的錯，是先複製三台一模一樣的主機，卻沒有處理資料庫、uploads、登入狀態與排程。結果主機看起來變多了，故障時還是可能出現圖片遺失、訂單狀態不一致，或後台更新互相覆蓋。

如果既有基礎設施已經在 Linode，三台 Web VPS 的 HA 第一層應該使用 Linode NodeBalancer。它負責健康檢查與流量分送；Cloudflare 留在外層負責 DNS、CDN、WAF 與快取。這樣 Cloudflare 只需要面對一個 NodeBalancer origin，不必先購買 Cloudflare Load Balancer。

推薦架構：Linode NodeBalancer 管三台 Web

訪客
  │
Cloudflare CDN / WAF
  │
Linode NodeBalancer（健康檢查、流量分送）
  ├── Linode Web A（寫入主）
  ├── Linode Web B（前台）
  └── Linode Web C（前台）
          │
  ├── Linode Managed Database
  ├── Linode Object Storage uploads
  └── Redis object cache / session

這裡的核心不是三台都各自保存 WordPress 狀態，而是三台都能連到同一份資料庫與媒體來源。三台 Web 解決 Nginx、PHP-FPM 與單台 VPS 故障；資料庫、媒體、登入與排程仍要有明確的共用策略。

為什麼 NodeBalancer 才是 Linode HA 的入口

NodeBalancer 是 Linode 管理的負載平衡服務。它會把公開流量分到健康的 backend；若 Web B 健康檢查失敗，NodeBalancer 停止把新請求送到 B，繼續交給 A、C。對三台 WordPress Web 而言，這正是最直接的 Linode HA 實作。

Cloudflare：保護與快取入口，對外只設定 NodeBalancer 的 IP 為 origin。
NodeBalancer：同區域的 L4/L7 流量分送與健康檢查；三台 Web 都加入同一份 backend configuration。
Web A、B、C：三台內容與設定一致的 WordPress application nodes。

不要把三台 Web IP 都直接填成 Cloudflare DNS A record，期待它自動做到健康切換。一般 DNS 記錄不會替 WordPress 做應用層健康判斷，而且快取期間仍可能把訪客送往故障主機。NodeBalancer 正好補上這一層。

Linode 各元件應該怎麼分工

Linode Web A：寫入主機，固定處理 /wp-admin、/wp-login.php、媒體上傳、外掛與佈景主題更新，以及唯一一份 WP-Cron。
Linode Web B、Web C：提供公開前台，與 A 使用同一份 WordPress 程式碼、外掛、主題與 wp-config.php salts。
Linode Managed Database：作為共用資料真相，所有 WordPress、WooCommerce 訂單與 session 都從同一資料庫讀寫。選擇具備備援與自動切換的高可用方案。
Linode Object Storage：作為正式媒體來源。透過 Media Offload 把 wp-content/uploads 的原圖、縮圖與附件存入 bucket。
Redis：負責 object cache；若個別外掛有 PHP session，也應改為共用 Redis 或資料庫，而不是各台本機 /tmp。

這是一個很務實的過渡架構。前台有多台可切流，後台寫入先集中，能避開多台同時上傳、更新檔案與執行 Cron 的衝突。它不是完整的寫入高可用，但非常適合先讓 WooCommerce、WPML 與高流量站脫離單機風險。

為什麼 uploads 要選 Linode Object Storage

Linode Volume 適合替單台主機擴充磁碟，但它不是三台 VPS 共用的檔案系統。即使把某個網站的 uploads 用 symbolic link 指到掛載點，也只解決 Web A 的容量；Web B、Web C 不會自動看到那份檔案。

Media Offload 才是多 Web 節點共享媒體的正確方向：WordPress 上傳圖片後，把原圖與縮圖放到 Linode Object Storage，並讓前台 attachment、srcset 與 PDF URL 指向 bucket 或 CDN。Linode Object Storage 採 S3-compatible API，對既有 WordPress offload 外掛與工具整合較方便。服務費與外掛比較可延伸閱讀 WordPress Offload 儲存服務價格比較。

導入時不要先刪除本機檔案。我會挑一個非 WooCommerce、非 WPML 的站先試，採 copy and retain local：驗證舊媒體、縮圖、WebP、PDF、Elementor 內容、重新上傳與刪除後，再批次搬移既有檔案。正式媒體 bucket 也不應取代備份；資料庫備份與異地 snapshot 仍要獨立保留。

登入、WooCommerce 與 WP-Cron 的三個關鍵

登入 cookie：三台 Web 必須使用完全相同的 WordPress salts、網域與 HTTPS 設定，否則使用者切到另一台會掉登入。
WooCommerce session：session 依賴 cookie 加上資料庫資料，資料庫一定要共用。PHP session 不能留在任一台的本機 /tmp。
WP-Cron：只能由 Web A 的系統 Cron 定時觸發。三台一起跑會造成寄信、同步、扣庫存與排程任務重複執行。

Redis 的定位要分清楚：它能降低資料庫的重複查詢，也能承接部分 session；它不能存取正式媒體，更不能取代 Object Storage。WooCommerce session 的實作可參考 WooCommerce Session 轉移到 Redis 的實戰筆記。

Cloudflare 在 Linode HA 裡負責什麼

Cloudflare 放在 Linode 前方，負責 CDN、WAF、Bot 防護與快取；對 origin 則指向 NodeBalancer 的公開 IP。這樣 Cloudflare 不需要知道 Web A、B、C 的個別狀態，NodeBalancer 在 Linode 內部完成健康檢查與切流。

只有當你未來要做跨 Linode region、跨雲供應商，或需要全球流量導向時，才值得再加購 Cloudflare Load Balancer，讓它在多個 NodeBalancer 或多個區域之間切換。Cloudflare Load Balancer 的 endpoint、pool、monitor 額度依訂閱方案而定，沒有一個所有帳號都相同的固定台數上限；三台 Web 單一區域架構不需要用到它。

導入順序：先以 Linode 降低維運複雜度

建立三台同區域的 Linode Web VPS，將程式碼、外掛、主題與設定檔版本化，確保可重複部署。
建立 Linode NodeBalancer，把 Web A、B、C 加入同一份 HTTP/HTTPS backend，設定輕量 health endpoint。
建立 Linode Managed Database 與 Redis，先讓測試站連上共用狀態服務。
建立 Linode Object Storage bucket，先用 retain local 模式導入 Media Offload。
將後台、上傳、部署與 WP-Cron 固定到 Web A；前台則由 NodeBalancer 分送。
完成資料庫備份、bucket versioning、異地備份與還原演練後，再評估跨區域或寫入層的進一步 HA。

同一個 Linode 平台能降低初期導入成本與維運複雜度，但不表示可以省略備份。正式媒體放在 Linode Object Storage 沒問題，仍應保留可還原的資料庫備份與另一份異地備份，避免帳號、區域或操作錯誤同時影響所有資源。