Thanks for your suggestions. I take it you haven't seen this
behavior before?
Originally, we configured the san with one portal machine to be
the metadata controller, one for failover, and the third as a
client. We then re-exported the san volume via NFS from all three
portals for a client:server ratio of 13:1 on the NFS side.
You should not be running other services on your Xsan MDCs (primary
or backup). Something like "OD master" or "OD slave" or DNS server
is probably OK in a pinch, but "NFS server", "AFP server", or "SMB
server" definitely is not. Every one of those CPU cycles you steal
from the "fsm" processes on the MDCs is going to negatively impact
your SAN's overall performance.
Gotcha. Thanks for the tip.
Stability far outweighs performance at this point. The fact that
every MDC and every Xsan client reboots when the system is loaded is
not in the category of "performance" for me.
Put it this way: Once I can load the system without experiencing
catastrophic failure I'll be able to *measure* performance.
This configuration seemed very unresponsive, and it would fall
over (all three portals reboot or hang) if I loaded the cluster
with enough work to get a bunch of reads and writes going from all
the compute nodes.
You didn't mention what version of Xsan you are running... Have
you contacted AppleCare about this problem?
We're using Xsan version 1.2, and working directly with Apple
engineering.
At this point, what is failing? The NFS server or the MDCs?
When the failure occurs, all three portal machines reboot. The MDC
(There's only one at this point) goes first, followed by the two
clients.
-Chris Dwan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xsan-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xsan-users/email@hidden
