對(duì)于許多公司而言，如Microsoft SQL Server、Oracle、SAP HANA、PostgreSQL、MySQL等，數(shù)據(jù)庫(kù)是其成功的重要原因之一。但是由于其中許多數(shù)據(jù)庫(kù)仍在遺留IT基礎(chǔ)架構(gòu)上運(yùn)行，導(dǎo)致其發(fā)展?jié)摿κ艿较拗啤?/p>

遺留IT架構(gòu)上布滿筒倉(cāng)(Silos)，且復(fù)雜度高，因此持續(xù)運(yùn)行數(shù)據(jù)庫(kù)的效率及伸縮性不足。在遺留基礎(chǔ)架構(gòu)上運(yùn)行關(guān)系數(shù)據(jù)庫(kù)，除了性能差、效率低外，公司的IT團(tuán)隊(duì)還可能要面臨解決以下一個(gè)、兩個(gè)或所有缺陷。

[[282098]]

一、多筒倉(cāng)=低利用率

筒倉(cāng)可以說(shuō)是所有使用遺留基礎(chǔ)架構(gòu)的企業(yè)熟悉的痛點(diǎn)——雖然確實(shí)可以滿足個(gè)別特殊數(shù)據(jù)庫(kù)和應(yīng)用程序需求，但卻增加了直接資本成本和運(yùn)營(yíng)成本。許多公司如果想提高僅為20%的CPU利用率，就需要配置更多的硬件，而這意味著更高的許可成本。

不僅如此，擁有全部額外設(shè)備之后，公司的設(shè)備環(huán)境也需要進(jìn)行繁復(fù)的部署和支付管理。電力、空間和冷卻需求都在進(jìn)行成本疊加。

從基礎(chǔ)設(shè)備到員工

公司的基礎(chǔ)設(shè)備并不是封閉在溫室中的?；A(chǔ)架構(gòu)發(fā)生改變不僅會(huì)影響業(yè)務(wù)流程，最重要的是還會(huì)影響到員工。下表是其工作原理：

如果一個(gè)公司的員工在數(shù)據(jù)中心耗時(shí)過(guò)多，而在業(yè)務(wù)轉(zhuǎn)移項(xiàng)目耗時(shí)過(guò)少時(shí)，該公司不僅將面臨員工留存率下降的風(fēng)險(xiǎn)，而且其業(yè)務(wù)也將陷入創(chuàng)新煉獄之中。

二、應(yīng)用程序無(wú)效

大部分企業(yè)主要的關(guān)注點(diǎn)在于能否找回丟失數(shù)據(jù)以及修復(fù)缺陷應(yīng)用程序，然而事實(shí)是大多數(shù)公司關(guān)鍵業(yè)務(wù)的應(yīng)用程序都無(wú)法得到足夠的保護(hù)。為什么呢?因?yàn)閷?duì)于這些使用遺留基礎(chǔ)架構(gòu)支持其虛擬化應(yīng)用程序的企業(yè)而言，其關(guān)鍵業(yè)務(wù)應(yīng)用程序需要過(guò)多的停機(jī)整頓時(shí)間。

另外，并非所有數(shù)據(jù)庫(kù)應(yīng)用程序都是平等創(chuàng)建的，因此了解哪些指標(biāo)最能反映公司的應(yīng)用程序情況非常重要。以下3種措施可供使用：

• IOPS：面向事務(wù)處理的應(yīng)用程序(例如數(shù)據(jù)庫(kù)、OLTP和電子郵件)，存儲(chǔ)性能通常以每秒I / O操作(IOPS)來(lái)衡量。為形成有效的IOPS比較數(shù)據(jù)，必須考慮操作大小(通常為4 KB和8 KB)以及讀/寫操作組合。
• 延遲：延遲衡量的是I / O完成所需的時(shí)間。尤其在衡量IOPS性能時(shí)，延遲至關(guān)重要。實(shí)時(shí)交易、OLTP等有時(shí)效性的應(yīng)用程序也極易受延遲的影響。
• 吞吐量：吞吐量也稱為“帶寬”，它衡量的是移入和移出存儲(chǔ)的數(shù)據(jù)量。因?yàn)閿?shù)據(jù)倉(cāng)庫(kù)和OLAP之類的應(yīng)用程序依賴對(duì)大型數(shù)據(jù)塊的順序流訪問(wèn)，所以它們的I / O性能以兆字節(jié)/秒(MB / sec)或十億字節(jié)/秒(GB / sec)為單位。

三、復(fù)雜的虛擬監(jiān)控環(huán)境

如今，89%的公司表示其IT環(huán)境過(guò)于復(fù)雜。但即便如此，這些企業(yè)的IT團(tuán)隊(duì)采用的監(jiān)控方法仍舊是多個(gè)虛擬監(jiān)控程序并用，這造成了冗余復(fù)雜度、運(yùn)營(yíng)開銷以及數(shù)據(jù)中心“混亂”。

此外，大多數(shù)企業(yè)的IT解決方案存在明顯局限性，致使其IT團(tuán)隊(duì)陷入窘境，增加高昂的管理程序許可費(fèi)等企業(yè)總成本。

四、走出云端

我們正處在云計(jì)算時(shí)代。更確切地說(shuō)是正處于混合云和多云時(shí)代。因此，越來(lái)越多的企業(yè)希望利用云功能來(lái)運(yùn)行傳統(tǒng)的企業(yè)應(yīng)用程序和原生云應(yīng)用程序。

但是，如果想要使用混合云和多云的功能，公司的基礎(chǔ)架構(gòu)需要能夠同時(shí)支持混合云和多云程序，然而這一點(diǎn)遺留IT體系結(jié)構(gòu)根本無(wú)法勝任。許多企業(yè)也完全無(wú)法提供云服務(wù)來(lái)補(bǔ)充支持其數(shù)據(jù)庫(kù)環(huán)境進(jìn)行復(fù)雜的多云管理，也無(wú)法承擔(dān)昂貴的數(shù)據(jù)保護(hù)和災(zāi)難恢復(fù)費(fèi)用風(fēng)險(xiǎn)。

五、選擇合適的基礎(chǔ)架構(gòu)管理數(shù)據(jù)庫(kù)

轉(zhuǎn)移數(shù)據(jù)庫(kù)時(shí)，公司可能會(huì)產(chǎn)生一些性能方面的擔(dān)憂。例如：轉(zhuǎn)移后的數(shù)據(jù)庫(kù)會(huì)發(fā)生變化嗎?使用會(huì)受到阻礙嗎?如何確定其一致性?

如果是首次進(jìn)行虛擬化，就要更加關(guān)注性能方面的可靠性。若是在傳統(tǒng)基礎(chǔ)架構(gòu)上運(yùn)行數(shù)據(jù)庫(kù)，為了確保其半可靠性能，需要進(jìn)行繁復(fù)枯燥的調(diào)整。

相反，若是在超融合基礎(chǔ)架構(gòu)(HCI)上運(yùn)行，則無(wú)需進(jìn)行任何調(diào)整。Nutanix企業(yè)云服務(wù)公司以HCI架構(gòu)為基礎(chǔ)，使用適配群集為事務(wù)工作提供完備隨機(jī)讀寫性能(IOPS)，為流工作提供流暢順序讀寫性能(帶寬)。

無(wú)論其增長(zhǎng)速度如何，HCI能夠支持公司的所有數(shù)據(jù)庫(kù)應(yīng)用程序工作負(fù)載。遺留基礎(chǔ)架構(gòu)需要經(jīng)常性地進(jìn)行昂貴且復(fù)雜的升級(jí)操作，導(dǎo)致希望擴(kuò)展其數(shù)據(jù)庫(kù)的企業(yè)并非一直處于具備良好狀態(tài)的階段。這就是為什么超融合基礎(chǔ)架構(gòu)一次擴(kuò)展一個(gè)節(jié)點(diǎn)，采用一個(gè)平臺(tái)服務(wù)，取代復(fù)雜昂貴的遺留組件，并在整個(gè)集群中分配所有操作功能以提高性能的原因。

簡(jiǎn)而言之：擴(kuò)展方便，無(wú)需停工。

從災(zāi)難恢復(fù)到簡(jiǎn)化，再到自動(dòng)化，超融合是最明智的選擇，以最高效、最具成本效益的方式運(yùn)行數(shù)據(jù)庫(kù)。若切換到HCI架構(gòu)時(shí)，出現(xiàn)顯示模糊不清的狀況。