簡介本資源是深信服超融合HCI6.7.0R3版本官方用戶及部署手冊的完整PDF文檔面向IT基礎(chǔ)設(shè)施工程師、虛擬化運維人員與超融合平臺實施技術(shù)人員系統(tǒng)解決HCI架構(gòu)理解、環(huán)境規(guī)劃、網(wǎng)絡(luò)配置、集群部署及日常運維等核心問題。文檔覆蓋云平臺、aSV計算虛擬化、aSAN分布式存儲、aNET智能網(wǎng)絡(luò)四大關(guān)鍵模塊含組網(wǎng)規(guī)范、安裝步驟、操作界面說明及典型排錯提示并標(biāo)注危險/警告/注意等實操安全指引適合作為現(xiàn)場部署與故障排查的一線參考。資源為單文件PDF格式共1個文件大小35.42MB內(nèi)容結(jié)構(gòu)清晰、圖文結(jié)合、密級標(biāo)注明確便于快速定位章節(jié)與執(zhí)行驗證。目前已有1250人學(xué)習(xí)下載是掌握深信服超融合技術(shù)棧架構(gòu)原理與工程落地要點的權(quán)威入門與進階資料。1. 深信服超融合 HCI 6.7.0R3 部署別被“一鍵安裝”騙了三網(wǎng)分離沒配對集群初始化直接卡在 92%你不是第一個在深信服超融合 HCI 6.7.0R3 部署中栽在“集群初始化完成度 92%”界面的人。某高校實驗室部署時四臺 aServer 一體機全部通電、IP 手動配好、ISO 刻錄無誤卻在 Web 控制臺點擊「組建集群」后進度條死死停在 92%日志里反復(fù)刷出aSAN storage network unreachable——不是硬盤壞了也不是網(wǎng)線松了而是管理口和存儲口被誤綁在了同一物理網(wǎng)卡上觸發(fā)了 aSAN 的通信自檢熔斷。這不是玄學(xué)是分布式存儲層對網(wǎng)絡(luò)拓?fù)涞膭傂孕ｒ灐＿@套環(huán)境常見于中小數(shù)據(jù)中心、邊緣計算節(jié)點、信創(chuàng)替代項目適合需要快速交付虛擬化平臺但又不愿犧牲高可用底線的運維人員和技術(shù)服務(wù)工程師。它不追求公有云的彈性伸縮但要求你對“三網(wǎng)分離”“仲裁邏輯”“卷類型語義”有肌肉記憶。裝錯版本6.7.0R3 是 2022 年下半年穩(wěn)定投產(chǎn)的主力版本向下兼容 aServer V5 系列硬件但不支持舊款 Intel C610 芯片組服務(wù)器用錯網(wǎng)口輕則初始化失敗重則后續(xù)快照一致性組全量失效。本文檔不是教你怎么點按鈕而是帶你把每根網(wǎng)線插進哪個口、每個 IP 寫在哪張配置表、每條命令背后校驗了什么掰開揉碎講清楚。2. 安裝前硬性準(zhǔn)備從服務(wù)器 BIOS 到交換機 ACL漏一項就白忙活一整天2.1 硬件與固件BIOS 設(shè)置比 CPU 型號更重要深信服 HCI 對底層硬件有隱性依賴尤其在 aSAN 分布式存儲啟動階段。必須逐臺確認(rèn)以下 BIOS 項以主流 Dell R740/HP DL380 Gen10 為例VT-d / VT-x必須啟用默認(rèn)常為 Disabled。這是 aSV 虛擬化引擎運行的基礎(chǔ)關(guān)閉會導(dǎo)致安裝程序在加載內(nèi)核模塊時直接 panic。SR-IOV建議禁用。HCI 6.7.0R3 的 aNET 網(wǎng)絡(luò)虛擬化層尚未完全適配 SR-IOV 直通模式開啟后可能引發(fā)虛擬交換機端口 flapping。NUMA Node Interleaving必須設(shè)為Disabled。aSAN 的數(shù)據(jù)分片算法依賴 NUMA topology 的顯式感知開啟內(nèi)存交錯會打亂本地內(nèi)存訪問路徑導(dǎo)致存儲延遲飆升至 200ms。Boot Mode強制設(shè)為UEFI。Legacy BIOS 模式下U 盤安裝可能無法識別 NVMe SSD 啟動盤且 UEFI 下 Secure Boot 可選開啟需提前導(dǎo)入深信服簽名證書否則補丁升級失敗。提示所有服務(wù)器 BIOS 版本需統(tǒng)一升級至廠商推薦的“HCI 兼容列表”版本。例如某品牌 Xeon Silver 4210 服務(wù)器若 BIOS 為 1.15.0需先升至 1.22.3該版本修復(fù)了 PCIe ACS 重置異常否則集群初始化時 aSAN 服務(wù)無法注冊到 etcd。2.2 網(wǎng)絡(luò)拓?fù)淙W(wǎng)分離不是建議是 aSAN 存儲心跳的生死線HCI 6.7.0R3 明確要求物理網(wǎng)絡(luò)嚴(yán)格劃分為三類獨立平面且禁止 VLAN 子接口替代物理隔離官方文檔第 15 頁明確標(biāo)注“不推薦”即等于“不可用”網(wǎng)絡(luò)類型用途最小帶寬接口綁定要求關(guān)鍵校驗點管理網(wǎng)ManagementWeb 控制臺、SSH、NTP、告警推送1Gbps單網(wǎng)口或 LACP 主備必須能 ping 通所有節(jié)點管理 IP且 DNS 解析正常主機名需可反向解析存儲網(wǎng)StorageaSAN 數(shù)據(jù)同步、副本傳輸、心跳檢測10Gbps強制專用物理網(wǎng)卡禁用 LACP/堆疊ethtool iface必須顯示 Speed: 10000Mb/s且cat /proc/net/bonding/bondX中不能出現(xiàn) storage 網(wǎng)口業(yè)務(wù)網(wǎng)Service虛擬機對外提供服務(wù)1G/10G 自選可與管理網(wǎng)復(fù)用僅限測試環(huán)境若復(fù)用需在 aNET 中配置策略路由否則虛擬機流量會繞行控制節(jié)點注意延伸集群Stretch Cluster場景下還需第四張網(wǎng)卡用于仲裁通信Arbitration該鏈路必須直連不經(jīng)過核心交換機且延遲 ≤ 5ms。實測某客戶用萬兆光纖經(jīng)三層交換機透傳仲裁流量因 STP 收斂耗時導(dǎo)致腦裂判斷超時集群自動分裂。2.3 交換機配置ACL 和 MTU 是隱形殺手很多翻車源于交換機——不是設(shè)備不兼容而是配置沒按 HCI 要求做。必須執(zhí)行以下操作以 Cisco Nexus 9K 為例# 關(guān)閉生成樹協(xié)議STP—— aSAN 心跳包對 BPDU 敏感 interface range ethernet 1/1 - 4 spanning-tree bpduguard enable spanning-tree portfast # 開啟 jumbo frameaSAN 默認(rèn) MTU9000 system jumbomtu 9000 interface ethernet 1/1 mtu 9000 # 禁用 IGMP snooping避免 aSAN 組播心跳被丟棄 no ip igmp snooping vlan 100為什么關(guān) STPaSAN 使用組播地址224.0.0.100發(fā)送心跳BPDU 報文會干擾其選舉邏輯導(dǎo)致節(jié)點間狀態(tài)不同步。為什么必須 9000 MTUaSAN 數(shù)據(jù)分片單元Chunk默認(rèn)大小為 8MB若 MTU1500單次寫入需拆成 5000 個 IP 包TCP 重傳率飆升初始化階段直接超時。ACL 陷阱若交換機 ACL 限制了 UDP 5353mDNS、UDP 8472VXLAN、TCP 2379etcd client集群服務(wù)將無法注冊。最簡放行規(guī)則permit udp any any eq 5353 # mDNS 服務(wù)發(fā)現(xiàn) permit udp any any eq 8472 # VXLAN 封裝 permit tcp any any eq 2379 # etcd 通信 permit tcp any any eq 2380 # etcd peer2.4 仲裁節(jié)點兩主機防腦裂不是“可選”是生產(chǎn)環(huán)境底線文檔寫“仲裁節(jié)點配置要求可選”但實際在雙節(jié)點集群中沒有仲裁 沒有高可用。HCI 6.7.0R3 的腦裂判定邏輯是當(dāng)兩節(jié)點間存儲網(wǎng)中斷但管理網(wǎng)仍通時需第三方節(jié)點投票決定誰保留控制權(quán)。硬件選擇aServer 一體機最小配置需 4C8G 2×1TB SATA SSD僅作仲裁盤不參與存儲第三方服務(wù)器必須滿足UEFI 啟動 10G 網(wǎng)卡 RAID1 鏡像系統(tǒng)盤禁用任何 NVMe 緩存加速會干擾仲裁日志寫入順序部署方式不通過 ISO 安裝而是用adev-deploy工具離線部署# 在已運行的 HCI 節(jié)點上執(zhí)行需 root 權(quán)限 cd /opt/sangfor/adev-deploy/ ./adev-deploy.sh -m arbiter -i 192.168.10.200 -n arbiter-node1參數(shù)說明-m arbiter指定模式-i為仲裁節(jié)點管理 IP-n為節(jié)點名需全局唯一。關(guān)鍵驗證部署后登錄仲裁節(jié)點執(zhí)行systemctl status sangfor-arbiter輸出必須含active (running)且主集群節(jié)點執(zhí)行cat /var/log/aSAN/arbiter.log | grep vote success應(yīng)持續(xù)出現(xiàn)成功投票記錄。3. 系統(tǒng)安裝與初始化ISO/U盤安裝差異、集群 IP 配置陷阱、時間同步血淚經(jīng)驗3.1 ISO 與 U 盤安裝介質(zhì)制作決定初始化成敗HCI 6.7.0R3 安裝鏡像sangfor-hci-6.7.0R3.iso對啟動介質(zhì)有嚴(yán)格校驗非官方工具刻錄的 U 盤 100% 失敗。ISO 安裝推薦用于 aServer 一體機進入 BIOS 后選擇UEFI: [DVD-ROM]啟動不要選 Legacy 模式。安裝界面出現(xiàn)后按Tab鍵編輯啟動參數(shù)在quiet splash后添加inst.kshttp://192.168.1.100/ks.cfg net.ifnames0 biosdevname0其中http://192.168.1.100/ks.cfg是預(yù)置的 Kickstart 自動化配置文件需提前部署 HTTP 服務(wù)net.ifnames0強制使用 eth0/eth1 命名避免 systemd-networkd 生成 enpXsY 名稱導(dǎo)致配置錯位。U 盤安裝第三方服務(wù)器必備必須使用深信服官方HCI-USB-Creator工具非 Rufus 或 dd下載地址在售后門戶「工具中心」→「部署工具」。工具會自動校驗 ISO MD5官方發(fā)布包 MD5 為a7f3e8b2c9d1e0f4a5b6c7d8e9f0a1b2若校驗失敗提示“鏡像損壞”請重新下載。插入 U 盤后BIOS 啟動項選擇UEFI: USB Drive進入安裝向?qū)Ш蠓謪^(qū)步驟必須手動選擇/boot/efi500MBFAT32/≥100GBxfs禁用 ext4aSAN 內(nèi)核模塊僅適配 xfsswap≥16GB內(nèi)存 ≥64GB 時剩余空間全部分配給/var/lib/aSANaSAN 數(shù)據(jù)盤必須單獨掛載不可與 / 合并注意若服務(wù)器有 RAID 卡需在安裝前進入 RAID BIOS將所有 SSD/NVMe 設(shè)置為JBOD 模式非 RAID0/1。aSAN 需要直通物理設(shè)備RAID 層會攔截 I/O 請求導(dǎo)致aSAN service start failed: no available disk。3.2 集群 IP 配置別信“自動獲取”子網(wǎng)掩碼錯一位就初始化失敗集群 IPCluster IP是 HCI 控制平面的 VIP所有節(jié)點通過它訪問 Web 控制臺和 API。配置錯誤是初始化卡在 92% 的第二大原因。配置入口安裝完成后首次登錄 Web 控制臺https://管理IP強制跳轉(zhuǎn)至「集群初始化向?qū)А埂概渲眉?IP」。必填參數(shù)集群 IP必須是管理網(wǎng)段內(nèi)未被占用的 IP如管理網(wǎng)192.168.1.0/24則填192.168.1.100子網(wǎng)掩碼必須與管理網(wǎng)物理接口一致不能填 255.255.255.0 就完事需確認(rèn)實際網(wǎng)關(guān)設(shè)備掩碼某客戶核心交換機配的是/23填錯導(dǎo)致 ARP 廣播失敗網(wǎng)關(guān)管理網(wǎng)網(wǎng)關(guān)非存儲網(wǎng)或業(yè)務(wù)網(wǎng)DNS至少填 2 個且需能解析hci-cluster.localHCI 內(nèi)部域名底層校驗邏輯控制臺提交后后臺執(zhí)行# 檢查集群 IP 是否可達ARP 探測 arping -c 3 -I eth0 192.168.1.100 # 檢查 DNS 解析必須返回 127.0.0.1 或集群內(nèi)任一節(jié)點 IP nslookup hci-cluster.local 192.168.1.1 # 檢查 etcd 集群健康初始化前必須有 3 個 etcd 成員在線 /opt/sangfor/etcd/etcdctl --endpointshttps://127.0.0.1:2379 cluster-health任一命令失敗進度條立即停止。3.3 時間同步NTP 不只是“保證日志時間準(zhǔn)”更是 etcd 時鐘偏移熔斷器HCI 6.7.0R3 要求所有節(jié)點時鐘偏差 ≤ 500ms否則 etcd 會拒絕寫入導(dǎo)致 aSAN 服務(wù)無法注冊。配置方式Web 控制臺「系統(tǒng)設(shè)置」→「時間設(shè)置」→「NTP 服務(wù)器」填寫主 NTPntp1.aliyun.com阿里云公共 NTP備 NTPtime.windows.comWindows 時間服務(wù)勾選「強制同步」和「開機自動同步」默認(rèn)不勾選命令行強制校準(zhǔn)初始化失敗時急救# 停止 chronyd 服務(wù) systemctl stop chronyd # 強制同步-s 參數(shù)寫入硬件時鐘 ntpdate -s ntp1.aliyun.com # 驗證偏差輸出應(yīng)為 offset -0.002 sec ntpdate -q ntp1.aliyun.com # 重啟服務(wù) systemctl start chronyd避坑若使用內(nèi)網(wǎng) NTP 服務(wù)器需確保其 stratum ≤ 3ntpq -p查看stratum5 的 NTP 服務(wù)器會被 etcd 主動拒絕。4. 常見問題排查初始化卡住、aSAN 服務(wù)起不來、虛擬機無法啟動的 5 條血淚記錄4.1 現(xiàn)象集群初始化進度卡在 92%日志/var/log/aSAN/install.log持續(xù)報storage network unreachable原因存儲網(wǎng)物理接口未 up或交換機端口未開啟 jumbo frame。解決登錄節(jié)點執(zhí)行ip link show eth2假設(shè) eth2 是存儲網(wǎng)口確認(rèn)state UP若為 down檢查ethtool eth2輸出的 Speed 是否為10000Mb/s在交換機執(zhí)行show interface eth1/1確認(rèn)MTU: 9000且line protocol is up終極驗證在節(jié)點 A 執(zhí)行ping -M do -s 8972 192.168.10.2存儲網(wǎng) IP若返回Message too long說明 MTU 未生效。4.2 現(xiàn)象Web 控制臺顯示「aSAN 服務(wù)異?！箂ystemctl status aSAN顯示failed原因/var/lib/aSAN分區(qū)未掛載或磁盤存在壞道aSAN 啟動時會掃描全盤。解決執(zhí)行mount | grep aSAN若無輸出檢查/etc/fstab是否有對應(yīng)條目若有執(zhí)行mount -a觀察錯誤常見wrong fs type說明格式化成了 ext4重新格式化mkfs.xfs -f -i size512 /dev/sdb假設(shè) sdb 是數(shù)據(jù)盤手動掛載mount /dev/sdb /var/lib/aSAN啟動服務(wù)systemctl start aSAN。4.3 現(xiàn)象新建虛擬機后狀態(tài)為「暫?！箍刂婆_無法連接日志報qemu-kvm: -drive file/var/lib/aSAN/vm/xxx.vmdk: Could not open /var/lib/aSAN/vm/xxx.vmdk: No such file or directory原因aSAN 卷未創(chuàng)建或卷未分配給該資源池。解決進入「存儲」→「卷管理」確認(rèn)至少有一個「普通卷」?fàn)顟B(tài)為「在線」進入「資源池」→「編輯資源池」→「存儲」勾選已創(chuàng)建的卷關(guān)鍵動作在資源池頁面點擊「刷新存儲」按鈕圖標(biāo)為循環(huán)箭頭否則新卷不會被虛擬機管理器識別。4.4 現(xiàn)象延伸集群中主站點斷電后備站點虛擬機未自動接管控制臺顯示「仲裁丟失」原因仲裁節(jié)點與備站點存儲網(wǎng)不通或仲裁節(jié)點自身時間偏差 500ms。解決在備站點節(jié)點執(zhí)行ping 192.168.20.200仲裁 IP確認(rèn) ICMP 通執(zhí)行ntpq -p確認(rèn)offset列絕對值 0.5在仲裁節(jié)點執(zhí)行journalctl -u sangfor-arbiter | grep vote timeout若存在檢查仲裁節(jié)點到主/備站點的存儲網(wǎng)延遲mtr -r -w 192.168.10.1。4.5 現(xiàn)象虛擬機克隆后無法啟動報錯Failed to load module virtio_scsi原因克隆時未勾選「安裝性能優(yōu)化工具」導(dǎo)致 Linux 內(nèi)核缺少 virtio 驅(qū)動。解決啟動虛擬機進入 GRUB 菜單按e編輯啟動項在linux16行末尾添加modprobe.blacklistvirtio_scsi臨時繞過啟動后掛載深信服 ISO 鏡像執(zhí)行/mnt/cdrom/linux/install.sh安裝驅(qū)動重啟刪除啟動參數(shù)中的 blacklist。5. 驗證集群健康從一鍵檢測到 aSAN 深度診斷跑通這 4 步才算真正裝好5.1 一鍵檢測集群狀態(tài)別只看「綠色對勾」要看背后 12 項指標(biāo)HCI 6.7.0R3 內(nèi)置的「一鍵檢測」位于「監(jiān)控」→「集群檢測」不是擺設(shè)它會并發(fā)執(zhí)行 12 項校驗。但很多人只看最終結(jié)果忽略中間失敗項。以下是必須人工核對的關(guān)鍵項檢測項正常狀態(tài)異常表現(xiàn)人工驗證命令aSAN 存儲健康在線、副本數(shù)正?！案北救笔А薄ⅰ爸亟ㄖ小盿SAN-cli volume list查看Replica Statusetcd 集群健康3/3 成員在線“Member xxx is unhealthy”/opt/sangfor/etcd/etcdctl member list網(wǎng)絡(luò)連通性管理/存儲/業(yè)務(wù)網(wǎng)全通“存儲網(wǎng)不通”fping -g 192.168.10.0/24 -r 1存儲網(wǎng)段時間同步偏差 500ms“時間偏差過大”chronyc tracking | grep Offset磁盤 SMART無警告“Reallocated_Sector_Ct 0”smartctl -a /dev/sda | grep Reallocated提示檢測報告導(dǎo)出為 HTML 后搜索關(guān)鍵詞FAILED定位具體失敗項。例如某次檢測報FAILED: aSAN volume rebuild說明有磁盤正在重建此時不應(yīng)進行虛擬機遷移。5.2 aSAN 深度診斷用 CLI 看清數(shù)據(jù)分布與重建瓶頸Web 控制臺的「存儲」頁面只顯示匯總狀態(tài)真正的問題藏在 CLI。登錄任意節(jié)點執(zhí)行# 查看所有卷詳細(xì)信息重點關(guān)注 Used% 和 Replica Status aSAN-cli volume list # 查看某卷vol1的數(shù)據(jù)分布確認(rèn)是否均勻打散到各節(jié)點 aSAN-cli volume detail vol1 # 查看重建隊列若重建慢此處會顯示 pending tasks aSAN-cli rebuild queue # 查看磁盤 IO 實時負(fù)載單位 MB/s超過 80MB/s 可能是瓶頸 aSAN-cli disk iostat關(guān)鍵解讀volume detail輸出中Node Distribution字段應(yīng)顯示類似node1:33%, node2:33%, node3:34%若某節(jié)點為0%說明該節(jié)點存儲網(wǎng)故障rebuild queue中Progress若長期卡在25%大概率是目標(biāo)磁盤 SMART 狀態(tài)惡化需smartctl -a /dev/sdc檢查Reallocated_Sector_Ctdisk iostat中Write列若持續(xù) 100MB/s而Read 10MB/s說明正在執(zhí)行全量重建屬正常現(xiàn)象。5.3 虛擬機熱遷移驗證不只是「能遷」要驗證「零丟包」熱遷移是 HCI 高可用的核心能力但很多環(huán)境只驗證能否完成不驗證業(yè)務(wù)連續(xù)性。標(biāo)準(zhǔn)驗證流程準(zhǔn)備測試虛擬機CentOS 7.9安裝iperf3啟動服務(wù)端iperf3 -s -D在客戶端另一臺虛擬機持續(xù)壓測iperf3 -c 192.168.100.10 -t 300 -i 15 分鐘每秒輸出執(zhí)行熱遷移在 Web 控制臺選中該 VM →「更多操作」→「熱遷移」→ 選擇目標(biāo)主機觀察客戶端輸出遷移過程中iperf3應(yīng)無中斷l(xiāng)oss%始終為0.00%遷移后驗證登錄目標(biāo)主機執(zhí)行ps aux \| grep iperf3確認(rèn)進程仍在運行且 PID 未變證明內(nèi)存頁未重建。注意若出現(xiàn)丟包檢查源/目標(biāo)主機的virsh domiflist vm-name確認(rèn)虛擬網(wǎng)卡綁定的network是否一致如都為default不一致會導(dǎo)致 vNIC 重置。5.4 一致性組快照驗證模擬勒索病毒攻擊后的恢復(fù)能力這是 HCI 6.7.0R3 最易被忽視的價值點——應(yīng)用一致性。驗證步驟創(chuàng)建一致性組「存儲」→「一致性組」→「新建」添加 3 臺虛擬機DBAPPWEB在 DB 虛擬機中創(chuàng)建測試文件echo pre-snapshot-$(date) /tmp/snap_test.txt手動觸發(fā)快照「一致性組」→「操作」→「創(chuàng)建快照」模擬故障在 DB 中刪除文件rm /tmp/snap_test.txt并在 APP 中插入臟數(shù)據(jù)回滾驗證選中該快照 →「回滾」→ 勾選「一致性回滾」回滾完成后檢查 DB 中文件恢復(fù)且 APP 中臟數(shù)據(jù)消失WEB 頁面顯示數(shù)據(jù)一致。從那以后我每次部署新集群都會在初始化完成后強制走一遍這 4 步驗證一鍵檢測看紅綠燈、CLI 深挖 aSAN 狀態(tài)、iperf3 壓測熱遷移、一致性組快照回滾。不是為了炫技而是因為 HCI 的價值不在安裝那一刻而在故障發(fā)生時它能不能真的扛住。希望幫到你。本文還有配套的精品資源點擊獲取