模板
教程
环境
性能
功能
管理
对Oracle自己的Web运营所进行的幕后观察
既要管理对内的应用程序又要管理对外的 Web 站点，这种多样性的工作使得 Steve 的团队拥有另人惊异的、全方位的、使用 Oracle 产品的、综合的 Web 经验。Steve 说，“我们已经部署了 OracleAS Container for J2EE (OC4J)应用程序、Web 高速缓存、移动服务、
既要管理对内的应用程序又要管理对外的 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 高速缓存中调整一个参数会出现问题，但最后却发现这样做是不对的。为了回过头来再次进行观察，同时又不想中断生产，那就必须将临时分区作为系统的一部分。”
正如上图所示，如果某个集群上的某个节点发生故障，客户请求就会透明地路由到该集群中的另一个节点，而终端用户从来不会知道曾经出现过故障。这样一来，在 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。这个热点还可能是网络。”
这是来自Keynote 系统为期 1 个月的评测结果。Keynote 系统从万维网的评测代理对 Oracle 的网站性能进行了评测。这一服务帮助我们来诊断全球 Oracle 技术网的问题。
即使在确定了位置以后，要想进一步知道引起热点的确切原因都是一件令人头痛的事。其他一些问题的边缘效应都可能引起热点。Steve 解释说，“例如，可能会找到某个网络的热点，但是真正的原因可能是因为某个服务器向网络接口推送了太多的信息。甚至可能是一些非常简单的原因，比如说网络接口限制为 10 兆之下而不是 100 兆。”Steve 提醒设计师一定不要忽视这些简单的原因。
此外，还有一些工具可以帮助设计师来诊断热点和瓶颈。厂商提供的工具常常是非常有用的，而且现有还有一些更为成熟的开发源代码可以用。Oracle 的企业管理器就有很优秀的评测能力。
Steve 建议最起码也要对体系结构进行权威性的负载测试和 OS 评测—特别是磁盘 I/O、内存的使用情况和 CPU 的使用情况和这些部件在负载下的表现。“如果你在 OS 中发现了一个热点，那么你是否能确定是什么引起该热点的吗？查看一下可能引发这一热点的技术。是 Java 中的 OC4J？是 HTTP 或 Apache？是 Web 高速缓存？以上任何一个都不是？”
Steve 还建议查看一下系统是如何与机构中其他 IT 职能部门进行交互的，特别是涉及到备份脚本。“这非常有趣。当我们试图要定位某个热点时这种热点可能会成倍增加，因为由于我们的原因备份脚本已经运行了。这是一个整体，但却和实际部署没什么关系。”
Steve 的团队只是简单得调整备份脚本在不同的时候暂停，以便在服务器中分配负载。
在排除了一些基本的原因后，就该将诊断推进到下一个层次，并要开始关注各个层自身的问题，系统地排除 OC4J、内存、CPU 使用情况—任何可能因为负载问题引起机械性过载的事物。
一旦这些原因的可能性都被排除，Steve 建议深入到实际的应用程序，但是他提醒设计师一定要小心不要与那些只有开发人员才能解决的问题纠缠。“在 Global IT，我们不是开发人员，我们只部署应用程序。但是，我们会向开发人员提供尽可能详尽的信息来确定应用程序内存在的问题，这样他们就可以对其进行调试和修改。”
但是要避免瓶颈和热点，设计师需要正确建立的可以进行工作的数据中心。对于 Steve 的团队来说“正确建立的”可以归结到一个词：冗余。
用冗余来构建
“在谈到数据中心的运行时，冗余极为重要”，Steve 解释说。“它是任何数据中心的主要目标之一—减少应用程序的宕机时间。”
这是来自Keynote 系统为期 1 个月的评测结果。 Keynote 系统从万维网的评测代理对 Oracle 的网站性能进行了评测。这一服务帮助我们来诊断全球 Oracle 技术网的问题。
Steve 指出在整个数据中心必须有冗余。 “在谈到数据中心的运行时，冗余极为重要的它是任何数据中心的主要目标之一—要减少应用程序的宕机时间。”操作。例如，在网络中设置冗余的交换机，并配置中间层的服务器使用不同的交换机。如果某个交换机发生了故障，用户仍然可以使用应用程序。Steve 还推荐使用多个中间层—而且我又要提到这样的论点，就是使用 Lintel 解决方案会使这一方案在经济上变得可行。“如果你的中间层之一死机了，该应用程序也不会有问题。”
对于 Oracle，即使是传输层—伸入到建筑物内的管道—也有冗余。Steve 解释说，“我们总是拥有从 ISP 流入的冗余网络管道；如果带有破坏工具人就在邻近的建筑并掐断了我们的主线，但是我们还有一条备用线。我们的冗余线就会连接到冗余交换机，交换机为了实现负载均衡使用冗余的 Big IP，这些 Big IP 可以使用冗余的中间层。”
Steve 是使用 Big IP 来进行负载均衡的推崇者，因为这样做也可以对冗余有所帮助。“假设一个中间层的机箱死机并开始冒烟，”，他解释说，“Big IP 检测到这个机箱宕机了，并将相应的网络流量路由到另一个服务器上，对于我们来说是另两个中间层服务器。这就是为什么说拥有冗余的硬件总是很重要，因为在替换另一个硬件的时候，现在剩下的两台服务器可以响应各种请求。”
冗余的另一个重要方面就是一致性的重要性，也就是说在涉及到软、硬件时，要保持系统体系内的一致。Steve 说，“我希望在我的集群中进行混合和匹配。他们清一色地全是 Linux；来自同一家厂商；使用同样的配置；全部是相同的尺寸。”
一致性还可以使补丁管理更为简单而不会有间断。对于 Steve 的团队来说，这些冗余和一致性目标强调了临时分区—最少要两台服务器，这样它们才可以在不影响生产的情况下集群在测试部署进行的地方。Steve 解释说，“我们按阶段分批测试了所有的补丁，从而来确保这些补丁是正确的。一旦要我们这样做，我们就在其他服务器继续运行的同时抽出一台中间层服务器。一旦补丁得到确认，我就将这台中间层服务器放回到集群中，然后再安装下一个补丁，以此类推，并从来没有中断过服务。我将给整个系统安装补丁，而没有间断。”
如果在整个过程中出现故障，Steve 的团队可以依靠冗余服务器，甚至只是临时服务器之一，只要所有部件一直保持一致，这就不是个问题。
负载均衡器 - F5 Labs BigIP HA+
中间层 — Dell 2650. 2 X 2.4 GHz, 6GB RAM。RedHat AS 2.1、Oracle 应用服务器（带有Web高速缓存，门户）
数据库服务器 — Dell 6450. 4x900MHz， 8GB RAM， RedHat AS 2.1，Oracle 真正应用集群
存储器 — Network Appliance NetApp 960C（集群的）
使用 Web 高速缓存减轻负载
性能平衡的一部分就是尽可能地优化内容的传输，从后台系统中尽量减轻后台系统的负载并将用户经常访问的数据位置放在离用户更近的地方。进入Web高速缓存。Steve 解释说，“例如，索引页和网站的首页是每个访问者访问的第一个页面。如果没有 Web 高速缓存，当出现页面请求时，就要访问 Apache；Apache 服务器会到文件系统中搜寻所需的页面，然后回送所需内容，并引起一次 I/O访问和一次内存访问。Web高速缓存所做的就是将经常使用的内容尽可能地调入内存中，从而减少I/O访问的次数。”
Steve 的团队则做得更多，他们也运用了 Edge Side Includes (ESI) 的分阶；一种连定制的内容都可以优化的独创方式。下面就是 Steve 对如何使用带有 Web 高速缓存的 ESI 标记所进行的讲解：
“实际上，你可以开发许多应用使用ESI 标记来获取用户定制的视图，并且将许多使用率最高的内容缓存到内存中。这就使得你能访问你的中间层（和数据库），因为只有很少的一部分定制内容是你希望服务来返回的。我们已经看到使用这种方法所取得的高性能，因为使用这种方法你无需进行 I/O 访问，也不需要通过网络访问数据库以收集返回信息。你不需要这样做。
“我们为 OTN 网站所做的一件事就是利用 ESI 标签来保持对用户定制内容的检查。所以您所看到的用户定制内容可能只是页面的 20%。所以为什么每次显示都要访问数据库呢？因此我们所做的就是同我们的开发团队一起将 ESI 标签与应用程序集成起来。这不是一个标准，但在开发应用程序时，我们强烈向您推荐在配置 OC4J 应用程序时，使用 ESI 标签。如果在您点击的页面中有 80% 也将被其他所有人访问的话，为什么不把它们放入内存中去，只有在真正需要时才访问您的数据库呢？”
