簡(jiǎn)介FusionCompute實(shí)驗(yàn)手冊(cè)1是華為HCIP-Cloud Computing V4.0認(rèn)證培訓(xùn)的官方實(shí)驗(yàn)指導(dǎo)材料面向備考該認(rèn)證的學(xué)員以及希望系統(tǒng)掌握華為服務(wù)器虛擬化平臺(tái)FusionCompute運(yùn)營(yíng)與運(yùn)維技能的工程師。手冊(cè)圍繞7個(gè)實(shí)驗(yàn)、四個(gè)部分展開先在KVM虛擬化嵌套環(huán)境中完成從CNA到VRM的環(huán)境搭建理解FusionCompute基礎(chǔ)架構(gòu)再練習(xí)計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)三類資源池管理體會(huì)計(jì)算虛擬化、存儲(chǔ)虛擬化與網(wǎng)絡(luò)虛擬化的核心能力隨后進(jìn)入虛擬機(jī)發(fā)放與管理涵蓋虛擬機(jī)創(chuàng)建、Tools安裝、模板封裝與導(dǎo)入導(dǎo)出、快照、規(guī)格調(diào)整、HA、熱遷移、安全組與規(guī)則組等業(yè)務(wù)運(yùn)維要點(diǎn)最后是用戶管理、管理數(shù)據(jù)備份與時(shí)間管理等常見運(yùn)維實(shí)驗(yàn)。資源包僅含1個(gè)docx文檔約10.53MB結(jié)構(gòu)完整、實(shí)驗(yàn)步驟與拓?fù)渑渲谜f明齊備適合對(duì)照搭建實(shí)驗(yàn)環(huán)境并逐項(xiàng)動(dòng)手驗(yàn)證也可作為日常運(yùn)維與故障排查的參考。目前已有227人學(xué)習(xí)。1. 兩臺(tái)服務(wù)器、七個(gè)實(shí)驗(yàn)這套 FusionCompute 6.5 手冊(cè)適合誰機(jī)架上擺著兩臺(tái)剛上架的服務(wù)器CNA 已經(jīng)裝完瀏覽器卻怎么也打不開 VRM 的 8443 登錄頁——這是很多人第一次接觸 FusionCompute 實(shí)驗(yàn)手冊(cè)時(shí)的真實(shí)開場(chǎng)。這套 HCIP-Cloud Computing V4.0 配套的 FusionCompute 實(shí)驗(yàn)指導(dǎo)手冊(cè)圍繞 6.5.0 版本把內(nèi)容拆成七個(gè)實(shí)驗(yàn)、四大部分環(huán)境搭建、虛擬資源管理、虛擬機(jī)發(fā)放與管理、常見運(yùn)維。它的價(jià)值不在于講清虛擬化概念而在于給你一條從 ISO 引導(dǎo)到資源池可用的完整路徑每一步都有界面位置和參數(shù)可對(duì)。適合三類人準(zhǔn)備認(rèn)證考試、需要把實(shí)驗(yàn)環(huán)境跑通的學(xué)員手上有一批服務(wù)器、想先在小環(huán)境驗(yàn)證 FusionCompute 可行性的運(yùn)維以及從其他虛擬化平臺(tái)轉(zhuǎn)過來、需要快速摸清 CNA 與 VRM 邊界的老手。下面按我實(shí)際復(fù)現(xiàn)的順序拆。2. 從 ISO 到 8443 可登錄CNA 與 VRM 的嵌套安裝鏈路手冊(cè)開篇給了一個(gè)很具體的場(chǎng)景某企業(yè)想減少硬件投入先拿兩臺(tái)服務(wù)器搭一套 FusionCompute驗(yàn)證業(yè)務(wù)跑在虛擬化上的可行性。這個(gè)設(shè)定決定了實(shí)驗(yàn)環(huán)境不是生產(chǎn)部署而是“能裝、能管、能遷移”的最小閉環(huán)。整條鏈路是先在物理機(jī)上跑 KVM再在 KVM 里開兩臺(tái)虛擬機(jī)當(dāng) CNA最后用安裝工具把 VRM 部署到其中一臺(tái) CNA 上。聽起來繞但這樣做的收益很直接環(huán)境可以快照回滾裝壞了重來只要幾分鐘不用重裝物理機(jī)。我一般把這條鏈路拆成三個(gè)檢查點(diǎn)CNA 的 8443 能不能打開、VRM 安裝向?qū)懿荒苓B上 CNA、VRM 登錄后能不能看到主機(jī)。三個(gè)點(diǎn)任何一個(gè)不通后面添加集群、掛存儲(chǔ)都是白費(fèi)。下面按這三個(gè)點(diǎn)倒推每一步的配置。2.1 為什么用 KVM 嵌套資源賬與網(wǎng)絡(luò)賬先算清嵌套虛擬化的第一個(gè)坑不在 FusionCompute而在宿主機(jī)的 CPU 虛擬化暴露方式。如果 KVM 虛擬機(jī)的 CPU 模式設(shè)成qemu64這類默認(rèn)模型CNA 裝完能啟動(dòng)但再往下創(chuàng)建虛擬機(jī)時(shí)會(huì)發(fā)現(xiàn)硬件虛擬化指令不可用虛擬機(jī)起不來。常見做法是把 CNA 虛擬機(jī)的 CPU 模式設(shè)成host-passthrough讓上層看到宿主機(jī)的完整指令集退一步也要用同一代 CPU 的命名模型保證兩臺(tái) CNA 的 CPU 特性一致否則后面做熱遷移會(huì)直接報(bào) CPU 不兼容。資源賬要提前算。實(shí)驗(yàn)環(huán)境里每臺(tái) CNA 我一般給 8 vCPU、16GB 內(nèi)存、120GB 系統(tǒng)盤VRM 給 4 vCPU、8GB 內(nèi)存、80GB 磁盤。低于這個(gè)數(shù)安裝過程能走完但再開兩臺(tái)業(yè)務(wù)虛擬機(jī)就很緊HA 和遷移實(shí)驗(yàn)會(huì)因?yàn)闆]有足夠空閑內(nèi)存而失敗。磁盤不要用精簡(jiǎn)置備的宿主盤疊太多層I/O 延遲會(huì)放大安裝過程會(huì)莫名卡在解壓階段。網(wǎng)絡(luò)賬更容易翻車。手冊(cè)給的地址規(guī)劃是管理網(wǎng)192.168.201.0/24、存儲(chǔ)網(wǎng)192.168.202.0/24CNA01 管理192.168.201.101、存儲(chǔ)192.168.202.101CNA02 對(duì)應(yīng).102VRM 管理地址192.168.201.100。在 KVM 里給每臺(tái) CNA 配兩張?zhí)摂M網(wǎng)卡分別橋接到兩個(gè)不同的虛擬交換機(jī)不要圖省事用 NAT 模式NAT 下 CNA 能出去但管理 PC 主動(dòng)連 CNA 的 8443 和安裝向?qū)У幕爻塘髁繒?huì)被擋住表現(xiàn)就是“向?qū)б恢碧崾具B接超時(shí)”。角色管理 IP存儲(chǔ) IP主要用途CNA01192.168.201.101192.168.202.101承載虛擬機(jī)、提供計(jì)算資源CNA02192.168.201.102192.168.202.102第二臺(tái)計(jì)算節(jié)點(diǎn)用于 HA 與遷移VRM192.168.201.100無管理平面Web 入口 8443管理 PC192.168.201.10無運(yùn)行安裝向?qū)?、瀏覽器訪問提示管理 PC 的地址不要和 VRM 計(jì)劃地址沖突安裝向?qū)?huì)在部署前做一次地址探測(cè)沖突時(shí)提示不直觀容易被當(dāng)成軟件包損壞。2.2 裝 CNA磁盤選擇、管理 IP 與 root 密碼的三個(gè)卡點(diǎn)CNA 的安裝介質(zhì)是FusionCompute 6.5.0_Installer.zip里的主機(jī) ISO。把 ISO 掛到 KVM 虛擬機(jī)的光驅(qū)啟動(dòng)后選擇安裝過程本身不復(fù)雜卡點(diǎn)集中在三處。第一處是磁盤選擇。安裝器會(huì)列出所有可用磁盤選中即格式化沒有二次確認(rèn)的機(jī)會(huì)。嵌套環(huán)境里經(jīng)常給 CNA 掛了兩塊盤一塊系統(tǒng)盤一塊準(zhǔn)備做本地存儲(chǔ)的實(shí)驗(yàn)盤選錯(cuò)就把實(shí)驗(yàn)數(shù)據(jù)清了。我一般先在 KVM 層面只掛系統(tǒng)盤裝完再加熱插盤減少誤選。第二處是管理網(wǎng)絡(luò)配置。主機(jī)名按CNA01、CNA02命名管理 IP 填手冊(cè)里的地址掩碼255.255.255.0網(wǎng)關(guān)填管理網(wǎng)段的網(wǎng)關(guān)。DNS 在純實(shí)驗(yàn)環(huán)境可以留空但一旦后面要配時(shí)間同步或者接認(rèn)證源沒有 DNS 會(huì)多繞一圈。存儲(chǔ)平面的 IP 不在安裝界面配等進(jìn)了 VRM 再做存儲(chǔ)接口這一點(diǎn)手冊(cè)的實(shí)驗(yàn)流程里是分開的別在安裝階段找存儲(chǔ) IP 的輸入框。第三處是 root 密碼復(fù)雜度。FusionCompute 的密碼策略要求長(zhǎng)度、大小寫、數(shù)字、特殊字符組合且不能包含用戶名。實(shí)驗(yàn)環(huán)境里很多人圖省事設(shè)Admin123安裝器接受但后面添加主機(jī)到 VRM 時(shí)可能觸發(fā)密碼過期策略表現(xiàn)是添加成功、過一會(huì)主機(jī)狀態(tài)變成“離線”。我一般在實(shí)驗(yàn)環(huán)境也設(shè)一個(gè)符合策略且不過期的密碼省掉后面排查時(shí)間。裝完重啟拔掉 ISO做三步驗(yàn)證管理 PC 上ping 192.168.201.101通ssh root192.168.201.101能登錄瀏覽器打開https://192.168.201.101:8443能看到 CNA 本地管理頁。第三步很多人會(huì)跳過但它能提前暴露證書和端口問題比等到 VRM 安裝向?qū)?bào)錯(cuò)再回頭查要省事。注意CNA 的 Web 管理頁和 VRM 的 Web 管理頁不是一個(gè)東西CNA 的 8443 只用于單機(jī)維護(hù)日常資源管理走 VRM 的 8443。兩臺(tái)設(shè)備同端口不同地址瀏覽器標(biāo)簽別開混。2.3 部署 VRMInstaller 向?qū)Ю锉仨殞?duì)齊的四個(gè)參數(shù)VRM 的軟件包是FusionCompute 6.5.0_VRM.zip部署靠安裝工具向?qū)瓿?。向?qū)茉诠芾?PC 上所以管理 PC 必須能同時(shí)訪問 CNA 的管理 IP 和計(jì)劃給 VRM 的地址。整個(gè)向?qū)Ю镉兴膫€(gè)參數(shù)值得停下來核對(duì)。第一個(gè)是目標(biāo) CNA 的管理 IP。向?qū)?huì)先連一臺(tái) CNA把 VRM 虛擬機(jī)部署到這臺(tái)主機(jī)上。實(shí)驗(yàn)環(huán)境填192.168.201.101。如果這臺(tái) CNA 之前被別的 VRM 管過向?qū)Э赡芴崾局鳈C(jī)狀態(tài)異常處理辦法是在 CNA 側(cè)清理殘留注冊(cè)信息或者換一臺(tái)干凈的 CNA 先部署。第二個(gè)是 VRM 軟件包路徑。解壓后的FusionCompute 6.5.0_VRM.zip不要改文件名向?qū)О垂潭野拿罂赡芴崾尽败浖袷讲徽_”。路徑里也不要有中文和空格Windows 管理 PC 上放在D:\fc\這類短路徑最穩(wěn)。第三個(gè)是 VRM 的管理 IP、掩碼和網(wǎng)關(guān)。填192.168.201.100、255.255.255.0、管理網(wǎng)網(wǎng)關(guān)。這個(gè)地址一旦確定后面改起來要進(jìn) VRM 后臺(tái)實(shí)驗(yàn)階段盡量一次填對(duì)。第四個(gè)是 VRM 虛擬機(jī)的磁盤位置。如果此時(shí)還沒有掛 IP-SAN向?qū)?huì)把 VRM 磁盤放在 CNA 的本地存儲(chǔ)里等后面加了共享存儲(chǔ)也不建議把 VRM 遷過去做實(shí)驗(yàn)VRM 自身依賴存儲(chǔ)的鏈路越簡(jiǎn)單越好。向?qū)芡旰鬄g覽器打開https://192.168.201.100:8443用默認(rèn)管理員賬號(hào)登錄首次登錄會(huì)強(qiáng)制改密碼。登錄后先看兩處系統(tǒng)管理里的服務(wù)狀態(tài)是否全部正常資源池里能否看到被部署的那臺(tái) CNA。這兩處正常環(huán)境搭建實(shí)驗(yàn)就算閉環(huán)可以進(jìn)下一章的資源池配置。3. 集群、IP-SAN 與精簡(jiǎn)磁盤把計(jì)算和存儲(chǔ)資源池化環(huán)境搭好后VRM 里只有一臺(tái)孤零零的主機(jī)既沒有集群也沒有共享存儲(chǔ)虛擬機(jī)只能放本地盤HA 和遷移都做不了。手冊(cè)第二部分要解決的就是把兩臺(tái) CNA 組成一個(gè)集群、把 IP-SAN 掛進(jìn)來、再創(chuàng)建一塊可被集群內(nèi)主機(jī)同時(shí)訪問的磁盤。這一章的順序不能反先集群后存儲(chǔ)先存儲(chǔ)接口后掃描 LUN先數(shù)據(jù)存儲(chǔ)后創(chuàng)建磁盤。順序反了界面上的按鈕會(huì)是灰的或者掃描結(jié)果為空。我復(fù)現(xiàn)時(shí)習(xí)慣把這一章當(dāng)成一次“資源池驗(yàn)收”集群里兩臺(tái)主機(jī)狀態(tài)正常、數(shù)據(jù)存儲(chǔ)掛載成功且兩臺(tái)主機(jī)都能看到、創(chuàng)建一塊精簡(jiǎn)磁盤并確認(rèn)使用率不是 100%。三個(gè)條件滿足后面發(fā)放虛擬機(jī)才有意義。3.1 建集群再加主機(jī)CPU 兼容性決定熱遷移上限集群在 FusionCompute 里不只是個(gè)文件夾它是資源調(diào)度和 HA 的邊界。同一集群內(nèi)的主機(jī)才能做虛擬機(jī)熱遷移跨集群只能關(guān)機(jī)遷移。創(chuàng)建路徑在 VRM 的“資源池”視圖新建集群時(shí)會(huì)給幾個(gè)策略開關(guān)HA、電源管理、計(jì)算資源調(diào)度。實(shí)驗(yàn)環(huán)境建議先把 HA 打開電源管理關(guān)掉計(jì)算資源調(diào)度保持默認(rèn)等虛擬機(jī)跑起來再按需調(diào)。添加主機(jī)時(shí)填 CNA 的管理 IP 和 root 密碼兩臺(tái)依次加。加第二臺(tái)時(shí)如果提示“主機(jī)已被其他集群管理”說明這臺(tái) CNA 之前注冊(cè)過先在 VRM 的主機(jī)列表里找殘留記錄刪掉或者在 CNA 后臺(tái)重置注冊(cè)狀態(tài)再重新添加。移動(dòng)主機(jī)用拖拽或“移動(dòng)到”都行刪除集群前必須先把集群內(nèi)主機(jī)移走否則刪除按鈕不可用這是界面上的硬約束不是 bug。CPU 兼容性是這一節(jié)最容易被忽略的點(diǎn)。嵌套環(huán)境里兩臺(tái) CNA 虛擬機(jī)的 CPU 模型如果一臺(tái)是host-passthrough、另一臺(tái)是命名模型集群能建起來虛擬機(jī)也能各自跑但一做熱遷移就失敗日志里提示 CPU 特性不匹配。常見做法是建集群前先統(tǒng)一兩臺(tái) CNA 的 CPU 模型或者把集群的 CPU 基線設(shè)成較低的那一代。這個(gè)坑在實(shí)驗(yàn)里不致命在生產(chǎn)里就是遷移窗口打不開血淚經(jīng)驗(yàn)往往來自第一次做主機(jī)維護(hù)。集群策略作用實(shí)驗(yàn)環(huán)境建議HA主機(jī)故障時(shí)在另一臺(tái)主機(jī)重啟虛擬機(jī)打開配合兩臺(tái) CNA 驗(yàn)證計(jì)算資源調(diào)度按負(fù)載在主機(jī)間遷移虛擬機(jī)默認(rèn)或關(guān)閉實(shí)驗(yàn)負(fù)載低開了看不出效果電源管理低負(fù)載時(shí)下電空閑主機(jī)關(guān)閉嵌套環(huán)境喚醒容易失敗3.2 IP-SAN 接入三步啟動(dòng)器號(hào)、端口綁定、掃描 LUN存儲(chǔ)接入是這套實(shí)驗(yàn)里操作步驟最多的一段。IP-SAN 走 iSCSICNA 作為 initiator存儲(chǔ)陣列作為 target中間要過三關(guān)啟動(dòng)器號(hào)唯一、存儲(chǔ)接口綁定正確、陣列側(cè)放通 initiator。第一步是修改 iSCSI 啟動(dòng)器號(hào)。CNA 安裝后自帶一個(gè)默認(rèn) IQN如果是克隆出來的虛擬機(jī)兩臺(tái) CNA 的 IQN 可能一模一樣陣列側(cè)看到兩個(gè)相同 initiator 會(huì)拒絕或只認(rèn)一個(gè)。在 CNA 后臺(tái)改啟動(dòng)器號(hào)文件把名字改成帶主機(jī)名后綴的唯一值再重啟 iSCSI 服務(wù)# 查看當(dāng)前啟動(dòng)器名克隆出來的 CNA 經(jīng)常兩臺(tái)完全一樣 cat /etc/iscsi/initiatorname.iscsi # 改成本機(jī)唯一的名字后綴用主機(jī)名區(qū)分 echo InitiatorNameiqn.2024-01.local:cna01 /etc/iscsi/initiatorname.iscsi # 重啟 iSCSI 服務(wù)讓新名字生效再確認(rèn)一次 systemctl restart iscsid cat /etc/iscsi/initiatorname.iscsi這段命令的關(guān)鍵在最后一行重啟后必須回讀確認(rèn)服務(wù)重啟失敗時(shí)文件已經(jīng)改了但進(jìn)程還用舊值表現(xiàn)就是“明明改了 IQN陣列側(cè)還是看不到新名字”。iqn.2024-01.local:cna01只是示例格式實(shí)際用哪一年的命名空間不影響功能關(guān)鍵是兩臺(tái)主機(jī)不能重復(fù)。第二步是配置端口綁定和存儲(chǔ)接口。在 VRM 的主機(jī)配置里找到存儲(chǔ)接口把存儲(chǔ)平面的網(wǎng)口和 IP 綁上去CNA01 填192.168.202.101CNA02 填192.168.202.102。綁定完成后在 CNA 后臺(tái)ping一下陣列的 iSCSI 業(yè)務(wù)地址通不過就別往下走先查 VLAN 和交換機(jī)端口。第三步是添加存儲(chǔ)資源并掃描。存儲(chǔ)類型選 IP-SAN填陣列的 iSCSI 目標(biāo) IP 和端口3260CHAP 認(rèn)證實(shí)驗(yàn)環(huán)境可以不配。掃描存儲(chǔ)設(shè)備后應(yīng)該能看到陣列上劃好的 LUN選中 LUN 添加數(shù)據(jù)存儲(chǔ)命名DS01塊大小保持默認(rèn)。如果掃描結(jié)果為空按順序查三處CNA 到陣列網(wǎng)絡(luò)通不通、陣列側(cè)有沒有把 CNA 的 IQN 加進(jìn)白名單、啟動(dòng)器號(hào)是不是重復(fù)。提示添加數(shù)據(jù)存儲(chǔ)會(huì)對(duì) LUN 做格式化實(shí)驗(yàn)前確認(rèn)這個(gè) LUN 上沒有還要保留的數(shù)據(jù)。手冊(cè)里這一步寫得比較輕但它是不可逆操作。3.3 精簡(jiǎn)磁盤不是萬能三種磁盤類型的分配與性能賬數(shù)據(jù)存儲(chǔ)掛好后創(chuàng)建磁盤這一步看似只是填容量實(shí)際上磁盤類型決定了后面虛擬機(jī)的空間利用率和 I/O 表現(xiàn)。FusionCompute 6.5 里常見三種類型普通、普通延遲置零、精簡(jiǎn)。普通磁盤創(chuàng)建時(shí)一次性分配并置零創(chuàng)建慢但寫入性能穩(wěn)定普通延遲置零創(chuàng)建快首次寫入時(shí)再置零適合批量發(fā)放但對(duì)首次寫入延遲敏感的場(chǎng)景要慎用精簡(jiǎn)磁盤按實(shí)際使用量分配支持超配創(chuàng)建最快但使用率上去后性能會(huì)下降且需要監(jiān)控存儲(chǔ)剩余空間。實(shí)驗(yàn)環(huán)境我一般用精簡(jiǎn)磁盤因?yàn)橐?yàn)證模板部署和快照空間利用率高但如果這個(gè)實(shí)驗(yàn)里要跑數(shù)據(jù)庫或者做性能對(duì)比就換成普通磁盤避免把存儲(chǔ)層的延遲算到虛擬機(jī)頭上。創(chuàng)建時(shí)容量填 40GB、數(shù)量 1創(chuàng)建完在數(shù)據(jù)存儲(chǔ)的使用率里確認(rèn)只占了幾百 MB說明精簡(jiǎn)分配生效。磁盤類型分配方式創(chuàng)建速度適用場(chǎng)景普通創(chuàng)建時(shí)全量分配并置零慢對(duì) I/O 穩(wěn)定性敏感的業(yè)務(wù)盤普通延遲置零創(chuàng)建時(shí)分配首次寫入置零中批量發(fā)放、能接受首寫延遲精簡(jiǎn)按實(shí)際寫入增長(zhǎng)快實(shí)驗(yàn)、模板盤、空間緊張環(huán)境4. 分布式交換機(jī)、VLAN 池與端口組網(wǎng)絡(luò)資源的落地順序計(jì)算和存儲(chǔ)就位后虛擬機(jī)還缺一張能跨主機(jī)漂移的網(wǎng)。FusionCompute 的網(wǎng)絡(luò)模型里分布式交換機(jī)是跨主機(jī)的邏輯交換機(jī)端口組是虛擬機(jī)掛網(wǎng)卡的入口VLAN 池負(fù)責(zé)給端口組分配 VLAN ID上行鏈路把邏輯交換機(jī)接到物理網(wǎng)口。這四樣?xùn)|西的創(chuàng)建順序是固定的先交換機(jī)、再上行鏈路、再 VLAN 池、最后端口組。順序亂了端口組創(chuàng)建時(shí)選不到 VLAN或者上行鏈路加不進(jìn)去。這一章我建議配合一次遷移實(shí)驗(yàn)做驗(yàn)證把一臺(tái)虛擬機(jī)從 CNA01 遷到 CNA02遷移后 IP 不變、同 VLAN 能通、跨 VLAN 隔離。網(wǎng)絡(luò)配置對(duì)不對(duì)遷移一次比看十遍界面更直觀。4.1 DVS 與標(biāo)準(zhǔn)交換機(jī)跨主機(jī)遷移時(shí)才見真章FusionCompute 里每臺(tái)主機(jī)可以配標(biāo)準(zhǔn)交換機(jī)也可以接入分布式交換機(jī)。標(biāo)準(zhǔn)交換機(jī)的配置只在本機(jī)生效虛擬機(jī)遷到另一臺(tái)主機(jī)后如果目標(biāo)主機(jī)沒有同名端口組和相同 VLAN遷移會(huì)失敗或者遷移后網(wǎng)絡(luò)不通。分布式交換機(jī)的配置是跨主機(jī)共享的端口組建一次集群內(nèi)主機(jī)都能用虛擬機(jī)遷移時(shí)網(wǎng)絡(luò)配置跟著走。實(shí)驗(yàn)里兩臺(tái) CNA必須用分布式交換機(jī)否則 HA 和熱遷移實(shí)驗(yàn)做不完整。創(chuàng)建時(shí)名稱填DVS01模式選 VLAN 池MTU 先保持1500。MTU 這一項(xiàng)后面配存儲(chǔ)網(wǎng)絡(luò)時(shí)會(huì)再提到業(yè)務(wù)網(wǎng)絡(luò)不要隨手改 9000端到端有一臺(tái)設(shè)備不支持就會(huì)丟包表現(xiàn)是“小包通、大包斷”排查起來很費(fèi)時(shí)間。4.2 先上行鏈路、再 VLAN 池、后端口組上行鏈路是把 DVS 接到物理網(wǎng)口的那一步。每臺(tái)主機(jī)至少選一個(gè)物理網(wǎng)口做上行鏈路綁定模式實(shí)驗(yàn)環(huán)境用主備最穩(wěn)負(fù)載分擔(dān)需要交換機(jī)側(cè)配置匹配配不好會(huì)出現(xiàn)單邊流量虛擬機(jī)時(shí)通時(shí)斷。加完上行鏈路在 DVS 上確認(rèn)每臺(tái)主機(jī)的鏈路狀態(tài)都是“正?！痹偻伦摺LAN 池按手冊(cè)規(guī)劃建兩個(gè)VLAN 201 給業(yè)務(wù)管理VLAN 202 給存儲(chǔ)。VLAN ID 要和物理交換機(jī) trunk 放通的列表一致不一致時(shí)虛擬機(jī)掛端口組能成功但流量出不去。端口組建的時(shí)候綁定 DVS、選 VLAN ID名稱建議帶 VLAN 號(hào)比如pg-business-201后面虛擬機(jī)掛網(wǎng)卡時(shí)不容易選錯(cuò)。步驟界面位置關(guān)鍵參數(shù)常見失敗表現(xiàn)創(chuàng)建 DVS網(wǎng)絡(luò)資源 → 分布式交換機(jī)名稱 DVS01、VLAN 池模式模式選錯(cuò)后面加不了 VLAN 池添加上行鏈路DVS → 上行鏈路每臺(tái)主機(jī)至少一個(gè)物理網(wǎng)口鏈路狀態(tài)異常虛擬機(jī)不通添加 VLAN 池DVS → VLAN 池201、202與交換機(jī) trunk 不一致流量出不去添加端口組DVS → 端口組綁定 VLAN ID虛擬機(jī)選不到端口組4.3 管理、存儲(chǔ)、業(yè)務(wù)三網(wǎng)分離的網(wǎng)口與 MTU 規(guī)劃手冊(cè)的地址規(guī)劃里管理網(wǎng)和存儲(chǔ)網(wǎng)是分開的這不是為了好看而是為了避免存儲(chǔ)流量把管理平面打滿。管理網(wǎng)跑 VRM 和 CNA 的心跳、Web 訪問存儲(chǔ)網(wǎng)跑 iSCSI 讀寫業(yè)務(wù)網(wǎng)跑虛擬機(jī)對(duì)外服務(wù)。三張網(wǎng)在物理上可以是同一臺(tái)交換機(jī)上的不同 VLAN但網(wǎng)口和 VLAN 要分開配。存儲(chǔ)網(wǎng)的 MTU 如果要用 9000必須從 CNA 網(wǎng)口、虛擬交換機(jī)、物理交換機(jī)到存儲(chǔ)陣列逐段確認(rèn)任何一段是 1500 都會(huì)導(dǎo)致大包分片或丟棄。我一般先在實(shí)驗(yàn)環(huán)境保持 1500 把流程跑通等存儲(chǔ)性能成為瓶頸再動(dòng) MTU改動(dòng)前記錄每段配置改完用大包 ping 驗(yàn)證。管理網(wǎng)不要開 jumbo frameVRM 和安裝向?qū)У牧髁啃￠_了反而增加不確定性。5. 安裝與運(yùn)維的五個(gè)高頻翻車點(diǎn)現(xiàn)象、原因與處置這套實(shí)驗(yàn)的步驟寫得細(xì)但真正卡人的往往不是步驟本身而是環(huán)境差異帶來的“界面能點(diǎn)、結(jié)果不對(duì)”。下面五條是我復(fù)現(xiàn)時(shí)遇到、也在別人環(huán)境里見過的翻車點(diǎn)按現(xiàn)象、原因、解決三段寫方便對(duì)照排查。每條都對(duì)應(yīng)手冊(cè)里的一個(gè)實(shí)驗(yàn)環(huán)節(jié)但手冊(cè)不會(huì)告訴你失敗時(shí)長(zhǎng)什么樣。5.1 安裝階段向?qū)нB不上 CNA 與添加主機(jī)失敗現(xiàn)象一VRM 安裝向?qū)崾具B接 CNA 失敗或超時(shí)。管理 PC 能 ping 通 CNA 的管理 IP但向?qū)Ь褪沁B不上。原因通常是管理 PC 和 CNA 不在同一網(wǎng)段中間過了 NAT 或者多層路由向?qū)Щ爻塘髁勘粨踝∫部赡苁?KVM 虛擬網(wǎng)卡用了 NAT 模式CNA 出方向正常入方向不通。解決辦法是把管理 PC 的網(wǎng)卡改到192.168.201.0/24網(wǎng)段KVM 虛擬網(wǎng)卡改橋接先保證雙向 ping 通再跑向?qū)?。嵌套環(huán)境里這一條占安裝失敗的大半?，F(xiàn)象二添加主機(jī)到集群失敗提示主機(jī)已被管理或證書校驗(yàn)失敗。原因有兩個(gè)CNA 之前注冊(cè)過別的 VRM殘留信息沒清或者 CNA 和 VRM 的時(shí)間偏差太大證書校驗(yàn)過不去。解決時(shí)先在 VRM 主機(jī)列表刪掉殘留記錄在 CNA 后臺(tái)用date看時(shí)間偏差超過幾分鐘就先配 NTP 同步再重新添加。實(shí)驗(yàn)環(huán)境里虛擬機(jī)掛起幾天再恢復(fù)時(shí)間漂移很常見別一上來就懷疑密碼錯(cuò)。5.2 存儲(chǔ)與網(wǎng)絡(luò)階段LUN 掃不到、遷移卡住現(xiàn)象三添加 IP-SAN 存儲(chǔ)后掃描不到 LUN。按網(wǎng)絡(luò)、白名單、啟動(dòng)器號(hào)三處查。先ping陣列 iSCSI 地址不通就查 VLAN 和存儲(chǔ)接口綁定通了再看陣列側(cè)有沒有把 CNA 的 IQN 加進(jìn) initiator 白名單最后回 CNA 確認(rèn)兩臺(tái)主機(jī)的啟動(dòng)器號(hào)不重復(fù)?？寺〕鰜淼?CNA 是重災(zāi)區(qū)兩臺(tái) IQN 一樣時(shí)陣列側(cè)只認(rèn)一條另一臺(tái)掃描結(jié)果永遠(yuǎn)為空?，F(xiàn)象四虛擬機(jī)熱遷移進(jìn)度卡住或直接失敗。日志里常見兩類提示CPU 特性不兼容、遷移網(wǎng)絡(luò)不通。CPU 問題按 3.1 節(jié)統(tǒng)一集群內(nèi)主機(jī) CPU 模型網(wǎng)絡(luò)問題要確認(rèn)集群是否配了遷移網(wǎng)絡(luò)沒配時(shí)遷移流量走管理網(wǎng)管理網(wǎng)一忙就超時(shí)。實(shí)驗(yàn)環(huán)境可以先用關(guān)機(jī)遷移驗(yàn)證存儲(chǔ)和網(wǎng)絡(luò)通不通再回頭調(diào)熱遷移。5.3 虛擬機(jī)階段模板克隆后藍(lán)屏與網(wǎng)卡改名現(xiàn)象五Windows 模板部署出來的虛擬機(jī)藍(lán)屏或首次啟動(dòng)進(jìn)不了系統(tǒng)。原因多是模板封裝前沒裝 Tools、沒做 sysprep克隆出來的 SID 和驅(qū)動(dòng)狀態(tài)不對(duì)。正確順序是源虛擬機(jī)裝 Tools → 確認(rèn)設(shè)備管理器無異常 → 執(zhí)行sysprep /generalize /shutdown→ 關(guān)機(jī)后轉(zhuǎn)模板。少了 sysprep 這一步單臺(tái)測(cè)試可能正常批量部署時(shí)就會(huì)出問題這是最典型的“單機(jī)驗(yàn)證通過、批量翻車”。Linux 模板則是另一個(gè)畫風(fēng)克隆后網(wǎng)卡名從eth0變成eth1IP 配不上。原因是 udev 規(guī)則按 MAC 綁定了網(wǎng)卡名。封裝前清掉綁定規(guī)則和網(wǎng)卡配置里的硬件地址# 清掉按 MAC 綁定網(wǎng)卡名的規(guī)則避免克隆后變成 eth1 rm -f /etc/udev/rules.d/70-persistent-net.rules # 去掉 ifcfg 里的 HWADDR 和 UUID讓新虛擬機(jī)重新生成 sed -i /^HWADDR/d /etc/sysconfig/network-scripts/ifcfg-eth0 sed -i /^UUID/d /etc/sysconfig/network-scripts/ifcfg-eth0 # 確認(rèn)清理結(jié)果再關(guān)機(jī)轉(zhuǎn)模板 grep -E HWADDR|UUID /etc/sysconfig/network-scripts/ifcfg-eth0這段腳本只做清理不碰 IP、掩碼、網(wǎng)關(guān)所以模板里的網(wǎng)絡(luò)配置會(huì)保留克隆后按需改 IP 即可。CentOS 7 如果啟用了可預(yù)測(cè)網(wǎng)卡命名光刪規(guī)則文件還不夠常見做法是在內(nèi)核啟動(dòng)參數(shù)里加net.ifnames0 biosdevname0讓網(wǎng)卡穩(wěn)定叫eth0。改完必須重啟驗(yàn)證一次再轉(zhuǎn)模板別在沒重啟的情況下直接封裝規(guī)則可能沒生效。6. 把手冊(cè)變成可驗(yàn)收的交付物一份 10 分鐘檢查清單手冊(cè)的實(shí)驗(yàn)步驟走完環(huán)境“看起來能用”和“真的能交付”之間還差一次驗(yàn)收。我習(xí)慣在關(guān)掉瀏覽器之前跑一遍檢查清單十分鐘內(nèi)能發(fā)現(xiàn)大部分隱患。下面這張表按檢查項(xiàng)、檢查方式、通過標(biāo)準(zhǔn)三列寫順序就是交付前的執(zhí)行順序。檢查項(xiàng)檢查方式通過標(biāo)準(zhǔn)管理網(wǎng)連通管理 PC 分別 ping 三個(gè)管理 IP全部通丟包為 0VRM Web瀏覽器打開https://192.168.201.100:8443能登錄服務(wù)狀態(tài)無告警CNA 主機(jī)狀態(tài)VRM 資源池 → 主機(jī)兩臺(tái)均為“正常”數(shù)據(jù)存儲(chǔ)VRM 存儲(chǔ) → 數(shù)據(jù)存儲(chǔ)已掛載使用率低于 80%DVS 上行鏈路網(wǎng)絡(luò) → DVS → 上行鏈路每臺(tái)主機(jī)至少一條“正?！碧摂M機(jī) Tools虛擬機(jī)詳情 → Tools 狀態(tài)“已運(yùn)行”版本與主機(jī)匹配快照殘留虛擬機(jī) → 快照無超過三天的臨時(shí)快照連不通的時(shí)候不用逐項(xiàng)猜先跑一段連通性腳本把范圍縮小#!/bin/bash # 交付前在管理網(wǎng) PC 上執(zhí)行先確認(rèn)四條鏈路再打開瀏覽器 for ip in 192.168.201.100 192.168.201.101 192.168.201.102 192.168.202.101; do if ping -c 2 -W 1 $ip /dev/null 21; then echo OK $ip else echo FAIL $ip fi done # 只看 HTTP 狀態(tài)碼-k 跳過自簽證書校驗(yàn)-o /dev/null 丟棄頁面內(nèi)容 curl -k -s -o /dev/null -w VRM HTTP %{http_code}\n https://192.168.201.100:8443-c 2是每個(gè)地址發(fā)兩個(gè)包-W 1是單包超時(shí)一秒實(shí)驗(yàn)網(wǎng)段里夠用-k是因?yàn)?VRM 默認(rèn)自簽證書不加會(huì)直接報(bào)證書錯(cuò)誤看不到狀態(tài)碼。腳本輸出里如果管理地址全通、存儲(chǔ)地址不通問題就鎖定在存儲(chǔ)接口或 VLAN不用再翻安裝日志。VRM 返回 200 或 302 都算正常返回 000 說明端口沒起來或者被防火墻擋了。這套手冊(cè)最大的價(jià)值是把七個(gè)實(shí)驗(yàn)串成一條可復(fù)現(xiàn)的鏈路但它不會(huì)替你做環(huán)境驗(yàn)收。從那以后我每次交付 FusionCompute 實(shí)驗(yàn)環(huán)境都強(qiáng)制先跑一遍這四個(gè) ping 和 8443 狀態(tài)碼再談集群策略和遷移順序反了就是給自己挖坑。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取