Update on our SAN – looks like os X.3.9 on G4’s are no go.

[Bart Harrison]

[chrispy] “Have you tried the ATTO Celerity series ?”

It’s my first choice. The Celerity writes faster to stripe sets than the Astera (ala dual-link RGB HD). My concern is that Atto is using parts of the Apple API meaning it might work fine today and then stop working all-together with a point upgrade of the OS.

Bart

– – – – – – – – – – – – –
Bart Harrison
MPA – The HD Suite

America’s VAR
TurnKey Editing Systems, Storage Area Networks
HD Consulting, Production & Post, Exhibition & Distribution
http://www.hdsuite.com
954-894-1221

[Christopher Tay]

Bart,

I think I may have asked you this before but anyhow…in your SAN installs, do you usually use both FC ports on the HBAs ? Does it speed up the throughput if you use both FC ports ?

And if the two FC ports goes to into a switch and the switch in turns goes into both the ADTX RAID controllers (4 FC cables in total, 2 per controllers), how you do manage the LUNs so that it does not duplicate or get confused ? This is the part that I’m still trying to figure out.

-chrispy

[Bart Harrison]

[Francois Stark] “When sharing over SMB to PC’s we can only access the user;desktop etc. We can not see any non-boot drives. So we’d have to get os X server software.”

I generally use Thursby DAVE if there’s a need to share other OS X drives/folders via SMB (as opposed to SAMBA). Whenever posible, though, I prefer using NFS.

Bart

– – – – – – – – – – – – –
Bart Harrison
MPA – The HD Suite

America’s VAR
TurnKey Editing Systems, Storage Area Networks
HD Consulting, Production & Post, Exhibition & Distribution
http://www.hdsuite.com
954-894-1221

[Bart Harrison]

[chrispy] “how you do manage the LUNs so that it does not duplicate or get confused ?”

What I like to do is deploy two FC switches. If that’s not in the cards then you need to set up appropriate LUN masking. The unique WWPN of each port on every HBA can be seen and masked by the ADTX GUI utility. It takes some organizational planning but works fine once you get it all setup.

Bart

– – – – – – – – – – – – –
Bart Harrison
MPA – The HD Suite

America’s VAR
TurnKey Editing Systems, Storage Area Networks
HD Consulting, Production & Post, Exhibition & Distribution
http://www.hdsuite.com
954-894-1221

[Francois Stark]

Hi Bart and chrispy

I’m just gonna ramble on about my experience because I find that typing it up makes you think deeper about the problem…

Well, last night I thought I had messed around enough with the Raid 0 test LU’s. I deleted all the LU’s and restarted the ADTX array. Created two new 5 drive arrays, one on each controller. Created 6 LU’s on each array – all raid 5.

While the first LU’s were being initialised ( the others were”waiting to be initialised”) I could access all the LU’s from the G5’s! I tried creating stripe sets in the disk utils, but that did not work properly, so I went home to let the raid 5 LU’s finish initialising.

This morning I found the LU’s had finished initialising. I started up in 10.4.1 Tiger on the G5, but Tiger seems to exhibit similar problems on the G5 as os X.3.9 did on the G4: All the LU’s are visible in the system profiler, but only one port on the ADTX array’s LU’s are visible in the disk utility. So I went back to os X.3.8 on the G5 and could see all the LU’s in the disk util.

Bad news for Tiger migration… The Astera cards might work but the apple fibre card is really not working well yet in Tiger.

Then it took me about 30 minutes just to figure out which LU’s must be striped together, because most of them are the same size! I had to format them as seperate drives, copy stuff over and see where the data goes using the fibre switch software – one by one. Eventually I figured out how to identify which array and which LU is which disk is in the disk utility.

Then I striped the corresponding LU’s from each array together and started doing some tests (journalling off – yesterday I had it on). Yesterday I could copy stuff from one stripe array to another at 55MB/s (raid 0 stripes), today it ran at 50MB/s (raid 5 stripes). OK, I guess. Raid 5 makes it about 10% slower.

Setting up the LU mapping in the ADTX: I set it up so that
1) every port has one LU 0 – so the G4’s can see all the LU’s
2) every real LU only shows up on one ADTX port
3) every real LU only shows up on the port of it’s own controller
4) I have 12 LU’s it total, 6 on each array
The LU mapping looks like this:
Port 1: 0 – 1 – 2 – – – – – – –
Port 2: – 0 – 1 – 2 – – – – – –
Port 3: – – – – – – 0 – 1 – 2 –
Port 4: – – – – – – – 0 – 1 – 2
(PS Only people who have a ADTX array will recognize this LU mapping)

Then I set up FCP to capture to the one Sanmp disk (stripe raid 50), SD PAL uncompressed using the Decklink Xtreme on a G5. Checking on the fibre switch performance graphs, I could see the G5 is splitting the data over both fibre links, 10MByte/s each, and the ADTX is also getting the data on two ports at 10Mbyte/s each, one on each controller. I captured about 55 minutes in 10 minute clips without problems.

Then I started some playback tests. Yesterday I could play back 8 streams uncompressed on the raid 0 stripe, today I could to 6. I continued capturing, while playing back 4 streams on the next G5 machine.

Then something went wrong. I don’t know what. The capturing started dropping frames – abort capture. At random times, between 1 min and 5 minutes from start of capture. The SanMP capture disk, mounted as read-only on the second G5, started acting strangely. It would show the folders on the drive, without icons. As I click on the folder name, it would vanish. Freaky. I restarted the read-only machine and it restored disk access to the sanMP disk.

I restarted the capture machine three times. Continued dropping frames on capture to the SAN disk. Trashed preferences. I even changed capture drive to the boot drive and it continued dropping frames as long as I had the sanMP disk mounted. Only after another reboot and by not mounting the sanMP disk at all, would the system capture to the boot drive wihtout dropping frames.

I’m sitting here on the read-only machine and it can not even play back four streams SD. It starts off fine, but after about 2 minutes it drops frames. Badly. And the capturer machine does not even have the SanMP disks mounted. No other machine is mounted. Yesterda it also dropped frames on capture, but I though that could be related to the journalling that I left on when creating the stripe sets. It seems I was wrong.

On the playback machine I playing four of the captured SD files (apple unc422 8 bit) in quicktime at the same time – looped. Plays at 80MByte/s. Then after a random time it drops fames and the datarate momentary drops, whereafter it shoots up to 130MByte/s as quicktime tries to catch up. It stays in this state indefinitely, reading from the array at 130MByte/s while continuing to drop frames in all 4 windows. When I pause one window, the others start playing normally after about 10 seconds – datarate drope to 60MB/s. Bottom line, it can not handle 4 streams continously, even though it has much higher datarate capability.

I checked the drive lights on the front of the ADTX to look for “sticky” lights indicating a drive with many retries slowing the ADTX down. Nothing strange – all lights blinking similarly.

I wonder if this has to do with the SanMP automatic sync. I set all my drives to ON for read and write, with a 360 second volume sync interval.

So I’m stuck again…

Regards
Francois

[Francois Stark]

I just realised the playback problems happen with even three streams. While I was typing, the fourth stream was paused. It was playing three streams reading 60MB/s for a random time, when it would drop frames, data rate drops and then shoots up to 120MB/s where it stays for about three minutes. Then they just continue like before.

It’s like something gets stuck on the array, and causes this dropped frame on playback. It could be the same thing that is causing the problem for capturing from next door. But then, why did the first 55 minutes capture OK this morning?

Regards
Francois

[Francois Stark]

I think I found the last remaing problem with the SAN:

I tested how long it takes between the dropped frames and it was exactly 6 minutes – the time I set up for SanMP’s volume sync.

So I disabled SANMP’s volume automatic sync, and the problem went away. Since then, I’ve captured long pieces without any problems.

This morning’s first 55 minutes must have captured fine because the SAN was empty. When it’s empty, the volume sync must be fast enough not to cause dropped frames.

So now we will start using the SAN properly – I hope.

Regards
Francois