企业官网建设流程全解析

简介：Think System DM 存储命令行界面初始化配置指南是一份联想凌拓官方技术手册，面向存储管理员与网络运维人员，重点解决 GUI 向导不支持集群设置的场景（如 MetroCluster 或纯 IPv6 环境）下，如何通过 CLI 完成 DM 存储的初始化与 ONTAP 配置。资源整体为 1 个 PDF 文件，压缩包大小 411KB，内容为完整中文版《软件设置指南》，便于查阅与离线使用。手册共五章加附录，系统梳理了集群设置工作流程、每个节点的初始化、在首节点创建集群并加入剩余节点等步骤；其中集群设置工作表可帮助读者提前记录 IP、网关、DNS、管理接口等关键值，降低配置遗漏风险。此外还涵盖使用预配置 ONTAP 模板配置 SVM，以及配置重要 EMS 事件邮件通知、syslog 转发和 SNMP 陷阱主机等系统任务，附录提供联系支持机构与声明。目前已有 667 人学习下载，适合需要针对 ThinkSystem DM 系列存储做命令行初始化配置的工程师作为参考速查手册。

1. 存储上架第一关：为什么初始化配置绕不开命令行界面

新存储从包装里拿出来，插好电源、连好后端磁盘、接上线缆，接下来第一件事不是点网页，而是面对一个现实：管理网口的 IP 还没配，网页根本登不进去。DM存储的初始化配置，恰恰就是在这个「网络还没通、网页还没影」的阶段进行的。命令行界面（CLI）就成了唯一能跟存储对话的通道，它能完成查状态、认磁盘、建存储池、建卷、映射主机这一整条链路。这篇文章按「连接、查状态、建资源、映射、排错、脚本化」的顺序，把 DM存储初始化配置这条路完整走一遍，新手可以照着敲命令，熟手可以重点看参数取舍和那几个最容易翻车的细节。

2. 连上命令行界面之前：先看清 DM存储的三种登录路径和初始状态

2.1 串口、SSH、带外管理：三种登录路径怎么选

DM存储的 CLI 登录路径，常见的有三条：串口（Console）、SSH、带外管理口。上架第一次操作时，最稳妥的是串口。原因很简单——串口走的是物理线，不依赖管理网口的 IP 地址是否配置正确。SSH 适合管理 IP 已经配好、网络可达之后的日常维护；带外管理口则是独立于存储数据平面的管理通道，适合远程诊断。

我一般会这么选：首次上架初始化，用串口；后续改配置、跑脚本，用 SSH；存储系统本身出了问题、SSH 和网页都进不去的时候，靠带外管理口救急。三种路径的登录入口和适用阶段不一样，别混着用。

用串口登录的操作如下：

# 在 Linux 管理机上，先确认 USB 转串口设备的名称 ls /dev/ttyUSB* # 用 screen 打开串口，DM存储常见波特率是 115200 sudo screen /dev/ttyUSB0 115200 # 退出 screen：先按 Ctrl+A，再按 K，最后输入 y 确认

逻辑说明：screen是一个终端复用工具，这里把它当作串口终端来用，不需要额外安装图形化串口工具。如果ls /dev/ttyUSB*没有输出，大概率是 USB 转串口芯片的驱动没装好，换根线或者换台机器试试。

不熟悉screen的话，用minicom也可以：

sudo minicom -D /dev/ttyUSB0 -b 115200

参数说明：-D指定串口设备文件，-b指定波特率。波特率必须跟存储侧保持一致，DM存储默认常见值是 115200，也有部分是 38400，具体以设备铭牌或出厂说明为准。串口登录成功后，会看到 CLI 的提示符，通常是一个>或者#，这表示可以开始敲命令了。

SSH 路径适合管理网口已经配好 IP 的情况。命令如下：

# 通过 SSH 登录 DM存储的管理 IP，默认端口 22 ssh admin@192.168.1.200 # 如果改过端口，用 -p 指定 ssh -p 2222 admin@192.168.1.200

注意，初始账号不是这篇内容能替你确认的，不同批次、不同出厂设置不一样，以设备机身上的标签或随附资料为准。登录后第一件事不是急着配置，而是看状态。

2.2 初始化前必查的系统状态字段：时钟、控制器、磁盘

刚登录 DM存储 的 CLI，不要直接去建池建卷，先把状态查清楚。命令行界面和网页不同，它不把健康状态画成绿色图标，而是给你一堆字段，你得自己判断哪些值得关注。下面这张表是初始化前必须过一遍的字段。

查看这些字段的命令很简单：

# 查看系统整体信息，含时间、控制器状态、系统名称 show system # 查看所有磁盘的状态和容量 show disk # 查看管理网络端口的状态 show network-port

逻辑说明：show system是初始化前必敲的第一条命令。它把系统级状态汇总成一页输出，重点看时间是否准确、有没有控制器不在线。如果系统时间差得离谱，后续配置生成的事件日志会很难追溯，建议在初始化阶段顺手校正时间。

show disk是建池前的关键检查。DM存储 的磁盘字段里，Uninitialized状态属于新盘未认到，Online才是可用状态；如果出现Offline或Rebuilding，说明磁盘有问题或者还在恢复，这种盘不能急着拿来建池。show network-port则是确认管理口链路状态，为后续切到 SSH 远程管理做准备。

2.3 首次登录后的最小安全检查：三查三不碰

第一次登录 DM存储 CLI，建议按「三查三不碰」的原则过一遍。三查：查系统时间、查控制器状态、查磁盘状态。三不碰：不碰删除命令、不碰初始化命令、不碰任何带reset字样的命令。

# 一查：系统时间和控制器状态 show system # 二查：磁盘状态，重点看 Status 列 show disk # 三查：告警信息，有告警先处理再往下走 show alarm

参数说明：show alarm在不同版本里也叫show event或show alert，具体名字以当前 CLI 的帮助为准。如果在终端里敲show alarm提示命令不存在，可以试着敲show后按 Tab 键补全，CLI 会列出所有可用的 show 子命令。

这个小检查的定位是「确认环境可操作」。磁盘阵列这种设备，最怕在状态没查清的情况下贸然执行配置命令，一旦把还在初始化的磁盘加进存储池，轻则重建时间变长，重则整池性能受影响。检查耗时不超过两分钟，但能让后面的每一步都走得踏实。

3. 磁盘和存储池初始化：把裸盘变成可用资源的完整命令序列

3.1 查看磁盘状态与识别故障盘：看懂 Status 列的五个状态

DM存储 的磁盘状态，在 CLI 里通过show disk查看，输出会列出磁盘槽位、型号、容量和状态。初始化配置的第一步，就是要从这一大串输出里挑出「能用的盘」和「不能用的盘」。

磁盘状态常见的有五种，我整理成一个状态对照表：

# 查看所有磁盘，输出包含槽位、状态、容量 show disk # 只看故障或不健康的磁盘，过滤关键字 show disk | grep -E "Offline|Rebuilding|Failed"

逻辑说明：show disk不带参数时列出全部盘，每一行对应一块物理磁盘。把它接到grep后面过滤异常状态，是排查故障盘最快的方式。输出里如果只有Online和Uninitialized，说明环境干净，可以放心往下走；如果混着Offline，先检查磁盘是否插到位，再确认是不是背板槽位故障。

参数说明：grep -E是扩展正则匹配，|表示或关系。这条命令只是在管理终端的 shell 层面过滤输出，不会影响存储本体。实际使用中，如果 CLI 输出里含颜色控制字符，需要加--color=never避免误判。

识别完可用磁盘后，记下槽位号。接下来建池的时候，需要用到这些槽位号来告诉存储「用哪些盘搭存储池」。这一步别偷懒用all这种笼统写法，明确指定槽位，后续换盘、加盘时清楚知道每一块盘在哪。

3.2 创建存储池的参数选择：RAID 级别、热备盘与容量计算

存储池是 DM存储 里承载所有卷的上级资源。建池之前先把需求理清：这个池子放什么数据，需要多大容量，容忍几块盘同时坏。这三个问题决定了 RAID 级别和热备盘数量。

常见做法是，性能敏感且容量压力大的场景选 RAID 5；数据重要性高、磁盘数量充足的场景选 RAID 6；只有两到四块盘的小规模场景选 RAID 1。热备盘一般配置一块，如果磁盘数量超过 12 块，配两块更稳妥。

# 创建一个 RAID 6 存储池，指定 12 块盘，再单独留 2 块做热备 create pool name=pool01 disk-type=sas raid-level=6 disk=slot1..slot12 hot-spare=slot13..slot14 # 查看存储池是否创建成功 show pool

逻辑说明：create pool是建池命令；name指定池名称，disk-type指定磁盘类型（SAS 或 NL-SAS 或 SSD，按实际盘型填）；raid-level指定 RAID 级别；disk=slot1..slot12是槽位范围的写法，表示从 slot1 到 slot12 这 12 块盘参与建池；hot-spare指定热备盘槽位。

参数说明：slot1..slot12这种连续范围写法是否支持，取决于 CLI 的解析器。如果不支持范围写法，改成逐个列出：disk=slot1 slot2 slot3 ...。判断方法很简单，建池前先敲help create pool看参数说明，CLI 会列出当前版本支持的语法。

建池后，存储会有一个初始化的过程。不同 RAID 级别初始化时长不同，RAID 6 的初始化明显比 RAID 5 慢。查看初始化进度：

# 查看存储池状态，关注 Progress 或 Status 字段 show pool pool01 # 查看存储池中磁盘的初始化进度 show disk pool=pool01

参数说明：show pool pool01第二个位置参数是池名，用来限定查询范围。输出里的Progress字段表示后台任务完成百分比。初始化没完成之前，不要急着往池里建卷，部分型号会限制此阶段的操作。

3.3 创建卷与设置容量：精简置备与容量单位的坑

存储池就绪之后，就开始建卷了。卷是主机实际读写的块设备，建卷时需要确定名称、所属存储池、容量大小、是否启用精简置备。这一步的容量单位，是整个初始化里最容易踩坑的地方。

# 创建传统厚置备卷，容量 2 TB create volume name=vol01 pool=pool01 size=2T thin-provisioning=no # 创建精简置备卷，容量上限 2 TB，实际按需分配 create volume name=vol02 pool=pool01 size=2T thin-provisioning=yes

逻辑说明：size=2T里的T代表 TB。问题在于，存储系统内部计算容量时，很多型号用的是 TiB（二进制单位），1 TiB = 1.0995 TB。也就是说，你创建了一个 2T 的卷，主机侧看到的容量可能只有 1.81 TiB，这是单位换算导致的，不是设备故障。

参数说明：thin-provisioning控制是否启用精简置备。yes表示卷的大小是上限，实际写入多少占用多少；no表示一次性把物理空间全部分配给这个卷。数据库、虚拟化平台这类对性能敏感的业务，存储侧空间充裕时用厚置备更稳；文件服务器、归档场景用精简置备更省空间。注意，精简置备卷的空间是共享存储池的，池容量一旦跑满，所有精简卷都会受影响，所以必须配合容量监控。

建完卷后用下面命令确认：

# 查看卷列表，确认卷状态为 Normal 或 Online show volume # 查看卷的详细信息和所属存储池 show volume vol01

到这里，存储侧的资源初始化就算完成了：磁盘被认到，存储池建好，卷也已经创建。但卷还只是存在于存储内部，主机根本看不到它。要让业务主机真正读写这些卷，还差最关键的一步——映射。

4. 把卷交到主机手上：主机映射与多路径的 CLI 配置

4.1 创建主机对象与 iSCSI/FC 映射：三条命令完成授权

存储的卷不会自动出现在主机上，必须先建立一个「主机对象」，再把这台主机使用的 iSCSI IQN 或 FC WWN 绑定到这个主机对象上，最后才能把卷映射过去。顺序不对，映射关系会乱。

# 第一步：创建主机对象，指定操作系统类型 create host name=host01 os=linux # 第二步：绑定主机的启动器标识 # 如果是 iSCSI 主机 add host-initiator host=host01 iscsi=iqn.2023-01.com.example:server01 # 如果是 FC 主机 add host-initiator host=host01 wwn=21:00:00:0e:1e:00:00:01 # 第三步：把卷映射给主机 map volume vol01 to host host01

逻辑说明：create host只是建一个空的逻辑对象，此时存储还不知道主机是谁；add host-initiator才是把主机的「身份证」告诉存储。iSCSI 用 IQN 字符串标识，FC 用 WWN 标识，二者必须在主机侧提前查好，填错一个字符，主机就登不上卷。map命令把卷映射到主机对象，映射完成后，主机侧扫描总线才能看到新磁盘。

参数说明：os=linux只是元数据，用于存储侧针对性地调整某些默认参数，不影响功能。如果主机是 Windows，填os=windows。map命令在被映射卷已被其他主机占用时，部分版本会拒绝执行或给出警告，这是保护机制，防止同一卷被多主机无保护地共享。

映射完成后查看关系是否建立：

# 查看主机对象的详细信息，确认 initiator 已绑定 show host host01 # 查看卷被映射到了哪些主机 show volume-mapping volume vol01

逻辑说明：show host host01会列出该主机下绑定的所有启动器和已映射的卷；show volume-mapping volume vol01从卷的视角反向查看映射关系。两条命令一正一反都能确认结果，建议都跑一遍。只有show host里能看到卷、show volume-mapping里能看到主机，映射才算真正生效。

4.2 多路径的 CLI 侧准备：双控制器配置别漏

生产环境的主机通常会通过两条甚至更多条物理路径连接到存储，目的是避免单条链路故障时业务中断。DM存储 这边，多路径的支持依赖两个前提：控制器都正常在线，主机侧的多路径软件能正确识别同一 LUN。

多路径不需要在存储侧为每个路径分别映射同一个卷。存储侧要做的，是确保这台主机的启动器在多个控制器上都完成了登录。iSCSI 场景下，主机会配置两个网口分别连到两个控制器；FC 场景下，主机 HBA 卡的两根光纤分别接到两个控制器。存储侧只需要建一个主机对象，绑定主机启动器一次，两个控制器会自动识别。

# 确认两个控制器都在线，分别为 controller-a / controller-b show controller # 查看主机在所有控制器上的登录会话 show host-connectivity host=host01

参数说明：show host-connectivity不是所有版本都有，没有这个命令时改用show host host01，查看输出中关于连接路径的信息。如果只有一个控制器显示已连接，说明另一条路径的物理链路或 zone 配置有问题，需要回到交换机侧排查，不要继续往下做。

主机侧的多路径软件配置（软件层面的参数）通常是操作系统管理员负责的，但存储侧必须配合确认一个关键点：同一卷映射给同一主机时，存储分配的 LUN ID 要一致。有的系统允许手动指定，map命令加lun参数：

# 指定 LUN ID 进行映射，避免主机侧出现盘符漂移 map volume vol01 to host host01 lun=10

注意，LUN ID 需要落在主机支持的范围内，常见是 0 到 255。如果主机侧已经存在其他存储映射的 LUN，提前规划一个不冲突的 ID，能省去后续很多排错时间。

4.3 映射完成后主机侧看不到盘：先查这三处

映射命令敲完，存储侧显示成功，主机侧却迟迟看不到新磁盘。这个问题几乎每个人都会遇到。我一般按下面三步查：

# 在 Linux 主机上扫描新的 SCSI 设备 # 先重扫主机总线 echo "- - -" > /sys/class/scsi_host/host2/scan # 如果是多路径环境，再扫描多路径设备 multipath -r

逻辑说明：存储侧映射成功不代表主机侧会自动感知。Linux 主机需要手动触发 SCSI 总线重扫，echo "- - -" > /sys/class/scsi_host/host2/scan是常用的重扫方法，host2 是主机上的某个 SCSI Host 编号，不同机器编号不同，可以在/sys/class/scsi_host/下查看有哪些 host。

参数说明：multipath -r用于多路径环境下重新加载多路径映射。执行前先确认主机已安装 device-mapper-multipath，否则命令不存在。执行完这两条命令还是看不到盘，再查启动器是否绑定正确：

# 在主机侧查看自己的 iSCSI IQN 或 FC WWN cat /etc/iscsi/initiatorname.iscsi # 或者用命令查看 FC 卡的 WWN cat /sys/class/fc_host/host*/port_name

拿到主机侧真实的启动器标识，回到存储侧show host host01对比，看是否完全一致。很多映射完成却不通的案例，最后都是 IQN 少写了一个冒号或 FC WWN 多写了一组 00。

5. 初始化配置避坑指南：五个容易出错的操作细节

5.1 现象：建池时某块磁盘状态是 Rebuilding，建池后整池性能起不来

原因：新盘加入系统后，存储会自动触发数据重构或一致性检查，处于Rebuilding状态的磁盘正在后台同步数据。此时把它强行加入存储池，存储不仅要重构这块盘，还要同时响应正常业务 IO，负载叠加，建池初始化和后续性能都会受明显影响。

解决：建池前用show disk | grep -E "Online|Uninitialized"过滤，确认所有待用盘都处于可建池状态；Rebuilding或Offline的盘不要纳入建池范围。等重构完成后再执行建池。如果重建过程超过预期时间，先查后端磁盘背板和物理连接，不要一味等待。

5.2 现象：创建了 2T 的卷，主机侧显示只有 1.8T，怀疑存储吞容量

原因：存储 CLI 里2T通常按二进制单位 TiB 计算，1 TiB = 1024 GiB；操作系统显示容量时同样按二进制单位换算，但人眼习惯十进制 TB，换算后看起来少了约 10%。这不是故障，是单位换算差异。

解决：建卷前明确容量需求。如果是数据库或数据仓库场景，按用户实际需求加 5% 余量再建卷；如果是归档场景，直接在size参数里换算好期望的实际可用值。参考命令行帮助确认当前版本容量单位，必要时用size=2048G精确指定，避免模糊换算。

5.3 现象：存储侧显示映射成功，主机fdisk -l找不到新盘

原因：映射成功后主机没有触发总线重扫；或者启动器标识绑定错误，存储侧虽然映射成功但主机根本没登录；还有可能是主机侧 zone 配置漏掉了存储端口，FC 场景最常见。

解决：按第 4.3 节的顺序排查。先重扫 SCSI 总线，再查启动器标识是否一致，最后检查交换机 zone。排查时可以重复执行show volume-mapping和show host-connectivity，对比输出中显示的主机连接是全部路径在线还是只有部分在线，以此缩小范围。

5.4 现象：CLI 长时间无操作后断开，某个配置命令不确定有没有执行成功

原因：命令行界面为了防止未退出连接一直占着会话，通常会设置空闲超时。超时断开本身不可怕，可怕的是配置命令执行到一半时断开，到底执行成功没有无从判断。

解决：养成「执行后立刻查」的习惯。每敲一个create或map命令，紧跟一条show命令确认结果。例如建卷后立刻show volume vol01；建池后立刻show pool pool01。如果超时发生在命令执行过程中，重新登录后用show系列命令检查目标对象是否已存在，不存在就重跑，存在就跳过。另外，尽量使用支持批处理的方式一次性下发多条命令，减少长时间悬挂在交互终端里的风险。

5.5 现象：误删了卷，数据无法恢复

原因：delete volume这类删除操作在多数存储系统上是立即生效的，没有回收站，也没有二次确认弹窗。敲错一个命令、写错一个卷名，数据就没了。

解决：删卷前用show volume vol01确认卷名和所属存储池，再检查这个卷是否还映射给了生产主机；如果映射关系还在，先unmap volume vol01 from host all解除映射，再执行删除。稳妥的做法是，在初始化阶段就建立命名规范和操作习惯：建卷命名带业务前缀（如db、archive），删除命令执行前先截图或复制show输出留底。误删后立即停止写入，联系存储技术支持尝试底层恢复，但成功率不保证——所以最值得投资的，还是删除前那几秒钟的确认。

6. 把初始化配置脚本化：从手敲命令到批量交付的进阶做法

初始化一台存储可能只需要几十条命令，但机房里有十台同样配置的存储需要交付时，手敲就变成了体力活，还容易敲错。把配置过程脚本化，是减少人为失误和翻车概率的实际手段。

6.1 用别名和命令补全减少手滑

DM存储 的 CLI 通常支持会话级的别名设置，或者至少支持命令名补全。登录后先定义好常用别名：

# 在 CLI 中定义别名，后续可用简称代替长命令 alias sp='show pool' alias sv='show volume' alias sh='show host' alias vm='show volume-mapping'

逻辑说明：别名的作用是减少长命令的击键次数。sp对应show pool，每次查看存储池状态时敲两个字符就够了。不是所有版本的 CLI 都支持别名，如果alias命令报错，改用 CLI 自带的补全功能——通常按 Tab 键可以自动补全命令或参数，多按几次还能列出候选内容。

6.2 配置脚本模板与回滚备份

把前面几章的命令按顺序写成脚本，可以保证每台存储的配置完全一致。脚本里要加入防呆机制：出错即停、日志留痕、环境检查先行。

#!/bin/bash # DM存储初始化配置脚本示例（伪代码，命令结构以实际 CLI 为准） # 用法: ./init_storage.sh <管理IP> <池名> <卷名> set -e MGMT_IP=$1 POOL_NAME=$2 VOL_NAME=$3 # 登录并执行配置命令 ssh admin@"$MGMT_IP" << EOF show system || exit 1 show disk create pool name=$POOL_NAME disk-type=sas raid-level=5 disk=slot1..slot8 hot-spare=slot9 show pool $POOL_NAME create volume name=$VOL_NAME pool=$POOL_NAME size=2T thin-provisioning=no show volume $VOL_NAME EOF

逻辑说明：set -e让脚本在第一条出错命令处停止，避免带着错误状态继续下发后续命令，防止半配置状态出现。<< EOF是 heredoc 语法，把其中若干行命令作为标准输入传给ssh会话，|| exit 1表示show system失败时立即退出脚本。

参数说明：这是脚本骨架，实战中要加上日志记录、密码处理、命令回显。配置完成后，建议用show pool、show volume、show volume-mapping三个命令的输出重定向到文件，作为初始配置的备份，后续变更时对比参考。

6.3 验证脚本：初始化完成后的十分钟检查清单

初始化不是敲完命令就结束了，验证环节别省略。我习惯用一个检查清单脚本收尾，把关键状态一次性拉出来，快速判断配置是否正确。

#!/bin/bash # DM存储初始化验证脚本（伪代码） ssh admin@"$1" << EOF echo "=== 1. 系统状态 ===" show system echo "=== 2. 存储池状态 ===" show pool echo "=== 3. 卷状态 ===" show volume echo "=== 4. 映射关系 ===" show volume-mapping EOF

逻辑说明：四个show命令覆盖了从系统到映射的全部关键环节。看输出时重点确认：系统状态无告警、存储池状态为 Normal、卷状态为 Online、映射关系里有目标主机。主机侧再用multipath -ll检查多路径是否认到同一 LUN 的多条路径。

这套验证习惯是我自己吃了亏之后养成的。之前有一次配置完存储，自认为命令都执行成功了，结果第二天业务上线才发现主机侧一直拿不到盘，查下来是映射少做了一步。从那以后，每次初始化配置，我都会把验证脚本跑一遍再交给下一个环节。配置存储这件事，命令本身不难，难的是每一步都确认到位，给自己留一份可追溯的记录。希望这份从连上串口到脚本化交付的完整路径，能帮你在下一次存储上架时少踩几个坑。

本文还有配套的精品资源，点击获取