Home Forums OS X Server and Client Discussion Xsan AFP crashes when resharing StorNext file systems

  • This topic is empty.
Viewing 1 post (of 1 total)
  • Author
    Posts
  • #369439
    Anonymous
    Guest

    Our setup is as follows:
    Open Directory Master, running SMB services. Open Directory Replica sharing home directories from Xserve RAID with AFP/SMB enabled. One DNS Server. Two File servers running AFP/SMB, joined to the Open Directory domain, resharing StorNext file systems. Oh yeah…. two Dell Power Edge 2850’s running RHEL3 and StorNext FSM 2.8. Obviously the Red Hat systems are our Master and Backup meta data controllers. Throw in a DAM server (on an Xserver) and a couple more Xserve’s running Episode Engine for enterprise transcoding over the LAN. We have an ADIC i2K tape library with only two drives. A gross neglect we are attempting to correct. MDC’s are configured for managed file systems. There are a total of 6 files systems, to include: hafs; usergrp (Groups – current work); repository (archiving); project (currently not in use); scratch (Video Encoding – not managed / backed up); webdb (Web Development & Trouble Ticket database). Clients are about 50+ mac’s, being mainly graphic designers (30), 13 for video encoding/producing/editing, 5 for animation and random others for office type aplications. We have about 20 pc’s running Windows 2K-XP as office systems, CG (Character Generators, teleprompter, large format scanner and laser angraver. You get the idea, we dabble in print, video, web, etc. My brow is sweating.

    Recently, we started getting AFP server crashes on our two “Apple File Servers (AFS)”. One server is mounting a SN file system for on-going work, labeled [i]groups[/i]. The second AFS mounts a SN file system labeled [i]repository[/i], for final archiving of finished products. Users were reporting the SMB service was reporting 0KB available through SMB connections from Apple clients. Okay, I’ve done the reading and realize this is due to Apple’s implementation of SMB and we are to wait until Leopard is released. Windows clients can write to these file systems no problem. The AFP service is where we are getting bitten. As user’s attempt to access data, or navigate through the directory structure of the file systems, Finder hesitates as the MDC pulls truncated media from tape to disk. Sometimes thhis works fine. It appears as demand grows, and how much the MDC is writing other media to tape, the AFP servers wig out, Finder hangs and client connections see the spinning beach ball of death. The only thing to do at this point is to power cycle the client. Normally, the second go around s fine because it appears the MDC has retrieved the file back to disk.

    I’m afraid I might have ansewered my own question, although it would be nice is someone else has seen this to confirm or deny. Is anyone sharing out Xsan (or in my case StorNext) file systems to clients using AFP and SMB? If so, do you notice any fault in AFP’s ability to do so? I was told by J.D. Mankovsky (Sr. Professioanl Services Manager @ Apple) to not use AFP because it shows signs of flakiness in there lab tests and recommended SMB sharing of XSAN / StorNext file systems over AFP. Could this be why? Groups is over 2TB & repository 3TB. Obviously we have the SMB restrictions in force of file systems over 2TB, which sucks. Damn the iPhone for delaying the release of Leopard! Would our problems be resolved by throwing more LTO-2 tape drives into our library to alleviate i/o from clients to the MDC’s & MDC to the library? Probably so huh?

    Thank you!

Viewing 1 post (of 1 total)
  • You must be logged in to reply to this topic.

Comments are closed