Recomendados
Mais conteúdo relacionado
Mais procurados
Destaque
Semelhante a 如何构建企业私有云
Semelhante a 如何构建企业私有云 (20)
如何构建企业私有云
- 1. < 在此处插入图片 > 私有 PaaS 的关键构建块 甲骨文福州分公司
- 2. 以下内容旨在概述产品的总体发展方向。此信息仅供 参考，不可纳入任何合同。该信息不承诺提供任何资 料、代码或功能，并且不应该作为制定购买决策的依 据。描述的有关 Oracle 产品的任何特性或功能的开 发、发行和时间规划均由 Oracle 自行决定。 © 2009 Oracle Corporation 2
- 3. 议题 • 私有平台即服务概述 • 私有平台即服务要求 - 动态容量 - 共享组件 - 快速部署 - 自助服务 - 管理与自动化 • 案例研究 • 结论 © 2009 Oracle Corporation 3
- 4. 私有云构建块 共享组件 自助式界面 中间件 平台即服务 数据库 管理 基础架构 OS 即服务 管理 虚拟化 © 2009 Oracle Corporation 4
- 5. 私有 IaaS 与私有 PaaS 之对比 PaaS 是企业战略的自然选择 IaaS PaaS • 更多自由 • 更安全 • 更敏捷 • 更多工作 • 更易管理 • 更高效 应用程序 应用程序 应用程序 应用程序 分散的组件 通用 / 共享组件 构建工 作更少 构建工 基础一致 作更多 基础不一致 PaaS 中间件 数据库 管理 IaaS OS OS 管理 虚拟化 虚拟化 © 2009 Oracle Corporation 5
- 6. 使用 Oracle 产品实现私有 PaaS 最全面、最开放、最集成的产品 共享组件 自助式界面 Oracle 融合中间件 中间件 Oracle Oracle PaaS 基础 Oracle 数据库 数据库 Enterprise 管理 Manager Oracle Enterprise Linux OS 虚拟化 Oracle VM © 2009 Oracle Corporation 6
- 7. 私有 PaaS 生命周期 模型推动我们的方法 3. 使用应用程序 4. 扩展 / 收缩 2. 构建应用程序 • 根据策略调整容量 • 通过自助服务进行 监视 应用程序用 • 使用共享组件装 配应用程序 户 • 通过自助服务进 应用程序开发人员 行部署 应用程序所有者 5. 付费 应用程序 • 记录使用量， 然后向应用程 序所有者或部 门付费 1. 创建云 共享组件 自助式界面 IT • 创建 PaaS • 创建共享组件 Oracle PaaS 基础 • 创建自助式门户 © 2009 Oracle Corporation 7
- 8. 议题 • 私有平台即服务概述 • 私有平台即服务要求 - 动态容量 - 共享组件 - 快速部署 - 自助服务 - 管理与自动化 • 案例研究 • 结论 © 2009 Oracle Corporation 8
- 9. 私有 PaaS 要求 PaaS 基础架构的必备功能 3. 支持快速部署 2. 支持组件共享 应用程序 4. 支持自助服 务 共享组件 自助式界面 Oracle PaaS 基础 1. 能够动态伸缩的共享基 5. 管理与自动化 础架构 © 2009 Oracle Corporation 9
- 10. 自动化的动态容量调整 应用网格和数据库网格 感知需求高峰 感知 需求 感知需求 部门应 部门 部门应 高峰 高峰 用程序 应用程序 用程序 1 1 2 共享 共享 共享 Oracle 服务 服务 服务 Enterprise Manager WebLogic Server 集群节点 Coherence 数据 网格节点 基于 WebLogic Suite 的应用网格 调整容量 Oracle 数据库 RAC 节点 Oracle 数据库网格： RAC 、 ASM 、 IMDB Cache © 2009 Oracle Corporation 10
- 11. Oracle 融合中间件和 PaaS 应用网格资源分配 + 共享组件基础架构 共享组件 自助式界面 Oracle Oracle Oracle Oracle WebCenter Identity Mgt Oracle 融合中间件 SOA Suite BPM Suite Oracle Oracle PaaS 基础 基于 Oracle WebLogic Suite 的应用网格 Enterprise Manager Oracle 数据库 Oracle Enterprise Linux Oracle VM © 2009 Oracle Corporation 11
- 12. 应用网格 资源共享和动态伸缩的基础 定制应用 打包的应 C/C+ SOA 服务 原有系统 程序 用程序 +/COBOL 自动化的动态调整 WebLogic Server 应用网格 Tuxedo Enterprise Coherence Manager JRockit 资源的池化和共享 © 2009 Oracle Corporation 12
- 13. WebLogic Server 集群化 实现应用网格的核心机制 节点 1 节点 2 动态调整 联机添加 / 删除节点 节点 节点 管理 管理 集群负载的自动再平衡 器 器 节点故障自动调节 同时实现了横向向外扩展和 高可 用性 可有外部管理参与 节点 0 节点 3 （管理员） 节点 节点 管理 管理 器 器 © 2009 Oracle Corporation 13
- 14. Coherence In-Memory Data Grid 分布式、共享、可动态伸缩的内存 • 内存分布于多台计算机（ 节点） • 联机添加 / 删除节点 WebLogic Server • 自动对所有内存进行分区和 利用 Coherence Coherence • 通过冗余实现可靠性 • 通过并行化提高性能 • 线性扩展至数千节点 © 2009 Oracle Corporation 14
- 15. 数据库网格与存储网格 为私有 PaaS 数据库与存储提供灵活的可伸缩性 • In-Memory Database (IMDB) Cache IMDB Cache - 缓存网格实现联机添加和删除节点 - 自动与 Oracle 数据库实现双向同步 • 真正应用集群 (RAC) - 联机添加 / 删除节点 RAC - 高可用性、高性能和高可伸缩性 • 自动存储管理 (ASM) - 联机添加和迁移存储 - 存储配置更改时可联机进行再平衡 - 存储所有数据 (11gR2) ASM © 2009 Oracle Corporation 15
- 16. Oracle 真正应用集群 为数据库提供灵活的可伸缩性 联机添加和 删除节点 CRM HR ERP • 实现按需伸缩、高可用性和高性能的数据库 集群 • 适应负载变化 Oracle RAC One Node • 滚动升级和滚动补丁 快速伸缩 新特性： • 联机实例迁移 在一个集群上运行 多个数据库 © 2009 Oracle Corporation 16
- 17. Oracle In-Memory Database Cache 集群化、可共享的内存数据库，是实现 PaaS 的理想数据库 服务器 A 服务器 B • 极速、一致的响应时间和高吞吐量 直连 直连 应用程序 应用程序 • 数据缓存在内存中 内存缓存表 内存缓存表 复制 - 数据库表 - 行和列的子集 • 自动与 Oracle 数据库实现双向同步 • 标准 SQL 接口 缓存刷新 缓存直写 • 通过复制保证高可用性 RAC • 缓存网格实现联机添加和删除节点 © 2009 Oracle Corporation 17
- 18. 自动存储管理 为 Oracle 数据库提供灵活可伸缩的存储 虚拟化之前 虚拟化之后 • 磁盘为数据库专用 • 存储在所有数据库间协调分配 • 无法共享容量 • 共享存储容量 • 有些磁盘超过极限，有些还有剩余 • 负载较重的数据库从所有磁盘借用 容量 存储容量 • 存储成为瓶颈 • 存储不再是瓶颈 DB1 DB2 DB3 DB4 DB5 DB1 DB2 DB3 DB4 DB5 磁盘 1 磁盘 2 磁盘 3 磁盘 4 磁盘 5 磁盘 1 磁盘 2 磁盘 3 磁盘 4 磁盘 5 © 2009 Oracle Corporation 18
- 19. Exadata ： Sun Oracle Database Machine 适用于云计算的数据库和存储平台 灵活的容量 • 网格体系结构 用于数据库和存储服务器的向外扩展 • 智能扫描 可将查询处理卸载到存储层 • 智能闪存缓存 存储实现实时随机 I/O • 数据压缩 针对 OLTP 、数据仓储和存档数据进行了优化 • 无限带宽 联网支持大量数据传输 资源共享 • ASM （自动存储管理）让所有数据库共享 Exadata 存储 • RAC （真正应用集群）让所有节点共享大型数据库 • IORM （ I/O 资源管理）根据数据库和应用程序的优先级分配 I/O 带宽 • 实例囚笼 让一个节点内的多个数据库共享 CPU Oracle 数据库的全部强大功能 • 真正应用集群、备份 / 恢复、复制、安全性、分区、大型对 象、 Enterprise Manager…… © 2009 Oracle Corporation 19
- 20. 私有 PaaS 要求 PaaS 基础架构的必备功能 3. 支持快速部署 2. 支持组件共享 应用程 4. 支持自助服 序 务 共享组件 自助式界面 Oracle PaaS 基础 1. 能够动态伸缩的共享基 5. 管理与自动化 础架构 © 2009 Oracle Corporation 20
- 21. PaaS 的精华：共享组件 2. 部门应用程序所有者使用 部门应用程 中央 IT 平台组件创建应用程序 序所有者 部门 1. 中央 IT 创建共 应用程序 部门 部门 享组件： 应用程 应用程序 序 • 要嵌入的模 块 • 要连接的单 一实例服务 • 使用嵌入式组件 • 使用连接服务 • 使用配置实例 的应用程序 的应用程序 化的应用程序 • 使用最小配 置实例化的 应用程序 共享组件 自助式界面 Oracle PaaS 基础 © 2009 Oracle Corporation 21
- 22. SOA 和 BPM ：构建共享服务和流程 部门应用程 部门 序所有者 应用程序 IT 构建应用程序 服务 流程 流程 包含组件 创建服务 查找组件 创建流程 服务 注册 和连接 服 服 服 服 流程 流程 流程 自助服务 务 务 务 务 Identity Mgt WebCenter Oracle Oracle 注册表 / 服务总线 SOA Suite Oracle Oracle BPM Suite 信息库 Oracle Enterprise Manager 基于 Oracle WebLogic Suite 的应用网格 Oracle 数据库网格： RAC 、 ASM 、 IMDB Cache © 2009 Oracle Corporation 22
- 23. WebCenter ：构建共享 UI 组件 部门应用程 部门 部门 部门 IT 序所有者 应用程 应用程 应用程序 构建应用程序 UI 序 UI UI 序 UI UI UI UI UI 创建自助式 UI UI UI UI 包含组件 门户 查找组件 更改组件 创建并注册 UI 组件 更改将被传播至共享该组件 的所有应用程序中 UI UI UI 自助式界面 Oracle Oracle Oracle SOA BPM Oracle WebCenter Identity Suite Suite Mgt Oracle Enterprise Manager 基于 Oracle WebLogic Suite 的应用网格 Oracle 数据库网格： RAC 、 ASM 、 IMDB Cache © 2009 Oracle Corporation 23
- 24. 私有 PaaS 要求 PaaS 基础架构的必备功能 3. 支持快速部署 2. 支持组件共享 应用程 4. 支持自助服 序 务 共享组件 自助式界面 Oracle PaaS 基础 1. 能够动态伸缩的共享基 5. 管理与自动化 础架构 © 2009 Oracle Corporation 24
- 25. 虚拟化实现快速部署 VM 模板可用作“软件设备” 传统的软件部署 通过虚拟机模板（“软件设备”） 部署 对每个应用程序 中间件 实例： 中间件 OS 软件设备 1.采购和配置硬 OS 件 数据库 1. 一次打包 2.安装和配置 OS OS 2. 快速部署并 3. 实时迁移实 3.安装和配置中 现动态优化 可多次使用 间件和数据库 4.安装和配置应 用程序 管理程序 管理程序 管理程序 © 2009 Oracle Corporation 25
- 26. Oracle VM 基于 Xen 的高级服务器虚拟化解决方案 • 运行 Oracle 数据库、融合 应用程序 中间件和应用程序 软件设备 中间件 • 运行非 Oracle 负载 OS 1. 一次打包 • 支持 Linux 、 Windows 和 2. 快速部署并 3. 实时迁移实 可多次使用 其他操作系统 现动态优化 • 免费下载和分发 Oracle VM Oracle VM Oracle VM © 2009 Oracle Corporation 26
- 27. 引入 WebLogic Server 虚拟版 去除软件设备中的 OS ，实现更大灵活性 标准虚拟机映像软件设备 WebLogic Server 虚拟版软件设 备 应用程序 中间件 WebLogic 软件设备 软件设备 Server VE OS • 更小的软件设备 • 更快部署 • 更高利用率 OS OVM OVM OVM • 更安全 • 更高性能 • 更快的实时迁移 © 2009 Oracle Corporation 27
- 28. 软件设备和 PaaS 2. 部门应用程序所有者基于 部门应用程 中央 IT 软件设备创建应用程序 序所有者 应用程序 应用程序 应用程序 WebLogic WebLogic 部门应 • 成功实现 PaaS 的 Server VE WebLogic Server VE 用程序 关键因素：应用程序 Server VE 所有者将每个软件设 备中的哪些内容公开 1. 中央 IT 创建软 为“可配置的” 件设备作为共 享组件 共享组件 自助式界面 Oracle PaaS 基础 © 2009 Oracle Corporation 28
- 29. 下一级别：组合件 应用程序经常是多层的和分布式的 Web 层 Web Web 应用程序 组合件 层 OVM OVM SOA WL WL 服务 OVM OVM 元数据 RAC RAC Oracle 组合件 = 软件设备 + Assembly 元数据描述： Builder • 配置 数据库层 • 连接 • 启动顺序 © 2009 Oracle Corporation 29
- 30. 组合件和 PaaS 2. 部门应用程序所有者使用组 部门应用程 中央 IT 合件创建应用程序，然后 将 序所有者 其部署到云平台中 组合件强化了 PaaS ： • 能够为平台预先构建 更复杂的应用程序基 1. 中央 IT 创建共 础 享组合件 部门应用程 • 加快部署 序 • 降低发生配置错误的 风险 • 通过标准化和一致性 简化了运行时操作 共享 组件 自助式界面 Oracle PaaS 基础 © 2009 Oracle Corporation 30
- 31. 私有 PaaS 要求 PaaS 基础架构的必备功能 3. 支持快速部署 2. 支持组件共享 应用程序 4. 支持自助服 务 共享组件 自助式界面 Oracle PaaS 基础 1. 能够动态伸缩的共享基 5. 管理与自动化 础架构 © 2009 Oracle Corporation 31
- 32. Enterprise Manager 实现自助服务 供应、监视和管理 应用程序所有者 部署应用程序 查找组件 付费 应用程 序 设置 监视和 策略 调整 共享组件 自助式界面 Oracle 融合中间件 Oracle 数据库 Oracle Enterprise Oracle Enterprise Linux Manager Oracle VM © 2009 Oracle Corporation 32
- 33. Identity Management 保障自助服务的安全 中央 IT 性 部门 应用程序 构建应用程序 部门应用程 序所有者 UI UI 服务 流程 包含组件 创建可重用 设置策略 组件 注册组件 发现授权的组 件 服 服 身份验证 流程 流程 UI UI 务服 务服 流程 流程 UI UI 务服 务服 流程 流程 UI UI 自助式界面 务 务 策略 Oracle SOA Oracle BPM Oracle Oracle Identity Suite Suite WebCenter Mgt Oracle Enterprise Manager 基于 Oracle WebLogic Suite 的应用网格 Oracle 数据库网格： RAC 、 ASM 、 IMDB Cache © 2009 Oracle Corporation 33
- 34. 私有 PaaS 要求 PaaS 基础架构的必备功能 3. 支持快速部署 2. 支持组件共享 应用程序 4. 支持自助服 务 共享组件 自助式界面 Oracle PaaS 基础 1. 能够动态伸缩的共享基 5. 管理与自动化 础架构 © 2009 Oracle Corporation 34
- 35. Enterprise Manager 实现大规模自动化 基于策略的资源管理和自动化 应用程序用 户 部门应用程 序所有者 使用应用 程序 中央 IT 部门 部门 部门 设置策略 应用 应用 应用 监视 程序 程序 程序 添加资源 共享组件 自助式界面 Oracle 融合中间件 Oracle 数据库 Oracle 调整分配 Enterprise Manager 故障切换 Oracle Enterprise Linux Oracle VM © 2009 Oracle Corporation 35
- 36. 议题 • 私有平台即服务概述 • 私有平台即服务要求 - 动态容量 - 共享组件 - 快速部署 - 自助服务 - 管理与自动化 • 案例研究 • 结论 © 2009 Oracle Corporation 36
- 37. 案例研究： Credit Suisse 公司概览 • 一个顶级全球投资银行 挑战 / 机遇 • 服务器泛滥 — 手工配置多个不同类型的服务器 • 在较高层缺乏标准化 — 需要为每个应用程序管理组件提供商和相关 SLA • 质量保证不是内嵌流程 • 维护和生产支持均面临挑战 — 为系统组件打补丁成为主要挑战，在生产 中不断需要开发人员的支持 • 审计和合规性均存在风险 解决方案 • 在 Oracle WebLogic Server 上构建“ Java 应用程序平台” © 2009 Oracle Corporation 37
- 38. Java 应用程序平台 能够动态分配资源的高级共享服务 苏黎世数据中心 ▪ 400 台服务器（ 120 台生产， 1:7 整合） ▪ 190 个应用程序 ▪ 169,000 个用户（内联网和互联网） ▪ 1400 万行有效代码 ▪ 每月 3.6 亿个 I/O 请求 ▪ 苏黎数据中心的 190 个应用程序和 30 多个并行 项目需要投入 43 个全职员工 新加坡数据中心 ▪ 12 台服务器（ 4 台生产） ▪ 4 个 PB 应用程序 ▪ 新加坡数据中心需要 6 个全职员工 纽约数据中心 (Q2/08) ▪ 5 台服务器（ 2 台生产） ▪ 1 个 PB 试验应用程序 + 来自 PB 和 IB 的准 客户应用程序 ▪ 标准化的操作流程 ▪ 190 个应用程序托管在 400 台服务器上 ▪更高效的运行支持 ▪ 取代了传统托管模型中需要的 2,800 台服务器 ▪只有 3 种平台版本并行运行 © 2009 Oracle Corporation 39 38
- 39. Java 应用程序平台 凭借条理清晰、可执行的流程取得成功 • 遵循规范的治理模型来 推动产品开发和发布以 及推动产品生命周期管 理 • 引导项目完成整个 开发流程，并使项 目不受低级基础架 构问题的干扰 • 根据 OLA 使用相应的 标准流程，从而经济高 效地运行应用程序 © 2009 Oracle Corporation 41 39
- 40. 结果 技术效益 业务效益 • 标准化改善了服务质量 • 运行成本比上年减少了 10% 以上 • 确保了重要质量属性（如安全性、故 • 共享服务器整合率 1:10 障切换、可操作性、可审计性）的供 应 • 连续 3 年（ 2007-2009 ） 未出现停机事件 • 建立了严格的生命周期管理 • 未因为对产品打 DST 补丁而发生服务 • 工具链让应用程序的升级和扩展更加 中断 高效 • 流程和组织的文档化让新的 IT-PL 能 够快速学习新知识 • KPI 提供了重要的管理透明度 © 2009 Oracle Corporation 40
- 41. Rakuten Travel 通过 RAC 实现伸缩 2 台 16 通道服务器 Oracle9i 数据库 2002 活动 备用 活动 - 备用 16CPU 16CPU （ 2 台服务器， 16 个“活动” cpu ） RAC RAC 添加 8 通道服务器 Oracle9i RAC （ 5 个节点） 2004 8CPU 8CPU LPAR RAC RAC RAC 8CPU 8CPU 8CPU 添加 16 通道服务器 Oracle RAC 10g （ 7 个节点 8CPU 8CPU 8CPU ） 2006 年夏 8CPU 8CPU 8CPU 8CPU Oracle RAC 10g （ 7 个节点 8CPU 8CPU 8CPU 8CPU 添加新 ） 2006 年秋 服务 8CPU 8CPU 8CPU 8CPU 8CPU 在集群上部署新服务 Oracle RAC 11g （ 10 个节点） 2008 年冬 8CPU 8CPU 8CPU 4CPU 4CPU 100% Oracle 体系 8CPU 8CPU 8CPU 8CPU 4CPU 采用 ASM 实现更好的可管理性 © 2009 Oracle Corpration 41
- 42. Pacific Gas & Electric 通过 RAC 实现伸缩 扩展数据库和存储实现智能仪表计划 挑战 解决方案 效益 • 为加利福尼亚北部和中部的 1500 • Oracle 数据库 • 改善了客户服务，停电时可以更快 万人供电 • Oracle 真正应用集群 速恢复供电，减少峰值电量需求 • 每天打印并邮寄超过 26 万份账 • 轻松按需增加容量，支持以递增方 • Oracle 自动存储管理 单，处理约 4 千万美元的付款 式向外扩展服务器和存储容量 • Oracle Recovery Manager • 每天接听约 1500 万次电话 • 可以使数据库容量从 20 TB 扩展 • Oracle Flashback 到 45 TB • SmartMeter™ 计划让自动读表替 • Oracle Enterprise Manager Grid • 在环境数据中心的成本减少了 代了每月的现场人工读表 Control 50% 的同时增加了计算容量 • 支持读表次数增加：天然气表读数 • Oracle Utilities Customer Care • 预计每个新系统每年节省 5 百万 每月从 4 百万增加到 1.2 亿，电 and Billing 美元 表读数每月从 5 百万增加到 3.6 亿 • 通过有计划的停电减少了停机时间 © 2009 Oracle Corporation 42
- 43. 议题 • 私有平台即服务概述 • 私有平台即服务要求 - 动态容量 - 共享组件 - 快速部署 - 自助服务 - 管理与自动化 • 案例研究 • 结论 © 2009 Oracle Corporation 43
- 44. 私有 PaaS 的构建块 总结 • 私有 PaaS 是企业战略的自然选择 - 最大的灵活性和控制 • Oracle 为构建私有 PaaS 提供了一组最全面的构 建块 - 在整个体系的各个级别均受到客户认可的网格解决方案 - 在网格计算、虚拟化和 SOA 方面已有多年投入并居领先 地位 © 2009 Oracle Corporation 44
- 45. © 2009 Oracle Corporation 45
Notas do Editor
- Unzip Keynote2_BuildingBlocksOfPrivatePaaS_v7_audio.zip into the same directory as this presentation. To turn off automatic advancing of slides, uncheck “Use Rehearsed Timings” under “Slide Show”. To turn off audio narration, check “Show without narration” under “Set Up Slide Show”.
- Welcome to this session on the Essential Building Blocks of Private Platform-as-a-Service. We’ll start with an overview of what Private PaaS is within the context of cloud computing. The core of the presentation is a discussion of what it takes to create a private PaaS and what Oracle technologies there are—the building blocks—to enable you to set up your own private PaaS. We end by taking a look at some specific examples of how our customers are implementing private PaaS.
- We’ll start with a macro-level organization of our building blocks. Note that we’re talking here about a private cloud context where an enterprise is building and providing the cloud offering internally. This is typically executed in a model where a central IT function within the enterprise builds and manages the cloud, and internal “customers” within the enterprise such as different departments are clients or “tenants” of the cloud. Some of what we’re talking about here may apply to public cloud as well, but that is not our focus in this presentation. [click] At the bottom of the software stack, residing just above physical servers, is infrastructure. This may or may not include virtualization but in most cases has an operating system (stay tuned though—even this has exceptions!). Notice that we depict management as an integral part of the picture—this theme will recur throughout our story. In the context of cloud, if one is offering infrastructure as a service (IaaS), these are the pieces inolved. [click] Platform as a Service, or PaaS, subsumes the infrastructure level and includes database, middleware, and custom-built or other additional pieces such as shared components or a self-service interface that are specific to the particular PaaS offering. Again, management is an important part of this story and is manifested as the combination of mechanisms internal to the individual layers, external management mechanisms, and how these are integrated.
- For many (if not most) enterprises pursuing a private cloud strategy, a platform-level (PaaS) cloud offering is a natural strategy and is superior to a basic infrastructure-level (IaaS) offering for several reasons. The basic idea is that PaaS provides the right balance between Central IT providing enough in the cloud so that cloud tenants can get up and running quickly and easily but have enough latitude and flexibility to create the applications they really need. If Central IT provides a much lower level offering such as at the IaaS level, each tenant must reinvent the wheel and build most of the stack on his own, lengthening time-to-deployment and resulting in inconsistent stacks that are harder to manage. By providing more in a PaaS model, tenants not only get up and running more quickly, but Central IT’s management, security, and efficiency is greatly enhanced through consistency and economies of scale.
- So to map Oracle technologies and products to this basic private cloud reference architecture, [click] we have Oracle VM and Oracle Enterprise Linux at the infrastructure layer, [click] Oracle Database and Fusion Middleware above that, [click] and Oracle Enterprise Manager as the management that ties these technologies together. [click] All together these constitute the Oracle PaaS Foundation.
- [quickly summarize since this was covered in the previous keynote] This slide shows the lifecycle of how a private cloud would work within an enterprise. Note the different roles. 1. First IT sets up the private PaaS based on the Oracle Cloud Platform. They also define certain shared components to ensure standardization and make it easier for app builders. These components may be services, processes or UI components. They also need to set up a self-service application, potentially based on WebCenter portal and Identity Management. This is potentially also integrated with the enterprise’s IT Service Mgmt application such as Siebel or BMC/Remedy. 2. Next, an app owner can take advantage of the PaaS and shared component to more quickly assemble the app and deploy it through self-service. If their role entitles them to make that request, it is automatically provisioned. If not, it gets routed to their management and/or IT for workflow approval…just like a procurement process. 3. Third, users start using the app. 4. If usage starts to approach the capacity limits, the app owner can monitor this through self-service. And the system can scale automatically thanks to an underlying grid architecture at the database and middleware levels, and thanks to effective grid control by Enterprise Manager. 5. Enterprise Manager also tracks resource usage (metering) and this data can be used to charge back to the departments or LOBs. So, this PaaS shows some of the key characteristics of cloud computing: self-service, shared services, dynamic provisioning, elastic scalabiltiy and metering/chargeback.
- So with that as background, we’ll turn now to what it takes to actually build a private PaaS.
- We identify five basic categories of capability that are important for enabling PaaS and are definitive in making a given infrastructure a truly cloud offering. [click] first is the notion of sharing infrastructure with the ability to dynamically allocate resources across different applications to scale their capacity. [click] second, and this is definitive for making the cloud offering truly “platform” is the ability to create shareable, reusable components that cloud tenants incorporate into their applications. [click] third is the ability to deploy apps nearly instantly—a basic feature that is definitive for cloud computing in general. [click] fourth, dependent on the ability to deploy apps quickly, is the ability for tenants to do so without time-consuming live interactions with IT—the basic idea is to login to a Web site and get an app live in minutes. [click] we’ll start by looking at what it takes to set up shared infrastructure with dynamic scaling. [click] fifth, a capability that really permeates the other four, is the ability to set up, monitor, and automate the infrastructure in cloud-specific ways such as automatic the dynamic capacity adjustment and generating departmental chargeback information or reports based on usage data.
- The basic mechanism for enabling resource pooling and sharing with dynamic adjustment is clustering. Clustering is a mechanism that exists at many levels within the Oracle stack, such as at the application server level, in-memory data grid level, and database level. Clustering is the ability to have multiple instances or “nodes”, each running on a separate machine, work together in a cluster to support a given workload. Important for clouds is the ability to dynamically add and remove nodes in live running clusters. For example [click] a spike in load on an application is sensed, and nodes are added to the underlying WebLogic Server and/or Coherence clusters to accommodate that spike. [click] Not just applications but shared components have spikes to be accommodated, and different spikes will be addressed in different ways such as this one entailing expansion of the Coherence grid but not the app server cluster. [click] Clustering at the Database level with RAC operates in a similar fashion.
- Let’s zoom in on the role of middleware within our Foundation. A number of Oracle Fusion Middleware components play important roles in the platform, and in particular application grid enables the dynamic capacity adjustment we just discussed.
- The idea of application grid is that you have a number of physical resources and a variety of application workloads to support with those resources. Traditionally these were allocated statically in dedicated stacks; [click] with application grid you have pooling and sharing of resources with automated, dynamic adjustment of resources enabled at the application server level. [click] the technologies we’re talking about are the app server itself, WebLogic Server for Java and its counterpart Tuxedo for C, C++, and COBOL, with related supporting technologies such as the Coherence in-memory data grid, JRockit Java Virtual Machine, and Enterprise Manager.
- To drill down a bit on WebLogic Server in particular, WebLogic Server has long had industry-leading clustering abilities. Not only can one dynamically add and remove nodes to live clusters, WebLogic Server automatically rebalances workload in such adjustments and can be set up to automatically startup new nodes in the event of node failure. This supports horizontal scale-out AND high availability. And this mechanism can be engaged by external management such as Enterprise Manager for optimization within the bigger application grid context.
- Coherence is an in-memory data grid. The basic function of this is to use the memory of multiple machines as if it were all local, appearing to an application as a single contiguous block of memory. Coherence makes effective use of even huge memory on each machine, beyond the several-gigabyte limit normally seen with JVMs on 32-bit machnes. By replicating objects and holding them in memory close to where the computation is carried out, both reliability and performance are greatly improved. Nodes can be added and removed dynamically, meaning Coherence is an important mechanism to support application grid’s dynamic capacity adjustment across shared resources. And Coherence can scale to literally thousands of nodes.
- Complementing the dynamic resourcing enabled by application grid is the dynamic resourcing at the database level, also using grid computing techniques. Starting in the middle of our picture, Real Application Clusters, RAC, is the database clustering mechanism that optimizes performance, availability, and scalability. An in-memory database cache is about caching relational data in memory. This complements the clustering enabled by RAC and also complements Coherence is about holding large numbers of Java objects in memory. Oracle In-Memory Database Cache allows us to build database caches in the memory of the application servers and process the data locally to the application. By caching the most commonly accessed subsets of rows and columns, fast consistent response times with high transaction throughputs can be achieved. Data remains synchronized with Oracle Database through a standard SQL interface. Automatic Storage Management creates a grid of storage for a database that can also be adjusted dynamically and automatically.
- Drilling in a bit on RAC, RAC is unique in database technologies in its support of grid architecture and mechanisms, particularly with its ability to adjust dynamically and automatically. Not only does this support the elastic capacity required by private cloud, it substantially enhances ongoing management tasks such as upgrades, patches, and migration without compromising zero-downtime requirements.
- Oracle In-Memory Database Cache is an OPTION of Oracle Database. It is based on TimesTen. Why fast? Entire database in memory, avoid slow disk accesses; deployed in middle tier, closer to the application, avoids round trip to the database server; optimized, short code path Automatic data synchronization Updates in cache propagated to Oracle database Updates in Oracle database refreshed to in-memory cache tables Supports read-only and updateable caches
- ASM brings the clustering, pooling, sharing, and dynamic adjustment of grid computing that we’ve been talking about to the area of database storage.
- You may have heard about Oracle’s most recent hardware offering, the Exadata database machine. This is world’s highest performance database machine along a number of dimensions. It is also an important option for enterprises looking to create a private cloud on consolidated infrastructure. Performance Facts… #1 in I/O Throughput – Up to 65 GB per second (uncompressed data) – scans can now access disk and flash simultaneously, going beyond 50 GB per second of Flash-only. #1 in I/O Rate – Up to 1 million I/O’s per second (full rack) #1 in Compression – 3x to 15x data compression (we have seen over 70x compression on some data sets)
- Ok, let’s turn to our second major requirement, component sharing.
- A definitive and important distinction between IaaS and PaaS is that the platform provides a number of components for cloud tenants to use in creating their applications. These components are unique to each domain, enterprise, and cloud and thus are custom-built, though with significant help from the Oracle PaaS Foundation as we’ll see in a minute. These are created by the Central IT function. There are three basic kinds of platform-based components. [click] The first include components that will be embedded in the tenant app (e.g. code that is copied into an app). The second consists of services that are already up and running and get connected and called into by the tenant app—these are things like SOA services. The last category is like the first but sort of inverted: The component is a nearly complete app that only requires minimal additional customization to turn it into a full app. You could think of this as an app shell or an app chassis.
- Creating SOA services and BPM processes as reusable components is straightforward with Oracle SOA Suite and BPM Suite. The Central IT department creates [click] services and process components. [click] Once they are created, they are registered in the registry, stored in the repository, and connected through the service bus. Next [click], the departmental app owner creates an app, finds [click] platform components to include, [click], includes them, and then [click] deploys the app.
- [click] Here we look at the case for UI components. In a similar fashion as for SOA and BPM components, Central IT creates the reusable components, and each cloud tenant finds the ones he needs via the self-service interface and includes them as appropriate. [click] Now let’s say we have multiple apps owned by different Department tenants (App Owners) and sharing the same UI components. [click] Central IT needs to make an important change to the corporate branding or policy and modifies one of the platform’s shared UI components accordingly. The beauty of the platform is that the centrally-made change is immediately picked up by all the tenant apps sharing that platform component.
- Now let’s turn to the third PaaS requirement, support for fast deployment.
- At the bottom of the stack, one of the most powerful enablers of fast deployment is server virtualization. Let’s contrast it with our traditional world, where for every app one typically has to procure and configure hardware, install and configure all the layers of the stack from OS up through middleware, and then ultimately install the app. This approach is time consuming and more prone to human error and administrative churn. In a virtualized server world, the stack can be pre-packaged as essentially a file—these packages are often referred to as virtual machine images, or templates, or appliances. Once a stack has been packaged into an appliance, that appliance can be deployed onto virtualized servers practically instantly, and can scale to tens, hundreds or even thousands of servers. Once an appliance instance is running, it can be moved or “live migrated” to different virtual servers for resource optimization.
- Oracle VM is Oracle’s server virtualization offering. It is based on the open source Xen hypervisor, runs Oracle as well as non-Oracle software including Linux, Windows, and other operating systems. It is free to download and distribute. Xen 是一个开放源代码虚拟机监视器，由剑桥大学开发。它打算在单个计算机上运行多达 100 个满特征的操作系统。操作系统必须进行显式地修改（“移植”）以在 Xen 上运行（但是提供对用户应用的兼容性）。这使得 Xen 无需特殊硬件支持，就能达到高性能的虚拟化。
- Moving up the stack, there’s an exciting new innovation in Oracle Fusion Middleware that allows you to get even more out of server virtualization: WebLogic Server Virtual Edition. WebLogic Server Virtual Edition is a variant of WebLogic Server designed to run directly on a virtualized server with no operating system. This is significant because, not only does it greatly improve the performance of Java apps running in virtualized environments, it makes the appliances themselves substantially smaller given the absence of the OS. WebLogic Server Virtual Edition appliances are thus faster and easer to create since there’s no OS to configure, faster to deploy since a much smaller appliance image is being transmitted to and started on the virtual server, and faster to live-migrate, since again there are fewer bits to transfer. These appliances are also easer to administer since there is no OS to patch and upgrade, and more secure since there is no OS presenting opportunities for breech.
- WebLogic Server Virtual Edition appliances are particularly interesting in the context of PaaS. [click] Central IT can create pre-configured app server appliances as bases for apps to be created by departmental app owners. [click] These appliances may or may not be pre-packaged with library code modules specific to the enterprise, and in either case the departmental app owner adds the Java code and other modules that constitute his individual app and then deploys the appliance with these additions. [click] Key to making platform appliances effective is exactly what is exposed as configurable and extendable by the departmental app owners.
- Now, let’s take this whole concept of prepackaging components with exposed extension points to the next level. As nice as an appliance is, the reality of typical enterprise applications is that they are not self-contained, single-element entities but rather comprise multiple distributed elements that are connected together. [click] Each element might be an appliance, but the application overall consists of multiple appliances connected in a certain way. Here’s where we introduce the notion of an assembly, a sort of “meta appliance” that consists of multiple appliances plus information about how to connect them. [click] Oracle Assembly Builder is a tool that takes such a multi-tier, distributed application and packages it up into an assembly that can be reused in a way similar to the way appliances are used. [click] the assembly, like an appliance virtual image, is essentially a file that contains the images of the constituent appliances as well as metadata about how those appliances get configured, connected, and started up.
- So with that brief introduction to assemblies and Oracle Assembly Builder, let’s consider the implications for PaaS. [click] Extending our PaaS lifecycle model here, Central IT uses Assembly Builder to create assemblies as shared components on the Platform. [click] Departmental app owners use the assemblies much like they use appliances in the previous example, except that the assemblies package and hide details of much more complex topologies, and are essentially shells of distributed multi-tier applications. The work each departmental app owner needs to do is now significantly reduced, and the risk of introducing configuration errors is also reduced. In addition, the various apps that different departments build using a given assembly now have much more consistency in their structures, simplifying operational acdtivities including diagnostics, updates, etc.
- Now let’s look at the fourth requirement area, self service.
- The first thing we want to highlight in the area of self service is the importance of the management capabilities. If we review our PaaS lifecycle model from the standpoint of the activities carried out by the cloud tenants, the departmental app owners, we see that many of the self-service activities such as setting policies, monitoring and adjusting application-level behaviors, and even chargeback based on usage metering depends on unified management mechanisms that span the foundation stack. More detail on this will follow in the management breakout session.
- The second critical area is security. Let’s again extend our PaaS lifecycle model. Central IT creates and registers shareable platform components, but now we highlight how they can set policies using Oracle Identity Management Suite and Oracle Enterprise Manager. Subsequently, when a departmental app owner logs into the self-service interface to create app, he is presented with only the components for which he is authorized based on his role and the policies in place.
- Now we turn to the fifth major category of requirements, management and automation.
- This is a huge topic, and we’ve devoted an entire breakout session to cover it in detail. We wanted to highlight here that it is truly a cross-cutting, integral set of requirements across the entire stack. If we review one last time our PaaS lifecycle, this time from the standpoint of Central IT in the ongoing running of the Platform, we can quickly get a sense of the nature of required automation. [click] Ahead of applications’ running, Central IT has entered policies ranging from foundation-wide to application-specific. [click] End users use the application, in many cases not even needing to know that they are running on a cloud per se—their main concern is application availability and responsiveness. As they’re using the cloud-based apps, Central IT is monitoring the platform and adding resources to the pool as aggregate demand grows, and meanwhile the platform itself is automatically adjusting allocation to optimize across ebbs and flows of demand and also failing over automatically as cluster nodes encounter problems, etc. Again, this automation depends on sophisticated mechanisms within the stack layer technologies themselves and the centralized management functions unified within Enterprise Manager.
- Now, with that very brief introduction to what a private platform as a service is and how to build one using Oracle technologies, we take a look at how a few customers are evolving toward PaaS environments in their IT shops.
- We start with Credit Suisse, a leading global investment bank and important Oracle WebLogic Server and Database customer. To address sprawling, heterogeneous infrastructure that challenged quality assurance and production support, they built a centralized, shared services platform called the Java Applications Platform on WebLogic Server.
- We’re talking about a global operation centered at Credit Suisse’s Zurich headquarters, with hubs in Singapore and New York. In Zurich the centralization effort consolidated the resources underlying 190 applications from 2,800 servers down to 400, a substantial 7:1 improvement, leveraging WebLogic Server’s clustering and other consolidation-supporting features.
- To truly realize the value of the consolidation enabled by WebLogic Server, Credit Suisse made substantial changes to their human IT processes as well. A customer-focused developer support function guides projects through the entire development process. A Centralized Platform Product function drives the development and release lifecycle according to a well-defined governance model. The Operations department runs applications cost-efficiently with standardized processes. These three processes depend on consistency of architecture guidelines, shared managed components, tool-chain automation, and centralized shared hosting.
- The results have been significant: standardization has made for higher quality, greater agility, faster learning, and more transparency on the technical side, resulting significant reduction in operating costs and service issues.
- Rakuten Travel (an orbitz.com equivalent in Japan) ,migrate their current system to an ASM based, 10 node 11gR1 system without HACMP. Their prior system was running on a 9 node 10gR2 cluster with HACMP and no ASM. They are a Oracle RAC reference customer in Japan. RAC SCP Customer Migrated from 10g to 11g, moved to a pure Oracle stack off of HACMP. Also grew the number of nodes. OLTP nodes have 16 cores, Batch nodes have 8 cores. Rakuten Travel has 16-cores Machine x 7 and 8-cores Machine x 3 (Total: 10 nodes). Environments run on LPARs, sometimes two of them per physical box. Reason for splitting a larger machine into two LPARs for the cluster include: When they decided to purchase a new server in 2004, they only needed 8cpu more of computing power, so 16-way x 3 was not an option. They wanted to avoid having a mixed cpu count setup (16, 16, 8) at the time (currently they do have a mixed setup ). Having more nodes give them more computing power when a server fails.
- For More Information: Press Release - http://www.oracle.com/corporate/press/2008_jan/pge.html Magazine Article - http://www.oracle.com/technology/oramag/oracle/08-jul/o48green.html
- We’ll wrap up with a short summary.
- We’ve shown here how private platform as a service is a natural strategy for enterprises. It takes centralization, consolidation, and shared services to the next level, providing enterprise departments with self service and automated capacity adjustment in a model that maximizes flexibility and control. Oracle offers the most comprehensive set of building blocks for and enterprise to create a private platform as a service, including unmatched grid capabilities at all layers of the stack backed by years of investment and industry leadership in grid, virtualization, and SOA. Thanks very much for listening, and we wish you the best in your private platform-as-a-service as well as other IT projects.