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