11.5.2 – 11.7.2

1. 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28

2. File Locking • 為何會有複雜的locking技術? • 常出現需要同時存取相同檔案時，因而有不同的locks存在。 • File locking in NFSv4 • It is simple, only four operations related to locking. • Nonblocking • Lock操作上通常會要求一連續範圍(bytes)的檔案讀或寫的鎖定。 Figure 11-18. NFSv4 operations related to file locking. Lock的時間限定是由server決定,如果client沒有將locks上的租期重新向server端申請,就會被server移除。 Client端可去察看是否有相衝突的lock存在。 Client可向server要求建立在lock上的租期。

3. File Locking • 如果client所要求的鎖定和其他鎖定相衝突時會被拒絕，那client就會收到error訊息，一段時間後才會再去詢問server。 • FIFO-ordered list • 另一種比較有效且公平的作法是client可要求被放入一個由server端所維護的FIFO-ordered list。 • 只要一有相衝的lock被移除，server端就會允許client的下一個lock放在FIFO-ordered list最上方以供client在某段時間內的詢問。 • 此方法可避免server端一直去通知client端，且非常公平，Clients的lock要求都可參照FIFO-ordered list就可以得知目前lock的狀態。

4. File Locking • Share reservation in NFS • Share reservation也是一種lock的鎖定，和locking是完全獨立的，被用來實做在windows-based的NFS上。 • 當一個client端要開啟一個檔案時，會指定要存取的檔案型態(也就是READ,WRITE或BOTH)，以及指定server端要拒絕其他client的存取型態(NONE,READ,WRITE,or BOTH)。如果server不能滿足client要求，那麼client開啟檔案就會失敗。 Figure 11-19. The result of an open operation with share reservations in NFS. (a) When the client requests shared access given the current denial state. Client端要求特定 access type,會得到另一個client正在使用的狀態。

5. File Locking (cont.) Figure 11-19. The result of an open operation with share reservations in NFS.(b) When the client requests a denial state given the current file access state. Client 端要求現在正在使用的檔案狀態(denial state)。

6. Sharing files in coda • 在NFS中此機制會命令最後的process被關閉時,狀態會回傳給Server,有任何updates同時發生時,最早的session會被遺失。 • Coda file System( Kistler and Satyanaryanan, 1992) • It uses a specialallocation scheme to accommodate file sharing. 這機制和 NFS裡的Share reservations類似。 • Operation： Figure 11-20. The transactional behavior in sharing files in Coda. Server通知client A資訊過時。 以transaction的觀點來看,因為session SA在session SB之前發生,所以沒什麼關係。

7. Client-Side Caching • Caching in NFS • NFSv3 • 不同的caching policy就有不同的caching實做方式,大部分都會不一致,儘管實做上,client可以擁有old cached data for 30sec而不知情。 • NFSv4 • 能以實做方式解決一致性問題，一般NFS所假設的caching模式如下： Figure 11-21. Client-side caching in NFS. Using the same consistency parameters.

8. Client-Side Caching (Cont.) • NFSv4對於caching file data有兩種不同方式 • 當client讀取從server端檔案，用了大量的read。 • Write操作也能在cache中實現。當client關閉檔案時，如果檔案有任何變更，NFS會要求cached data要傳回到server。 一旦(部分)檔案被cached，client即便關閉file，能保留在cache裡的資料。 • NFS要求無論何時client端開啟先前已關閉的檔案，都要馬上使cached data重新啟用。 • Cached data何時重新啟用(revalidation) • 檢查檔案最近的更新時間 • 當cache裡包含過時的資料

9. Client-Side Caching (Cont.) • 在NFSv4中，當檔案被開啟時，server可能會賦予一些client端權力。 • 當client被同一機器的其他client允許能本地處理開啟與關閉的操作，Open delegation就會發生。正常來說，server是負責檢查檔案是否有被成功開啟。 • Open delegation • Client有時候被允許做一些決定以避免通知server • Ex： 假如server被client要求對開啟的檔案加以寫入，來自於其他 同一機器上的client對file locking的request也能本地端處理，但 server會拒絕來自其他機器上client的存取要求。 • Client有時候還是要通知server • Ex：假如client只做讀取的動作，其他local client發出寫入要求，就 要通知server，不可能直接在本地端處理這些request。

10. Client-Side Caching (Cont.) • 收回委派(recall the delegation)的權力 • Server賦予檔案的副本給Client時，最重要的要能夠要能夠回收檔案以便於讓其他Client能存取更新過的檔案。如下表： Figure 11-22. Using the NFSv4 callback mechanism to recall file delegation. • NFS的Callback是使用RPC機制去做的。 • NFS server不可能實做為stateless server。 Question: 結合stateful server和delegation 會有很大的問題!萬一 Server指派file給不 回應的client呢? Solution: lease

11. Client-Side Caching (Cont.) • Write-through cache coherence policy • Clients可各自cache attribute values，但會有不一致的情形。透過此機制可將更改過的attribute values立即傳到server端。 • 為要減輕不一致的情形，NFS使用lease在cached attributes、file handles及directories上。 • 隨著時間經過，無效的cache entries要在再度被使用之前要能revalidation。

12. Client-Side Caching in Coda • 此機制對於Coda operation來說是重要的兩個理由： • Caching可達成scalability。 • Caching有高度的容錯力，所以client比較不依賴於Server的可用性。 • Cache coherence(讀取連貫)在coda中是由callbacks所維護。 • Callback promise: server端會持續追蹤client從server那裡得到的檔案(local copy)，即server可以被說成是記錄一個client端的callback promise。 • Callback break: 一旦client端檔案被更新就會通知server， server會端發出invalid message給其他client。一個invalid message就叫一個callback break。當server發出invalid message給client時，會丟掉原本在client所持有的callback promise。

13. Client-Side Caching in Coda (Cont.) Client A在開啟Session S’A之前,發現自己檔案f的local copy已無效所以向server重新取得新的版本。 Figure 11-23. The use of local copies when opening a session in Coda. Client B更新檔案通知server,由server發出callback break,並丟棄原本持有client A的callback promise。 Client開啟Session SA, Server端就記錄一個Callback promise Client B想要開啟session S’B,也去check server還持有自己的callback promise,所以Client B可以繼續使用Session B的local copy。

14. Client-Side Caching for Portable Devices • 很多設備為非永久性連結，ex: PDA、筆記型電腦裝置以及可攜式多媒體裝置(ex:電影或聲音播放器)。 • 大部分的情況都是以上傳/下載模式來維護可攜式裝置裡的檔案。檔案通常儲存在local端的設備或是透過網路連結到系統。 • Tolia et al. (2004)提出一個很簡單的方法：將以密碼加密的hash資料儲存在檔案中。這些hashes儲存在可攜式裝置上，用來將request導向到相關的內容/頁面上。 • 當檔案被擷取時，系統會檢查檔案是否可在local端取得以及檔案是否為最新的資料。請注意舊有資料會有不同的hash，如果檔案可在本地端取得，就會傳回給client，否則就是透過網路傳輸資料。 • 未來期望user會使用特別的程式事先在設備上安裝好檔案。

15. Server-Side Replication • Server端的複製技術在分散式的檔案系統裡很少見，為要因應緊急時需要能快速取得資料所以才有複製的應用。 • 從績效的觀點來看 • 在整個檔案或大部分的檔案上用cache，效率會來得更好。 • 高度複製但讀取/寫入比率過低，效率也會降低。因為每更新一次就需要一次replica,所以同步更新需要用到同步化的技術，導致需要更多的溝通與績效的低落。 • 基於上述理由，檔案伺服器通常只為了要容錯時才會複製。

16. Server Replication in Coda • Coda • 允許檔案伺服器上的複製。 • 使用replicated-write協定去維護volume副本的一致性。 • 特別也使用ROWA的變形。 • Volume • 是以一群檔案為單位的複製。 • 一個volume是對應一個Unix硬碟分割區。 • Volume Storage Group (VSG) • 一群Coda servers有著一份volume的copy，名為volume的Volume Storage Group。 • 如果有失敗情形發生，Client就不能存取所有在VSG中的Server。 • Accessible Volume Storage Group (AVSG) • 為Client端所能存取的VSG，Client可聯繫存在VSG裡的Server。如果AVSG是空的，則Client端就被稱為是disconnected。

17. Server Replication in Coda (Cont.) • ROWA (Read-one, Write All)的變形： • 當Client需要讀取一個檔案，就會聯繫關於位在此檔案裡的AVSG的member。當關閉已更新的檔案，Client會平行傳輸此更新檔給AVSG裡每一member。這種平行傳輸可藉由MultiRPC來完成。 Figure 11-24. Two clients with a different AVSG for the same replicated file. 每個Server會為每一file維護coda version vector。 CVVi(f)[j]=k即是Serveri知道Serverj擁有f至少k個最新版本的個數。 Client A更新檔案後傳給Server S1,S2 CVV1(f)=CVV2(f)=[2,2,1] ClientB更新檔案後傳回Server S3CVV3(f)=[1,1,2] 當Broken network修復了，三個server勢必要重新整合各自 的file copy，並比較各自version vector來修復彼此相衝的版本。 大部分情況下，版本衝突可依賴應用程式自動解決，或人為處理。 有一檔案的副本存於Server S1,S2,S3。而Server S1,S2是Client A可存取的AVSG。利用Coda version vector: CVVi(f)[i]為存於Server Si中file目前版本個數 Client B可存取的AVSG是在Server S3上。

18. Structured Peer-to-Peer Systems • 由Gopalakrishnan et al. (2004)所提出，能在peer-to-peer間平衡負載的查詢機制，即查詢路徑上所有節點的load都考量到。 • 當R檢查完有檔案要下載給P，又有很多其他的節點也向R索求檔案的話，就會要求P複製檔案的副本(數量要是R被索求檔案的最大數量)。中間的節點則有pointer指向P，當pointer所指向到的檔案沒有再被要求時就會很快被移除。 Figure 11-25. Balancing load in a peer-to-peer system by replication.

19. File Replication in Grid Systems • 在Grid所應用的資料都是read only，且鮮少更新。資料的來源都是從sensors或是其他的applications來的。也因此可以大量的應用data replication。 • 但資料集的size有時過於龐大，需要一些測量機制以避免data providers(儲存在資料的機器)在資料傳輸於網路上負擔過重。 • Grid systems中的複製技術 • 已演化到在最佳的來源上複製資料的問題。這種問題可由replication services解決，類似之前討論過的naming system的location service。即client端可利用FTP的協定下載檔案，用replication location services註冊即可取得replication。 • 還有一個最明顯的方法就是使用之前討論過的DHT-based system可以減少replicas被集中查詢的問題。

20. Handling Byzantine Failures • 應用： • 分散式系統，尤其是在NFS系統上。 • Basic idea • 藉由建構一組finite state machines以主動指派replication以及在這一組中有些nonfaulty processes可以執行相同順序的操作。 • 假設至多有k個processes 立即fail，client會送出operation給整個group，然後收到至少k+1不同的processes。 • 為要避免Byzantine failures，server group必定至少要有3k+1 processes. • Processes有一系列的views，每個view的member都同意nonfaulty processes及當現有的master掛掉時，要能啟動一個新的view。

21. Handling Byzantine Failures (Cont.) • Quorum mechanism • 能確保每個request的順序都相同。 • quorum certificate • 當process收到request時,將它送給其他process,並確保收到至少2k+1個process收到相同的request之確認訊息。 Figure 11-26. The different phases in Byzantine fault tolerance. 此階段是由每個process去告訴others存在自己local端的request log。因為crash時，每個process也能根據哪個view、哪個sequence number被指派做復原。 Slave Replicas收到後也接受由master傳來的sequence number，它就把這接受的訊息廣播出去。 Master收到client的request後隨即廣播相關操作的sequence number。 Client送出request給所有整個server group。

22. High Availability in Peer-to-Peer Systems • Redundancy • 可確保在peer-to-peer系統中的可用性。 • 當談到檔案時，實際上可以透過兩個不同的方法來瞭解它： • Replication • Erasure coding • 是一個有名的技術，即是把檔案分成m個區段再隨後加以編碼成n區段，但n>m區段。 • 重要的是只要任何一組m個編碼過的區段就足以重建整個原始檔案。 • 假設節點平均的可用性為a， ε表示部分檔案不能取得，但我們必須保證至少有m個區段是可以獲得的。 1- ε= ai(1-a)n-i

23. High Availability in Peer-to-Peer Systems (Cont.) • 如果假設node是分開的且是分散的，我們可以說 1- ε=1-(1-a)rrep • 我們可以考慮在節點可用度a關係上rrep /rec的比率來表達replication與erasure coding之間的不同。 Figure 11-27. The ratio rrep /rec as a function of node availability a.

24. High Availability in Peer-to-Peer Systems (Cont.) • 從上圖可看出在所有情形下，erasure coding需要的redundancy會比replicating files還少。換句話說，replicating files是為要增加peer-to-peer網路節點的可用度，但從儲存的空間來看沒有比使用erasure coding來得有效率。 • 維護redundancy會增加communication，那麼越低的redundancy就可以更節省頻寬的使用。 • 當這些節點對應到的user machines所透過非對稱DSL或cable lines連上網際網路時，效率就變的明顯重要。因為連出的link通常只有每秒幾百k的大小而已。