HORIZON
HORIZON
基于AWS的混合云管理及DevOps协作平台

混合云管理

统一管理不同来源的主机

  • 支持导入各种公有云主机、私有云主机及物理机
  • 提供多种导入方式(自动、手动、批量导入)
  • 按应用角度分集群、分组管理所有导入主机
  • 集成云API,支持动态创建并导入,支持自动伸缩

自动化运维

高效运维集群化管理

  • 对集群、虚机组或者虚机批量执行脚本
  • 多种方式(按需、定时、告警触发)执行脚本
  • 集中查看脚本执行状态、结果及历史记录
  • 统一管理各种运维脚本,方便运维各环节复用

监控告警

端到端的监控,实现快速反馈

  • 提供虚机、站点、端口监控
  • 支持应用级别的自定义监控
  • 提供集群和虚机组级别的监控数据展示
  • 支持多级别告警定义,告警状态展示

自服务IT

自助获取IT资源,加快云上的开发和测试

  • 一键创建或释放应用系统所用云资源
  • 自动执行用户定义逻辑,完成云资源初始化
  • 统一管理自助IT资源申请、使用及开销情况
  • 支持自定义镜像

持续部署和交付

DevOps协作平台,加快云上业务创新

  • 对接常见代码构建工具,实现统一的Artifacts管理
  • 兼容AWS CodeDeploy规范,支持不同部署策略
  • 可视化整个部署过程,实时展示部署进度及结果
  • 统一开发、测试、准生产和生产环境的部署和管理

自动化运维

高效运维集群化管理

  • 对集群、虚机组或者虚机批量执行脚本
  • 多种方式(按需、定时、告警触发)执行脚本
  • 集中查看脚本执行状态、结果及历史记录
  • 统一管理各种运维脚本,方便运维各环节复用

HORIZON功能列表

功能 通用版
资源管理
AWS
阿里云
服务器管理
缓存管理
数据库管理
LBS
存储
脚本管理
容器资源池
任务队列
运维平台
用户管理
权限管理
菜单管理
接口管理
审计管理
事件管理
发出的事件
收到的事件
事件模板管理
事件搜索
流程管理
流程列表
流程模板
我的任务
我的流程
项目管理
项目管理
项目设置
拓扑展示

1. 容器化的持续交付系统(基于AWS部署,但非ECS)

设计目标:

提供一个连通线下开发测试与线上产品发布的容器化持续交付平台,并对于托管在该平台上的已发布产品进行完整的生命周期管理。

持续发布以及基础构架的一致性

目前我们容器化的产品发布采用持续交付策略,并且对于构建以及测试是使用线下数据中心的计算资源进行,线下的产品构建以及测试发布环境需要与线上保持完全一致,所以对于线下数据中心我们也提供了部署容器化的持续发布基础构架,与线上保持一致。

细粒度的资源调度策略

由于现有ECS是基于已采购的实例上进行容器化,我们就需要考虑到对于底层VM在成为容器池后的资源二次分配问题,比如有的容器封装的service是CPU intensive,那么我们希望这些CPU intensive的服务不会被调度在同一个VM上,同理,比较消耗带宽的容器化service们也会通过策略使其避免重叠(Anti-Affinity)。对于有相关性的services我们希望其尽可能的被deploy在一起(Affinity)。对于有些VM资源是用来进行测试目的的,那么我们希望能够尽可能的充分使用其计算资源(packaging),对于对外部用户提供服务的容器我们希望能够尽可能的进行workload balance(stripping)。

多租户相关

1)资源隔离与限制:

由于多BU的存在,考虑到成本核算问题,线上的共享容器资源池会根据各个BU的计算能力预估进行资源分配,并且由于目前容器化在安全与隔离性上存在先天的缺陷,所以当不同BU的产品在容器池中进行部署时我们会尽可能的将其schedule至为其BU划分的实例上,同时也会为每一个BU设定其resource quota防止超出。
另外一种资源限制方式是针对OS对于cgroup的resource limit超出时存在的OOM kill行为,我们会为VM设定一个总的resource limit,只有当总的limit达到后,才会触发OOM Kill,这样尽可能的减少服务被kill的几率。

2)资源共享与Reclaim

考虑到某些服务在高峰时或者灰度发布时会占用额外的资源,同时考虑到cost saving和时间开销,我们不会轻易的申请额外的VM资源加入容器池,如果此时有其他BU的空闲计算能力,调度系统会借用其资源来deploy 容器。但是当被借用的BU有额外的计算需求时,则被借出的资源将被reclaim。

服务编排与灰度发布

我们的服务在自动化发布以及灰度更新时,不是全部并发完成的,很多服务间存在启动依赖顺序,所以我们需服务编排与灰度发布能力的基础构架,这个功能不是独立的容器化服务能够解决的问题,需要借用独立的编排工具,同时也存在定制化在里面。

服务发现

1)发布时的服务发现:

之前提到的服务编排,就是在被依赖的容器里的服务启动后,相关依赖服务才能启动,并不意味着容器状态变为running就可以,同样,在容器需要被kill掉前,为了保证内部作业的完整性,需要保证只有作业完成后容器状态才能变更。所以我们会在容器里设置一些脚本,比如:preStop,postStart等。

2)运行时的服务发现

有些runtime的service可能由于bug等因素会导致其crash或者hang住无法提供服务,这时候需要有机制来通知基础构架,该容器可以被kill掉并进行recovery。

2. DevOps运维管理平台(AWS-based)

设计目标:

作为对AWS管理平台已有功能的补充,为企业中各个产品开发团队提供一个统一的运维管理平台,整合项目、资源,公共服务,提供一站式DevOps服务。同时引入流程体系与认证管理系统,保证了各个团队能够灵活安全的自助式管理所分配的AWS资源以及对应产品的运维操作。

针对开发团队

1)基于项目的上线发布管理系统:

产品在上线发布流程中通常会引入多个不同角色的共同参与,如测试发起,运维执行,测试验证,PO确认等不同的角色在不同的环节需要介入,通过该平台可以平滑的讲各个不同角色通过流程管理体系进行串联,并可以针对不同的产品团队,风险级别进行自定义,保证了上线流程的完整性。同时,以可视化的方式对线上产品的部署进行展现,并可以针对组件个体进行参数修改、独立发布等功能。

2)基于项目的资产申请与修改变更管理系统:

通常当产品团队需要对线上项目中的资产进行变更时,会通过运维团队进行费用预估,之后会发送领导以及财务进行审批。通过该平台,产品团队在触发资源变更后,平台会自动生成预算账单,并自动发起审批流程,通知流程相关人员,从而提高生产效率。

3)公共服务管理:

该平台将常用的AWS服务根据我们已评估的计算能力进行了封装,开发团队只需填写对于所申请服务的期望计算量即可而无需关心其内部申请细节,以缓存服务Redis为例,用户只需输入项目中对于该服务所期望的QPS,MEM,SLA,Region以及backup信息,系统会根据已测试的数据进行优化选择实例类型、数量,高可用等参数,并自动生产账单信息,之后会触发审批流程。

针对运维管理团队

1)批量作业执行:

对于管理大批量机器的运维团队来说,通常需要在各个区域的相同类型机器上执行相同的脚本(or 作业),比如漏洞修复,安全扫描或是清理任务等。常规的批量执行方式会通过脚本,远程无密码登录等方式进行,这样就很容易留下漏洞,或者一旦执行命令出错,就有可能造成无法挽回的损失(比如携程事件)。所以对于批量作业执行系统来说,需要对所执行的作业根据风险程度进行严格的管控,并且引入流程与review体系,对于危险任务的执行,需要进行审核方可继续执行,若审核不通过,则具有风险的作业无法被执行。

2)安全漏洞扫描:

该平台集成了基于主机的安全扫描与基于开放端口的安全扫描系统,可以制定计划任务定期检查。

针对产品决策层

1)成本分摊:

以图形化的方式对各个部门不同产品的成本构成进行直观的展示,包括计算,网络,存储,数据库服务等维度。帮助PO与决策层更清晰地了解当前产品的成本构成,从而可以进一步进行相关的优化。

2)利用率展示:

结合监控系统,对各个部门不同产品的计算资源使用进行统计,以图形化的方式进行直观的利用率展现。

3)项目管理:

项目管理人员针对不同的项目进行用户权限于角色设置,变更后的设置会体现在流程、审批以及部分受限制的功能点上。

HORIZON
Copyright © 2016 Yeahmobi | All Rights Reserved
  • 技术白皮书:以应用为中心的企业级混合云管理
  • 邮件: chieh.zhu@yeahmobi.com
  • 客服QQ: 30904909
  • 西安地址: 高新区高新路2号西部国际广场西座6楼