本次最佳实践将为您介绍行业云多Region的设计思路和场景应用。

专有云多Region概述

在专有云的使用中,大型用户系统在特定行业的属性下,会在行业内部部署一个仅在该行业中使用的云实例。该云实例不但具备专有云的属地化部署特性,还兼具公有云按照用户需求提供云服务,以及按照服务用量计费的使用需求,该形态定义为行业云属性。

在行业云中,涉及到的大规模或跨多个地域的云平台部署场景,在不同的地域、数据中心部署业务需要解决以下问题:

  • 行业云的中心节点需要解决各个不同地域的云资源统一管理问题:权限分配要符合用户的实际使用场景和组织架构。
  • 高可用性:当某个数据中心出现故障或灾难的时候,不能影响其他数据中心对外提供服务。
  • 合规问题:多个数据中心的统一管理和权限分配等需要符合用户内部规定,以及法律法规的要求。
  • 各个数据中心之间的资源联动和共享:某些应用或业务的访问很难在同一个数据中心内部独立实现,需要跨多个数据中心协同工作和访问。

通过专有云的地域(Region)逻辑,来解决大型用户的多个数据中心部署的问题。根据地理位置,把某个地区的基础设施服务的集合称为一个专有云的地域(Region)。地域可以按照多种维度进行划分,通常按照数据中心所在的城市进行划分,也可以按照合规要求进行划分。

专有云的各个地域是相互独立的。专有云云服务,通过地域为您提供地理位置上更接近的基础设施,用于部署各种应用,您可以选择不同地域存储数据,以满足包括法规遵循方面的要求的各种需求。

阿里专有云多Region形态描述
图 1. 专有云多Reigon架构整体示意图
专有云多Region架构整体示意图

专有云地域(Region)的设计为了满足客户多地域部署一个专有云实例的需求,在架构设计上分为中心Region和普通Region。专有云多Region具有以下特点:

  • 一个云实例:提供统一管控,统一运维,以及统一监控的能力。
  • 一致性:与阿里云公共云的架构保持一致。
  • 兼容性:向前兼容单Region的部署形态,向后支持多Region的扩展部署。
  • 可用性:故障域隔离,当中心Region出现故障的情况下,不影响云平台已申请云实例资源的使用。当普通Region出现问题的情况下,不影响其他Region的使用。
多Region的部署架构
图 2. 多Region架构的部署示意图
多Region架构的部署示意图

天基(Tianji)是一套自动化数据中心管理系统,管理数据中心的硬件生命周期与各类静态资源,为各种云产品应用及服务提供通用的版本管理、部署、热升级方案。

每个Region部署一套天基服务,天基会同步中心Region的服务变量,以供普通Region上的产品或者服务引用。

多Region架构侧重云管控层面的统一,由一个中心进行统一管理、统一运维、统一计量等。下图展示专有云多Region的整体架构,其中管控服务Apsara Uni-manager运营控制台、 业务逻辑层服务、大数据产品的开发平台DataWorks和MaxComputer的管控集群是中心化部署。基础服务的读写服务部署在中心Region,普通Region的基础服务只提供读服务,元数据库的同步通过DTS实现。普通Region只需要部署服务节点,由中心Region统一管控运维。

图 3. 多Region的逻辑架构
多Region的逻辑架构

云管平台总体概述

混合云管理平台分为租户级云管理平台(Apsara Uni-manager运营控制台)和统一运维管理平台(Apsara Uni-manager运维控制台)两个主要平台:

  • 租户级云管理平台(Apsara Uni-manager运营控制台):阿里自研支持多租户的云管理平台,为专有云各产品提供统一登录方式和使用体验,同时为阿里云平台中各个产品的用户提供资源使用入口。用户可以在Apsara Uni-manager运营控制台上进行资源开通、使用、变配、删除等日常的云产品生命周期管理,支持租户级的授权,资源集、Region、操作等做对应的用户权限管理。用户体验与阿里云公有云保持一致。Apsara Uni-manager运营控制台会在中心Region和普通Region各部署服务,既提供中心Region内的统一管理能力,也提供普通Region内的管理能力。中心Region的管控平台可以管理所有Region的资源,普通Region的管控平台只能管理本Region的资源。在中心Region管控平台单产品服务宕机后,普通Region管控平台依旧可以对外提供服务。但是如果普通Region跟中心Region断开连接,普通Region内的管控平台将无法登录。
  • 专有云统一运维平台(Apsara Uni-manager运维控制台):阿里云自研的运维管理平台,为TAM驻场人员、用户的运维团队提供专业、统一的运维体验。通过Apsara Uni-manager运维控制台,可以对云平台后台的物理设备、云服务资源、服务状态、资源水位、告警数据等诸项目最运维的统一操作。
多Region下的用户权限分级模型

多Region架构下的用户使用权限模型,该权限模型覆盖了用户在多Region架构下的云管理员对Region级别的资源的操作使用权限,包括租户级运管平台Apsara Uni-manager运营控制台和运维平台Apsara Uni-manager运维控制台两个产品的权限模型。

分权分域管理包括两个层面的内容:

  • 云资源使用和维护层面:拥有一个地域资源管理权限的管理员只能管理自己所辖地域的设备以及使用相关的功能,不能管理其他地域的资源和设备。
  • 业务和数据配置层面:各个管理地域的管理员只能管理属本地域的业务和数据等资源,未得到授权时不能查看、修改其他地域的资源。
分权分域管理有以下特点:
  • 提供了集中管理方式下的分域协作功能。
  • 有助中心Region和普通Region以省为单位建设、跨本地网部署、资源共享和协同管理,节省配套投资。
  • 通过资源和权限灵活匹配,可以灵活适应维护管理模式,如Region中心化管理或边缘Region自治管理可以灵活切换和配置。
  • 充分利用地域运维资源,提高地域运维效率,减轻中心Region所在的地域的产品使用和运维压力,从而优化跨地域协作的运维流程。
图 4. 多Region架构下的用户运营和运维管控台权限模型
多Region架构下的用户运营/运维管控台权限模型

如上图所示,横向为Region部署,纵向为组织和人员的权限分配,对不同的Region进行不同的权限分配,分为下面两个场景:

  • 场景一:总部管理员可以根据实际的业务需求设置一个监控管理员,该监控管理员拥有所有Region的资源监控权限,通过该用户查看资源使用大屏,监控所有Region的资源水位、告警等操作。
  • 场景二:普通资源管理员和运维管理员,只有被授权Region的资源使用和运维的权限,对于未被授权的Region内的资源无任何资源管理权限。

统一运营平台租户管理设计

中心Region部署统一云管理平台Apsara Uni-manager运营控制台,中心Region管理员可以通过中心Region的Apsara Uni-manager运营控制台登录和管理中心Region。中心Region和普通Region都建设好之后,通过中心Region的管理员建立普通Region对应的组织和用户组,以及用户。为普通组织分配Region的管理权限,组织和Region可以存在一对多的映射关系。但是在实际项目应用过程中,涉及到多省份,多组织的情况,建议设置每个Region对应一个组织的管理关系。如下图所示。

图 5. 多Region架构下的用户运营管控台权限模型
多Region架构下的用户运营管控台权限模型
多Region模式下的管理方式
  • 中心Region最先部署,中心Region的管理员可以创建和删除普通Region的组织和管理员。
  • 中心Region管理员创建普通Region对应的一级组织,为一级组织分派Region的管理权限。
  • 普通Region的管理员从中心Region拿到账号后,自主进行本Region的资源管理和运营分配。
  • 普通Region管理员为本组织内部的下级组织关系的维护负责,即:本组织内部的下一级组织关系,由本Region的管理员创建和维护。
  • 普通Region内的下级管理员由本Region的管理员创建和分配资源使用权限。
  • 本Region关联的组织下包含的用户,能且仅能使用本Region内部的资源,不能访问其他未被授权的Region的资源。
组织和租户的授权管理方法

如下图所示,中心节点的管理员,可以对root下的一级组织授权特定Region的资源管理权限。被授权的Region仅能被该组织使用。

图 6. 对组织进行Region级别的授权操作
对组织进行Region级别的授权操作

对组织级别进行授权操作后,中心Region的管理员为该组织分派一个初始的管理员账号,分派给对应Region的人员进行使用。

被分派的组织接收到Region的授权账号后,对该Region进行单独的组织内部划分和管理。

图 7. 对组织内部进行账号管理
对组织内部进行账号管理
租户的权限模型设计

专有云的Apsara Uni-manager运营控制台权限模型设计如下图所示。

图 8. Apsara Uni-manager运营控制台的权限模型
ASCM的权限模型
  • 专有云多Region为单个云实例的模式,对应到下级组织为一级组织,一级组织之间是平行并列关系。
  • 每个一级组织下可以设置下级组织,下级组织最多设置5级,一级组织的管理员可以根据业务的实际需要,定义和设置下级组织的详细信息以及管理员权限。
  • 在Apsara Uni-manager运营控制台中设置权限管理模块,权限管理模块可以对组织进行授权,首先把特定Region的管理权限绑定到指定的Region上;其次可以对一级组织内部的资源实例进行授权,分配到资源集下。
  • 资源集即组织内部进行分配,将资源与下级组织进行配对使用的一个集合。
  • 下级组织可以嵌套设置资源实例的管理权限,可以分配用户组、用户、资源集。

统一运维平台Apsara Uni-manager运维控制台架构设计

环境描述

Apsara Uni-manager运维控制台产品本身支持单Region和多Region架构的部署形态,在单Region形态下,即中心Region,Apsara Uni-manager运维控制台管理本Region的云平台资源;而在多Region情况下,Apsara Uni-manager运维控制台可以管理多Region的资源。

软件描述

Apsara Uni-manager运维控制台是⼀套专有云的运维管理系统,主要面向专有云的运维管理人员,如驻用户现场的阿里云专有云运维工程师、用户侧的运维工程师、云平台运维管理工程师、运维安全管理或审计人员等。通过Apsara Uni-manager运维控制台,运维工程师能够及时掌控系统运行状况,并进行相应的运维操作。

运维平台(Apsara Uni-manager运维控制台)的多Region权限模型

Apsara Uni-manager运维控制台在中心Region部署,每个普通Region部署独立的运维管控台。

图 9. 多Region架构下统一运维管控台(Apsara Uni-manager运维控制台)的操作权限模型
多Region架构下统一运维管控台(ASO)的操作权限模型

如上图所示:

  • 多Region部署模式下,中心Region最先部署,中心Region的管理员可以创建和删除普通Region的组织和管理员。
  • 多Region模式下,中心Region管理员可以创建普通Region的实体,并为实体分配Region的管理权限。
  • 多Region模式下,普通Region的管理员从中心Region拿到账号后,自主进行本Region的资源运维操作。
  • 普通Region管理员为本组织内部的下级组织关系和人员账号的维护负责。
  • 普通Region内的下级管理员由本Region的管理员创建和分配资源使用权限。
  • 本Region关联的实体下包含的用户,能且仅能对本Region内部的资源进行运维操作,不能运维其他未被授权的Region。
Apsara Uni-manager运维控制台的账号权限体系

Apsara Uni-manager运维控制台的账号体系模型区分为多级组织,多级部门和多个角色操作集。

图 10. Apsara Uni-manager运维控制台的账号体系模型
ASO的账号体系模型
名称 描述
组织 用户使用的所有人员、操作、权限的集合。
用户组 多个用户的集合。
用户 指运维系统的管理员和操作员。
角色 通常情况下,角色可以理解为⼀系列权限的集合。一个角色内可以包含多个角色单元或多个角色。权限系统中,一个角色可以包含其他角色,形成角色嵌套。
角色单元 权限点的具体描述,一个角色单元由资源、操作集合和授权选项组成。
多Region下Apsara Uni-manager运维控制台权限分配操作
  1. 在Apsara Uni-manager运维控制台中建立和用户对应的组织部门关系。
  2. 在组织中创建用户。
  3. 创建一个角色,归属给一个角色单元。
  4. 为角色单元分配资源的权限和操作集。资源包括某个特定Region的资源操作权限。
多Region下运维操作指导

场景1:中心Region运维人员通过管理员账号登录中心Region的Apsara Uni-manager运维控制台查看所有Region的运维情况。

  1. 中心Region的运维管理员登录中心Region的Apsara Uni-manager运维控制台。
    管理员可以查看运维大盘和所有Region的资源情况。
    图 11. Apsara Uni-manager运维控制台通过切换Region对不同Region进行运维操作
    ASO通过切换Region对不同Region进行运维操作
  2. 通过切换Region操作,可以从中心Region跳转到其他Region的Apsara Uni-manager运维控制台上,对其他Region做需要的运维操作。
    图 12. 切换Region后对本Region进行运维管理
    切换Region后对本Region进行运维管理
  3. 对云产品的运维操作,可以通过跳转到对应Region的云产品运维管控台做对应的运维操作。
    图 13. 通过Apsara Uni-manager运维控制台对本Region内的云产品进行运维操作
    通过ASO对本Region内的云产品进行运维操作
  4. 本操作中以RDS杜康的运维管控台操作举例。在对应Region下单击杜康,可跳转到对应Region的杜康控制台上做运维操作。
    图 14. 以杜康为例对云产品进行运维
    以杜康为例对云产品进行运维

场景2:普通Region的管理员登录本Region的Apsara Uni-manager运维控制台管理界面,对本Region内的资源做运维操作。

普通Region管理员登录本Region的Apsara Uni-manager运维控制台后,没有权限查看其他Region的资源。

对云产品的运维操作:可以通过Apsara Uni-manager运维控制台跳转的方式登录普通Region云产品运维管控台。

登录本Region云管控台,单击产品运维中对应的产品管控台进行跳转。

目前已经支持单元化部署方式的控制台。

图 15. Apsara Uni-manager运维控制台管理的多Region架构下的云产品运维管控台
ASO平台管理的多Region架构下的云产品运维管控台

数据中台运维系统多Region最佳实践

阿里大数据平台使用的是一站式大数据运维平台,大数据管家(原名BCC)。可以对MaxCompute、DataWorks、Blink、DataHub、Quick BI等组件进行日常运维与管理工作。

图 16. 数据中台组件的架构图
数据中台组件的架构图

大数据管家的架构大致可以分为三层,从底至顶分别为基础管控、运维中间层和组件运维。

  • 基础管控是与各大数据平台组件的管理节点、计算节点交互的环节,通过SDK、命令行工具、日志采集等多种手段进行基础的运维管理操作。
  • 运维中台为通用服务层,提供常见的命令下发、定时调度执行、配置下发、网关注册等服务,方便顶层运维功能实现。
  • 组件运维是面向终端运维工程师的一层,包括了Web界面。在这层完成了包含各组件运维场景的封装与组合,如监控告警、资源配额组管理、指标趋势、配置管理等功能,让运维工程师可以直观、高效地完成日常运维工作。
数据中台运维体系多Region架构

数据中台组件中,MaxCompute、DataWorks、Blink、DataHub都可以理解为单元化部署,中心化管控。在中心Region部署的大数据管家上,有能力管理中心Region以及各个普通Region的组件。

数据中台运维多Region的权限模型

下图所示为大数据管家(BCC)的权限和使用模型。

图 17. 大数据管家(BCC)的权限和使用模型
大数据管家(BCC)的权限和使用模型
  • 大数据管家当前的使用方式为中心化部署,在中心Region可以登录大数据管家BCC的运维控制台。
  • 创建中心Region的大数据运维管理员和对普通Region的大数据管理员做授权操作。
  • 普通Region的管理员通过获得中心Region管理员授权的账号,从中心Region的Apsara Uni-manager运维控制台登录大数据管理平台。
  • 普通Region的管理员能且仅能对授权的Region进行大数据运维管理操作。