当前位置:首页 期刊杂志

基于OpenStack的云管平台架构设计与实现

时间:2024-05-04

叶远清

(广州市第十二人民医院 广东省广州市 510620)

现代化智慧医院需要部署众多信息系统,为充分利用物理服务器资源,通常采用虚拟化平台创建虚拟机进行部署,但商业的虚拟化平台费用高昂,一种替代方案是采用开源虚拟化平台OpenStack。OpenStack 的基础核心服务如虚拟机管理、虚拟网络构建、块存储管理等都很成熟稳定,但平台自带的控制面板服务Horizon 功能过于简陋,其Web 操作界面并不能满足生产环境的使用要求,如缺乏灵活的权限配置、缺乏订单计价体系、监控体系不完整等[1]。为了解决以上问题,本文基于OpenStack 设计了一套云管平台,通过OpenStack 的RESTfulAPI 接口,将底层云化管理的工作依托于OpenStack 实现,而上层的业务相关操作控制台则重新搭建。

1 OpenStack技术体系分析

OpenStack 是由美国国家航天局NASA 和Rackspace 共同发起的开源云计算软件,由OpenStack 社区共同维护,提供IaaS(InfrastructureasaService)层服务,常用于企业搭建私有云平台。通过OpenStack,可以对计算、存储、网络等基础设施物理资源进行虚拟化管理[2],并以服务的形式提供给用户或者PaaS(Platform as a Service)层服务使用。

经过开源社区多年发展,OpenStack 软件日趋完善,目前已经发布22 个稳定版本,核心服务都已非常稳定。各核心服务的逻辑关系[3]如图1所示。

Nova:计算虚拟化管理服务,管理虚拟机的整个生命周期;Neutron:网络虚拟化管理服务,为其它服务提供网络连接;Cinder:块存储管理服务,为虚拟机提供块存储;Swift:对象存储管理服务,为其它服务提供对象存储管理,如为Glance 提供镜像存储服务,为Cinder 提供卷备份管理服务;Keystone:认证管理服务,为平台提供身份认证和访问策略;Ceilometer:测量管理服务,为计费和监控以及其它服务提供数据支撑;Glance:镜像管理服务,提供虚机镜像上传、检索、管理服务;Horizon:控制面板服务,为其它服务提供Web 界面管理,简化用户操作。

2 系统设计

经过对需求的收集和甄别,确定整个云管系统需要如下子系统:

图1:OpenStack 核心服务逻辑关系

权限子系统:灵活地对用户、角色赋权,管控资源访问;用户子系统:按部门、角色管理用户;计费子系统:对各用户和部门的资源使用计费;价格子系统:对资源标定价格,对订单做总价核算;订单子系统:对资源创建形成订单,加入审批流程;搜索子系统:对资源、订单、日志、监控信息检索和分类;安全子系统:接入安全产品,如WAF、防火墙、日志审计等;设备子系统:方便地添加物理服务器,扩容平台计算节点;VPN 子系统:提供VPN 接入服务;镜像子系统:管理系统镜像;监控子系统:管理各种监控信息;日志子系统:收集分析各类服务日志。

在用户层面,提供浏览器和手机APP 两种使用方式,同时管理员和租户分别使用管理端控制台和租户端控制台。整个云管系统设计如图2所示。

3 架构设计

鉴于整个系统较复杂,功能繁多,本系统采用分层与微服务相结合的架构[4],设计如图3。

图2:云管平台系统设计

图3:云管平台架构设计

整个系统分为界面表示层、接口汇聚层、应用业务层、数据层和云化层。

界面表示层是用户入口,处理界面展示和操作相关功能,采用VUE 框架实现;接口汇聚层是网关,统一管理与前端的API 接口。应用业务层实现具体的业务逻辑,包含各个子业务的具体实现,架构设计上采用微服务架构,基于SpringCloud 微服务框架,各微服务通过基于http 协议的RPC(Remote Procedure Call 远程过程调用)进行交互。

应用业务层包括多个微服务,每个微服务实现一个对应的子系统,如:Account Service 实现用户子系统,Order Service 实现订单子系统,Search Service 实现搜索子系统,Monitor Service 实现监控子系统,Device Service 实现设备子系统,Security Service 实现安全子系统等等。

其中特别的是Cloud Service,该微服务位于其它Service 与OpenStack 平台之间,作为其它Service 与OpenStack 的沟通桥梁。Cloud Service 微服务通过RESTfulAPI 接口与OpenStack 交互。为了明确云管平台与OpenStack 的技术边界,方便后续开发维护,只有Cloud Service 才与OpenStack 交互,其它微服务通过Cloud Service 与OpenStack 交互。通过这种隔离设计,在系统内构建一层云化抽象层,只需调整Cloud Service 即可应对OpenStack 的接口变动。

应用数据层负责业务数据的存储和管理,采用Mysql 负责持久化存储,Redis 负责缓存管理,ElasticSearch 则处理需要检索的各类数据,如日志、监控数据、资源明细等等。应用数据层只负责应用业务数据的存储和处理,不包括OpenStack 平台的数据。

云化层是独立部署的OpenStack 平台,为整个系统提供计算、网络、存储等资源的虚拟化管理,相关功能都通过丰富的RESTfulAPI 接口提供给CloudService 调用。

4 结论

本云管平台在系统功能层面添加了账户、订单、计价、权限、搜索、安全等功能,已能满足大部分生产环境需求。在架构设计上采用了分层+微服务的模式,带来如下好处:

(1)界面表示层与接口汇聚层分离:界面表示层独立开发、部署、测试,降低了开发期团队内的沟通成本,与接口汇聚层通过API 交互,在浏览器和手机端共用一套API 接口,减少开发工作量,也便于后期维护;

(2)应用业务层与云化层分离:隔离了OpenStack 技术栈的复杂性。后续OpenStack 平台做版本升级,云管平台只需要根据OpenStack 新版本的接口变动,对CloudService 做适配修改即可;

(3)各微服务功能明确,任务单一,降低构建整体系统的复杂性;

(4)采用微服务的开发模式,开发团队管理上可围绕业务功能组建小开发团队,更加符合企业的分工和组织结构;小开发团队更加关注自己的成果,方便管理;

(5)微服务横向扩展方便,微服务实例是无状态的,状态信息保存在应用数据层,灵活地增减微服务实例即可扩展/缩小系统的处理能力,弹性应对实际使用环境;

(6)微服务结合docker,方便容器化[5],结合K8S 平台,统一编排,更加方便运维。

采用分层+微服务架构,小版本更新不影响业务连续性,只需要启动新版本微服务,再关闭老版本微服务即可。随着系统实施,功能增多,微服务间调用关系越来越复杂,如何让调用关系更可控合理,是下来要优化考虑之处。

免责声明

我们致力于保护作者版权,注重分享,被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自各大过期杂志,内容仅供学习参考,不准确地方联系删除处理!