云计算中的多租户与多租户架构

1、此处填写密级标识 云计算中的多租户与多租户 架构Richard Yu *此处填写密级标识 什么是多租户(Multitenancy)“多租户”的概念最早起源于软件领域，指一个软件实例服务于多个用户的架构。每个用户称为一 个租户。http:/en.wikipedia.org/wiki/Multitenancyhttp:/ tenancy此处填写密级标识 云计算中的多租户“多租户”也是“云计算”的基本属性之一。云计算的三种服务层次SaaS、PaaS和IaaS均体现 了对“多租户”不同的支持。SaaSPaaSIaaS出租的资源举例说明软件的使用权。典型如：电子邮件系统。用户 （租户）拥有使用账号。租户 登录使用系统。软件开发平台资源（如开发支 撑系列工具，应用存储空间， 运行容器，平台服务等等）。如：某租户拥有1G应用存储 空间，应用容器（数量不限， 总内存上限4G），2个缓存服 务。硬件基础设施（如CPU、内存 ，存储，IP，网络设备等等） 。如：某租户拥有2颗CPU，8G 内存，80G硬盘，10IP，2负 载均衡器，创建主机数量不限此处填写密级标识 【隐藏】多租户是云计算的基本属性之一ht

2、tp:/ container此处填写密级标识 多租户与多租户架构应用实现对“多租户”的支持，需要相应的“多租户架构”（Multi-tenancy architecture）。在云 计算时代，伴随着技术的发展， 应用的“多租户架构”获得了极大的丰富。Windows Azure VS 经典的多租户架构： Shared nothing Shared hardware Shared everything此处填写密级标识 多租户架构总览Gartner对当前云应用“多租户”架构进行了总结并给出了参考架构，如下：此处填写密级标识 为什么要“多租户”？“多租户架构”已经是云计算时代应用基本架构，那么，为什么采用“多租户”？它有什么优势？事实上，“多租户”的模式并非IT独有，在我们日常生活的许多方面，均有体现。下面，我们以一个旅馆的例子，来探究为什么要“多租户” 。 （Why multitenancy？）此处填写密级标识 一个旅馆的例子1个旅馆， 出租给多个人 换个角度，多个人共 租用了1旅馆的空间（ 资源），旅馆正在面 对“多租户”。1个空间（资 源）多人共用 ，如何划分房 间（资源分配 ）？不划分，

3、全部共用 。旅客共享居住空间 ，床铺。大通铺方案木板隔断方案划分，用木板隔离 。一个隔断中容纳 几名旅客。几名旅客共享居住 空间，每名旅客独 享床铺。水泥墙隔断方案划分，用水泥墙隔离 。一个隔断中只容纳 一名旅客。每名旅客独享居住空 间，床铺。本例中，我们从居住空间和床铺两个方面考量 。此处填写密级标识 一个旅馆的例子大通铺木板隔离水泥墙隔离释意容纳旅客数504025进行分隔时必然会消耗 空间，不同方案消耗空 间不同，使得等量空间 最终容纳旅客数不同。旅客 体验私密性差中好旅客的行动是否会被其 他旅客知晓决定了私密 性。分差、中、好三个 等级，对应私密性由低 到高。本例中，多人共 享居住空间还是单人独 享居住空间决定了私密 性。舒适性差中好居住空间如何分享，床 铺如何分享共同决定了 舒适性。二者均独享的 方式舒适性最好。均共 享的舒适性最低。住宿价格 （元/每天）202540本例假设旅馆满员，每 天计划总收入1000元 。住宿价格=1000/容 纳旅客数我们来评价一下按照不同划分方案划分的结果：此处填写密级标识 一个旅馆的例子大通铺木板隔离水泥墙隔离容纳旅客 数504025旅客 体验私

4、密 性差中好舒适 性差中好住宿价格 （元/每天 ）202540高低资源利用率资源利用率 = 1 / 容纳旅客数低高旅客体验低高住宿价格旅馆视角（资源出租者）旅客视角（资源承租者）此处填写密级标识 一个旅馆的例子大通铺 共享居住空间、床铺 （Shared Everything）木板隔离 共享居住空间、独享床铺水泥墙隔离 独享居住空间、床铺 （Shared Nothing）资源利用率高中低租户间 共享资源多中少/无租户间 隔离性低中高单位资源 价格低中高如果再抽象一点：此处填写密级标识 一个旅馆的例子（结论）不难得出结论：l 租户间共享资源越多，基础资源的利用率越高，单位资源成本越低, 租户间 隔离性越差。现在回到开始的问题：为什么要多租户？希望利用多租户带来的资源高度共享模式（架构），提高资源利用率，降低单 位资源成本。 但，同时必须克服租户间隔离性下降给租户带来的不便。此处填写密级标识 不同架构差异少多租户间共享资源现在回到云应用“多租户架构”的讨论，基于刚才的分析与结论，首先分析一下各种架构，可见： 随着“多租户”在应用架构中实现层次的增高，租户间共享资源也越来越多。多租户实现层次此

5、处填写密级标识 不同架构差异根据之前的结论，图中架构从1-7，租户间共享资源越来越多，资源利用率越来也高，单位资源成本 越来越低，租户间的隔离性越来越差。显然，租户间共享资源越多 的架构，租户隔离难度越大 ，成本越高。租户隔离难度越 大，应用开发难度，测试与维护 成本都会上升。租户间隔离性降低，会导致许多 问题：如数据安全性降低，租户 间性能、异常相互影响等等。这 些问题是应用为保证对租户的 服务质量而必须解决的。这类 行为业内称为租户隔离。低高资源利用率高低单位资源成本低高租户隔离成本理论上，在单位资源成本和 租户隔离成本取最佳平衡点 ，就能找到最合理的架构。此处填写密级标识 业内的实践如此多的“多租户”架构，业内知名厂商是如何实践的？此处填写密级标识 业内的实践业内厂商“多租户架构”多集中在Shared Hardware 和 Shared Everything。为何如此？l 理论上，各厂商选择的是单位资源成本和租户隔离成本取最佳平衡点的架构。l 厂商选择的“多租户”架构与其擅长的业务领域的技术积累紧密相关：SalesForce 与 Google 在Shared Everything

6、多租户高共享架构方面积累深厚，因此其优先选择了共享程度较高、同时实现难度也较大的架构。l 对于“多租户高共享”方面积累尚浅的厂商，随着虚拟化技术出现而产生的Shared Hardware架构，方案成熟，难度适中，是一个好的选择。l 还有一个重要因素租户的需求是否有共性。SalesForce的实际上是面对特定领域（CRM）的，且其领域用户需求共性明显，因此，采用Shared Everything架构非常适合，且取得巨大成功。如果租户间需求没有趋同，比如租户的需求是来自多个领域的，或者同领域、但有大量定制，会使得采用Shared Everything架构十分困难。此时，选择共享程度低的架构反而是个明智的选择。此处填写密级标识 附录：关于PaaS“应用容器集群”EAF在策划时创造了“应用容器集群”的提法。此提法基于如下考虑：PaaS平台需要为其租户提供一个由平台管理的应用运行的环境。应用运 行在应用容器中，因此，组成应用运行环境的是应用运行容器，因为有 大量的容器，且会使用集群技术，因此取名“应用容器集群”。关于“应用容器集群”的实现。 EAF原计划采用Shared OS多租户架构实现应用容

7、器集群。即多个容器 共享一个操作系统的方式。结合实际。就是一台虚拟机上，会有多于一 个的应用运行容器（类似于Cloudbees）。而常见的Shared Hardware架构， Shared Hardware架构中，一台虚 拟机上只有一个应用运行容器。（类似于AWS Beanstalk、Aclome BC）此处填写密级标识 附录：关于PaaS“应用容器集群”对比“应用容器集群”Shared OS与Shared Hardware架构的实现二者对比， “应用容器集群”在调度容器时， Shared OS架构实际调 度的是应用服务器实例，而Shared Hardware架构实际调度的是虚拟机 。在进行应用弹性伸缩时， Shared OS架构调度的最小单位应用 容器模版远小于Shared Hardware架构调度最小单位虚拟机 模版的体积，因此具有资源利用率高，弹性响应速度快的优点。未来 Shared OS架构从其原理考虑，是依靠应用服务器对同一操作系统上资 源进行了细分，如果未来应用服务器可以保证其上的多个应用之间良好 的隔离，则“应用容器集群”的实现还可以采用多租户实现层次更高的 架构Shared Container。介时，“应用容器集群”资源利用率将 进一步提高，弹性调度效率将更理想。此处填写密级标识 Thank

《云计算中的多租户与多租户架构》由会员油条分享，可在线阅读，更多相关《云计算中的多租户与多租户架构》请在金锄头文库上搜索。