1. 存储卷的底层逻辑先搞清楚“卷”到底是什么讲存储卷之前先想一个问题你在虚拟机里看到的C盘、D盘和你在ESXi主机上看到的“datastore1”到底差了多少层答案是差了很多层但很多运维干了几年也没认真琢磨过这件事。实际上虚拟机看到的一块100GB的磁盘可能是ESXi主机上一个叫“VMFS存储卷”的东西里面存放的一个vmdk文件而这个vmdk文件在物理层面可能是从一组RAID磁盘阵列上切出来的LUN也可能是NAS设备通过NFS导出的一份共享目录还有可能是本地SATA盘上的一个大分区。存储卷简单理解就是“存储系统提供给上层使用的一块逻辑空间”。它屏蔽了底层的物理实现——你的物理存储是一块盘、十块盘还是一个分布式集群对上层来说都是一块可以格式化、可以放文件的“空地”。1.1 为什么同一个词在不同场景指的东西完全不同这里特别容易踩坑。大家嘴上都说“存储卷”但在不同产品、不同架构里这个词对应的对象完全不一样在VMware ESXi里存储卷通常指一个VMFS文件系统或NFS挂载点也叫数据存储datastore。在Linux的LVM里存储卷指逻辑卷Logical Volume由卷组Volume Group划分而来。在Docker里存储卷Volume是宿主机上专门为容器持久化数据准备的目录。在云平台上存储卷往往是云硬盘通过块存储服务挂载到云服务器上。这篇文章我们以虚拟化/超融合场景为主来讲因为最近我正好在帮客户梳理VMware存储架构也遇到了“vmware扩展vmfs存储卷”这个高频操作需求干脆就顺着这个话题把存储卷从头捋一遍。2. 最常用的四类存储卷本地盘、SAN卷、NAS卷、虚拟卷做虚拟化的人每天打交道的基本就是这四种存储卷。很多人只知其名不知其所以然我逐个说一下它们的内在工作方式以及各自的适用边界。2.1 本地盘存储卷最直接也最容易“玩脱”本地盘就是把ESXi主机自己物理硬盘刨出一块空间格式化成VMFS文件系统当作数据存储来用。单台主机环境下它很常见十几块盘做个RAID5或者RAID10然后建一个存储卷虚拟机就放上面。本地盘做存储卷最大的优点是性能好、延迟低因为没有网络开销SSD的话哪怕SATA接口也能跑出很好的4K随机读性能。缺点也很明显主机本身就变成了单点。如果这台服务器主板烧了、电源炸了本地盘上的所有虚拟机全部跟着遭殃。我见过不少客户一开始嫌共享存储贵全部用本地盘结果一年之内两次数据丢失。最典型的一次是RAID卡电池坏了写缓存策略失效恰好碰到一次意外断电整个卷的元数据全部损坏VMFS结构都检查不出来。所以本地盘存储卷只建议用于以下场景单机测试环境、边缘节点、开发环境或者配合vSAN这类分布式软件将多台本地盘聚合成一个共享池。2.2 SAN存储卷虚拟化时代的“标准答案”SAN存储区域网络提供了基于块的存储卷常见的协议是FC和iSCSI。ESXi主机通过HBA卡或者软件适配器连接存储阵列由存储侧创建一个LUNLogical Unit Number逻辑单元号主机把它格式化成一个VMFS数据存储。SAN存储卷有几个关键特征值得注意第一个特征是多个主机可以同时访问同一个LUN。这一点是虚拟化集群的基础vMotion跨主机迁移虚拟机的时候源主机和目标主机必须能看到同一份数据。第二个特征是存储阵列本身提供冗余双控制器、多路径、快照、复制能力这些都是存储卷之上的额外保护。第三个特征是性能可以独立扩展加盘、加闪存、增加端口带宽都能直接作用于存储卷。SAN卷适合绝大多数生产环境。不过它的实施和维护有门槛尤其是FC SAN需要规划Zoning和LUN Masking还要理解多路径MPIO如何配置。iSCSI相对简单但性能和可靠性依赖你的网络质量建议要单独设置VLAN或物理隔离网络不要和业务流量混跑。2.3 NAS存储卷灵活性最高的选择NAS存储卷走的是文件协议最主流的是NFS。ESXi原生支持NFS 3和NFS 4.14.1这个版本我在后面会重点说一下。和SAN卷相比NAS卷最大的区别在于存储卷本身是一个文件系统比如NFS导出的共享目录ESXi在上面直接创建一个VMFS或者直接使用文件协议存放虚拟机文件实际上ESXi在NFS上用的还是VMFS文件系统格式化的方式不过ESXi 6.5以后默认是NFS 4.1 完整的VMFS封装。NFS存储卷的好处无需规划LUN、无需考虑多路径IP网络通了就能用。对于分支办公室、中小企业或者跑在通用服务器上的虚拟化集群NFS的性价比很高。NFS的问题也来自它的本质——文件协议需要额外处理锁、缓存一致性。在NFS 3时代并发访问同一个虚拟磁盘时性能下降明显也容易遇到元数据操作延迟。有了VAAIvStorage APIs for Array Integration之后NFS的性能有所改善但要达到块存储的稳定表现还是要看存储阵列本身的执行效率。2.4 vVol虚拟卷存储感知虚拟化的终局形态VMware的Virtual VolumesvVol改变了存储卷和虚拟机的对应关系。传统方式是一个LUN里放很多个vmdk文件存储策略是在LUN层面统一管理的。vVol则把每个虚拟机直接映射到存储阵列上的一个单独卷也就是说虚拟机的每个虚拟磁盘甚至每个快照都是存储阵列上的一个独立对象。这个模式的好处是存储策略复制、快照、加密可以直接按虚拟机级别下发而不影响同一LUN上其他虚拟机。不过vVol必须依赖存储厂商提供的VASA Provider接入也就是说你的存储阵列要原生支持vVol否则玩不起来。目前HPE、NetApp、Pure Storage等主流厂商都支持vVol如果存储侧本身就是全闪阵列vVol能带来非常漂亮的性能压缩和策略管理体验。但如果是老旧的存储阵列不建议强行上vVol兼容性和稳定性风险都比较高。3. VMFS存储卷到底是怎么组织数据的既然题目挂着“vmware扩展vmfs存储卷”VMFS就值得单独拿一章来讲。VMFSVirtual Machine File System是VMware专为虚拟化而生的集群文件系统普通文件系统是为单机优化的但VMFS从出生那刻起就是为多台主机同时读写同一个文件系统而设计的。3.1 VMFS的版本演进选错版本等于埋雷VMFS升级到VMFS 6已经很多年了ESXi 6.5起默认VMFS 6但很多老机器上还有VMFS 5的存储卷。这两者的区别不是版本号好看而已底层变化很大VMFS 5文件块大小为1MB之前可以选2MB/4MB/8MB等而VMFS 6引入了64KB的子块sub-block概念小文件占用的空间明显减少。VMFS 6支持存储卷容量自动扩展自动检测并扩展物理存储对多路径主动优化也更好。VMFS 6对SSD有专门优化支持TRIM和UNMAP指令SSD上的写入和回收性能有显著提升。VMFS 5最大单文件2TB调整过可以更大VMFS 6最大单文件62TB大致大数据量虚拟磁盘没那么容易撞天花板。所以在规划新环境的时候尽量一步到位升级到VMFS 6。旧环境升级要注意VMFS 5可以原地直升VMFS 6这不是破坏性操作存储卷数据和虚拟机文件都保留。但升级前依然要打快照和完整备份毕竟存储操作从来都容不得侥幸。前提是ESXi版本要6.5以上而老版本主机可以访问VMFS 5但访问不了VMFS 6。3.2 VMFS数据存储的核心结构LVM分区体系如果你用lsblk去看ESXi主机的存储设备会发现LUN上会有分析过的“分区”这类分区并不是你定义出来的而是VMFS在初始化的时候自动创建的一套LVMLogical Volume Manager结构。VMFS把物理存储划分成几个主要区域第一个区域是文件系统的基本头信息Super Block、Heartbeat区域等保存着卷的UUID、版本、状态。第二个区域是文件描述符区也就是保存目录结构和文件元数据的地方VMFS里每个文件比如vmdk都会有一个对应的File Descriptor文件描述符。第三个区域是真正的数据区存放虚拟机磁盘数据的文件块。理解这个结构很重要因为以后做存储卷扩容或者遇到存储卷损坏需要手工修复的时候你知道底层是LVM分区体系而不是普通EXT4那种结构处理思路就会明确很多。3.3 VMFS存储卷的上限和块逻辑讲VMFS实现细节之前先给大家一个直观的上限表做容量规划时直接参考参数VMFS 5VMFS 6单卷最大容量64TB64TB实际可达更大单个VMDK最大容量2TB旧版约2TB62TB块大小1MB1MB子块64KB管理小文件每卷最大文件数约130,000约130,000快照支持支持支持更优自动回收有限支持UNMAPVMFS 6的一个单卷最大容量理论值远超64TB但不要指望单个存储卷无限扩充。你还需要考虑文件描述符区的大小和实际文件数量。如果虚拟机的数量很多而且很碎文件描述符区会先耗尽即使卷剩余空间还有很多也会出现“无法创建新文件”的异常。4. 实战vmware扩展vmfs存储卷的完整流程好进入正题。扩展VMFS存储卷简写就是给数据存储扩容。物理层面的操作根据后端存储类型不同会不一样但ESXi层面的逻辑是相通的。4.1 先判断存储卷是否具备扩展条件做任何扩容前先确认这几个条件后端存储是否还有空闲空间可以划给这台主机。新的LUN或扩容后的LUN在ESXi主机上是否已经识别到了新增容量。当前VMFS存储类型是否允许在线扩展。主机层面的存储适配器HBA/网卡是否工作正常。检查命令也简单ESXi主机上跑esxcli storage vmfs extent list也可以直接在vSphere Client里选中目标数据存储查看“操作 - 扩展”按钮是否可用。4.2 后端存储扩容三种底层环境下的差异先说SAN块存储。比如一台HPE存储或者一台DELL存储划的LUN原本是2TB你需要在存储侧把它扩到3TB。这一般需要在存储管理界面操作扩建LUN本身是热操作LUN上的数据不中断但建议操作前后都要确认多路径状态正常。再看NAS存储。NFS存储卷扩容则相对简单在NAS侧把共享目录的配额调大或者直接把导出的NFS filesystem扩容ESXi侧自动发现容量变大即可不需要重新挂载不需要扫描。最后看vSAN场景。vSAN不是传统VMFS卷的概念是通过“vSAN存储策略”来管理容量的。要让存储卷容量变大直接给集群加盘或加主机vSAN会自动将容量更新至存储策略要求的对象上。这个不在VMFS扩展范围之内但容易混淆这里单独说明。4.3 在ESXi侧执行VMFS数据存储扩展后端调整完成后ESXi上的存储卷还是旧容量这时候需要让主机重新扫描存储设备然后执行扩展。操作路径如下第一步在vSphere Client中选择主机点击“存储”选项卡然后选择“重新扫描存储适配器”或者在存储设备上右键选择“重新扫描”。这一步是必须的否则主机会看不到存储侧新增加的容量。第二步选中目标VMFS数据存储点击“操作 - 扩展”。在弹出的界面中你可以选择将存储卷扩到哪一块物理存储设备上。注意这里有一种情况如果存储阵列和之前该LUN是同一个LUN但容量增大了界面会直接显示容量从2TB变成3TB选择此项扩展即可。如果是额外划了一个全新的LUN出来希望把它并入已有数据存储也可以在扩展界面中将它添加为“扩展区”Extent。第三步确认扩展后的容量。扩展操作是秒级的不影响存储卷上的虚拟机运行完全在线操作。不过但凡涉及LUN和文件系统的操作我无论如何都建议提前做一次虚拟机快照或者备份数据无价。4.4 核心命令esxcli下的扩展操作在某些场景下你可能没有图形客户端可访问ESXi Shell或者SSH里的命令同样可以完成扩展思路和图形界面完全一样# 查看数据存储当前extent esxcli storage vmfs extent list # 获取存储设备信息 esxcli storage core device list # 使用一个新LUN或扩展后的LUN来扩展数据存储需要先卸载不需要VMFS原生支持在线扩展 vmkfstools -Z /vmfs/devices/disks/naa.xxxxxxxx /vmfs/volumes/your_datastore_namevmkfstools的-Z参数是“扩展到一个新的extent”。-z参数则是“向当前extent追加容量”。两者的区别很重要-z用于同一个LUN本身容量被扩大后把新增容量追加到当前数据存储。例如原LUN 2TB扩到了3TB就用-z。-Z用于把另一个独立的LUN或分区添加为新的扩展区合并到同一个数据存储。例如新增了一个1TB的LUN希望并到原2TB的卷里就用-Z。我把这两个参数的坑列出来因为这个很容易搞反参数用途典型场景-z扩展当前extentLUN本身从2TB扩容到3TB-Z添加新extent新增一个1TB LUN并入原2TB卷结果-z扩容后单extent 3TB-Z扩容后卷总容量3TB单extent还是2TB新extent 1TB多个extent会导致一个VMFS卷由多个LUN组成这本身没问题但如果其中一个extent损坏整个存储卷的文件系统都会受影响。所以做过-Z扩展的卷一定要慎用“移除extent”操作。移除extent会要求数据全部迁移没有外部迁移工具的时候基本做不到。4.5 VMFS 6的自动扩展与需要手动干预的情况VMFS 6本身支持在物理存储扩容后自动扩展VMFS但只针对“单个LUN自身容量变大”的场景。这类场景在vSphere 6.5之后如果存储卷是在VMFS 6上主机会自动感知到新的容量并完成在线扩展无需手动执行任何操作。但是自动扩展只适用于存储阵列正确报告LUN容量的情况。如果主机有多路径配置异常或者存储阵列缓存刷新延迟也可能遇到扩容后主机仍然只看到旧容量。这种情况下的排查顺序是重置存储适配器重新扫描。检查多路径插件NMP/MPP状态。确认存储阵列中的LUN映射Masking和Zoning没有变化。查看主机系统和VMkernel日志/var/log/vmkernel.log搜索存储卷的容量变化记录。5. 存储卷选型与容量规划实战建议光知道怎么扩展还不够实际项目里如何选择存储卷类型才是真正考验架构能力的地方。我把几种常见场景的选型建议和理由列出来。5.1 小规模场景1~3台宿主主机本地盘外部备份或NFS小规模环境如测试机房、小型工作室虚拟化的一个典型特点是预算有限、没有专职存储管理员、但对业务连续性有一定要求。我的建议是优先考虑NFS存储卷配合一台普通的NAS设备。理由是NFS不需要学习FC组网和LUN Masking只要会配NAS共享目录就能在ESXi上快速挂载。如果你完全不想买NAS纯本地盘也能跑但你要接受重建成本。这种情况下强烈建议开启vSphere Replication把虚拟机复制到另一台服务器或者另一个本地盘组上遇到单机故障至少能缩短恢复时间。本地盘没有冗余、没有备份这是运维大忌讳。踩过坑的人都懂。5.2 中大规模场景4台以上宿主主机FC SAN或iSCSI SAN是底线一旦ESXi主机数量超过4台并且虚拟机数量上到50台以上本地盘的局限性会彻底爆发。这时候共享存储几乎是必须的。预算充足的项目可以选FC SAN光纤通道在延迟和稳定性上表现确实好所有生产环境标准做法都是FC SAN。预算有限的项目建议选iSCSI。不过iSCSI要出效果网络设计必须到位至少使用双千兆生产环境建议双万兆分别接到不同的交换机。iSCSI网络独立VLAN不跑业务流量。开启巨帧MTU 9000之前先确认交换机端口和存储端口都支持否则宁可不做。配置多路径ESXi自带的MCA/固定路径都可以这样可以避免单链路故障导致的IO中断。我最初给一家子公司搭的iSCSI环境用的是普通千兆链路带宽成了瓶颈虚机迁移慢到怀疑人生。后来换成双万兆之后一切顺畅虚拟机存储迁移从原来的几个小时降到十几分钟。5.3 高性能场景数据库、高IO应用全闪阵列vVol或纯NVMe本地盘如果虚拟机里跑的是数据库、ERP、报表分析存储重点考虑随机IOPS和延迟。这时候有两套主流方案方案一是全闪存储阵列vVol。卷策略直接按虚拟机下发快照、克隆、加密都走阵列级功能IO路径最短延迟通常在0.5ms以内。vVol对数据库类虚拟机尤其友好因为每个虚拟机数据卷都是独立的互不干扰。方案二是vSAN全闪配置把每台宿主机的NVMe SSD组建成一个分布式存储池。vSAN在IO路径上需要经过VMkernel的网络栈延迟比纯SAN略高但胜在无硬件阵列的单点故障扩容也容易。具体选哪套取决于你现有硬件生态。已经在用某一厂家的服务器和存储延续同品牌生态在运维成本上会更低。5.4 容量规划时最容易忽略的三个隐藏成本第一快照占用。每做一个虚拟机快照存储卷就会增加一份差异数据。当快照数量较多且时间较长时存储卷容量可能突然被耗尽。所以如果项目里经常打快照预留容量建议在正常使用量的基础上再增加20%-30%。第二性能与容量分开考虑。一个存储卷剩余空间充裕不代表它能扛住高IO压力。有时候VM卡顿不是空间不够而是底层物理盘性能不足。容量规划时一定要同时考虑IOPS而不是只看容量数字。第三文件数量上限。我前面提到过VMFS卷文件描述符区有上限VMFS 6大约每卷130,000个文件。看这个数字觉得很多但单台虚拟机的快照、日志文件、交换文件一多规模大了之后文件数会快速膨胀。如果接近上限存储卷会报告“空间不足”但实际磁盘还有大量剩余空间。6. 存储卷管理避坑指南日常维护与排错实录最后分享一批我实际工作中踩过的坑和对应的排查办法。这部分内容常规文档里不会写但极其影响日常运维幸福感。6.1 存储卷显示“不活动”或“无法访问”有一次客户报障说ESXi主机上的数据存储在界面里变成灰色状态为“不活动”。我第一时间检查存储侧发现存储阵列的控制器已经重启过了但LUN映射列表发生变化。排查步骤先看主机存储适配器状态确认物理链路正常。在存储侧检查LUN是否正常处于映射和屏蔽状态是否意外被取消映射。vCenter里的数据存储右键选择“挂载”或“卸载”后重新挂载。多路径配置出错也会导致类似现象。检查命令esxcli storage nmp path list如果发现所有路径都显示Dead那多半是链路或存储侧屏蔽有问题要逐段排查。6.2 VMFS存储卷扩容后虚拟机无法写入这是一个比较隐蔽的问题。某客户把一个LUN从1TB扩到2TBVMFS卷显示扩容成功但虚拟机写数据到某个vmdk时报“磁盘空间不足”。排查后发现了根因原存储卷中某个vmdk的单文件大小超过了VMFS 5的2TB限制扩容后的总容量是变大了但单个虚拟磁盘文件因为格式限制无法继续增大。解决办法是把虚拟磁盘格式从thin转换为thick或者更推荐直接新建一个更大的VMDK迁走数据后切换。确认现有VMFS版本生产环境尽快规划升级到VMFS 6。6.3 存储卷大量空间被占用但又找不到文件这类问题常出现在频繁使用快照或删除虚拟机后。实际原因通常是vmdk的“虚拟大小”大于“占用大小”删除文件后VMFS不会马上把空间返回给存储卷。VMFS 6可以利用UNMAP回收未使用空间在ESXi主机上执行esxcli storage vmfs unmap -l datastore_name如果是VMFS 5你可能需要先升级到VMFS 6才能享受自动回收功能或者定期执行UNMAP操作。注意UNMAP操作也会占用存储I/O资源建议在业务低谷期执行不要在高峰期频繁触发。6.4 通过命令行快速查看存储卷健康状态日常巡检我建议养成用命令行查看存储卷的习惯速度快、信息全。常用命令总结# 查看所有存储卷基本信息 esxcli storage vmfs list # 查看VMFS卷的extent组成 esxcli storage vmfs extent list # 查看存储设备基本信息NAA标识、容量、状态 esxcli storage core device list # 查看存储卷无用的快照占用 vim-cmd vmsvc/snapshot.getallvms其中esxcli storage core device list的输出里naa开头的设备号就是LUN的唯一标识你在存储侧做LUN映射时一定要确保ESXi看到的NAA和存储侧呈现的一致否则容易映射错设备。6.5 在线扩展时最容易被忽视的“时间窗”风险所有存储卷操作都有一个隐形的安全时间窗——就是你在存储阵列调整容量、但还没让ESXi重新扫描中间的间隔。这个期间虚拟机还在正常读写存储阵列端如果正在执行LUN重建、重映射或者缓存回写可能导致ESXi端I/O挂起。所以规范操作顺序是先暂停业务写入可选、调整存储阵列容量、完成LUN重映射检查、再执行ESXi重新扫描、最后扩展VMFS。如果业务完全不能中断至少也要在变更窗口内操作并且全程盯着vCenter里的任务和告警。实际项目里我还习惯在操作前把ESXi的配置备份一份vim-cmd hostsvc/firmware/sync_config这样即使操作过程中出了意外也可以快速恢复主机配置。7. 一个vSAN扩展存储卷的真实案例复盘分享一个上个月处理的vSAN存储卷容量扩展案例整个过程中踩了一个比较典型的坑复盘出来给大家做参考。客户环境是6节点vSAN集群全部NVMe盘总可用容量大约40TB。某天告警提示存储卷容量超过85%需要扩容。一般的做法是给集群添加新的容量盘即可最简单的操作是将vSAN存储策略的“容错方法”从“RAID-1镜像”改为“RAID-5”或者“RAID-6”来降低冗余开销并释放容量。但客户没有冗余欠账空间因此还是走了加盘路线。新加了两块NVMe盘之后vSAN集群显示系统容量确实增加了但VM存储策略里的“对象空间”仍没有变化甚至有部分对象报“合规性不满足”。排查后才发现新加的盘虽然被vSAN认到了但默认存储策略要求的所有对象仍然放置在没有故障的旧设备上vSAN不会自动重平衡数据。解决方式是手动触发重平衡检查vSAN健康状态确认无异常。在vSAN管理界面中将存储策略临时调整为“允许重平衡”或者手动触发重平衡任务。等待数据迁移完成。这个案例说明存储卷扩容到末端不只是“加设备”那么简单还要了解上层存储策略和对象布局的关联否则存储卷扩展了虚拟机却还是访问不到新空间。如果你是做虚拟化的建议每半年就重新审视一次存储卷的容量、性能、冗余现状不要等到告警再动。存储卷管理从来不是一个静态的规划任务而是一个持续演进的过程。我在最开始入行的时候也犯过低级错误比如直接在存储阵列上删除了一个卷结果发现它还被ESXi主机用着好在当时环境是测试环境。从那以后再也没敢在没确认存储卷关联的情况下动手。做存储操作一句话多看、多查、多想动设备之前把链路、映射、关联关系全确认一遍再下手。