张磊,刘军,晁凯,张敏杰,吴垠,刘赛
(1.南瑞集团有限公司(国网电力科学研究院有限公司),南京210003;2.南京南瑞信息通信科技有限公司,南京210003)
近期,国家电网有限公司完成云平台建设,并进入常规运营阶段[1-2]。随着多个重要业务系统迁移上云,业务部门对平台提出下一步工作的推进要求[3-4]。如何发挥云平台在不停运、无感知检修的先天优势,提高自动化、智能化作业水平,推进传统业务、云上业务无感检修成为当前云平台运营工作中重点的研究任务[5-6]。
国家电网公司通过云平台建设,构建了新一代信息基础设施平台,带动了公司的IT 资源和数据资源的建设,应用运维向“企业级”转型,实现了强大的平台架构,强大的支持和响应敏捷性,全局资源调度,灵活的共享和高效的应用[7-8]。
云平台和数据中心坚持“企业级”建设,协调公司的规划,建设和运营,实现公司IT 资源,数据资源和系统服务的“企业级”共享应用[9-10]。电网业务系统逐步迁移上云,相关的软硬件资源由云平台按需提供,不再根据系统进行配置,将公司的数据资源统一到公司的数据中心管理中,构建全网一朵云架构,形成一个“IT 资源服务中心”和一个“数据服务中心”,实现总部与省公司操作两级协同[11-12]。全网一朵云平台如图1 所示。
图1 全网一朵云平台
方法和目的:扩容云平台资源池,保证资源后备充足,分配率警戒线75%,保证资源稳定、足额、高利用率供给。重要措施:推进资源监控、资源统计、容量预测工作,严格执行资源申请开通、变更、回收机制,建设云平台组件健康管理指标体系,达到事先健康评估和故障、隐患发现的效果,以不停机检修工作为契点,建设全自动化业务系统检修机制,降低人为故障率。资源健康管理系统的框架如图2 所示。严格按照操作计划的内容执行日常操作,并在日常工作的闭环中反馈有关组件优化,问题消除和云咨询工作的补充建议。将云平台资源运作流程制度化,建立云业务结构和资源应用的评审流程,逐步制定评审标准。
图2 资源健康管理系统的框架
结合云平台Devops 解决方案和非感知实现的应用程序发布,主要从业务系统的服务系统的角度研究在不停止服务的情况下如何进行维护工作的策略和计划。并且用户不知道,并且对现有的维护对象进行了大修。标准化操作程序和实施计划的流程准备。
在发布过程中,用户不会感知到服务的重启,这通常是通过新旧版本的共存实现的,也就是说,在发布过程中,新版本和旧版本是相互备用的通过切换路由权重的方式(不是0 或100)实现不同应用程序的联机或脱机,在不中断业务的情况下完成可视化的一键式灰色释放,并且可以在升级期间随时回滚到旧服务流程,以确保升级安全。无感知检修过程如图3 所示。
图3 无感知检修过程
通过不间断的维护,在不影响用户正常工作的情况下,实现了不间断维护工作的应用服务保证。确保业务系统安全、稳定、高效的运行,大大提高了前端用户的系统体验价值,增强了客户的黏度,解决了系统维护中业务不畅的问题。
通过实验,对应用服务进行了不间断检修。验证方案包括ECS 加SLB 大修方案,CS 加SLB 大修方案,CS 服务单批大修,CS 服务批大修,CS 微服务大修以及微服务配置中心配置大修。
SLB 负载权重用于控制访问请求访问的ECS 服务。升级资源统计服务时,可以通过调整负载均衡负载来实现。其他内部服务不允许直接访问ECS IP 地址,必须通过SLB 访问,否则将无法实现不间断运行检查。
根据云平台资源部署服务,具体如下ECS_IP:25.50.146.204、25.50.146.203,ECS 服务端口:18080,SLB_IP-PORT:25.50.15.17-8081。确认两个ECS 的服务正常,确认SLB 负载正常,两个ECS 的负载权重为100,请访问http://25.50.15.17:8081,请求将被随机发送到两个ECS 比例为1:1 时,服务正常,可以通过调整重量来更改比例。
测试正常后,将重量调回100,或逐渐调整。这时,用户将随机访问版本1 或版本2 的服务。如果确定版本2 正常,则可以选择快速调整204 的权重,而203 将直接接管请求。检查SLB 入口http://25.50.15.17:8081的服务是否正常,所有请求将被203 接管。
至此,该服务的大修已经完成,在此过程中,仍有一些服务提供不间断的服务来满足不间断的大修要求。维护操作版本升级或自包含配置修改等。通过SLB 负载切换方法可以实现业务应用程序的不间断维护要求。检修过程的结果如图4 所示。
该服务部署的CS 服务通过SLB 端口公开该服务。CS 服务中有多个容器组副本。理论上,当需要对应用程序进行大修时,只需要替换容器组副本的内容即可。具体操作主要涉及负载的控制。CS 服务的容器组副本需要在版本维护开始时删除负载,并在维护完成并通过测试后自动添加负载。
图4 无感知检修结果
单批部署是完整的更新版本,业务将中断,并且无法进行停机维护和验证。
批量检查CS 服务,并通过SLB 端口公开该服务部署的CS 服务。CS 服务中有多个容器组副本。当需要对应用程序进行大修时,理论上只需要替换容器组副本的内容。具体操作主要涉及负载的控制。CS 服务的容器组副本需要在版本维护开始时删除负载,并在维护完成并通过测试后自动添加负载。
在DEMO 描述和验证中,只能批量部署多副本应用程序(滚动部署)。在v1 和v2 的过程中,需要验证是否按要求删除和增加了负载,如果v2 版本存在问题,验证系统自己的处理方法,验证容器服务是否正常,然后进行部署批量升级到v2 版本。在执行期间,容器组将等待新版本启动,然后替换旧版本。应用程序本身可以通过设置批处理间隔来有效地完成不间断维护。在此过程中,可以随时启动回滚操作。验证在容器启动失败,上载失败的映像v3 并启动批处理部署时,是否可以完成升级部署。可以看出,已识别出异常图像:容器本身的负载也从该版本中自动删除,并且只有5 个负载地址。继续等待,看看是否触发了下一批更新。5 分钟后,仍然不会触发更新。失败的镜像无法正常释放。此时,可以将所有副本回滚到原始版本。完成后负载将还原到6 个节点。最终结论是容器服务的批量部署可以完成不间断的维护要求。
通过对试点业务系统不间断维护工作的研究,提出了云平台维护工作的内容,对云平台维护方法进行了合理性评估,并将云平台Devops 解决方案与非平台维护相结合。从业务系统的服务角度出发,对应用程序发布的看法,提出了在服务不停止,用户不知情的情况下云平台维护工作的策略和实施方法,进一步规范了操作流程和实施计划以及准备现有维护对象维护过程的方法。下一步将对云平台微服务应用程序的整个生命周期管理系统进行研究。