超融合服務(wù)器和超融合一體機有什么區(qū)別
01 超融合平臺中的數(shù)據(jù)是否需要獨立的放在外置存儲上？
@超融合產(chǎn)品經(jīng)理：
完全沒必要，因為超融合的核心之一就是分布式存儲，對于專業(yè)廠商提供的超融合產(chǎn)品，分布式塊存儲都有類似副本的技術(shù)，保證硬盤和節(jié)點在冗余度之內(nèi)的損壞數(shù)據(jù)都不會丟失 。
如果是用在生產(chǎn)環(huán)境里，基于數(shù)據(jù)可靠性的考慮，需要獨立的備份系統(tǒng)用于保護數(shù)據(jù)，防止因為誤刪除外部因素導(dǎo)致的數(shù)據(jù)損壞和丟失，這不是針對超融合系統(tǒng)，因為無論多么高端的存儲，備份都是不可替代的。
如果是更高級別的數(shù)據(jù)可用性，比如同城雙活，需要購買對應(yīng)的軟件模塊或者配備第三方的方案?，F(xiàn)在vSAN都是自帶雙活功能的。
02 超融合服務(wù)器是什么？和超融合一體機什么區(qū)別？
@超融合產(chǎn)品經(jīng)理：
首先，超融合是近幾年興起的一種新的 IT 基礎(chǔ)架構(gòu)，這種架構(gòu)具備以下特點：
符合軟件定義數(shù)據(jù)中心理念，一定是通過軟件結(jié)合標準的 x86 服務(wù)器來構(gòu)建分布式存儲，而不使用基于定制硬件的傳統(tǒng)集中式存儲；
這個概念強調(diào)的是分布式存儲軟件和虛擬化軟件的融合部署，并不是單純的指軟、硬件融合。
基于這種架構(gòu)，廠商給用戶提供的產(chǎn)品形態(tài)一般有兩種：
1.超融合軟件。用戶可以基于超融合軟件和自己選定的 x86 服務(wù)器硬件構(gòu)建超融合基礎(chǔ)架構(gòu)；
2.超融合一體機。廠商根據(jù)客戶的需求，和自身的產(chǎn)品策略，為用戶提供的開箱即用，一體機化的交付方式，一體機包含了軟件和 廠商選定并適配的 x86 服務(wù)器。
那么超融合服務(wù)器是什么？目前市場上還會有“超融合服務(wù)器”這樣的概念，這并不是一個標準的概念，其中包含兩種可能：
1.就是指超融合一體機；
2.指支持超融合軟件的服務(wù)器，而這類服務(wù)器，一般就是標準的 x86 服務(wù)器。
03 超融合三副本模式，能避免任意3塊硬盤故障嗎？節(jié)點故障時引起的數(shù)據(jù)復(fù)制對集群性能造成的影響，會不會影響生產(chǎn)系統(tǒng)性能？
@超融合產(chǎn)品經(jīng)理：
題主的問題主要來自對超融合平臺的數(shù)據(jù)可靠性方面的質(zhì)疑，我們可以圍繞這兩個問題進行一下探討。
a. 三副本是否能允許任意 3 塊硬盤故障？
三副本是允許單一集群內(nèi)部任意 2 塊硬盤同時故障而不導(dǎo)致數(shù)據(jù)丟失的數(shù)據(jù)可靠性保護手段，也就是說無法允許任意 3 塊硬盤同時故障。
這里有兩個關(guān)鍵詞，第一個是 “任意”，由于三副本是將數(shù)據(jù)寫三份，強制分布在 3 臺服務(wù)器上的不同硬盤之中，任意丟失 2 個副本，依然可以通過剩下的 1 個副本進行數(shù)據(jù)恢復(fù)，不會引發(fā)數(shù)據(jù)丟失，那就意味著如果故障硬盤都在同一個服務(wù)器上的話，即使多于 2 塊硬盤也不會導(dǎo)致數(shù)據(jù)丟失，因為肯定可以在其他節(jié)點中有其他可用副本。第二個關(guān)鍵字是 “同時”，如果這個故障是先后發(fā)生也是不在限制范圍，例如有 1 塊硬盤故障，經(jīng)過自動地數(shù)據(jù)恢復(fù)完成后，再次故障 2 塊硬盤，這樣也不會導(dǎo)致數(shù)據(jù)丟失的情況。
目前主流的超融合產(chǎn)品都是支持 2 副本 和 3 副本的，基本上沒有更高級別的冗余，因為這樣容量開銷比較大，實際可用空間就太少了。
b. 當數(shù)據(jù)恢復(fù)的時候是否會影響現(xiàn)有生產(chǎn)環(huán)境性能？
首先觸發(fā)數(shù)據(jù)恢復(fù)或者數(shù)據(jù)重構(gòu)，動作本質(zhì)上是發(fā)生存儲讀寫 IO 的，它必然是占用一部分存儲性能的。但是現(xiàn)在做得比較好的超融合產(chǎn)品，會自動控制單節(jié)點數(shù)據(jù)恢復(fù)的速度，利用多個節(jié)點進行并發(fā)恢復(fù)，這樣既能在較短的時間窗口恢復(fù)數(shù)據(jù)可靠性級別，又能盡可能保障生產(chǎn)環(huán)境性能。另外超融合使用的副本技術(shù)與傳統(tǒng) raid 數(shù)據(jù)冗余保護有所不同，raid 組出現(xiàn)硬盤故障，是需要全盤數(shù)據(jù)重構(gòu)的，無論這塊盤是否寫滿數(shù)據(jù)甚至是基本是空的都要全盤數(shù)據(jù)恢復(fù)；而副本技術(shù)只會恢復(fù)寫入的數(shù)據(jù)，某些情況下可以大幅減少數(shù)據(jù)恢復(fù)量，縮短數(shù)據(jù)恢復(fù)窗口，減少對生產(chǎn)環(huán)境的影響。
04 Ansible是否適合做自動化采集工作？如何與CMDB進行結(jié)合？
@企業(yè)級開源解決方案中心軟件架構(gòu)設(shè)計師：
某些客戶數(shù)據(jù)中心已經(jīng)實現(xiàn)了系統(tǒng)數(shù)據(jù)采集的應(yīng)用場景，比如CPU，內(nèi)存，磁盤容量，IO等參數(shù)的抓取。直接編寫playbook即可，無需和CMDB對接。如果需要對接，可從CMDB從查詢設(shè)備信息，然后去相應(yīng)設(shè)備上抓取指定參數(shù)。實現(xiàn)需要詳細討論
05 Ansible系統(tǒng)損壞，對被管理系統(tǒng)有什么影響？
@企業(yè)級開源解決方案中心軟件架構(gòu)設(shè)計師：
損壞后如果playbook也對丟了影響比較大，如果數(shù)據(jù)沒丟，可以重建然后重新建互信即可快速恢復(fù)。
生產(chǎn)環(huán)境下ansible以及tower的建設(shè)需要有高可用架構(gòu)，對于tower的高可用架構(gòu)，前端需要F5或者haproxy這些負載均衡器，后端的狀態(tài)同步需要有postgresql 的replication多副本保證。
對于playbook的保護，最好有備份機制，或者放到代碼庫或者共享存儲中。
06 上線新的對象存儲平臺，應(yīng)該從哪些方面對新產(chǎn)品進行細致的測試？
@資深解決方案專家：
上新的存儲系統(tǒng)都需要對存儲平臺進行穩(wěn)定性，兼容性，性能，異常進行全方面測試。需要應(yīng)用部門，技術(shù)部門一起協(xié)同測試。
比如：
兼容性——
需要與前端對象應(yīng)用部門聯(lián)合測試，通過API，腳本充分測試和對象存儲的對接驗證，并配合性能，穩(wěn)定性持續(xù)測試。
性能——
對于對象存儲來說，數(shù)據(jù)類型分為大對象，小對象。衡量對象存儲性能是否滿足業(yè)務(wù)需求，可以通過cosbench模擬4k 1M在大并發(fā)下存儲性能表現(xiàn)，當然也要和業(yè)務(wù)進行對接測試，用業(yè)務(wù)系統(tǒng)真實跑一輪性能測試，在性能測試過程中也要進行穩(wěn)定性測試，進行拔盤，斷節(jié)點查看在異常的狀態(tài)下存儲性能表現(xiàn)。
穩(wěn)定性——
長期跑IO測試集群性能。
07 Ceph一個OSD應(yīng)該分配多少內(nèi)存？
【問題描述】一個OSD應(yīng)該分配多少內(nèi)存？最近在測試Ceph集群，發(fā)現(xiàn)OSD占用的內(nèi)存隨著寫入的數(shù)據(jù)越來越多，占用的內(nè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)問題了呢？Ceph 集群出現(xiàn)異常比如數(shù)據(jù)重平衡會大量使用內(nèi)存， OSD 內(nèi)存消耗通常與系統(tǒng)中每個守護進程的 PG 數(shù)有關(guān)。內(nèi)存問題需要多注意，內(nèi)存不夠會導(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.
