A few random Xsan tips and tricks

• Make absolutely certainly DNS works and is configured properly. Absolutely.
  
  
• Be really careful doing anything that might interrupt the Xsan volumes. Especially if those volumes are shares; that can get ugly, maybe requiring a forced power down. Best policy is to dismount the volumes from all Xsan clients, stop the Xsan volumes, and _then_ do whatever you need.
  
  
• Anything at all; some XSR (Xserve RAID) operations cause _both_ controllers to restart (ex: firmware upgrade) - including the other one, that's part of the Xsan, that you thought wouldn't be affected.
  
  
• When copying files with extended attributes (ex: ACLs or resource forks) to an Xsan volume, the extended attributes are automagically copied to an "AppleDouble Header" file that's named the same as the original file, except with "._" prepended. (Transparent to the user and/or application; slick.) Interestingly, the mod date on the AppleDouble Header file is the date of the copy. Also, if you want to sanity-check the copy, good luck - most tools (ex: diff and cmp) simply ignore the AppleDouble Header file and if you attempt to compare the extended attributes directly, you'll see that their order is not guaranteed, so you must compare attribute-by-attribute.
  
  
• How to decommission a Controller? I don't know, however if you demote it to a Client first, at least the logs won't fill up with messages about how the Controller can't be found. I say "first" because I believe it's necessary to do it while the machine is still live on the Xsan.
  
  
• It's critical for all Controllers to agree - and can be ugly if you perform operations on a Controller that's lost sync with the rest - so sanity-check by adding the following (single line) to the periodic/daily (presuming you read the results, maybe by email) on each:

  if [ -d /Library/Filesystems/Xsan ] ; then echo ""; echo "Xsan status:"; cvadmin -e select | grep -F '>'; fi

  
  
• Do run multiple MDCs; even if you never have an unplanned event, you _will_ have a planned event (ex: software upgrade) that multiple MDCs will render trivial.
  
  
• Check all the docs (PDFs, "ReadMe"s, KB articles, AFP548, Xsanity...) carefully - and consult with someone else before performing anything dramatic. Like, just for the sake of example, "cvfsck -j" and "cvfsck -wv".
  
  
• Sometimes it's the simple stuff that gets you: For example, check _both_ Ethernet interfaces; the one used by the Xsan MDCs and the one used to talk to the rest of the world; just because you can ping out, doesn't mean the Xsan Ethernet cable didn't come loose.
  
  
• Sharing an Xsan volume out? Watch out for the 16TB limit; I believe this applies to SMB as well as AFP; not sure about NFS.
  
  
• Do use hot spares; the performance you lose is rarely missed - though your weekend might be, without them.
  
  
• Do configure the Xsan email warnings; it should be quite infrequent and you will want to know, even if its "just" switching Controllers and none of the users noticed.
  
  
• Same goes for battery backup modules; it's "penny wise, pound foolish" to skip them.
  
  
• No, you can't shrink a volume and re-allocate a LUN; only grow. (BTW: It's possible to grow an XSR LUN - though there's no Apple volume format yet capable of surviving this; you must back up before and restore after.)
  
  
• Yes; you can configure multiple LUNs on a single XSR side. Not optimal, though a reasonable tradeoff for some situations.
  
  
• Just because it's so big, makes it difficult to back up - and, critically, that much more important to back up.
  
  
• Make any modifications using Xsan Admin logged into to the Xsan via the Xsan Ethernet interface of the Primary (active) Controller. Maybe not strictly necessary, but safer.
  
  
• Be aware of the power config; if one XSR is on a UPS that's loaded, and it runs out of power before the MDCs shut down, it'll be ugly. (BTW: Take advantage of the redundant power supplies on the XSRs; plug each into separate UPS units.)
  
  
• Make notes as you go; you never know what you might need later, in a rather frantic time.