On 8/5/2014 3:30 AM, Alex wrote: > Hi all, > > Please help me to make a decision here. I am trying to determine whether > Openafs is the right choice for us and it is not clear for me if > modifying client's firewall is mandatory or not. The situation is like > this: > > -all Openafs servers are behind the same NAT firewall. Firewall rules > can be changed.
How many OpenAFS servers and how many public IP addresses on the NAT? Can you provide static mappings for the servers? OpenAFS services are required to be visible on explicit port numbers file: 7000/udp protection: 7002/udp volume location: 7003/udp volume mgmt 7005/udp at the very least the file and volume location services must be visible to clients. If there are more than one instance of each AFS service and the NAT only supports one public IP address, then you will have a problem because only one instance of each service can be accessed by clients. There will be other issues regarding volume management and there are likely to be delays when clients attempt to access data if the service's private addresses are registered for the file servers with the location service. It is possible to run OpenAFS services from behind a NAT. The your-file-system.com cell has many db and file service instances behind NATs with static public/private address mappings. All of the service instances were originally OpenAFS but are now YFS. The YFS tool chain does a much better job of support volume management across NAT boundaries. > -client computers are behind another NAT firewall. Firewall rules cannot > be changed. Clients by default use port 7001/udp to communicate with db and file servers. In AFS, the caching coherency model is built upon a push messaging model. File servers provide the client's cache manager some data with a lease expiration time and promises to notify the cache manager if the data is going to change before the lease expires. However, the file server is not particular about the port number the client uses. If the port is mapped from 7001/udp to 56039/udp that is fine provided the NAT maintains the port mapping while traffic continues to flow periodically. The IETF recommends sending udp keep alive packets at least every 30 seconds to keep NAT port mappings open but not all NAT devices do so. Some NAT devices explicitly do not do so for "security" reasons. In particular, they might cap the number of inbound UDP packets received in response. These devices are broken and will fail to work with any number of other udp based streaming media protocols. The cache managers will probe known file servers every ten minutes when the file system is idle. Configuring the NAT to maintain the port mappings for up to 15 minutes is recommended. The cache managers (in particular the Windows CMs) work very hard to ensure that lost connections due to NATs do not prevent access to data or corrupt the cache. Windows applications (unlike UNIX) almost always maintain file locks whose leases must be extended every five minutes. The Windows CM is more likely to notice and be forced to recover from a temporary connectivity loss. As Stephan indicated, an inability for the file server to notify cache managers of changes has a larger impact on clients attempting to change files for which active leases (callback promises) have been issued. The clients make the change must wait for the callback delivery attempt to timeout before the file server can complete the request. The file server thread assigned to that RPC will be blocked and idle until the timeout completes. If there are many threads in such as state, the file server will be unable to accept new RPCs until the backlog clears. It is also worth noting that the OpenAFS file servers have to perform extra work when there are many clients accessing the file server from the same IP address and different port numbers. The file server has a harder time determining whether a client has moved port numbers or is in fact a unique client. Whether OpenAFS works for you is going to be somewhat dependent upon the workload and the specific behavior of the NAT devices involved. > -some clients are on Windows, some on Linux.
smime.p7s
Description: S/MIME Cryptographic Signature
