既要治理对内的应用程序又要治理对外的 Web 站点，这种多样性的工作使得 Steve 的团队拥有另人惊异的、全方位的、使用 Oracle 产品的、综合的 Web 经验。Steve 说，“我们已经部署了 OracleAS Container for J2EE (OC4J)应用程序、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 拥有许多 OC4J 应用程序、可定制应用程序和许多基于技术的内容服务，” Steve解释说。“没有一个是出自数据库的。因此，要转换成一个门户，使其中的一切信息都来源于数据库—并通过数据库对所有内容进行治理— 这不只是对体系结构进行转换，对于许多内容的所有者来说，这还将成为一种文化的转换。 Steve 的团队最终确定实施这一项目的最佳方式就是按从前端到后台的方式进行。“最终目标就是要将 OTN 移植到门户上。但是我们还希望运行在 Linux 上的 OTN 可以真正证实 Oracle 的 Linux RAC 解决方案是可行的。基于这一点，我们希望新的 OTN 的性能即使不能超越现有 OTN 的性能，也不能比现在差。为此使用现有 OTN 的性能指标数值，我们可以向后对比的方式来工作，以确定什么是新体系结构所需要的。” 明确性能目标帮助 Steve 的团队架构了这个新的门户解决方案，但这还不能称作是真正的科学。“前端是 Web 高速缓存，以及 HTTP 服务器和门户服务器。其后则是位于两节点 RAC 集群上的数据库服务器，为门户数据库提供服务。” 除了产品的体系结构以外，Steve 确保有一个阶梯层作为开发的一部分。“假如没有临时分区，我们就寸步难行。”，他这样解释说。“这是我们的必由之路，因为在你进行测试和部署的时候，你会想要将可能出错的地方划定在一个区域内，并进行验证，得出结论。”例如，你可能认为在 Web 高速缓存中调整一个参数会出现问题，但最后却发现这样做是不对的。为了回过头来再次进行观察，同时又不想中断生产，那就必须将临时分区作为系统的一部分。”
图 1：通过利用 Oracle 应用服务器和 Oralce 数据库获得高可用性 正如上图所示，假如某个集群上的某个节点发生故障，客户请求就会透明地路由到该集群中的另一个节点，而终端用户从来不会知道曾经出现过故障。这样一来，在 Oracle 应用服务器上部署的任何商务应用程序都会保持正常运转而不会中断，这就确保了 0 计划内的和 0 计划外的宕机时间。正如可以从上图中看到的那样，Oracle 应用服务器在中间层支持三个层次的集群：Web 服务器、J2EE 服务器和 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 服务器买 6 个 Lintel 服务器。” 但是在选择日常使用的硬件和操作系统 (OS) 时，成本就不再是我们唯一要考虑的。性能也极为重要，而且了解如何去诊断并解决性能衰退的问题就是架构一个好的部署方案的要害。 热点和瓶颈 在获得优化的性能水平的过程中，最主要的一个挑战就是在出现热点时能够正确地定位这些热点。这并不像听起来那么轻易。Steve 说，“非凡是当你拥有一个三层体系结构的时候。这个热点可能是 Web 高速缓存；可能是门户；可能是数据库；也可能是这三层中的任意一层上的 OS。这个热点还可能是网络。” 图 2：otn.oracle.com 的性能 这是来自Keynote 系统为期 1 个月的评测结果。Keynote 系统从万维网的评测代理对 Oracle 的网站性能进行了评测。这一服务帮助我们来诊断全球 Oracle 技术网的问题。　 即使在确定了位置以后，要想进一步知道引起热点的确切原因都是一件令人头痛的事。其他一些问题的边缘效应都可能引起热点。Steve 解释说，“例如，可能会找到某个网络的热点，但是真正的原因可能是因为某个服务器向网络接口推送了太多的信息。甚至可能是一些非常简单的原因，比如说网络接口限制为 10 兆之下而不是 100 兆。”Steve 提醒设计师一定不要忽视这些简单的原因。 此外，还有一些工具可以帮助设计师来诊断热点和瓶颈。厂商提供的工具经常是非常有用的，而且现有还有一些更为成熟的开发源代码可以用。Oracle 的企业治理器就有很优秀的评测能力。