[OpenAFS] more newbie questions
Thu, 22 Feb 2007 19:04:06 -0500
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
> 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
> 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.