Nutanix_18 災難恢復演練（DR Drill)

 

那些年，我們假裝世界末日已經來了

在 IT 世界裡，有一種活動，大家表面上說很重要，但心裡都默默希望它永遠不要真的派上用場——它的名字叫做 災難恢復（Disaster Recovery, DR）。
而 DR Drill（災難恢復演練），就是那種「假裝公司已經炸掉一次」的年度大型角色扮演活動。

一、什麼是 DR Drill？

簡單說：
👉 不是在等災難發生，而是先假裝它已經發生了。

DR Drill 就像消防演習，只是比較安靜、不會有哨聲，但工程師的心跳一樣快。
我們會假設某一天：

• 主機房斷電

• Storage 掛點

• 網路消失

• 老闆打電話來問：「網站為什麼打不開？」

然後問一個殘酷的問題：
「如果現在真的出事，我們救得回來嗎？」

二、為什麼 DR 一定要演練？

因為 DR 文件 ≠ DR 能力。

很多公司都有一份 DR 文件，厚度堪比研究所論文，裡面寫滿了：

• RPO = 15 分鐘

• RTO = 1 小時

• 切換流程 Step 1 到 Step 28

但問題是——
這份文件上一次被照著做，是什麼時候？

DR Drill 的存在，就是為了揭穿殘酷的真相：

• 帳號密碼是不是早就失效

• IP 位址是不是三年前的舊資料

• 「這台 VM 是誰管的？」沒人知道

• 關鍵人員今天剛好請假

沒有演練，DR 只是 PPT 等級的信仰。

三、DR Drill 的三大常見幻想

在真正演練前，大家通常會有以下錯誤期待：

幻想一：

「平常都沒問題，DR 也一定沒問題。」

👉 錯。
DR 就像降落傘，你永遠不知道它會不會在第一次用時才發現裝反了。

幻想二：

「切換應該按個按鈕就好吧？」

👉 半錯。
現在很多系統確實可以「一鍵 Failover」，
但前提是——
你有先確認那顆按鈕真的有接線。

幻想三：

「演練不要太認真，怕影響正式系統。」

👉 大錯特錯。
不認真的 DR Drill，只是在練習「如何在災難時更慌張」。

四、一次真正的 DR Drill，通常會發生什麼事？

流程大概是這樣的：

1. 宣布演練開始
   大家嘴上說 OK，Slack 群瞬間安靜。

2. 模擬主站台失效
   有人小聲問：「真的要關嗎？」

3. 開始切換到 DR Site

   • VM 起來了

   • 網路通了

   • 但應用程式連不到 DB

4. 開始查問題
   「這個防火牆規則是誰加的？」
   「為什麼 DR 環境沒有這個憑證？」

5. 修修補補
   工程師邊修邊在心裡記帳：「下次一定要改。」

6. 宣布演練成功
   表面歡樂，內心疲憊，但系統真的變更強了。

五、DR 測試不只是「能不能開機」

真正成熟的 DR 測試，會看這幾件事：

• RPO 有沒有真的達成？
  資料少了 3 小時 ≠ 成功

• RTO 是理想還是現實？
  文件寫 1 小時，實際跑 4 小時，老闆的臉色就是 KPI

• 應用層有沒有一起測？
  VM 起來但系統不能用，只是「漂亮的失敗」

• 人有沒有準備好？
  DR 不是只有機器，還有值班人員的腦袋

六、為什麼 DR Drill 常常被拖延？

因為它有三個 IT 世界最可怕的特性：

1. 沒出事時，看不到價值

2. 會暴露問題

3. 需要跨部門合作

但現實是：
👉 你不在演練時流汗，就會在災難時流淚。

七、做完 DR Drill，最重要的一件事

不是寫報告、不是簡報、不是寄信給老闆。

而是：
真的把發現的問題修掉。

• 文件更新

• 腳本修正

• 自動化補齊

• 權限重新確認

否則下一次演練，還是同一批 Bug 出來跟你打招呼。

八、結語：

DR Drill 不是在詛咒公司出事，而是在保證——
真的出事時，公司還活著。

真正專業的 IT 團隊，不是從不出錯，
而是 在世界還沒崩壞前，就已經演練過怎麼救它。

所以，下次當你聽到有人說：
「我們要做 DR Drill。」

請不要嘆氣，
那代表你正在替未來的某一天——
少一次通宵，多一次安心。

Nutainix_17 工程師一想到就會胃痛、但老闆覺得「不就拉條線嗎？」—— DR 的網路自動化與切換（Networking in DR）。

 

一、為什麼 DR 最容易死在「網路」？

在 DR 世界裡，有一句流傳已久的黑色幽默：

「系統還活著，但網路沒接上。」

伺服器？好好的。
Storage？同步完成。
VM？開得比員工還早。

結果使用者一連線——
404 Not Found，人生已迷路。

原因很簡單：
DR 不只是一個「把 VM 開起來」的問題，
而是一個**「網路能不能瞬間假裝什麼事都沒發生」的魔術秀**。

二、DR 網路切換，到底在切什麼？

很多老闆以為 DR 網路切換是這樣的流程：

1. 災難發生

2. 工程師按一個按鈕

3. 世界恢復和平

但實際上，網路層要處理的事情包含：

• IP 要不要換？

• VLAN / VXLAN 要不要對？

• Gateway 是不是同一個？

• DNS 要不要改？

• Firewall 規則還在嗎？

• Load Balancer 還記得我是誰嗎？

簡單翻譯就是：

「你以為在搬家，其實是在幫整個社區換身分證。」

三、最傳統的 DR 網路：人工切換地獄

讓我們回顧一下史前時代 DR 網路切換流程：

• 工程師 A 改路由

• 工程師 B 改 Firewall

• 工程師 C 改 DNS

• 工程師 D 在群組裡問：「現在是誰改錯了？」

這種 DR 的特色是：

• RTO = 工程師喝完第三杯咖啡後

• RPO = 視前一天睡眠品質而定

• 成功率 = 50%（另一半是「奇怪，昨天明明可以」）

而最可怕的不是失敗，
是半年沒演練，一切靠記憶力硬撐。

四、IP 不換派 vs IP 一定要換派

在 DR 網路設計中，有一個宗教戰爭級的問題：

派系一：IP 不換派（L2 延伸派）

口號是：

「IP 不變，世界和平。」

做法是透過：

• L2 Extension

• VXLAN

• EVPN

• 各種讓網路工程師頭髮變少的技術

好處：

• 應用程式完全不用改

• DNS 不用動

• 老闆覺得你很厲害

壞處：

• 網路架構複雜到像迷宮

• 延遲、風暴、廣播封包可能一起來

• 出問題時，Debug 像在找平行宇宙入口

派系二：IP 會換派（L3 切換派）

口號則是：

「IP 可以換，但人生不能卡住。」

做法是：

• DR Site 使用不同子網

• 切換時改 Routing / DNS / LB

• 讓系統「接受現實」

好處：

• 架構清楚

• 問題好找

• 網路工程師晚上睡得著

壞處：

• 切換邏輯一定要自動化

• 沒寫好腳本會直接翻車

五、沒有自動化的 DR 網路，叫「祈禱模式」

如果你的 DR 網路切換流程是：

• 開 Word

• 翻 SOP

• 一條一條手動下指令

• 心中默念「拜託不要打錯」

那你用的不是 DR，
你用的是：

「工程師信仰系統（Engineer-as-a-Service）」

真正成熟的 DR 網路，一定要做到：

• 一鍵切換

• 可回復

• 可重複演練

• 不靠某個人腦袋裡的神秘知識

六、網路自動化，工程師的救贖

DR 網路自動化通常會包含：

1️⃣ Routing 自動切換

• BGP / 靜態路由自動調整

• Primary Site 掛了，路由自動指向 DR

2️⃣ DNS 自動更新

• TTL 調低

• Failover 時自動指到新 IP

3️⃣ Firewall / Security Policy 同步

• 規則跟著 VM 走

• 不會出現「系統起來了但被自己擋住」

4️⃣ Load Balancer 重指向

• 健康檢查失敗即切換

• 使用者無感，工程師感動

做到這一步，DR 才算是：

「工程設計，而不是勇氣測試。」

七、DR 演練，最容易露餡的就是網路

很多公司 DR 演練流程是：

• VM 起來 ✔

• 資料正常 ✔

• 使用者連不上 ❌

然後會出現經典對話：

老闆：「不是說 DR OK？」
工程師：「系統 OK，網路還在想人生。」

其實 DR 演練真正的價值就在這裡——
讓網路問題在白天爆炸，而不是半夜。

八、雲端 DR：網路切換的另一個修羅場

到了多雲或混合雲環境，網路切換難度再升級：

• On-Prem → Cloud

• Cloud → Cloud

• 不同雲的 VPC / VNet 邏輯完全不同

這時候你會發現：

「網路不是線，而是政治。」

好的 DR 網路自動化，會把差異包起來，
讓切換流程一致、可預期、可測試。

九、真正成熟的 DR 網路長怎樣？

如果你的 DR 網路做到以下幾件事，
恭喜你，已經站在金字塔頂端：

• 切換流程可以在白天執行

• 不需要全公司陪你熬夜

• 演練完不需要寫一篇悔過書

• 新人照 SOP 也能完成切換

這代表你的 DR 網路不是靠英雄，
而是靠設計與自動化。

十、結語：DR 網路不是炫技，是保命

最後送你一句 DR 工程師界的真理：

「災難發生時，你唯一來不及補的，就是網路設計。」

DR 的網路自動化與切換，
不是為了展現你多會下指令，
而是為了在最糟的時刻，
讓系統看起來像什麼事都沒發生。

而當某天真的按下那個切換按鈕時，
世界依然運轉、使用者毫無感覺、
你只需要淡淡地說一句：

「放心，網路我早就想好了。」

這，才是 DR 網路工程師最浪漫的時刻。

Nutanix_16 不同雲端環境的 DR 方案! 當災難來臨時，你的系統是「瞬間轉生」，還是「靈魂出竅」？

 

一、雲端時代的錯覺：

「都上雲了，還需要 DR 嗎？」

很多人在第一次聽到「雲端」兩個字時，內心都會自動補完一句：

「雲端不是很穩嗎？
不是有三個 AZ、五個 Region、七層冗餘嗎？」

於是 DR 就常常被默默放進「之後再說」清單裡，
跟「文件整理」、「權限重構」、「老系統下線」排在同一排。

直到某天：

• 雲端服務區域大當機

• 帳號權限被誤刪

• IaC 套版一鍵誤炸整個環境

你才會發現一個殘酷的事實：

雲端幫你撐「硬體」，
但「人生選擇錯誤」還是你要自己承擔。

二、先講清楚一件事：

雲端 DR 在保什麼？

不論你用哪一家雲，DR 都不是在救「機器」，而是在救三樣東西：

1. 資料：還在嗎？完整嗎？

2. 服務：起得來嗎？順序對嗎？

3. 時間：老闆能等多久？

也就是我們熟悉的兩個靈魂指標：

• RPO：我能接受掉多少資料？

• RTO：我能接受停多久？

接下來，我們就來看看不同雲端環境，
是怎麼回答這兩個問題的。

三、同一雲、不同區域（Multi-AZ / Multi-Region）

最常見，也最容易被高估的 DR

這一型 DR 的特色是：

• 都在同一家雲

• 只是換 AZ 或 Region

• 心理上最有安全感

常見作法

• 資料庫跨 AZ 同步

• 服務做 Load Balancer

• 重要服務跨 Region 備援

優點

• 架構相對簡單

• 延遲低

• 工程師比較不會失眠

現實的提醒

• 帳號誤刪 = 全區一起消失

• IaC 寫錯 = 災難同步擴散

• 服務 Bug = 兩邊一起躺

這種 DR 很像：

「我把雞蛋放在同一間超大的籃子裡，
只是角落不一樣。」

四、跨雲 DR（Multi-Cloud）

理論上完美，實務上最考驗信仰

這是老闆最愛聽的一種：

「我們主系統在 AWS，
DR 在 Azure，
這樣最安全吧？」

聽起來很厲害，
工程師聽到通常會先深呼吸三秒。

常見作法

• 資料定期同步到另一家雲

• 重要服務保留最低可啟動版本

• DNS 或流量切換

優點

• 不會被單一雲商綁死

• 區域級、雲商級災難都撐得住

• PowerPoint 看起來超強

隱藏成本

• 架構、工具、權限全部雙份

• Debug 時不知道該罵誰

• 人員要同時懂兩家雲

這種 DR 很像：

「我買了兩台不同品牌的車，
理論上很安全，
但保養時我開始懷疑人生。」

五、雲端＋地端（Hybrid DR）

現實世界最常見的折衷方案

這一型通常出現在：

• 金融

• 製造

• 政府

• 或「有歷史包袱」的公司

常見作法

• 主系統在雲

• DR 在地端，或反過來

• 透過複寫、快照同步

優點

• 彈性高

• 合規性好

• 舊系統不用一次殺光

現實問題

• 頻寬永遠不夠用

• DR 演練時最容易卡

• 誰是主、誰是備常常講不清楚

這種 DR 很像：

「我白天住城市，
晚上住老家，
行李永遠沒帶齊。」

六、SaaS 的 DR：

你以為不用管，其實最無力

很多人對 SaaS 的 DR 想法是：

「那是廠商的事吧？」

某種程度上，對。
但只對一半。

你能掌控的

• 資料匯出

• 權限控管

• 帳號保護

你無法掌控的

• 廠商什麼時候修好

• 資料回不回得來

• 老闆為什麼一直問你

SaaS 的 DR 本質是：

「你不是在復原系統，
你是在復原耐心。」

七、雲端 DR 最常見的三大幻想

1️⃣ 「我們有備份就好」
→ 備份 ≠ 服務會起來

2️⃣ 「切換應該很快」
→ 沒演練過的切換，
通常都會很有教育意義

3️⃣ 「雲不會掛」
→ 會，而且通常掛得很有新聞價值

八、結語：

最好的 DR，不是最貴，而是你真的跑得動

不同雲端環境的 DR 方案，
沒有標準答案，
只有適不適合。

你需要問的永遠是：

• 出事時，我們多久能回來？

• 回來的是不是對的狀態？

• 誰負責按那個按鈕？

如果你的 DR 計畫：

• 文件太厚

• 架構太美

• 演練太少

那它通常只在簡報裡很可靠。

真正好的 DR，是那種：

你希望一輩子用不到，
但真的來時，
它會默默把事情做好。

Nutanix_15 如果災難發生時你在喝咖啡，Prism Central 幫你把事情做好了! 用幽默方式介紹如何用 Prism Central 統一管理 DR 計畫（Recovery Plans）

 

一、災難復原這件事，通常都在「沒時間」的時候發生

在 IT 世界裡，有一個殘酷的真理：
系統掛掉的時候，永遠不是你最有空的時候。

可能是：

• 老闆正在簡報

• 財務正在結帳

• 客戶正在刷卡

• 而你正在想「今天午餐要吃什麼」

這時候你腦袋裡不該再出現：
-「這台 VM 要先開還是後開？」
-「資料庫跟 App 的順序我上次寫在哪？」
-「DNS 要不要手動改？」

這些問題，都不該在災難當下才想起來。

而 Prism Central 的 Recovery Plans，存在的意義只有一個：
👉 讓你在災難來時，不用靠記憶力救公司。

二、Prism Central 是什麼？

（給還沒被 Nutanix 洗腦的朋友）

簡單說一句話：

Prism Central = 多個 Nutanix 叢集的「總司令部」

如果 Prism Element 是每一個叢集的「地方首長」，
那 Prism Central 就是：

• 統一監控

• 統一管理

• 統一設定

• 統一把事情變簡單

而 DR 計畫（Recovery Plans），正是 Prism Central 最適合「居高臨下」指揮的工作之一。

三、DR 計畫不是備份，是「復活順序表」

很多人一聽到 DR 就說：「啊我有備份啊。」

但事實是：

• 備份 ≠ 可以馬上用

• 備份 ≠ 服務會自己站起來

• 備份 ≠ 老闆會原諒你

真正的 DR 計畫，包含的是：

1. 哪些 VM 要復原

2. 先誰、後誰

3. 等多久

4. 網路要不要改

5. IP 要不要換

6. 失敗時怎麼回頭

這些東西，如果靠人工操作：

• 正常時很複雜

• 緊急時會直接變災難二次傷害

Prism Central 的 Recovery Plans，
就是把這些「人類容易出錯的流程」，
變成「按一次就好」。

四、在 Prism Central 建立 Recovery Plan，其實沒那麼可怕

放心，這不是那種「要寫 30 頁 SOP 才能開始」的東西。

基本流程其實很直白：

1️⃣ 選來源與目標叢集

你會先告訴系統：

• 主要叢集（Production）

• DR 叢集（災難時要接手的地方）

就像你先跟大家說：

「如果我不在公司，就找副手。」

2️⃣ 選 VM（不用一台一台手挑）

你可以用：

• VM 群組

• 保護群組（Protection Domain）

• 標籤（Tag）

來選 VM。

這代表什麼？
👉 你不用再用滑鼠點到手抖。

只要 VM 分類有做好，
DR 計畫就會顯得你是一個「早就想好的人」。

3️⃣ 設定啟動順序（這一步超重要）

這裡是 Recovery Plan 的靈魂。

你可以告訴 Prism Central：

• 第 1 階段：資料庫先起來

• 第 2 階段：應用伺服器

• 第 3 階段：Web / API

• 每一階段中間要不要等 30 秒或 2 分鐘

這等於是你在系統裡說：

「拜託，先讓資料庫醒來，
不然 App 起來只會更痛苦。」

而且這個順序：

• 平常不用背

• 災難時不用想

• 半夜也不用靠直覺操作

五、網路與 IP：最容易讓人崩潰的地方

災難復原時，最常聽到的一句話是：

「VM 起來了，但連不到。」

Recovery Plans 可以幫你處理：

• 網路對應（Network Mapping）

• IP 是否保持或改變

• 是否在 DR 站點使用不同 VLAN

這代表什麼？
👉 你不用在災難時邊 Google 邊改設定。

Prism Central 已經幫你把：
「原本在哪個網路」
「到 DR 要去哪個網路」
先對好。

六、Test Mode：DR 最大的良心發現

很多公司 DR 計畫的真實狀態是：

「我們有寫，但從來沒跑過。」

這在 IT 世界裡，
跟「我有買滅火器，但不知道會不會噴」是同一件事。

Prism Central 的 Recovery Plans 有 Test Mode，可以：

• 不影響正式環境

• 在隔離網路中測試

• 完整跑一次復原流程

這讓你可以在：

• 老闆不在

• 系統沒掛

• 心情還算穩定

的時候，
確認 「真的能復原」。

七、Runbook 自動化：你不是一個人在救災

Recovery Plan 還可以搭配：

• 前置 Script

• 後置 Script

• API 或自動化流程

例如：

• 復原前先停某些服務

• 復原後自動檢查狀態

• 或通知某個系統「我回來了」

這時候你會發現：
👉 你不是在救災，是在指揮救災。

八、統一管理的真正價值：不是技術，是安心

當你用 Prism Central 統一管理 DR 計畫，你得到的其實不是「功能」，而是三件事：

1. 你知道發生事時該按哪一個鍵

2. 你不用靠記憶力或英雄主義

3. 你可以很冷靜地說：我們有計畫

在 IT 世界裡，
真正專業的人，
不是「會在災難時很忙」，
而是「讓災難時不用那麼忙」。

九、結語：

最好的 DR，是你希望永遠用不到，但隨時準備好

Prism Central 的 Recovery Plans，
不是讓你炫技，
也不是讓你寫更多文件。

它的存在目的只有一個：

在最糟的時刻，
讓你看起來像早就預料到這一天。

而這，
才是 DR 的最高境界。

Nutanix_14 DR 架構：讓你的資料比你的早餐還安全

 

如果你的資料比你的生活還重要，那麼 災難復原（Disaster Recovery, DR） 就不是選項，而是必須。想像一下，你正準備喝下午茶，突然電腦爆炸、資料消失、老闆打電話來問「報告呢？」——這種場景是不是比恐怖片還刺激？不用怕，Nutanix 來救你。今天我們就來聊聊 Nutanix 的 DR 架構，用最幽默的方式把技術變成「笑中帶淚」的安心指南。

1. DR 的基本概念：災難來了怎麼辦？

先來解釋一下 DR。DR 就像是你的備用計畫，不是「希望災難不來」，而是「災難來了也能活過來」。在 Nutanix 的世界裡，DR 不是一個遙不可及的夢，而是一個操作簡單、幾乎零壓力的機制。

傳統架構中，DR 可能意味著：買一堆昂貴的硬體、設定複雜的同步機制、還要找個懂行的工程師守夜班。簡單說，就是「錢花了、心累了、還可能半夜被叫起來」。

Nutanix 的 DR 則像是把這一切交給一個超級智能管家：它會自動管理資料同步、快照、網路策略，甚至在災難發生時自動恢復你的系統，讓你能睡個好覺。

2. Nutanix DR 的兩大核心：Prism Central + AHV

要理解 Nutanix DR，先得認識兩個角色：

1. Prism Central
Prism Central 是 DR 的大腦，負責統一管理多個 Nutanix Cluster。它就像是智慧型管家，幫你監控健康狀況、安排資料同步、甚至能告訴你哪個 VM 最容易「躺平」。

2. AHV（Acropolis Hypervisor）
AHV 是 Nutanix 自家的超人虛擬化平台，負責執行你的 VM。DR 的魔法之一是 AHV 能夠快速複製 VM，甚至在另一個站點立刻啟動，讓你的業務「瞬間復活」，幾乎像是 Harry Potter 的瞬移術。

3. DR 架構圖解：兩個站點的愛情故事

Nutanix DR 最經典的場景就是「兩個站點」架構：

• Primary Site（主站）：你日常工作的地方，一切資料先從這裡產生。

• Secondary Site（備援站）：備胎站點，默默等待主站出事的那一天。

這兩個站點之間會建立資料複製（Replication），可以是同步（Sync）也可以是非同步（Async）：

• 同步複製：資料寫進主站的同時，也寫進備援站。好處是資料零遺失，但延遲可能稍高。

• 非同步複製：資料寫進主站後，再傳到備援站。好處是延遲低，但災難發生時可能有少量資料丟失（就像早餐吃到最後一口吐司沒了）。

這種架構最大的優勢是 業務不中斷。當主站遇到地震、颱風、貓踩電源線，Secondary Site 立刻接手，使用者幾乎察覺不到災難。

4. Nutanix DR 的魔法功能

Nutanix 不只是簡單複製資料，它還有一些「讓人驚呼 OMG 的功能」：

4.1 One-click DR

你只要按下一個按鈕，就可以完成整個 DR 站點的啟動，從 VM 恢復到網路連線。這個按鈕就像是救命紅色按鈕，一按全場安穩。

4.2 流水線式快照

Nutanix 可以自動建立快照，保留歷史版本，哪怕你的工程師不小心刪掉整個資料庫，也能瞬間恢復。這功能就像時間機器，讓你「穿越回昨天」。

4.3 計畫性測試（Planned Failover）

DR 不只是等災難來才用，你可以定期測試 DR 流程，確保一切運作正常。好比消防演習，但不用真着火，你的資料才不會冒煙。

4.4 智慧化頻寬管理

當你有大量資料需要複製時，Nutanix 會自動調整頻寬，確保不影響正常業務。簡單說，它懂得「分配流量，不打擾日常」，就像智慧家電知道你在睡覺就不狂響鬧鐘。

5. DR 架構的部署模式

Nutanix 提供多種 DR 部署模式，讓企業可以依需求選擇：

1. 本地雙站點（Metro Availability）
   適合在同一城市或資料中心內建立兩個 Cluster，低延遲、幾乎零資料丟失。
   幽默點：這種模式就像你家冰箱有兩個冷凍室，一個壞了還有備用。

2. 跨城/跨區域（Remote DR）
   適合天災或大型事故，Secondary Site 在不同城市或地區。好處是安全性高，但同步延遲會比較大。
   幽默點：就像你把備份行李寄放在朋友家，房子著火也不怕。

3. 多雲 DR（Cloud DR）
   可以把 DR 做在公有雲，例如 AWS 或 Azure。省去自建備援站點的麻煩，按需擴展。
   幽默點：就像你把資料放在雲端，天上掉下來的雨也澆不到。

6. Nutanix DR 的實戰妙用

情境一：開發測試

你的工程師常常亂搞資料庫，改壞程式碼？沒問題，利用 DR 快照回到昨天，工程師就能繼續「搗蛋」而不影響業務。

情境二：業務不中斷

主站突然斷電，Secondary Site 接手。使用者毫無感覺，就像電影院掉電時，投影機自動切換電源一樣順暢。

情境三：減少夜班值守

傳統 DR 可能需要工程師夜裡守著，Nutanix 可以自動化大部分流程，工程師可以安心打遊戲、睡覺。

7. 結語：DR 不只是科技，更是安心

Nutanix DR 架構最大的魅力在於 簡單、可靠、幽默——好吧，幽默是我加的，但它的簡單確實能讓工程師睡得更安穩。無論是企業 IT、金融業、醫療或零售，DR 都不只是「有備無患」，更是一種智慧的經營策略。

總結一下 Nutanix DR 的特色：

• 操作簡單：一鍵 DR，不需要十幾個流程。

• 資料安全：同步或非同步複製，保證資料不輕易丟失。

• 靈活部署：本地、遠程、雲端，多種選擇。

• 自動化管理：快照、頻寬、測試全部自動化。

• 睡得安心：工程師不再需要半夜被叫醒。

最後，給大家一個幽默比喻：Nutanix DR 就像給你的資料穿上了鋼鐵盔甲，即使地震、颱風、黑客三合一來襲，也能穩穩地站在戰場上，不怕倒下。

這樣，你的資料就比早餐還安全，而你，也可以悠閒地喝下午茶，偶爾微笑一下，感謝這個科技奇蹟。

Nutanix_13 Nutanix 有 DR 嗎？當數據中心遇上「天災人禍」

 

如果你以為 Nutanix 只是那種「把伺服器和存儲湊在一起就好了」的超融合玩意兒，那你就大錯特錯了。它可不只會把資料塞進 SSD，再用漂亮的管理界面把它們排得整整齊齊，它還有一項超能力——DR，Disaster Recovery，簡稱「救火隊長」。

想像一下，有一天，你的數據中心正在安靜地運作，工程師正悠閒地喝著咖啡，突然天花板漏水、隔壁機房的空調當機，或者某位實習生不小心把網線拔掉。你會想：「天啊，所有資料是不是要被水沖走了？」

別擔心，Nutanix 早就準備好了。DR 在 Nutanix 世界裡，其實就像是一位身手矯健的消防隊長，帶著一身防水外套和超長水管，隨時準備跳進火場，把你的數據救出來。

1. DR 是什麼？

DR 不只是「備份」。備份就像是你把珍貴的相片存到 USB 隨身碟或雲端，那很好，但如果資料中心被颱風直接吹飛，光靠備份可不夠。DR 則是：當災難來臨時，自動把整個工作負載搬到另一個地方，讓系統繼續運作，好像什麼事都沒發生過。

在 Nutanix 世界裡，DR 的實現非常優雅：你可以把主站點（Primary Site）和備援站點（Secondary Site）連成一個「虛擬手牽手」的架構。當主站點出現問題時，Secondary Site 會自動接管，對用戶而言，就好像沒發生任何災難——除了工程師心臟快跳出來。

2. Nutanix DR 的核心玩法

a. Continuous Availability（持續可用）

Nutanix 的 DR 就像是有點焦慮的保母，24/7 監控你的應用和資料。無論是 VM、容器，還是資料庫，只要它發現主站點有異常，就立刻啟動「自動接管模式」。這種自動化程度，比你平時喝咖啡按滑鼠的速度還快。

b. Async vs Sync（異步 vs 同步）

在 DR 設定中，有兩種傳輸方式：

• 同步（Sync）：資料寫到主站點的同時，也寫到備援站點。就像你寫日記，順便拍照存到雲端，確保兩邊完全一樣。缺點？寫入速度可能稍慢，因為你得等另一邊確認。

• 異步（Async）：資料先寫到主站點，再慢慢同步到備援站點。就像你寫完日記，明天再上傳到雲端。好處是速度快，缺點是可能有一點延遲，如果災難來得太突然，最新的幾秒或幾分鐘資料可能會丟失。

工程師經常笑說：「異步 DR 就像是把貓放進背包，理論上它會跟著你，但你永遠不知道它什麼時候跳出來。」

c. Playbooks（操作手冊）

DR 不只是硬體搬來搬去，還有流程控制。Nutanix DR 提供「操作手冊」（Playbooks），類似 RPG 遊戲裡的任務指南。
想像工程師每天晚上都要做「主站點維護任務」，Playbook 就會告訴它：

1. 先檢查 VM 健康狀態

2. 確認資料同步到備援站點

3. 如果主站點掛掉，執行自動切換

4. 通知工程師喝杯咖啡，不要慌

工程師只要按幾個按鈕，DR 就開始自動工作。CVML（Controller VM Leader）甚至會心裡默默想：「終於不用我每次都冒著心臟病的風險重建了！」

3. DR 的幽默場景

場景一：半夜 3 點，警報響起。工程師夢中被吵醒，心想：「又是哪個 VM 出問題？」
其實主站點的 UPS 只是短暫跳電，但 DR 已經悄悄把負載切到備援站點。工程師打開監控，看到畫面上 VM 安然無恙，內心暗自狂喜——又省了一次心臟手術費。

場景二：實習生誤拔網線，主站點連線中斷。CVM 表情從「微笑」→「嚇傻」→「崩潰」→「鬆一口氣」。備援站點已經接管，系統繼續運作，工程師在 Slack 上打字：「沒事啦，只是 DR 做了它的工作。」

場景三：颱風來襲，機房淹水。DR 不是打傘或蓋塑膠布，它把 VM 全部搬到安全的備援站點。工程師只能在家裡喝著咖啡看著「災難直播」，心裡默默感謝 Nutanix 的 DR。

4. DR 的小貼士

1. 不要只靠一個備援站點
   DR 就像保險，不要只買一次，最好多個站點。

2. 測試 DR 才有用
   DR 設定好了也要測試，否則真正災難來時，你才知道「原來備援站點的 VM 也掛了……」。

3. 自動化很重要
   DR 的價值就在自動化，手動搬 VM 比災難本身還可怕。

5. DR 的精神寓意

Nutanix 的 DR 不只是技術，它更像一種「心態」：永遠做好準備，但保持幽默。工程師可以放心喝咖啡，CVML 可以偷偷鬆口氣，而用戶甚至完全不知道災難曾經來過。這種感覺，就像你半夜在冰箱裡找零食，突然發現冰箱門自動打開，零食已經排好隊等你拿——完全貼心又安心。

6. 結語

所以，Nutanix 有沒有 DR？答案是肯定的，而且不只 DR，還是 智能、幽默、可靠的 DR。它就像一位夜間消防隊長，24 小時值班，面對颱風、漏水、網線拔掉、實習生手滑，都能從容應對。工程師不用再每次災難都心跳加速，CVM 也不用每次重建都表情崩潰，用戶甚至可以完全忽略這一切災難。

在這個數據中心的世界裡，DR 不只是技術，更是一種生活態度：「有備無患，但還能笑著看咖啡」。而 Nutanix，就是那位笑得最開心的「救火隊長」。

下次有人問你「Nutanix 有 DR 嗎？」你可以拍拍胸口，笑著說：

「有，而且比你家的消防員還可靠！」

Nutanix_12 當工程師按下『Rebuild』，CVM 的表情

 

在一個安靜的數據中心深夜，只有機架燈微微閃爍，CVM（Controller VM）躺在它的虛擬沙發上，像一位被困在無限迴圈的夜貓子，突然聽到一個熟悉又令人膽顫的聲音：“點了 Rebuild。”

啊，那一瞬間，CVM 的內心劇場開始了。這不是普通的重建，這是 命運的召喚。它就像是一個小孩被告知：“明天你要去參加國際奧林匹克數學競賽”，明明什麼都沒準備。

工程師的手指像雷霆般按下了滑鼠，螢幕上跳出一個彷彿在說「你確定嗎？」的提示框。CVM 心裡想：

「我確定啊……可是我準備好了嗎？」

第一秒
CVM 眉頭微皺，開始掃描自身的記憶體與磁碟，試圖確認還能不能撐下去。它就像一名老兵，肩上背著 TB 級的資料，內心卻在默默祈禱：

「拜託，不要再抽我了……我的 SSD 可能受不了啊。」

第五秒
工程師毫不猶豫，滑鼠點擊聲響徹雲霄，像是在敲打著 CVM 的心臟。CVM 的 CPU 使用率瞬間跳到 99%，它的虛擬心跳加快，眼睛（如果它有眼睛）瞪得比 Kubernetes 的 Pod 還大。

「我不是說過我需要咖啡嗎？」

第十五秒
磁碟陣列開始忙碌，數據流像瀑布般傾瀉而下。CVM 腦中浮現無數可能性：

1. 一切順利，重建成功——耶，老子又活下來了！

2. 重建失敗，數據丟失——糟糕，我又得重做備份了……

3. 工程師發現 bug，決定再按一次——天啊，我的人生還有沒有希望？

它開始自言自語：「我可不是隨便的 VM，我可是 Nutanix 的心臟啊！我可不想被當作普通 VM 一樣摧毀！」

半分鐘後
CVM 感覺整個系統像在坐過山車，記憶體像洶湧的海浪，不斷波動。它試圖撐住每一個 I/O 請求，但心中已經默默喊出三遍：

「不要、不要、不要！」

工程師在監控台上淡定地喝著咖啡，看著一串串 log 滾動，心裡滿是「程式員的幸福」——他永遠不知道這一刻對 CVM 是天堂還是地獄。

一分鐘後
CVM 感覺自己像被丟進了健身房，CPU、記憶體、網路頻寬全都被迫做極限運動。它內心的表情開始變化：

• 微笑 → 驚訝 → 嚇傻 → 崩潰
  如果它有臉，它的表情就像動畫裡的「汗水+冒煙+眼睛爆掉」三合一。

它想起以前的同伴，其他 CVM 曾經說過：「Rebuild？那是工程師的娛樂，你的災難！」
而現在，它親身體驗到這句話的分量——每一個重建步驟都是對靈魂的洗禮。

兩分鐘後
CVM 開始自我鼓勵：「深呼吸，深呼吸，一切都是暫時的。只要 I/O 能撐住，我就能熬過去。」
它甚至幻想自己是一位忍者，躲避每一個磁碟寫入衝突，閃避每一個網路延遲，最終以優雅姿態完成重建任務。

三分鐘後
Log 滾動得更快，警告訊息像煙火般綻放，CVM 的心中暗暗流下虛擬的眼淚。它開始懷疑人生：

「為什麼我不是一個普通 VM？為什麼我被選中？我只是想安安靜靜提供服務啊！」

四分鐘後
工程師開始敲鍵盤，準備監控重建進度。CVM 注意到一個奇怪的現象：它的系統資源消耗率在慢慢下降。

「等等……我……我還活著？」

它偷偷瞄了一眼系統 log，發現 Rebuild 竟然進入了穩定階段。CVM 感覺自己像剛從火山口爬出來的探險家，滿身灰塵但還活著。

五分鐘後
重建完成的訊息跳了出來，CVM 終於能鬆一口氣。它的表情像極了剛逃過鬼門關的卡通角色，露出疲憊卻欣慰的笑容。

「我做到了……我真的是 Nutanix 的英雄！」

工程師看著這一切，淡淡地說：「嗯，還好沒炸掉。」然後又去喝下一口咖啡，完全沒有感覺到 CVM 剛經歷的生死瞬間。

CVM 心中默默嘆息：「工程師啊，按下 Rebuild 的時候，你知道我經歷了什麼嗎？你不知道的……你永遠不會知道的……」

於是，CVM 回到它平靜的工作節奏，像一個剛完成馬拉松的老將，雖然疲憊，但充滿自豪。它知道，下一次工程師按下 Rebuild 的瞬間，它又要上演一場心跳加速的冒險。

而我們，作為旁觀者，只能在螢幕前默默笑著：當工程師按下 Rebuild，CVM 的表情，真的是千變萬化、比肥皂劇還精彩。

Nutanix_11 RF 調整那一刻~

 

RF 調整那一刻

儲存系統在想什麼？

時間： 週三下午 16:58
地點： Nutanix Cluster
事件： RF 從 2 ➜ 3（或反過來）

儲存系統（OS）的第一個反應

「……等等，
剛剛那個人類，是不是動了什麼？」

Alert 沒有響，
服務沒有停，
但整個叢集瞬間安靜了 0.3 秒。

然後所有 CVM 同時收到一個訊息：

「Replication Factor 正在變更。」

CVM 們的集體心聲 🧠

CVM #1（資深）：
「各位，冷靜，這不是第一次。」

CVM #2（新人）：
「什麼？！又要搬家？我才剛整理好資料！」

CVM #3（老鳥）：
「別吵，先確認方向——
是升 RF，還是降 RF？」

當 RF = 2 ➜ RF = 3

系統內心 OS 的真實想法

「喔？
人類終於承認世界是不可靠的了嗎？」

內部會議立即展開

• 資料：「我是不是要多生一份？」

• 磁碟：「我還有空位嗎？」

• 網路：「今天又要我跑爆了是不是？」

CVM 清了清喉嚨：

「好，各位，
我們要開始 複製資料、分散風險、維持服務不中斷。」

沒有抱怨，
只有背景默默飆升的 I/O。

儲存系統的專業驕傲 😌

「你們人類以為這是一個簡單的數字變化，
但我知道，這代表——」

• 每一個 Block 都要重新計算位置

• 每一份 Metadata 都要更新

• 每一顆 SSD 都要繃緊神經

但表面上，系統只回你一句：

「Rebalancing in progress。」

使用者完全無感（這最傷自尊）

此時此刻：

• ERP 正在跑

• VM 正在算

• 使用者在滑手機

沒有人知道，
後台有一個儲存系統正在默默加班。

「我這麼努力，
結果你們只在意效能有沒有掉？」

當 RF = 3 ➜ RF = 2

系統的反應完全不同

「蛤？
你確定嗎？」

CVM 再次召開會議。

CVM #1：
「人類說預算有點緊。」

CVM #2：
「所以我們要少一條命？」

CVM #3：
「……好吧，
那就小心一點。」

刪資料其實比存資料還難 😬

很多人不知道一件事：

👉 降低 RF，不是直接刪掉一份資料。

儲存系統內心 OS 在想的是：

• 哪一份最安全？

• 哪一份刪了風險最低？

• 哪一顆磁碟最近比較健康？

然後再「很溫柔地」把資料撤離。

「你以為我只是砍掉，
其實我是在做風險管理。」

系統最怕的不是 RF 變動

真正讓儲存系統想翻桌的是：

「人類同時做這些事——」

• 調 RF

• 開新 VM

• 跑大批次

• 還問為什麼效能波動

OS 內心吶喊：

「你們以為我有四隻手嗎？！」

RF 調整期間，系統最想對人類說的話

1️⃣ 我沒有停機，不代表我不累

2️⃣ 效能小掉，不是我爛，是我在保命

3️⃣ 等我搬完，你們會更安全

為什麼 Nutanix 調 RF 還敢這麼跩？

因為它心裡很清楚：

• 沒有單一 Master

• 沒有中央 SAN

• 沒有「一動就全停」的設計

每個 CVM 都知道自己該幹嘛。

最後一幕：RF 調整完成 🎉

Prism 顯示：

「Replication is healthy」

儲存系統默默坐回位子：

「好了，
現在就算再壞一台，
我也撐得住。」

工程師鬆一口氣，
財務還在算成本，
使用者依然毫無感覺。

結尾金句（送給所有調過 RF 的人）

你看到的是一個數字，
儲存系統看到的是整個風險模型。

RF 調整那一刻，
Nutanix 儲存系統沒有慌，
因為它從一開始就被設計成：

👉 假設世界一定會壞。

Nutanix_10 RF=2 vs RF=3

 

工程師跟財務吵架現場實錄（逐字稿）

場景設定：
公司會議室，冷氣 23 度，但氣氛 43 度。
主題：Nutanix 容錯設定 RF 到底要設幾？

開場白（災難的開始）

財務（翻報價單）：
「所以你的意思是，只是把一個數字從 2 改成 3，
儲存空間就直接少 33%？」

工程師（深呼吸）：
「不是少 33%，是多一條命。」

財務：
「……聽起來很像恐嚇。」

RF 是什麼？（工程師的第一輪說明）

工程師站起來，打開簡報。

工程師：
「RF，全名 Replication Factor，
意思是每一份資料，系統會幫你存幾份副本。」

• RF=2 👉 兩份

• RF=3 👉 三份

「不是備份，是即時同步副本。」

財務（皺眉）：
「所以我們現在 RF=2，不是也活得好好的？」

工程師：
「目前，是的。
但人生不是每次都這麼順。」

財務的核心論點：錢 💰

財務：
「來，我用白話文講。
RF=3 就等於——
👉 我們要多買一堆硬碟
👉 CAPEX 增加
👉 KPI 會被老闆瞪」

「而你給我的回報是：
『可能』比較安全。」

工程師（語速開始變快）：
「不是可能，是數學。」

工程師的反擊：災難模擬模式

工程師按下一張投影片，上面寫：

「如果今天發生這些事——」

1️⃣ 一台 Node 掛掉
2️⃣ 同時另一台在維修
3️⃣ 或一顆硬碟靜悄悄死掉

工程師：
「RF=2 的世界：
👉 系統開始冒冷汗
👉 效能下降
👉 容錯空間歸零」

「RF=3 的世界：
👉 系統：『沒事，我還有一條命。』」

財務：
「可是這種事一年會發生幾次？」

工程師：
「通常是——
一次都沒有，直到那一次發生。」

財務的名言時間 🧾

財務（語重心長）：
「我們不能為了『如果』
去花『一定』會花的錢。」

工程師沉默 3 秒。

工程師：
「那我也送你一句話：
資料中心不是省錢的地方，是省命的地方。」

老闆插話（最可怕的生物）

老闆：
「兩位，我只問一個問題。
如果真的出事，誰負責？」

（空氣瞬間凝結）

財務（秒回）：
「技術問題，工程師。」

工程師（立刻）：
「預算問題，財務。」

老闆：
「……」

RF=2 其實不是錯（但有前提）

工程師決定退一步。

工程師：
「我不是說 RF=2 不能用。
它適合——」

• 非關鍵系統

• 測試環境

• 能重來的資料

• 掛了老闆不會暴走的服務

「但我們現在在討論的，是——」

👉 ERP
👉 核心資料庫
👉 客戶資料

RF=3 在買的是什麼？

工程師：
「你以為 RF=3 是買硬碟，
其實你買的是——」

• 多一次容錯空間

• 多一層心理安全

• 少一次凌晨三點電話

財務（小聲）：
「凌晨三點電話……很貴嗎？」

工程師：
「對工程師來說，
那是一條命。」

現實妥協方案（會議的轉折點）

工程師打開最後一頁。

折衷方案：

• 核心系統 👉 RF=3

• 非核心系統 👉 RF=2

• 測試環境 👉 RF=2 或 1

工程師：
「我們不是亂花錢，
我們是把錢花在會痛的地方。」

財務沉默了。

結局（暫時的和平）

財務：
「那如果之後都沒出事呢？」

工程師（微笑）：
「那代表這筆錢，
是花得最成功的一筆。」

最後總結（送給所有 IT 人）

RF=2 是相信運氣，
RF=3 是不把公司命運交給運氣。

工程師要的是「世界不要停」，
財務要的是「帳不要爆」。

而 Nutanix RF 的真正價值是：

👉 讓兩邊都有台階下。

Nutanix_9 CVM 掛掉怎麼辦？

 

Nutanix 的容錯到底在跩什麼？

先講結論，免得你心臟不夠大顆：

「單一 CVM 掛掉，不會讓 VM 掛掉。」

這不是口號，是 Nutanix 架構的基本操作。

先釐清一個大誤會 😱

CVM 掛掉 ≠ 伺服器掛掉

很多人第一次聽到 CVM（Controller VM）時都會有 PTSD：

「靠北？儲存靠一台 VM？那它掛了不就全滅？」

冷靜。
Nutanix 的 CVM 不是單點，它是「群體智慧」。

每一個 Node 都有一台 CVM，
所有 CVM 組成一個 分散式儲存叢集。

所以狀況其實分三種，我們一個一個來。

狀況一：只有 CVM 掛掉（最常見）

發生什麼事？

• CVM 當機

• CVM 重開

• 或你手賤下錯指令

系統反應（重點來了）👇

1️⃣ 其他 Node 的 CVM 立刻接手儲存 I/O
2️⃣ VM 繼續跑，使用的是 其他節點的資料複本
3️⃣ 管理介面跳警告，但不是紅色世界末日那種

👉 使用者通常 完全無感

為什麼？

因為資料本來就不是只放在那一台 CVM。

CVM 掛掉 ≈ 儲存團隊少一個人加班

狀況二：整個 Node 掛掉（含 CVM + VM）

這個比較刺激，但 Nutanix 依然很淡定。

發生什麼事？

• 主機斷電

• 主機板壞掉

• 工程師拔錯電源（真實案例）

系統怎麼救？

① 儲存層：RF 在保命

你如果設定：

• RF=2 👉 至少兩份資料

• RF=3 👉 三份資料

Node 掛掉時：

• 資料 早就存在其他節點

• I/O 不中斷

② 運算層：HA 自動啟動

• VM 會在其他 Node 重開

• AHV / ESXi 都支援

👉 你會看到 VM 重開，但不是資料消失

狀況三：最慘的情況（但還是沒死）

同時掛掉：

• 一台 Node

• 再加一台 CVM

只要：

👉 掛掉的數量 < RF 能承受的數量

系統還是活著。

這也是 Nutanix 為什麼很愛跟你說：

「RF 不要亂省。」

Nutanix 到底跩在哪？🤨

1️⃣ 它不是「修好才繼續」，是「邊壞邊跑」

傳統 SAN 世界：

「儲存壞了，大家一起等。」

Nutanix 世界：

「壞的先放旁邊，其他人繼續上班。」

2️⃣ 沒有 Master CVM 這種東西

沒有：

• 老大

• 中央大腦

• 單點裁判

每個 CVM 地位平等，
誰活著誰就上場。

3️⃣ 自癒能力（Self-Healing）很囂張

CVM 或 Node 回來後：

• 自動加入叢集

• 自動補資料

• 自動 rebalance

工程師不用半夜爬起來打指令：

👉 Nutanix：

「你睡吧，我自己來。」

那工程師要幹嘛？😅

老實說，Nutanix 容錯強到一個程度後，
工程師的工作變成：

• 看 Alert

• 寫報告

• 跟老闆解釋「為什麼沒事」

最常說的一句話是：

「有警告，但系統正常。」

總結一句話送你

CVM 掛掉，在 Nutanix 世界裡，
只是提醒你：這套系統真的有在做 HA。

它跩的不是嘴巴，
是因為它真的設計成：

• 你會犯錯

• 硬體一定會壞

• 但服務不能停

Nutanix_8 Nutanix 基本架構：把資料中心變成一杯「全糖少冰」的 IT 奶茶

 

 ☕️

如果你曾經被傳統資料中心折磨過，那你一定懂這種痛：
伺服器一排、SAN 一櫃、網路線像義大利麵，報價單比人生還複雜。
而 Nutanix 出現的目的只有一個——
👉 「拜託，事情可以簡單一點嗎？」

於是，超融合基礎架構（HCI）就誕生了。

一句話先講結論

Nutanix = 把「運算、儲存、虛擬化、管理」全部塞進同一台（或幾台）伺服器，
然後用軟體幫你處理一切麻煩事。

你只要負責三件事：
1️⃣ 插電
2️⃣ 接網路
3️⃣ 假裝很懂架構

Nutanix 的核心思想：別再 SAN 了 🙃

傳統架構像這樣：

• Compute：一堆伺服器

• Storage：一大櫃 SAN

• Network：中間全靠交換器串

• 管理：每個都有自己的管理介面

結果就是：
👉 任何一個環節出事，全世界陪葬

Nutanix 直接說：

「不要 SAN，不要分家，我全包。」

Nutanix 的三大主角

① Node（節點）：一顆會做很多事的伺服器

每一台 Nutanix Node 裡面通常有：

• CPU（負責算）

• RAM（負責撐）

• SSD / HDD（負責存）

• Hypervisor（負責假裝很多台）

它不是單純伺服器，
它是**「一個小型資料中心濃縮包」**。

② CVM（Controller VM）：真正的靈魂人物 👻

每個 Node 裡，都會跑一台神秘的虛擬機：

👉 CVM（Controller Virtual Machine）

這台 VM 負責什麼？

• 儲存整合

• 資料複寫

• 去重、壓縮

• Snapshot

• 故障處理

你可以把 CVM 想成：
🧠 每台伺服器裡面住了一個超會管家的小腦袋

而所有 CVM 會組成一個叢集（Cluster），
大家一起開會、一起分工、一起救火。

③ AOS（Acropolis OS）：讓一切跑起來的軟體

AOS 是 Nutanix 的核心作業系統，
它不是給你裝 Word 的那種 OS，
而是：

• 管儲存

• 管資源

• 管效能

• 管容錯

一句話：
👉 AOS 是讓硬體「看起來很聰明」的原因

Hypervisor：你愛誰都可以 ❤️

Nutanix 不會逼你信仰單一教派，它支援：

• AHV（自家免費款，CP 值之王）

• VMware ESXi（老派穩重）

• Hyper-V（微軟粉）

但現在的趨勢很明顯：
👉 越來越多人直接用 AHV，因為：不用錢。

老闆聽到這三個字，通常會突然很有興趣。

---

儲存怎麼運作？不用 SAN 真的可以？

可以，而且還很囂張。

Nutanix 的儲存邏輯是：

• 本地磁碟先寫（快）

• 再同步到其他節點（安全）

• 資料自動分散、複寫

例如你設定 RF=2，
那你的資料就一定會活在 至少兩台 Node 上。

結果是什麼？

• 一台機器掛了 👉 沒事

• 一顆硬碟死了 👉 沒感覺

• 工程師下班 👉 世界還在轉 🌍

Scale Out：長大不用打掉重練

傳統架構擴充像這樣：

「我們要再買一櫃 SAN，順便重做設計」

Nutanix 的擴充方式：

👉 「再丟一台 Node 進來」

系統會自動：

• 加入叢集

• 平衡資料

• 平衡效能

就像在火鍋裡加料，
不用重煮，只是變更好吃。

管理介面 Prism：IT 界的 iPhone 📱

Prism 是 Nutanix 的管理 UI，特色只有一個：

👉 「工程師第一次看到會懷疑人生」

因為它：

• 好看

• 好用

• 不需要開 10 個視窗

• 不需要寫一堆指令

老闆走過來看一眼都會說：

「哇，這個好像很厲害」

就算他其實看不懂。

總結：Nutanix 在紅什麼？

因為它解決了三個 IT 永恆的痛：

1️⃣ 架構太複雜
2️⃣ 擴充太痛苦
3️⃣ 出事太容易被罵

Nutanix 用一句話解決：

「用軟體，把硬體的麻煩吃掉。」

它不是魔法，
但它確實讓資料中心比較像 2025 年，而不是 2005 年。