企业官网建设流程全解析

简介：《Think System DM存储命令行界面初始化配置指南》是联想凌拓DM系列存储的官方配置手册，面向存储管理员与运维人员，重点解决图形界面向导不支持MetroCluster或纯IPv6等场景下的集群初始化配置问题。资源为单个PDF文件，大小411KB，含五章正文与两个附录，内容源自2019年8月发布的第三版。指南系统讲解集群设置工作流程、节点创建与加入集群、使用预配置ONTAP模板配置SVM，以及重要EMS事件邮件通知、syslog转发、SNMP陷阱主机等后续配置任务；同时提供集群设置工作表，可记录集群名称、管理IP、网关、DNS等关键参数，便于部署时对照填写。读者既能按章逐项完成初始化，也能直接参考工作表规划配置，适合需要以命令行方式部署和管理DM存储的初中级运维人员。目前已有667人学习，是一份实用的初始化配置参考。

1. 什么情况下必须走 CLI：ThinkSystem DM 初始化配置的边界

大多数存储管理员第一反应是用图形界面完成初始化，但 ThinkSystem DM 系列存储的 ONTAP 系统里，有两条路：能用 GUI 向导就用 GUI，可一旦遇到 MetroCluster 配置、纯 IPv6 网络这类 GUI 向导不覆盖的场景，命令行就成了唯一入口。这份命令行界面初始化配置指南，解决的正是这个边界问题——它把集群创建、节点加入、时间同步、事件通知和 SVM 配置模板串成一条可执行的初始化路径。适合两类人：一类是刚接手 DM 系列、想系统走一遍初始化流程的存储新人；另一类是已经在用 GUI，但遇到特殊网络或高级容灾配置时，需要快速定位 CLI 命令的集成工程师。

2. 集群设置工作表：动手前的 20 个参数和一条 MTU 铁律

2.1 先别敲命令，把「设置工作表」填完整

硬件上架、线缆连接完成之后，最容易被跳过的步骤就是填集群设置工作表。这份表在官方流程里是强制前置项，记录的是整个集群初始化过程中需要用到的所有值：集群名称、管理接口 IP、网络掩码、网关、DNS、NTP 服务器、节点位置描述等等。实际执行时你会发现，大部分配置失败都发生在参数记录阶段——要么是 IP 规划重叠，要么是 IPv4 掩码和 IPv6 前缀长度混淆，要么是 MTU 不一致。

填写工作表的意义不在于「照抄一遍」，而在于把每个节点的网络参数先固定下来。我一般会建议在表格里增加一列「该值来自哪个网段规划文档」，因为集群管理接口 IP 应该落在数据网络，节点管理接口 IP 也要单独分配，这两类地址如果来自同一个 DHCP 池，后期极容易冲突。另外，工作表中每个节点的物理位置描述也别偷懒，多节点集群排障时，「实验室 5，第 7 排，机架 B」这种写法比「机房角落」有用得多。

2.2 集群网络参数：专用集群网络的缺省值别乱改

对于使用网络交换机连接的集群，系统缺省值是为专用集群网络预设的。两个关键参数必须记牢：集群网络掩码缺省是 255.255.0.0，集群接口 IP 位于 169.254.x.x 网段，且每个节点上的每个集群网络端口 IP 必须落在同一子网。这些缺省值大概率是能直接用的，但要注意适用前提——只针对「配置为使用网络交换机」的集群。

有一个铁律需要单独强调：每个集群交换机必须使用 9000 MTU，集群中的每个节点也必须保持与集群互连交换机相同的 9000 MTU 大小。这个参数一致性是集群初始化和后期性能的命门，很多案例里节点已经加入集群但 intercluster 通信异常，最后查下来都是交换机端口 MTU 被改成 1500 而节点没同步。

2.3 管理接口与节点信息：IP、掩码、网关的一一对应

集群管理接口是集群管理员访问管理 SVM 的入口，它的 IP 通常应该位于数据网络上；节点管理接口则是管理单个节点的入口，同样需要唯一 IP。这两类接口最容易出现在规划阶段漏配或缺省网关的情况。工作表里明确要求记录集群管理接口的缺省网关，很多部署环境里管理网和业务网是隔离的，缺省网关一旦填错，管理地址虽然能起来，但从外部 SSH 永远不通。

节点信息部分有一个容易被忽略的字段是「控制器物理位置」，虽然它不影响连通性，但在多节点告警定位时它是排障线索。另外，节点管理接口如果被定义为数据端口，它的 IP 地址和数据网络掩码就要按数据网络来填，不能想当然按管理网段填——这两种网络往往掩码长度不同。DNS 域名和名称服务器 IP 同样在这一阶段记录，因为后续 NTP 服务器解析、邮件通知、syslog 转发都依赖 DNS 是否可用。

配置系统配置备份目标地址时要注意类型选择：仅限单节点集群，可以指定 HTTP 或 FTP 地址，而且提供该 URL 的 Web 服务器必须启用 PUT 操作，否则备份上传必然失败。这项工作表里还有一栏「集群基本许可证密钥」，初始化时不需要，但不装它就不能装功能许可证，建议提前在支持站点查好存进工作表，免得配 SVM 时卡在许可证报错上。

3. 在第一个节点上创建集群：create 与 join 的完整流程

3.1 打开电源后看到的第一屏：Welcome to the cluster setup wizard

所有节点上电后，连接到第一个节点的控制台，等待系统引导，会看到“Welcome to the cluster setup wizard ....”的提示。这里要先决定走 Web 浏览器路径还是命令行路径。如果显示了一个 https 访问地址，可以用浏览器完成配置；但如果你已经在纯 CLI 模式，直接按 Enter 进入命令行交互。

关键的决策点是这一句：

Do you want to create a new cluster or join an existing cluster? {create, join}:

第一个节点选create，后续节点选join。这个选择在初始化阶段一旦选错，处理起来比较麻烦：在已有集群的节点上误选了 create，会尝试另起一个集群；在全新节点上误选了 join，会因为没有集群可加入而中断。实际执行前建议把集群里所有节点的角色写在工作表里，避免凭记忆作答。

3.2 创建新集群：接受缺省值还是输入自己的值

选 create 之后，向导会逐个询问集群名称、集群基本许可证密钥、功能许可证密钥、管理员密码、管理接口 IP 等信息。每个参数都有缺省值，可以接受也可以输入自己的值。这里有几个细节值得注意：

• 集群名称必须以字母开头，少于 44 个字符，可包含.-_
• 集群管理员密码至少 8 字符，必须包含至少一个字母和一个数字
• 缺省情况下「自动支持」处于启用状态，如果环境不允许外部回传遥测数据，记得在设置完成后把它关掉

在向导运行期间输入的参数可以通过cluster setup命令重新打开向导来修改，这相当于初始化阶段的后悔药。很多管理员是在完成创建后才意识到某个参数填错了，直接重新执行cluster setup就能回到参数配置界面，不需要把节点重启再来一遍。

3.3 将剩余节点加入集群：每次只能一个，且必须完成

第一个节点创建完成后，剩余节点逐个加入。每次只能将一个节点加入集群，加入过程一旦开始就必须完成，该节点成为集群一部分后才能开始下一个。这个约束在文档里写得很明确，实操里最常见的错误是想并行操作——两台节点同时跑 join 向导，大概率后一个会报错，因为集群配置处于中间态。

加入流程会在节点上启动同样的向导，选择 join 后输入集群名称和管理员凭据，向导会配置该节点的节点管理界面和集群端口。如果使用 GUI 存储管理软件向导，后续节点可以跳过加入流程，但 CLI 模式下没有任何捷径，每个节点都要走一遍。

3.4 验证集群状态：cluster show 是唯一标准

无论创建还是加入，完成后第一步都是用cluster show确认节点健康状态和集群资格。只看节点是否在线是不够的，两个字段都要看：Health 和 Eligibility。

cluster1::> cluster show Node Health Eligibility ------------ ------ ----------- cluster1-01 true true cluster1-02 true true

Health 为 true 代表节点自身正常，Eligibility 为 true 代表节点有资格参与集群。如果 Health 是 true 但 Eligibility 是 false，说明节点还在加入流程的中间态，需要检查集群网络连通性或者 MTU 配置。我一般在所有节点加入完成后会连续执行三次cluster show，间隔 10 秒左右，确认状态稳定，防止某次查询正好落在集群配置同步的间隙里。

3.5 设置完成后的管理 SVM 与节点 SVM

向导在创建集群时只建立一个集群管理员 SVM，节点层面的服务和管理接口是分散配置的。这就是为什么文档里特意强调：可以用cluster setup来更改管理员 SVM 或节点 SVM 的值。比如你发现节点管理接口 IP 和网关配错了，不需要重新跑整套流程，用这个命令进入向导针对性修改即可。

另外，配置单节点集群时别忘了配置系统配置备份目标地址。单节点没有第二个节点作为配置冗余，远程 URL 是唯一的备份出口。这里要再次确认 Web 服务器已启用 PUT 方法，否则上传备份会失败，而且这类失败往往不是立刻暴露的，是下次需要回滚配置时才被发现。

4. 集群时间同步：NTP 配置与对称认证的关键命令

4.1 先校准系统时间和时区：cluster date show / modify

在关联 NTP 服务器之前，先把每个节点的系统时间、时区同步到一致。不要小看这一步——CIFS 和 Kerberos 认证都对时间偏差极其敏感，节点间时间差超过阈值，认证就会随机失败。先看当前状态：

cluster1::> cluster date show Node Date Time Zone ----------- ---------------- ------------ cluster1-01 01/06/2015 09:35:15 America/New_York cluster1-02 01/06/2015 09:35:15 America/New_York

如果时区不一致，用cluster date modify统一修改：

cluster1::> cluster date modify -timezone GMT

在配置 NTP 之前手动校准一次时间，能让 NTP 同步起点更准确。我的习惯是：先改时区，再手动校准大致的当前时间，最后再配 NTP 服务器。顺序反过来可能出现时间向前跳变，导致消息序列号这类依赖时间的服务出现短暂异常。

4.2 关联 NTP 服务器：cluster time-service ntp server create

时间校准后，把集群与一个或多个 NTP 服务器关联。命令格式：

cluster1::> cluster time-service ntp server create -server ntp1.example.com

这个命令的前提是集群已经配置了 DNS。如果还没有配置 DNS，就必须直接指定 NTP 服务器的 IP 地址。回车后系统会持续后台同步，不会立即输出结果。用cluster time-service ntp server show查看关联状态。

4.3 对称认证的完整命令链（从 ONTAP 9.5 开始）

ONTAP 9.5 起，NTP 支持对称认证，使用 SHA-1 密钥，需要配置共享密钥和 key-id。以下命令是认证配置的完整链路：

# 创建共享 NTP 密钥 cluster1::> cluster time-service ntp key create -id shared_key_id -type shared_key_type -value shared_key_value # 配置采用对称认证的 NTP 服务器 cluster1::> cluster time-service ntp server create -server server_ip_address -key-id key_id

这里的 key-id 是 NTP 认证中的「标识」，key 的 id、类型、值在节点和 NTP 服务器上必须完全相同。实际配置时，很多人只做了服务器端配置，忘了在 NTP 服务器上添加相同的密钥标识，结果认证一直失败。注意一点：对称认证的创建命令用的是server_ip_address，因为基于主机名的解析存在被 DNS 欺骗的风险，用 IP 更稳妥。

4.4 管理命令速查：修改、禁用与重启认证

有一个细节值得注意：为 NTP 服务器配置「未知密钥标识」这个动作本质上是把 key-id 绑定到服务器上，即使该 key-id 还没在 NTP 服务器端生效也能先配置上。但只有当 NTP 服务器端也配置了相同的 key-id、类型和值之后，认证才会真正成功。所以排障顺序应该是：先查 key 是否两边一致，再查服务器关联是否生效，别一上来就怀疑命令敲错。

5. 常见问题与避坑：5 个翻车现场与排查修复记录

5.1 现象：节点加入集群时卡在集群网络握手阶段

新节点选择 join 后，长时间停留在等待状态，cluster show里该节点 Eligibility 一直显示 false。查看节点日志，发现集群网络端口反复重启。

原因：集群互连交换机的端口 MTU 是 9000，但新节点集群网络端口的 MTU 还是系统默认的 1500。交换机丢弃了大包，节点间的集群协议包无法正常交互。

解决：把该节点的集群网络端口 MTU 手动改为 9000，然后重启集群网络端口。可以用 ifconfig 命令确认端口参数，修改为 9000 后重新触发加入流程。从那以后我每次加节点，先检查 MTU 再执行 join，几秒就过。

5.2 现象：集群管理接口 IPv6 地址配完，从管理网完全 ping 不通

管理接口配置结束后，接口显示 up，但外部网络无法访问。反复检查物理链路无异常。

原因：IPv6 的集群管理接口配置项里，「网络掩码长度」和 IPv4 的「网络掩码」是两个完全不同的字段。IPv4 填255.255.255.0，IPv6 应该填前缀长度64。有人直接把这俩字段都填成255.255.255.0，IPv6 地址非法，路由表里根本没有这条直连路由。

解决：在集群管理接口配置里，把 IPv6 前缀长度改为实际规划值（通常 64），重新激活接口。排障思路要区分：ping 不通先看接口物理状态，再查地址合法性，最后看路由表，不要在物理层反复折腾。

5.3 现象：NTP 对称认证一直报认证失败，node 日志里全是 bad auth

配置完共享密钥和认证 NTP 服务器后，cluster time-service ntp server show里服务器状态波动，日志里有认证失败记录。

原因：NTP 服务器的对称认证需要两端的 key-id、类型（如 SHA-1）和密钥值完全一致。检查后发现只在 ONTAP 侧创建了 key，NTP 服务器端没有添加同一个 key。没有共享密钥，客户端发起认证请求时，服务端回应了 denial，同步自然失败。

解决：在 NTP 服务器上添加相同 key-id 和值，两分钟后同步恢复正常。这条踩坑经验让我养成了习惯：配置对称认证的 NTP 时，先配服务器端，再配 ONTAP 端，两边核对 key 一致后再关联服务器。

5.4 现象：EMS 邮件通知配置完成后不触发，或者触发了但邮件到达慢

配置了重要事件邮件通知，测试时事件已经产生，但收不到邮件。用 event log 查看，显示事件已记录，通知目的地是 storage_admins，但发送状态异常。

原因：事件通知的发送依赖 SMTP 邮件服务器配置，而 SMTP 服务器地址用的是主机名。如果集群没有配置 DNS，事件被记录但邮件无法投递。看到的情况是一封都没有，而不是延迟。

解决：先用event config modify -mail-server mailhost.example.com -mail-from cluster_admin@example.com配置邮件服务器，并确认集群 DNS 配置完整。配置完成后发一封测试通知验证投递链路。这条经验之后，我配邮件通知的次序是：先配 DNS，再配 SMTP，再建邮箱目的地，最后建通知规则。

5.5 现象：template provision 跑完，SVM 的安全模式还是 unix

使用预配置模板配置 SVM，provision 过程中直接按回车接受了所有缺省值，创建完成后用 vserver show 检查，发现安全模式是 unix，但业务需要的是 ntfs。

原因：VserverEnvironmentSetup 模板是只读模板，其中 security_style 参数的缺省值是 unix。直接 provision，用的就是这个缺省值。模板 copied 后虽然可以修改参数缺省值，但很多人跳过了 copy 和 modify 步骤。

解决：用template copy -name VserverEnvironmentSetup -destination-name template1复制模板，再用template parameter modify -template template1 -name security_style -default-value ntfs修改，最后用template provision -name template1重新配置 SVM。配置完后验证vserver show -fields security-style。顺带提醒：SVM 配置需要功能许可证，而功能许可证必须在基本许可证安装之后才能安装，顺序不对会直接报错，建议在工作表里先确认许可证就位。

6. 模板定制与配置后验证：把只读模板变成自己的配置规范

VserverEnvironmentSetup 模板是只读的，意味着它自带的参数定义不能直接改。遇到需要修改默认参数时，先复制模板，再修改新模板的缺省值，最后用新模板 provision。这套操作在多个节点重复部署同一类 SVM 时特别好用。复制动作和修改参数可以这样做：

# 复制模板 cluster1::> template copy -name VserverEnvironmentSetup -destination-name template1 # 修改指定参数的缺省值 cluster1::> template parameter modify -template template1 -name security_style -default-value ntfs

模板里 26 个参数基本覆盖了 SVM 的完整配置：协议选择（nfs、cifs、iscsi、fcp）、数据 LIF 的 IP 和端口、网关、DNS、AD 配置、CIFS 服务器名、LDAP 等。实际规划时，先执行template parameter show把每个参数和运行值记下来，再决定哪些参数需要覆盖。比如多业务集群里，不同 SVM 的 security_style 和 languages 往往不同，我会按业务类型复制出多套模板，分别命名，避免每次 provision 都要现场敲参数。

配置完成后的验证，我习惯按顺序执行三条命令：cluster show确认节点健康与资格、cluster time-service ntp server show确认时间同步、event notification show确认事件通知目的地生效。这三条命令 10 秒内能跑完，却能覆盖集群最核心的三个状态维度：集群成员、时间基础、事件通道。有一次模拟项目 X 的集群配置完成后，所有服务看着都正常，只有event notification show里发现 syslog 目的地是空指针，邮件目的地也少了一条，当时如果跳过这步，故障告警就会全部丢失。从那以后我每次做完集群初始化，都强制走一遍这三条命令，把输出贴到当天的工作记录里。希望这条习惯也能帮到你。

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