譯者 | 布加迪

策劃 | 云昭

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

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

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

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

云遷移示例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.選擇：PaaS 還是IaaS？

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

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

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

SaaS：

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

PaaS：

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

IaaS：

• 您接觸TB到PB級的大型關(guān)系系統(tǒng)
• 您需要與本地應(yīng)用程序相同或相似的架構(gòu)
• 您對資源有獨特的需求——IO、vCPU及/或內(nèi)存
• 您有要求非常苛嚴的工作負載，有復雜的RPO/RTO和開發(fā)需求

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

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

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

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

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

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

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

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

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

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

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

4.重要保證：構(gòu)架框架

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

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

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

云遷移的大體框架示例

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

5.結(jié)語

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

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

原文鏈接：

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