深入解析aCloud VS3.0虚拟存储：分片、副本与仲裁机制

你负责的那套虚拟化集群，下了班之后是不是也经常让你心里不踏实？尤其到了晚上，手机一响，心跳先漏半拍，多半就是某个宿主机宕了，或者哪台业务虚拟机出了幺蛾子。这时候大家最怕的是什么？不是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 我先列一份排查清单

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路CPU，256GB内存，6块960GB SSD加2块3.84TB NVMe做缓存和高性能数据层，2块16TB机械盘做大容量冷数据层。三节点起步，后续扩容按相同节点堆叠，这样整体的调度和副本分布都会非常平稳。

结尾说点实在话

写到这里，VS3.0从数据分片到仲裁机制这些核心链路，基本已经过了一遍。

技术这块的分享，该讲的我尽量都讲了，但最后我还是想再啰嗦几句我个人的实际运维心得。整套超融合虚拟存储，尤其是VS3.0这套体系，其实已经非常成熟了，它的设计思路和工程实现里都体现了极强的“防止最坏情况”思维。但是，再好的软件设计也架不住底层硬件的抽风，或者不合理的规划拆台。我见过太多集群出问题，最后查下来不是软件本身不行，而是当初在规划阶段为了省钱省事，把存储网络和业务网络混跑，或者副本放置没考虑物理机柜的隔离。

所以，我给正在规划或者已经运行aCloud的朋友一个比较实在的建议：前期多花心思在物理网络和故障域设计上，中期把你的容量水位管好，后期遇到故障别急着骂存储，按排查清单一步一步查。你的VS3.0集群大概率会一直健康地服役很多年。记得在项目上线前多花点时间做几次断电和断网演练，让系统里跑的那些虚拟机真的经历过一次故障切换，心里才有底。这也是一台让你晚上睡得踏实的超融合，和一台只配活在宣传册里的超融合，最大的区别。