自2001年Google CEO Eric schmidt首次提出了云計算的概念至今，云計算技術的發展已從提出概念到技術實現，其應用也從互聯網服務擴大到了企業內部IT基礎設施建設范疇。G009le公司宣稱，由于使用了云計算技術，其計算成本僅為競爭對手的1／100，存儲成本僅為競爭對手的1／30，這讓云計算技術一時之間成為行業內最令人矚目的焦點。業界國外IT巨頭如Amazon、Microsoft、IBM、Yahoo等都紛紛推出自己的云計算戰略以及商用技術產品，而國內廠家如世紀互聯、百度、阿里巴巴、華為也都在積極推進相關應用。國內外電信運營商也不甘落后地加入云計算陣營，開展嘗試引入云計算技術。
為了滿足運營管理的需要，電信運營商建設了大量的IT系統，而這些系統大小規模不一、用途各異且又相互獨立，每年以數以萬計的規模遞增。引入云計算技術，將有利于快速部署業務，提高IT系統的資源利用率，可有效降低企業建設和維護成本，使經濟效益實現最大化，更為企業技術、業務和管理創新帶來了新的契機。
1 業務平臺的建設現狀
目前運營商的業務平臺種類及數量多達百級，業務平臺建設方面存在諸多問題，主要包括：
(1)建設周期過長：目前，工程建設從立項、可研、采購至實施完成需要大量時間，周期一般在半年左右，無法滿足新業務新產品快速上線的要求。對于業務量高速增長的業務平臺，也往往因為建設周期過長無法及時擴容，無法支撐業務進一步開展；
(2)資源利用率較低：目前業務平臺的建設一般按照業務峰值進行平臺設計和資源采購，導致平臺容量規劃過大。在絕大多數時間，平臺的實際利用率較低，服務器等設備空轉，資源利用率較低，導致大量的資源浪費；
(3)孤立建設：目前大量業務平臺孤立建設，難以實現業務平臺之間的資源互補與共享。各平臺資源需求和實際利用率差異較大，在目前的環境下，無法調配空閑平臺的資源給其它平臺使用。
2 業務平臺向云平臺遷移的方案分析
業務平臺向私有云遷移首先需評估業務平臺遷移至云平臺的可行性，在分析結論可行的基礎上，再進一步分析具體的遷移方案，最后還要考慮遷移至云平臺的具體業務部署方案。
2．1業務平臺云遷移可行性分析
業務平臺向云平臺遷移的可行性分析的具體步驟和方法如圖l所示，首先對業務平臺的業務特性、平臺特點、平臺定位、收益、風險進行全面系統的梳理及分析，然后根據分析結果制定業務平臺向云平臺遷移的策略。具體的策略包括：
(1)平臺遷移：稍作修改遷移到云計算環境；
(2)平臺改造后遷移：先對應用軟件進行架構改造再進行遷移；
(3)不實施云策略：暫時無法進行遷移。
圖1 向云平臺遷移的規劃及分析
業務平臺是否適合遷移至云平臺，首先需要根據業務特性、平臺特點、平臺定位等方面進行初步評估。適合向云平臺遷移的業務平臺應具有如下特點：平臺對硬件無特殊依賴性，平臺的應用服務器可通過增加節點的方式提高處理能力；平臺的應用系統與數據存儲能有效分離；模塊化設計，且模塊之間通信實時性要求不高。平臺架構以PC／刀片服務器為主。
除此以外，還需要考慮平臺遷移至云平臺可以獲得的收益和可能的風險。改用云計算技術的部署方式，是否可以滿足工程建設需要、是否可以實現業務平臺整合和資源共享等預期收益。最后還要從技術方面、初始建設成本、運維管理等方面評估遷移至云平臺的風險。
需要指出的是，對于具體業務平臺在正式遷移至云平臺之前，需要對業務平臺的特性、效益及風險進行量化分析，確定資源需求才能制定具體的云平臺遷移策略，且要充分考慮回退方案。
2．2業務平臺云遷移方案分析
業務平臺工程的云遷移應該考慮到新建、改擴建等工程建設性質的不同。考慮到云計算具有實現業務平臺整合和資源共享、實現業務快速部署、有助于節能減排、節省建設及人員成本等技術優勢，因此新建業務平臺工程應盡可能引入云計算技術，部署在私有云上。對于一些有特殊業務特性的業務平臺，如涉及敏感數據的業務。非IP化的業務，如部分語音類業務；大規模實時性處理業務；業務流程不統一。需要定制化的業務等可暫不考慮部署在私有云上。
對于改擴建工程來說，向云平臺遷移方案比較復雜，需要考慮的因素比較多。需要遵循的原則包括：盡量避免或減少對業務帶來影響，盡量保護原有設備的投資，減少投資浪費，兼顧長遠發展等。下面將重點分析改擴建工程業務平臺(即原有業務平臺)的云遷移方案。
對于原有業務平臺來說又分為多節點業務平臺系統和單節點業務平臺系統，多節點業務平臺系統是指由多個系統來共同提供某業務，多個系統之間是按照不同業務、不同用戶等劃分方式負載分擔業務t單節點業務平臺系統是指由單一的系統設備來提供某業務。對于多節點系統來說，在論證遷移至云平臺可行的基礎上，遷移方案相對簡單些，可考慮先將某一個或幾個節點遷移到私有云上，將這些節點原有業務割接到其它節點上；待部署在私有云上的節點運行穩定后，后續將其余節點系統逐步遷移到私有云上。而對于單節點系統來說，向私有云遷移方案較復雜，與每個業務平臺的系統架構有關系，下面將以某運營商的郵箱系統為例來分析具體的遷移方案。
郵箱系統作為典型的互聯網業務，從業務特性來說適合遷移至云平臺，且平臺架構以PC／刀片服務器為主，平臺對硬件無特殊依賴性，平臺的應用服務器可通過增加節點的方式提高處理能力·平臺的應用系統與數據存儲能有效分離；模塊化設計等，這些特點使得郵箱系統適合遷移至云平臺。
某運營商的郵箱系統是單系統業務平臺，全網只有一套系統為所有用戶服務，設備集中設置在某城市。且其上的用戶規模已經達到億級以上的用戶，且郵箱系統保存的用戶郵件等數據也達到了幾PB，因此，郵箱系統向云平臺遷移有兩種方法：部分遷移和整體遷移。部分遷移是一種逐步遷移到云的方法，先將部分功能及設備遷移到云平臺上，后續逐步實現向云平臺的全部遷移。整體遷移是一次性將郵箱系統全部遷移到云平臺上。
2．2．1部分遷移方案
考慮到目前云平臺的成熟度，以及原有設備的利舊使用，郵箱系統向云平臺遷移可采用部分遷移方案，即將部分設備遷移到云平臺，部分設備仍部署在原有機房保持不變。目前郵箱系統架構是集中式的架構，不適合分布式部署，因此為了遷移到云平臺上，首先需要對現有的郵箱系統架構進行改造，如可改為中央節點+分節點的分布式架構，中央節點提供服務入口，并根據用戶歸屬節點及路由信息將業務路由到歸屬分節點；業務節點為用戶提供實際服務，不同的業務節點按照省份劃分為不同的用戶提供業務。考慮到郵箱系統后續將逐步全部遷移至云平臺，因此該方案中建議將中央節點的功能及設備都遷移在云平臺上，同時還要遷移其中一個業務分節點的功能及設備到云平臺上，而原有郵箱系統未遷移的設備組建成另外一個業務分節點。這種架構設計以及部署方案便于未來原有設備的逐漸退網，將整個系統全部遷移到云平臺上，同時還兼顧到將來郵箱系統可能部署在不同城市的多個云平臺。
2．2．2整體遷移方案
目前郵箱系統是集中式的架構，考慮到盡量減少對現有系統架構改造的因素，也可將郵箱系統整體遷移到云平臺上。
2．2．5方案對比分析
上述兩種方案都各有優點和缺點，具體的方案對比分析如表1所示。
通過上述對比分析，可以看出不同的遷移方案各有優劣，在業務平臺向云遷移具體選用何種方案需根據工程的具體情況進行分析及選擇。
表1 部分遷移方案和整體遷移方案對比分析
圖2 根據服務器性能要求部署資源池
平臺的業務部署業務平臺遷移至云平臺主要的出發點是提高設備利用率，因此在部署中必須考慮錯峰填谷、安全性、資源共享的效率等，業務部署需要遵循以下原則：
(1)云劃分資源區域，為需要一定隔離、應用類型不同的業務提供資源承載；例如將應用服務器、數據庫服務器和web服務器部署在不同的資源區域；
(2)分析業務平臺對資源需求的時間特征，將不同時段需求不同的業務平臺進行資源共享，實現錯峰填谷，例如將工作時間需求量較大的業務平臺與夜間需求量較大的業務平臺部署在同一物理設備上。
(3)分析業務平臺對資源的需求特征，將對不同資源的需求不同的業務平臺進行資源的共享。例如將對內存密集型的業務平臺與IO密集型的業務平臺部署在同一物理設備上。
根據業務平臺不同部分對服務器性能要求的差異，建立不同的資源池的例子如圖2所示。業務平臺的接口服務器、管理服務器、應用服務器和數據庫服務器對性能要求存在較大差異：例如接口服務器對性能要求不高，可以通過多臺服務器提供多個線程即可，應用服務器需要CPU能力較強，數據庫服務器對CPU和內存要求較高等。對每個大類的服務器，根據其性能要求分別建立子資源池．每個平臺從不同的子資源池中獲取資源部署虛擬機，同一個平臺的虛擬機經過高速網絡互聯。不同平臺的虛擬機部署在同一物理服務器上，需要考慮錯峰填谷效應。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：業務平臺云遷移方案的探討時間
相關文章
