Isaac: You may be under the assumption that AFS is similar to SMB or CIFS where the file system that is exported to the world is locally readable/writable to applications on the file server. This is not the case. In AFS, volumes containing directories, files, mount points and symlinks are stored in a format that is only readable to the AFS server processes. All access to that data is performed via the AFS client (or AFS cache manager.)
This model provides many of AFS' strengths: * location independence - the applications do not care where the data is located and volumes can be moved from one file server to another while it is being used. This is important for load balancing or hardware maintenance without downtime. * readonly replication - a readonly snapshot of a volume can be taken and replicated to multiple file servers to improve access to clients and provide failover. * online backup - for each read/write volume a single backup volume can be maintained that permits users to recover the file they accidentally deleted. Backup volumes are created using copy-on-write semantics so they do not take up additional space on the disk until the user begins to make changes to the read-write volume. * heterogeneous server deployments - an AFS cell can use a mixture of operating system and hardware platforms for its servers and clients. * authentication - all access goes through the file server process and is therefore authenticated in a consistent manner. Kerberos is always used. The performance benefit that you will receive by using AFS is avoidance of the VPN for access and data caching on the client. Instead of reading data from the file server each time the file is opened, the client can access it out of the local disk cache if the data version of the file has not changed. Although Microsoft has made great strides in improving CIFS performance over the WAN with SMB 2.0 as found in Vista and 2008, it requires that both parties be either Vista or 2008. Old Windows operating systems can not take advantage of the benefits. If you want to run the AFS Services on a Windows Server, I can certainly make that happen but there is a month or two of work that needs to be done to make it production quality. Given that it doesn't matter what OS the services run on because the data on disk cannot be locally accessed in any case, every organization that has asked for AFS services on Windows Server always ends up deciding to just use Linux, MacOS X, Solaris, etc. because it is cheaper in the short term to use what is already available. If on the other hand you do want to use Windows builds of the services please contact me off-list. Jeffrey Altman Isaac Perez wrote: > > Hi Jeffrey, > > Our problem is the lack of performance and reliability of CIFS/SMB across > VPN, I found openAFS and I thought that it would be worth to giving it a > chance. > As some windows applications must run in the server, moving it to linux is > not an option. Installing a virtualized linux machine in the server could be > an option. But it will add levels of complexity to the system, and I would > not lilke that. > > As some people suggested, going to payed support could help the project. But > I doubt my directors will approve budget for something doesn't works in > windows from the start. > > I tried windows NFS, but it seems that windows clients with windows server > doesn't work as well as Windows-Linux. > > Any idea of how could improve the communications with a reliable > service/protocol? > > Thanks, > Isaac _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
