简介面向IBM DS系列存储系统运维与实施人员的参考文档聚焦DS Storage Manager的日常管理与调试。内容围绕Storage Partition与LUN Masking展开说明如何通过存储分区实现主机间LUN隔离避免多主机同时识别同一磁盘造成签名覆盖或数据互写并以Linux与Windows主机共享LUN为例提示隔离的必要性同时比较单主机或集群主机分区与Host Group多主机分配两种方案的适用取舍覆盖在线扩容、新增主机、扩展Storage Partition数量等维护操作。后半部分结合DS4800讲解图形界面建卷、RAID级别选择、条带块与文件系统设置、热备盘配置、HBA卡WWN映射及串口命令行排障思路。压缩包共1个doc文件约1019KB篇幅集中便于随查随用。已有452人学习适合需要理解DS4000/DS4800存储分区、卷映射与容量扩展的读者作为操作参考和排错线索。1. 一条 LUN 被两台主机同时看见为什么两边都不会报错Storage Partition 和 LUN Masking 这两个词在存储管理套件的配置界面里通常挨着放很多人点进去扫一眼就退出去了——不就是给主机分个盘吗。真正的风险在于把同一块 LUN 同时映射给两台主机两边都不会报错。操作系统照常枚举磁盘、照常挂载、照常读写日志一片安静直到某天发现数据被覆盖成了别人的内容或者文件系统直接损坏。这类事故不是“越权访问”造成的恰恰是两次都“合法”的写入——Windows 看到一块新磁盘会习惯性地写入签名Linux 上的卷管理器会自作主张打上自己的元数据头谁也没觉得自己做错。所以 Storage Partition 不是权限面板上的一个装饰开关它是把“物理上看得见”和“逻辑上可以用”这两件事切开的那道闸。搞懂这道闸卡在哪一层、为什么只能卡在那一层才谈得上会管一台中端阵列。2. LUN Masking 与 Zoning两道闸门分别卡在哪一层很多人对隔离的理解停在“划个 zone 就完事了”这在只连一台主机的时候完全没有问题一旦上了双机、多机就必然出问题。原因不复杂Zoning 和 Storage Partition 作用在协议栈的两个完全不同的高度上一个管链路能不能通一个管命令报不报得出来。把它们混为一谈等于把防火墙当成了文件权限。2.1 Zoning 卡在光纤交换层解决“能不能看见这台阵列”主机接进 SAN 之后第一步是向交换机端口发 FLOGI 完成 fabric 登录拿到一个 FC ID然后才能对目标端口发 PLOGI、PRLI建立真正的 SCSI 会话。Zoning 做的事就是在这条路上设卡只有处在同一个 zone 里的端口或 WWN彼此之间的登录帧才被交换机转发不在同一个 zone 里则连 PLOGI 都完不成后面的 SCSI 命令自然无从谈起。这个粒度的关键特征是——Zoning 的判定对象是“设备/端口”不是“LUN”。只要主机和阵列的某个 target 端口在同一个 zone 内登录成功之后主机就能对这个 target 发REPORT LUNs而交换机不会、也没能力去检查返回的 LUN 列表里是不是混进了别人的盘。换句话说Zoning 最多告诉你“这栋楼你能进”进了楼之后哪几个房间能开它管不着。这也解释了为什么只做 Zoning 的多主机环境经常出现“我明明只 zone 了 A 主机和阵列怎么 A 还看到了 B 的盘”——因为你看的是 LUN而 zone 看的是端口。2.2 Storage Partition 卡在控制器层解决“能看见这台阵列的哪些 LUN”真正的 LUN 级判定发生在阵列控制器内部。主机登录成功后SCSI 层第一步是发REPORT LUNs问“你身上挂了哪些逻辑单元”控制器这时才拿到主机的身份标识在 FC 环境下就是 HBA 的 WWN去查自己维护的映射表只把登记在这个 WWN 名下的 LUN 返回来。没登记的 LUN 不会出现在返回结果里主机侧的 SCSI 中层根本不知道它们存在/dev/sd*也就不会多出对应的块设备。常见的实现思路大致是这样一张表以主机 WWN 为键以“可见 LUN 编号 → 后端卷”为值Default Group 作为兜底策略处理未登记的主机。控制器在每次REPORT LUNs、INQUIRY、TEST UNIT READY时都过一遍这张表属于典型的白名单模型——默认拒绝登记才放行。# 控制器侧 LUN 可见性判定的示意结构用于说明白名单模型非厂商实现 # mapping: {host_wwn: {lun_id: volume_id}}由 Storage Partition 配置生成 def report_luns(host_wwn, mapping, default_group_policy): # WWN 必须先做归一化大小写、冒号分隔、前导零都会影响匹配 key normalize_wwn(host_wwn) visible mapping.get(key) if visible is None: # 未登记主机走 Default Group 策略这也是没买 License 时的唯一归宿 return default_group_policy() # 只返回该 WWN 名下登记过的 LUN 编号其余卷在主机侧完全不可见 return sorted(visible.keys()) def normalize_wwn(wwn): # 统一成小写、去掉分隔符50:0a:09:80:00:1a:2b:3c - 500a0980001a2b3c return wwn.replace(:, ).replace(-, ).lower()这段伪代码里有两个值得注意的点。第一是归一化看起来是琐碎细节实际是现场最高频的翻车点之一交换机上抄下来的 WWN 带冒号、全小写管理界面里粘贴进去的可能带大写或者少一位前导零配置上“看着有”映射就是不生效。第二是兜底分支Default Group 的存在意味着只要有一台主机没被划进任何 Partition它就会落到默认策略里而这个策略通常是“看得见所有没被别的 Partition 独占的卷”——这就是隔离形同虚设的根源。2.3 两个机制的组合关系缺一不可但不能互相替代把两道闸门放在一起看职责边界就清楚了。Zoning 决定“哪些主机能跟这台阵列建立 SCSI 会话”Storage Partition 决定“会话建立之后能看到哪些 LUN”。前者在交换机上配后者在阵列控制器上配配置位置不同、生效层不同、故障表现也不同Zoning 配错的表现是链路起不来、lsscsi里连阵列的 target 都看不到Partition 配错的表现是链路正常、能看到阵列但 LUN 数量对不上或者多出了不该有的盘。维度Zoning光纤交换机Storage Partition阵列控制器判定对象端口 / WWN主机 WWN 对应的 LUN 列表协议层FC 登录FLOGI/PLOGISCSI 命令REPORT LUNs隔离粒度设备级LUN 级配错后的现象看不到阵列 target看得到阵列LUN 数量异常典型误用所有端口划进一个大 zone全部卷映射给 Default Group注意Zoning 做得再细也不能替代 Storage Partition。一个主机在 zone 内、所有卷都在 Default Group 里的环境隔离度等于零。3. Storage Partition 的两种划法Host Group 里放一台还是放多台知道了闸门卡在哪一层接下来的问题就是这张白名单表怎么组织。DS 系列的管理套件给了两种划法表面看只是“主机放一组还是分开”实际是两种完全不同的运维模型选错了不会立刻出事但会在扩容和加节点的时候一点一点把运维成本还回来。3.1 方案一一个 Host Group 放一台或一对集群主机这个方案的规则很干脆一个 Host Group 里放一台主机或者放两台装了集群软件、需要共享同一批逻辑盘的主机共享盘分配给 Host Group各自独占的盘分配给具体 Host。判定顺序是“先看 Host 自己的映射再看所属 Group 的映射”所以同一台主机既能拿到组内共享的卷也能拿到自己独占的卷。它的价值在双机场景里体现得最明显。举个例子两台小型机做 HA 集群共享数据盘两边都要看见各自的系统盘只想让自己看见。用方案一共享盘挂到 Host Group 上系统盘分别挂到两个 Host 上一张映射表就表达完了既不会让 A 看见 B 的系统盘也不会影响两边对共享盘的并发访问。扩容时也一样新加一块共享盘挂到 Group 上两台同时可见新加一块只给 A 的盘挂到 A 的 Host 上B 完全无感。逻辑层次跟实际的业务拓扑是同构的后面接手的人看一眼分组名就知道怎么回事。代价是 License 消耗。每个 Storage Partition 对应一份授权方案一是“每台主机或每对集群主机一份”主机数量一多账面上的授权数就上去了。3.2 方案二一个 Host Group 放多台主机逻辑盘直接给 Host省授权的方式是把多台主机塞进同一个 Host Group然后把逻辑盘直接分配给每个 Host不经过 Group 这一层。因为授权是按 Partition 算的一个 Partition 里放十台主机也只算一份。代价是表达能力。这个模型里只有“Host 独占”这一种关系没办法表达“这两台共享、那三台独占”的混合需求。如果一组主机里有两台需要共享同一块盘在方案二下把这块盘同时映射给两台 Host从阵列角度看确实两边都能看见但这已经越过了 Host Group 的语义边界后面排查“这块盘到底该归谁”的时候会很痛苦。所以这个方案通常用在纯独占的小规模环境一批互不相干的业务主机各自一块或几块盘没有任何共享需求。3.3 License 与运维成本的取舍为什么建议下单时就买一个常见的后悔药场景是装机时没订 Storage Partition 授权所有主机只能落在 Default Group 里于是每台主机都能看到阵列上所有卷。这时候业务还没上线看起来“也没出什么事”等到一台 Windows 主机扫盘时把别人的 LUN 写了签名或者两台主机同时挂了一块盘互相覆盖问题才暴露出来而这时候再补授权、再重新规划分组是要停业务窗口的。选型的判断标准其实很朴素如果环境里有集群、有共享盘、或者主机数量会增长就走方案一并且在下单阶段把授权数量按“主机数或集群对数”估足如果是一批完全独立、永远不共享的单机业务方案二可以省一笔但要接受未来加共享需求时得重新规划。这里没有普适答案只有“你的拓扑会不会变”这个问题的答案。3.4 集群协调软件两个节点都能写同一块盘之后即使 Storage Partition 把共享盘正确地映射给了两台主机也只是解决了“谁能看见”没有解决“谁能写”。两台主机同时往同一个块设备写如果没有上层协调结果依然是数据互相覆盖。所以共享卷必须搭配协调机制常见的有三类HA 集群软件用心跳和资源组做互斥同一时刻只有一个节点挂载并写入并行文件系统用分布式锁管理并发访问让多节点真正同时读写同一个文件系统SAN 共享文件系统则用令牌机制协调多台主机对同一批卷的访问。裸设备场景下还有并发卷的概念允许多节点同时打开同一块设备由数据库自己的锁机制接管一致性。注意映射给 Host Group 的共享卷如果上层没有集群或并行文件系统等于把两块主机的手同时伸进同一个抽屉隔离做得再好也没用。4. 一条 LUN 从创建到映射图形界面背后的参数与顺序图形界面把创建流程串成了一条向导点下一步就行但每一步背后的选择都会在后期变成性能问题或者容量问题。把向导拆开看实际是四件事先在物理盘上切出 RAID 组再在组里切出逻辑盘并定条带参数然后留出热备盘兜底最后通过 WWN 把逻辑盘映射给主机。顺序不能乱参数要想清楚。4.1 磁盘组、RAID 与逻辑盘的创建顺序向导的第一步是Create Logical Drive选 RAID 级别然后决定怎么选盘全自动让控制器自己挑或者切成手工模式逐块勾选。后者在已有数据的阵列上几乎是必须的——自动选盘不会管你哪些盘已经被别的卷占着、哪些盘属于哪个磁盘组一通自动下去可能把容量切得七零八落。选完盘要点一次Calculate Capacity不点这一步向导不会放行因为控制器需要先算出这组盘在当前 RAID 级别下实际可用的容量再让你决定切多大的逻辑分区。分区大小和命名之后向导会问是自动设置属性还是手工设置建议选手工自动方案是给“不知道自己要什么”的人准备的而条带大小、文件系统类型这些参数一旦定错改起来往往要重建卷。最后一步是选该分区将要挂载的操作系统类型这个选择会影响控制器对该卷的呈现方式选错的表现不一定是报错有时候只是主机侧认出来的设备属性不对。4.2 条带块大小8K 到 256K 对应的是什么 IO 模型条带深度stripe unit从 8K 到 256K 有多档可选选型的依据只有一个这块卷上跑的应用IO 长什么样。数据库类负载是典型的小块随机 IO一次写 7K、8K 很常见。如果条带设成 256K一次 7K 的写落在了一个 256K 的条带单元里这个单元剩余的空间在这次 IO 中就用不上了等于用大颗粒去装小数据空间利用率和控制器处理效率都不划算。反过来多媒体、备份归档这类顺序大 IO 负载一次读 200MB 的电影文件条带设大一些控制器跨盘轮询的次数就少预读和并行度都能吃满效率明显更高。文件系统类型的选择同理向导里让选“数据库 / 多媒体 / 文件系统”本质就是在替你预设这一组条带参数。这里有个容易误解的点条带大小不是“块大小”它不影响单个文件占多少空间影响的是控制器把一个 IO 拆成几份、落到几块盘上。所以判断标准不是“我的文件平均多大”而是“我的 IO 请求平均多大、是顺序还是随机”。4.3 热备盘容量为什么必须不小于阵列内最大的一块盘RAID 组做完之后要留热备盘Hot Spare作用是阵列里某块盘故障时控制器自动拿热备盘顶上并开始重建把降级窗口压到最短。这里有一条硬性限制热备盘的容量必须大于或等于它所保护的那个阵列里容量最大的盘。原因很直白重建是把故障盘上的数据按条带重新算一遍写到热备盘上如果热备盘比故障盘小物理上就装不下重建根本没法开始阵列会一直停在降级状态。更隐蔽的情况是热备盘容量够大但被划给了别的磁盘组、或者被指定成了只保护某个特定阵列的专用热备这时候别的组出故障它不会被自动征用。所以配完热备盘之后务必要确认它的保护范围覆盖了所有需要兜底的磁盘组。4.4 Mapping ViewWWN 才是主机的身份证卷建好了最后一步是映射。管理套件里的Mapping View是整条链路的收口处也是最容易配错的地方。规范的做法是先在Mapping View里建 Host Group比如按业务命名成Oracle_data这样的组再在组里建 Host然后给每个 Host 添加 HBA 卡的 WWN。一台主机有几块 HBA、几个端口就要加几次因为阵列认的是端口身份不是主机名。加完 Host 之后分配逻辑盘。这一步的界面支持两种操作把多块盘分给同一台主机或者把同一块盘分给多台主机后者就是共享场景需要上层集群软件配合。最后的收尾动作是在Default Group上右键选Define Additional Mapping补齐映射关系。这一步很容易被跳过跳过的后果是前面配的分组没真正生效主机侧扫出来还是老样子。主机侧可以用几条命令确认映射是否真的落地了# 1. 采集 HBA 端口 WWN用于在 Mapping View 里登记主机身份 # 输出形如 0x500a0980001a2b3c粘贴进管理界面时注意去掉 0x 前缀 cat /sys/class/fc_host/host*/port_name # 2. 触发 SCSI 总线重扫让新映射的 LUN 出现在系统里 # 三个 - 分别代表 channel / target / lun全通配表示扫全部 for h in /sys/class/scsi_host/host*/scan; do echo - - - $h; done # 3. 确认多路径下每块 LUN 的可见性与聚合情况 # 同一 LUN 的多条路径应聚合成一个 mpath 设备而不是散成多个 sdX multipath -ll # 4. 查看 SCSI 层实际枚举到的设备核对数量是否与映射一致 lsscsi -gmultipath -ll的输出值得多看两眼如果同一块 LUN 出现了多个独立的设备节点而不是聚合成一个说明多路径配置有问题如果设备数量比映射的多说明有卷落进了 Default Group隔离没做干净。Windows 主机侧还有一层额外风险需要提前处理。Windows 默认策略会对新发现的磁盘自动上线并写入签名这正是跨主机数据损坏的经典成因。可以在映射之前先把策略改成离线# 将新发现的磁盘一律置为 Offline避免主机对不属于自己的 LUN 写入签名 Set-StorageSetting -NewDiskPolicy OfflineAll # 确认当前策略已生效 Get-StorageSetting | Select-Object NewDiskPolicy这条策略配合 Storage Partition 使用才是完整的Partition 保证主机看不到别人的盘离线策略保证即使因为某种原因看到了也不会主动去写。5. 在线扩容与常见问题排查改分区为什么不用停业务存储管理里最容易被低估的能力是“在线改”。扩容、加主机、加 Partition这些操作在 DS 系列上都是在线进行的不影响正在跑的业务。理解了这个“在线”是怎么来的遇到问题才知道从哪儿查。5.1 三条扩容路径与“在线”的来源第一条路径是动态卷扩容直接把已有 LUN 调大主机侧重扫之后看到块设备变大了再扩分区和文件系统。第二条路径是新增 LUN 然后修改该主机的 Storage Partition把新卷加进去——注意这里改的是映射表不是已有卷的属性。第三条路径是升级 Storage Partition 的数量授权让原本挤在 Default Group 里的主机能各自独立成组。三条路径的在线性来自同一个设计映射表的变更是“新增条目”或“追加 LUN 编号”不触碰已经生效的条目。已经在跑的 IO 走的还是原来那条路径新加的 LUN 对老会话不可见要靠主机侧重扫或者重新登录才会出现。所以“在线”不等于“自动生效”阵列侧改完了主机侧还得主动去发现一次。主机数量增加时同理新定义一个 Storage Partition 不会影响已定义的任何 Partition。注意在线扩容的前提是文件系统和卷管理器支持在线扩容。块设备变大了df不一定跟着变中间那层分区表和文件系统要单独扩。5.2 常见问题与排查现象一主机重扫之后看不到新映射的 LUN。原因通常是三选一WWN 填错了大小写、冒号、前导零的差异都算错卷映射到了别的 Host 或 Host Group 上或者主机没有重新对 fabric 做一次登录所以控制器那边还是旧会话。排查顺序是先在Mapping View里核对这台主机名下的 LUN 清单再回主机侧用cat /sys/class/fc_host/host*/port_name拿到真实 WWN 逐字符比对最后确认扫描命令确实写进了scan文件而不是只 echo 到了终端。现象二Windows 主机扫到了一块不属于它的盘并且自动写了签名。原因是这台主机没有被划进独立的 Storage Partition落到了 Default Group 里而 Default Group 的策略通常是可见所有未被独占的卷。解决分两步先按 3.1 的方案给这台主机单独建 Host 并补齐映射把它从 Default Group 里摘出来再在主机侧把NewDiskPolicy改成OfflineAll让自动签名这件事从源头上不可能发生。已经写坏签名的 LUN只能从备份恢复或者重建没有别的办法。现象三热备盘在阵列里显示正常故障发生时却没有自动顶上。原因包括热备盘容量小于故障盘、热备盘被指定成了只保护另一个磁盘组的专用热备、或者这个磁盘组压根没被纳入保护范围。解决方式是在热备盘的属性里确认它的保护范围覆盖了需要兜底的组并核对容量重建没起来的时候先看阵列的事件日志里有没有“insufficient capacity”之类的提示比盲目换盘高效得多。现象四LUN 扩容完成、主机也重扫了文件系统容量没变。原因是块设备变大只发生在 SCSI 层上面的分区表和文件系统还是旧尺寸。解决是依次扩分区growpart之类、扩物理卷、扩逻辑卷、扩文件系统每一步都要确认前一步到位了再走下一步。跳过中间任何一步最后df都不会变。现象五一块 LUN 在多路径环境里散成了多个独立设备。原因通常是多路径软件没识别到这块盘设备白名单没加或者同一块 LUN 通过多条路径被当成了不同设备。解决是先看multipath -ll里有没有对应的 mpath 条目没有就把该设备加进多路径配置并重新加载而不是急着在裸设备上直接建文件系统——那样做等于把一条路的数据和另一条路的数据割裂开。6. 串口命令行与图形界面什么时候必须离开鼠标图形界面和串口命令行不是“好用”和“难用”的关系是两种失效模式下的互补。管理套件的图形界面承担的是“建模”职责磁盘组、逻辑盘、Host Group、映射关系这些结构性配置在界面上有可视化呈现配错的时候能一眼看出拓扑不对这对防止误操作的价值远大于敲命令快那么几秒。现场绝大多数日常操作包括建卷、扩容、加主机、改映射走图形界面都更稳。串口那条路的价值在另一个场景管理网口不通、控制器状态异常、图形界面连不上的时候。这时候以太网管理通道默认地址段那种带外管理口可能整条断掉图形界面的自动扫描在网络上找不到任何控制器但通过串口登进去用终端工具以命令行方式仍然能拿到控制器的内部状态、看事件日志、做故障定位。它还能做到界面上没有的一些扩展查询信息密度更高代价是没有图形提示任何一条命令敲下去都没有“下一步”按钮帮你兜底。两条路的实际分工我一般这么理解图形界面用来“把结构搭对”串口用来“在结构出问题的时候还能进去看”。这带来一个容易被忽略的运维要求——串口连接方式、终端参数、登录方式这些信息必须在设备上架阶段就记录进运维文档而不是等出故障那天再去翻手册。真到了管理网不通的深夜能不能连上串口决定的不是效率是能不能在业务恢复窗口内定位到问题。这里还有个取舍值得说清楚图形界面之所以“更直观、更容易掌握”本质是它把一堆有依赖关系的操作编排成了强制顺序你不能在没选 RAID 级别的情况下直接去切分区也不能在没加 WWN 的情况下完成映射。这种强制顺序既是保护也是限制——它挡住了误操作也挡住了“我只想查一个状态”的轻量操作。串口命令行反过来什么都能干什么都得自己保证顺序对。两边都吃过亏之后我形成了一个习惯任何一次涉及映射关系的变更先在图形界面里把拓扑配好并截图存档变更完成后立刻用主机侧的扫描命令验证一遍 LUN 数量和设备名两步都过了才算这次变更结束。这个习惯救过我很多次——有几次就是靠变更前后的设备清单对比发现某台主机的卷落进了 Default Group在业务感知到之前就纠正了。希望帮到你。本文还有配套的精品资源点击获取 Storage Partition与LUN Masking：SAN隔离映射实践
简介面向IBM DS系列存储系统运维与实施人员的参考文档聚焦DS Storage Manager的日常管理与调试。内容围绕Storage Partition与LUN Masking展开说明如何通过存储分区实现主机间LUN隔离避免多主机同时识别同一磁盘造成签名覆盖或数据互写并以Linux与Windows主机共享LUN为例提示隔离的必要性同时比较单主机或集群主机分区与Host Group多主机分配两种方案的适用取舍覆盖在线扩容、新增主机、扩展Storage Partition数量等维护操作。后半部分结合DS4800讲解图形界面建卷、RAID级别选择、条带块与文件系统设置、热备盘配置、HBA卡WWN映射及串口命令行排障思路。压缩包共1个doc文件约1019KB篇幅集中便于随查随用。已有452人学习适合需要理解DS4000/DS4800存储分区、卷映射与容量扩展的读者作为操作参考和排错线索。1. 一条 LUN 被两台主机同时看见为什么两边都不会报错Storage Partition 和 LUN Masking 这两个词在存储管理套件的配置界面里通常挨着放很多人点进去扫一眼就退出去了——不就是给主机分个盘吗。真正的风险在于把同一块 LUN 同时映射给两台主机两边都不会报错。操作系统照常枚举磁盘、照常挂载、照常读写日志一片安静直到某天发现数据被覆盖成了别人的内容或者文件系统直接损坏。这类事故不是“越权访问”造成的恰恰是两次都“合法”的写入——Windows 看到一块新磁盘会习惯性地写入签名Linux 上的卷管理器会自作主张打上自己的元数据头谁也没觉得自己做错。所以 Storage Partition 不是权限面板上的一个装饰开关它是把“物理上看得见”和“逻辑上可以用”这两件事切开的那道闸。搞懂这道闸卡在哪一层、为什么只能卡在那一层才谈得上会管一台中端阵列。2. LUN Masking 与 Zoning两道闸门分别卡在哪一层很多人对隔离的理解停在“划个 zone 就完事了”这在只连一台主机的时候完全没有问题一旦上了双机、多机就必然出问题。原因不复杂Zoning 和 Storage Partition 作用在协议栈的两个完全不同的高度上一个管链路能不能通一个管命令报不报得出来。把它们混为一谈等于把防火墙当成了文件权限。2.1 Zoning 卡在光纤交换层解决“能不能看见这台阵列”主机接进 SAN 之后第一步是向交换机端口发 FLOGI 完成 fabric 登录拿到一个 FC ID然后才能对目标端口发 PLOGI、PRLI建立真正的 SCSI 会话。Zoning 做的事就是在这条路上设卡只有处在同一个 zone 里的端口或 WWN彼此之间的登录帧才被交换机转发不在同一个 zone 里则连 PLOGI 都完不成后面的 SCSI 命令自然无从谈起。这个粒度的关键特征是——Zoning 的判定对象是“设备/端口”不是“LUN”。只要主机和阵列的某个 target 端口在同一个 zone 内登录成功之后主机就能对这个 target 发REPORT LUNs而交换机不会、也没能力去检查返回的 LUN 列表里是不是混进了别人的盘。换句话说Zoning 最多告诉你“这栋楼你能进”进了楼之后哪几个房间能开它管不着。这也解释了为什么只做 Zoning 的多主机环境经常出现“我明明只 zone 了 A 主机和阵列怎么 A 还看到了 B 的盘”——因为你看的是 LUN而 zone 看的是端口。2.2 Storage Partition 卡在控制器层解决“能看见这台阵列的哪些 LUN”真正的 LUN 级判定发生在阵列控制器内部。主机登录成功后SCSI 层第一步是发REPORT LUNs问“你身上挂了哪些逻辑单元”控制器这时才拿到主机的身份标识在 FC 环境下就是 HBA 的 WWN去查自己维护的映射表只把登记在这个 WWN 名下的 LUN 返回来。没登记的 LUN 不会出现在返回结果里主机侧的 SCSI 中层根本不知道它们存在/dev/sd*也就不会多出对应的块设备。常见的实现思路大致是这样一张表以主机 WWN 为键以“可见 LUN 编号 → 后端卷”为值Default Group 作为兜底策略处理未登记的主机。控制器在每次REPORT LUNs、INQUIRY、TEST UNIT READY时都过一遍这张表属于典型的白名单模型——默认拒绝登记才放行。# 控制器侧 LUN 可见性判定的示意结构用于说明白名单模型非厂商实现 # mapping: {host_wwn: {lun_id: volume_id}}由 Storage Partition 配置生成 def report_luns(host_wwn, mapping, default_group_policy): # WWN 必须先做归一化大小写、冒号分隔、前导零都会影响匹配 key normalize_wwn(host_wwn) visible mapping.get(key) if visible is None: # 未登记主机走 Default Group 策略这也是没买 License 时的唯一归宿 return default_group_policy() # 只返回该 WWN 名下登记过的 LUN 编号其余卷在主机侧完全不可见 return sorted(visible.keys()) def normalize_wwn(wwn): # 统一成小写、去掉分隔符50:0a:09:80:00:1a:2b:3c - 500a0980001a2b3c return wwn.replace(:, ).replace(-, ).lower()这段伪代码里有两个值得注意的点。第一是归一化看起来是琐碎细节实际是现场最高频的翻车点之一交换机上抄下来的 WWN 带冒号、全小写管理界面里粘贴进去的可能带大写或者少一位前导零配置上“看着有”映射就是不生效。第二是兜底分支Default Group 的存在意味着只要有一台主机没被划进任何 Partition它就会落到默认策略里而这个策略通常是“看得见所有没被别的 Partition 独占的卷”——这就是隔离形同虚设的根源。2.3 两个机制的组合关系缺一不可但不能互相替代把两道闸门放在一起看职责边界就清楚了。Zoning 决定“哪些主机能跟这台阵列建立 SCSI 会话”Storage Partition 决定“会话建立之后能看到哪些 LUN”。前者在交换机上配后者在阵列控制器上配配置位置不同、生效层不同、故障表现也不同Zoning 配错的表现是链路起不来、lsscsi里连阵列的 target 都看不到Partition 配错的表现是链路正常、能看到阵列但 LUN 数量对不上或者多出了不该有的盘。维度Zoning光纤交换机Storage Partition阵列控制器判定对象端口 / WWN主机 WWN 对应的 LUN 列表协议层FC 登录FLOGI/PLOGISCSI 命令REPORT LUNs隔离粒度设备级LUN 级配错后的现象看不到阵列 target看得到阵列LUN 数量异常典型误用所有端口划进一个大 zone全部卷映射给 Default Group注意Zoning 做得再细也不能替代 Storage Partition。一个主机在 zone 内、所有卷都在 Default Group 里的环境隔离度等于零。3. Storage Partition 的两种划法Host Group 里放一台还是放多台知道了闸门卡在哪一层接下来的问题就是这张白名单表怎么组织。DS 系列的管理套件给了两种划法表面看只是“主机放一组还是分开”实际是两种完全不同的运维模型选错了不会立刻出事但会在扩容和加节点的时候一点一点把运维成本还回来。3.1 方案一一个 Host Group 放一台或一对集群主机这个方案的规则很干脆一个 Host Group 里放一台主机或者放两台装了集群软件、需要共享同一批逻辑盘的主机共享盘分配给 Host Group各自独占的盘分配给具体 Host。判定顺序是“先看 Host 自己的映射再看所属 Group 的映射”所以同一台主机既能拿到组内共享的卷也能拿到自己独占的卷。它的价值在双机场景里体现得最明显。举个例子两台小型机做 HA 集群共享数据盘两边都要看见各自的系统盘只想让自己看见。用方案一共享盘挂到 Host Group 上系统盘分别挂到两个 Host 上一张映射表就表达完了既不会让 A 看见 B 的系统盘也不会影响两边对共享盘的并发访问。扩容时也一样新加一块共享盘挂到 Group 上两台同时可见新加一块只给 A 的盘挂到 A 的 Host 上B 完全无感。逻辑层次跟实际的业务拓扑是同构的后面接手的人看一眼分组名就知道怎么回事。代价是 License 消耗。每个 Storage Partition 对应一份授权方案一是“每台主机或每对集群主机一份”主机数量一多账面上的授权数就上去了。3.2 方案二一个 Host Group 放多台主机逻辑盘直接给 Host省授权的方式是把多台主机塞进同一个 Host Group然后把逻辑盘直接分配给每个 Host不经过 Group 这一层。因为授权是按 Partition 算的一个 Partition 里放十台主机也只算一份。代价是表达能力。这个模型里只有“Host 独占”这一种关系没办法表达“这两台共享、那三台独占”的混合需求。如果一组主机里有两台需要共享同一块盘在方案二下把这块盘同时映射给两台 Host从阵列角度看确实两边都能看见但这已经越过了 Host Group 的语义边界后面排查“这块盘到底该归谁”的时候会很痛苦。所以这个方案通常用在纯独占的小规模环境一批互不相干的业务主机各自一块或几块盘没有任何共享需求。3.3 License 与运维成本的取舍为什么建议下单时就买一个常见的后悔药场景是装机时没订 Storage Partition 授权所有主机只能落在 Default Group 里于是每台主机都能看到阵列上所有卷。这时候业务还没上线看起来“也没出什么事”等到一台 Windows 主机扫盘时把别人的 LUN 写了签名或者两台主机同时挂了一块盘互相覆盖问题才暴露出来而这时候再补授权、再重新规划分组是要停业务窗口的。选型的判断标准其实很朴素如果环境里有集群、有共享盘、或者主机数量会增长就走方案一并且在下单阶段把授权数量按“主机数或集群对数”估足如果是一批完全独立、永远不共享的单机业务方案二可以省一笔但要接受未来加共享需求时得重新规划。这里没有普适答案只有“你的拓扑会不会变”这个问题的答案。3.4 集群协调软件两个节点都能写同一块盘之后即使 Storage Partition 把共享盘正确地映射给了两台主机也只是解决了“谁能看见”没有解决“谁能写”。两台主机同时往同一个块设备写如果没有上层协调结果依然是数据互相覆盖。所以共享卷必须搭配协调机制常见的有三类HA 集群软件用心跳和资源组做互斥同一时刻只有一个节点挂载并写入并行文件系统用分布式锁管理并发访问让多节点真正同时读写同一个文件系统SAN 共享文件系统则用令牌机制协调多台主机对同一批卷的访问。裸设备场景下还有并发卷的概念允许多节点同时打开同一块设备由数据库自己的锁机制接管一致性。注意映射给 Host Group 的共享卷如果上层没有集群或并行文件系统等于把两块主机的手同时伸进同一个抽屉隔离做得再好也没用。4. 一条 LUN 从创建到映射图形界面背后的参数与顺序图形界面把创建流程串成了一条向导点下一步就行但每一步背后的选择都会在后期变成性能问题或者容量问题。把向导拆开看实际是四件事先在物理盘上切出 RAID 组再在组里切出逻辑盘并定条带参数然后留出热备盘兜底最后通过 WWN 把逻辑盘映射给主机。顺序不能乱参数要想清楚。4.1 磁盘组、RAID 与逻辑盘的创建顺序向导的第一步是Create Logical Drive选 RAID 级别然后决定怎么选盘全自动让控制器自己挑或者切成手工模式逐块勾选。后者在已有数据的阵列上几乎是必须的——自动选盘不会管你哪些盘已经被别的卷占着、哪些盘属于哪个磁盘组一通自动下去可能把容量切得七零八落。选完盘要点一次Calculate Capacity不点这一步向导不会放行因为控制器需要先算出这组盘在当前 RAID 级别下实际可用的容量再让你决定切多大的逻辑分区。分区大小和命名之后向导会问是自动设置属性还是手工设置建议选手工自动方案是给“不知道自己要什么”的人准备的而条带大小、文件系统类型这些参数一旦定错改起来往往要重建卷。最后一步是选该分区将要挂载的操作系统类型这个选择会影响控制器对该卷的呈现方式选错的表现不一定是报错有时候只是主机侧认出来的设备属性不对。4.2 条带块大小8K 到 256K 对应的是什么 IO 模型条带深度stripe unit从 8K 到 256K 有多档可选选型的依据只有一个这块卷上跑的应用IO 长什么样。数据库类负载是典型的小块随机 IO一次写 7K、8K 很常见。如果条带设成 256K一次 7K 的写落在了一个 256K 的条带单元里这个单元剩余的空间在这次 IO 中就用不上了等于用大颗粒去装小数据空间利用率和控制器处理效率都不划算。反过来多媒体、备份归档这类顺序大 IO 负载一次读 200MB 的电影文件条带设大一些控制器跨盘轮询的次数就少预读和并行度都能吃满效率明显更高。文件系统类型的选择同理向导里让选“数据库 / 多媒体 / 文件系统”本质就是在替你预设这一组条带参数。这里有个容易误解的点条带大小不是“块大小”它不影响单个文件占多少空间影响的是控制器把一个 IO 拆成几份、落到几块盘上。所以判断标准不是“我的文件平均多大”而是“我的 IO 请求平均多大、是顺序还是随机”。4.3 热备盘容量为什么必须不小于阵列内最大的一块盘RAID 组做完之后要留热备盘Hot Spare作用是阵列里某块盘故障时控制器自动拿热备盘顶上并开始重建把降级窗口压到最短。这里有一条硬性限制热备盘的容量必须大于或等于它所保护的那个阵列里容量最大的盘。原因很直白重建是把故障盘上的数据按条带重新算一遍写到热备盘上如果热备盘比故障盘小物理上就装不下重建根本没法开始阵列会一直停在降级状态。更隐蔽的情况是热备盘容量够大但被划给了别的磁盘组、或者被指定成了只保护某个特定阵列的专用热备这时候别的组出故障它不会被自动征用。所以配完热备盘之后务必要确认它的保护范围覆盖了所有需要兜底的磁盘组。4.4 Mapping ViewWWN 才是主机的身份证卷建好了最后一步是映射。管理套件里的Mapping View是整条链路的收口处也是最容易配错的地方。规范的做法是先在Mapping View里建 Host Group比如按业务命名成Oracle_data这样的组再在组里建 Host然后给每个 Host 添加 HBA 卡的 WWN。一台主机有几块 HBA、几个端口就要加几次因为阵列认的是端口身份不是主机名。加完 Host 之后分配逻辑盘。这一步的界面支持两种操作把多块盘分给同一台主机或者把同一块盘分给多台主机后者就是共享场景需要上层集群软件配合。最后的收尾动作是在Default Group上右键选Define Additional Mapping补齐映射关系。这一步很容易被跳过跳过的后果是前面配的分组没真正生效主机侧扫出来还是老样子。主机侧可以用几条命令确认映射是否真的落地了# 1. 采集 HBA 端口 WWN用于在 Mapping View 里登记主机身份 # 输出形如 0x500a0980001a2b3c粘贴进管理界面时注意去掉 0x 前缀 cat /sys/class/fc_host/host*/port_name # 2. 触发 SCSI 总线重扫让新映射的 LUN 出现在系统里 # 三个 - 分别代表 channel / target / lun全通配表示扫全部 for h in /sys/class/scsi_host/host*/scan; do echo - - - $h; done # 3. 确认多路径下每块 LUN 的可见性与聚合情况 # 同一 LUN 的多条路径应聚合成一个 mpath 设备而不是散成多个 sdX multipath -ll # 4. 查看 SCSI 层实际枚举到的设备核对数量是否与映射一致 lsscsi -gmultipath -ll的输出值得多看两眼如果同一块 LUN 出现了多个独立的设备节点而不是聚合成一个说明多路径配置有问题如果设备数量比映射的多说明有卷落进了 Default Group隔离没做干净。Windows 主机侧还有一层额外风险需要提前处理。Windows 默认策略会对新发现的磁盘自动上线并写入签名这正是跨主机数据损坏的经典成因。可以在映射之前先把策略改成离线# 将新发现的磁盘一律置为 Offline避免主机对不属于自己的 LUN 写入签名 Set-StorageSetting -NewDiskPolicy OfflineAll # 确认当前策略已生效 Get-StorageSetting | Select-Object NewDiskPolicy这条策略配合 Storage Partition 使用才是完整的Partition 保证主机看不到别人的盘离线策略保证即使因为某种原因看到了也不会主动去写。5. 在线扩容与常见问题排查改分区为什么不用停业务存储管理里最容易被低估的能力是“在线改”。扩容、加主机、加 Partition这些操作在 DS 系列上都是在线进行的不影响正在跑的业务。理解了这个“在线”是怎么来的遇到问题才知道从哪儿查。5.1 三条扩容路径与“在线”的来源第一条路径是动态卷扩容直接把已有 LUN 调大主机侧重扫之后看到块设备变大了再扩分区和文件系统。第二条路径是新增 LUN 然后修改该主机的 Storage Partition把新卷加进去——注意这里改的是映射表不是已有卷的属性。第三条路径是升级 Storage Partition 的数量授权让原本挤在 Default Group 里的主机能各自独立成组。三条路径的在线性来自同一个设计映射表的变更是“新增条目”或“追加 LUN 编号”不触碰已经生效的条目。已经在跑的 IO 走的还是原来那条路径新加的 LUN 对老会话不可见要靠主机侧重扫或者重新登录才会出现。所以“在线”不等于“自动生效”阵列侧改完了主机侧还得主动去发现一次。主机数量增加时同理新定义一个 Storage Partition 不会影响已定义的任何 Partition。注意在线扩容的前提是文件系统和卷管理器支持在线扩容。块设备变大了df不一定跟着变中间那层分区表和文件系统要单独扩。5.2 常见问题与排查现象一主机重扫之后看不到新映射的 LUN。原因通常是三选一WWN 填错了大小写、冒号、前导零的差异都算错卷映射到了别的 Host 或 Host Group 上或者主机没有重新对 fabric 做一次登录所以控制器那边还是旧会话。排查顺序是先在Mapping View里核对这台主机名下的 LUN 清单再回主机侧用cat /sys/class/fc_host/host*/port_name拿到真实 WWN 逐字符比对最后确认扫描命令确实写进了scan文件而不是只 echo 到了终端。现象二Windows 主机扫到了一块不属于它的盘并且自动写了签名。原因是这台主机没有被划进独立的 Storage Partition落到了 Default Group 里而 Default Group 的策略通常是可见所有未被独占的卷。解决分两步先按 3.1 的方案给这台主机单独建 Host 并补齐映射把它从 Default Group 里摘出来再在主机侧把NewDiskPolicy改成OfflineAll让自动签名这件事从源头上不可能发生。已经写坏签名的 LUN只能从备份恢复或者重建没有别的办法。现象三热备盘在阵列里显示正常故障发生时却没有自动顶上。原因包括热备盘容量小于故障盘、热备盘被指定成了只保护另一个磁盘组的专用热备、或者这个磁盘组压根没被纳入保护范围。解决方式是在热备盘的属性里确认它的保护范围覆盖了需要兜底的组并核对容量重建没起来的时候先看阵列的事件日志里有没有“insufficient capacity”之类的提示比盲目换盘高效得多。现象四LUN 扩容完成、主机也重扫了文件系统容量没变。原因是块设备变大只发生在 SCSI 层上面的分区表和文件系统还是旧尺寸。解决是依次扩分区growpart之类、扩物理卷、扩逻辑卷、扩文件系统每一步都要确认前一步到位了再走下一步。跳过中间任何一步最后df都不会变。现象五一块 LUN 在多路径环境里散成了多个独立设备。原因通常是多路径软件没识别到这块盘设备白名单没加或者同一块 LUN 通过多条路径被当成了不同设备。解决是先看multipath -ll里有没有对应的 mpath 条目没有就把该设备加进多路径配置并重新加载而不是急着在裸设备上直接建文件系统——那样做等于把一条路的数据和另一条路的数据割裂开。6. 串口命令行与图形界面什么时候必须离开鼠标图形界面和串口命令行不是“好用”和“难用”的关系是两种失效模式下的互补。管理套件的图形界面承担的是“建模”职责磁盘组、逻辑盘、Host Group、映射关系这些结构性配置在界面上有可视化呈现配错的时候能一眼看出拓扑不对这对防止误操作的价值远大于敲命令快那么几秒。现场绝大多数日常操作包括建卷、扩容、加主机、改映射走图形界面都更稳。串口那条路的价值在另一个场景管理网口不通、控制器状态异常、图形界面连不上的时候。这时候以太网管理通道默认地址段那种带外管理口可能整条断掉图形界面的自动扫描在网络上找不到任何控制器但通过串口登进去用终端工具以命令行方式仍然能拿到控制器的内部状态、看事件日志、做故障定位。它还能做到界面上没有的一些扩展查询信息密度更高代价是没有图形提示任何一条命令敲下去都没有“下一步”按钮帮你兜底。两条路的实际分工我一般这么理解图形界面用来“把结构搭对”串口用来“在结构出问题的时候还能进去看”。这带来一个容易被忽略的运维要求——串口连接方式、终端参数、登录方式这些信息必须在设备上架阶段就记录进运维文档而不是等出故障那天再去翻手册。真到了管理网不通的深夜能不能连上串口决定的不是效率是能不能在业务恢复窗口内定位到问题。这里还有个取舍值得说清楚图形界面之所以“更直观、更容易掌握”本质是它把一堆有依赖关系的操作编排成了强制顺序你不能在没选 RAID 级别的情况下直接去切分区也不能在没加 WWN 的情况下完成映射。这种强制顺序既是保护也是限制——它挡住了误操作也挡住了“我只想查一个状态”的轻量操作。串口命令行反过来什么都能干什么都得自己保证顺序对。两边都吃过亏之后我形成了一个习惯任何一次涉及映射关系的变更先在图形界面里把拓扑配好并截图存档变更完成后立刻用主机侧的扫描命令验证一遍 LUN 数量和设备名两步都过了才算这次变更结束。这个习惯救过我很多次——有几次就是靠变更前后的设备清单对比发现某台主机的卷落进了 Default Group在业务感知到之前就纠正了。希望帮到你。本文还有配套的精品资源点击获取