[Macpartners] Filesystem virtualization for AFP

[Mateja Miljacki]

Hi,

This involves a long thread that compares AFP, SMB, NFS v3,  
kerberized NFS v3, NFS v4, AFS and XSan. The thing to remember is  
that there is no single solution to all the problems in file-system  
space, but there are a lot of options and almost all of them are  
available on the Mac.

Responses are bellow...

>> On Sep 28, 2006, at 2:53 PM, Douglas Alan wrote:
>>
>>     Does anyone know if there is a filesystem virtualization  
>> solution for
>>
>>     Apple's AFP filesharing protocol?
>>
>> What problem are you trying to solve? That would help us when  
>> trying to
>> suggest solutions.

This is the right approach. What are you trying to solve? Are you  
creating centralized storage or are you trying to glue together  
disparate storage?
A centralized storage option, like XSan, can provide growable storage  
(with no down time) and can present this storage via AFP, SMB, NFS,....
to a cross-platform set of clients, and thereby solve the main  
problem mentioned bellow: growing and moving the storage around  
without the user noticing or needing to re-configure.

Another option to look into, for AFP, is AFP re-sharing NFS. You  
could create your entire structure the same way you already do within  
NFS mounts and then reshare any NFS mount using Mac OS X Server. You  
could do this on multiple servers for fault-tolerance as well.

>
>    Flexible, expandable, shared storage for a growing research lab.

This usually means that the lab's research data is growing  
exponentially, not the complexity of its organization. The answer is  
a storage area network like XSan which can hold petabytes of data,  
grow dynamically (just throw more disks at it) and provide high-speed  
access and bandwidth control to the storage.

> 	I also have some questions about these imminent fileshares, and  
> how to
> 	best organize them.  I'm a Unix expert, but I'm a Mac expert only to
> 	the extent that OS X has Unix hidden underneath its skin, so I'm
> 	looking for some guidance on how to best handle things in this
> 	not-quite-traditional-Unix world.

Just jump into it. Mac OS X 10.4 is unix-based, and Leopard actually  
has the UNIX SUSv3 cert, so it IS UNIX.
Most of the UNIX commands are the same but Apple adds commands and  
management tools, both GUI and command-line equivalents for all.
Disk Utility is diskutil in Terminal and can accomplish everything  
that the GUI version can. It then just becomes your preference: GUI  
or Terminal.

>
> 	One of the biggest worries I have with shared filesystems is the  
> issue
> 	of having inflexible volumes.  What always eventually happens is that
> 	a volume fills up, or a server gets overloaded, and then you need to
> 	add more disks or servers, and relocate directories from one  
> volume to
> 	another, or maybe even to a new server.  If the paths to directories
> 	change during this relocation, it typically breaks scripts and other
> 	software that has already been configured to look for things in
> 	specific places.  The users also have to be notified and retrained to
> 	look for the stuff in the new location.  And even if you end up not
> 	having to relocate directories, you often have to resort to putting
> 	new directories on a new volume, while old directories remain on an
> 	old volume, and then people have to look in multiple places to find
> 	things.  It's much better if all of this unpleasantness can be  
> avoided.

Again, if you do this on the SAN level, you will not come to an  
issue. The "network" file system also stays independent of the  
underlying disk file-system.
With XSan you can have a single volume that spans multiple storage  
pools, consisting of multiple, growable storage LUNs. You can even  
combine storage with different properties (super fast or super fault- 
tolerant) into a single volume via affinities.
This single volume can then be shared to any number of clients via  
multiple network file protocols (AFP, SMB, NFS).

Leopard will feature a lot of improvements in performance of many of  
these and will include kerberized NFS v3 support.

>
> 	One solution to this sort of problem has lately been referred to as
> 	"filesystem virtualization".  AFS invented the idea long, long ago by
> 	presenting all the AFS files in the entire world as one huge AFS
> 	volume.  With AFS sometimes the sysadmin has to move stuff around
> 	between disks or servers, and then change some entries in some config
> 	files somewhere, but all of this happens under the covers.  To the
> 	end-user the rearrangement of the data is all invisible.

AFS is available on Mac OS X. It was also invented before centralized  
storage based on FibreChannel became mainstream and affordable (Apple  
had a lot to do with that, as you may see from the price lists).

>
> 	I hear that Microsoft has something similar to AFS called DFS that is
> 	layered on top of CIFS, but I know next to nothing about either CIFS
> 	or DFS.  (I believe that DFS usually spans a department or  
> enterprise,
> 	rather than the entire world, but the idea is similar.) I also hear
> 	that there are now NFS filesystem virtualization servers that
> 	implement something similar for NFS too, but I haven't ever used such
> 	a server.

Yes this is what DFS tries to accomplish, the MS way. NFS does  
basically the same, but is available everywhere.
Currently, there is no support for DFS in the Mac OS X Tiger other  
than manually mounting specific shares within the DFS structure.

> 	Long before DFS or such NFS virtualization servers existed......
<snip a lot>
>
> 	Also, I'm unclear as to how authentication works with AFP.  With NFS
> 	(i.e., unkerborized and prior to v4), there isn't any real
> 	authentication, so everything works smoothly, if a bit insecurely.

AFP is authenticated and a user session. Ie, AFP volumes can not be  
mounted if no-one is logged on.

> 	With the more robust security that AFP presumably offers (does it?),

Yes. NFS is not authenticated at all. NFS v3 with kerberos will be.
Also you can re-share NFS via AFP and thereby implement an additional  
user level of security on top of NFS.

> 	do we have to worry about kerberos tickets expiring and the like?

AFP can be authenticated/authorized via Kerberos as well. The  
Kerberos credentials can come from MIT Kerberos or Active Directory  
or Open Directory.

> 	Will people have to manually mount all volumes via the Finder after
> 	they log in?
> Or can they somehow specify a list of volumes to be
> 	automatically mounted?

Yes you can set up a volume to be mounted automatically. On the  
simple side, just add the volume to the Login Items of the user (in  
System Preferences).
If the authentication system is not Kerberos, you can add the  
password to the user's keychain (where it is encrypted and secure)  
and the user will never have to type it.

>   Will people have to log out and log back in
> 	periodically to remain authenticated?

AFP runs with users credentials, so the user has to be logged on in  
order to maintain the connection. AFP does have auto re-connect, so  
if you are disconnected or drop your network entirely, it will  
silently re-connect upon need.

> Or will a dialog box pop-up
> 	periodically reprompting them for their password?

This will only happen if the user tries to mount the AFP volume with  
an outdated password. If the user is logging in to the Login Window  
with kerberos credentials, all password policy will come from KDC. If  
the KDC says the user will need to change a password, it will display  
the dialog for it.

>   If so, how does one
> 	typically handle the issue of long-running programs that need to
> 	proceed unattended, or jobs that run from cron?

They do not use AFP. NFS is a better option for this in most cases,  
because any process on the host mounting the share will have access  
to the share.

>
> 	One final concern of mine is how do fileserver-hosted home  
> directories
> 	typically work?  We won't want fileserver-hosted homedirs right away,
> 	but we probably also want to plan ahead for them.

Leopard will bring autofs to Mac OS X and make it on par with any  
other Linux based mounting system. The story will get significantly  
simpler then. Currently Mac OS X uses automountd for automounting and  
home directory creation. There are LOTS of manuals and precisely the  
information you need at:

http://www.apple.com/server/documentation/



> How and where do
> 	they usually get mounted?

/Network/Servers/
This can be either AFP, NFS or SMB. Each has slightly different  
behavior.

> Do they just appear under "/Users"?

No. The user's home directory will point to a /Network/Servers/ 
whateveryourserveris/share


> Or do
> 	they appear somewhere else?  What about if you need to access someone
> 	else's fileserver-hosted homedir?

as long as it is automounted you could navigate to that share and the  
user's home folder. You will only have access to what the file  
permissions say you have access to. By default this is the "Public"  
and "Sites" folder within the user's home directory.

> How do you get to it and where does
> 	that appear in the filesystem?

Click on the Home!

  or /Network/Servers/

Mateja.

-- 
Mateja Miljacki, ACSA, CCDP, CCNP, MCSE
mateja at apple.com
Systems Engineer
http://www.apple.com/education/technicalresources/
-- 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/macpartners/attachments/20060929/35392234/attachment.htm