你负责的那套虚拟化集群下了班之后是不是也经常让你心里不踏实尤其到了晚上手机一响心跳先漏半拍多半就是某个宿主机宕了或者哪台业务虚拟机出了幺蛾子。这时候大家最怕的是什么不是CPU跑满也不是内存不够而是底层那摊数据——如果存储没扛住全完蛋。我这两年最常接触的存储底座之一就是深信服aCloud的虚拟存储VS3.0。很多人可能对它还没有太强的概念只知道它是超融合架构里的分布式存储模块是aCloud的“全自研研发”部分。实际上只要你把业务真正跑在aCloud上无论是数据库、文件服务器还是桌面虚拟化VDI你的所有数据IO最终都要交给VS3.0去处理。所以说白了整个集群能不能让人省心九成拼的就是这套存储干得怎么样。如果你正在把业务迁到aCloud或者已经在用了但总被底层存储搞得焦头烂额这篇东西就是写给你看的。我不准备讲太多花里胡哨的营销概念只把这套虚拟存储在工程落地时涉及的数据分片、多副本机制、仲裁选主逻辑、故障域隔离这些底层算法逻辑以及我们在实际交付里调整过哪些参数和流程一步步掰开来讲。不用怕听不懂我会尽量讲成人话。1. 为什么说理解数据分片是运维VS3.0的第一道门槛很多刚接触超融合的朋友都会先入为主地觉得分布式存储就是“把几块硬盘拼成一个大的SAN”。这个理解不算错但太粗了。以VS3.0的底层逻辑为例它遵循的是标准的分布式存储分片原则。一个很直观的做法是你和客户签下的存储性能其实不是由整机性能决定的而是由一个叫“数据分片”的粒度决定。也就是说VS3.0会把每一块虚拟硬盘虚拟磁盘VHD对应的存储部分按照固定大小进行切分打散到集群里的所有物理节点上。1.1 业务VDI是如何被映射到一块块小分片上的我们先来看一个最常见的生产场景假设你在aCloud上跑桌面虚拟化VDI。也就是云桌面一百个用户一人一个Windows 10虚拟机。在这种业务下底层的VS3.0不是像传统存储那样按LUN把一整块空间划分好而是会先建立一个全局的地址索引也就是元数据表然后在物理磁盘上按照默认策略把数据切分成一个个标准大小的数据片。这里的关键点是这些数据片会被分散存储到集群内不同宿主机的物理磁盘上。打个简单的比方你的一百个云桌面虚拟机文件不是待在一台物理机的硬盘里的。恰恰相反它会被“肢解”成很多大小一致的小碎片分散在不同物理主机的硬盘里。那么在VS3.0里一个虚拟机的文件到底被分得多碎这就涉及到一个“分片宽度”的概念。在实际部署里系统会把这些碎片打散得比较厉害。粒度越小数据在整个集群里的分布就会越均匀理论上并发读写性能就越好因为每个物理节点都在帮忙干活。但代价是元数据规模会变大管理索引会变得更复杂。1.2 分片策略决定了热点是否扎堆性能好不好除了看硬盘快不快还要看数据热不热。传统RAID容易遇到的一个典型瓶颈是“单盘热点”在某一块盘上的数据被读写了成百上千次这块盘就会成为性能短板。用了VS3.0的分片机制之后这个热点问题会被有效分散。因为一份业务数据的片被均匀地打散到了多块磁盘上相当于把原来一个人扛的活分给了一支小队去扛。但这里有一个会踩坑的地方分片的“均匀”不是纯靠运气而是靠精心设计的哈希散列和容量调度算法。在实际操作中系统不仅要认物理磁盘的大小还得看IOPS能力。比如同一个集群里混着SSD固态盘和机械盘VS3.0就不会傻到把热数据的片丢到机械盘里。它会优先把承载核心业务虚拟机的数据分片调度到高速磁盘上。注意我们自己在交付项目时如果对分片的路径和映射关系有疑问习惯用的办法是在系统诊断里查看数据分布报告重点观察各节点间的容量水位差距。如果有一台宿主机长时间比其他几台高出不少基本可以断定分片分布策略因为某些原因没生效大概率和你调整过存储策略有关得早点排查。2. 一份数据到底写几份两副本模式的工程解读关于VS3.0的规格你在深信服的产品介绍页上大概率能查到这样一句话支持多副本机制保障数据安全。这句话看起来有点像是废话但真正理解它对运维工作有多重要得看你在生产环境里配了几份副本。2.1 单副本、双副本、三副本之间的权衡VS3.0默认推荐使用两副本策略。什么意思就是你的每一个数据分片不是只在物理环境里存一份而是同一份数据在集群内不同位置存两份。这两份数据互为副本并保持强一致。可以这么想假设你的物理环境里有两台宿主机。主机A上的一台虚拟机写了一段数据这段数据被切成了分片主副本可能落在了宿主机A的某块SSD上次副本则会被VS3.0自动调度到宿主机B的另一块SSD上。由于是同步写的主机A在告诉业务“写入成功”之前主机B也必须确认写完。这样除非两台宿主机同时挂了否则这段数据不会丢。既然两副本已经挺保险为什么还会有人考虑三副本这主要取决于你的硬件规模和成本承受力。三副本的好处是可以允许同一个集群内有两台宿主机同时故障数据依然完整可用。但代价也很明显一是存储容量利用率直线下降原来两副本用掉50%的可用空间三副本就直接掉到33%二是写IO会翻倍对网络和硬盘都是一种压力。2.2 主副副本分工与分片条带化细节在VS3.0里一份数据被切成很多片每一片都有主副本和次副本。主副本一般承担读操作的响应次副本平时主要负责容灾。当主副本所在的磁盘或者宿主机出现故障次副本会被提升为新的主副本继续服务整个过程对上层虚拟机来说是透明的。条带化这个词可能有点DOS时代的味道但VS3.0的分片本质上就是一种最大化的条带化。它会按条带把一份逻辑上连续的数据分散到集群中的多个存储节点中。打个比方你的一顿饭本来是放在一个碗里的为了不让一个碗烫手VS3.0把它倒进了好几个小碗里分给不同的人捧着。想吃的时候所有小碗都得端到桌上。这样一来读写请求会被分摊到多个物理节点上性能获得了横向扩展的能力。不过我想提醒一句别因为数据分散了就觉得单块硬盘死掉无所谓然后大规模采购老旧的拆机硬盘来用。分布式存储可以把单盘故障的影响降到最低但它不是一个让劣质硬件“滥竽充数”的遮羞布。在VS3.0的生产环境里硬盘出现慢道、坏块照样会影响对应分片的性能表现说不定整个集群的时延都会被拉起来。3. VS3.0的写IO路径从客户端到落盘经历了什么很多运维在排查性能问题时会觉得很玄学明明底层SSD速度很快但虚拟机内的数据库写入就是慢得离谱。要搞清楚这个背后的逻辑我们得先弄明白一次写IO在VS3.0里是怎么走的。3.1 CPU先处理还是磁盘先处理为何缓存层如此重要写命令从虚拟机里发出来以后会先经过宿主机的虚拟化层再通过VS3.0的存储客户端组件找到这个数据分片所在的主副本位置。注意这不是一个简单的“拿到就去写”里面还有缓存层在起作用。VS3.0的缓存机制其实分了好几层。最早最容易理解的是写缓存。当数据被判定为需要写入时系统并不一定直接落盘而是会先写入到当前节点的SSD缓存层或内存缓存中然后等待异步刷盘。而读操作则优先读内存缓存再读SSD缓存最后才去机械硬盘里找。3.2 刷盘策略与掉电保护的关系这里有个非常要命的设计如果数据只写在缓存里还没来得及刷到物理盘上突然整个节点断电了数据是不是就没了所以VS3.0在这里引入了硬件层面的掉电保护依赖。在实际部署过程中我们是强烈建议给物理服务器配上BBU电池备份单元或者支持电容掉电保护的RAID卡以及SSD。因为虚拟存储的写缓存设计得再巧妙一旦遇到极端断电保护措施如果不完善就容易导致缓存里的数据来不及落盘引发数据不一致或者需要额外校验来恢复。说白了你在采购物理服务器时如果打算跑aCloud虚拟存储那么服务器必须支持标准掉电保护功能。这不是可以随意砍掉的配置为了省几千块钱在这个地方让步万一遇上一次意外断电代价可能就是要重建整个虚拟机存储那时候你说不清是心疼钱还是心疼数据。3.3 两副本同步写是性能杀手还是安全底座回到双副本既然写数据要同时写两份而且要求两份都成功才算成功那是不是意味着性能直接减半从理论上说确实多了一次远端网络写入的延迟。但在万兆网络已经成为标配的数据中心里这种网络延迟对大多数业务来说微乎其微尤其是在节点数不多的小型集群里。真正影响写性能的反而不是双副本这个机制本身而是底层物理网络的质量与交换机配置。VS3.0在后端存储网络之间走的流量非常大如果管理口、业务口、存储口全部混跑在同一个千兆交换机上那么两副本的同步写就会变成一场灾难。实操经验在规划aCloud集群时我把存储网络与业务网络做物理隔离存储网单独用万兆交换机实在不行也要做VLAN隔离并把存储流量放在独立的物理网口上。这样每笔数据写两份的开销会显得非常微小几乎感知不到。4. 仲裁机制全景解析当集群出现“脑裂”到底听谁的前面这些说到底还是常规操作。到了仲裁机制这一篇才是真正显示出分布式存储复杂性和精华的部分。也是我最想写的部分。4.1 为什么多副本反而引出了“谁说了算”的问题既然存放了多份副本那么当某些节点之间失去通信网络出现分区时问题就来了我该向谁去确认数据状态谁手里的数据才是最新的、有效的这时候仲裁机制就必须站出来充当物理世界里的“裁判”。以标准的两副本加仲裁部署为例。经典情况是这样的集群里有两台宿主机是存储节点各自保存了对方数据的副本。正常情况下彼此通过心跳线保持通信。但说不定哪天机房某台交换机抽风导致两台宿主机之间网络中断但它们和上层管理端还在通信。这时候两台宿主机都会认为自己手里的数据才是活的对方已经死了。这种事在分布式系统里称之为“脑裂”。如果两个节点都坚持对外提供写入服务那这些写入的数据就会各自为政以后再也合不到一起这是绝对不可接受的事情。VS3.0引入仲裁机制即当对端状态无法确定时存储节点会去找第三者请求裁决。这个第三者可以是部署在管理平台上的一个仲裁服务进程也可以是一个独立的轻量级节点。4.2 仲裁投票计算的逻辑为什么是多数派有了仲裁者问题就好办了。比如三节点架构两个数据节点加一个仲裁节点。当两个数据节点失联它们会各自向仲裁者汇报“我现在怀疑对方挂了我要成为主节点请投我一票。”仲裁者会根据自己目前所掌控的信息对比双方的存活状态、数据版本、心跳时间戳等指标最终将票投给更符合条件的一方。获得多数派支持的那个节点才有资格对外继续提供存储服务。另一方则会主动降级停止对外响应避免两个“大脑”同时发号施令。在VS3.0实际落地部署时默认的最小推荐生产配置往往不是两台而是三台。多出来的那一台不单单是为了多存一份数据更是为了在仲裁投票时能形成多数派。如果你只有两台存储节点用两副本当一台宕机时你想让剩下那一台继续提供服务它就需要去寻找第三方仲裁者。这个仲裁者通常可以放在管理节点上。4.3 双副本仲裁者的落地模板我们交付里最常给中小客户推荐的是“两台计算存储一体机 一台轻量级仲裁机”的组合。仲裁机不需要太高的硬件配置甚至还可以顺带承载aCloud的管理平台。这样当两台存储节点中的一台宕机剩下的一台仍然拥有超过一半的票数可以继续对外提供存储服务而不中断业务整个故障切换过程数据零丢失业务可能只会感觉到轻微的抖动。这个过程很像班级里三个人商量去哪吃饭班长和副班长意见不统一时让学习委员来投票。谁拉到两票谁就说了算。分布式存储的仲裁逻辑本质上就是在避免“公说公有理”导致的混乱。4.4 仲裁者自身挂了怎么办很多人会追问一嘴如果仲裁者自己宕机了呢数据还能不能正常读答案是能。因为在正常情况下两台存储节点之间的通信是通畅的数据主副本的确认写可以不依赖仲裁服务。仲裁服务只在出现了网络分区、节点失联等异常场景下才被迫介入。仲裁者短暂不可用不会影响正常的数据读写。但要注意如果这时恰好又有一台存储节点宕机导致多副本主从无法自我确认那问题就会变得棘手了。极端情况下系统为了保证数据一致性可能会暂停写入服务优先保障数据不损坏。所以在比较核心的生产环境里我们也建议把仲裁节点的可用性维持在较高水准说白了至少别让它成为整个集群的单点故障。5. 故障域隔离光有仲裁还不够还得考虑“怎么放”搞定了分片搞定了副本搞定了仲裁是不是这套虚拟存储就万无一失了呢还没完。数据放在哪怎么放是运维规划里一个既考验智商又考验经验的事情。5.1 跨主机副本放置策略的价值双副本意味着同一份数据一定会有两份那么这两份数据如果都放在同一台宿主机上的两块硬盘里这个副本策略就完全失去意义了。主机一旦宕机两份数据全没数据照样完蛋。因此VS3.0在实际进行数据分片的副本分布时会自动识别并遵循“反亲和性”规则简单讲就是强制要求主副本和次副本必须落在不同的宿主机上。如果集群规模大一点支持跨机柜部署副本还会被要求落进不同的机柜中。这种规则设计的意义在于对抗“群死群伤”。比如你的一整个机柜因为交换机故障或者供电异常整体断电了如果副本全都放在这个机柜内数据就直接不可用。但如果你提前规划了跨机柜放置那么一个机柜断电另一个机柜里的副本还能顶上。5.2 机架感知官方文档不会明说的那层门道很多初次建aCloud集群的朋友可能会忽略一个叫“机架感知”或者“拓扑感知”的细节。如果你们的物理服务器分布在不同的机柜中但底层并没有开启机架感知功能VS3.0进行数据分布时会认为所有服务器处在一个同一位置有可能把主副本放到机柜A把次副本也放到机柜A另一个机柜B只是空转。一旦机柜A出现整体性故障业务数据就面临重大灾难。我们在做规划时基本都会要求从底层把物理位置信息编排到VS3.0的感知策略里。让系统在做分片副本放置时知道尽量不让同一个数据的多个副本落在同一个故障域内。这个动作往往能在很大程度上避免区域性硬件故障。故障域这个概念不光是物理机柜。还可以精确到电源域、网络交换域。尤其是双电源服务器如果两台服务器的电源分别接到了两个不同的UPS回路里在设计副本放置时也可以考虑让主副本在一个电源回路次副本在另一个电源回路。这种细致末节在核心业务的生产环境里非常值得做。6. 性能调优实战缓存分层、容量水位与快照链聊完底层数据安全我们来聊聊怎么让这套虚拟存储跑得快同时又不被容量问题拖后腿。6.1 分层存储里的“热数据优先”到底是怎么判定的VS3.0和很多现代化的超融合存储一样会做缓存分层。它会在硬件层面识别出哪些是SSD哪些是机械硬盘。然后通过实时的IO访问计数、读写频次统计把访问频繁的热数据块保留在快速存储层里。我用个简单的描述来帮助理解有一家食堂炒好的菜都放在后厨机械盘厨师太忙没法每道菜都现炒。于是他把一些常点的菜先盛出来放在取餐窗口SSD缓存客人来了说出菜名厨师直接从窗口把菜端出来速度快得多。VS3.0的SSD缓存差不多就是这个逻辑但它是按数据块来精细标记的而不是整块虚拟磁盘缓存。它能智能识别哪部分数据是热点把这个范围内的数据块保留在SSD层冷数据则逐渐被淘汰回机械盘里。6.2 容量水位超过阈值时的连锁反应所有分布式存储都有个通病容量别用得太后。用得太满性能和稳定性都会出问题VS3.0也一样。当某个节点的容量水位逼近一个较高的警戒值时比如接近90%VS3.0可能会进入一种“容量保护模式”。在这种模式下它会限制一些新的写入请求甚至触发数据自动重平衡把一些分片从高水位节点搬迁到低水位节点。但数据重平衡是很吃资源的操作它会占用主机的计算资源和网络带宽。如果业务正处在高峰期这些资源被挤占前端业务延迟就会明显增加。我个人在管理aCloud时会把集群整体容量水位控制在70%以下。超过70%就要开始严肃讨论扩容方案了而不是等到快满了再着急忙慌地去加磁盘。因为扩容本身也要触发数据重分布也需要预留一定的缓冲空间。6.3 快照与克隆对性能带来的隐形影响VS3.0的一大亮点是支持虚拟机快照和链接克隆。这在交付VDI桌面云项目时特别好用只要做好一个母盘就能秒级生成几十上百个虚拟桌面。但别只顾上体验秒级创建的快乐快照和链接克隆技术在写入时会产生一种叫“写时重定向”的机制。也就是说虚拟机发生新的写入时数据不会直接写到原始盘上而是要写到新的差异数据层里。差异数据越来越多整个存储系统的随机读比例会大幅上升底层存储的IO压力会随之大增。如果你们的VDI项目里用户经常大量安装软件或者保存大文件快照盘的增长会非常快进而拖慢整个存储集群的性能。所以我会建议定期对链接克隆的桌面进行刷新操作即把差异数据合并回母盘甚至可以安排策略每周自动强制刷新一次虚拟桌面免得个人数据把存储底层拖垮。7. 一图流梳理aCloud虚拟存储故障排查的思路这部分是纯经验干货。实际在运维VS3.0的过程中遇到故障不可怕怕的是连排查思路都没有东一榔头西一棒子。我先给出一个我常用的判断顺序表然后在下面针对最典型的场景详细讲透。7.1 我先列一份排查清单故障现象优先排查对象检查要点虚拟机IO延迟突然升高物理磁盘健康状态、存储网络丢包率确认是否有慢盘、坏道检查交换机端口错误计数单台宿主机上的虚拟机全部卡的厉害该宿主机的存储网络链路、缓存剩余空间看看是不是存储网口被业务流量挤爆了或者缓存层写满某个LUN或存储池性能骤降热点数据分布、快照链长度查看数据是否严重倾斜检查快照层占比出现部分节点失联心跳网络、仲裁服务状态确认集群控制平面是否健康检查仲裁日志重启一台宿主机后所有虚拟机没有漂移存储集群故障域策略检查是否全部副本都在本机导致无法热迁移确认反亲和策略生效7.2 慢盘问题的完整排查链路“慢盘”是分布式存储运维中非常容易踩到的坑而且特别难缠。一开始业务反应“数据库有点慢”这时候你进aCloud控制台查看可能一切指标都正常CPU不高内存不紧存储池健康状态也显示正常。但数据库的SELECT请求就是几百毫秒才返回。这时候很有必要深入到物理节点上去检查磁盘状态。VS3.0底层也是跑在Linux系统上的你可以通过命令行工具去查看物理硬盘的IO状态看看是不是有磁盘出现了大量的延迟。如果很不幸发现有块机械盘的平均IO等待时间明显高于同型号其他盘大概率就是遇到了典型的慢盘问题。慢盘未必会立刻报错但它会严重拖慢跨节点的数据确认写流程。处理办法是把该磁盘对应的存储角色先接管走让数据副本重新分布到健康磁盘上然后在业务低峰期更换这块物理盘。绝不能在高峰期直接拔盘那样很容易引起临时性的数据重建风暴整个集群性能都会崩。7.3 主机失联时的数据保护动作还有一种比较常见的情况某台宿主机因为意外断电或者内核宕机发生了失联。这时候VS3.0会在短时间内自动将该节点上的数据副本在其它健康节点上进行补全这个过程叫数据重建或数据重构。数据重建是一个高IO的过程。它会占用其他健康节点的存储带宽和CPU资源可能会造成短暂的存储性能波动。如果这台失联的主机在短时间内能恢复并且重新加入集群那问题不大。但如果它一直无法恢复你又强行允许系统持续把所有副本都重建完毕那你就得面临双风险一方面重建期间磁盘可能扛不住另一方面重建完成后这台主机再回来又会引起新一轮的数据反补。所以我通常的建议是遇到主机失联先判断是否能在半小时内恢复如果判断不行直接准备替代资源节点让它干净利落地退出集群把副本补齐。8. 从实战规划角度出发聊聊节点选型和容量规划讲完了这些原理和故障机制最后来点“逼格”低但巨实用的内容——选型和容量规划。8.1 虚拟机存储策略性能优先还是容量优先VS3.0里支持针对不同的虚拟机或存储策略来定义不同的数据冗余方式比如性能优先策略、容量优先策略。考虑到不同业务的差别我建议在同一个集群里用不同的存储策略来隔离业务。比如核心数据库虚拟机开启三副本或双副本加SSD缓存优先而普通文件服务器、备份数据虚拟机则可以使用两副本但不对SSD缓存做强制要求。8.2 给硬盘算账的正确姿势假设你要规划一个能承载50台虚拟机的集群每台虚拟机平均分配200GB磁盘空间业务需要保证双副本。总数据量算出来是50乘以200GB等于10TB逻辑容量。为了做到双副本物理存储占用就需要翻倍变成20TB。考虑到VS3.0的元数据开销以及系统本身要预留一部分空间做数据重建缓冲那你实际配置的裸容量建议至少在25TB以上。如果你准备全闪配置那盘的数量和型号就要围绕性能冗余去考虑不能光看总容量。尽量让SSD的总IOPS能力大于你所有业务虚拟机峰值IOPS加起来的1.5倍避免在高并发时段出现存储性能瓶颈。8.3 避免“一台顶三台”的集中式思维很多习惯了传统架构的运维老哥刚接触超融合时总喜欢买很贵的服务器磁盘插满内存拉满美其名曰“一台顶三台”。这个思路在虚拟化场景里偶尔还能接受但在分布式存储里是大忌。因为VS3.0横向扩展能力虽然不错但数据分片的副本策略要求数据必须分散。如果一台服务器上挂了超大容量的磁盘另一台服务器磁盘很少那么那台超大容量服务器承载的数据副本就很可能会与其它节点的副本形成数据分布不均衡从而引发故障域风险。更合理的方式是采用同构节点数量可以多一些单节点容量适中即可。以我们常见的配置模板举例单节点采用2路CPU256GB内存6块960GB SSD加2块3.84TB NVMe做缓存和高性能数据层2块16TB机械盘做大容量冷数据层。三节点起步后续扩容按相同节点堆叠这样整体的调度和副本分布都会非常平稳。结尾说点实在话写到这里VS3.0从数据分片到仲裁机制这些核心链路基本已经过了一遍。技术这块的分享该讲的我尽量都讲了但最后我还是想再啰嗦几句我个人的实际运维心得。整套超融合虚拟存储尤其是VS3.0这套体系其实已经非常成熟了它的设计思路和工程实现里都体现了极强的“防止最坏情况”思维。但是再好的软件设计也架不住底层硬件的抽风或者不合理的规划拆台。我见过太多集群出问题最后查下来不是软件本身不行而是当初在规划阶段为了省钱省事把存储网络和业务网络混跑或者副本放置没考虑物理机柜的隔离。所以我给正在规划或者已经运行aCloud的朋友一个比较实在的建议前期多花心思在物理网络和故障域设计上中期把你的容量水位管好后期遇到故障别急着骂存储按排查清单一步一步查。你的VS3.0集群大概率会一直健康地服役很多年。记得在项目上线前多花点时间做几次断电和断网演练让系统里跑的那些虚拟机真的经历过一次故障切换心里才有底。这也是一台让你晚上睡得踏实的超融合和一台只配活在宣传册里的超融合最大的区别。