譯者 | 布加迪

策劃 | 云昭

RDBMS常常是公司所有數據中最關鍵的，自然不會消失，但也可以充當全面遷移到云端的錨點。  

云吞噬軟件，那么舊系統消失了么？當然沒有。

當今許多頂級企業要么遷移到云端，要么正在遷移中。作為IT組織的一部分，企業通常擁有一個或多個支持業務核心的大型關系數據庫管理系統（RDBMS）。這些龐大的老舊單體數據庫，往往是公司中最關鍵的數據，自然不會拋棄，恰恰相反，它反而可以充當全面遷移到云端的錨點。

無論是何種云戰略，為了確保成功上云，這些單體數據庫對于整個生態系統都必不可少，應該成為遷移戰略的一部分。

云遷移示例

當團隊試圖分離連接到大型關系數據庫的應用程序或小系統時，如圖1所示，就會出現常見錯誤。要取得成功，關系數據庫和所有連接的資源（無論是應用程序、輔助數據庫還是Web服務器等）必須作為一個整體來遷移。此外，這種成功需要一種策略來遷移大量關系數據、多臺服務器、安裝的軟件、作業和網絡配置，這些都是數據生態系統的一部分。

網絡是最后一個瓶頸，將是需要克服的最大挑戰之一。

1.數據引力：大型關系數據庫的影響

在過去，關系系統至少有兩層：關系數據庫層和應用程序或訪問層。在較復雜的設計中，它們有多層應用服務器，這些服務器用來管理FTP訪問、ETL/ELT、Web服務器、中間件以及與主關系系統密切聯系的相應數據庫。Oracle等一些平臺圍繞模式（schema）構建，這帶來了更龐大的數據庫：除非作為整體來對待，否則更難遷移。

首先，關系數據庫不斷發展壯大，RDBMS基于模式設計而不是較小的租戶架構，每個數據庫可能擁有TB甚至PB級的數據。視數據與其他系統的互連性而定，數據庫大小會產生自己的“引力”，將系統拉近數據源，進而提供最佳的用戶體驗。在云端，這種拉力被企業云的龐大覆蓋面放大了。

數據引力會將應用程序、連接的數據資產和資源拉到最龐大的數據體，這常常是擁有關鍵業務數據的遺留關系數據庫。

隨著更多的數據在應用程序和數據庫之間傳輸到更大的關系系統（通過ETL/ELT處理或數據庫鏈接），所有涉及的系統都需要與更大的關系系統緊密連接以消除延遲。這實際上是數據引力。

為云構建RDBMS時，必須考慮數據引力。不僅對于基礎架構而言，甚至對于服務而言，云解決方案必須了解應用程序和數據庫連接，才能部署它們以獲得最佳性能。設計從最大的系統開始，然后輻射到最小的組件/服務，確保最具影響力的系統獲得架構設計成功所需的關注。

2.全部遷移到云端，或什么都不遷移到云端

客戶遷移到云時，可能已用幾個遷移的系統作了嘗試，隨后決定將所有內容遷移到云端。考慮到這一點，目標是在本地不留下任何東西，這需要了解舊的關系系統以及將它們遷移到云端的要求。

這種逐漸遷移到云端的策略存在的最大弊端之一是，以前的較小云遷移項目可能已經將各種工作負載轉移到多個云上，如果系統之間存在數據交互，這會導致需要發現多云依賴項。網絡成為最后一個瓶頸，沒有人發現如何克服這個瓶頸。使用對等網絡和加速網絡，靠近數據中心可能有助于消除一些延遲，但正如圖3所示，除非開發新的網絡技術，否則這一挑戰會繼續存在。多云解決方案可以在云提供商之間提供一些數據優勢，但它們的運作永遠不會像單一云解決方案那樣。

云提供商之間的網絡延遲差異可能因地區和地理位置而異

克服跨云延遲問題的首要目標是確定每天、每周在諸環境之間需要移動什么數據。第二個目標應該是開發人員如何在本地執行工作，并針對云開發進行優化，盡可能消除多余環節。始終選擇簡化通過網絡拉取或推送數據時可能形成額外IO。

所有跨云數據處理應該經過全面測試，確保它能夠滿足業務需求，即使數據可能逐漸增多，也是可以接受的。

3.選擇：PaaS 還是IaaS？

調查云遷移后，平臺即服務（PaaS）和軟件即服務（SaaS），是供應商大力推銷的、號稱是所有本地技術的誘人選擇。用戶很高興聽到自己可以減少支持基礎設施和平臺的支出，但忘了在他們想要遷移到云的關系環境中已積累了多少技術債務。

（1）為什么非常大的RDBMS常常局限于Iaas？

一旦PaaS和SaaS顯然需要用戶放棄許多定制和功能，用戶會重新考慮基礎設施即服務（IaaS）。這歸因于多個因素，但大多數挑戰圍繞著多年來系統內置的復雜性以及SaaS/PaaS產品缺少功能。在決定云端與遷移到云端的數據資產有哪些選項時，應遵循這些簡單的指導原則：

SaaS：

• 新建項目
• 數據庫層不需要定制的代碼
• 系統采用應用驅動開發，數據存儲需求簡單
• 較小的用戶群和簡單的恢復點目標（RPO）/恢復時間目標（RTO）

PaaS：

• 新建項目
• vCPU、內存和 IO的資源使用輕松適應PaaS的限制
• 管理基礎設施的IT資源很少，或者希望擯棄這個要求
• 數據庫層實現的高級功能或定制選項較少

IaaS：

• 您接觸TB到PB級的大型關系系統
• 您需要與本地應用程序相同或相似的架構
• 您對資源有獨特的需求——IO、vCPU及/或內存
• 您有要求非常苛嚴的工作負載，有復雜的RPO/RTO和開發需求

如果需要使用IaaS，重要的是要認識到云供應商可以為一大堆工作負載提供解決方案，而關系工作負載很獨特，需要合適的IaaS解決方案來滿足要求。

（2）如何擴建RDBMS遷移策略？

遷移具有挑戰性，做好準備是取得成功的最佳途徑。無論您使用過時的客戶端/服務器架構還是大型機解決方案，具有多層系統的關系數據庫都需要規劃以確保成功。雖然每個項目都很獨特，但某些方面是共通的，如果作為計劃的一部分得到滿足，將有助于確保成功遷移。通用列表常常包括如下：

• 數據庫大小和復雜性
• 數據負載和連接的生態系統
• 應用程序、作業、Web 及其他服務器
• 網絡延遲

（3）RDBMS中必須識別哪些重要指標？

大多數關系型工作負載耗用大量資源——換句話說，它們對基礎架構的要求比其他工作負載更高。但是盡管我們可能專注于CPU和內存，但關系工作負載、尤其是Oracle之類的工作負載可能需要高IO存儲解決方案。

大多數IO存儲和基準測試側重于請求（IOP），然而，請求大小會有差異，從而使這些值會有水分。根據我的經驗，建議少關注IOP，確保圍繞虛擬機和存儲IO限制而選擇的解決方案能夠每秒處理兆字節數（吞吐量）。

（4）創建多層RDBMS復雜性

由于云端的服務、高可用性和備份發生變化，圍繞存儲的所有決策和解決方案都必須關注RPO和RTO。還應考慮可能與RPO/RTO不同的任何客戶正常運行時間SLA，因為服務可能被捆綁到作為架構一部分而選擇的存儲解決方案中。

確保所有架構決策都基于應如何為推薦的實踐設計云架構，而不只是復制客戶做入到其本地架構中的內容。這是云端常見的錯誤，會造成漏洞和冗余。

平移關系數據庫工作負載將是一個好的起點，這將消除現有本地硬件中固有的基礎架構債務。如果不考慮這種硬件，所有注意力都放在關系工作負載上，可以根據需要設計一種新的架構。

4.重要保證：構架框架

由于大多數數據生態系統不僅需要遷移主數據庫和連接的系統，還需要為非生產副本復制，因此構建一個可以作為DevOps實踐的一部分進行簡化、自動化和部署的框架非常重要。每次在沒有框架的情況下執行所有環環相扣的操作將非常耗時、容易出錯。

構建云遷移框架始于記錄將關系系統從端到端部署到云所需的內容。起步階段可能類似圖4中所示的大體示例，隨后可以擴建，以完成遷移項目計劃。

一旦擴建完成，使用工具和腳本盡量自動化，同時確保足夠大的靈活性，以便將來在眾多系統和架構中重用。

云遷移的大體框架示例

確保腳本語言和工具可以像云遷移一樣擴展，驗證它們可以管理基礎架構、關系系統和數據。問題出現并得到解決后，記錄下來，確保將來不會重演，從而不斷提高效率，作為云遷移策略的一部分。

5.結語

大型關系數據庫往往是許多云遷移項目的焦點。一旦遷移到云端，可能提議上多個項目，更新改造和消除這些舊系統，但它們的核心部分往往成為新應用戰略的基礎，數據駐留在同樣的關系系統中，就跟在本地環境中一樣。由于資源有限、缺乏ROI或工作量大，更新改造常常消除了改變系統的緊迫性。

隨著企業繼續向云遷移，將大型RDBMS作為這些數據中心和數據資產的一部分而遷移的推薦實踐將必不可少，因為這些關系系統在數據資產中仍將發揮作用。

原文鏈接：

??https://dzone.com/articles/migrate-rdbms-dinosaurs-to-the-cloud???