超融合服務(wù)器和超融合一體機(jī)有什么區(qū)別
01 超融合平臺(tái)中的數(shù)據(jù)是否需要獨(dú)立的放在外置存儲(chǔ)上?
@超融合產(chǎn)品經(jīng)理:
完全沒(méi)必要,因?yàn)槌诤系暮诵闹痪褪欠植际酱鎯?chǔ),對(duì)于專業(yè)廠商提供的超融合產(chǎn)品,分布式塊存儲(chǔ)都有類似副本的技術(shù),保證硬盤(pán)和節(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(wú)論多么高端的存儲(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ù)中心理念,一定是通過(guò)軟件結(jié)合標(biāo)準(zhǔn)的 x86 服務(wù)器來(lái)構(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)品策略,為用戶提供的開(kāi)箱即用,一體機(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塊硬盤(pán)故障嗎?節(jié)點(diǎn)故障時(shí)引起的數(shù)據(jù)復(fù)制對(duì)集群性能造成的影響,會(huì)不會(huì)影響生產(chǎn)系統(tǒng)性能?
@超融合產(chǎn)品經(jīng)理:
題主的問(wèn)題主要來(lái)自對(duì)超融合平臺(tái)的數(shù)據(jù)可靠性方面的質(zhì)疑,我們可以圍繞這兩個(gè)問(wèn)題進(jìn)行一下探討。
a. 三副本是否能允許任意 3 塊硬盤(pán)故障?
三副本是允許單一集群內(nèi)部任意 2 塊硬盤(pán)同時(shí)故障而不導(dǎo)致數(shù)據(jù)丟失的數(shù)據(jù)可靠性保護(hù)手段,也就是說(shuō)無(wú)法允許任意 3 塊硬盤(pán)同時(shí)故障。
這里有兩個(gè)關(guān)鍵詞,第一個(gè)是 “任意”,由于三副本是將數(shù)據(jù)寫(xiě)三份,強(qiáng)制分布在 3 臺(tái)服務(wù)器上的不同硬盤(pán)之中,任意丟失 2 個(gè)副本,依然可以通過(guò)剩下的 1 個(gè)副本進(jìn)行數(shù)據(jù)恢復(fù),不會(huì)引發(fā)數(shù)據(jù)丟失,那就意味著如果故障硬盤(pán)都在同一個(gè)服務(wù)器上的話,即使多于 2 塊硬盤(pán)也不會(huì)導(dǎo)致數(shù)據(jù)丟失,因?yàn)榭隙梢栽谄渌?jié)點(diǎn)中有其他可用副本。第二個(gè)關(guān)鍵字是 “同時(shí)”,如果這個(gè)故障是先后發(fā)生也是不在限制范圍,例如有 1 塊硬盤(pán)故障,經(jīng)過(guò)自動(dòng)地?cái)?shù)據(jù)恢復(fù)完成后,再次故障 2 塊硬盤(pán),這樣也不會(huì)導(dǎo)致數(shù)據(jù)丟失的情況。
目前主流的超融合產(chǎn)品都是支持 2 副本 和 3 副本的,基本上沒(méi)有更高級(jí)別的冗余,因?yàn)檫@樣容量開(kāi)銷比較大,實(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ǔ)讀寫(xiě) 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)硬盤(pán)故障,是需要全盤(pán)數(shù)據(jù)重構(gòu)的,無(wú)論這塊盤(pán)是否寫(xiě)滿數(shù)據(jù)甚至是基本是空的都要全盤(pán)數(shù)據(jù)恢復(fù);而副本技術(shù)只會(huì)恢復(fù)寫(xiě)入的數(shù)據(jù),某些情況下可以大幅減少數(shù)據(jù)恢復(fù)量,縮短數(shù)據(jù)恢復(fù)窗口,減少對(duì)生產(chǎn)環(huán)境的影響。
04 Ansible是否適合做自動(dòng)化采集工作?如何與CMDB進(jìn)行結(jié)合?
@企業(yè)級(jí)開(kāi)源解決方案中心軟件架構(gòu)設(shè)計(jì)師:
某些客戶數(shù)據(jù)中心已經(jīng)實(shí)現(xiàn)了系統(tǒng)數(shù)據(jù)采集的應(yīng)用場(chǎng)景,比如CPU,內(nèi)存,磁盤(pán)容量,IO等參數(shù)的抓取。直接編寫(xiě)playbook即可,無(wú)需和CMDB對(duì)接。如果需要對(duì)接,可從CMDB從查詢?cè)O(shè)備信息,然后去相應(yīng)設(shè)備上抓取指定參數(shù)。實(shí)現(xiàn)需要詳細(xì)討論
05 Ansible系統(tǒng)損壞,對(duì)被管理系統(tǒng)有什么影響?
@企業(yè)級(jí)開(kāi)源解決方案中心軟件架構(gòu)設(shè)計(jì)師:
損壞后如果playbook也對(duì)丟了影響比較大,如果數(shù)據(jù)沒(méi)丟,可以重建然后重新建互信即可快速恢復(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ī)制,或者放到代碼庫(kù)或者共享存儲(chǔ)中。
06 上線新的對(duì)象存儲(chǔ)平臺(tái),應(yīng)該從哪些方面對(duì)新產(chǎn)品進(jìn)行細(xì)致的測(cè)試?
@資深解決方案專家:
上新的存儲(chǔ)系統(tǒng)都需要對(duì)存儲(chǔ)平臺(tái)進(jìn)行穩(wěn)定性,兼容性,性能,異常進(jìn)行全方面測(cè)試。需要應(yīng)用部門,技術(shù)部門一起協(xié)同測(cè)試。
比如:
兼容性——
需要與前端對(duì)象應(yīng)用部門聯(lián)合測(cè)試,通過(guò)API,腳本充分測(cè)試和對(duì)象存儲(chǔ)的對(duì)接驗(yàn)證,并配合性能,穩(wěn)定性持續(xù)測(cè)試。
性能——
對(duì)于對(duì)象存儲(chǔ)來(lái)說(shuō),數(shù)據(jù)類型分為大對(duì)象,小對(duì)象。衡量對(duì)象存儲(chǔ)性能是否滿足業(yè)務(wù)需求,可以通過(guò)cosbench模擬4k 1M在大并發(fā)下存儲(chǔ)性能表現(xiàn),當(dāng)然也要和業(yè)務(wù)進(jìn)行對(duì)接測(cè)試,用業(yè)務(wù)系統(tǒng)真實(shí)跑一輪性能測(cè)試,在性能測(cè)試過(guò)程中也要進(jìn)行穩(wěn)定性測(cè)試,進(jìn)行拔盤(pán),斷節(jié)點(diǎn)查看在異常的狀態(tài)下存儲(chǔ)性能表現(xiàn)。
穩(wěn)定性——
長(zhǎng)期跑IO測(cè)試集群性能。
07 Ceph一個(gè)OSD應(yīng)該分配多少內(nèi)存?
【問(wèn)題描述】一個(gè)OSD應(yīng)該分配多少內(nèi)存?最近在測(cè)試Ceph集群,發(fā)現(xiàn)OSD占用的內(nèi)存隨著寫(xiě)入的數(shù)據(jù)越來(lái)越多,占用的內(nèi)存也越來(lái)越多,最終都把系統(tǒng)內(nèi)存完了。
root 31383 28.2 8.3 2593676 920976 ? Ssl Mar01 332:07 /usr/local/hstor/ceph_dir/bin/ceph-osd -i 42 --pid-file /var/run/ceph/osd.42.pid -c /usr/local/hstor/ceph_dir/etc/ceph/ceph.conf --cluster ceph
root 32534 21.2 8.4 2591672 936432 ? Ssl Mar01 249:22 /usr/local/hstor/ceph_dir/bin/ceph-osd -i 44 --pid-file /var/run/ceph/osd.44.pid -c /usr/local/hstor/ceph_dir/etc/ceph/ceph.conf --clust
@資深解決方案專家:
現(xiàn)在分配了多少內(nèi)存出現(xiàn)問(wèn)題了呢?Ceph 集群出現(xiàn)異常比如數(shù)據(jù)重平衡會(huì)大量使用內(nèi)存, OSD 內(nèi)存消耗通常與系統(tǒng)中每個(gè)守護(hù)進(jìn)程的 PG 數(shù)有關(guān)。內(nèi)存問(wèn)題需要多注意,內(nèi)存不夠會(huì)導(dǎo)致 OSD 重啟,集群異常。ceph.com 也給出了推薦的 OSD 內(nèi)存配置,可以參考一下建議3-5GB吧。
OSDs (ceph-osd)
By default, OSDs that use the BlueStore backend require 3-5 GB of RAM. You can adjust the amount of memory the OSD consumes with the osd_memory_target configuration option when BlueStore is in use. When using the legacy FileStore backend, the operating system page cache is used for caching data, so no tuning is normally needed, and the OSD memory consumption is generally related to the number of PGs per daemon in the system.