1. 超融合一体机到底解决了什么问题1.1 传统架构的三大痛我接手的第一套 SANDSTONE HYPERCUBE 超融合一体机是在一个业务量不大但系统却乱得吓人的某公司机房。当时他们跑的是传统三层架构两台机架式服务器接一台共享存储再挂一堆交换机虚拟化平台是某虚拟化软件的老版本。表面上每台设备都有冗余但实际运维起来非常难受共享存储扩容要先停业务做存储规划还要提心吊胆等数据迁移结束。服务器和存储是不同厂商出问题互相推诿现场排查链路超过一整天。新业务上线要提前几个月做服务器、存储、网络的资源申请根本跟不上业务节奏。这就是传统架构最典型的三大痛点扩展难、排障难、交付慢。超融合一体机本质上就是把这堆散装零件揉成一台开箱即用的单机来管理而且这台单机还能通过加节点的方式平滑变大。1.2 超融合的定义别被绕晕网上对超融合Hyperconverged InfrastructureHCI的定义特别多但落到实地上就三句话第一句计算和存储放在同一台物理设备里。CPU、内存跑虚拟机硬盘组成分布式存储池不再需要单独的磁盘阵列或者SAN交换机。第二句多台设备通过软件组成一个集群。每台设备就是一个节点节点的硬盘通过软件汇聚成统一的存储资源池虚拟机可以跑在任意一个节点上数据分布在多个节点上单节点挂了虚拟机还可以在其他节点继续跑。第三句管理是通过软件统一完成的。物理设备只是承载单元真正的核心是那个把存储、计算、网络管理整合起来的软件平台。SANDSTONE HYPERCUBE 这类一体机在出厂时就把这套软件预装好了开机配置 IP 就能用省掉了大部分集成工作量。这三点理解了就明白为什么超融合能用几台通用服务器替换掉一大机柜的传统设备也理解了为什么它叫超融合而不是简单叫集群——因为融合的层次更深连存储都软件化了。1.3 这东西适合你吗我私下给朋友的选型建议都是这样分的适合用的场景有这么几类。中小规模虚拟机整合比如跑几十台虚拟机的中小机房资源规模不大但希望管理简单。分支机构或边缘机房没人驻场设备越少越好、远程管理越强越好。还有快速交付的项目型业务比如一个项目要从零搭建一套测试环境超融合一体机能省掉大量协调时间。不适合的场景也有。对存储性能要求极其变态的核心交易数据库按每秒几十万次IOPS来设计的超融合的共享存储池在某些情况下不如高端全闪阵列稳定。冷数据归档和超大容量存储场景比如上百TB的图片、视频、日志保存超融合的分布式架构成本不如对象存储或专用存储划算。所以超融合不是万能的银弹它是管理复杂度与性能需求之间的一个平衡点。SANDSTONE HYPERCUBE 这类产品把弹性扩展和简化交付做得确实好但选购前先对照自己的业务量级和性能预期别被厂商宣传带偏。2. 硬件规格与核心部件选型2.1 CPU、内存、存储该怎么配超融合一体机的硬件选型核心目标是软件需求决定硬件配置不是你拍脑袋想买什么就买什么。SANDSTONE HYPERCUBE 的节点硬件一般长这样部件推荐配置说明CPU2颗24核以上的处理器虚拟化场景CPU不是只看主频核心数和缓存更重要内存512GB起步推荐每节点512GB-1TB内存越大可用的内存页缓存越多分布式存储性能越好系统盘2块480GB SSD做镜像装系统和虚拟化管理组件用不要和虚拟化存储池混用缓存盘2块1.6TB NVMe SSD用作分布式存储的热数据缓存层选直写型企业盘别用消费级数据盘6-12块4TB/8TB SATA/SAS容量层按业务数据量来定容量与性能要平衡网卡2口25GE或4口10GE业务网络和存储网络分开至少双网卡绑定选缓存盘是整个硬件配置里的关键它直接决定虚拟机的写性能。如果业务对读多写少的容忍度比较高PCIe NVMe SSD 做缓存盘的性价比很好如果写操作很频繁性能倒挂到后端数据盘慢的瓶颈就暴露出来了。这里必须提醒一个常见误区数据盘不是越大越好也不是盘越多越好。分布式存储的副本机制决定了数据需要跨节点复制节点之间传输数据的压力会随磁盘数量增加而上升所以一般单节点控制在12块盘以内是合理区间。2.2 网络设计是隐形雷区超融合系统里网络比服务器硬件更重要。因为每一笔写入都要通过网络复制到其他节点去网络抖动会直接拖垮整个集群的写性能。我实际部署 SANDSTONE HYPERCUBE 时对网络做的最小要求是管理网络独立一个 VLAN只有管理平台和带外管理用。存储网络和生产网络要物理隔离或至少 VXLAN 隔离不然大流量业务会把存储复制的带宽挤掉。所有涉及存储的链路建议用 25GE能上 100G 更好低于 10GE 的性能瓶颈会非常明显。交换机的MTU要统一调成9000巨型帧否则分布式存储的数据包转发效率会掉一截。记得我在某测试环境部署时因为交换机型号老旧、MTU只能支持1500结果创建虚拟机时延迟明显偏高后来统一MTU后写入延迟直接降了将近一半。这就是很多文档里不写但实际影响巨大的细节。2.3 硬件层面的几件小事服务器电源一定要双路。超融合节点挂了会影响整个集群的可用性和性能冗余电源单路就是拿可用性开玩笑。硬盘固件版本要统一。不同固件版本的硬盘混插某些场景下会触发磁盘微码Bug表现为偶发掉盘排查起来非常耗时。开机自检和内存测试别跳过。新节点上架前建议跑一轮完整测试很多厂商的设备在运输途中松了内存这种问题上并不少见。建议每个节点都配置 IPMI 带外管理。远程重启、看状态灯、抓串口日志全靠带外口了别只靠SSH。3. 部署安装与初始化配置3.1 部署前规划一小时决定后面三年我踩过的最大一个坑就是低估了部署前规划的重要性。拿到 SANDSTONE HYPERCUBE 设备后别急着开机手痒先把下面这些信息确认清楚网络规划表包括管理网段、存储网段、业务网段的IP地址、子网掩码、网关、VLAN ID。节点命名规划节点名不能用下划线不能以数字开头最好有明确的机房和机柜信息。账户规划管理平台超级管理员、运维账户、只读监控账户至少要规划三种角色别全用管理员账号。虚拟化网络规划规划好虚拟机所用的分布式交换机、端口组、VLAN策略。这里吃过的亏很具体。某次部署时我把管理网段和存储网段配成了一个网段省了交换机配置结果业务大流量直接把管理面卡断平台访问一会儿通一会儿不通。最后只能重启所有节点重新初始化配置白白损失了整整一个下午。老老实实把各网段隔离好后面能省非常多事。3.2 实际部署步骤SANDSTONE HYPERCUBE 的初始化基本是向导式的整体流程大概是上架安装。节点装上导轨、插好电源线、网线。根据规划表把管理口连到管理交换机。配置带外管理。登录IPMI把节点的带外IP配好确认物理健康状态正常。配置节点操作系统网络。首次开机后通过控制台配置节点的管理IP。这个IP是加入集群的入口。环境预检。SANDSTONE HYPERCUBE 的部署向导一般会先做一轮环境预检检查内存、CPU、硬盘数量、网络连通性。没通过的项目会直接标红必须全部处理好才能继续。初始化集群。填集群名称、管理网络、存储网络、DNS、NTP然后选择要加入集群的节点。加入过程会把节点上的硬盘重新格式化组成分布式存储池这个操作是不可逆的数据会清空千万别在已有业务的机器上做。等待数据均衡。节点加入完成后存储池会自动开始数据均衡。均衡期间节点会持续进行数据复制业务性能会有所下降但不需要人工干预。部署的时间一般要看节点数量和磁盘容量3节点集群大概两三个小时能搞定包括系统安装和数据池创建。如果期间报错大多出在网络不通或硬件预检不通过。3.3 存储池与虚拟机创建初始化完成后建虚拟机就变得很简单了。创建虚拟机时需要注意几个关键参数虚拟机磁盘的存储策略。一般有双副本(2副本)和三副本(3副本)生产环境至少选双副本千万别选单副本虽然省空间但数据安全性没保障。磁盘类型选厚置备还是精简置备。我建议对数据库类虚拟机用厚置备防止磁盘增长导致底层存储碎片化对普通文件服务器用精简置备更省空间。虚拟机CPU和内存预留。不要在配置页面上直接给虚拟机分配整个物理节点的全部内存要留足系统本身的开销否则创建虚拟机会直接失败。建虚机常用的模板化操作是先创建一台基础虚拟机装好操作系统和常用软件然后制作成模板后面新开虚拟机直接从模板克隆。SANDSTONE HYPERCUBE 的克隆速度取决于存储池性能NVMe缓存层充裕的情况下克隆一台小型Linux虚机也就是几十秒的事。4. 超融合关键运维技巧4.1 日常监控与告警配置超融合一体机最大的亮点就是虚拟化管理平台里看一眼就能知道所有节点状态。但很多人把这个便利用歪了从来不看告警等用户报故障了才上线排查。我建议至少配置这么几类告警告警类型阈值参考说明节点CPU利用率持续高于85%关注是否有虚拟机资源超分严重节点内存利用率持续高于90%同样警惕过度超分存储池容量高于85%触发警告高于95%触发紧急防止存储写满导致集群只读分布式存储延时写延迟高于10ms正常应该在1ms内硬件健康状态任何异常都触发包括硬盘SMART、风扇、电源、电池存储池容量告警是最关键的因为分布式存储在写满后会进入保护状态这个状态下虚拟机可能无法迁移也不能正常创建处理起来非常麻烦。我在一个客户现场就看到过因为日志虚拟机把存储池占满、整个集群进入只读状态的案例最后只能停机加盘清理代价非常大。4.2 扩容和升级胆子要大心要细扩容是超融合最爽的操作之一。加新节点时先做好物理上架和网络连通性检查然后登录管理平台把新节点加入集群。加入后存储池会重新均衡新硬盘的容量加入整体资源池。这里要注意扩容时不要一次性加太多节点建议每批次加一个或两个节点。一次加太多节点的数据均衡量会很大如果业务高峰期做扩容容易对现有业务造成影响。我一般建议扩容在业务低峰期做并提前评估均衡所需时间。升级方面SANDSTONE HYPERCUBE 的固件和软件升级一般是滚动式升级平台会先后迁移虚拟机关机更新再启动。整个流程设计得很平稳但实际操作中还是要先严格做好备份。升级过程中要保持所有节点网线、电源稳定别在升级期间挪动设备一旦中途断网或断电升级状态就会卡住甚至需要厂商介入修复。4.3 备份与容灾别靠副本打天下超融合的分布式多副本机制能防止“硬盘坏了一块导致虚拟机丢数据”但它不能防止“不小心删除了虚拟机”“虚拟机内业务逻辑出错”“整个集群机房断电”这类逻辑层和物理层灾害。所以别以为有副本就不做备份。我在生产环境中的做法是使用虚拟机级备份功能对关键虚拟机做每日全量或增量备份备份到独立的备份服务器或对象存储。对数据库虚拟机额外做数据库日志备份或者快照配合恢复保证崩溃时能恢复到最近的时间点。定期做恢复演练这是很多运维人员忽略的。备份数据如果从来没恢复过就等于没有备份。我见过某公司在一次误删事故后发现备份文件在恢复时校验失败那时候就已经晚了。有条件的话配置异步容灾副本到同城另一个集群这样整个机房级别的故障也能恢复。备份这块确实是平时觉得花钱花时间关键时刻救命的典型例子。务必重视备份的恢复演练环节而不是“备份任务都成功了”就觉得万事大吉。5. 常见故障排查与实战心得5.1 存储性能突然下降怎么查SANDSTONE HYPERCUBE 在实际运维中我遇到最多的问题就是虚拟机跑着跑着变慢了尤其是数据库特别卡。排查这类问题是有清晰的逻辑链路的。第一步看存储池整体IOPS和延迟。登录管理平台看分布式存储的全局监控数据。延迟高说明后端存储压力大延迟正常但某台虚拟机慢问题就可能在虚拟机内部或者网络。第二步看物理节点资源。哪个节点的CPU和内存接近饱和重点排查这个节点上跑的虚拟机把它迁移到其他节点看问题是否缓解。第三步看缓存命中率。如果是存储池的写缓存被打满延迟会明显飙升。此时通常是一段时间内有大量写操作比如大批量导入数据或者备份任务集中执行。解决思路是把这类操作错峰或者增加缓存盘。第四步查网络。存储网络有丢包时延迟会忽高忽低。通过登录交换机查丢包计数和错误计数基本能确认网络问题。这四步走下来大多数性能问题都能定位到具体瓶颈。我强烈建议别跳过任何一步很多人一上来就怀疑硬盘坏了结果查了半天发现是自己的备份脚本在同一时间开始跑全量备份把存储IO挤爆了。5.2 节点失联的处置经验节点失联有两种一种是管理平台显示节点红叉一种是SSH能通但平台无响应。前一种通常是网络或硬件故障后一种通常是服务卡死。处理流程先登录IPMI看物理机是否还活着电源状态、风扇转速、温度。尝试SSH登录节点看系统负载。如果load average高得离谱通常是某个存储进程死循环了需要重启对应服务。确认不是硬件和系统问题后从管理平台尝试强制隔离该节点让集群把该节点的虚拟机迁移出去。如果强制隔离也失败才考虑重启节点。重启后要关注该节点上的硬盘重建和数据同步。一个容易忽略的细节是超融合集群在节点离线时集群会降级运行此时其他正常节点上的虚拟机IO性能也会受影响因为分布式存储的副本可能无法同时满足系统会等待恢复。所以节点失联不是”某台机器挂了“这么简单而是整集群的可用性抖动。这个背景下日常监控节点硬件健康是非常重要的。5.3 网络抖动对集群的影响一次惨痛教训我第一次独立运维 SANDSTONE HYPERCUBE 时经历过一次比较严重的故障起因只是机柜里一台旧交换机的光模块性能劣化导致存储网络每隔几分钟就丢包一次。现象是所有节点都显示正常但虚拟机创建失败、存储池IO延迟居高不下业务系统反复报错。我在平台上翻来覆去查存储、查虚拟机都看不出问题直到登录交换机看端口错包计数才发现某个端口上CRC错误数量疯狂增长错误包已经被丢弃了。排查加上解决用了大半天。事后总结就是超融合的稳定性高度依赖网络质量网络层面的间歇性抖动表现在上层就是“存储不稳定虚拟机各种怪毛病”。这个经验让我后来在所有一体机项目的网络规划里都把交换机光模块质量、链路冗余放在了最高优先级。运维上可以做的小优化是在交换机上对存储网络端口开启风暴控制同时把不必要的组播流量过滤掉降低对分布式存储协议的影响。6. 写在最后一些个人体会用 SANDSTONE HYPERCUBE 超融合一体机干了这几年带过测试环境也带过生产环境最大的感受是超融合把运维门槛确实降低了但也没低到买回来插上电就能跑十年不管的程度。有几个心得想分享给准备入手或者刚入手的同行前期网络规划花的时间永远值得。网络做得好后面可以少处理一半以上的疑难杂症。所有节点和虚拟机的命名、IP、账号、端口规划都写进文档里。多节点环境下靠脑子记IP一定会出乱子。监控告警一定要配到位告警渠道要能触达到人。别怕告警多就怕没告警等真正坏的时候才发现平台已经默默降级好几天了。没事的时候多演练恢复流程。真遇到节点失联、数据异常、磁盘故障能快速反应的唯一方法就是之前演练过别以为临场看文档来得及。对厂商的售后支持别完全依赖但该用的资源还是要用。一些存储层面底层日志和修复策略厂商工具比你自己折腾要稳妥得多重要事故该上报就上报。最后再分享一个小习惯。我在每次做完节点扩容、存储策略调整等操作后都会主动把告警阈值再看一遍确认没有因为新增的容量把已有阈值覆盖掉。这个习惯帮我避免过两次很尴尬的扩容后漏告警问题也算是一个不容易注意到的细节收获了。