[OpenAFS] What filesystem?

[Christopher D. Clausen]

Horst Birthelmer <horst@riback.net> wrote:
> On Mar 4, 2006, at 11:46 AM, Christopher D. Clausen wrote:
>> Horst Birthelmer <horst@riback.net> wrote:
>>> On Mar 3, 2006, at 11:30 PM, Volker Lendecke wrote:
>>>> If you have one or two servers, AFS probably is not worth
>>>> the hassle. But AFS really pays off when you run out of
>>>> fingers to count your servers. I see the initial cost in
>>>> particular when you're new to AFS as relatively high, but in
>>>> the long run with a lot of servers around the world, you
>>>> will start to love it.
>>>>
>>> I just wanted to add, that if you reach that size Volker was talking
>>> about, you also ran out of options.
>>> AFS is the only file system being able to help you in that case.
>>
>> Microsoft's Dfs should scale as well.  Of course, it essentially
>> only works on Windows, but if you are mostly a Windows shop, it may
>> be the best way to go.  I am a particular fan of the multi-master
>> read-write replication possibilities it offers, something that is
>> not currently possible with OpenAFS.  And MS Dfs is suposed to get
>> even better in Windows 2003 R2.
>
> My experience with DFS is very limited (I actually didn't have more
> than a few contacts with it), but is there any possibility for an
> administrator to move any of the shared data transparently to a new
> location without all the clients to notice?
> Is there any possibility to manage the 'shares' at all?

You can transparently move a share by setting up a new share on the new 
fileserver, create a replica on it, wait for replication to finish, and 
delete the old share.  More work is involved than a simple vos move, but 
I would strongly prefer read-write realtime replicas to the simplicity 
of vos move and would likely have everything setup with a least one 
mirror anyway and then there wouldn't be as much of a need to move 
things.  The server could just go down while rebooting for patches, 
hardware upgrades, etc.

Depends on what you mean by manage.  There is a nice Dfs management GUI 
MMC plugin.  If you want to manage everything from the command line or 
from non-Windows you will likely be in some pain.  And you are correct 
that its not quite as nice as AFS b/c one is not always an admin on all 
the local servers and thus may not be able to just create shares on 
whatever random server is in the Dfs name space.  Domain Admins need to 
be granted local administrator rights on each machine to create the 
shares or otherwise have them created by the local admins.

> I'm a little confused how and why that's a match for AFS. We were
> talking about a large worldwide installation with possible
> mountpoints from different cells etc.

Dfs reparse points are links to various Windows shares.  (They are 
similar to junctions within NTFS.)  Its different from AFS in that the 
servers don't need to share a common KeyFile and can utilize the same 
UNC namespace.  (Similar to allowing multiple groups to run their own 
cells, without the need to tokens and PTS entries in each seperate 
cell.)

You could argue that NFS with the proper auto-mount mappings in NIS and 
sometype of file replication could provide infrastructure similar to 
Dfs.

> I quickread some of the information from Microsoft on this topic but
> didn't find any information about any improvements of DFS beyond that
> 'name service' for windows fileservers. (well, it's over simplified,
> I know)

Actually, that is pretty much all it is.  Its a namespace for CIFS 
shares.  The replicas work with the File Replication Service (frs) and 
can operate even without a domain controller, although most places will 
want the data hosted in active directory.  The file replication can be 
more advanced than one to many replication.  Active Directory has a 
concept of "sites" and this can be utilized to save data transmission 
time over WAN links between branch offices.  Group Policy can be used to 
point different sets of machines at different servers by default, 
failing over to other sites when needed.

MS Dfs (not to confuse it with the OpenGroup's DCE DFS stuff) works 
differently from how AFS works, with a different view of where things 
should be managed.  IMHO, AFS is limited b/c different cells tie PTS 
entries to specific Kerberos credentials and one needs to seperate 
authenticate to each cell, not each server.  Dfs uses only Kerberos 
tickets to logon to each server and provides failover if one of them is 
down.  The servers can be individually managed by seperate entities as 
long as they are joined to the same AD forest.  Adding a server to a Dfs 
namespace does not imply sharing admin access to all other server admins 
like how AFS works with its shared key.  (Needing to be in the UserList 
on all DB servers to add volumes and vldb entries is a serious 
limitation and probably prevents some organizations from adopting AFS.)

Its not a solution for everyone, but its an option.  Its more integrated 
with Microsoft technologies than is usually liked in the organizations 
that use AFS, but IMHO it provides a more useful set of features, 
especially for Microsoft-only organizations.

<<CDC