FileWall - Research - Rutgers University

Download Report

Transcript FileWall - Research - Rutgers University

Implementing Network File System
Policies with FileWall
Stephen Smaldone, Aniruddha Bohra, and Liviu Iftode
{smaldone,bohra,iftode}@cs.rutgers.edu
Department of Computer Science
Rutgers University
File System Evolution
• Single user (desktop) FS to shared infrastructures
–
–
–
–
–
Centrally managed
24/7
Shared access
High maintenance requirements
Interoperability: standards
• Unprecedented growth
– Size of storage infrastructures
• Today - Tera
• Tomorrow - Peta, Exa, ???
• User density: user consolidation
• Data sources
– File sharing, document management, email, IM, VOIP
2
File System Management Problems
• Monitoring:
– Minimal built-in support for statistical monitoring (e.g., nfsstat)
– Administrators required to gather data from many sources
• Access control:
– Access control maintained per file at the discretion of the owner
– Administrators must enforce access control to shared resources despite
ignorant non-malicious users
• Maintenance:
– Patching newly exposed bugs in the file system
– Debugging, testing, and deployment of new code
– Administrator error impact much larger
• Evolution:
– New functionality cannot be introduced without code extensions
3
File System Management Problems
• Monitoring:
– Minimal built-in support for statistical monitoring (e.g., nfsstat)
– Administrators required to gather data from many sources
• Access control:
– Access control maintained per file at the discretion of the owner
– Administrators must enforce access control to shared resources despite
ignorant non-malicious users
• Maintenance:
– Patching newly exposed bugs in the file system
– Debugging, testing, and deployment of new code
– Administrator error impact much larger
• Evolution:
– New functionality cannot be introduced without code extensions
Management tools have not evolved to match administrator needs
4
Policy vs. Data Access
• Data Access:
–
–
–
–
Evolves independently
Performance enhancement
Protocol optimization
Acceptable to most
• Policy:
– Evolves due to functionality requirements
– Difficult to specify and reason about
– Administration requirements differ between installations and
must be implemented independent of user requirements
5
Policy vs. Data Access
• Data Access:
–
–
–
–
Evolves independently
Performance enhancement
Protocol optimization
Acceptable to most
• Policy:
– Evolves due to functionality requirements
– Difficult to specify and reason about
– Administration requirements differ between installations and
must be implemented independent of user requirements
File systems implement a minimal set of management
functionality
6
Monitoring Policy : Example
7
Monitoring Policy : Example
8
Monitoring Policy : Example
9
Monitoring Policy : Example
10
Monitoring Policy : Example
11
Our Goal
We propose a novel approach to implement
network file system policies externally, without
modifying the client or server, by transforming
messages flowing between them.
12
Network File Systems
Transport
FS_OP
RPC
NFS_REQ()
NFS_REQ
read()
NFS_OP()
Transport
RPC
NFS_RSP
13
Observations
• All file system access are performed through messages
– Message transformations can be used to enforce policies
– File system state can be constructed using information contained
in messages
• All state relevant to file system accesses is available in
messages
– Policies can use file attributes contained in messages in policy
evaluation
– Statistical information can also be used
14
FileWall Model
Transport
Transport
FS_OP
RPC
RPC
NFS_READ()
NFS_REQ
FS_OP
NFS_REQ
NFS_READ()
Transport
Transport
RPC
RPC
NFS_RSP
NFS_RSP
15
Monitoring Policy: Revisited
16
Monitoring Policy: Revisited
17
Monitoring Policy: Revisited
18
Monitoring Policy: Revisited
FileWall enables the separation of concerns of network aware
policy enforcement and the file systems
19
Outline
•
•
•
•
•
•
Motivation
Design
Implementation
Evaluation
Related Work
Conclusions
20
Design Guidelines
• Specification
– Ease of specify and reason about policies
• Protocol semantics
– Message reordering and aggregation
– Retransmissions and lost bytes
• Performance
– In critical path  cannot have large delays
• Fault tolerance and availability
– Cannot maintain “hard-state”
– Limited access to stable storage
21
FileWall Design Overview
• Specification
– Policies specified using macro-like language
– Message transformation
• State Maintenance (Access Context)
–
–
–
–
Local policy state and global environment
Read-only state specified by the administrator
State generated and stored by policies during execution
Time, available disk space, CPU load, etc.
• Execution
– Policy scheduling and execution
– Logging and debugging
22
FileWall Architecture
M’
M
FS Client
FileWall Engine
R’
File Server
R
Access
Context
Policies
FileWall
23
FileWall Policies
• Transform messages (requests and replies)
– REQ handler
– RSP handler
• Use:
– File attributes contained in messages
– Access context
24
FileWall Policy Example
• Policy: “Show files accessed today”
• For each client-visible file:
– Access Time = TODAY
• Transform directory listing messages
– READDIR and READDIRPLUS
25
FileWall Policy Example
FileWall Engine
Access
Context
Policies
FileWall
26
FileWall Policy Example
READDIR
FileWall Engine
Access
Context
Policies
FileWall
27
FileWall Policy Example
READDIR
FileWall Engine
Access
Context
Policies
FileWall
28
FileWall Policy Example
READDIR
FileWall Engine
Access
Context
Policies
FileWall
29
FileWall Policy Example
READDIR
READDIRPLUS
FileWall Engine
Access
Context
Policies
FileWall
30
FileWall Policy Example
READDIRPLUS
FileWall Engine
Access
Context
Policies
FileWall
31
FileWall Policy Example
READDIRPLUS
FileWall Engine
Access
Context
Policies
FileWall
32
FileWall Policy Example
READDIRPLUS
FileWall Engine
Access
Context
Policies
FileWall
33
FileWall Policy Example
READDIR
READDIRPLUS
FileWall Engine
Access
Context
Policies
FileWall
34
Policy Chains
• Defined by administrator
– Lists policies in order of request processing
• Scheduler
– Determines policy execution schedule
• Fowarder
– Forwards messages between policies
– Determines next policy in chain as a message flows along the
policy chain
– Discards messages
• Default Policies
– RECV Policy (start), SEND Policy (end)
35
Policy Chains
36
Outline
•
•
•
•
•
•
Motivation
Design
Implementation
Evaluation
Related Work
Conclusions
37
Implementation
• FileWall
– Click Modular Router
– NFS over UDP
• Unmodified Linux NFS client and server
• Policies
–
–
–
–
Statistics monitoring policy
Temporal Access Control
File Handle Security
Client Transparent Failover
38
Outline
•
•
•
•
•
•
Motivation
Design
Implementation
Evaluation
Related Work
Conclusions
39
Fstress Performance (2.4 GHz Server)
40
Interposition Overheads
41
Varying Network Delay
42
Fstress Performance (Overloaded Server)
43
Scalability
44
Related Work
• Distributed and Extensible File Systems:
– FiST [Zadok ’00]
– Interposed Request Routing [Anderson ’02]
– SFS [Mazieres ’99]
• Extensible Policies:
–
–
–
–
–
SPIN [Sirer ’95]
VINO [Seltzer ’96]
Exokernel [Engler ’95]
Infokernel [Arpaci-Dusseau ’03]
LGI [Minsky ’00], [He ’05]
• Composable Network Processing:
–
–
–
–
Packet filters [Bos ’04]
x-kernel [Hutchinson ’91]
Scout [Montz ’94]
Click [Kohler ’00]
45
Future Work
• High-Level Policy language
– Constraints
– Debugging and logging
46
Future Work
• High-Level Policy language
– Constraints
– Debugging and logging
• User study
– Real deployment
– Behavior models
47
Future Work
• High-Level Policy language
– Constraints
– Debugging and logging
• User study
– Real deployment
– Behavior models
• Data transformations
– Censorship
– Protocol translations
• NFS -> CIFS
• Recipe-based file system (CASPER)
• IP -> RDMA
– Video encoding
– Content adaptation
48
Conclusions
• FileWall
– Architecture, Design, and Implementation
•
•
•
•
•
Policy enforcement through message transformation
Implementation of four real-world policies
Policy implementations are portable
Interposition overheads are low
Given sufficient resources, relative to an NFS server,
FileWall imposes minimal overheads
49
Acknowlegements
• Fabio Picconi (Universite de Paris 6)
• Cristian Ungureanu (NEC Labs)
50
Thank You
Questions?