Gateway for NFS

Gateway for NFS

“I wish I had to configure only one machine as NFS share” Many of us who are new to “Services for Unix” asks this question. Gateway for NFS comes as a rescue to them. It is a part of Services for Unix 3.5. However, Gateway for NFS was not recommended for high performance and high stability scenarios. This feature has been removed starting windows 2003 R2.

Gateway for NFS translates SMB traffic from Windows clients in to NFS traffic and then passes it on to the UNIX servers and vice versa. The process of translating SMB/NFS/SMB protocol for every data packet adds a huge overhead to the processor and eats up valuable system resources. After a certain limit, the processing costs becomes too high and results in performance degradation. Complexity of the translation process make is more unstable. Following picture describe the communication flow of Gateway for NFS.

Also the issue which you may be facing could be due to the below factor:

· “Gateway for NFS” service needs services to be started in a certain sequence and a failure of some dependent service not starting up can trigger a failure.

· Using “Gateway for NFS” means that ONE machine that is acting as Gateway is going to do all the translation from SMB to NFS to SMB.

· This puts a lot of processor overhead on the Gateway machine and also means there is a “single point of failure”. If there is any issue with the Gateway for NFS server then all the clients fetching data from it will not be able to access the share.

Drawbacks of Gateway for NFS:

1. Gateway for NFS leads to single point of failure situation. If there is any issue with the Gateway for NFS server then all the clients who fetch data from it, will not be able to access the share.

2. Gateway for NFS is not recommended for high performance and high stability scenarios.

3. Gateway for NFS is to be used under scenarios where downtimes are acceptable to certain extent.

4. Gateway for NFS is not available in Windows 2003 R2 release and it will be not available in future releases as well (like in Vista and Longhorn). So, for future usability probably you would like to fix this issue by using Client for NFS in your environment.

5. Also Gateway for NFS is known for performance related issues when no. of users increases beyond 1000. It uses both SMB and NFS communication so from troubleshooting perspective there can be multiple issues appearing.

6. Gateway for NFS service needs services to be started in a certain sequence and a failure of some dependent service not starting up can trigger a failure.

7. Using “Gateway for NFS” means that ONE machine that is acting as Gateway is going to do all the translation from SMB à NFS à SMB. This puts a lot of processor overhead on the Gateway machine and also means there is a “single point of failure”. 

 

 

Alternate Solution:

1. Client for NFS is one obvious alternative to Gateway. It requires the “Client for NFS” component to be installed in every Windows Client. But once installed and setup, it will work seamlessly. It can deliver higher speed, performance and stability compared to Gateway.

2. Another workaround for your environment is to host a SAMBA service on the UNIX box. This will allow Windows clients to natively access the file shares on UNIX box. You need to plan authentication and authorization means while using SAMBA.

 

 

Advantages of Client for NFS:

1. Client for NFS is much robust and reliable than Gateway for NFS. The only drawback is that it needs to be installed on all the client machines but it is still better than using Gateway for NFS.

2. Once installed and setup, it will work seamlessly. It can deliver higher speed, performance and stability compared to Gateway.

3. Even if one client is unable to access the share, it will not stop the working of rest of the clients.