建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 布加迪
策劃 | 云昭
RDBMS常常是公司所有數(shù)據(jù)中最關(guān)鍵的，自然不會消失，但也可以充當(dāng)全面遷移到云端的錨點(diǎn)。
云吞噬軟件，那么舊系統(tǒng)消失了么？當(dāng)然沒有。
當(dāng)今許多頂級企業(yè)要么遷移到云端，要么正在遷移中。作為IT組織的一部分，企業(yè)通常擁有一個(gè)或多個(gè)支持業(yè)務(wù)核心的大型關(guān)系數(shù)據(jù)庫管理系統(tǒng)（RDBMS）。這些龐大的老舊單體數(shù)據(jù)庫，往往是公司中最關(guān)鍵的數(shù)據(jù)，自然不會拋棄，恰恰相反，它反而可以充當(dāng)全面遷移到云端的錨點(diǎn)。
無論是何種云戰(zhàn)略，為了確保成功上云，這些單體數(shù)據(jù)庫對于整個(gè)生態(tài)系統(tǒng)都必不可少，應(yīng)該成為遷移戰(zhàn)略的一部分。
云遷移示例
當(dāng)團(tuán)隊(duì)試圖分離連接到大型關(guān)系數(shù)據(jù)庫的應(yīng)用程序或小系統(tǒng)時(shí)，如圖1所示，就會出現(xiàn)常見錯(cuò)誤。要取得成功，關(guān)系數(shù)據(jù)庫和所有連接的資源（無論是應(yīng)用程序、輔助數(shù)據(jù)庫還是Web服務(wù)器等）必須作為一個(gè)整體來遷移。此外，這種成功需要一種策略來遷移大量關(guān)系數(shù)據(jù)、多臺服務(wù)器、安裝的軟件、作業(yè)和網(wǎng)絡(luò)配置，這些都是數(shù)據(jù)生態(tài)系統(tǒng)的一部分。
網(wǎng)絡(luò)是最后一個(gè)瓶頸，將是需要克服的最大挑戰(zhàn)之一。
1.數(shù)據(jù)引力：大型關(guān)系數(shù)據(jù)庫的影響
在過去，關(guān)系系統(tǒng)至少有兩層：關(guān)系數(shù)據(jù)庫層和應(yīng)用程序或訪問層。在較復(fù)雜的設(shè)計(jì)中，它們有多層應(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è)計(jì)而不是較小的租戶架構(gòu)，每個(gè)數(shù)據(jù)庫可能擁有TB甚至PB級的數(shù)據(jù)。視數(shù)據(jù)與其他系統(tǒng)的互連性而定，數(shù)據(jù)庫大小會產(chǎn)生自己的“引力”，將系統(tǒng)拉近數(shù)據(jù)源，進(jìn)而提供最佳的用戶體驗(yàn)。在云端，這種拉力被企業(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í)際上是數(shù)據(jù)引力。
為云構(gòu)建RDBMS時(shí)，必須考慮數(shù)據(jù)引力。不僅對于基礎(chǔ)架構(gòu)而言，甚至對于服務(wù)而言，云解決方案必須了解應(yīng)用程序和數(shù)據(jù)庫連接，才能部署它們以獲得最佳性能。設(shè)計(jì)從最大的系統(tǒng)開始，然后輻射到最小的組件/服務(wù)，確保最具影響力的系統(tǒng)獲得架構(gòu)設(shè)計(jì)成功所需的關(guān)注。
2.全部遷移到云端，或什么都不遷移到云端
客戶遷移到云時(shí)，可能已用幾個(gè)遷移的系統(tǒng)作了嘗試，隨后決定將所有內(nèi)容遷移到云端。考慮到這一點(diǎn)，目標(biāo)是在本地不留下任何東西，這需要了解舊的關(guān)系系統(tǒng)以及將它們遷移到云端的要求。
這種逐漸遷移到云端的策略存在的最大弊端之一是，以前的較小云遷移項(xiàng)目可能已經(jīng)將各種工作負(fù)載轉(zhuǎn)移到多個(gè)云上，如果系統(tǒng)之間存在數(shù)據(jù)交互，這會導(dǎo)致需要發(fā)現(xiàn)多云依賴項(xiàng)。網(wǎng)絡(luò)成為最后一個(gè)瓶頸，沒有人發(fā)現(xiàn)如何克服這個(gè)瓶頸。使用對等網(wǎng)絡(luò)和加速網(wǎng)絡(luò)，靠近數(shù)據(jù)中心可能有助于消除一些延遲，但正如圖3所示，除非開發(fā)新的網(wǎng)絡(luò)技術(shù)，否則這一挑戰(zhàn)會繼續(xù)存在。多云解決方案可以在云提供商之間提供一些數(shù)據(jù)優(yōu)勢，但它們的運(yùn)作永遠(yuǎn)不會像單一云解決方案那樣。
云提供商之間的網(wǎng)絡(luò)延遲差異可能因地區(qū)和地理位置而異
克服跨云延遲問題的首要目標(biāo)是確定每天、每周在諸環(huán)境之間需要移動(dòng)什么數(shù)據(jù)。第二個(gè)目標(biāo)應(yīng)該是開發(fā)人員如何在本地執(zhí)行工作，并針對云開發(fā)進(jìn)行優(yōu)化，盡可能消除多余環(huán)節(jié)。始終選擇簡化通過網(wǎng)絡(luò)拉取或推送數(shù)據(jù)時(shí)可能形成額外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）。這歸因于多個(gè)因素，但大多數(shù)挑戰(zhàn)圍繞著多年來系統(tǒng)內(nèi)置的復(fù)雜性以及SaaS/PaaS產(chǎn)品缺少功能。在決定云端與遷移到云端的數(shù)據(jù)資產(chǎn)有哪些選項(xiàng)時(shí)，應(yīng)遵循這些簡單的指導(dǎo)原則：
SaaS：
- 新建項(xiàng)目
- 數(shù)據(jù)庫層不需要定制的代碼
- 系統(tǒng)采用應(yīng)用驅(qū)動(dòng)開發(fā)，數(shù)據(jù)存儲需求簡單
- 較小的用戶群和簡單的恢復(fù)點(diǎn)目標(biāo)（RPO）/恢復(fù)時(shí)間目標(biāo)（RTO）
PaaS：
- 新建項(xiàng)目
- vCPU、內(nèi)存和 IO的資源使用輕松適應(yīng)PaaS的限制
- 管理基礎(chǔ)設(shè)施的IT資源很少，或者希望擯棄這個(gè)要求
- 數(shù)據(jù)庫層實(shí)現(xiàn)的高級功能或定制選項(xiàng)較少
IaaS：
- 您接觸TB到PB級的大型關(guān)系系統(tǒng)
- 您需要與本地應(yīng)用程序相同或相似的架構(gòu)
- 您對資源有獨(dú)特的需求——IO、vCPU及/或內(nèi)存
- 您有要求非常苛嚴(yán)的工作負(fù)載，有復(fù)雜的RPO/RTO和開發(fā)需求
如果需要使用IaaS，重要的是要認(rèn)識到云供應(yīng)商可以為一大堆工作負(fù)載提供解決方案，而關(guān)系工作負(fù)載很獨(dú)特，需要合適的IaaS解決方案來滿足要求。
（2）如何擴(kuò)建RDBMS遷移策略？
遷移具有挑戰(zhàn)性，做好準(zhǔn)備是取得成功的最佳途徑。無論您使用過時(shí)的客戶端/服務(wù)器架構(gòu)還是大型機(jī)解決方案，具有多層系統(tǒng)的關(guān)系數(shù)據(jù)庫都需要規(guī)劃以確保成功。雖然每個(gè)項(xiàng)目都很獨(dú)特，但某些方面是共通的，如果作為計(jì)劃的一部分得到滿足，將有助于確保成功遷移。通用列表常常包括如下：
- 數(shù)據(jù)庫大小和復(fù)雜性
- 數(shù)據(jù)負(fù)載和連接的生態(tài)系統(tǒng)
- 應(yīng)用程序、作業(yè)、Web 及其他服務(wù)器
- 網(wǎng)絡(luò)延遲
（3）RDBMS中必須識別哪些重要指標(biāo)？
大多數(shù)關(guān)系型工作負(fù)載耗用大量資源——換句話說，它們對基礎(chǔ)架構(gòu)的要求比其他工作負(fù)載更高。但是盡管我們可能專注于CPU和內(nèi)存，但關(guān)系工作負(fù)載、尤其是Oracle之類的工作負(fù)載可能需要高IO存儲解決方案。
大多數(shù)IO存儲和基準(zhǔn)測試側(cè)重于請求（IOP），然而，請求大小會有差異，從而使這些值會有水分。根據(jù)我的經(jīng)驗(yàn)，建議少關(guān)注IOP，確保圍繞虛擬機(jī)和存儲IO限制而選擇的解決方案能夠每秒處理兆字節(jié)數(shù)（吞吐量）。
（4）創(chuàng)建多層RDBMS復(fù)雜性
由于云端的服務(wù)、高可用性和備份發(fā)生變化，圍繞存儲的所有決策和解決方案都必須關(guān)注RPO和RTO。還應(yīng)考慮可能與RPO/RTO不同的任何客戶正常運(yùn)行時(shí)間SLA，因?yàn)榉?wù)可能被捆綁到作為架構(gòu)一部分而選擇的存儲解決方案中。
確保所有架構(gòu)決策都基于應(yīng)如何為推薦的實(shí)踐設(shè)計(jì)云架構(gòu)，而不只是復(fù)制客戶做入到其本地架構(gòu)中的內(nèi)容。這是云端常見的錯(cuò)誤，會造成漏洞和冗余。
平移關(guān)系數(shù)據(jù)庫工作負(fù)載將是一個(gè)好的起點(diǎn)，這將消除現(xiàn)有本地硬件中固有的基礎(chǔ)架構(gòu)債務(wù)。如果不考慮這種硬件，所有注意力都放在關(guān)系工作負(fù)載上，可以根據(jù)需要設(shè)計(jì)一種新的架構(gòu)。
4.重要保證：構(gòu)架框架
由于大多數(shù)數(shù)據(jù)生態(tài)系統(tǒng)不僅需要遷移主數(shù)據(jù)庫和連接的系統(tǒng)，還需要為非生產(chǎn)副本復(fù)制，因此構(gòu)建一個(gè)可以作為DevOps實(shí)踐的一部分進(jìn)行簡化、自動(dòng)化和部署的框架非常重要。每次在沒有框架的情況下執(zhí)行所有環(huán)環(huán)相扣的操作將非常耗時(shí)、容易出錯(cuò)。
構(gòu)建云遷移框架始于記錄將關(guān)系系統(tǒng)從端到端部署到云所需的內(nèi)容。起步階段可能類似圖4中所示的大體示例，隨后可以擴(kuò)建，以完成遷移項(xiàng)目計(jì)劃。
一旦擴(kuò)建完成，使用工具和腳本盡量自動(dòng)化，同時(shí)確保足夠大的靈活性，以便將來在眾多系統(tǒng)和架構(gòu)中重用。
云遷移的大體框架示例
確保腳本語言和工具可以像云遷移一樣擴(kuò)展，驗(yàn)證它們可以管理基礎(chǔ)架構(gòu)、關(guān)系系統(tǒng)和數(shù)據(jù)。問題出現(xiàn)并得到解決后，記錄下來，確保將來不會重演，從而不斷提高效率，作為云遷移策略的一部分。
5.結(jié)語
大型關(guān)系數(shù)據(jù)庫往往是許多云遷移項(xiàng)目的焦點(diǎn)。一旦遷移到云端，可能提議上多個(gè)項(xiàng)目，更新改造和消除這些舊系統(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)的一部分而遷移的推薦實(shí)踐將必不可少，因?yàn)檫@些關(guān)系系統(tǒng)在數(shù)據(jù)資產(chǎn)中仍將發(fā)揮作用。
網(wǎng)站標(biāo)題：RDBMS這個(gè)老古董，如何遷移？
文章網(wǎng)址：http://www.dlmjj.cn/article/djhocdc.html
