01 超融合平臺(tái)中的數(shù)據(jù)是否需要獨(dú)立的放在外置存儲(chǔ)上？

@超融合產(chǎn)品經(jīng)理：

完全沒必要，因?yàn)槌诤系暮诵闹痪褪欠植际酱鎯?chǔ)，對(duì)于專業(yè)廠商提供的超融合產(chǎn)品，分布式塊存儲(chǔ)都有類似副本的技術(shù)，保證硬盤和節(jié)點(diǎn)在冗余度之內(nèi)的損壞數(shù)據(jù)都不會(huì)丟失 。

如果是用在生產(chǎn)環(huán)境里，基于數(shù)據(jù)可靠性的考慮，需要獨(dú)立的備份系統(tǒng)用于保護(hù)數(shù)據(jù)，防止因?yàn)檎`刪除外部因素導(dǎo)致的數(shù)據(jù)損壞和丟失，這不是針對(duì)超融合系統(tǒng)，因?yàn)闊o論多么高端的存儲(chǔ)，備份都是不可替代的。

如果是更高級(jí)別的數(shù)據(jù)可用性，比如同城雙活，需要購(gòu)買對(duì)應(yīng)的軟件模塊或者配備第三方的方案?，F(xiàn)在vSAN都是自帶雙活功能的。

02 超融合服務(wù)器是什么？和超融合一體機(jī)什么區(qū)別？

@超融合產(chǎn)品經(jīng)理：

首先，超融合是近幾年興起的一種新的 IT 基礎(chǔ)架構(gòu)，這種架構(gòu)具備以下特點(diǎn)：

符合軟件定義數(shù)據(jù)中心理念，一定是通過軟件結(jié)合標(biāo)準(zhǔn)的 x86 服務(wù)器來構(gòu)建分布式存儲(chǔ)，而不使用基于定制硬件的傳統(tǒng)集中式存儲(chǔ)；

這個(gè)概念強(qiáng)調(diào)的是分布式存儲(chǔ)軟件和虛擬化軟件的融合部署，并不是單純的指軟、硬件融合。

基于這種架構(gòu)，廠商給用戶提供的產(chǎn)品形態(tài)一般有兩種：

1.超融合軟件。用戶可以基于超融合軟件和自己選定的 x86 服務(wù)器硬件構(gòu)建超融合基礎(chǔ)架構(gòu)；

2.超融合一體機(jī)。廠商根據(jù)客戶的需求，和自身的產(chǎn)品策略，為用戶提供的開箱即用，一體機(jī)化的交付方式，一體機(jī)包含了軟件和 廠商選定并適配的 x86 服務(wù)器。

那么超融合服務(wù)器是什么？目前市場(chǎng)上還會(huì)有“超融合服務(wù)器”這樣的概念，這并不是一個(gè)標(biāo)準(zhǔn)的概念，其中包含兩種可能：

1.就是指超融合一體機(jī)；

2.指支持超融合軟件的服務(wù)器，而這類服務(wù)器，一般就是標(biāo)準(zhǔn)的 x86 服務(wù)器。

03 超融合三副本模式，能避免任意3塊硬盤故障嗎？節(jié)點(diǎn)故障時(shí)引起的數(shù)據(jù)復(fù)制對(duì)集群性能造成的影響，會(huì)不會(huì)影響生產(chǎn)系統(tǒng)性能？

@超融合產(chǎn)品經(jīng)理：

題主的問題主要來自對(duì)超融合平臺(tái)的數(shù)據(jù)可靠性方面的質(zhì)疑，我們可以圍繞這兩個(gè)問題進(jìn)行一下探討。

a. 三副本是否能允許任意 3 塊硬盤故障？

三副本是允許單一集群內(nèi)部任意 2 塊硬盤同時(shí)故障而不導(dǎo)致數(shù)據(jù)丟失的數(shù)據(jù)可靠性保護(hù)手段，也就是說無法允許任意 3 塊硬盤同時(shí)故障。

這里有兩個(gè)關(guān)鍵詞，第一個(gè)是 “任意”，由于三副本是將數(shù)據(jù)寫三份，強(qiáng)制分布在 3 臺(tái)服務(wù)器上的不同硬盤之中，任意丟失 2 個(gè)副本，依然可以通過剩下的 1 個(gè)副本進(jìn)行數(shù)據(jù)恢復(fù)，不會(huì)引發(fā)數(shù)據(jù)丟失，那就意味著如果故障硬盤都在同一個(gè)服務(wù)器上的話，即使多于 2 塊硬盤也不會(huì)導(dǎo)致數(shù)據(jù)丟失，因?yàn)榭隙梢栽谄渌?jié)點(diǎn)中有其他可用副本。第二個(gè)關(guān)鍵字是 “同時(shí)”，如果這個(gè)故障是先后發(fā)生也是不在限制范圍，例如有 1 塊硬盤故障，經(jīng)過自動(dòng)地?cái)?shù)據(jù)恢復(fù)完成后，再次故障 2 塊硬盤，這樣也不會(huì)導(dǎo)致數(shù)據(jù)丟失的情況。

目前主流的超融合產(chǎn)品都是支持 2 副本 和 3 副本的，基本上沒有更高級(jí)別的冗余，因?yàn)檫@樣容量開銷比較大，實(shí)際可用空間就太少了。

b. 當(dāng)數(shù)據(jù)恢復(fù)的時(shí)候是否會(huì)影響現(xiàn)有生產(chǎn)環(huán)境性能？

首先觸發(fā)數(shù)據(jù)恢復(fù)或者數(shù)據(jù)重構(gòu)，動(dòng)作本質(zhì)上是發(fā)生存儲(chǔ)讀寫 IO 的，它必然是占用一部分存儲(chǔ)性能的。但是現(xiàn)在做得比較好的超融合產(chǎn)品，會(huì)自動(dòng)控制單節(jié)點(diǎn)數(shù)據(jù)恢復(fù)的速度，利用多個(gè)節(jié)點(diǎn)進(jìn)行并發(fā)恢復(fù)，這樣既能在較短的時(shí)間窗口恢復(fù)數(shù)據(jù)可靠性級(jí)別，又能盡可能保障生產(chǎn)環(huán)境性能。另外超融合使用的副本技術(shù)與傳統(tǒng) raid 數(shù)據(jù)冗余保護(hù)有所不同，raid 組出現(xiàn)硬盤故障，是需要全盤數(shù)據(jù)重構(gòu)的，無論這塊盤是否寫滿數(shù)據(jù)甚至是基本是空的都要全盤數(shù)據(jù)恢復(fù)；而副本技術(shù)只會(huì)恢復(fù)寫入的數(shù)據(jù)，某些情況下可以大幅減少數(shù)據(jù)恢復(fù)量，縮短數(shù)據(jù)恢復(fù)窗口，減少對(duì)生產(chǎn)環(huán)境的影響。

04 Ansible是否適合做自動(dòng)化采集工作？如何與CMDB進(jìn)行結(jié)合？

@企業(yè)級(jí)開源解決方案中心軟件架構(gòu)設(shè)計(jì)師：

某些客戶數(shù)據(jù)中心已經(jīng)實(shí)現(xiàn)了系統(tǒng)數(shù)據(jù)采集的應(yīng)用場(chǎng)景，比如CPU，內(nèi)存，磁盤容量，IO等參數(shù)的抓取。直接編寫playbook即可，無需和CMDB對(duì)接。如果需要對(duì)接，可從CMDB從查詢?cè)O(shè)備信息，然后去相應(yīng)設(shè)備上抓取指定參數(shù)。實(shí)現(xiàn)需要詳細(xì)討論

05 Ansible系統(tǒng)損壞，對(duì)被管理系統(tǒng)有什么影響？

@企業(yè)級(jí)開源解決方案中心軟件架構(gòu)設(shè)計(jì)師：

損壞后如果playbook也對(duì)丟了影響比較大，如果數(shù)據(jù)沒丟，可以重建然后重新建互信即可快速恢復(fù)。

生產(chǎn)環(huán)境下ansible以及tower的建設(shè)需要有高可用架構(gòu)，對(duì)于tower的高可用架構(gòu)，前端需要F5或者h(yuǎn)aproxy這些負(fù)載均衡器，后端的狀態(tài)同步需要有postgresql 的replication多副本保證。

對(duì)于playbook的保護(hù)，最好有備份機(jī)制，或者放到代碼庫或者共享存儲(chǔ)中。

06 上線新的對(duì)象存儲(chǔ)平臺(tái)，應(yīng)該從哪些方面對(duì)新產(chǎn)品進(jìn)行細(xì)致的測(cè)試？