1 / 17

How to Build Cloud Platform

How to Build Cloud Platform. Intel SSG DRD EPE. Key Technical Problem - How to Design. 宏观： 架构如何支持大规模数据中心 ? 架构如何支持多数据中心的集中管理？ 设计考虑异构系统的支持 物理机的异构， 实时迁移的局限性， 从而引出高级功能的局限性 - 比如基于实时迁移的动态负载均衡和不中断业务的停机维护等。 微观： 是否绑定一个 VMM? 考虑将来对不同 VMM 的扩展？ 怎样融入业务的管理？使业务与云平台的交互 如何根据需要灵活的定义自己的业务策略？

vladimir-compton
Download Presentation

How to Build Cloud Platform

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. How to Build Cloud Platform Intel SSG DRD EPE

  2. Key Technical Problem - How to Design 宏观： • 架构如何支持大规模数据中心? • 架构如何支持多数据中心的集中管理？ • 设计考虑异构系统的支持 物理机的异构， 实时迁移的局限性， 从而引出高级功能的局限性- 比如基于实时迁移的动态负载均衡和不中断业务的停机维护等。 微观： • 是否绑定一个VMM?考虑将来对不同VMM的扩展？ • 怎样融入业务的管理？使业务与云平台的交互 • 如何根据需要灵活的定义自己的业务策略？ • 如何在不改变架构的基础上增加新的功能？

  3. 怎样设计架构 – 大规模多数据中心管理 多层次管理 – 增强平台扩展能力 • 中央管理服务器去管理多个“子云”或数据中心 • 很容易扩展到大于2层架构 Management Console Management Console Cloud Mgmt Service IT User IT User Managed nodes & groups CCMS (Central Cloud Mgmt Service) … CMS CMS One-tier Management Two-tier Management

  4. 怎样设计架构 – 如何支持异构系统 1。 同构与异构并存 2。 可以对异构系统统一分类，统一标示，与同构系统加以区分。 3。 同构系统资源池，来满足高级功能 – 实时迁移，动态负载均衡，容灾。。 4。 异构系统资源池，可以实现基础功能 – 静态迁移，静态负载均衡。 异构系统资源池 同构系统资源池 资源池,独立主机 实时迁移，高级特性 磁盘IO不是密集的应用 快速静态迁移 磁盘IO不是密集的应用 慢速静态迁移 磁盘IO密集的应用.(如果仍无法满足性能,可以考虑使用VT-d/VT-c)

  5. 怎样设计架构 – 架构的存储考虑 1。 共享存储： 两个层面： - Cloud Service层面：需要有一个共享存储去存储相对稳定业务获软件模板。为以后业务部署创造条件。 如：操作系统级模板，数据库模板，中间件模板。。。 - 资源池层面：需要有一个共享存储去集中管理虚拟机/业务镜像。另外可能需要支持高级功能。 - xenserver – COPY-ON-WRITE:增量形式部署,快~. 2。本地存储的利用：- 相对稳定业务 - 特点是分散，而且业务可移植性差。但性能相对好。适用于一些相对稳定的业务组。 - 由CMS的公共模板库生成业务模板，业务模板放入到资源池中的一台主机上，由此在资源池内部做部署分发。

  6. Key Technical Problem - How to Implement • 怎样选定VMM? 稳定？成本？性能？维护？ • 成熟的接口或标准? • 如何测试云平台？ • 测试管理平台的管理能力 – 管理平台性能 • 测试云平台业务服务能力– 虚拟化的性能

  7. VMM的选择 VMware: 生态链完善，价格昂贵，稳定，新技术更新快，限制第三方。 尽管有免费的ESXi, 但在4.0之后所有的API都从VC提供出来。也就意味着所有基于Vmware的开发都要先购买VC。 XEN Family: 生态链比较完善 • Opensource: 免费，但不稳定。新技术应用快。 • SLES XEN:免费，但不稳定，补丁更新频繁。新技术应用快。 • RHEL XEN:免费，策略导向ＫＶＭ。 • Ctirx XEN:免费（一年更新一次免费的license）,稳定。但新技术应用慢。 … KVM： RHEL – KVM : 生态链比较少。 我们的云平台需要考虑什么？ - 求稳->价格->自主开发->不绑定

  8. VMM的选择 –性能？ Intel虚拟化硬件加速技术发展很快，已经大大降低了虚拟化软件的性能损耗，虚拟化软件间的性能差别将会越来越小。 处理器层面 VT-x, Flex-Priority, EPT 芯片组层面 VT-d IO设备层面 VMDq, VMDc(VT-c) 所以我们可以利用Intel多种层面的虚拟化技术来解决性能问题。 但要注意的是如何在云平台当中正确有效的使用这些技术。

  9. 标准及接口的介绍 Distributed Management Task Force (DMTF) OVF – 开放虚拟化格式? 很多VMM开始支持此标准，降低业务的部署复杂度。 要考虑： 此标准格式是否可以满足我们对于业务部署的要求？ libvirt： 可以支持很多VMM，xen/kvm/vmware… 要考虑： 其提供的接口是否足够？

  10. 测试云平台业务服务能力– 虚拟化的性能 云平台下面的性能测试非常复杂，业务种类多，无法抽象出一个典型应用来测试。 对于关键业务：Case By Case 来看性能。 • 上线之前：通过一系列完整的测试，可以锁定其所需的资源和最佳配置。 1。vCPU Scale 2。VM Scale 3。网络和磁盘IO的监控：决定未来要使用什么技术来支持大IO的性能。 注意，如果虚拟机内部的连接访问非常频繁，我们可以借助虚拟机内部网络，加速性能。成功案例：盛大。 • 上线之后：定义策略，动态调整业务组资源。达到按需分配。 非关键，非IO密集型业务，直接上线，缩短上线周期： - 定义策略，实时监控业务组状态，动态调整资源。 云平台的导入可能会颠覆以往的运营模式: 性能测试-〉采购机器-〉上线-〉人工调整资源 转变为: 性能测试->上线->自动/人工调整资源 整体资源池资源紧张->采购新硬件

  11. Key Technical Problem - How to Deploy • 硬件类型繁多，怎样有效管理，发挥硬件特性 • 业务模板的创建与管理 • 业务集中部署 • 性能考虑，利用虚拟化硬件加速技术提升IO性能，但部署时需要考虑功能局限性。

  12. Provide Basic Cloud Biz HW LoadBalancer Example Solution 1 2 应用示例 Example Solution HW LoadBalancer Define Management Entity for Cloud Example Solution HW Load Balancer Move to Virtualization Environment APP Server (VM) Could manage the solution directly in cloud, not the VM. APP Server (VM) APP Server (Physical Server) DB Server (VM) DB Server (VM) DB Server (Physical Server) Intel CFP Physical Server (w/ VMM) Physical Server (w/ VMM) 3 Provide Adv. Cloud biz HW Load Balancer Write Extended Module for Adv. Solution Mgmt. Example Solution 4 Configure F5 LB APP Server(VM) Define Policies for Elastic Computing Configure HW LB Re-conf. HW LB when add new app server Monitor APP Server Status DB Server(VM) Monitor APP Server Status Get the APP runtime status (No. of Connection) • Monitor APP Status • If too high Connections • Start one APP server • Reconfigure HW LB to add this APP into Cluster Control APP Server Control APP Server Control APP server (stop, start, reset) Intel CFP Physical Server (w/ VMM)

  13. 业务集中部署 资源池 共享存储 业务镜像 业务镜像 模板Index Table 业务镜像 业务模板库 业务镜像 业务镜像 CMS 资源池 模板库存储 独立主机本地存储 业务模板库 通用模板库 业务镜像 业务镜像 业务镜像 业务镜像 业务镜像 业务镜像 业务镜像 业务镜像

  14. Key Technical Problem - How to Operate • 权限管理 - 不同部门拥有不同的执行权力和查询权利 • 业务部署？管理？监控？ • 业务部署需要大量人工操作 • 业务资源无法根据实际情况按需分配 • 业务规模无法根据实际情况灵活扩张与收缩 • 发现业务相关问题无法做出及时自动化反映 • 业务的资源限制？不同业务组其资源是否 可以共享？是否有公司内部约束？如果有限制，如何去限制？ • 数据中心内资源如何灵活调度？ • 电源管理-节能减排

  15. 权限管理 平台使用者要根据其目的和角色做详细的划分： 运营部门：要有最高的权限去管理整个云平台。 管理层：关心平台资源利用情况，关心平台的部分重要事件。 - 查询性能指标，事件出发提醒。以此来作为购买硬件资源的根据 业务管理部门：业务环境的搭建，业务部署，业务日常管理。 业务发展决策层：关心业务数据中心或资源池的状态. - 查询性能指标，事件出发提醒。以此来作为购买硬件资源的根据 在设计CMS初期要将用户权限管理考虑进去，深入到具体的action内.在用户和action之间有一个权限的映射关系。我们可以轻松的根据实际情况改动设置权限。来满足多层次多用户的管理模式。

  16. 数据中心内资源的灵活调度 定义策略时注意，尽量缩小可调度范围。保证调度策略的正确执行。例如：经过一段时间的观察，已知两资源池业务峰值不同，我们可以在两资源池间定义调度策略。 某资源池资源紧张 系统收到相应事件,并通知管理员 查找空闲资源池 从空闲资源池中check out一台物理机 配置相应网络/存储属性，加入到资源紧张资源池

More Related