5/30/2018 Distributed File Systems Security: Anonymous access • all files available to all users 14B. Remote Data Access: Security – no authentication required – may be limited to read-only access 14C. Remote Data: Robustness – examples: anonymous FTP, HTTP 14D. Remote Data Access: Performance • advantages 14E. Remote Data Access: Consistency – simple implementation 14F. Remote Data Access: Scalability • disadvantages – incapable of providing information privacy – write access often managed by other means Distributed File Systems 1 Distributed File Systems 2 Peer-to-Peer Security Server Authenticated Sessions • client-side authentication/authorization • client agent authenticates to each server – all users are known to all systems – session authorization based on those credentials – all systems are trusted to enforce access control – example: CIFS, authenticated HTTPS sessions – example: basic NFS • advantages • advantages – simple implementation – simple implementation • limitations • disadvantages – assumes all client systems can be trusted – may not work in heterogeneous OS environment – assumes all users are known to all systems – universal user registry is not scalable • UID mapping between heterogeneous OSs – statefull sessions complicate server fail-over • efficiency /scalability of universal user registries Distributed File Systems 3 Distributed File Systems 4 Domain Authentication Service example: KERBEROS • establishes secure client/server sessions • independent authentication of client & server • based on digital signatures – each authenticates with authentication service – every agent has a secret (symmetric) key – keys are known only to agent, and KERBEROS – each knows/trusts only the authentication service • request to KERBEROS encrypted w/client key • authentication service issues signed “tickets” – KERBEROS can decrypt it, authenticating requester – assuring each of the others’ identity and rights • KERBEROS response is two-part work ticket – may be revocable or have a limited life-time – part 1: encrypted with client's key • a symmetric session key • may establish secure two-way session • part 2 (to be forward, by client, to server) – privacy – nobody else can snoop on conversation – part 2: encrypted with server's key • client ID, ticket duration, – integrity – nobody can generate fake messages • symmetric session key Distributed File Systems 5 Distributed File Systems 6 1
5/30/2018 KERBEROS Work Tickets Distributed Authorization Authentication Client Server • Authentication service returns credentials Service request – which server checks against Access Control List client ID generate session key server ID – advantage: auth service doesn’t know about ACLs expiration time C-ticket S-ticket • Authentication service returns Capabilities session key session key server ID client ID – which server can verify (by signature) expiration time expiration time encrypt w/client key encrypt w/server key – advantage: servers do not know about clients decrypt w/client key decrypt w/server key • Both approaches are commonly used – credentials: if subsequent authorization required subsequent communication encrypted w/symmetric session keys – capabilities: if access can be granted all-at-once – either may have an expiration time Distributed File Systems 7 Distributed File Systems 8 Robustness: Embracing Failure Reliability and Availability • Failures are inevitable • Reliability … probability of not losing data – more components have more failures – disk/server failures to not result in data loss • RAID (mirroring, parity, erasure coding) – complex systems have more modes of failure • copies on multiple servers – we cannot build perfect components or systems – automatic recovery (of redundancy) after failure • We must build robust systems • Availability … fraction of time service available – additional capacity to survive failures – disk/server failures do not impact data availability – automatic failure detection • backup servers with automatic fail-over – dynamically adapt to the new reality – automatic recovery (back up to date) after rejoin – continue service, despite component failures Distributed File Systems 9 Distributed File Systems 10 Problems and Solutions Availability: Fail-Over • Network Errors – support client retries • data must be mirrored to secondary server – RFS protocol uses idempotent requests • failure of primary server must be detected – RFS protocol supports all-or-none transactions • client must be failed-over to secondary • Client Failures – support server-side recovery – automatic back-out of uncommitted transactions • session state must be reestablished – automatic expiration of timed out lock leases – client authentication/credentials • Server Failures – support server fail-over – session parameters (e.g. working directory, offset) – replicated (parallel or back-up) servers • in-progress operations must be retransmitted – stateless RFS protocols – client must expect timeouts, retransmit requests – automatic client-server rebinding – client responsible for writes until server ACKs Distributed File Systems 11 Distributed File Systems 12 2
5/30/2018 Reliability: Data Mirroring Availability: Failure Detect/Rebind • client driven recovery secondary – client detects server failure (connection error) – client reconnects to (successor) server Back-side Mirroring client primary – client reestablishes session secondary • transparent failure recovery – system detects server failure (health monitoring) secondary – successor assumes primary’s IP address Front-side Mirroring – state reestablishment client primary • successor recovers last primary state check-point • stateless protocol secondary Distributed File Systems 13 Distributed File Systems 14 Availability: Stateless Protocols Availability: Idempotent Operations • a statefull protocol (e.g. TCP) • can be repeated many times with same effect – operations occur within a context – read block 100 of file X – each operation depends on previous operations – write block 100 of file X with contents Y – delete file X version 3 – successor server must remember session state – non-idempotent operations • a stateless protocol (e.g. HTTP) • read next block of current file – client supplies necessary context w/each request • append contents Y to end of file X • if client gets no response, resend request – each operation is complete and unambiguous – if server gets multiple requests, no harm done – successor server has no memory of past events – works for server failure, lost request, lost response • stateless protocols make fail-over easy • but no ACK does not mean operation did not happen Distributed File Systems 15 Distributed File Systems 16 (nearly) Stateless Protocols Peter Deutsch Warned Us! • client can maintain the session state • POSIX semantics require coherent state – e.g. file handles and current offsets – this complicates server fail-over • write operations can be made idempotent • there are numerous shared resources – e.g. associate a client XID with each write – must synchronize all updates to all of them • idempotence doesn’t solve multi-writer races • location transparency – competing writers must serialize their updates – remote objects are much more expensive to use – clients cannot be trusted to maintain lock state • distributed is not really the same as local • we need a state-full Distributed Lock Manager – performance may be proportional to locality – for whom failure recovery is extremely complex – adds more frequent and new modes of failure Distributed File Systems 17 Distributed File Systems 18 3
Recommend
More recommend
