📚 课程目录第1章 Pure Storage自动化运维全景

1. Pure Storage自动化运维全景

Pure Storage的自动化运维并不是单一工具的能力，而是由产品线、API体系、云管理平台三层能力叠加形成的整体。理解这三层各自解决什么问题、彼此如何衔接，是后续编写自动化脚本、接入监控告警、构建自愈流程的前提。本节先建立一张全景地图：FlashArray与FlashBlade分别承担什么角色，REST API如何成为自动化的统一入口，Pure1如何把本地阵列的数据汇聚到云端，以及自动化运维真正能带来哪些可量化的价值。

一、两条产品线：块与文件的自动化对象不同

Pure Storage的主力存储产品分为两条线，它们的自动化对象和接口语义有明显差异，写脚本前必须先分清。

FlashArray面向块存储与统一存储场景，对外提供iSCSI、Fibre Channel、NVMe-oF等块协议，同时通过Purity//FA操作系统支持文件服务。它的自动化对象主要是：卷（Volume）、主机（Host）、主机组（Host Group）、保护组（Protection Group）、快照（Snapshot）、克隆（Clone）、Pod、ActiveCluster双活对等体。典型操作包括创建卷并映射给主机、为保护组打快照、把快照克隆成新卷用于测试、配置异步复制到远端阵列。

FlashBlade面向非结构化数据场景，提供NFS、SMB、S3对象存储，底层是刀片式架构，容量与性能通过增加刀片线性扩展。它的自动化对象是：文件系统（File System）、对象存储账户与桶（Bucket）、快照与快照策略、SMB/NFS导出策略、数据复制链路、目录配额。典型操作包括批量创建文件系统并挂载、为对象账户生成访问密钥、按策略对文件系统打快照并复制到远端。

两条产品线的REST API在路径前缀、资源命名、认证方式上高度一致，但资源模型不同。这意味着自动化框架可以共用认证、重试、日志等公共层，而资源操作层需要按产品分别封装。

二、REST API体系：自动化的统一入口

Pure Storage所有管理能力最终都收敛到REST API。Purity//FA和Purity//FB各自暴露一套版本化的REST接口，通常以 /api/<version>/ 作为前缀，例如 /api/2.0/volume、/api/1.12/file_systems。认证方式以API Token为主：先用用户名和密码调用登录接口换取令牌，后续请求在 Authorization 头中携带该令牌。令牌有有效期，自动化程序需要处理过期与重新获取。

API的关键特性决定了自动化脚本的写法：

资源化路径：集合用复数或资源名表示，单个对象通过 /resource/{id} 或 /resource/{name} 访问，支持按名称直接操作，减少先查询再操作的往返。
幂等性设计：创建类接口在对象已存在时通常返回冲突错误而非重复创建，脚本应捕获该错误并视为“已达成目标状态”。
异步任务：部分操作（如克隆、复制、扩容）返回任务ID，需要轮询任务状态直到完成，不能假设请求返回即操作完成。
分页与过滤：列表接口默认分页，脚本必须处理 continuation_token，否则只能拿到第一页数据。

下面是一个获取FlashArray卷列表并翻页的示例结构，用于说明令牌与分页的处理方式（示例参数，非实测结果）：

POST /api/2.0/login
  body: {"username": "pureuser", "password": "******"}
  → {"api_token": "<token>"}

GET /api/2.0/volume?limit=100
  header: Authorization: <token>
  → {"items": [...], "continuation_token": "abc123"}

GET /api/2.0/volume?limit=100&continuation_token=abc123
  → {"items": [...], "continuation_token": null}   # 翻页结束

除REST API外，Pure Storage还提供Python SDK（purestorage、purity_fb）、Ansible模块、Terraform Provider、PowerShell SDK等封装。它们本质上是REST API的语法糖，理解底层接口后，使用哪种封装都能快速上手。

三、Pure1：跨阵列的云管理平面

Pure1是Pure Storage的云端管理与分析平台。阵列通过安全出站连接把遥测数据上报到Pure1，运维人员无需逐台登录阵列，就能在一个控制台中查看多站点、多产品的健康状态、容量趋势、性能指标和告警。

Pure1对自动化的价值体现在三点：

统一资产视图：跨FlashArray与FlashBlade汇总阵列、卷、文件系统、主机连接关系，适合做资产盘点与容量规划。
Pure1 REST API：提供面向云端的查询接口，可获取阵列清单、指标、告警、订阅信息，适合构建跨站点的报表与巡检脚本。
主动支持与预测：基于遥测数据做故障预测与容量预测，自动化流程可订阅这些信号触发工单或扩容动作。

需要注意，Pure1 API与阵列本地API的认证体系不同：Pure1使用API Client的私钥签名（JWT）方式，而阵列使用本地令牌。自动化平台通常需要同时维护两套凭据。

四、自动化运维的核心价值与典型场景

把上述能力组合起来，自动化运维解决的是四类问题：重复操作规模化、配置一致性、故障响应速度、资源可视化。对应的典型场景包括：

批量供给：为新项目一次性创建数十个卷或文件系统，按命名规范映射给对应主机，并设置快照策略。
快照与克隆编排：在应用发布前自动打快照，发布失败时用克隆快速回滚验证环境。
巡检与容量报表：定时通过API采集容量、性能、告警，生成日报并推送到运维平台。
告警联动自愈：监控系统捕获阵列告警后，自动执行预定义动作，如扩容卷、切换复制方向、创建工单。
跨站点一致性检查：对比主备阵列的保护组、复制链路、快照策略是否一致，发现漂移即告警。

自动化的第一步不是写脚本，而是把“目标状态”定义清楚。例如“卷已存在、容量为1TiB、已映射给host-db01、属于保护组pg-db、快照策略为每日保留7份”，只有目标状态可描述，脚本才能判断是否达成、是否需要修正。

五、全景关系图

下图把产品线、API入口、Pure1云平台与自动化场景的关系组织在一起，帮助建立整体认知：本地阵列通过REST API被自动化平台直接操作，同时通过遥测上报到Pure1，Pure1 API再为跨站点报表与预测提供数据来源。