1. 从“单打独斗”到“团队作战”aCloud虚拟存储的进化之路大家好我是老张在IT基础设施这块摸爬滚打了十几年亲眼看着存储技术从一堆笨重的磁盘阵列一步步演变成今天软件定义的超融合形态。今天咱们不聊那些虚的就掰开揉碎了讲讲深信服信服云aCloud里那个核心的“大心脏”——虚拟存储Virtual Storage简称VS。这玩意儿从VS2.0一路迭代到VS3.0.3可不是简单的版本号升级而是一场从“能用”到“好用”再到“聪明且可靠”的深刻变革。简单来说虚拟存储VS就是aCloud超融合架构里的“仓库管理员”。它把一堆服务器自带的硬盘有快的SSD也有慢但便宜的HDD通过软件“池化”成一个巨大的、统一的存储资源池然后灵活地分配给上面的虚拟机用。它的核心目标就俩高性能和高可靠。高性能就是让虚拟机读写数据像从本地SSD取东西一样快高可靠就是哪怕硬盘坏掉一两块甚至整台服务器宕机你的业务数据也毫发无损服务照常跑。这听起来简单但背后从VS2.0到VS3.0的技术演进充满了工程师们的巧思和实战中踩过的坑。最早的VS2.0时代可以看作是“单兵作战”模式。那时候的存储管理颗粒度比较粗是以整个虚拟机磁盘文件qcow2格式为单位的。想象一下你有一个100GB的虚拟机磁盘它很可能就完整地存放在某一块机械硬盘上。这种方式的弊端很明显首先这个虚拟机的性能上限就被单块硬盘的IO能力给卡死了尤其是当多个虚拟机挤在同一块硬盘上时性能“打架”是常事。其次数据重建比如某块盘坏了的负担很重因为你要把整个可能很大的文件从其他副本盘上完整地拷贝过来耗时很长期间性能压力也大。VS2.8版本引入了一些重要的补丁和优化比如IO重试机制和虚拟共享盘支持。IO重试机制就像给存储访问加了“保险丝”当网络闪断或存储节点暂时无响应时虚拟机不会立刻崩溃而是会智能地重试等存储恢复后自动续上这对保障业务连续性至关重要。而虚拟共享盘则是为了支持像Oracle RAC这样的集群数据库让多台虚拟机可以同时访问同一块“磁盘”这在传统架构里得靠昂贵的外置共享存储才能实现VS2.8开始在超融合内部做到了。但真正的质变发生在VS3.0。它引入了一套全新的“团队作战”体系核心思想就是化整为零和并发协作。存储管理的颗粒度从“整个文件”细化到了4GB大小的“数据分片”。一个大的虚拟机磁盘文件会被切成很多个4GB的分片这些分片再通过条带化技术像编辫子一样并发地写入到多块不同的硬盘上。这就好比原来一个仓库的货物都堆在一个角落现在被分门别类、均匀地摆放到仓库的各个货架上。这样一来单块硬盘的IO压力被分散了多块硬盘可以同时为同一个虚拟机的IO请求服务性能得到了质的飞跃。数据重建也变得轻量化只需要重建那些出故障的硬盘上的分片即可速度快对集群影响小。到了VS3.0.1和VS3.0.3这套体系又增加了应对更大规模、更复杂场景的能力。延伸集群实现了跨机房的“双活”数据在两个机房各存一份一个机房整体断电业务能在另一个机房秒级恢复这是金融、医疗等关键业务梦寐以求的能力。存储快照的引入让数据备份和快速恢复变得更加高效和灵活。而磁盘亚健康检测则像给硬盘做了个“全天候体检”能在硬盘彻底罢工前预警提前迁移数据把故障影响降到最低。所以你看aCloud虚拟存储的演进就是一个不断追求更细粒度、更高并发、更智能自治的过程。下面我们就钻进这几个关键版本里看看具体是怎么实现的。2. VS2.0到VS2.8夯实基础与关键补丁咱们先回到起点看看VS2.0是怎么打基础的。这一版的核心架构今天看来有些“古朴”但很多设计思想一直延续了下来。2.1 VS2.0读写缓存分离与早期数据保护VS2.0时代aSAN也就是VS的存储管理单元是整个虚拟机磁盘文件qcow2。为了提升性能它引入了SSD作为缓存层而且很有意思地把读写缓存给分开了。读写缓存7:3分区SSD缓存空间被严格划分为两部分大约70%用作读缓存30%用作写缓存两者空间不共用。为啥要这么设计我理解是为了避免读写互相干扰。读缓存的目标是存放热点数据加速频繁读取的操作写缓存则是为了聚合那些零碎的小块写操作比如小于4KB的写把它们攒成更大的数据块再写入后面的HDD避免对HDD进行大量的随机小写那可是HDD的“性能杀手”。这里有个细节SSD写缓存需要虚拟机积累一定的写入量才会触发。不是一来数据就往SSD写而是先到内存缓冲区等攒到一定量了再一次性刷入SSD的写缓存区。如果在这个过程中有读请求系统会聪明地先去写缓存里找找有没有刚写进去还没落盘的数据如果有就直接返回这叫“读己之写”保证了数据一致性。数据重建与热备盘高可靠靠的是多副本。VS2.0通常采用两副本或三副本机制一份数据会在不同的物理服务器上存多份。当一块磁盘故障时系统会启动数据重建。这里的热备盘机制值得一说热备盘是全局共用的不是每台主机配一块。它的数量建议等于副本数比如两副本就配两块热备盘。重建时系统会遵循“主机互斥原则”确保新副本不会和剩下的老副本放在同一台主机上防止主机再次故障导致数据彻底丢失。一个我踩过的坑早期部署时有客户为了省钱SSD缓存配得特别小远低于总数据量的10%。结果就是缓存命中率极低大部分IO请求都直接打到了HDD上业务高峰期性能波动得像过山车。所以缓存盘总容量与实际业务数据量之比最好在20%以上与机械硬盘容量之比至少10%这个建议真是血泪教训。2.2 VS2.8增强可用性与共享存储初探VS2.8可以看作是VS2.0的一个重要增强包解决了一些实际运维中的痛点。IO重试与仲裁机制这个功能太实用了。以前存储网络抖动一下虚拟机可能就直接卡死或异常退出了。VS2.8引入了更完善的IO重试和仲裁判断逻辑。简单说当虚拟机发现存储访问异常时它会尝试“等一等”、“重试一下”而不是立刻“放弃治疗”。同时集群会通过仲裁机制比如利用第三台主机的信息来判断是存储真的挂了还是临时网络问题。如果是临时问题存储恢复后虚拟机会自动恢复运行如果判断是永久故障才会触发HA高可用把虚拟机在别的节点拉起来。这大大减少了因短暂网络波动导致的业务中断。虚拟共享盘这是为了满足数据库集群等特殊需求。它本质上是通过iSCSI代理实现的让多台虚拟机能够像访问本地磁盘一样并发地访问同一块存储在aSAN上的虚拟磁盘。注意这个共享盘是通过存储网络通信的外部的标准iSCSI发起端是扫描不到的保证了安全性和隔离性。当时我们给一个客户部署Oracle RAC就用上了这个功能替代了昂贵的传统光纤通道SAN效果很不错。存储分卷当集群规模变大比如6台实体机起步VS2.8支持了存储分卷。你可以理解成在一个大的存储资源池里再划分出几个逻辑上隔离的“小池子”。不同卷可以设置不同的存储策略比如SSD比例、副本策略实现故障隔离和性能隔离。比如你可以把核心数据库的虚拟机放在一个高性能卷SSD比例高把普通的文件服务器放在另一个容量型卷里互不影响。3. VS3.0架构革命性能与可靠性的双重飞跃如果说VS2.x系列是“改良”那么VS3.0就是一场“革命”。它彻底重构了数据组织和IO路径带来了性能和管理灵活性的巨大提升。3.1 核心概念重塑分片、条带与多副本VS3.0引入了三个基石性的概念数据分片、数据条带化和智能化的多副本分布。数据分片这是管理颗粒度细化的关键。VS3.0默认将每个虚拟机磁盘文件qcow2切割成固定大小为4GB的“分片”。这样做的好处太多了首先单个虚拟机的容量不再受单台主机硬盘空间的限制理论上可以达到整个存储池的容量。其次数据均衡和重建的颗粒度从“整个文件”变成了“4GB的分片”速度更快对系统影响更小。最后它为更精细的数据分布和并发IO打下了基础。数据条带化光有分片还不够VS3.0通过条带化技术让一个分片组默认6个分片为一组的数据能够并发地写入到多块物理硬盘上。你可以把它想象成组建了一个RAID 0阵列但这是在软件层面、跨服务器实现的。条带深度或叫条带大小默认是128KB这意味着连续的1MB数据会被切成8个128KB的块由于条带数是6那么前6个块可以同时写入6块硬盘写完再写后2个。这极大地提升了顺序读写和大型随机读写的吞吐量。数据多副本与分布策略副本机制保证了高可靠。VS3.0的副本分布更加智能遵循几个核心策略主机互斥原则同一个数据块的多个副本绝对不能放在同一台物理主机上。这是数据安全性的底线。数据本地化优先虚拟机的数据会优先有一个副本存放在其所在的主机上。这样虚拟机读写本地数据时IO路径最短性能最好这就是“IO本地化”。容量均衡优先系统会尽量把数据往剩余空间多的磁盘上写避免某些磁盘被过早写满。跨磁盘组/磁盘分布即使在单台主机内部同一个副本的数据也会尽量分散在不同的磁盘组和不同的HDD上充分利用所有硬盘的IO能力。3.2 智能缓存系统Tier分层与流水线无锁IOVS3.0的缓存架构也做了重大革新从固定的读写缓存分区变成了更智能的统一分层Tier设计。SSD空间不再硬性分割而是作为一个整体Tier层来使用。所有数据写入无论大小都先进入SSD的Tier区标记为Dirty然后立刻向上层返回“写入成功”。后台有异步线程源源不断地、顺序地将Tier里的Dirty数据整理后写入到后端的HDD容量层写完后数据在Tier里状态变为Clean。当Tier空间不足时系统会优先淘汰那些“冷”的访问频率低Clean数据因为它们已经在HDD里有完整备份了。这样做的好处是显而易见的消除了读写缓存区固定比例可能带来的浪费空间利用率更高数据只需写入SSD一次开销更小传统架构可能是写缓存 - HDD - 读缓存通过“热度”算法能有效抵抗“扫描读”比如全盘杀毒对缓存的大面积污染保护真正的热点数据。另一个性能黑科技是流水线IO无锁化。传统存储软件在处理高并发IO时经常需要用“锁”来协调多个线程访问共享资源并发高了抢锁就成了性能瓶颈。VS3.0自研的流水线技术把整个IO处理流程像工厂流水线一样拆分成多个步骤每个步骤由专门的“工人”线程/协程负责工序之间通过无锁队列传递“半成品”IO请求。这样IO路径大大缩短并发度再高线程间也不会互相阻塞IO性能可以随着并发数线性增长这在支撑高并发数据库场景时优势特别明显。3.3 平滑扩容与智能重建平滑扩容在VS3.0里变得非常友好。无论是增加新的主机还是新的硬盘系统都能自动将数据重新均衡分布到新的资源上。而且它支持“异构”新加入的硬盘容量可以和旧硬盘不一样系统会智能计算确保数据分布均衡。扩容过程对业务的影响很小数据迁移是在后台静默进行的并且可以设置时间窗口避免在业务高峰期进行。数据重建机制也更加智能和高效。首先是断点续传以4GB分片为单位重建过程中如果中断下次可以从断点继续不用重头再来。其次是多并发重建不再是单线程拷贝可以同时从多个健康副本读取数据向多个目标位置写入速度大大加快。最重要的是分级重建被标记为“重要虚拟机”的数据在重建时享有最高优先级确保关键业务能最快恢复数据冗余性。重建速度还会根据集群负载智能限速在后台默默干活的同时尽量不影响前台业务的性能。4. VS3.0.1与VS3.0.3迈向企业级关键应用随着超融合承载的业务越来越核心对跨数据中心容灾和数据保护的需求也愈发强烈。VS3.0.1和VS3.0.3的升级正是为了满足这些严苛的企业级需求。4.1 VS3.0.1延伸集群与双活数据中心这是实现同城双活的关键特性。传统的灾备是“主备”模式备中心平时闲着只有主中心挂了才启用资源浪费切换时间也长。而双活是“主主”模式两个数据中心同时对外提供服务。VS3.0.1的延伸集群功能允许你将一个超融合集群的节点部署在两个不同的机房称为两个故障域。数据写入时系统会强制将数据的两个副本分别写入两个机房各一份同时还有一个仲裁副本放在第三个地点可以是另一个小机房或云端。这样任何一个机房整体断电另一个机房仍然有一份完整的数据副本虚拟机可以在几秒到几分钟内自动在幸存机房启动实现业务双活和数据双活。这里的技术关键是网络要求。两个数据中心之间的链路必须是万兆网络且延迟要稳定在1毫秒以内否则同步写性能会受影响。仲裁链路要求低一些千兆、5毫秒内延迟即可。我们在实际项目中如果客户机房之间是裸光纤直连通常都能满足这个条件。4.2 VS3.0.3存储级快照与磁盘亚健康检测存储快照是VS3.0.3的一个重磅功能。以前的快照是基于虚拟机的依赖于虚拟化层。而存储快照是基于存储卷的直接在aSAN分布式存储层面为虚拟磁盘创建快照。这样做的好处是效率更高、对虚拟机性能影响更小并且可以快速克隆出新的虚拟机。它的原理类似于写时复制Copy-On-Write创建速度极快几乎瞬间完成。需要注意的是第一个快照会占用等同于原磁盘大小的空间用于保护数据后续的增量快照才会根据数据变化量逐渐增大。磁盘亚健康检测这个功能我觉得特别贴心它把运维从“救火”变成了“防火”。硬盘不会突然暴毙在彻底失效前往往会有征兆比如读写速度变慢、IO错误增多、SMART信息报告坏道数增长、寿命预警等。VS3.0.3的aSAN会持续监控所有硬盘的健康状态一旦发现某块盘出现“亚健康”迹象就会提前告警并自动将这块盘上的数据迁移到其他健康磁盘上。等迁移完成这块盘会被标记为故障离线管理员可以从容地安排更换。这极大地避免了因硬盘突然故障导致的数据重建风暴对集群性能的冲击也小得多。5. 实战配置与避坑指南聊了这么多原理最后咱们落地一点说说在实际部署和运维aCloud虚拟存储时有哪些关键配置点和容易踩的坑。这些都是我带着团队在几十个项目里真金白银换来的经验。5.1 硬件规划与配置黄金法则硬件是地基地基打不好软件再牛也白搭。对于aCloud的存储部分硬件规划有几个黄金比例SSD缓存盘容量这是影响性能最关键的因素。我强烈建议SSD总容量至少占到你预估业务数据总量活跃数据的20%以上并且不低于HDD总容量的10%。举个例子如果你计划用6块4TB的HDD做容量层共24TB那么SSD缓存至少配2.4TB。如果预算允许达到15%-20%的HDD容量比例更好。别在这方面省钱否则缓存命中率上不去性能瓶颈立马出现。磁盘组配置一个磁盘组由1块SSD和最多7块HDD组成。这样设计是为了缩小故障域。如果某块SSD故障只需要重建它负责的那几块HDD上的数据而不是整台服务器的所有数据。建议按照1:4到1:6的比例配置性能与容量比较均衡。网络配置存储网络用于节点间数据同步和传输一定要用万兆及以上的网络并且和管理网络、业务网络做物理或逻辑隔离。强烈建议使用双网卡做链路聚合Bond避免单点故障。很多性能问题最后追查下来都是网络带宽不足或抖动太大。5.2 策略调优与日常运维系统装好了策略调优才是发挥性能的关键条带数设置默认条带数是6意味着数据会并发分布在6块硬盘上。这个数不是越大越好它受限于单台主机的数据盘数量。比如你每台主机只有4块数据盘那么条带数最大也只能生效为4。原则是在不超过单台主机数据盘数的前提下可以适当调大条带数来提升大块顺序读写的吞吐量。但对于小块随机IO为主的OLTP数据库默认值通常就够了。重要虚拟机标记一定要用好这个功能对于那些跑核心数据库、ERP的虚拟机在平台里把它标记为“重要虚拟机”。这样在资源紧张时它会优先保障资源在数据重建时它的数据优先级最高而且系统会避免对它进行后台数据平衡防止影响业务性能。监控关键指标日常运维要盯着几个核心指标存储卷整体使用率别超过80%、单盘使用率避免某块盘用到100%、SSD Tier层脏数据Dirty比例如果持续很高说明回写速度跟不上写入速度可能HDD性能或网络有瓶颈、网络带宽使用率和延迟。5.3 常见故障场景与应急思路最后分享几个我们遇到过的典型问题及处理思路场景一业务突然变慢监控显示存储延迟很高。排查思路首先看SSD缓存命中率是否骤降其次检查是否有硬盘进入“亚健康”或“故障”状态触发数据重建然后看网络是否有丢包或带宽打满最后检查是否有后台任务如数据平衡、快照合并在大量占用IO。经验优先启用“磁盘亚健康检测”并设置告警防患于未然。数据平衡任务尽量设置在业务低峰期。场景二单台主机故障后虚拟机HA失败或启动很慢。排查思路检查集群网络心跳是否正常管理网络是否隔离且稳定。确认存储网络是否正常故障主机的数据副本是否能在其他主机上被正常访问。对于两节点集群一台主机故障后另一台主机因为副本不满足“主机互斥”只剩一份数据会进入只读保护模式需要人工介入恢复。经验生产环境强烈建议至少3节点起步4节点以上才能实现主机故障的自动重建。两节点方案仅适用于边缘或测试场景。场景三存储空间即将用尽告警。排查思路检查是否有大量快照未清理快照会占用大量空间。检查是否有被删除的虚拟机磁盘文件未彻底回收孤儿文件。使用存储卷的“容量分析”功能查看是哪个业务或用户占用了大量空间。经验建立存储容量预警机制使用率超过70%就要开始规划扩容。定期清理无效快照和镜像。