3. 实验环境搭建

在开始使用 HPE Alletra 的自动化能力之前,必须先建立一个“可被代码访问”的实验环境。本节的目标不是把设备装好通电,而是让后续的 Ansible、Python SDK、REST API 调用有明确的访问入口、可用的凭据和可验证的连通性。围绕这个目标,环境搭建可以拆成五条并行的准备线:模拟器、物理阵列、DSCC 部署、网络与账号、API 连通性验证。它们最终汇聚到同一个判断点——能否用一条命令或一次 API 调用拿到阵列的真实响应。

一、先决定用模拟器还是物理阵列

模拟器适合验证剧本语法、参数拼写和调用顺序,不需要真实硬件,也不会因为误操作影响生产数据。物理阵列适合验证真实性能、容量、快照、复制等依赖硬件的功能。两者不是替代关系,而是分工关系:先在模拟器上把自动化逻辑跑通,再切到物理阵列做端到端确认。

以 HPE Alletra 的 REST API 为例,模拟器通常提供与真实阵列一致的接口路径和 JSON 结构,但返回的数据是构造的。例如查询 /api/v1/arrays 时,模拟器可能返回一个固定的序列号 SIM-ARRAY-0001,而物理阵列返回的是真实序列号。因此,凡是依赖真实序列号、真实卷 ID 或真实性能计数的剧本,必须在物理阵列上复测。

二、DSCC 部署的位置与作用

DSCC(Data Services Cloud Console)是 HPE 面向云化存储的管理控制台,也是很多自动化接口的入口。部署 DSCC 时,需要明确它和阵列之间的管理关系:阵列通过管理网络向 DSCC 注册,DSCC 再向自动化工具暴露统一的 API 端点。实验环境中,DSCC 可以部署在本地虚拟机,也可以使用云端实例,但无论哪种方式,都要保证自动化主机能解析并访问 DSCC 的域名或 IP。

部署完成后,至少确认三件事:DSCC 管理界面可以正常登录;目标阵列已经出现在 DSCC 的设备列表中;DSCC 的 API 端点可以通过 HTTPS 访问。这三件事分别对应“控制台可用”“纳管成功”“接口可达”,缺一不可。

三、网络与账号准备

网络准备的核心是打通三条路径:自动化主机到阵列管理口、自动化主机到 DSCC、阵列管理口到 DSCC。建议在实验环境中使用固定的管理网段,例如 192.168.50.0/24,并给阵列管理口、DSCC 和自动化主机分配同网段地址。如果使用域名访问 DSCC,还要在自动化主机的 DNS 或 hosts 文件中写入解析记录。

账号准备要区分“人用账号”和“自动化账号”。人用账号用于登录界面,自动化账号用于 API 调用。自动化账号应遵循最小权限原则,只授予实验所需的卷管理、快照管理和只读查询权限。同时记录账号、密码或令牌的存放位置,避免把凭据硬编码在剧本里。实验环境中可以使用环境变量或凭据文件,例如:

export DSCC_HOST="dscc.lab.local"
export DSCC_USER="automation@lab"
export DSCC_PASSWORD="LabPassw0rd!"
export ARRAY_MGMT_IP="192.168.50.21"

这些值只是教学示例,实际使用时必须替换为实验环境的真实参数。

四、API 访问连通性验证

连通性验证不要只做 ping,因为 ping 通不代表 API 可用。建议按“网络层—传输层—应用层”的顺序逐层验证。网络层用 ping 确认地址可达;传输层用 curl -k -I https://<host> 确认 443 端口有响应;应用层用一次真实的 API 调用确认能拿到业务数据。

以查询阵列信息为例,可以先获取令牌,再携带令牌访问资源接口:

# 1. 获取访问令牌(示例端点)
curl -k -X POST "https://${DSCC_HOST}/api/v1/auth/token" \
  -H "Content-Type: application/json" \
  -d "{\"username\":\"${DSCC_USER}\",\"password\":\"${DSCC_PASSWORD}\"}"

# 2. 使用令牌查询阵列列表
curl -k -X GET "https://${DSCC_HOST}/api/v1/arrays" \
  -H "Authorization: Bearer <token>"

判断成功的依据不是命令没有报错,而是返回体中包含预期的阵列对象,例如 serialNumber、model、status 等字段,且 status 为正常状态。如果返回 401,说明凭据或令牌有问题;返回 403,说明权限不足;返回超时,说明网络路径或防火墙仍有阻断。

HPE Alletra 实验环境搭建:五条准备线与连通性汇聚 自动化主机 Ansible / Python SDK curl / REST 客户端 192.168.50.10 模拟器 语法 / 参数 / 调用顺序 SIM-ARRAY-0001 物理阵列 真实性能 / 容量 / 快照 192.168.50.21 DSCC 控制台 统一 API 端点 设备纳管与令牌签发 dscc.lab.local 网络与账号 管理网段 / DNS / 防火墙 自动化账号 / 最小权限 API 连通性验证 ping → curl -I → 真实调用 401 / 403 / 超时判断 判断点 返回阵列对象 serialNumber / model status 正常 → 环境可用 HTTPS 443 先验证 后复测 依赖 支撑 验证结果 API 响应 三条路径:自动化主机→阵列管理口、自动化主机→DSCC、阵列管理口→DSCC;三层验证:网络层 ping、传输层 curl -I、应用层真实 API 调用

五、把验证结果落到判断上

连通性验证的最终产物不是“命令跑过了”,而是一份可复用的判断依据。建议在实验记录中保留三类信息:访问入口(DSCC 地址、阵列管理 IP)、凭据来源(环境变量名或凭据文件路径)、验证命令与返回摘要。这样当后续剧本出现 401 或超时时,可以快速区分是凭据过期、权限变更还是网络策略调整。

实验环境建议先只开一条最小路径:自动化主机 → DSCC → 目标阵列。路径越短,排障时变量越少。等这条路径稳定后,再逐步加入模拟器、多阵列和更细的权限划分。
不要把生产阵列的凭据直接用于实验剧本。实验环境应使用独立的自动化账号和独立的凭据文件,避免调试过程中的误删、误改影响到真实业务卷。