一篇文章讀懂傳統架構到超融合架構的轉型升級中的裝置利舊與業務遷移
目前,越來越多的使用者因瞭解到超融合架構的巨大價值,計劃啟動傳統架構到超融合架構的轉型升級。但涉及到具體方案設計時,往往會遇到一些問題,其中 “超融合架構如何整合原來的架構” 就是使用者的關注點之一。一般來說,採用超融合架構,原有架構的整合和利舊通常包含軟體與硬體等各方面,比如原有的伺服器、儲存裝置是否可以利用?如何利用?原有架構業務如何遷移?本文將針對這些常見問題進行詳細解答。
傳統架構中哪些裝置會被替換?
首先,以 SmartX 產品為例介紹一下超融合架構和傳統三層架構的核心區別,以便了解原有架構整合時有哪些需要被替換的裝置。
透過上圖看出:
1.超融合架構最大的變化是使用 x86 伺服器和超融合軟體(分散式儲存模組)替代傳統的控制器架構 SAN 儲存;
2.傳統架構中僅用於計算的伺服器,在超融合的架構中,還用於執行分散式儲存軟體,並需增加 SSD 快取、萬兆網路卡以及用於儲存資料的硬碟,以實現資料儲存功能;
3. FC 交換機被標準的 10G 乙太網交換機替代;
4.虛擬化的部分可以繼續使用 VMware 或者使用超融合廠商的內嵌的虛擬化軟體,但需要確認超融合廠商對虛擬化的支援情況。
已有裝置和軟體如何利用?
伺服器可以利舊,但要注意相容性列表和穩定性。
如上介紹,超融合完全基於 x86 伺服器構建,所以使用者已有伺服器是可以用來構建超融合系統。但需要注意以下幾點:
1.需要保證伺服器以及配件都要嚴格符合廠商的相容性列表要求。一般來說,伺服器改造成超融合節點還需要加配 SSD、萬兆網路卡等配件;
2. 一個叢集中的硬體儘可能地保持配置統一,否則低配置節點會影響整體叢集的效能
3.儘管超融合的分散式儲存有副本保證可靠性,但一般來說超過3年的裝置不建議使用,一方面陳舊裝置的使用會提升多個裝置同時出現故障的機率,影響整體的穩定性;另一方面,老舊裝置配件的後續採購也是一大問題。
SAN儲存不能用在資源池中,但可以構建冗餘的系統
由於超融合系統透過分散式儲存軟體和 x86 伺服器構建了儲存池,所以原有的 SAN 儲存和光纖交換機都不需要整合在新系統中。在 SmartX 的客戶中,部分使用者會將產品用在核心生產業務中,並同時使用原有的儲存構建一個冗餘的系統。冗餘的方式可以採用應用層面的負載均衡和冗餘,也可以採用類似 Oracle Data Guard 做資料庫層面的冗餘(以上方式都需要增加部分伺服器),從而在超融合副本等技術的保護之下,再上一層保險。既增加了業務的可靠性,又利用了原有的裝置。
原有虛擬化軟體可根據情況選擇是否繼續使用
超融合模組除了包含分散式儲存,另一個重要的部分就是伺服器虛擬化軟體。對於虛擬化的支援,各家廠商產品的支援情況差異較大,例如 SmartX、Nutanix 除了支援 VMware ESXi 虛擬化平臺,還支援內嵌免費的基於 KVM 的虛擬化平臺;而其他廠商僅支援 VMware 或僅支援 KVM 的虛擬化平臺,使用者可以根據自身情況進行產品的選擇。
以下是市場主流超融合廠商的虛擬化平臺支援情況:
如果使用者當前正在使用 VMware ESXi 虛擬化,並且希望繼續使用該平臺,可基於已有的 VMWare 平臺構建超融合系統,選擇支援該平臺的廠商並且確認版本的相容性;如果想使用其他虛擬化平臺,則需要進行虛擬機器的遷移,將在下面的章節介紹。
業務的遷移
由於超融合架構需要構建一個新的分散式的儲存池和虛擬化平臺,所以資料和業務的遷移不可避免。由於市場主流虛擬化為 ESXi 與 KVM ,如下就主要針對這兩種虛擬化平臺討論一下如何進行業務遷移。
由於原有環境可能是 KVM 與 ESXi ,而遷移目的環境也是 KVM 與 ESXi,都是 V2V 的遷移,所以一共有有四種可能:
ESXi -> ESXi
KVM -> ESXi
ESXi -> KVM
KVM -> KVM
以下逐一介紹每中場景遷移的方法和對業務的影響:
1)ESXi -> ESXi
這種情況下的遷移最為簡單。將原有 ESXi 環境加入超融合的 ESXi 所在的 vCenter 中,可以利用 VMware 本身提供的 Storage vMotion 功能線上遷移資料到超融合叢集中,然後進行重新註冊虛擬機器,這樣可以儘可能地縮短遷移停機時間;如果 EVC 相容性支援的話,甚至可以利用 vMotion做到 0 停機的遷移。
2)KVM -> ESXi 或者 ESXi -> KVM
KVM -> ESXi 或者 ESXi -> KVM 這兩種遷移是跨 hypervisor 的遷移。這種跨平臺的遷移有廠商或第三方提供的工具支援。由於涉及不同 hypervisor 型別之間遷移,這種遷移大多數情況都會涉及停機。停機時間的長短與遷移虛擬機器的資料量、業務繁忙程度(遷移過程中的資料變化量)以及網路頻寬等因素都有關係。例如 SmartX 提供的 v2v 遷移工具,可支援對目標端虛擬機器執行快照。執行線上的資料遷移,等待快照傳輸完畢後,虛擬機器需要關機,再次進行差量資料的同步(快照傳輸過程中,資料的變化量)。同步完成後,即可在 SMTX OS 上開啟虛擬機器,並可對於主流的作業系統無需進行重新配置工作,可以有效減少停機時間。
3)KVM -> KVM
KVM -> KVM (不同版本或品牌的 KVM)的轉換一般來說也是比較簡單。因為磁碟檔案是通用的格式,基本是把虛擬磁碟進行匯出/匯入就可以正常使用,但是這種方法一般也需要少量時間進行停機遷移。
更多超融合專業知識,請前往 SmartX部落格超融合技術專欄。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69974533/viewspace-2695915/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 一文讀懂傳統虛擬化升級超融合架構中裝置利舊與業務遷移架構
- 超融合架構與傳統IT架構的區別架構
- 如何將傳統 Web 框架遷移部署到 Serverless 架構?Web框架Server架構
- 傳統應用系統架構向微服務應用架構升級的實戰案例微服務應用架構
- 浪潮資訊超融合方案助力土耳其雲服務商架構升級架構
- 讀書筆記 之《軟體架構設計: 大型網站技術架構與業務架構融合之道》筆記架構網站
- 金融信創與雲化轉型|基金超融合架構轉型與場景探索合集架構
- 金融信創與雲化轉型|期貨超融合架構轉型與場景探索合集架構
- 金融信創與雲化轉型|保險超融合架構轉型與場景探索合集架構
- 金融信創與雲化轉型|證券超融合架構轉型與場景探索合集架構
- 一圖讀懂阿里雲RDS架構與選型阿里架構
- 老闆:把系統從單體架構升級到叢集架構!架構
- Imagination升級PowerVR圖形架構,高階移動裝置或將迎來重大升級VR架構
- B2B商業模式轉型三要素:組織、架構、與遷移模式架構
- 微服務架構解析:跨越傳統架構的技術革命微服務架構
- 容器架構轉傳統lnmp架構(失敗篇)架構LNMP
- 企業網架構與安全裝置部署架構
- 超融合私有云基礎架構方案評估(架構與儲存篇)架構
- 招商證券業務系統基於OceanBase完成架構升級架構
- 服務架構學習與思考(12):從單體架構到微服務架構的演進歷程架構微服務
- 清晰架構(Clean Architecture)的Go微服務—重大升級架構Go微服務
- 醫院超融合方案:廣醫三院 IT 基礎架構升級中從選型評估到決策落地架構
- XView 架構升級之路View架構
- ORTC與SIP融合通訊服務架構架構
- 深度解讀!阿里統一應用管理架構升級的教訓與實踐阿里架構
- 數商雲:B2B商業模式轉型三要素:組織、架構、與遷移模式架構
- 讀懂Netty的高效能架構之道Netty架構
- 單體架構&微服務架構&中臺服務架構架構微服務
- 超融合架構與產品選型的選型評估過程及實施方案架構
- 一文讀懂微服務架構——【詳解】微服務架構
- 一張圖讀懂阿里雲資料庫架構與選型阿里資料庫架構
- SOA/ESB架構升級之路:從微服務到ServiceMesh,再到Sermant架構微服務
- 《架構基礎 從需求到架構》讀書架構
- 從單體架構到分散式微服務架構的思考架構分散式微服務
- 架構與思維:微服務架構的思想本質架構微服務
- 業務架構架構
- 關於軟體架構和業務架構的思考架構
- 什麼叫超融合基礎架構?架構