譯者 | 布加迪

策劃 | 云昭

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

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

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

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

云遷移示例

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

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

1.數(shù)據引力：大型關系數(shù)據庫的影響

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

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

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

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

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

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

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

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

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

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

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

3.選擇：PaaS 還是IaaS？

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

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

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

SaaS：

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

PaaS：

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

IaaS：

• 您接觸TB到PB級的大型關系系統(tǒng)
• 您需要與本地應用程序相同或相似的架構
• 您對資源有獨特的需求——IO、vCPU及/或內存
• 您有要求非?？羾赖墓ぷ髫撦d，有復雜的RPO/RTO和開發(fā)需求

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

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

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

• 數(shù)據庫大小和復雜性
• 數(shù)據負載和連接的生態(tài)系統(tǒng)
• 應用程序、作業(yè)、Web 及其他服務器
• 網絡延遲

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

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

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

（4）創(chuàng)建多層RDBMS復雜性

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

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

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

4.重要保證：構架框架

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

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

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

云遷移的大體框架示例

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

5.結語

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

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

原文鏈接：

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