1. 从一台物理服务器到资源池超融合到底在解决什么问题第一次接触超融合这个概念是在一个只有三台物理服务器的机房里。当时业务方要求把一批测试环境从老旧的独立服务器上迁移出来预算有限不可能去买一套传统集中式存储加光纤交换机的架构。摆在我面前的选择只有两个要么继续用本地磁盘加手工同步脚本要么试试当时已经被讨论得很热的超融合方案。我选了后者从此开始了一段边踩坑边记录的历程。超融合基础设施英文缩写HCI核心思路一句话就能说清把计算、存储、网络这些原本分散在不同硬件上的资源通过软件定义的方式揉进同一批标准服务器里形成一个可以横向扩展的资源池。传统架构里计算归计算存储归存储中间还要靠专门的存储网络连接扩容的时候往往要分别考虑计算节点和存储阵列很容易出现一边资源紧张、另一边却闲置的情况。超融合要做的就是打破这种割裂让每一台加入集群的服务器都同时贡献CPU、内存和磁盘大家合力对外提供服务。我这次学习笔记围绕的是HX系列平台与VSAN分布式存储的组合。HX在这里指的是一套超融合管理平台负责集群的部署、监控和生命周期管理VSAN则是分布式存储层把每台服务器上的本地磁盘聚合成一个共享数据存储。两者配合起来管理员面对的不再是一台台孤立的机器而是一个统一的资源池。这个组合适合谁看我觉得是那些手里有几台服务器、想搭建私有化测试环境或者小型生产环境又不想被传统存储架构绑住手脚的运维人员和爱好者。哪怕你之前只接触过单机虚拟化只要理解基本的虚拟化概念这篇笔记里的思路和操作都能对上号。需要提前说明的是下面涉及的所有参数、步骤和案例都是基于我自己的实验环境和常见实践整理出来的具体数值会因为你使用的硬件型号、磁盘类型和平台版本不同而有差异。我尽量把“为什么这么做”讲清楚这样你遇到不一样的环境时也能自己判断。2. 整体架构设计与方案选型思路2.1 为什么选超融合而不是传统三层架构传统架构的典型形态是若干台计算服务器通过光纤交换机连接到一台集中式存储阵列。这个模式成熟稳定但有几个绕不开的痛点。第一是成本门槛高光纤交换机、HBA卡、存储阵列本身都不便宜小规模场景下性价比很低。第二是扩容不灵活计算不够了加计算节点存储不够了加硬盘柜两边很难同步容易造成投资浪费。第三是管理复杂计算、存储、网络三套独立的配置和监控体系出问题时要跨领域排查。超融合把这三层压缩到一层。每台服务器既是计算节点也是存储节点节点之间通过普通以太网互联存储的冗余和分布由软件层负责。这样做的好处很直接扩容时加一台标准服务器就行计算和存储同步增长管理界面统一一个平台看全貌硬件采购标准化不用为不同角色准备不同规格的设备。代价也有比如存储性能更依赖网络质量节点数量少的时候冗余能力有限这些在后面会具体讲。2.2 计算、存储、网络三层的角色划分虽然是“融合”但逻辑上还是要分清楚三层各自干什么。计算层由虚拟化平台负责把物理CPU和内存切分成虚拟机资源这一层和普通虚拟化没本质区别。存储层是VSAN的核心它把每台服务器上的本地磁盘组织成一个分布式数据存储虚拟机看到的是一块共享的、有冗余的存储空间实际上数据被分散在多个节点的磁盘上。网络层则承担了双重任务既要传输虚拟机的业务流量又要承载VSAN节点之间的存储同步流量。这里有个关键设计点VSAN的存储流量对网络延迟和带宽很敏感如果和业务流量挤在同一条链路上高峰期容易互相影响。所以我在规划时把网络分成了至少两个平面一个跑业务一个跑存储物理上可以用不同的网卡或者不同的VLAN隔离。这个决定在后面调试性能时被证明是对的具体原因在实操部分展开。2.3 最小可用集群的规模考量超融合集群的节点数量直接决定了可用性和性能。理论上单节点也能跑但那样就失去了分布式的意义一台机器坏了整个环境就没了。三节点是常见的最小生产规模因为VSAN默认的存储策略是“允许1个故障”也就是数据存两份副本三节点能保证任意一台宕机后数据仍然可用且能重新平衡。如果只有两个节点副本放置会很尴尬通常需要引入见证节点来仲裁复杂度上升。我自己的实验环境用的是三台同型号服务器每台配置两块SSD做缓存层、四块大容量HDD做容量层。这个缓存加容量的分层设计是VSAN的经典模式SSD负责承接写入和热点数据HDD负责冷数据存储兼顾性能和成本。如果预算充足全用SSD当然更好但全闪配置下缓存层和容量层的比例需要重新考虑这个后面细说。3. 核心组件与关键参数拆解3.1 磁盘组与缓存层的配置逻辑VSAN里最小的存储单元叫磁盘组。一个磁盘组由一块缓存盘和多块容量盘组成缓存盘必须是SSD容量盘可以是SSD也可以是HDD。每台服务器可以配置多个磁盘组但通常建议每台机器的磁盘组数量保持一致这样数据分布更均匀。我三台机器每台配了一个磁盘组每组一块SSD加四块HDD。缓存盘的作用有两个一是写缓冲所有写入先落到缓存盘再慢慢刷到容量盘二是读缓存热点数据会留在缓存盘上加速读取。正因为承担了读写双重职责缓存盘的容量和耐久度很关键。业界常见的经验比例是缓存盘容量占磁盘组总容量的百分之十左右但这个比例不是死的。如果业务写入量大缓存盘要适当加大如果主要是读多写少比例可以低一些。我用的SSD容量是800GB四块HDD每块4TB比例大约是百分之五实测在测试负载下够用但如果是生产环境我会建议往上加。注意缓存盘一旦加入磁盘组后续想更换或扩容会比较麻烦规划阶段宁可买大一点不要事后后悔。3.2 存储策略副本数与故障域VSAN通过存储策略来控制数据怎么放。最常用的两个参数是“允许的故障数”和“故障域”。允许的故障数设成1意味着数据存两份副本分布在不同的主机上任意一台主机故障数据不丢。设成2就是三份副本能扛两台同时故障但存储利用率会降到三分之一。故障域则定义了副本不能放在哪些范围内比如可以设置成“不同主机”或者“不同机架”防止一个机架断电导致所有副本同时失效。我自己的测试环境设的是允许1个故障、故障域为主机级别。这样三台机器每台存一份数据实际可用容量是总容量的二分之一左右再扣掉一些元数据开销。如果你对容量更敏感、能接受稍低的冗余也可以在某些非关键虚拟机上用“允许0个故障”的策略但我不建议在承载实际业务的虚拟机上这么干。3.3 网络平面与流量隔离前面提到网络要分平面具体怎么分我的做法是每台服务器配两块万兆网卡一块接业务交换机一块接存储交换机两个交换机物理独立。VSAN的存储流量走存储网卡虚拟机对外通信走业务网卡。如果只有一块网卡也可以用VLAN在逻辑上隔离但物理隔离在延迟和故障隔离上更彻底。带宽方面万兆是超融合的起步配置。VSAN节点之间同步数据、重建副本都要吃带宽千兆网卡在节点多、数据量大的时候会成为瓶颈。我实测过用千兆跑三节点集群日常运行没问题但一旦有节点故障触发数据重建重建速度慢得让人着急而且业务延迟明显上升。换成万兆后重建时间缩短到原来的几分之一。3.4 见证节点的作用与部署位置三节点集群其实已经能满足基本冗余但如果想进一步提升可用性或者节点数是偶数就需要见证节点。见证节点不存实际数据只参与集群的仲裁投票防止出现“脑裂”——也就是节点之间网络中断后各自以为对方挂了都想接管集群。见证节点对资源要求很低一台小虚拟机就能胜任但它的部署位置有讲究不能和主要节点放在同一个故障域里否则那个故障域出问题见证节点也跟着没了起不到仲裁作用。我目前的实验环境没上见证节点因为三节点加主机级故障域已经够用。但如果你的集群是两节点或者四节点强烈建议加一个见证节点部署在独立的物理位置或者至少独立的供电和网络环境里。4. 实操过程从裸机到可用集群4.1 硬件上架与基础环境准备三台服务器上架后第一件事是进BIOS检查几个关键设置。磁盘模式要确认是直通模式而不是RAID模式因为VSAN需要直接看到每块物理磁盘如果RAID卡把磁盘组成了逻辑卷VSAN就认不出来。这个坑我踩过当时有一台机器忘了改结果安装时死活看不到磁盘排查了半天才发现是RAID模式在作怪。另外要开启虚拟化相关的CPU特性比如Intel VT-x或者AMD-V还有内存的NUMA相关选项保持默认即可。网络方面我给每台服务器配了管理口、业务口和存储口。管理口接千兆交换机用于平台管理业务口和存储口各接万兆交换机。IP规划上管理网段、业务网段、存储网段分开存储网段建议用独立的子网方便后续做流量策略。每台服务器的存储口配置一个静态IP并且要保证三台之间能互相ping通这是VSAN正常工作的前提。4.2 平台安装与集群初始化安装HX管理平台的过程比较直接找一台机器作为初始节点用安装介质启动按照向导设置管理IP、主机名、root密码这些基础信息。安装完成后通过浏览器访问管理界面把另外两台机器也加入进来。加入的方式通常是在每台待加入的机器上运行一个发现脚本或者直接在管理界面里输入待加入机器的管理IP和凭据。集群初始化时要注意时间同步。三台机器的时间必须一致否则证书校验、日志关联都会出问题。我一般会在环境里配一个内部时间源所有节点都指向它。初始化过程中平台会自动检查硬件兼容性如果某块磁盘或者网卡不在兼容列表里会给出警告。兼容性列表这个东西不要忽视不在列表里的硬件可能能跑起来但稳定性没保证出问题也很难排查。4.3 磁盘组的创建与存储策略应用集群建好后进入存储配置界面创建磁盘组。选中一台主机指定哪块SSD做缓存盘、哪些盘做容量盘确认后平台会自动格式化并加入存储池。三台机器都创建完磁盘组后VSAN数据存储就自动形成了在虚拟化平台里能看到一个共享的数据存储容量是三台机器容量盘的总和再乘以副本系数。接下来创建存储策略。在策略管理里新建一个策略设置“允许的故障数”为1“故障域”为主机级别其他参数保持默认。然后把这个策略设为该数据存储的默认策略这样后续所有虚拟机默认就按这个策略存放。如果有特殊需求的虚拟机比如某个测试机不需要冗余可以单独给它指定一个允许0故障的策略但生产虚拟机不要这么干。4.4 虚拟机部署与迁移验证存储就绪后部署一台测试虚拟机验证整个链路。创建虚拟机时选择刚才建的数据存储安装一个轻量系统启动后确认能正常读写。然后做几个验证动作一是把虚拟机在三台主机之间做在线迁移观察迁移过程中业务是否中断、存储流量是否正常二是手动关闭一台主机看虚拟机是否自动在其他主机上重启数据是否完整三是往虚拟机里持续写入数据同时观察VSAN的读写延迟和吞吐指标。我实测下来在线迁移很顺畅万兆网络下迁移一台中等配置的虚拟机大概几十秒。关闭一台主机后虚拟机在另一台主机上自动重启重启时间取决于虚拟机操作系统本身的启动速度数据没有丢失。持续写入时缓存盘的写入吞吐能跑到几百兆每秒延迟在毫秒级别对于测试环境完全够用。5. 常见问题与排查技巧实录5.1 磁盘识别异常与兼容性排查最常见的问题就是磁盘认不出来。除了前面说的RAID模式问题还有一种情况是磁盘被其他系统残留了分区信息VSAN认为它已经被占用。这时候需要在命令行里手动清除磁盘的分区表或者通过平台的磁盘管理功能做一次清理。另外有些磁盘虽然容量和接口都符合要求但固件版本太老也可能导致性能异常或者掉盘。遇到这种情况先去查兼容性列表确认固件版本是否在推荐范围内不在的话升级固件往往能解决。5.2 存储流量拥塞与网络调优如果发现虚拟机读写变慢但CPU和内存都不紧张大概率是存储网络出了问题。排查顺序是这样的先看存储网卡的利用率如果持续接近饱和说明带宽不够要么升级网卡要么把部分流量分流到其他链路。再看交换机端口有没有丢包或者错误计数有的话检查网线、光模块和交换机配置。最后看VSAN本身的性能指标比如缓存盘的写缓冲是否经常满、容量盘的IOPS是否达到上限。我遇到过一次性能抖动最后定位到是业务流量和存储流量走了同一个物理网卡虽然做了VLAN隔离但物理带宽是共享的业务高峰期把存储流量挤了。后来把存储流量单独挪到一块网卡上问题就消失了。所以如果条件允许物理隔离比逻辑隔离更靠谱。5.3 节点故障后的数据重建观察节点故障后VSAN会自动在其他节点上重建丢失的副本这个过程会占用网络带宽和磁盘IO。重建期间整个集群的性能会有所下降这是正常的。要关注的是重建速度和是否卡住。如果重建进度长时间不动可能是网络不通、目标节点空间不足或者磁盘有问题。我一般会在重建开始后盯着存储网络的流量和各个节点的磁盘利用率确认数据在流动。重建完成后集群会恢复正常的冗余状态。这时候建议做一次数据一致性校验确保没有静默损坏。VSAN本身有校验机制但手动触发一次全量校验更放心尤其是在经历过非正常断电之后。5.4 常见问题速查表现象可能原因排查方向处理建议安装时看不到磁盘RAID模式未关闭进BIOS检查磁盘控制器模式改为直通模式后重新扫描磁盘加入失败残留分区信息查看磁盘是否有旧分区清除分区表后重试虚拟机读写慢存储网络拥塞检查存储网卡利用率分流流量或升级带宽节点故障后重建慢带宽不足或磁盘瓶颈观察网络和磁盘指标错峰重建或扩容集群脑裂仲裁机制缺失检查见证节点状态部署独立见证节点时间不同步未配置统一时间源检查各节点时间配置内部时间源提示这张表是我自己遇到问题后整理的实际排查时不要死板对照先看日志和监控指标让数据说话。6. 性能调优与容量规划经验6.1 缓存盘与容量盘的比例调整前面提到缓存盘占总容量百分之十是个参考值但实际怎么定要看业务特征。如果业务以随机写入为主比如数据库类应用缓存盘要更大因为写缓冲需要空间来吸收突发写入。如果业务以顺序读写为主比如文件存储或者备份缓存盘可以小一些因为顺序IO对缓存依赖低。我自己的测试环境因为负载不重百分之五的比例够用但如果要跑数据库我会把缓存盘加到总容量的百分之十五到二十。另外缓存盘的耐久度也要考虑。SSD有写入寿命限制缓存盘承担了大量写入寿命消耗比容量盘快。监控里要关注缓存盘的剩余寿命快到期时提前更换。有些平台支持缓存盘热插拔更换换上去后会自动重建缓存但这个过程有风险最好在业务低峰期做。6.2 存储策略的精细化调整默认策略适合大多数场景但不同虚拟机可以有不同的策略。比如开发测试虚拟机可以放宽冗余要求用允许0故障的策略节省空间核心业务虚拟机可以用允许2故障的策略提高可用性。还可以针对单个虚拟机的磁盘做策略调整比如系统盘用高冗余、数据盘用低冗余。这些调整在管理界面里点几下就能完成但改完之后VSAN会重新分布数据会消耗一定的集群资源建议批量操作放在业务低峰期。6.3 扩容时的注意事项超融合的扩容很直观加一台配置相近的服务器加入集群创建磁盘组数据会自动重新平衡。但有几个细节要注意。新节点的硬件配置最好和现有节点接近尤其是磁盘组的结构否则数据分布可能不均匀。加入集群后数据平衡是自动触发的但平衡速度可以调节如果业务对性能敏感可以把平衡速度调低让它慢慢来。扩容后存储策略不需要改VSAN会自动把新节点的容量纳入可用空间。我做过一次扩容测试从三节点加到四节点数据平衡花了几个小时期间业务性能有轻微下降但可接受。平衡完成后可用容量增加了大约四分之一符合预期。7. 这套方案适合谁以及我踩过的那些坑回过头看HX加VSAN这套组合最适合的场景是中小规模的私有化部署节点数在三到八个之间预算有限但需要一定的冗余和扩展能力。它不适合超大规模集群那种场景下专门的分布式存储方案可能更合适也不适合对存储延迟极度敏感的应用因为网络跳转总会带来额外延迟。我踩过的坑里最值得说的是两个。一个是RAID模式没关白白浪费了一个下午。另一个是网络没做隔离业务高峰期存储性能被挤导致虚拟机卡顿排查了很久才定位到。这两个问题的共同点是它们都不是技术难题而是规划阶段的疏忽。超融合的部署本身不复杂复杂的是前期想清楚硬件怎么配、网络怎么分、策略怎么定。这些想明白了后面基本就是按部就班。最后分享一个小技巧在正式部署前先用一两台机器搭一个最小环境跑一遍全流程把安装、配置、故障模拟都走一遍。这个过程能暴露大部分配置问题而且不会影响生产环境。等流程熟了再上正式集群心里有底手也不慌。