既要管理對內的應用程序又要管理對外的 Web 站點
這種多樣性的工作使得 Steve 的團隊擁有另人驚異的
全方位的
使用 Oracle 產品的
綜合的 Web 經驗
Steve 說
我們已經部署了 OracleAS Container for J
EE (OC
J)應用程序
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 擁有許多 OC
J 應用程序
可定制應用程序和許多基於技術的內容服務
Steve解釋說
沒有一個是出自數據庫的
因此
要轉換成一個門戶
使其中的一切信息都來源於數據庫—並通過數據庫對所有內容進行管理— 這不只是對體系結構進行轉換
對於許多內容的所有者來說
這還將成為一種文化的轉換
Steve 的團隊最終確定實施這一項目的最佳方式就是按從前端到後台的方式進行
最終目標就是要將 OTN 移植到門戶上
但是我們還希望運行在 Linux 上的 OTN 可以真正證實 Oracle 的 Linux RAC 解決方案是可行的
基於這一點
我們希望新的 OTN 的性能即使不能超越現有 OTN 的性能
也不能比現在差
為此使用現有 OTN 的性能指標數值
我們可以向後對比的方式來工作
以確定什麼是新體系結構所需要的
明確性能目標幫助 Steve 的團隊架構了這個新的門戶解決方案
但這還不能稱作是真正的科學
前端是 Web 高速緩存
以及 HTTP 服務器和門戶服務器
其後則是位於兩節點 RAC 集群上的數據庫服務器
為門戶數據庫提供服務
除了產品的體系結構以外
Steve 確保有一個階梯層作為開發的一部分
如果沒有臨時分區
我們就寸步難行
他這樣解釋說
這是我們的必由之路
因為在你進行測試和部署的時候
你會想要將可能出錯的地方劃定在一個區域內
並進行驗證
得出結論
例如
你可能認為在 Web 高速緩存中調整一個參數會出現問題
但最後卻發現這樣做是不對的
為了回過頭來再次進行觀察
同時又不想中斷生產
那就必須將臨時分區作為系統的一部分
圖 通過利用 Oracle 應用服務器和 Oralce 數據庫獲得高可用性 正如上圖所示
如果某個集群上的某個節點發生故障
客戶請求就會透明地路由到該集群中的另一個節點
而終端用戶從來不會知道曾經出現過故障
這樣一來
在 Oracle 應用服務器上部署的任何商務應用程序都會保持正常運轉而不會中斷
這就確保了
計劃內的和
計劃外的宕機時間
正如可以從上圖中看到的那樣
Oracle 應用服務器在中間層支持三個層次的集群
Web 服務器
J
EE 服務器和 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 中的 OC
J？是 HTTP 或 Apache？是 Web 高速緩存？以上任何一
From:http://tw.wingwit.com/Article/program/Oracle/201311/17735.html
