部署和管理應用程序的 Oracle AS 特性

2024-08-29 13:38:11

字體：大中小

來源：轉載

供稿：網友

　　今天的 web 應用程序處在極為兩難的狀態之中 — 它們必須足夠強大以處理高峰負載，還要足夠靈活以便可以輕易地修改和伸縮。要害的商務事務現在通過瀏覽器來進行處理，并且這些要害事務要求每周 7 天天天 24 小時的正常運行時間。停機時間只是帶來失望和造成收入損失，而拖延可能意味著客戶將點擊轉向實力最為接近的競爭對手。
　　
　　過去，構建高性能、高可用性的 web 應用程序意味著要付出高價，要為大型硬件和昂貴的軟件支付大筆費用。今天，部分得益于像 linux 集群這樣的操作系統改進，以及得益于緊縮的 IT 預算，更多商用級價格水平的硬件正被大家所使用。但商用硬件也意味著更多的治理問題；更多的負載均衡問題，非凡是對于動態內容；當部署或升級應用程序時更多的要處理的機器；一旦服務器節點出現故障而引起的潛在故障或可能導致的瓶頸，等等。
　　
　　下面我們分兩部分來分析新的 Oracle application Server 10g (OracleAS 10g)，以及該軟件如何處理可用性、性能和治理問題，以使在商用硬件上運行應用程序變得簡單且非常可靠 — 并且在這個過程中，使集群和企業網格計算更易于控制。第一部分將研究用來確保高可用性的 OracleAS 10g 特性。第二部分將研究該軟件確保高性能和使應用程序治理變得更輕易的特性。
　　
　　永遠離別了堪薩斯的日子
　　記得堪薩斯嗎？回顧我們購買那些大型、昂貴、單一的服務器來保持我們的應用程序持續運行的時候。我們在前面扔掉了一些 web 服務器，然后讓大型計算機來處理所有繁重的負載。然而，經歷了一場風暴，那些堪薩斯的日子一去不返了。IT 預算被削減，在發展的要害轉折階段，為了進一步提高生產效率并降低成本，對 Web 應用程序的要求也更高了。
　　
　　為了控制 IT 成本，公司（包括 Oracle）將運行要害商務應用程序的任務分派給了更便宜的商用服務器。但在商用服務器中，每個機器的負載容量更少了，而且更便宜的服務器更可能出現故障。存儲器和操作系統方面的改進提供了一些幫助，但實際情況仍然是運行商用硬件意味著使用多得多的服務器，這反過來導致更多的故障節點和瓶頸。
　　
　　集群技巧和技術被設計用來在出現故障的情況下提供冗余，有助于跨一個服務器群均衡負載，以使單個機器不會因為超載而變得滯塞。現在獲得的推動力是網格技術；使用了能夠處理極高工作負載的鱗次櫛比的互操作服務器的硬件和軟件體系結構 — 實質上是一個龐大的集群的集群。
　　
　　問題是：是否能夠把低成本商用服務器的集群和網格真正轉變成高容錯的系統 — 今天的 web 應用程序需要的這種高可用的系統?您將看到，答案是肯定的。
　　
　　高級的端到端集群
　　傳統上，集群意味著重點是負載均衡 — 在服務器之間劃分任務和用戶來避免單個機器超載。假如一個節點出現故障，用戶連接經常被終止或該服務器完全不可用。其它服務器還在運行，但被斷開的用戶不得不重新與它們連接，也就是說，假如剩余的服務器還沒有因其它的用戶而超載。甚至在剩余的服務器能夠處理更多的負載時，它們也可能不會這么做 — 它們被限制在最初配置時設定的用戶數之內了。
　　
　　隨著時間的推移，硬件和軟件解決方案得到了發展，它們超越了負載均衡的范圍來更好地治理出現故障的意外情況。但這些點解決方案經常成為瓶頸或它們自己成為單個故障節點。
　　
　　OracleAS 10g 使用了 Advanced Clustering 來實現更多的功能。這個軟件不僅使均衡負載在一個集群中的服務器上變得輕易，而且還能夠檢測故障并在剩余的服務器上重新分配任務來無縫地承擔額外的工作負載。例如，在一個三節點的集群中，節點 A、B 和 C 承擔了相等的工作負載。假如在一個 10g 集群中£節點 C 出現了故障，則將自動對節點 A 和 B 重新分配任務來繼續處理節點 C 的工作負載，就像什么也沒有發生過一樣。
　　
　　但今天的多層次應用程序甚至比上面的例子更復雜。它們可能有專門分配給應用程序層的節點和分配給 web 服務器層的單獨的節點。假如應用程序使用了高速緩存（我們一會將討論這個主題），則可能存在專門為 web 高速緩存層分配的節點。在一個多層次應用程序內部的任何節點上出現的節點故障都可能引起層疊的效應。（參見圖 1。）
　　部署和治理應用程序的 Oracle AS 特性

　　OracleAS 10g 的 Advanced Clustering 的前提是它能夠自動適應任何層次上的故障。假如一個 HTTP 集群中的一個節點出現了故障，則客戶請求將被透明地路由到集群中的另一個節點上，終端用戶永遠不會知道曾經出現了故障。
假如 J2EE 集群層上的一個節點中止了，OracleAS 10g 確保另一個節點承擔它的工作。這避免了單個故障節點。因而，甚至在不同層上的節點同時出現故障的時候，部署在 OracleAS 10g 上的任何商務應用程序也將保持無中斷地運行。
　　
　　故障切換和恢復特性
　　當出現故障時，應用程序繼續運行，并迅速解決問題以確保快速恢復是至關重要的。為了加快端到端應用程序故障切換的時間，OracleAS 10g 提供了多層次的故障切換通告。利用這個特性，OracleAS 10g 用戶能夠將與跨層次的應用程序故障切換相關的 TCP/ip 超時延遲從 15 分鐘減少為 5 秒。
　　
　　為了保護集群系統不受故障的影響，OracleAS 10g 采用了冷故障切換集群 (Cold Failover Clusters CFC)，從而實現了從出現故障的主集群到一個從屬集群的切換。為了獲得更高的可用性，OracleAS 10g 甚至提供了活動故障切換 (Active Failover Clusters AFC)。假如一個節點出現了故障，接下來進入的請求將立即在剩余的節點之間重新分配，從而消除了任何停機時間。
　　
　　OracleAS 10g 為何能夠變得這么智能化和靈敏？一個原因是一個稱為 Web Cache 的非凡的軟件元素。由于 Oracle 10g 的出現，Web Cache 成為多層次應用程序中的第一層。
　　
　　利用 Web Cache
　　OracleAS 10g Web Cache 是獨一無二的，它確保了高性能和高可用性。Web Cache 還可以無縫地與來自 BEA、IBM、ATG、Sun、Apache 和 Microsoft 等的第三方應用程序和 web 服務器一起工作，因此它可以為您的整個 Web 體系結構提供幫助 — 無論它是否建立在 Oracle 之上。
　　
　　下面我們將研究 OracleAS 10g Web Cache 的高可用性功能，高性能特性留待我們的第 2 部分再討論。
　　
　　Web Cache 面向服務器節點，并像常規的高速緩存一樣，響應所有的入站 HTTP 請求，并根據每臺 Web 服務器的容量分配這些請求。回到我們假定的由節點 A、B 和 C 組成的集群中，我們可以配置 Web Cache 來將 30% 的負載分配給 Web 服務器 A，另外的 30% 給 Web 服務器 B，40% 給 Web 服務器 C。
　　
　　OracleAS 10g Web Cache 有一個要害的優點：假如三臺服務器中的一臺出現了故障，Web Cache 自己可以自動將該負載的 50% 重新分配到剩余的兩臺 Web 服務器上。當出現故障的服務器回到在線狀態時，Web Cache 將負載重新分配回所有的三臺服務器，而所有這些對用戶都是透明的。
　　
　　OracleAS 10g 還自帶了許多有助于改善應用程序內部的數據可用性的特性 — 甚至當應用程序擴展和使用率增加時。這些特性包括智能化的路由和治理工具，這些工具使 OracleAS 10g 能夠執行容量驅動的路由，其實質是預先關注集群中服務器的容量，然后相應地均衡進入的負載。這種路由智能化與 Web Cache 一起創建了一個對內容敏感的負載均衡系統，以分配所有的 HTTP 請求。
　　
　　與 OracleAS 10g 其它的可用性特性協作，Web Cache 解決了使用商用服務器的一個要害問題：當出現故障時，如何自動調整服務器負載，而無需重新配置服務器或引入單個故障節點。
　　
　　但假如在這個 Web Cache 層出現了故障，情況會怎樣？這不會成為單個故障節點嗎？回答當然是“不會”。在 OracleAS 10g 中能夠讓一個 Web Cache 與集群中其它的 Web Caches 通信，從而將它們連接在一起來提高總體的緩存容量。這種通信還可以在一個高速緩存集群成員出現故障時檢測出來。例如，假如一個節點上的高速緩存出現故障，則集群中其它的成員可以承擔額外的高速緩存負載 — Web Cache 可以無縫地處理它自身的故障。
　　
　　Web Cache 僅是 OracleAS 10g 中所帶的各種各樣性能和可用性元素中的一個。在其表面之下，您將發現一個輕型且非常強大的 J2EE 引擎，它具有一個令人吃驚的微小內核。在第 2 部分中，我們將討論許多用來部署和治理您的 Web 應用程序的命令和控制工具。以及具有記錄回放功能的監控和分析工具，以根據實際用戶的經驗確保一切都優化地運行。而在性能方面，OracleAS 10g 提供了幾個加速您的應用程序的選項 — 單獨使用 Web Cache 就可以加速您的應用程序達 20 倍。但這是第 2 部分要討論的內容……

上一篇：關于Oracle10g跨平臺傳輸表空間

下一篇：對Oracle自己的Web運營所進行的幕后觀察