【正文】 表示object計數(shù)，bytes_used表示使用空間，hash表示db文件的哈希值, reported_put_timestamp, reported_delete_timestamp, reported_object_count, reported_bytes_used表示reported的狀態(tài)信息，id表示統(tǒng)一標識符，status表示container狀態(tài)，status_changed_at表示更改時間，metadata表示container的元數(shù)據(jù)，x_container_sync_point1表示同步點1，x_container_sync_point2表示同步點2。這也是Swift存儲的一個優(yōu)點。對于實際的需求，可以通過客戶端內(nèi)部自動建立新的容器來解決。在objects目錄下存放的是各個partition目錄，suffix_path目錄下是由object的hash_path名構成的目錄，在hash_path目錄下存放了關于object的數(shù)據(jù)和元數(shù)據(jù)。；當對象被刪除后，這個文件會在定期的檢查過后清理掉。/account/container/object39。其中HASH_PATH_SUFFIX作為salt來增加安全性，HASH_PATH_SUFFIX值存放在/etc/swift/。一種是客戶端和系統(tǒng)之間的同步，主要通過調(diào)用對象服務器的PUT、GET方法來完成；另一種是當系統(tǒng)發(fā)生故障后，系統(tǒng)內(nèi)部為了維護一致性進行的數(shù)據(jù)同步，這個功能主要由復制器（Replication）完成。而對于一致性維護的同步過程，主要集中在討論方案的變化對一致性維護的影響。 對象服務對象服務器（Object Server）主要用來接收和處理用戶發(fā)送的Object請求，如上傳、下載、刪除等。由對象服務器來處理請求并返回結果信息。通過HTTP協(xié)議，主要請求的方法是PUT、GET。上傳的文件會先存儲在tmp目錄中（臨時文件），等到文件上傳完畢，再轉(zhuǎn)存在相應的路徑中。object 生成后，會通知對應的container，然后container會通知對應的account，這樣對于單個的對象服務器就上傳成功了。如果對象的創(chuàng)建由于某些原因失敗，比如元數(shù)據(jù)信息不符合要求，則返回錯誤：error_response = check_object_creation(request, obj)并退出。下面，展示了上傳文件的系統(tǒng)操作流程。當文件更新時，對于對應的文件來說，是將原有的存儲對像刪除并寫入新的存儲對象。在文件的上傳中，元數(shù)據(jù)的寫入由DiskFile類的put方法來完成，：表 33元數(shù)據(jù)寫入def put(self, fd, tmppath, metadata, extension=39。): metadata[39。] = timestamp = normalize_timestamp(metadata[39。]) write_metadata(fd, metadata)元數(shù)據(jù)寫入文件 if 39。 in metadata: (fd, 0, int(metadata[39。])) (, fd) invalidate_hash(()) renamer(tmppath, (, timestamp + extension))重命名文件 = metadata在該操作完成后，調(diào)用container_update通知Container，使其更新db文件的Object表。并返回結果。當請求發(fā)送到對象服務器，GET方法將首先檢查所請求的設備掛載情況和對象的完整性。：表 34 對象檢測代碼response = Response(app_iter=file, request=request, conditional_response=True) [39。] = ( 39。, 39。) for key, value in (): if ().startswith(39。) or \ () in : [key] = value = [39。] = float([39。]) = file_size if and \ ( or (39。 not in and 39。 not in )): = True if 39。 in : = [39。] [39。] = [39。] return (response)如以上代碼所示，服務器需要檢測對象的長度、元數(shù)據(jù)信息、ETAG、用戶令牌和存儲令牌等信息。而所有的檢測都通過的情況下，服務器將創(chuàng)建一個response對象，其中包含了存儲對象的基本屬性信息。 復制器在Swift系統(tǒng)中，復制器主要完成兩類數(shù)據(jù)的復制，即數(shù)據(jù)庫復制和對象復制，前者并不直接對存儲對像的訪問性能產(chǎn)生影響，因而在本文中不作討論。這些分歧將會通過復制器，以端對端的形式來進行響應和操作。通過將待處理對象的數(shù)據(jù)包括在請求中，將可以確保數(shù)據(jù)能夠被送到正確的存儲節(jié)點上。復制器是Swift中一個變化很快的熱點內(nèi)容，同時也被認為是系統(tǒng)中性能優(yōu)化的重要切入點。 對象復制早先的復制器在推送信息的時候直接使用rsync算法，將目錄結構廣播到其他節(jié)點中。而且對于目錄結構的變化過于敏感，當目錄結構不保存在內(nèi)存中時，復制代價將極大的提高。復制器將pkl文件發(fā)送到遠程節(jié)點，當發(fā)現(xiàn)無效的哈希值時，具有不同哈希值的后綴目錄將會以rsync方式發(fā)送。對象復制的性能主要在于它要遍歷的未緩存目錄的數(shù)量，失效的后綴目錄的哈希值的結果集。 代碼分析對于復制器的分析和開發(fā)工作，主要在于復制器的對pkl文件的解析和修改上，在系統(tǒng)的代碼中，就是get_hash和invalidate_hash兩個方法上面。在swift\obj\，已經(jīng)指定HASH_FILE = 39。類似的，當我們需要讓復制器接受和解析多個HASH_FILE的時候，可以參照這個方式定義新的變量或者修改HASH_FILE的結構，使之保存多種變量。get_hashes(partition_dir,do_listdir=False,==HASH_FILE) 獲得pkl文件路徑modifiedFalsehashes{}mtime1try:with39。)fp:hashes(fp) 使用pickle打開pkl文件mtime(hashes_file)except=do_listdir:forinlen(suff)3:(suff,=None)hash_recalculate)重新計算hash數(shù)值forhash_():ifhash_:suffix_dirjoin(partition_dir,=reclaim_age)hashed1excepthashes[suffix]exceptErrorsuffix39。=modified:當處于需要更新的狀態(tài)時，該狀態(tài)主要由上面的過程指定。lock_path(partition_dir):if(hashes_file)\(hashes_file)mtime:write_pickle(hashes,partition_dir,hashed,get_hashes(partition_dir,do_listdir,reclaim_age)再次調(diào)用本函數(shù)以驗證else:returnhashes 成功返回hash內(nèi)容get_hashes方法主要是通過調(diào)用cPickle來解析pkl文件。發(fā)現(xiàn)存在需要更新的情況時，寫入pkl文件并再次進行驗證。invalidate_hash方法解析。invalidate_hash(suffix_dir):===HASH_FILE)獲得pkl文件路徑withopen(hashes_file,rb39。as=suffixhashesnotException:returnhashes[suffix]Nonewrite_pickle(hashes,partition_dir, 本章小結本章主要分析了OpenStack云計算平臺的主要組織結構，分別簡單的描述了每一個組件的作用。本章的后兩節(jié)，通過對Swift存儲結構和對象的兩類同步方法的研究，分析了對象存儲系統(tǒng)的主要結構和工作流程。并根據(jù)相應的特點，討論了他們在可配置副本方案下完成數(shù)據(jù)同步工作所需要進行的改變。46浙江大學碩士學位論文 第4章總結與展望第4章 設計與分析 系統(tǒng)設計從上一章的主要架構分析可以看出，Swift通過副本的方式實現(xiàn)了對象存儲的持久性要求，同時多個對象也可以并行的向外提供服務。 原型分析通過對對象服務的兩個主要的方法進行分析，可以對用戶與系統(tǒng)之間的數(shù)據(jù)同步過程有一個清晰的認識。通過處理返回信息和簡單多數(shù)協(xié)議，判定文件的上傳和下載是否成功。在發(fā)送文件的過程中，先發(fā)送文件的屬性信息，然后利用對象存儲直接訪問的優(yōu)勢，由代理服務器直接訪問存儲對像。而通過對復制器的分析，可以看出，保存在不同的Zone之間的副本，通過復制器的檢查并傳送差異文件來維持一致性。 開發(fā)設計思路從復制器的工作流程可以看出，在整個一致性維護的過程中，最主要的hash數(shù)據(jù)存儲在pkl文件中，而系統(tǒng)的一部分配置參數(shù)在系統(tǒng)啟動的時候從配置信息中獲得。在整個工作流程中，首先需要對Proxy Server進行修改，使之可以對不同的存儲方案采取不同的簡單多數(shù)表決，然后需要利用對象存儲的用戶屬性特征，增加關于副本的存儲份數(shù)的記錄，用于向Proxy Server以及復制器提供比較信息。這種方式對原系統(tǒng)結構的改變較小，對系統(tǒng)的接口和通用性幾乎不造成破壞，但是設計復雜性較高，在系統(tǒng)內(nèi)部需要對多個方法和處理流程進行修改，而且在部分應用場景下會帶來性能相對的下降。這種方法對系統(tǒng)結構的改變較大，并且對象訪問的接口需要一定的修改，主要適用于深度的二次開發(fā)或者獨立存儲系統(tǒng)的部署，不過由于在一致性保持的操作流程上比較簡單，系統(tǒng)內(nèi)部執(zhí)行的性能會比較平穩(wěn)。值得注意的是，在生產(chǎn)環(huán)境下，一般會采用第三方的負載均衡工具，這些工具在高負載的情況下，會對數(shù)據(jù)同步尤其是客戶端和系統(tǒng)之間的對象服務型同步產(chǎn)生一定的影響，這種影響主要在于平衡設備性能，對系統(tǒng)效率會有所提高從而減輕由于設計因素帶來的性能下降。 系統(tǒng)結構在本系統(tǒng)的設計中，設計系統(tǒng)的總體結構與原系統(tǒng)基本相似。由于系統(tǒng)中不同的存儲方案對應著不同的副本數(shù)量，而一致性哈希的隨機性使得這些不同的副本數(shù)量所需要的存儲空間是均勻的分散在存儲設備上的，那么，就需要保證最大數(shù)量的副本個數(shù)可以在系統(tǒng)中得到完整的保存。Swift系統(tǒng)基本的結構需要保證每一個Zone上面最多只有一份副本，副本保存的數(shù)量n就必須和Zone的數(shù)量M之間滿足：n小于等于M。存儲系統(tǒng)初始化時按照最大的副本數(shù)量值建立Ring，而在系統(tǒng)的運行過程中，每個存儲對象的副本個數(shù)由客戶端指定，并通過代理服務器進行分配和維護。這些存儲對象的副本數(shù)量由自身的用戶屬性來維護，并且在pkl文件中分別保存。但是如果完全按照最大的副本數(shù)量來設計，在文件系統(tǒng)中，會有一定的目錄冗余。 系統(tǒng)工作流程由于采用的是對主流程修改較小的處理方案，從文件的基本服務上來說，總體流程和原系統(tǒng)總體保持高度一致，從而保證調(diào)整后的系統(tǒng)可以與OpenStack平臺的組件保持原有的互操作性。而需要下載對象時，客戶端只需要傳遞對象的存儲名稱（OID），系統(tǒng)仍然是由代理服務器和Ring計算出存儲位置，再通過主要的變化在于復制器的操作中，對于不同的副本數(shù)量，復制器通過解析和對比pkl文件來判斷存儲對象的一致性時，同時需要計算該對象是否需要保存在自身控制的Partition下。同時，在處理完成后，寫入pkl文件的過程也應該有著類似的分類處理機制。運行的存儲服務可以通過自己開發(fā)的客戶端程序來調(diào)用API，訪問存儲。獲取權限方法調(diào)用，：表 41 auth調(diào)用def=:5000/39。=auth39。{39。:password39。passwd,39。:username},39。:=tokens)resp,=token_url,===access39。servicecatalogs:iftype39。==objectstore39。=endpoints39。publicURL39。=access39。token39。id39。Errorreturntoken_id 獲得URL和令牌下載對象，這里將獲得的對象按照文本的方式打印出來：deftokenget_auth()parsed,==%s/%s/%s39。%quote(filedir),=GET39。=XAuthToken39。token}(method,39。==body對于其他的功能，其代碼結構與上述的方法是相似的。在本文所討論的系統(tǒng)的開發(fā)中，在客戶端層面與開源項目swiftclient相似，主要是上傳過程中需要提交副本數(shù)量請求