[OpenAFS] more newbie questions

[Jason Edgecombe]

Jonathan Dobbie wrote:
> Thank you for the responses, we're still designing our storage system 
> and AFS still seems like the best option.  I've installed AFS on a 
> test server (G4 OSX - I figured I'd start with the craziest platform 
> we might want it on)
>
> I'm hoping that if I toss my plan out now, people can point out the 
> holes before I invest too much time in it.  The end goal is uptime 
> more than performance.
>
> Our AFS servers would probably all be running linux.  Clients are OSX, 
> windows and Linux.
>
> There would be an MSKDC that would trust the main MIT KDC.  I need to 
> talk to the Windows Admin about ntlm, but if we need to sync the 
> passwords, thats fine (password change is done via a webpage or 
> command line tools that we wrote, not passwd), if not, the MSKDC will 
> have random passwords.
>
> We only have one small chunk or data that (I think) lends itself to a 
> RO replica.  We have a network library that it automounted by all osx 
> computers.  All other data is updated enough that people wouldn't want 
> to wait for me to release  it.  Am I missing a way to set up RO 
> replicas?  I'd be nice if they would mirror changes automatically.  
> Part of what I want is to be able to have any one piece of hardware 
> die, and either route around it automatically, or bring it back up 
> remotely.
>
> Here is my current idea (I'm not hugely fond of it, so I'm really 
> hoping that someone has a better one)  There will be two FC storage 
> devices (we currently have one xraid.  If we can't get much cash, 
> it'll be another, if not, something better.)  These will be kept in 
> sync with DRBD, at least at the partition level (which seems a little 
> silly)  Heartbeat will be used so that if anything goes wrong with the 
> server or the storage, the other server will restart its AFS server 
> and start serving the downed server automatically.  (It'll certainly 
> end up more complicated than this, but that's the basic idea).
>
> Could someone please point out the holes in this plan?  Is there a 
> simpler way to do this with R/O replicas that might require me to 
> manually promote the replica to R/W, but would be less error prone?  
> Most of the data involved is home directories and departmental 
> shares.  If it can be fixed remotely in <5 minutes, it's probably good 
> enough.
>
> I keep thinking that there should be a clever way to use GFS(not 
> google, the RH one) instead or DRBD to keep the volumes in sync.  All 
> of the machines have two gigabit NICs, but it still seems like a waste 
> not to use FC.
>
> More precisely, would this be possible:
> /vicepd is on GFS on both RAID arrays (A and B)
> it's mounted on servers 1(rw) and 2(ro).
> If A dies, B serves the data and no one notices
> if 1 dies, heartbeat promotes 2 to rw and ro.
> and, if it is possible, what would users notice?
>
I've read other people's remarks that syncing /vicepx is bad, but I 
don't know for myself.

FC isn't neccessary. Just add more disks, FC or not. Add a new server 
with more disks. You simply add more volumes and mount them in any path 
you want in /afs. The AFS client automatically does failover for R/O 
volumes. It doesn't do failover for R/W volumes, though. You can also 
create a backup volume, which is a snapshot of a volume. You can have as 
many R/O replicas as you have servers.

> As a last question, completely out of left field, does anyone know if 
> AFS stores apple metadata?  I've seen some references to it doing so 
> in Apple Double files, but nothing concrete.
>
I'm not sure, but apple tends to store resource metadata for filename in 
._filename when the filesystem doesn't support resource forks natively.


Jason