• 1. 云计算中的多租户与多租户架构 Richard Yu xiaoqingfeng@yeah.net 2018年10月15日
  • 2. 什么是多租户(Multitenancy)“多租户”的概念最早起源于软件领域,指一个软件实例服务于多个用户的架构。每个用户称为一个租户。http://en.wikipedia.org/wiki/Multitenancyhttp://whatis.techtarget.com/definition/multi-tenancy
  • 3. 云计算中的多租户“多租户”也是“云计算”的基本属性之一。云计算的三种服务层次——SaaS、PaaS和IaaS均体现了对“多租户”不同的支持。SaaSPaaSIaaS出租的资源举例说明 软件的使用权。 典型如:电子邮件系统。用户(租户)拥有使用账号。租户登录使用系统。软件开发平台资源(如开发支撑系列工具,应用存储空间,运行容器,平台服务等等)。如:某租户拥有1G应用存储空间,应用容器(数量不限,总内存上限4G),2个缓存服务。硬件基础设施(如CPU、内存,存储,IP,网络设备等等)。如:某租户拥有2颗CPU,8G内存,80G硬盘,10IP,2负载均衡器,创建主机数量不限
  • 4. 【隐藏】多租户是云计算的基本属性之一http://www.zdnet.com/blog/saas/defining-the-true-meaning-of-cloud/1160?pg=2&tag=content;siu-container
  • 5. 多租户与多租户架构应用实现对“多租户”的支持,需要相应的“多租户架构”(Multi-tenancy architecture)。在云计算时代,伴随着技术的发展, 应用的“多租户架构”获得了极大的丰富。Windows Azure VS force.com经典的多租户架构: Shared nothing Shared hardware Shared everything
  • 6. 多租户架构总览Gartner对当前云应用“多租户”架构进行了总结并给出了参考架构,如下:
  • 7. 为什么要“多租户”?“多租户架构”已经是云计算时代应用基本架构,那么,为什么采用“多租户”?它有什么优势? 事实上,“多租户”的模式并非IT独有,在我们日常生活的许多方面,均有体现。下面,我们以一个旅馆的例子,来探究为什么要“多租户”。 (Why multitenancy?)
  • 8. 一个旅馆的例子1个旅馆, 出租给多个人换个角度,多个人共租用了1旅馆的空间(资源),旅馆正在面对“多租户”。1个空间(资源)多人共用,如何划分房间(资源分配)?不划分,全部共用。 旅客共享居住空间,床铺。大通铺方案木板隔断方案划分,用木板隔离。一个隔断中容纳几名旅客。 几名旅客共享居住空间,每名旅客独享床铺。水泥墙隔断方案划分,用水泥墙隔离。一个隔断中只容纳一名旅客。 每名旅客独享居住空间,床铺。本例中,我们从居住空间和床铺两个方面考量。
  • 9. 一个旅馆的例子大通铺木板隔离水泥墙隔离释意容纳旅客数504025进行分隔时必然会消耗空间,不同方案消耗空间不同,使得等量空间最终容纳旅客数不同。旅客体验私密性差中好旅客的行动是否会被其他旅客知晓决定了私密性。分差、中、好三个等级,对应私密性由低到高。本例中,多人共享居住空间还是单人独享居住空间决定了私密性。舒适性差中好居住空间如何分享,床铺如何分享共同决定了舒适性。二者均独享的方式舒适性最好。均共享的舒适性最低。住宿价格 (元/每天)202540本例假设旅馆满员,每天计划总收入1000元。住宿价格=1000/容纳旅客数我们来评价一下按照不同划分方案划分的结果:
  • 10. 一个旅馆的例子大通铺木板隔离水泥墙隔离容纳旅客数504025旅客体验私密性差中好舒适性差中好住宿价格 (元/每天)202540高低资源利用率资源利用率 = 1 / 容纳旅客数低高旅客体验低高住宿价格旅馆视角(资源出租者)旅客视角(资源承租者)
  • 11. 一个旅馆的例子大通铺 共享居住空间、床铺 (Shared Everything)木板隔离 共享居住空间、独享床铺水泥墙隔离 独享居住空间、床铺 (Shared Nothing)资源利用率高中低租户间 共享资源多中少/无租户间 隔离性低中高单位资源 价格低中高如果再抽象一点:
  • 12. 一个旅馆的例子(结论)不难得出结论:租户间共享资源越多,基础资源的利用率越高,单位资源成本越低, 租户间隔离性越差。现在回到开始的问题: 为什么要多租户? 希望利用多租户带来的资源高度共享模式(架构),提高资源利用率,降低单位资源成本。 但,同时必须克服租户间隔离性下降给租户带来的不便。
  • 13. 不同架构差异少多租户间共享资源现在回到云应用“多租户架构”的讨论,基于刚才的分析与结论,首先分析一下各种架构,可见:随着“多租户”在应用架构中实现层次的增高,租户间共享资源也越来越多。多租户实现层次
  • 14. 不同架构差异根据之前的结论,图中架构从1-7,租户间共享资源越来越多,资源利用率越来也高,单位资源成本越来越低,租户间的隔离性越来越差。显然,租户间共享资源越多的架构,租户隔离难度越大,成本越高。租户隔离难度越大,应用开发难度,测试与维护成本都会上升。租户间隔离性降低,会导致许多问题:如数据安全性降低,租户间性能、异常相互影响等等。这些问题是应用为保证对租户的服务质量而必须解决的。这类行为业内称为租户隔离。低高资源利用率高低单位资源成本低高租户隔离成本理论上,在单位资源成本和租户隔离成本取最佳平衡点,就能找到最合理的架构。
  • 15. 业内的实践如此多的“多租户”架构,业内知名厂商是如何实践的?
  • 16. 业内的实践业内厂商“多租户架构”多集中在Shared Hardware 和 Shared Everything。 为何如此? 理论上,各厂商选择的是单位资源成本和租户隔离成本取最佳平衡点的架构。 厂商选择的“多租户”架构与其擅长的业务领域的技术积累紧密相关:SalesForce 与 Google 在Shared Everything多租户高共享架构方面积累深厚,因此其优先选择了共享程度较高、同时实现难度也较大的架构。 对于“多租户高共享”方面积累尚浅的厂商,随着虚拟化技术出现而产生的Shared Hardware架构,方案成熟,难度适中,是一个好的选择。 还有一个重要因素——租户的需求是否有共性。SalesForce的force.com实际上是面对特定领域(CRM)的,且其领域用户需求共性明显,因此,采用Shared Everything架构非常适合,且取得巨大成功。如果租户间需求没有趋同,比如租户的需求是来自多个领域的,或者同领域、但有大量定制,会使得采用Shared Everything架构十分困难。此时,选择共享程度低的架构反而是个明智的选择。
  • 17. 附录:关于PaaS“应用容器集群”EAF在策划时创造了“应用容器集群”的提法。此提法基于如下考虑: PaaS平台需要为其租户提供一个由平台管理的应用运行的环境。应用运行在应用容器中,因此,组成应用运行环境的是应用运行容器,因为有大量的容器,且会使用集群技术,因此取名“应用容器集群”。 关于“应用容器集群”的实现。 EAF原计划采用Shared OS多租户架构实现应用容器集群。即多个容器共享一个操作系统的方式。结合实际。就是一台虚拟机上,会有多于一个的应用运行容器(类似于Cloudbees)。 而常见的Shared Hardware架构, Shared Hardware架构中,一台虚拟机上只有一个应用运行容器。(类似于AWS Beanstalk、Aclome BC)
  • 18. 附录:关于PaaS“应用容器集群”对比“应用容器集群”Shared OS与Shared Hardware架构的实现 二者对比, “应用容器集群”在调度容器时, Shared OS架构实际调度的是应用服务器实例,而Shared Hardware架构实际调度的是虚拟机。在进行应用弹性伸缩时, Shared OS架构调度的最小单位——应用容器模版——远小于Shared Hardware架构调度最小单位——虚拟机模版——的体积,因此具有资源利用率高,弹性响应速度快的优点。 未来 Shared OS架构从其原理考虑,是依靠应用服务器对同一操作系统上资源进行了细分,如果未来应用服务器可以保证其上的多个应用之间良好的隔离,则“应用容器集群”的实现还可以采用多租户实现层次更高的架构——Shared Container。介时,“应用容器集群”资源利用率将进一步提高,弹性调度效率将更理想。
  • 19. Thank you. xiaoqingfeng@yeah.net