Horst Birthelmer <[EMAIL PROTECTED]> wrote:
On Mar 4, 2006, at 11:46 AM, Christopher D. Clausen wrote:
Horst Birthelmer <[EMAIL PROTECTED]> 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
