【作者】周奇凡，某城市商业银行科技部数据中心架构师，目前主要负责全行私有云平台、存储平台等基础平台架构设计及容灾能力建设工作，推进基础设施转型改造。
一、 自动化项目的背景
存量存储自动化建设痛点：
1、 存储设备类型多，不同品牌的配置定义差异较大
以集中式 SAN 存储为例 ，在lun映射的逻辑中， 既 存在 A 厂商（lun - lun组 - host组 - 端口组）一个映射链条的配置，也存在 B 厂商（lun - lun组 - port - host组）多个port多个映射链条的配置。
不仅仅是集中式存储，同一类型产品都存在 配置逻辑的细微差异 ， 导致独自建设的场景的扩展性差，扩展往往需要重构场景。
2、 自动化产品难以覆盖个性化的需求
自动化不仅服务于覆盖资源交付，还包括基线监控、容量分配分析、智能应急预案等个性化场景。考虑到存在大量个性化需求，选择开展存储自动化自研工作。
3、 竖井式建设自动化场景，既重复“造轮子”，也限制了更复杂的场景建设
早期的自动化建设以单一场景的形式由存储管理员提需求，统一自动化平台开发实现。此类竖井式需求导致自动化建设效率低下，一是 API 的解析仅按项目需求展开，二是需求场景过于单一，自动化投入的复用价值低。
更重要的是，此类竖井式的做法导致需求与需求间没有关联性，未来持续扩展能力差，需要关联解决更复杂场景时，往往需要全面重构。
存储自动化项目建设思路：
1、 由模型构建推动自动化场景实现，保障场景的扩展性
以自下而上的路径，以构建模型优先，重新梳理并采集存储相关配置项，为自动化场景铺垫基础。不以实现某个具体场景为目的，将所有有效信息进行采集、模型匹配。如后续场景建设仍缺失数据，先优化模型补全数据，再完成场景建设。
2、 重构存储配置模型，积累自动化数据，并向CMDB投送
模型自动化数据除了服务于自动化需求，也可以向CMDB供数。作为自动化运行的支撑数据，主要以采集为主，可以作为CMDB的细节数据来源。在部分自动化场景中，也经常需要调用CMDB的其他对象数据，同样的存储自动化项目也是为了优化CMDB数据。
存储自动化平台定位
二、主要实现过程
自动化实现步骤
1、可行性评估阶段——挑选合理采集接口、排除不合理需求
①剔除低成熟度接口：
不同产品提供原生接口差距较大，部分旧型号设备甚至没有合适的采集API（如仅支持SSH交互）。低成熟度的交互接口使得实现成本高、稳定性差，应在评估阶段提前识别并剔除，可以一定程度上保障自动化建设效率。
②筛选最佳API接口源：
同一套设备的数据来源也可以选择不同的接口，部分设备有原厂预制的统一管理平台。在保障接口稳定性、数据准确性的前提下，可以选用相对更易用的一套API接口，达到提高自动化效率目的。
③排除不合理需求，挑选优先级：
自研自动化的一个重要的前提是为了满足个性化需求，并非所有场景都适合自研。如已有成熟的自动化能力且能力相对标准，优先考虑复用或进行集成。
2、数据采集阶段——批量采集原始数据
①全量扫描采集对象
在评估阶段明确采集对象后，根据接口文档尽可能将全量数据一次采集完成原始数据（键值对）入库。该过程与实现场景无关，一次全量扫描能避免后续反复研究采集接口，提高采集效率。
②减少递归交互次数
为尽可能避免对采集API设备造成性能影响，在批量采集阶段可以最大程度减少递归查询，批量采用GET全量数据的接口。
3、模型匹配阶段
①自动化模型设计
为了实现自动化场景与具体产品的配置项解耦，使能兼容多种不同类型产品，要避免使用采集后的原始数据，必须引入模型层。而模型层的构建是整个自动化项目最核心的部分，一个好的模型结构可以有效支撑未来自动化场景的扩展。
②原始数据匹配模型并入库
完成模型设计后，由业务逻辑对原始采集数据进行处理，入库至模型层内，后续的主要数据消费均由模型层提供。
4、场景实现阶段
①消费层视图生成
与模型层不同，在实现具体自动化场景时，仍需要调用大量模型层数据并形成新的视图，而这类新的视图与业务逻辑紧密关联，往往需要频繁调整。故此类与场景直接关联的数据应生成新的消费层数据。
②自动化场景实现
三、三层模型设计思路
1、三层数据模型
①设备层：通过API采集的原始数据，以基础键值对形式存放在原始库中。设备层数据没有明确的关联关系，主要要保障数据的准确性及覆盖率。保障设备层数据的关键是挑选合适的采集接口。
在设备层中，统一含义的存储池容量在不同接口中名称、单位均可能不相同。
示例：存储A-PoolA的：“StoragePoolSize”值为“100TB”；存储B-PoolB的“PoolBlockSize”值为“219,902,325,555,200Byte”
模型层数据是自动化场景构建的基础，模型层内容只支持扩展，不适合频繁调整。故在设计模型层时要尽可能考虑全面，一是要尽可能兼容多种类型的设备，二是尽可能满足消费场景的需求。
示例：存储A-PoolA的：“PoolSize”值为“102,400GB”；存储B-PoolB的“PoolSize”值为“204,800GB”；在模型层中，重新定义PoolSize，将不同的原始数据清洗为标准属性名称，并统一数据格式
示例：存储A的：“Usage-rate-health”值为“1”；存储B的“Usage-rate-health”值为“0”；在这里“Usage-rate-health”的值代表一台存储是否存在任何存储池使用率超过90%的情况，超过90%置为“1”，在这种情况下该值的业务逻辑可能随时变化为85%，故应该作为消费层数据，供具体场景调用
2、自动化数据调用原则
①自动化场景禁止直接调用原始数据
如为了实现某个型号存储的一个专项基线配置监控，这个配置参数仅该型号设备独有（例：某产品的“ConfigurationA”为“1”or“0”，代表该设备启用了某种特定功能），哪怕其他型号并没有这一配置项，也应扩展一模型层配置项录入原始数据后被代码调用。可以将自动化场景与数据准确性彻底解耦，避免互相影响。
②模型层数据尽量以采集数据为准
模型层数据虽然也由原始数据+处理逻辑生成，但该部分处理逻辑仅以配置项匹配、格式统一、补全空值为主，不含具体业务逻辑。以原始数据采集为准，可以最大程度保障模型层数据的准确性，避免影响上层业务场景调用的准确性。
③避免轻易复用消费层数据
四、数据模型设计过程
模型构建以实际情况为准，并没有标准答案，实际情况下往往会因为场景发展的顺序不同导致结构差异。
接下来以一个存储模型设计过程作为示例，仅提供思路参考。
1、模型对象&属性基础设计（需求：建设SAN存储自动化）
①抽象关键实例，整合类似对象，避免信息重合
以集中式存储为例，既有仅提供SAN存储的型号、也有同时提供SAN、NAS协议的。如分开定义两种类型存储，可能存在信息重复，如统计总设备台数时可能加剧业务复杂度，故统一定义为集中式存储。一般在使用场景中基本不相干的配置才会分离为多个模型对象。
②谨慎定界模型对象及属性
部分对象很容易被误设计为某一对象的子属性，一般可以参考以下2点：一、该配置是否可能存在多个子属性；二、该配置是否存在多种关联关系。
2、模型横向扩展（新增关联需求——NAS相关自动化场景）
①模型支持横向扩容，尽量避免纵向插入
一个业务场景业务场景的新增，扩展模型是在所难免的，而场景关联度较低模型扩展不会影响整体架构；但如需调整一段完整逻辑，如其中一个配置需要从属性调整为模型对象，可能涉及大量的代码改动。
在模型扩展时，尽量充分考虑新扩展可能涉及的所有模型，避免后续出现纵向插入。
建议：NAS场景的全量模型一并考虑，避免未来发现缺漏了一项（比如NAS
租户），同时新设置的模型也不仅仅为当下的需求展开（比如以太网接口可能被ISCSI场景复用）
②场景新增时，尽量复用存量对象，保障对象的全局性
场景与场景之间并不是割裂的，在场景新增时仍要确保全局的模型是完整一体的，避免出现模型对象割裂。
建议：不新建NAS存储这一对象，复用集中式存储。
3、模型横向扩展（新增矛盾需求——虚拟存储网关）
视核心逻辑保留模型、补全专项配置信息。
假设考虑引入虚拟存储网关（如SVC），对于模型设计而言是一个典型挑战，从原有的“主机”-“映射”-“存储”的三层结构变成了“主机”-“映射”-“虚拟网关”-“存储”的四层模型。
如能提前识别业务逻辑，应将虚拟网关作为整体模型的一部分；但如上层已经完成场景的实施，整体插入一层模型是不现实的。
此时应以满足核心业务逻辑优先，选择性忽略一部分信息先进行信息录入。如大部分业务逻辑以硬件设备信息开展，可以先将虚拟网关视作一类特殊业务，由专项模型进行信息补充。
建议：视核心业务场景情况在原有模型中完成数据录入，再单独设计“存储”-“虚拟网关”的关系补全数据。
4、模型横向扩展（新增非关联需求——对象存储）
参考历史模型，借鉴设计经验。
对象存储与存量模型虽没有明显的关联关系，但仍可以借鉴此前模型的一些设计经验。此类扩展场景也不仅是对象存储，也可能是备份、私有云VPC等其他新的自动化领域，往往参与设计的人是不同的。模型设计团队应关注以下几点：
1、统一定义风格：按统一风格应定义分布式存储集群，而非对象存储集群。
2、借鉴关联关系：许多关联关系可以借鉴，比如租户，虽然暂时未使用租户概念，也可以提前设计，避免未来模型调整。
五、自动化场景实践
存储的自动化场景是高度个性化的，在完成模型层设计后，可以实现不同类型的场景。但并非所有管理能力建设均依赖自研，个性化自动化场景是为了补充部分管理能力。以下是一些场景的粗略展示，大致可以分为三类：统计类、监控类、变更类：
1、统计类：是适用性最高的自动化场景，每家公司的管理要求不同，统计类需求往往是个性化的，且数据展示风险较低，在自动化建设时，优先可以落地统计类场景，也可以加速验证模型数据的可靠性，以便进行下高风险场景的落地。
2、监控类：与统计类场景类似，但监控数据需要以来监控模块完成专项监控数据上报，并不是基于三层模型直接调用，但也可视为某一特定用途的消费层数据。而自研的监控能力主要依赖管理API，很多并非为监控而设计，监控频率不低于5分钟，主要作为标准监控的一类个性化补充，难以替代原生监控能力。
3、变更类：作为高风险自动化场景，变更类场景所依赖的数据、逻辑的严谨性要求极高，建议先通过统计类自动化场景对模型数据完成验证后再正式上线。一般除了存储自动化平台外，往往都有统一自动化平台，作为存储自动化平台而言，一般不直接在前端执行自动化作业，做好北向接口的封装被其他平台调用。存储作为底层基础平台，在北向接口提供时，要注意双向鉴权，避免高权管理接口外泄。
六、整理总结
这是一套自动化项目设计的思路，理论上跟具体场景无关，也可以复用于存储以外的自动化需求。该思路从实现需求优先转为构建模型沉淀数据优先，可以有效积累自动化能力，通过新的场景落地推进该领域自动化建设进入正向循环。
此外，自研自动化需要投入大量的人力资源，对大部分公司而言都面临着巨大的挑战，建议要以满足个性化需求优先，充分利用并集成现有自动化能力，将成本压缩至可接受范围。
如有任何问题，可点击文末阅读原文，到社区原文下评论交流
觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 “存储”技术主题 ，将会不断更新优质资料、文章。地址：https://www.talkwithtrend.com/Channel/179
长按二维码关注公众号
