客戶端緩存
我們緩存什么腋逆？
- 只讀文件數(shù)據(jù)和目錄數(shù)據(jù)
- 由客戶機(jī)寫入的數(shù)據(jù)
- 什么時(shí)候?qū)懭敕?wù)器慕嚷？
- 如果客戶機(jī)宕機(jī)了偶宫，會(huì)發(fā)生什么非迹？
- 由其它機(jī)器寫入的數(shù)據(jù)
- 如何知道數(shù)據(jù)已經(jīng)改變了？
- 如何保持?jǐn)?shù)據(jù)的一致性纯趋？
- 有沒有預(yù)仍魇蕖？（不太理解）
如果我們進(jìn)行緩存结闸，這些風(fēng)險(xiǎn)將會(huì)使得事情不一致
使用緩存去減輕網(wǎng)絡(luò)負(fù)載
- 其他客戶端可以在推送時(shí)看到更新
- 如何使舊數(shù)據(jù)的緩存失效唇兑？
故障
1 服務(wù)器故障
- 數(shù)據(jù)在內(nèi)存里，不在硬盤里桦锄。（丟失）
- 那么...如果客戶端做了什么
- seek() ; /* SERVER CRASH */; read()
- If server maintains file position, this will fail. Ditto for open(), read()
2 丟失信息：要是我們失去了對(duì)delete("foo")的確認(rèn)
- 與此同時(shí)，另一個(gè)客戶創(chuàng)建了一個(gè)名為foo的新文件蔫耽？
3 客戶機(jī)宕機(jī)
- 客戶端緩存也許會(huì)丟失數(shù)據(jù)
Client Caching in NFS v2
- 緩存干凈和臟的文件數(shù)據(jù)和文件屬性
- 客戶端緩存中的文件屬性在60秒后過期（文件數(shù)據(jù)不會(huì)過期）
- 文件數(shù)據(jù)將根據(jù)文件屬性中的修改時(shí)間進(jìn)行檢查（可能是緩存的副本）
- 在一臺(tái)機(jī)器上所做的更改最多可能需要60秒才能在另一臺(tái)機(jī)器上反映出來
每當(dāng)客戶打開一個(gè)以前被關(guān)閉但（部分）被緩存的文件结耀，客戶必須馬上使緩存的數(shù)據(jù)重新有效。這是通過檢查文件最后被修改的時(shí)間并使包含過時(shí)數(shù)據(jù)的緩存無效來實(shí)現(xiàn)的匙铡。
- 臟數(shù)據(jù)在客戶端機(jī)器上被緩沖图甜，直到文件關(guān)閉或長(zhǎng)達(dá)30秒
- 如果在此之前機(jī)器崩潰，則更改將丟失
Implication of NFS v2 Client Caching
- 優(yōu)點(diǎn)：如果打開/讀取/寫入/關(guān)閉可以在本地完成鳖眼，則不會(huì)有網(wǎng)絡(luò)流量黑毅。
- 但… 數(shù)據(jù)一致性保證很差
- 對(duì)于某些分布式應(yīng)用程序來說簡(jiǎn)直是不可接受的
- 生產(chǎn)力應(yīng)用程序往往容忍這種松散的一致性
- 通常，客戶端不會(huì)在本地磁盤上緩存數(shù)據(jù)
NFS’s Failure Handling ——Stateless Server
- 文件有狀態(tài)钦讳，但是...
- 服務(wù)器導(dǎo)出文件而不創(chuàng)建額外的狀態(tài)
- 沒有“誰打開這個(gè)文件”的列表（打開文件上的每個(gè)操作的權(quán)限檢查？笫荨）
- 宕機(jī)后枕面，沒有"掛起的交易"
- 崩潰恢復(fù)很“快”
- 重啟，讓客戶機(jī)們指出發(fā)生了什么
- 狀態(tài)藏在其他地方
- Separate MOUNT protocol
- Separate NLM locking protocol in NFSv4（Network Lock Manager）
- Stateless protocol: requests specify exact state. read()
->read( [position]). no seek on server.
NFS’s Failure Handling
- Operations are idempotent 操作是冪等的
- 我們?nèi)绾未_保這一點(diǎn)缚去？ 文件/目錄上的唯一ID潮秘。 它不是刪除（“foo”），它是刪除（1337f00f）易结，其中該ID不會(huì)被重用枕荞。
- 并非完美 比如mkdir
- 直寫緩存：當(dāng)文件關(guān)閉時(shí)，所有修改的塊都發(fā)送到服務(wù)器搞动。 close（）不會(huì)返回躏精，直到字節(jié)安全地存儲(chǔ)。
- Close failures?
- 重試直到事情到達(dá)服務(wù)器
- 返回失敗給client
- 大多數(shù)客戶端應(yīng)用程序無法處理close（）調(diào)用的失敗鹦肿。
- 通常的選擇：掛了很長(zhǎng)時(shí)間試圖聯(lián)系服務(wù)器
NFS總結(jié)
- NFS provides transparent, remote file access
- Simple, portable, really popular
(it’s gotten a little more complex over time, but...) - Weak consistency semantics
- Requires hefty server resources to scale (write-through, server queried for lots of operations)
AFS
NFS缺陷
- 可能無法處理大規(guī)模
- 對(duì)網(wǎng)絡(luò)延遲非常敏感
我們?nèi)绾胃倪M(jìn)這矗烛？
- 更積極的緩存（除了在內(nèi)存中的AFS緩存在磁盤上）
- 預(yù)取（在open的時(shí)候狮惜，AFS從服務(wù)器獲取整個(gè)文件高诺，使得后來的本地和快速操作）
- 記住：對(duì)于傳統(tǒng)的硬盤碾篡，大的順序讀取比小的隨機(jī)寫入要快得多虱而。所以更容易支持（客戶端a：讀取整個(gè)文件;客戶端B：讀取整個(gè)文件），而不是讓它們交替（alternate）开泽，特別是如果客戶最終要讀整個(gè)文件的話牡拇。
Client Caching in AFS
- Callbacks！客戶向服務(wù)器注冊(cè)他們有文件副本;
- 服務(wù)器告訴他們：“無效穆律！”如果文件改變
- 這交易狀態(tài)改善一致性
- 如果服務(wù)器崩潰怎么辦惠呼？ 失去所有的回叫狀態(tài)！
- 重建來自客戶端的回調(diào)信息：去問問大家“哪些文件被緩存了峦耘？
- 如果客戶機(jī)崩潰怎么辦剔蹋？
- 必須重新驗(yàn)證它使用的任何緩存內(nèi)容，因?yàn)樗赡芤呀?jīng)錯(cuò)過了回調(diào)
AFS v2 RPC Procedures
AFS特有的
- Fetch：返回文件或目錄的狀態(tài)和可選的數(shù)據(jù)辅髓，并對(duì)其進(jìn)行回調(diào)
- RemoveCallBack：指定客戶端從本地計(jì)算機(jī)刷新的文件
- BreakCallBack：從服務(wù)器到客戶端泣崩，撤銷（revoke）文件或目錄的回調(diào)
- 如果回調(diào)被撤銷，客戶應(yīng)該做什么洛口？
- Store：存儲(chǔ)文件的狀態(tài)和可選的數(shù)據(jù)
其他的和NFS類似
File Access Consistency
- 在UNIX本地文件系統(tǒng)中矫付，并發(fā)文件讀寫具有“順序”一致性語義
- 從用戶級(jí)應(yīng)用程序讀取/寫入的每個(gè)文件都是一個(gè)原子操作
- 內(nèi)核鎖定文件vnode
- 每個(gè)文件寫入都立即對(duì)所有文件讀取器可見
- 從用戶級(jí)應(yīng)用程序讀取/寫入的每個(gè)文件都是一個(gè)原子操作
- NFS和AFS都不提供這種并發(fā)控制
- NFS:有時(shí)在30秒內(nèi)
- AFS:會(huì)話語義的一致性
AFS V2 的會(huì)話語義
- 什么意思：
- 文件寫入對(duì)于立即在同一個(gè)框中進(jìn)行處理是可見的，但對(duì)于其他機(jī)器上的進(jìn)程不可見第焰，直到文件關(guān)閉
- 當(dāng)文件關(guān)閉時(shí)买优，更改對(duì)新的打開可見，但對(duì)“舊”打開不可見
- 所有其他文件操作立即可見
- 實(shí)現(xiàn)：
臟數(shù)據(jù)在客戶端機(jī)器上被緩沖，直到文件關(guān)閉杀赢，然后被刷新回服務(wù)器烘跺，這導(dǎo)致服務(wù)器向其他客戶端發(fā)送“中斷回調(diào)”
AFS寫入策略
- 寫回緩存
- NFS的對(duì)面“每一個(gè)寫都是神圣的”
- 將塊存儲(chǔ)回服務(wù)器
- 緩存溢出時(shí)
- 在上次用戶關(guān)閉（）
- ..或不（如果客戶端機(jī)器崩潰）
- Is writeback crazy?
Write conflicts “assumed rare”
Who wants to see a half-written file?
AFS總結(jié)
- 比NFS更低的服務(wù)器負(fù)載
- 更多的文件緩存在客戶端上
- 回調(diào)：如果文件是只讀的，則服務(wù)器不忙（通常情況下）
- 但也許會(huì)慢一些：從本地磁盤訪問比從另一臺(tái)機(jī)器通過局域網(wǎng)的內(nèi)存慢得多
- 對(duì)彼此而言：
- 中央服務(wù)器是瓶頸：所有的讀寫操作至少一次;
- 是單點(diǎn)故障
- 使他們快速葵陵，健壯和可靠的服務(wù)器成本高昂液荸。
命名空間建設(shè)與組織
- 每一個(gè)客戶端連接
- Server: export /root/fs1/
- Client: mount server:/root/fs1 /fs1
- AFS： global name space
- 命名空間被組織成卷
- 全球目錄 /afs
- /afs/cs.wisc.edu/vol1/…; /afs/cs.stanford.edu/vol1/…
- 每個(gè)文件都被識(shí)別為fid = <vol_id，vnode＃脱篙，唯一標(biāo)識(shí)符>
- 所有AFS服務(wù)器都保留“卷位置數(shù)據(jù)庫”的副本娇钱，這是一個(gè)vol_id→server_ip映射表
- 命名空間被組織成卷
Vol_id標(biāo)識(shí)存儲(chǔ)在單個(gè)服務(wù)器上的大量文件
Vnode＃提供并索引到服務(wù)器上的一個(gè)數(shù)組; 數(shù)組條目包含有關(guān)如何訪問文件的信息
對(duì)位置透明度的影響
NFS:沒有透明性
- 如果一個(gè)目錄從一臺(tái)服務(wù)器移動(dòng)到另一臺(tái)，客戶端必須重新掛載
AFS:透明性 - 如果卷從一臺(tái)服務(wù)器移動(dòng)到另一臺(tái)服務(wù)器绊困，則只需要更新服務(wù)器上的卷位置數(shù)據(jù)庫
Naming in NFS
image.png
這里請(qǐng)注意文搂，沒有命名透明度，因?yàn)閮蓚€(gè)客戶端都具有存儲(chǔ)在不同層次命名空間中的文件（eg.mbox）秤朗。
image.png
用戶認(rèn)證和訪問控制
- 用戶X登錄到工作站A煤蹭，想要訪問服務(wù)器B上的文件
- A怎么告訴B誰是X？
- B應(yīng)該相信A取视？
- 在NFS V2中進(jìn)行的選擇
- 所有服務(wù)器和所有客戶端工作站共享相同的<uid硝皂，gid>名稱空間->B將X的<uid，gid>發(fā)送給A
- 問題：任何客戶端工作站上的root訪問都可能導(dǎo)致創(chuàng)建任意<uid作谭，gid>的用戶
- 服務(wù)器無條件相信客戶端工作站
- 問題：如果任何客戶端工作站被破壞稽物，服務(wù)器上的數(shù)據(jù)保護(hù)將會(huì)丟失。
- <uid折欠，gid>以明文形式通過線路發(fā)送->請(qǐng)求數(shù)據(jù)包可以很容易偽造
- 所有服務(wù)器和所有客戶端工作站共享相同的<uid硝皂，gid>名稱空間->B將X的<uid，gid>發(fā)送給A
用戶認(rèn)證（續(xù)）
- 如何修改這些問題再NFS V2
Hack 1: root remapping -> strange behavior
Hack 2: UID remapping -> no user mobility
Real Solution: use a centralized
Authentication/Authorization/Access-control (AAA) system
A Better AAA System: Kerberos
- 共享機(jī)密
- 用戶向KDC證明他是誰; KDC在客戶端和文件服務(wù)器之間生成共享密鑰
image.png
Kclient [S]表示使用客戶端的私鑰對(duì)S進(jìn)行加密
Automounting
image.png
image.png
