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

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

[[282098]]

一、多筒倉=低利用率

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

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

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

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

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

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

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

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

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

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

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

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

四、走出云端

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

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

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

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

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

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

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

簡而言之：擴(kuò)展方便，無需停工。

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