Recent Comments

  • Reply to: Notes on Xsan4   2 days 19 hours 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   2 days 19 hours 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   3 days 1 hour 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   3 days 18 hours ago

    Yes, thanks for keeping the flame alive, Bill!

  • Reply to: Notes on Xsan4   3 days 21 hours ago

    Thanks wrstuden

  • Reply to: OS X 10.10 Yosemite and Xsan   4 days 22 hours 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 21 hours ago
  • Reply to: Xsan 4   1 week 21 hours ago

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

  • Reply to: Xsan 4   1 week 21 hours 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 22 hours 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   1 week 1 day 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   1 week 3 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.

  • Reply to: Finder not refreshing   2 weeks 1 day ago

    I've done some preliminary testing with 10.10 GM2 and I'm encouraged to see that the finder refresh bug appears to be resolved on an Xsan system I set up on it.

    Its still in beta, and things can definitely change in a short amount of time, and that doesn't even begin to address some larger issues of other software compatibility on 10.10, but at least that issue seems like it got some attention.

  • Reply to: About the Snow Leopard Graphics Update (Apple KB)   2 weeks 1 day ago

    Annually, many visitors flock to the Pit involving Bouquets (located in Uttarakhand state) to experience a glance involving their wonderful assorted landscape as well as find a new sight involving a lot of the unusual as well as cv writing service vulnerable kinds involving creatures. Some visitors usually are not just mother nature enthusiasts, but in addition a number of die hard trekkers as well as botanists.

    The actual Pit involving Bouquets can be home for you to creatures much like the Asiatic black keep, compacted snow leopard, dark brown keep as well as orange lambs; as well as unusual notable flowers much like the Brahma Kamal (a its heyday seed local to the Himalayas), your Violet Poppy and also the Cobra Lily. There are many kinds involving butterflies together with colors which could similarly match up your colours from the flowers.

  • Reply to: EOL Notice: AppleCare Xsan Support   2 weeks 2 days ago

    The XSan support product was XSan ONLY - a product that no one really bought. It was introduced many years ago, superseded by Applecare OS support at a cheaper price. I remember attempting to purchase XSan only support a few years ago when we first acquired the san. My apple account executive recommended very strongly to NOT buy the XSan only product. This was three years ago, and even back then, the product made no sense at all. Too limited in scope.

    We've have maintained Apple OS Support for years with excellent results.