PLM系統架構規劃、優化方法及案例分析（上篇）
4 服務器資源計算及分配
大部分PLM系統在產品手冊中，都會提供各層組件的資源消耗數據（見圖3）。但是這些數據一般都是基于實驗室的標準測試，只能作為理論計算的參考，實際中由于各個企業不同的業務種類、數據模型、業務場景不同，需要結合實際場景對PLM系統所需的服務器資源進行綜合評定。
4.1 資源計算所需理解的概念
●并發比例（Concurrency）：它是服務器硬件資源消耗的主要考慮因素。并發用戶數指的是某一時刻同時連入系統的用戶數，消耗資源的是并發用戶數而非許可證允許的用戶總數。但是在資源規劃計算階段，很難判斷今后生產系統并發用戶數的多少，因此一般采用經驗處理。可根據前文提到的需求分析報告中，業務數據增長量和同時在線人數，按照一定比例估算并發用戶數。如果系統使用率高，可以將并發比例設置在0.8～1之間，如果系統使用率一般，則最低將并發比例設置為0.5。
●CPU/Mem SDR，SiR：它是Siemens Global APA組織實驗室發布的關于TC系統每層組件CPU、內存消耗值的測試數據，針對每種主流操作系統平臺均發布有相對應的測試數據。其中CPU SDR值來源于第三方權威CPU性能測試機構 SPEC （http://www.spec.org）。SPEC發布的CPU性能測試數據為SiR。Mem SDR則完全來自于APA組織的測試結果。圖5和圖6給出了SDR與SiR參數的示例；
圖5 Siemens TeamCenter部署手冊中發布的EntERPrise Tier CPU SDR參數
圖6 SPEC機構在其官方網站上發布的測試數據
●CPU/Mem使用率（Utilization）：數據中心一般會設定主要應用服務器（TC系統中為EntERPrise服務器）CPU/Mem的閘值，如果系統資源超過閘值，就可以確認服務器資源緊張。不同的應用服務器其閘值可以做針對性的設定。
●擴展系數（Scaling Factor）：Siemens APA組織發布的測試數據一般是基于一組特定的場景，而且測試環境一般都非常理想。但是在PLM系統實際使用中，業務場景與數據肯定不是特別理想的環境，需要考慮系統長時間運行后產生的垃圾已經OS、硬件層面帶來的負面反饋效應。因此在計算資源消耗時，要按照一定的比例系數來適當放大所需的服務器資源。具體的擴展系數需要根據經驗值來定，一般取值范圍在1.5~2.5之間。
4.2 資源層組件所需資源計算
4.1.1 數據庫資源計算
●CPU SiR=(TotalUsers×Concurrency×CPUSDR)/CPU_Ultilization×Scaling_F；
●PGA=(TotalUsers×Concurrency×MemSDR)/Mem_Ultilization×Scaling_F；
●SGA=PGA*Ratio
●Mem Total=SGA+PGA+4GB
說明：部署Oracle數據庫時，SGA與PGA的比率可以取值為5-7之間，一般選取6；負載特別大的系統，可以選取8-10；MemSDR計算公式最后的4GB是為OS預留的內存空間；
4.1.2 卷資源計算
●CPU SiR=CPU_SDR/CPU_Ultilization×Scaling_F
說明：卷服務器的內存資源一般不進行計算，可以通過查詢TeamCenter幫助文檔中的System Administration手冊——Sizing the FMS fast cache章節來查詢（見圖7）。
注意：windows操作系統環境下，TC卷服務最大可調用的內存僅為2048MB。
圖7 Siemens官方幫助文檔—卷服務器資源應用快查表
4.3 應用層組件所需資源計算
●CPU SiR=(TotalUsers×Concurrency×CPUSDR)/CPU_Ultilization×Scaling_F；
●MemTotal=(TotalUsers×Concurrency×MemSDR)/Mem_Ultilization×Scaling_Fsctor×SafeF；
說明：在應用服務器實際使用過程中，因為不斷創建和關閉的服務池（tcserver）進程會產生一定的內存垃圾，并且這些內存垃圾在系統定期維護重啟之前無法被消除，所以必須考慮給予一定量的安全系數（ ，安全系數取值范圍可為1.2～1.5。
4.4 Web層組件所需資源計算
4.4.3 中間件服務器的資源計算
●CPU SiR=(TotalUsers×Concurrency×CPUSDR)/CPU_Ultilization×Scaling_F；
●MemTotal=SPEC_MemSDR/Mem_Ultilization×Scaling_F；
說明：如采用基于J2EE的中間件（weblogic或JBoss）需要考慮使用過程中GC（Garbage Collect，垃圾收集）方法造成的服務暫停時間。如果為中間件分配的內存過小，會造成系統響應遲鈍，吞吐量小的問題。也不可設置過多的內存給中間件，否則中間件啟動時間會很長容易造成與企業服務器上的應用層組件鏈接失敗的故障。
4.4.4 分發服務器的資源計算
●CPU SiR=(TotalUsers×Concurrency×CPUSDR)/CPU_Ultilization/WorkingH
說明：PLM系統的分發服務器一般是指分發業務模型程序（即客戶端程序）的文件分發服務器，對系統資源占用率較低，且大多運行在java環境中，故內存部分只需設置最大Heap Size=512MB即可。
4.5 服務器資源匯總
在計算好單層組件所需要的資源后，再根據系統架構匯總好所需的服務器數量及每臺服務器需要的資源。需要注意的幾點是：
●資源層和應用層服務器，每臺服務器至少為OS預留4GB的內存；
●有高可用性集群時：需要增大內存需求的安全系數，以保證發生故障遷移或負載均衡失敗時，服務器不至于被大量涌入的請求沖擊當機；
4.6 服務器硬件配置校核
當服務器資源計算完成后，可以請企業IT部門配合向服務器供應商或在SPEC組織查詢獲取最為匹配的服務器型號和配置信息。需要注意：
●計算的結果要考慮OS平臺的依賴性，可以多查閱PLM系統官方發布的兼容性文檔，避免因兼容性故障造成系統部署失敗；
●理論計算給出的配置一般較低，可以根據項目資金，合理的增加服務器的配置，避免短時間內用戶、數據暴增造成的服務器資源不夠用的情況。
5 硬件計劃審核和系統詳細設計
5.1 硬件計劃審核
一旦服務器資源確定后，需要盡快聯系硬件廠家進行服務器的采購。但是由于硬件規劃除了設計CPU、內存、磁盤等常見逐漸外，還涉及到存儲設備、網絡交換機、客戶端工作站等其他硬件資源。這些硬件資源的采購周期不一，有的進口設備采購周期甚至長達3個月。所以要求IT部門需要配合構架師制定一個采購計劃，并對采購計劃進行審核。審核的主要內容應該包括：
●采購硬件的清單（硬件BOM）
●硬件的兼容性信息
●硬件設備采購周期
●許可證點數與硬件設備是否相符合
5.2 系統基礎詳細設計
在服務器就位，正式安裝之前，必須做好系統基礎詳細設計，至少應當包含如下內容：
●服務器的磁盤劃分
●服務器存儲的文件系統確定
●服務器運行的OS環境與系統參數確認
●存儲設備的權限管理與存儲盤的劃分
●網絡信息的詳細配置
●集群的詳細配置（如果部署集群或高可用性服務時）
●虛擬化云計算的詳細設計（如部署在虛擬化平臺上或云計算平臺上時）
表2給出了服務器部署所需的系統詳細設計表格范本，可以參考在此范本上進行擴展和完善。
表2 服務器詳細配置總覽表示例
PLM系統架構規劃、優化方法及案例分析（下篇）
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文網址：http://www.guhuozai8.cn/html/solutions/14019312213.html
相關文章
