特集 太郎さんの青春 太郎さんの青春 · 小口太郎生誕太郎さんの青春 特集 120周年 琵琶湖周航の歌 100周年 小口太郎顕彰碑等建立 30周年
11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.
-
date post
20-Dec-2015 -
Category
Documents
-
view
235 -
download
5
Transcript of 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.
![Page 1: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/1.jpg)
11.5.2 – 11.7.2
Teacher: 周清江By 郎健如
Date: 08/5/28
![Page 2: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/2.jpg)
File Locking
為何會有複雜的 locking 技術 ?◦ 常出現需要同時存取相同檔案時,因而有不同的 locks 存在。
File locking in NFSv4◦ It is simple, only four operations related to locking.
NonblockingNonblocking◦ Lock 操作上通常會要求一連續範圍 (bytes) 的檔案讀或寫的鎖定。
Figure 11-18. NFSv4 operations related to file locking.
Client 端可去察看是否有相衝突的 lock 存在。
Lock 的時間限定是由server 決定 , 如果 client 沒有將 locks 上的租期重新向 server 端申請 , 就會被 server
移除。
Client 可向 server 要求建立在 lock 上的租期。
![Page 3: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/3.jpg)
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 的狀態。
![Page 4: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/4.jpg)
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 正在使用的狀態。
![Page 5: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/5.jpg)
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) 。
![Page 6: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/6.jpg)
Sharing files in coda 在 NFS 中此機制會命令最後的 process 被關閉時 , 狀態會回傳
給 Server, 有任何 updates 同時發生時 , 最早的 session 會被遺失。
Coda file System( Kistler and Satyanaryanan, 1992)◦ It uses a specialspecial allocation schemeallocation scheme to accommodate file shari
ng. 這機制和 NFS 裡的 Share reservations 類似。
◦ Operation :
Figure 11-20. The transactional behavior in sharing files in Coda.
Server 通知 client A 資訊過時。
以 transaction 的觀點來看 , 因為 session S
A 在 session SB 之前發生 , 所以沒什麼關
係。
![Page 7: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/7.jpg)
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.
![Page 8: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/8.jpg)
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 裡包含過時的資料
![Page 9: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/9.jpg)
Client-Side Caching (Cont.)
在 NFSv4 中,當檔案被開啟時, server 可能會賦予一些 client 端權力。
當 client 被同一機器的其他 client 允許能本地處理開啟與關閉的操作, Open delegationOpen delegation 就會發生。正常來說, server 是負責檢查檔案是否有被成功開啟。
Open delegation◦ Client 有時候被允許做一些決定以避免通知 server
Ex: 假如 server 被 client 要求對開啟的檔案加以寫入,來自於其他 同一機器上的 client 對 file locking 的 request 也能本地端處理,但 server 會拒絕來自其他機器上 client 的存取要求。
◦ Client 有時候還是要通知 server
Ex:假如 client 只做讀取的動作,其他 local client 發出寫入要求,就 要通知 server ,不可能直接在本地端處理這些 request 。
![Page 10: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/10.jpg)
Client-Side Caching (Cont.)
收回委派收回委派 (recall the delegation)(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
![Page 11: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/11.jpg)
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 。
![Page 12: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/12.jpg)
Client-Side Caching in Coda
此機制對於 Coda operation 來說是重要的兩個理由:◦ Caching 可達成 scalability 。◦ Caching 有高度的容錯力,所以 client 比較不依賴於 Server 的可用
性。
Cache coherence( 讀取連貫 ) 在 coda 中是由 callbacks 所維護。
Callback promiseCallback promise: server 端會持續追蹤 client從 server 那裡得到的檔案 (local copy) ,即 server 可以被說成是記錄一個 client 端的 callback promise 。
Callback breakCallback break: 一旦 client 端檔案被更新就會通知 server , server 會端發出 invalid message 給其他 client 。一個 invalid
message 就叫一個 callback break 。當 server 發出 invalid message 給 client 時,會丟掉原本在 client 所持有的 callback promise 。
![Page 13: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/13.jpg)
Client-Side Caching in Coda (Cont.)
Figure 11-23. The use of local copies when
opening a session in Coda.
Client B更新檔案通知 server,由 server 發出 callback break,並丟棄原本持有 client A 的 ca
llback promise 。
Client B想要開啟 session S’B, 也去check server還持有自己的 callback promise, 所以 Client B 可以繼續使
用 Session B 的 local copy 。
Client A 在開啟 Session S’
A 之前 , 發現自己檔案 f 的 local copy已無效所以向 server 重新取得新的版本。
Client 開啟 Session SA, Server 端就記錄一個
Callback promise
![Page 14: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/14.jpg)
Client-Side Caching for Portable Devices 很多設備為非永久性連結非永久性連結, ex: PDA、筆記型電腦裝置以及可攜式多媒體裝置 (ex:電影或聲音播放器 ) 。
大部分的情況都是以上傳上傳 // 下載模式下載模式來維護可攜式裝置裡的檔案。檔案通常儲存在 local 端的設備或是透過網路連結到系統。
Tolia et al. (2004)提出一個很簡單的方法:將以密碼加密的 hash 資料儲存在檔案中。這些 hashes儲存在可攜式裝置上,用來將 request導向到相關的內容 /頁面上。
◦ 當檔案被擷取時,系統會檢查檔案是否可在 local 端取得以及檔案是否為最新的資料。請注意舊有資料會有不同的 hash ,如果檔案可在本地端取得,就會傳回給 client ,否則就是透過網路傳輸資料。
未來期望 user 會使用特別的程式事先在設備上安裝好檔案。
![Page 15: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/15.jpg)
Server-Side Replication
Server 端的複製技術在分散式的檔案系統裡很少見,為要因應緊急時需要能快速取得資料所以才有複製的應用。
從績效的觀點來看
◦ 在整個檔案或大部分的檔案上用 cache ,效率會來得更好。
◦ 高度複製但讀取 / 寫入比率過低,效率也會降低。因為每更新一次就需要一次 replica, 所以同步更新需要用到同步化的技術,導致需要更多的溝通與績效的低落。
基於上述理由,檔案伺服器通常只為了要容錯時才會複製。
![Page 16: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/16.jpg)
Server Replication in Coda
Coda◦ 允許檔案伺服器上的複製。◦ 使用 replicated-write協定去維護 volume副本的一致性。◦ 特別也使用 ROWA 的變形。
Volume◦ 是以一群檔案為單位的複製。◦ 一個 volume 是對應一個 Unix 硬碟分割區。
Volume Storage Group (VSG)◦ 一群 Coda servers 有著一份 volume 的 copy ,名為 volume 的 Volume S
torage Group 。
◦ 如果有失敗情形發生, Client 就不能存取所有在 VSG中的 Server 。
Accessible Volume Storage Group (AVSG) ◦ 為 Client 端所能存取的 VSG, Client 可聯繫存在 VSG裡的 Server 。如果
AVSG是空的,則 Client 端就被稱為是 disconnected 。
![Page 17: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/17.jpg)
每個 Server 會為每一 file 維護 coda version vector 。
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 S1,S2,S3 。而 Server S1,S2 是Client A 可存取的AVSG 。利用 Coda version vector:
CVVi(f)[i] 為存於 Server Si 中 file 目
前版本個數
CVVi(f)[j]=k即是 Serveri 知道 Serverj 擁有 f至少 k 個最新版本的個數。
Client B 可存取的 AVSG 是在 Server S3 上。
Client A更新檔案後傳給 Server S1,S2 CVV1(f)=CVV2(f)=[2,2,1]ClientB更新檔案後傳回 Server S3CVV3(f)=[1,1,2]當 Broken network修復了,三個 server勢必要重新整合各自的 file copy ,並比較各自 version vector 來修復彼此相衝的版本。大部分情況下,版本衝突可依賴應用程式自動解決,或人為處理。
![Page 18: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/18.jpg)
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.
![Page 19: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/19.jpg)
File Replication in Grid Systems
在 Grid 所應用的資料都是 read only ,且鮮少更新。資料的來源都是從 sensors 或是其他的 applications 來的。也因此可以大量的應用 data replication 。
但資料集的 size 有時過於龐大,需要一些測量機制以避免 data providers(儲存在資料的機器 ) 在資料傳輸於網路上負擔過重。
Grid systems 中的複製技術◦ 已演化到在最佳的來源上複製資料的問題。這種問題可由 replicatreplicat
ion servicesion services 解決,類似之前討論過的 naming system 的 location service 。即 client 端可利用 FTP的協定下載檔案,用 replication location services註冊即可取得 replication 。
◦ 還有一個最明顯的方法就是使用之前討論過的 DHT-based system可以減少 replicas 被集中查詢的問題。
![Page 20: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/20.jpg)
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 。
![Page 21: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/21.jpg)
Handling Byzantine Failures (Cont.)
Quorum mechanism◦ 能確保每個 request 的順序都相同。◦ quorum certificatequorum certificate
當 process 收到 request 時 , 將它送給其他 process,並確保收到至少 2k+1 個 process 收到相同的 request 之確認訊息確認訊息。
Figure 11-26. The different phases in Byzantine fault tolerance.
Master 收到client 的 request 後隨即廣播相關操作的 sequence number 。
Client送出 request 給所有整個 ser
ver group 。
Slave Replicas 收到後也接受由 master 傳來的 sequence number ,它
就把這接受的訊息廣播出去。
此階段是由每個 process 去告訴 others 存在自己 local 端的 request log 。因為 crash 時,每個 process 也能根據哪個 view、哪個 sequence number 被指派做復原。
![Page 22: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/22.jpg)
High Availability in Peer-to-Peer SystemsRedundancy
◦ 可確保在 peer-to-peer系統中的可用性。
◦ 當談到檔案時,實際上可以透過兩個不同的方法來瞭解它: Replication Erasure coding
是一個有名的技術,即是把檔案分成m 個區段再隨後加以編碼成 n區段,但 n>m區段。
重要的是只要任何一組m 個編碼過的區段就足以重建整個原始檔案。
假設節點平均的可用性為 a , ε 表示部分檔案不能取得,但我們必須保證至少有 m 個區段是可以獲得的。
1- ε= ai(1-a)n-i
![Page 23: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/23.jpg)
High Availability in Peer-to-Peer Systems (Cont.) 如果假設 node 是分開的且是分散的,我們可以說 1- ε=1-(1-a)r
rep
我們可以考慮在節點可用度 a 關係上 rrep /rec 的比率來表達 replication與 erasure coding 之間的不同。
Figure 11-27. The ratio rrep /rec as a function of node availability a.
![Page 24: 11.5.2 – 11.7.2 Teacher: 周清江 By 郎健如 Date: 08/5/28.](https://reader036.fdocuments.net/reader036/viewer/2022062320/56649d4e5503460f94a2d009/html5/thumbnails/24.jpg)
High Availability in Peer-to-Peer Systems (Cont.) 從上圖可看出在所有情形下, erasure coding 需要的 redund
ancy 會比 replicating files還少。換句話說, replicating files 是為要增加 peer-to-peer網路節點的可用度,但從儲存的空間來看沒有比使用 erasure coding 來得有效率。
維護 redundancy 會增加 communication ,那麼越低的 redundancy 就可以更節省頻寬的使用。
當這些節點對應到的 user machines 所透過非對稱 DSL 或 cable lines 連上網際網路時,效率就變的明顯重要。因為連出的link 通常只有每秒幾百 k 的大小而已。