既要管理对内的应用程序又要管理对外的 Web 站点这种多样性的工作使得 Steve 的团队拥有另人惊异的全方位的使用 Oracle 产品的综合的 Web 经验Steve 说我们已经部署了 OracleAS Container for JEE (OCJ)应用程序Web 高速缓存移动服务文件代理门户—您可以讲出这些名词而我们可能已经将这些东西应用到生产环境中服务于大量的用户并要求这些应用程序具有最好的可视性和可靠性
但是无论是一个内部的应用程序一个 Web 站点还是一项托管服务对于 Steve 的团队每种情况都面临着相同的商务问题它总是具有很高的可用性多年以来我们发现我们正在对内部或外部的用户提供服务并不会对它产生什么影响同样的规则也适用于我们如何来接近并实现高的可用性
而且为一家业界领先的全球性的软件公司工作也给我们带来了一些不平常的挑战Steve 说Oracle 是时刻变化的环境在这里存在很多伟大的思想一个崭新的应用程序可能在第二天就过时了我们在 Global IT 中的工作就是确保 Oracle 在这些站点所部署的应用程序是稳定的并运行得很好从本质上讲我们提供硬件和软件来公司的站点和部署服务
开始着手准备并加马上运行起来
对于 Steve 的团队部署新应用程序的过程是一门艺术也是一门科学Steve 团队要与研发人员以及 Oracle 内部的设计师网络组数据中心团队甚至是采购人员进行大量的协调工作下面 Steve 将解释这一过程
一旦有一个新的研发项目需要我们来进行部署就会牵涉到许多部门就象画画一样我们在 Global IT 就是一块空白的画布开发团队可以向我们提供所有的颜料和画笔然后我们就将不同的部分整合在一起形成一幅画我们从网络连接开始这样我们就可以将所需要的新服务器接入到 Oracle 的主干网中
然后我会与采购和运作部门相互配合来选购最适合于该项目的服务器我还会与 Global IT 中的体系结构组相互配合来确保我所要购买的服务器能够满足新应用程序的需要并能被我们现有的基础架构所支持
然后我们就可以启动该项目了我与设备部门相互配合以在数据中心获得空间来放置我的服务器我们搭建网络放置硬件并将其放在架子上进行固定只有一切都搭建好了才会把磁盘—操作系统和新服务—交给我此时我需要将小组中的其他成员召集到一起
之后 Steve 的团队就要与开发人员紧密合作通常包括测试项目其中他们构建了实际的服务并将其应用到将在部署中使用的硬件中
Steve 说从这开始我们将与其他部门紧密合作—比如管理 Oracle 互联网目录 (OID) 的部门和单点登录服务器（如果需要调用的话）我们与邮件团队相互配合来确保我们能够连接到邮件服务器且不会比我们事先计划增加太大的负载量然后我们就会在临时环境中展开全面的测试然后再将其应用到产品中
一旦完成以上所有的工作Steve 的团队就将该项目转换到维护模式处理补丁和发现问题我们首先分阶段进行全面测试确保每一步中的每个修补程序都是好的然后将其应用到产品中
按照这种方式指导此过程就是将高可用的高性能的服务部署到终端用户的业务总目标
OTN 移植项目 — 案例研究
当 Oracle 决定OTN 需要重新进行架构以获得更好的可用性和性能时就看准了门户但是Steve 的团队遇到的不仅仅是技术上的问题OTN 拥有许多 OCJ 应用程序可定制应用程序和许多基于技术的内容服务 Steve解释说没有一个是出自数据库的因此要转换成一个门户使其中的一切信息都来源于数据库—并通过数据库对所有内容进行管理— 这不只是对体系结构进行转换对于许多内容的所有者来说这还将成为一种文化的转换
Steve 的团队最终确定实施这一项目的最佳方式就是按从前端到后台的方式进行最终目标就是要将 OTN 移植到门户上但是我们还希望运行在 Linux 上的 OTN 可以真正证实 Oracle 的 Linux RAC 解决方案是可行的基于这一点我们希望新的 OTN 的性能即使不能超越现有 OTN 的性能也不能比现在差为此使用现有 OTN 的性能指标数值我们可以向后对比的方式来工作以确定什么是新体系结构所需要的
明确性能目标帮助 Steve 的团队架构了这个新的门户解决方案但这还不能称作是真正的科学前端是 Web 高速缓存以及 HTTP 服务器和门户服务器其后则是位于两节点 RAC 集群上的数据库服务器为门户数据库提供服务
除了产品的体系结构以外Steve 确保有一个阶梯层作为开发的一部分如果没有临时分区我们就寸步难行他这样解释说这是我们的必由之路因为在你进行测试和部署的时候你会想要将可能出错的地方划定在一个区域内并进行验证得出结论例如你可能认为在 Web 高速缓存中调整一个参数会出现问题但最后却发现这样做是不对的为了回过头来再次进行观察同时又不想中断生产那就必须将临时分区作为系统的一部分
图 通过利用 Oracle 应用服务器和 Oralce 数据库获得高可用性 正如上图所示如果某个集群上的某个节点发生故障客户请求就会透明地路由到该集群中的另一个节点而终端用户从来不会知道曾经出现过故障这样一来在 Oracle 应用服务器上部署的任何商务应用程序都会保持正常运转而不会中断这就确保了 计划内的和 计划外的宕机时间正如可以从上图中看到的那样Oracle 应用服务器在中间层支持三个层次的集群Web 服务器JEE 服务器和 Web 高速缓存集群此外位于 OracleAS 顶层的应用程序可以利用 Oracle RAC 具有高可用性特性的优势利用由 Oracle RAC 管理的动态内容来加强保护
利用 Oracle 产品套件（Oracle 应用服务器和 Oracle 数据库）中构建的高可用性就有可能配置和架构一个解决方案使这些特性发扬光大使用 Dell/Linux 解决方案的成本是非常高效的因此只需在高端服务器解决方案上花费很小的成本就可以实现这就使得 Global IT 能够获得更多的服务器来支持故障切换或是备用解决方案这样一来在构建高可用解决方案的同时还可以兼顾到灵活性的提高
Steve 经常会用到的另一个窍门就是创建他自己的 psuedo 网格环境 我们有双倍的额外服务器可以使用已经配置好并准备就绪一旦需要就可以运转起来他这样解释说这些额外的服务器所能作的不仅仅是备份在网络流量突增的时候这些服务器可以真正地部署进来就像在 OracleWorld 的前一周我们需要更优的性能于是我们加入了一些额外的服务器并在使用高峰期间提供了比 OTN 期望水平更高质量的服务一旦点击率下降我们就可以将这些服务器撤出让它们去完成其他任务
在需要额外的机箱只以及体系结构不同部分需要进行交换时廉价的 Linux 选项才是最适用的通常认为使用更廉价的软硬件比如 Lintel 机箱就意味着需要更多的软硬件管理而且与昂贵的 Sun机箱相比很可能会存在一些性能上的问题事实让 Steve 明白这种简单的推理并不总与事实相符
Steve 说使用 OTN 之前的体系结构我们有四个 Sun 机箱来运行 Web 高速缓存还有四个 Sun 机箱运行 AIS 服务器我们用三个 Linux 服务器来替换这八个 Sun 服务器结果我们即使没能获得更好的性能也至少获得了同等的性能据 Steve 说在成本方面更没有争议我还可以为每个 Solaris 服务器买 个 Lintel 服务器
但是在选择日常使用的硬件和操作系统 (OS) 时成本就不再是我们唯一要考虑的性能也极为重要而且了解如何去诊断并解决性能衰退的问题就是架构一个好的部署方案的关键
热点和瓶颈
在获得优化的性能水平的过程中最主要的一个挑战就是在出现热点时能够正确地定位这些热点这并不像听起来那么容易Steve 说特别是当你拥有一个三层体系结构的时候这个热点可能是 Web 高速缓存可能是门户可能是数据库也可能是这三层中的任意一层上的 OS这个热点还可能是网络
图 的性能 这是来自Keynote 系统为期 个月的评测结果Keynote 系统从万维网的评测代理对 Oracle 的网站性能进行了评测这一服务帮助我们来诊断全球 Oracle 技术网的问题
即使在确定了位置以后要想进一步知道引起热点的确切原因都是一件令人头痛的事其他一些问题的边缘效应都可能引起热点Steve 解释说例如可能会找到某个网络的热点但是真正的原因可能是因为某个服务器向网络接口推送了太多的信息甚至可能是一些非常简单的原因比如说网络接口限制为 兆之下而不是 兆Steve 提醒设计师一定不要忽视这些简单的原因
此外还有一些工具可以帮助设计师来诊断热点和瓶颈厂商提供的工具常常是非常有用的而且现有还有一些更为成熟的开发源代码可以用Oracle 的企业管理器就有很优秀的评测能力
Steve 建议最起码也要对体系结构进行权威性的负载测试和 OS 评测—特别是磁盘 I/O内存的使用情况和 CPU 的使用情况和这些部件在负载下的表现如果你在 OS 中发现了一个热点那么你是否能确定是什么引起该热点的吗？查看一下可能引发这一热点的技术是 Java 中的 OCJ？是 HTTP 或 Apache？是 Web 高速缓存？以上任何一
