阿里云云栖社区

“云栖社区”是阿里云官方开发者技术社区,聚焦于传播云计算、大数据等DT时代核心技术的内容与资源。...

从单租户IaaS到多租户PaaS——金融级别大数据平台MaxCompute的多租户隔离实践

摘要:在2017年云栖大会•北京峰会的大数据专场中,来自阿里云的高级技术专家李雪峰带来了主题为《金融级别大数据平台的多租户隔离实践》的演讲。在分享中,李雪峰首先介绍了基于传统IaaS单租户架构做隔离时面临的问题;然后,他重点分享了MaxCompute PaaS层面的多租户的架构以及MaxCompute在安全隔离方面的具体实践。
点此查看原文:http://click.aliyun.com/m/42755/

在2017年云栖大会•北京峰会的大数据专场中,来自阿里云的高级技术专家李雪峰带来了主题为《金融级别大数据平台的多租户隔离实践》的演讲。在分享中,李雪峰首先介绍了基于传统IaaS单租户架构做隔离时面临的问题;然后,他重点分享了MaxCompute PaaS层面的多租户的架构以及MaxCompute在安全隔离方面的具体实践。

IaaS单租户大数据产品架构

图片描述

基于IaaS单租户大数据产品架构如上图所示,架构底层通常利用HDFS2实现;基于HDFS2之上搭建Hadoop Yarn或MESOS等资源管控平台;在其之上再实现具体的计算模型,如MR、Hive、HBASE以及Spark等。在这类生态环境中,IaaS平台通常作为同一租户存在,当用户产生新需求时,通过IaaS平台申请一批集群(虚机),再这些集群上部署相应的开源产品。从隔离的角度出发,这种生态面临以下问题:

首先,IaaS单租户大数据产品架构在实际使用时存在一定的逻辑问题。使用者进行数据分析时,需要了解使用的每种产品的具体逻辑,例如运行SQL时,需要理解Hive的逻辑,使用Spark时,需要学习spark的相关知识。当使用产品数量较少时,使用成本还能够得到有效控制;当需要多种产品相互协助使用时,学习成本便成几何倍数增加。并且,通常两款不同的开源产品之间的逻辑模型相互间无法识别,当遇到鉴权等问题时,逻辑问题更加突出。

其次,每一种开源产品在运行级别上都有其自身的优先级定义。在使用同一种开源产品时,任务的优先级会按照开源产品自身的优先级体系进行运行,高优先级的任务会比低优先级的任务得到更多的资源,运行的时长也会得到更好地保障。当同时使用多款开源产品时,基于IaaS单租户大数据产品架构无法做到运行优先级的全局最优化。

最后,上述这些开源产品通常会提供用户自定义逻辑,例如MR或Hive提供的UDF。当用户自定义的代码在大数据产品内运行时,会造成一定的安全风险。例如,Hadoop Yarn在运行用户自定义代码时,仅仅使用比较简单的Linux Container机制进行隔离。使用这种机制运行隔离时,用户的代码逻辑和Hadoop自身进程是运行在同一个内核(kernel)下的,也就是说如果这部分用户代码逻辑包含的攻击程序能够影响机器kernel,则在同一个内核下运行的大数据产品进程也会随之受到影响。通常情况下,大数据产品的一个Job会根据数据分片的大小同时运行在集群的大部分机器、甚至所有机器上。这种情况下,安全的风险便放大至整个集群。一种极端的情况是:当利用一个内核的漏洞攻击一台机器成功时,当所提交的Job分片足够大时,可能会使得整个计算集群瘫痪。

在认识到上述问题之后,MaxCompute通过独立自研整体系统架构,提供了PaaS层面的多租户能力。

MaxCompute PaaS多租户架构

图片描述

上图是MaxCompute PaaS多租户架构示意图。从图中可以看出,MaxCompute运行在飞天操作系统上,依赖于飞天伏羲模块提供统一资源管控;依赖于飞天盘古模块提供统一存储;依赖于飞天女娲模块提供一致性服务。MaxCompute通过提供同一套计算引擎为上层提供了多种计算形态,包括SQL、MR、图计算、PAI、准实时等。

图片描述

目前,这套计算引擎已经为金融用户在公共云上提供了相应的计算能力。

图片描述

在解决MaxCompute多租户这一问题时,主要是从三个角度入手:

一是逻辑隔离。从租户的角度出发,每个租户都有自己独立的逻辑模型,拥有自己独立的资源以及基于相同的逻辑模型实现的统一授权模型。

二是资源隔离。对于不同租户的任务,在MaxCompute运行时,能够实现统一的、全局最优的任务调度能力以及资源隔离能力。

三是运行隔离机制。目前,MaxCompute提供了用户自定义逻辑的功能(如Python UDF),为用户自定义逻辑在MaxCompute上运行提供了一套完善的运行隔离机制。

下面来具体分析下MaxCompute提供的这三种隔离机制。

MaxCompute 逻辑隔离

目前,对于同一个MaxCompute实例,无论其运行在多少个物理集群上,都能在逻辑层提供统一的租户体系。对于这套租户体系,同一个租户的数据资源视图和权限管理模型是唯一的,并与租户模型绑定。在实际使用中,MaxCompute上的租户对应于MaxCompute的Project,其中Project包含租户所有的资源、属性以及权限等信息。

图片描述

如上图所示,Project由属性(Properties)、主题(Subject)、实体(Object)三部分组成。其中属性包括Quota、Owner、Payment Account、Region等信息;在Project内部所有的授权访问都需要以User ID为主题,基于这些主题,MaxCompute提供了角色模型用于实现授权聚集;上文所提到的计算模型(MR、Hive等)要操作的资源最终都落脚于Project中的某一实体上,例如SQL模型对应于Table实体、UDF对应Function实体。

图片描述

基于以上提供的逻辑模型,MaxCompute提供了一套完整的鉴权、授权机制用于管控权限。首先,所有权限均来源于Project Ower,作为Project的所有者,它拥有该Project内的全部权限,任何用户使用该Project进行计算时,首先需要Project Owner对其进行授权(具体实现是利用GTANT语句);当该用户访问Project时,它会以User ID的身份进行读写表、创建函数、添加删除资源等操作;这些操作被真正执行之前,会通过统一的ACL逻辑对当前User ID是否具有相应的权限进行判断。

图片描述

上图给出了MaxCompute对不同类型对象支持的操作方式,更多详细操作说明请参考官方文档。

MaxCompute 资源隔离

MaxCompute 的计算引擎依赖于飞天操作系统提供资源运行、隔离能力。

图片描述

如上图所示,当不同任务Job-0、Job-n 提交到飞天伏羲模块时,伏羲的调度系统会根据不用用户的运行级别来分配任务的运行级别,这与上文提到的Project中的属性相对应。伏羲模块将不同的任务Job-0、Job-n转化为伏羲任务;然后调度到计算集群的节点上;最终在计算集群上,同一个server上会同时运行多个租户的任务,这些任务均以伏羲Worker形态运行。

图片描述

对于其中的一台机器,当该机器上的伏羲引擎收到Worker Plan后,它会根据Worker所对应用户的quota值去配置当前这台机器上的Cgroup的参数。这样一来,就保证不同用户提交的Job最终在物理机上运行的Cgroup配置参数不同。目前,MaxCompute依赖于Linux Kernel提供的Cgroup能力来规划某个特定进程在物理机上所得的CPU、Memory等资源。

MaxCompute 运行隔离

最后来分析下MaxCompute为了安全运行用户自定义逻辑所提供的运行隔离机制。当伏羲运行用户自定义代码逻辑时,它会拉取一个隔离的环境,把用户的代码运行在隔离的进程中。该进程对与伏羲而言与其他进程无差别,但其运行环境是在隔离系统中;也就说对于伏羲而言,这个进程是普通的进程,但对于untrusted code进程是隔离的。

运行隔离又可以分为进程隔离、设备隔离和网络隔离。

进程隔离

图片描述

在进程隔离方面,对于单个进程而言,如果是运行的untrusted code(有可能包括恶意攻击的代码)进程,有可能会对计算平台造成损害。针对这一问题,MaxCompute提供了多层隔离嵌套方案以便规避这种潜在的安全风险。在最内部,MaxCompute提供了语言级沙箱,包括java sandbox和python sandbox,这种语言级别的沙箱为用户代码提供了最内层的隔离,例如java UDF 目前可以做到限制加载具体的类,python UDF可以做到函数级别的限制;外面一层,MaxCompute提供了进程隔离,它依赖于当前Linux Kernel提供的内核机制实现进程的隔离,使用的内核机制包括namespace、cgroup 、secomp-bpf等;最外侧,MaxCompute实现了一层轻量级的虚拟化,它的实现原理是通过深度定制Linux Kernel以及一个最小化的Hypervisor,进而提供非常轻量级的虚拟机(建立时间仅为几百毫秒)。这样一来,untrusted code最终会以hypervisor方式运行在物理机;也就是说,对于伏羲而言,它看到的仅仅是hypervisor的进程,但对于untrusted code,它看到的是一套隔离环境。

设备隔离

图片描述

除此之外,MaxCompute也为用户自定义代码提供了硬件加速能力,例如PAI是支持直接GPU访问。目前,MaxCompute通过PCIE passthrough方式将GPU卡直接passthrough到VM内部,允许guest进程直接通过PCIE总线以及guest kernel 内的GPU driver来访问GPU。

这种VM通过PCIE总线访问GPU的实现方式相较于在物理机直接访问GPU,性能相近;另一方面,在物理机上无需安装GPU driver,规避掉了GPU driver对平台稳定性和可靠性影响。

网络隔离

图片描述

在某些产品上,MaxComputer为用户代码逻辑提供了网络隔离能力。在伏羲拉起的VM之间实现了一层虚拟网络。这些VM可以通过虚拟网络进行直接通信,这也为在VM内部运行一些开源代码提供了良好的兼容性。同时,从上图可以看到,用户自定义的代码逻辑并不是直接访问物理网络的;而伏羲拉起的tursted code包括MaxCompute框架上的代码是通过物理网络进行通信的,这种做法保证了MaxCompute框架在通信上的低时延。

阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/yunqiinsight/article/details/80133972
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭