为什么需要别名
分区配置里满是 10:00:00:00:c9:xx:xx:xx 这类地址，人工审阅时很难判断某条规则到底放通了哪台服务器、哪个端口。别名机制允许先给每个 WWN 起一个名字，再在分区里引用别名，配置从此可读、可评审、可交接。更实用的价值在于变更：HBA 硬件更换后 WWN 会变化，如果分区规则引用的是别名，只需把别名重新指向新的 WWN，分区结构本身不动，变更范围与出错概率都显著降低。反之若分区里直接写 WWN，每次换卡都要逐条修改规则，很容易遗漏某个 zone。
命名要素建议
| 要素 | 示例含义 | 作用 |
|---|---|---|
| 站点或机房 | 标识所在位置 | 多站点环境下避免重名与误配 |
| 设备角色 | 主机、存储、备份等 | 快速判断访问方向 |
| 设备标识 | 主机名或资产编号 | 与资产管理体系对应 |
| 端口序号 | 端口 1、端口 2 | 区分同一设备的不同路径 |
| 用途备注 | 业务或集群名称 | 便于跨团队沟通与审计 |
基本信息
| 作用范围 | 在交换机或存储侧定义，供分区与映射引用 |
|---|---|
| 命名要求 | 全局唯一、长度受限、避免特殊字符 |
| 维护要求 | 与资产台账同步更新，淘汰设备及时清理 |
| 变更优势 | 换卡时只改别名指向，分区结构保持不变 |
| 评审价值 | 配置可读性提升后，变更评审才能真正发现错误 |
典型使用场景
- 分区配置编写：以别名代替裸 WWN，配置可读性明显提升
- 设备更换：改别名指向完成切换，减少对分区规则的触碰
- 审计与合规：从配置中直接看出访问关系，便于核对授权范围
- 多站点管理：统一命名前缀，避免跨站点重名与误操作
- 新人交接：命名规则自解释，降低依赖个人记忆的风险
别名要及时清理：退役设备保留的别名会造成配置冗余与误判。建议在设备退役流程中加入别名清理步骤，并定期核对别名与在用设备的一致性。
别名的创建方式、长度限制与是否只在本地生效因厂商而异；部分实现中别名不随 fabric 自动同步，多交换机环境需分别维护，具体以官方文档为准。