Recent Comments

  • Reply to: MDC locking up. XSAN 3.1 OSX 10.9.4, MDC Mac Mini   16 hours 18 min ago

    Leaving Xsan Admin open shouldn't be a problem, but I would recommend closing it when not in use, just to make sure the data you see in the GUI is updated every time you use it.

    cvlog and nssdbg.out do not get wiped on a reboot, so you should be able to find some valuable data there, to help troubleshoot this issue.

    /Library/Logs/Xsan/data//log/cvlog*
    /Library/Logs/Xsan/debug/nssdbg.out

    Failed drives in our Promise arrays should not cause problems for your MDCs, unless a whole LUN gets damaged, but then you're in deep trouble.

    What kind of fibre channel switches are you using? If it's Qlogic, have you double checked that the target and initiator ports are configured correctly?

    Also make sure that DNS is looking right on your MDCs, and that the date/time of both MDCs is in sync.

    Are you able to ssh into your MDCs after a lockup?

  • Reply to: Xsan 4   21 hours 43 min ago

    Xsan 4 clients are not manageable by Xsan Admin and so you will always get "offline" errors.

    Upgrading the MDCs to Yosemite is the only officially supported method to get the clients in the SAN.

    Other administrators have noted that there is nothing in the underlying protocol that blocks the clients and MDCs from talking to each other, and they have had success manually configuring clients in a manner similar to how you would configure an Xsan client to be part of a SAN with Quantum MDCs. Obviously going that route takes on a measure of risk as you are in a not-officially-supported configuration; Apple does not perform QA validation on that configuration. If you feel comfortable with that risk envelope, you could choose to follow their example.

    Also, you would be taking on all of the other responsibilities of management. If you change the fsnameservers list, you will need to update the clients manually. If you want to stop a volume, you will need to unmount it manually from the client.

  • Reply to: Rorke Data Storage Galaxy HDX 4   5 days 21 hours ago

    IIRC this unit is based on infortrend hardware. At least it was when I set up a HDX Aurora Galaxy HD3 many moons ago. There were Stanley Cup riots going on. No fun. Oh anyway, ya, the hardware.... It used for metadata for a StorNext setup. So no Mac clients interacted with it directly. When I did try to get multi path working with an actually infortrend branded box I was not successful. Using ATTO HBA and drivers. It works as a LUN, but I couldn't get multi path working. The setup was fun too. CLI or web or the little display on the raid. Choose your pain.

  • Reply to: Notes on Xsan4   1 week 1 day ago

    There are a lot of notes on this site about your issue. Metadata controllers should/must be newer than clients. Xsan4 makes that more strict. You can "hack" this by manually configuring clients and pointing to the FSM. 10.9 is your best bet until your ready to move your whole environment to Yosemite.

    http://support.apple.com/kb/HT200135?viewlocale=en_US&locale=en_US

  • Reply to: Xsan 4   1 week 1 day ago

    We are running Xsan 3.1 on a couple of Mac minis as dual MDC's, and have new Mac Pro computer that has Yosemite on it, and we want to add it to the San but can't seem to add it. (We continually get the old "unreachable or offline" warning. We have no plans to upgrade our MDC's to Yosemite for now, or is the only way to add a Yosemite client?

  • Reply to: Notes on Xsan4   1 week 2 days ago

    We are running Xsan 3.1 on a couple of Mac minis as dual MDC's, and have new Mac Pro computer that has Yosemite on it, and we want to add it to the San but can't seem to add it. (We continually get the old "unreachable or offline" warning. We have no plans to upgrade our MDC's to Yosemite for now, or is the only way to add a Yosemite client?

  • Reply to: Notes on Xsan4   1 week 2 days ago

    Yes, thanks for keeping the flame alive, Bill!

  • Reply to: Notes on Xsan4   1 week 2 days ago

    Thanks wrstuden

  • Reply to: OS X 10.10 Yosemite and Xsan   1 week 3 days ago

    As others have noted, Xsan 4's administration model is notably different from the model in all previous versions of Xsan. Here are some notes I have on the changes.

    We have coined a new term, "Activation." "Upgrade" and "Migration" are two ways of taking the base operating system and configuration from a previous OS to Yosemite. "Promotion" is the act of updating Server.app to Server 4.0. We coined a corresponding term, "Activation," to describe taking an Xsan 3 or 2 configuration and moving it into Xsan 4. SAN Activation happens after Upgrade or Migration and also after Server Promotion. Activation happens first on the previous Xsan Primary MDC, and then happens on the other MDCs.

    Xsan 4 no longer directly manages clients. We ran into too many issues where SAN operations would fail because one client was off-line. To address this, Xsan 4 uses ldap to store the SAN configuration. Now instead of having Xsan Admin update (push) the configuration on all machines, we have Server.app store a changed configuration in ldap and we inform all the clients that they need to re-parse (pull) the configuration.

    We now run Open Directory on all the MDCs and they act as an OD cluster to replicate this information. Clients do not need to bind to these severs. If you previously had Xsan managing Users & Groups, Xsan will use that OD for its storage. If you have an external source for your Users and Groups, say AD, just use that for Users&Groups and don't worry about this OD cluster.

    There are two direct consequences of this change.

    First, Xsan 4 does not support Xsan 3 or earlier systems in the SAN. We do not lock them out of the fsm's, and you can perform a zero-down-time upgrade. The rub is that the older clients do not understand the messages we now send out when the configuration changes, nor do they understand the new message instructing clients to unmount a volume (as it is about to be stopped). In this respect they are akin to Linux or Windows clients in the SAN. If you want to stop a volume, these clients will not automatically unmount it. If you destroy a volume, these cients will not correctly forget it.

    Second, we use Transport Level Security (TLS) in ldap when querying the configuration. As such, we need certificates to anchor the TSL trust. Certificates need DNS host names. So Xsan 4 requires DNS be configured on the Metadata Network. We expect many sites already had it, but we now will require it.

    Unfortunately the error message you get today is unclear about this issue. So be forewarned.

    A thrid issue is that all of the MDCs need to be in the same OD cloud. If you had a SAN before where Xsan was NOT managing users & groups but you had OD running on some of the MDCs, you need to ensure the Xsan 3 primary controller is in that OD cluster as the primary (ODM) before activating the SAN. Otherwise Xsan will see that OD is not running on the former primary, create it, and then you won't be able to activate MDCs which are in a different OD cloud; we require all SAN MDCs have the same OD master.

  • Reply to: Xsan 4   1 week 6 days ago
  • Reply to: Xsan 4   1 week 6 days ago

    Xsan 4 Migration Guide by Apple Inc.
    https://itun.es/ca/7qTk3.l

  • Reply to: Xsan 4   1 week 6 days ago

    I put up some screenshots of a clean Xsan 4 install on my blog macvfx.wordpress.com, link below.

    https://t.co/redirect?url=http%3A%2F%2Ft.co%2FDT0I6VLKX2&t=1&sig=d65689d...

  • Reply to: OS X 10.10 Yosemite and Xsan   1 week 6 days ago

    Hopefully your MDC's won't restart after two weeks. I'm waiting at least a month before I upgrade to Yosemite.

  • Reply to: MDC locking up. XSAN 3.1 OSX 10.9.4, MDC Mac Mini   2 weeks 22 hours ago

    Volume is always mounted on both MDC's. I'll try to gather info from logs. It usually requires a hard boot, so logs get wiped. What is your recommendation on leaving XSAN Admin open all of the time on one of the MDC's?
    This is looking like a storage problem. We have been working with Promise, but are still getting frequent failed drives. Whenever a drive fails or is replaced and initiates a rebuild, the lockup problem happens.

  • Reply to: MDC locking up. XSAN 3.1 OSX 10.9.4, MDC Mac Mini   2 weeks 2 days ago

    Have you made sure all Xsan volumes hosted by these two MDCs are mounted on the MDCs? This is required for things to work properly, especially failover.

    What do you see in the cvlog and nssdbg.out log at the time of the freeze/failover? Please don't copy/paste the whole log here. Only find the relevant messages around the time frame of the freeze/failover.