既要治理對內的應用程序又要治理對外的 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 的企業治理器就有很優秀的評測能力。