銀行業(yè)對象存儲平臺設(shè)計說明

1、 銀行業(yè)對象存儲平臺設(shè)計企業(yè)級對象存儲助力銀行企業(yè)精簡存儲架構(gòu)、提升非結(jié)構(gòu)化數(shù)據(jù)存儲效率目錄一、企業(yè)非結(jié)構(gòu)化數(shù)據(jù)存儲的現(xiàn)狀與痛點3（1）現(xiàn)狀3（2）痛點3二、企業(yè)非結(jié)構(gòu)化數(shù)據(jù)存儲優(yōu)化思路3（1） 采用對象存儲方案思路4（2）對象存儲方案與傳統(tǒng)分布式 NAS 方案的對比與總結(jié)5三、平臺測試與體驗6（1）測試容6（3）測試過程與結(jié)果61、功能性測試62、部署靈活性測試133、接口可用性測試144、系統(tǒng)可靠性測試175、系統(tǒng)管理性測試306、系統(tǒng)可維護性測試327、系統(tǒng)安全性測試36一、企業(yè)非結(jié)構(gòu)化數(shù)據(jù)存儲的現(xiàn)狀與痛點隨著本行數(shù)字化業(yè)務(wù)的持續(xù)開展和監(jiān)管要求的不斷提高，其中影像系統(tǒng)、呼叫中心系統(tǒng)，以與

2、已經(jīng)上線的后督系統(tǒng)等各類應(yīng)用系統(tǒng)產(chǎn)生的影像文件、音頻、視頻等非結(jié)構(gòu)化數(shù)據(jù)急速增加，本行正面臨現(xiàn)有的文件存儲設(shè)施不能適應(yīng)業(yè)務(wù)增長、系統(tǒng)管理復(fù)雜、擴展能力差、訪問能力差等問題。因此需要啟動開放式海量非結(jié)構(gòu)化數(shù)據(jù)的存儲平臺項目，滿足本行海量的非結(jié)構(gòu)化數(shù)據(jù)存儲、讀取、管理需求。（1）現(xiàn)狀目前我行的影像數(shù)據(jù)主要分兩塊，一塊是地市影像數(shù)據(jù)，主要承載著事后督查業(yè)務(wù)，一塊是總行影像數(shù)據(jù)，主要是柜面和信貸的影像數(shù)據(jù)。11 個地市的影像數(shù)據(jù)目前分別存放于 11 個 SAN 存儲當(dāng)中，根據(jù)地市的業(yè)務(wù)規(guī)模不一，存儲容量也不一，平均每個 SAN 存儲約 50TB?？傂杏跋駭?shù)據(jù)通過存儲分層架構(gòu)實現(xiàn)在線、近線和離線數(shù)據(jù)的存

3、儲和隔離。在線存儲存放于閃存（FS900）當(dāng)中，約 5T，保存了近 7 天的影像數(shù)據(jù)，并通過 IBM 的 ECM 客戶端定期遷移至 ECM 系統(tǒng)所在的近線存儲（DS8870）當(dāng)中，約 20T，保存了近 30 天的影像數(shù)據(jù)，最后再通過 TSM 備份軟件每日將近線存儲中的影像數(shù)據(jù)備份至華為（5300V3）離線存儲當(dāng)中，約200TB，當(dāng)信貸或者柜面業(yè)務(wù)需要調(diào)取 7 天的影像數(shù)據(jù)時，直接讀取在線存儲， 調(diào)取 30 天的數(shù)據(jù)時，先通過 ECM 客戶端將 ECM 中數(shù)據(jù)抽取至影像平臺，再傳給業(yè)務(wù)系統(tǒng)，調(diào)取 30 天以上的數(shù)據(jù)時，需先通過 TSM 備份軟件抽取備份的影像數(shù)據(jù)至 ECM 系統(tǒng)，再傳給影像平臺，

4、最終傳給相關(guān)業(yè)務(wù)系統(tǒng)。（2）痛點此架構(gòu)通過存儲的分層，不同性能的存儲提供不同的 IO 服務(wù)，確實也在項目上線后的 3、4 年，提供了比較高效非結(jié)構(gòu)化數(shù)據(jù)存取能力。然而隨著近兩年存儲的影像數(shù)據(jù)量的暴增，新增了多類業(yè)務(wù)的影像業(yè)務(wù)和數(shù)據(jù)，像互聯(lián)網(wǎng)影像數(shù)據(jù)、手機銀行與人臉識別影像數(shù)據(jù)、銀企業(yè)務(wù)影像數(shù)據(jù)等等，這樣就導(dǎo)致影像系統(tǒng)尤其是 ECM 系統(tǒng)壓力的陡增，目前遇到的痛點主要在于 ECM 系統(tǒng)，無論是近線數(shù)據(jù)還是離線數(shù)據(jù)，影像數(shù)據(jù)的位置與影像數(shù)據(jù)間的關(guān)系等信息均存放于 ECM 數(shù)據(jù)庫當(dāng)中，該數(shù)據(jù)庫為聯(lián)機型關(guān)系數(shù)據(jù)庫，隨著數(shù)據(jù)量的劇增，ECM 數(shù)據(jù)庫的數(shù)據(jù)量已達到近 5TB，7 天以上的數(shù)據(jù)調(diào)閱均需要訪問

5、先 ECM 數(shù)據(jù)庫，來獲取數(shù)據(jù)位置，然而目前龐大 ECM 的數(shù)據(jù)庫，并發(fā)讀取性能已經(jīng)越來越不滿足業(yè)務(wù)的需求，因此數(shù)據(jù)調(diào)閱響應(yīng)時間也越來越長。因此迫切需要對現(xiàn)有影像以與 ECM 的數(shù)據(jù)存儲架構(gòu)進行轉(zhuǎn)型，精簡該存儲架構(gòu)，全面提升影像數(shù)據(jù)的存儲效率。二、企業(yè)非結(jié)構(gòu)化數(shù)據(jù)存儲優(yōu)化思路鑒于我行目前非結(jié)構(gòu)化數(shù)據(jù)主要存放在 SAN 集中式存儲上，而傳統(tǒng)存儲采用集中式的元數(shù)據(jù)處理方式，因此，當(dāng)我行影像系統(tǒng)在處理千萬、億級的文件量時就會出現(xiàn)陡峭的性能驟降拐點，直接表現(xiàn)就是前端影像平臺處理效率降 低，柜面、信貸、事后督查等涉與影像的業(yè)務(wù)效率的下降，最終導(dǎo)致客戶滿意度的下降，這顯然不利于我行的健康持久發(fā)展。因此我行

6、需要對現(xiàn)有存儲中的43 / 43海量數(shù)據(jù)進行整合、精簡存儲架構(gòu)，目前非結(jié)構(gòu)化海量數(shù)據(jù)存儲較好的方案主要有傳統(tǒng)分布式 NAS 方案和對象存儲方案。傳統(tǒng) NAS 存儲方案由于和現(xiàn)有 SAN 存儲方案類似，都是基于文件系統(tǒng)的方案，均為樹形目錄組織結(jié)構(gòu)，隨著數(shù)據(jù)量的增大，同樣存在文件尋址越來越慢的瓶頸。另外如果將現(xiàn)有 SAN 方案改為NAS 存儲方案，IOPS 和 IO 響應(yīng)時間還有所降低，尤其是在線儲存目前所用的為閃存陣列，近線存儲為 DS8870，地市后督影像存儲為華為 5300V3，NAS 方案顯然不適合對現(xiàn)有架構(gòu)進行改造，且存在越改越差的情況，并且對 NAS 存儲的容災(zāi)備份方案，依舊是兩套 N

7、AS 鏡像的方式，副本數(shù)較少，備份效率低，數(shù)據(jù)一致性校驗困難。因此我行在非結(jié)構(gòu)化存儲架構(gòu)轉(zhuǎn)型偏向于對象存儲方案。（1） 采用對象存儲方案思路我行期望通過使用分布式對象存儲架構(gòu)替換傳統(tǒng)的 SAN 存儲架構(gòu)，能夠解決海量非結(jié)構(gòu)化數(shù)據(jù)的集中存儲與訪問問題，提升非結(jié)構(gòu)化文件存取效率，解決地 市影像和總行影像存儲單點問題，并盡可能的精簡現(xiàn)有非機構(gòu)化數(shù)據(jù)的存儲架構(gòu)。而分布式對象存儲能夠保證不丟失數(shù)據(jù)、不中斷服務(wù)、提供良好的用戶體驗，解 決存儲擴容復(fù)雜問題。由于分布式對象存儲采用扁平化的數(shù)據(jù)組織方式，所以目 錄架構(gòu)擴展性強，耦合性低，增刪節(jié)點時所需遷移的數(shù)據(jù)少。整體而言，在業(yè)務(wù) 系統(tǒng)、IT 性能以與運維方面

8、都帶了本質(zhì)的提升。因此利用對象存儲的方案，可以解決我行三個方面的問題：1、精簡非結(jié)構(gòu)化數(shù)據(jù)存儲架構(gòu)。對總行而言，之前我行的存儲架構(gòu)為閃存-DS8870-華為 5300V3，三層存儲架構(gòu)，且存儲和現(xiàn)有生產(chǎn)交易類存儲閃存和DS8870 共用，一來非結(jié)構(gòu)化數(shù)據(jù)不適合放于 IO 響應(yīng)時間優(yōu)異的存儲當(dāng)中，性能浪費嚴重，占用過多的存儲空間，其他對 IO 響應(yīng)時間要求較高的交易類系統(tǒng)， 可能反而得不到高性能的存儲。二來該存儲架構(gòu)過于冗余，數(shù)據(jù)存儲具有大量遷移過程，如 7 天以上的數(shù)據(jù)由閃存遷移至 DS8870,30 天以上的數(shù)據(jù)由 DS8870 遷移至 5300V3，歷史數(shù)據(jù)調(diào)閱的過程又反向，雖然均通過 E

9、CM 系統(tǒng)和 TSM 軟件實現(xiàn)該過程，但效率較低，相當(dāng)于，存儲性能比較優(yōu)異，但整體數(shù)據(jù)存取效率不高， 尤其是歷史數(shù)據(jù)的存儲方面。對地市分行而言，11 個地市分別部署了一套華為存儲，獨立使用，數(shù)據(jù)來源于事后監(jiān)督系統(tǒng)通過抽取總行 ECM 的歷史數(shù)據(jù)而來， 數(shù)據(jù)和總行數(shù)據(jù)重合，卻并不是總行數(shù)據(jù)的副本。而采用對象存儲方案，可以通過總行和地市部署存儲節(jié)點和訪問節(jié)點的方式，將所有存儲打通成一個大存儲資源池，所有影像數(shù)據(jù)均放在該存儲池，形成二層精簡架構(gòu)，所有數(shù)據(jù)的存取，包括柜面、信貸、后督系統(tǒng)對影像數(shù)據(jù)的存儲，均通過本地的訪問節(jié)點訪問，大大提升了訪問效率。2、提升非結(jié)構(gòu)化數(shù)據(jù)的副本數(shù)和冗余度。相較于現(xiàn)有存儲

10、架構(gòu)中的單副本數(shù)據(jù)，由于對象存儲池中的數(shù)據(jù)可劃分為多個副本，且每份影像數(shù)據(jù)也通過切片的方式分布于所有存儲節(jié)點當(dāng)中，因此數(shù)據(jù)的冗余度也大大提升，即使某一個或者多個存儲節(jié)點發(fā)生故障，或者訪問節(jié)點發(fā)生故障，均可以通過其他存儲節(jié)點和訪問節(jié)點獲取數(shù)據(jù)。3、提升非結(jié)構(gòu)化數(shù)據(jù)的存取性能。雖然目前的方案中閃存的引入，對于 7 天的影像數(shù)據(jù)的存取效率大大提升，但歷史影像數(shù)據(jù)的調(diào)閱性能較差，導(dǎo)致該問題的一個主要原因在于歷史影像數(shù)據(jù)調(diào)閱需要通過 ECM 客戶端訪問 ECM 系統(tǒng)中的存儲數(shù)據(jù)，而該訪問的過程首先要讀取 ECM 數(shù)據(jù)庫，獲取存儲數(shù)據(jù)的位置和地址，才能獲取存儲當(dāng)中的數(shù)據(jù)，這樣的弊端在于隨著 ECM 數(shù)據(jù)庫

11、中數(shù)據(jù)量的增大， 數(shù)據(jù)庫訪問效率大大降低，30 天歷史影像數(shù)據(jù)的調(diào)閱也就越來越慢，無法滿足柜面與信貸對影像數(shù)據(jù)的需求，至于 30 天以上的歷史數(shù)據(jù)就更加如此，除了需要訪問 ECM 數(shù)據(jù)庫之外，還需要訪問 TSM 備份系統(tǒng)，通過 TSM 備份系統(tǒng)自動將要調(diào)閱的數(shù)據(jù)恢復(fù)至 ECM 系統(tǒng)中，再上傳給影像平臺，供其他系統(tǒng)調(diào)閱。因此整個過程實際上耗費了大量時間在數(shù)據(jù)查找和數(shù)據(jù)傳輸上，即使底層存儲采用了 SAN 存儲，性能較對象存儲強，但加上這些時間，總體調(diào)閱時間大大提高。因此倘若采用了對象存儲，訪問時間就僅僅為對象存儲的尋址時間，沒有其他時間的消耗， 這樣性能也就大大提升。因此，對本行的非結(jié)構(gòu)化數(shù)據(jù)存儲

12、架構(gòu)的改造而言，采用對象存儲方案是最優(yōu)的方案。但同時，另一方面，采用對象存儲，也將給我行帶來兩個方面的問題：1、傳統(tǒng)的文件系統(tǒng)讀取的方式將改為對象存儲 API 的方式。需要對應(yīng)用進行改造，增加接口，修改程序代碼。2、原閃存、DS8870、5300V3 中的存儲數(shù)據(jù)需要通過調(diào)閱的方式遷移至對象存儲當(dāng)中，涉與的數(shù)據(jù)量較多，耗時較長，且影像系統(tǒng)在數(shù)據(jù)遷移過程中，不能有中斷現(xiàn)象，遷移時也要對其他業(yè)務(wù)系統(tǒng)提供影像服務(wù)，因此，整個平滑遷移與過渡的方案要理清。（2）對象存儲方案與傳統(tǒng)分布式 NAS 方案的對比與總結(jié)我行在對非結(jié)構(gòu)化數(shù)據(jù)改造過程中，也考慮過傳統(tǒng) NAS 方案，對經(jīng)過對比， 發(fā)現(xiàn)傳統(tǒng) NAS 方

13、案并不能滿足我們的實際需求，下面一圖為對象存儲與分布式NAS 方案的對比：該圖總結(jié)而言，相對于傳統(tǒng)的 SAN 存和 NAS 存儲，對象存儲具有以下優(yōu)點： 1、降低數(shù)據(jù)存儲成本對象存儲可以使用低廉的 X86 服務(wù)器+對象存儲軟件實現(xiàn)，存儲成本比較低。2、數(shù)據(jù)可用性RAID，當(dāng)一個 RAID 磁盤出現(xiàn)故障，系統(tǒng)會慢如蝸牛需要數(shù)小時或數(shù)天來重建陣列。大多數(shù)對象存儲使用糾刪碼技術(shù)存儲數(shù)據(jù)，經(jīng)過合理設(shè)施后，可以以較低的副標數(shù)量保證數(shù)據(jù)的可用性。而數(shù)據(jù)恢復(fù)只需要數(shù)分鐘便可以完成，而且數(shù)據(jù)可用性不會中斷，性能也不會明顯退化。3、大容量和高擴展性對象存儲系統(tǒng)中，沒有目錄層次結(jié)構(gòu)(樹)，對象的存儲位置可以存儲在

14、不同的目錄路徑中易變檢索。這就使得對象存儲系統(tǒng)可以精準到每個字節(jié)，而且不受文件(對象)數(shù)量、文件大小和文件系統(tǒng)容量的限制。對象存儲系統(tǒng)可以不需要文件名、日期和其他文件屬性就可以查找文件。他們還可以使用元數(shù)據(jù)應(yīng)用服務(wù)水平協(xié)議(SLA),路由協(xié)議，備災(zāi)和災(zāi)難恢復(fù)，備份和數(shù)據(jù)刪除刪除以與自動存儲管理。這些是文件系統(tǒng)所不能解決的問題。4、容災(zāi)備份優(yōu)勢對象存儲系統(tǒng)如果設(shè)計合理，并不需要備份。多個副本可以確保數(shù)據(jù)始終保持可用狀態(tài)，而且異地災(zāi)難恢復(fù)備份也可以被自動創(chuàng)建。、5、性能優(yōu)勢利用分布式實現(xiàn)大規(guī)模 I/O 并行讀寫。每個節(jié)點都是獨立的，提供了集群的切入點，并運行一樣的代碼。這使得工作量可以平均分配到集

15、群中的所有節(jié)點上，避免 NAS 和集群文件系統(tǒng)中常見的熱節(jié)點問題的出現(xiàn)。自動負載均衡可以讓I/O 自動選擇合理的節(jié)點，保證系統(tǒng)性能最大化。因此，在現(xiàn)有 SAN 存儲架構(gòu)、傳統(tǒng) NAS 存儲架構(gòu)方案和對象存儲方案中，我們最終決定選擇采用對象存儲方案來對現(xiàn)有 SAN 分層存儲架構(gòu)進行改造。三、平臺測試與體驗為了充分了解對象存儲方案的優(yōu)勢，幫助我們且為了將來更好的利用好對象存儲，我們采用線上和線下兩種方式對 IBM 的 Cleversafe 對象存儲進行測試， 經(jīng)過充分的測試容、方案的準備和測試中詳盡的過程記錄，發(fā)現(xiàn)這款對象存儲軟件十分優(yōu)異，下面將整個測試容和測試過程匯總?cè)缦拢海?）測試容通過對如下

16、容的測試來驗證IBM Cleversafe產(chǎn)品是否滿足業(yè)務(wù)需求： 1、產(chǎn)品基本功能，如對非結(jié)構(gòu)化數(shù)據(jù)的上傳、修改、刪除2、產(chǎn)品的部署可行性和靈活性。包括部署的復(fù)雜度，模擬跨站點等場景3、產(chǎn)品的接口可用性性。和應(yīng)用系統(tǒng)的對接開發(fā)可行性，對應(yīng)用系統(tǒng)的改造可行性。4、產(chǎn)品的可靠性。是否有完善的性能保障方案，保障系統(tǒng)穩(wěn)定可靠運行。5、產(chǎn)品的易用性。包括圖形化的前端界面，方便日常的維護操作管理。6、產(chǎn)品的可維護性。包括硬件更換，系統(tǒng)升級，監(jiān)控管理和日志管理。（3）測試過程與結(jié)果1、功能性測試產(chǎn)品功能展現(xiàn)A、 案例編號：001B、 案例名稱：產(chǎn)品功能的基本展現(xiàn)C、 案例場景描述：創(chuàng)建對應(yīng)的存儲池（stor

17、agepool）、訪問池（access）、庫（vault）。D、 案例實現(xiàn)描述： 系統(tǒng)初始化完畢后，在管理界面實現(xiàn)對應(yīng)配置，存儲池選取生成的六臺 slicestor，訪問池選取配置 CloudStorage 方式，即 S3， 創(chuàng)建一個 IDA 為 4/5/6 的 Vault，即讀閾值為 4，寫閾值為 5，寬度為 6。意味著此庫會將寫入的數(shù)據(jù)通過糾刪碼計算為 6 片，當(dāng)獲取其中 4 片時，即完成讀操作，當(dāng)成功寫入 5 片時即完成寫操作。此時一個全新的系統(tǒng)，所有由虛機構(gòu)成，有一臺 manager，兩臺 accesser， 六臺 slicestor創(chuàng)建 storage pool：創(chuàng)建 access

18、pool：第一個紅框表明此 access pool 是使用何種 API 進行調(diào)用訪問創(chuàng)建庫（vault=bucket），即邏輯上的存儲空間。第一個紅框即為 IDA 的配置，第二個紅框是一些可選功能，依次為加密、版本管理、防刪除，第三個紅框為是否需要 S3 header 來構(gòu)建索引。對象讀寫刪操作A、 案例編號：002B、 案例名稱：存儲系統(tǒng)的上傳，下載，刪除C、 案例場景描述：通過 S3 Browser 工具，完成文件的上傳、下載與刪除D、 案例實現(xiàn)描述： 通過 S3 Browser 連接到已經(jīng)創(chuàng)建好的 Vault，上傳一個實例文件，確認存儲系統(tǒng)對應(yīng)的空間被消耗，下載此文件，確認可以被訪問后，

19、 刪除此文件。當(dāng) vault 創(chuàng)建完成后，需要配置該 vault 對應(yīng)的 access pool，以與用戶權(quán)限，亦可簡化配置 Vault template。S3Browser 中的存儲類型選擇 S3 兼容存儲，endpoint 即為 accesserIP（生產(chǎn)部署后對應(yīng)的是負載均衡器的服務(wù) IP），accesskeyID 需要在管理界面中生成獲取，如下截圖：第一步：進入 security tag，點擊進入需要連接存儲的賬戶（此賬戶可能對應(yīng)的是某應(yīng)用或某管理員）第二步：進入特定某用戶，如果已經(jīng)生成密鑰，即可直接拷貝，如果沒有生成過密鑰，則點擊右邊 Generate Key第三步，將此 key 拷

20、貝配置到 S3 Browser 中S3 Browser 可以查看到對應(yīng)的 vault 和執(zhí)行的上傳下載操作。在 S3 Browser 上完成刪除操作2、部署靈活性測試多站點部署A 、 案 例 編 號 ：003 B、 案例名稱：各節(jié)點的靈活部署C、 案例場景描述：在管理界面展現(xiàn)各站點機器的部署情況D、 案例實現(xiàn)描述： 模擬六臺 slicestor 分布在不同的三個城市的機房，其中accesser、manager 在分散在這三個機房中。在系統(tǒng)中邏輯部署成三個站點：、，存儲系統(tǒng)可以做到靈活部署和配置，一方面滿足我行組網(wǎng)需求、一方面提升運維效率。3、接口可用性測試接口對接A 、 案 例 編 號 ：00

21、4 B、 案例名稱：接口調(diào)用與可用性C、 案例場景描述：展現(xiàn)具體的 S3API 的調(diào)用方式D、 案例實現(xiàn)描述： 分別展現(xiàn) S3 Browser 和 CloudBerry Explore 兩種工具采用 S3 API 的調(diào)用方式配置對象存儲，以與對應(yīng) JAVA 語言，采用 AWS SDK 與Curl 的方式如果通過 S3 API 的方式訪問，其 access key 和 secret key 的獲取方式已在測試案例 2 已經(jīng)描述。S3 Browser 的配置界面：CloudBerry Explore：JAVA S3 SDK API 調(diào)用方式，完成對象 PUT 與 GET 的操作4、系統(tǒng)可靠性測試M

22、anager 節(jié)點失效A、 案例編號：005B、 案例名稱：系統(tǒng)可靠性-manager 失效C、 案例場景描述：當(dāng) manager 失效時，系統(tǒng)能夠正常運作D、 案例實現(xiàn)描述： 暫停 manager 的虛機，通過 S3 Browser 對存儲系統(tǒng)進行正常上傳測試所有正常運作的虛機節(jié)點將 manager shutdownS3 Browser 中的 log 顯示，讀寫操作均正常Accesser 節(jié)點失效A、 案例編號：006B、 案例名稱：系統(tǒng)可靠性-accesser 失效C、 案例場景描述：當(dāng) accesser 失效時，只要還有在線 accesser，系統(tǒng)就能夠正常運作D、 案例實現(xiàn)描述： 暫停

23、兩臺 accesser 當(dāng)中的一臺虛機，在 CloudBerry 中配置兩個 endpoint 的對象存儲，可以看到一個 endpoint 無法訪問，但是另外一個 endpoint 正常使用，并測試文件上傳，以與之前上傳文件的下載關(guān)閉 accesser1在 CloudBerry 中，當(dāng)兩臺 accesser 都正常的時候，可以同時讀取 vault 中的文件，而當(dāng)其中一臺 accesser 失效是，第二臺已經(jīng)可以獲得所有數(shù)據(jù)。失效前：失效后：Slicestor 節(jié)點失效，不同 IDA 配置A 、 案 例 編 號 ：007 B、 案例名稱：系統(tǒng)可靠性-slicestor 失效，測試不同 IDA 的

24、系統(tǒng)能力C、 案例場景描述：當(dāng) slicestor 失效時，在滿足 IDA 設(shè)置的極限值，系統(tǒng)能夠正常運作D、 案例實現(xiàn)描述： 在 IDA 為 4/5/6 的情況下，失效一臺可以正常讀寫，失效兩臺可以正常讀，失效三臺系統(tǒng)失效；在 IDA 為 3/4/6 的情況下，失效一臺或兩臺均可正常讀寫，失效三臺可以正常讀，失效四臺系統(tǒng)失效。配置兩種不同的 IDA 從而觀察當(dāng) slicestor 一臺臺失效時，系統(tǒng)的行為。當(dāng)一臺 slicestor 失效時：讀操作正常，可以看到所有 vault 當(dāng)中的文件，寫操作正常，可以新添加圖片當(dāng)兩臺 slicestor 失效時：IDA456 已經(jīng)無法寫入，報 inte

25、rnal error，讀正常，可以展示之前所有的圖片。而 IDA346 則讀寫正常當(dāng)三個節(jié)點失效時：IDA456 無法進行讀寫，IDA346 依然可讀，但是不可執(zhí)行寫操作。當(dāng)四個節(jié)點失效時，IDA456 和 IDA346 的 vault 都無常讀寫。掃描和重構(gòu)A、 案例編號：008B、 案例名稱：系統(tǒng)后臺掃描與重構(gòu)的驗證C、 案例場景描述：正常寫入某對象文件，強行進入后臺破壞某 slicestor 數(shù)據(jù)， 通過 Rebuild 方式獲取原數(shù)據(jù)D、 案例實現(xiàn)描述： 在 IDA 為 4/5/6 的桶下，寫入部分數(shù)據(jù)，在某臺 slicestor 中找到對應(yīng)的數(shù)據(jù)盤，刪除上面的切片數(shù)據(jù)，監(jiān)控管理界面的

26、 Rebuild 程序， 當(dāng)發(fā)現(xiàn) Rebuild 完成后，暫停另外兩部沒有改動的機器，測試讀取剛剛寫入的文件，從而驗證剛剛壞損的數(shù)據(jù)獲得 Rebuild。在未寫入數(shù)據(jù)時，先使用 root 權(quán)限，進入 slicestor6，查到到最底層， 無切片數(shù)據(jù)。從 CloudBerry 工具也是零數(shù)據(jù)當(dāng)寫入一個 9.1MB 的文件時，我們可以發(fā)現(xiàn)有三個切片文件出現(xiàn)，按照每4MB 一個切段的原理，因此一臺 slicestor 會存有 3 個切段數(shù)據(jù)的六分之一的切片數(shù)據(jù)，如下截圖在第三塊磁盤中找到切片數(shù)據(jù)將其中第一個切片數(shù)據(jù)進行 DD 篡改，只修改其中的一個字節(jié)，count=1，15:43 啟動篡改。此時關(guān)閉

27、另外兩臺沒有更改過切片數(shù)據(jù)的 slicestor4&5，發(fā)現(xiàn)下載對象。重啟兩臺剛剛關(guān)閉的機器，觀察 slicestor6 的 Rebuild 情況（注：UI 顯示界面與實際物理機操作有三分鐘左右延時。）大約在 3 分鐘后開始掃描程序。暫停 slicestor4&5 后，可以直接讀取同時，在 log 中，也能夠獲取對應(yīng)重構(gòu)的信息，時間戳也能匹配。5、系統(tǒng)管理性測試系統(tǒng)監(jiān)控、報警、報告A、 案例編號：009B、 案例名稱：系統(tǒng)監(jiān)控、報警與報告配置C、 案例場景描述：觀測之前系統(tǒng)測試中，所出現(xiàn)的異常D、 案例實現(xiàn)描述： 在管理中控界面，觀察之前一系列異常動作，展現(xiàn)告警數(shù)據(jù)、性能數(shù)據(jù)、

28、告警提示配置、日志配置界面、報表配置界面等告警總控臺：性能數(shù)據(jù)監(jiān)控：告警配置：收集日志配置：報表配置：6、系統(tǒng)可維護性測試網(wǎng)頁 troubleshootingA、 案例編號：010B、 案例名稱：網(wǎng)頁版的 troubleshooting 中控臺C、 案例場景描述：在管理界面中實現(xiàn) terminal 界面的 debug 指令D、 案例實現(xiàn)描述：實現(xiàn)一鍵點擊 troubleshooting 指令在 web UI 中，能夠?qū)υ诰€的機器進行簡單的 debug，發(fā)送一些常用指令，檢測其結(jié)果。在線系統(tǒng)升級A、 案例編號：011B、 案例名稱：簡易在線升級C、 案例場景描述：在管理界面中上傳升級包，實現(xiàn)全自

29、動化系統(tǒng)升級D、 案例實現(xiàn)描述：實現(xiàn)一鍵點擊，系統(tǒng)各部件完成自動升級的過程一鍵升級系統(tǒng)，Cleversafe 采取滾動式升級，先升級 manager，再由 manager 升級其他部件，系統(tǒng)會自己控制每次升級的臺數(shù)，從而保證系統(tǒng)始終可用。在線硬件更換A、 案例編號：012B、 案例名稱：在線硬件更換C、 案例場景描述：在管理界面中簡單步驟實現(xiàn)一臺機器的替換D、 案例實現(xiàn)描述：額外生成一臺 slicestor7 虛擬機，實現(xiàn)硬件替換功能創(chuàng)建第七臺 slicestor可以看到 slicestor7 已經(jīng) approved 進入到系統(tǒng)中了，第一步點擊右側(cè)的replace Device第二步，確認源機器和目的機器當(dāng)數(shù)據(jù)遷移完成后，會顯示對應(yīng)狀態(tài)注意：替換下來的機器需要重新安裝后才可以繼續(xù)使用。在線容量擴容A、 案例編號：013B、 案例名稱：存儲池擴容C、 案例場景描述：在管理界