好吧，所以我想開始比以前更多地利用 SAN，同時利用 ESXi。
目前，我有一個連接到單機櫃 EMC AX4-5 FC 儲存陣列的 Dell PowerEdge 1955 刀片陣列。我本質上是使用 SAN 作為 DAS。我在 SAN 上有指向特定實體機器的 LUN，這些機器將 LUN 用於任何用途（主要是資料庫和 Samba/NFS 共享，取決於目標伺服器）。
我有多個實體檔案伺服器，每個伺服器都有一個 samba 設定設定來為適當的共用提供服務。由於我從未讓 RHCS 正常工作，因此一次只有一台檔案伺服器掛載了 LUN。如果檔案伺服器當機，我會手動隔離（透過卸載並取消顯示磁碟機、使用 navisphere 公用程式或透過 DRAC 切斷電源），然後使用 navisphere 公用程式在下一個競爭者上啟動所顯示的 LUN（之後，啟動apache和其他守護程式）。一切都靠手工，現在。
我覺得有點像費里斯·布勒（Ferris Bueller）演奏單簧管。從來沒有上過課！
無論如何，我正在努力改進。我想要做的是在實體主機上安裝 ESXi，然後建立 LUN 來保存兩個檔案伺服器映像（以防一個損壞/fubar），其中一個將是活動的，另一個將是備用的。至少這樣，我不會改進自動化（儘管我很快就會開始編寫一個腳本來切換“活動”伺服器），但我覺得我增加了靈活性，而且我可以使用ESXi主機來容納其他虛擬機，並且硬體不會像現在一樣被浪費。
我的問題是：
1）我的計劃有多愚蠢？
2) 當涉及到實際實作時，我應該在 LUN 上建立一個普通的 vmdk 映像，還是應該給它一個「原始」分割區（如果 ESXi 可以這樣做的話？）
3）是否有使用非叢集檔案伺服器的「好」方法？
答案1
你的計劃並不瘋狂。像往常一樣，根據您想要實現的目標以及如何保護數據，有多種方法可以解決此問題。
首先，您可以使用「原始裝置對應」向虛擬機器提供原始 LUN。去做這個：
- 將 LUN 提供給 ESXi 主機（或主機群組，如果您要使用叢集/HA）
- 將磁碟新增至您的虛擬機，選擇裸設備映射，指向 LUN
- 重新掃描VM內的SCSI匯流排
- fdisk，掛載並新增到fstab，就像普通磁碟一樣。
優點：設定快速、使用快速、簡單，如果您發現自己需要 V2P，可以將磁碟表示為實體主機
缺點：您可能會遺失一些基於 VMware 的快照/回滾選項，具體取決於您使用實體還是虛擬相容模式
另一種選擇是在 LUN 上建立 VMFS 以建立資料存儲，然後將 VMDK 磁碟新增至位於該資料儲存體上的 VM。
- 優點：如果您購買了使用它的許可證，它對 Storage vMotion 是友好的。這允許 VMDK 磁碟在 LUN 甚至 SAN 之間進行熱遷移。
在這兩種情況下，如果 VMware 或您的虛擬機器在故障期間佔用檔案系統，您將面臨類似的風險。儘管可用的恢復選項會有很大不同，但其中一個並不比另一個好得多。
除非必要，否則我不會部署 RDM；我發現他們並沒有為我帶來太多作為 VMDK 的靈活性（而且我已經被蟲這使得它們在執行其他儲存操作時不切實際（自已修復 - 請參閱該連結中的 RDM 部分））
對於您的 VM，靈活性的最佳選擇是將檔案伺服器的啟動磁碟作為 VMDK 儲存在 SAN 上，以便在主機發生故障時可以讓其他主機啟動它。使用VMware的HA功能，在另一台主機上啟動VM是自動的（VM將在第二台主機上啟動，就像電源已被拔掉一樣；期望執行通常的fsck和魔術來將其啟動，就像普通伺服器一樣）。請注意，HA 是一項許可功能。
為了緩解 VM 故障，您可以建立檔案伺服器的輕型克隆，其中包含啟動所需的最低限度的要求，並使 SAMBA 在配置狀態下啟動，並將其儲存在每個主機的本機磁碟上，等待您從VM 故障並啟動它。
這可能會也可能不會為您在 SAN 發生故障時提供額外的選擇；最好的情況是，您的資料儲存將需要進行 fsck 或其他修復，但至少您不必在頂部修復、重建或配置虛擬機器。最糟糕的情況是，您丟失了資料並需要返回磁帶......但無論如何您已經處於該狀態。
答案2
我會堅持使用 vmdk 映像，以防萬一您將來轉而使用 vmotion，您永遠不知道您可能會獲得預算。
如果您的電腦沒有集群，那麼就我而言，管理它們的最佳方法是嘗試盡可能均勻地分散負載。我有 3 個非叢集 2950，其中來自最關鍵虛擬機的負載盡可能為每個 1/3。理論上我不太可能同時丟失多個盒子，因此至少 2/3 將能夠繼續運行而不受影響。
從電源供應器的角度來看，將機器加載到盡可能接近 100% 並關閉其他機器可能會更有效，但對我來說，這似乎把所有雞蛋放在一個籃子裡。
我不會稱自己為這方面的專家，這只是我所做的。
答案3
嘿馬特。使用虛擬化解決方案時，有多種方法可以對解決方案進行分割。首先，有許多基準測試顯示原始 LUN (RDM) 與 VMDK 效能的比較，且差異通常可以忽略不計。使用 RDM 需要注意的一些事項： 只有某些叢集情況需要使用 RDM（MS 叢集）。 RDM 有 2TB 限制，但 LVM 可用來解決此限制。與向 ESXi 提供用於 VMFS 的 LUN 並在其上放置 vmdk 相比，RDM 更「難以」追蹤。 VMDK（如上所述）有一些很好的好處：svMotion、快照（無法對 pRDM 進行快照）。
如果運行免費 ESXi，我可能會按照以下方式處理您的情況。首先，所有資料都位於 VMFS LUN 上的 vmdk 檔案中。設定 2 個虛擬機器並使用 Heartbeat 進行 IP 和服務的故障轉移。 Heartbeat 將轉移服務 IP，並可以處理腳本以在適當的情況下卸載/安裝資料 LUN。您甚至可以編寫一些 VMware Remote CLI 腳本來確保「關閉」的虛擬機器關閉電源以進行防護。透過心跳直接在系統之間進行協調，存取資料 lun/運行相同服務的風險應該非常低。這裡的關鍵是確保資料 LUN 的掛載/卸載以及服務的啟動/關閉由 Heartbeat 處理，而不是正常的 init 機制。
替代的故障轉移可以透過監控系統來完成。當它偵測到主機故障時，它可以使用 VMware Remote CLI 發出關閉電源（為了安全起見）的命令，然後開啟備份虛擬機器的電源。在這種情況下，故障恢復是相當手動的。
在我的「微小」環境中，我還沒有看到 VMDK 被損壞。我還逐漸意識到，如果您有超過 2 台 ESX(i) 主機或十幾台虛擬機，您將需要使用 vCenter 來幫助追蹤一切。考慮到好處，一些 Essential/Plus 套餐的成本並不算太高。
答案4
我認為你應該問自己“我是否計劃回到實體伺服器”
如果答案是“也許”，那麼也許您應該堅持使用 RDM。具有 RDM 的 ESXi（我認為）需要您購買一些東西才能使光纖正常工作（在 esxi 上也不能 100% 確定）。
我們有幾台機器，我剛剛使用 RDM 快速從實體伺服器遷移到 ESX (4.0)。我混合使用了 Linux 和 Windows 機器（對於這兩個平台來說都非常簡單）。我們仍然有一些在實體伺服器上運行舊版 FreeBSD（6.0 及更早版本），我們無法使用 RDM，因為舊的 FBSD 核心不支援這一點。它很快，除了指向我的 LUN 然後安裝 VMWare 工具之外，我不需要做任何事情。腦死很容易..沒有轉換器沒有大驚小怪...
您應該問自己的另一件事是“我想使用 VMWare 的哪些功能？”
根據您的回答，除了 VMDK 之外您可能別無選擇。例如，如果您使用 SAN 進行快照，並且不關心使用 vmware 進行快照。
我將與您分享一些關於我們迄今為止遇到的問題的說明。轉到VMDK 很糟糕只需使用轉換器即可。備份應用程式運行得非常好，並且不受 vmware 的影響，但做的事情沒有我們希望的那麼多。我強烈推薦參加 vmware 的課程。我花了一周的時間，每一分錢都值得。 ....） ），但一旦我得到他們，他們總是會提供快速可靠的支援。