Planning disk utilization for a new SAN

Loki · RAID 5 Joined: 20 Nov 2008 Posts: 19

Hello-

just trying to decide how best to use the disk space available for a new SAN. I have 3 Promise arrays- 2 controllers and 1 expansion chassis. We decided to go this way so we could add at least one additional expansion chassis down the road without burdening any controller too much.

This is what I will probably end up doing:

My quandary: I'm a frugal guy, and the idea of disks sitting there not doing anything bugs me. Not the global spares, but the ones that don't really need to be spares (white on my little drawing), and can't be incorporated into the data LUNs.

I've seen examples where a couple of smaller LUNs are set up for 'scratch disks', but I'm not sure that will be of much use in the work flow of the 2 video editors that will be using the system.

If there was a way to put the Journal data somewhere else, I could have 7 disk LUNs, but that doesn't strike me as feasible.

Is this just something I accept and move on?

JesusAli · Xsan Master Joined: 25 Jul 2008 Posts: 151

What if your Data1 LUN became "Loose Files" or "Final Cut Server Proxy/Scratch Generation Storage" and you took the Dedicated Spares to make Five 7 disk LUNs for your main volume? ...although I may have read that the Main Volume should be comprised of an even number of LUNs...

From what I've read, you can keep adding J Units to E Units and not worry about over taxing the E Unit. You only get speed gains with the first 2 J Units, however. But adding 3-8 J's doesn't negatively impact performance in any way.

Do you have any old Apple RAIDs lying around or being under utilized? It was recommended to me that I should put my MetaData LUN on one side of an Apple RAID in order to get more speed out of my Promise E+J. The Controller should be dedicated, only have 3 drives (Mirrored MD and Hot Spare), and there should be no other disks or services running on that RAID Controller.

Otherwise, you could RAID 0 those 4 white disks and have Final Cut Server use that for generating Proxies on.

Loki · RAID 5 Joined: 20 Nov 2008 Posts: 19

JesusAli-
I like your idea of using an old Xserve Raid for metadata. I am a little bit uncomfortable about using old, out of warranty hardware, but I would have plenty of spares from the 4 I have now that will soon be decommissioned. They are all 2Gbps interfaces, though. I don't think this would be a huge detriment, since the actual volume of data going to the Journal LUN must be tiny compared to the Data LUNs.

comments?

Here's another idea I came up with:

Here I have an odd number of Data LUNs, which you say is sub-optimal, but also I'm not sure if having a LUN that spans a controller and an expansion chassis is a good idea, either.

comments?

JesusAli · Xsan Master Joined: 25 Jul 2008 Posts: 151

Thanks Loki, but the tips for using an Apple RAID side for MD comes from Xsanity Co-Founder Matthew Geller (MattG). I haven't tried it. But MattG also said the 2GB/s difference did not negatively impact performance.

In your Alternative diagram, put the 2nd Controller Chassis on Top and it's not too different from your first diagram.

I should have been more specific, I believe you want an even number of LUNs in any 1 Pool. You don't need to worry about overall LUNs, just the amount in 1 particular Pool.

As for this new design, I would always dedicate 1 spare to the MD LUN, just because that's your WHOLE disk. So that only leaves you with 1 spare for two or 3 LUNs per Chassis. If you didn't care about your DATA07 LUN being backed up, i.e. if it was just for renders or proxy generation, I suppose it wouldn't need redundency, but I think it is still a good idea to have two spares per chassis to ensure up time while a new drive is ordered and delivered.

abstractrude · Xsan Master Joined: 13 Mar 2008 Posts: 561

I use Xserve RAID's for my metadata LUNs. They are the perfect storage if you dont mind that they are not redundant. and well old

Loki · RAID 5 Joined: 20 Nov 2008 Posts: 19

It would be nice if there was a 1U 3 drive storage chassis available just for metadata. But I suppose once you added redundant controllers, power supplies and a fibre interface it would cost almost as much as the 16 drive units.

MattG · Xsan Master Joined: 15 Apr 2005 Posts: 422

To be clear, using Xserve RAIDs for anything new right now is not a good idea. The drives are all but impossible to find. It was awhile back that I made that recommendation.

brianwells · Knows DNS is the answer Joined: 22 Oct 2008 Posts: 31

I ran into a similar problem with two VTrak subsystems and one expansion box. Our solution was to configure two Xsan volumes as illustrated below. The larger of the two is used by a few video editors and others in post production. The smaller one is used as shared storage for a few Xserves that provide access over AFP.

We were able to divide up the data between the two depending on if the work needed the high speed of a Fibre Channel connection or would work just as well with the slower Gigabit AFP connection. In doing so, we were also able to convert some of our Power Mac G5s to Intel iMacs instead of Mac Pros.

– Brian Wells

matx · Xsan Master Joined: 15 Apr 2005 Posts: 263

It's 2009 (almost 2010!) and using Xserve RAIDs for metadata in a Promise-based Xsan is crazy and not recommended. It's dangerous. This is not a game. We're building production based systems that are supposed to work with the least amount of worry and stress for the sysadmins and the people who depend on that data being there.

abstractrude · Xsan Master Joined: 13 Mar 2008 Posts: 561

yeah I should have been more clear. You can use them and they may work great, but I do not use them in production systems. Only second tier storage. I have been using promise with SAS drives for metadata.

http://store.apple.com/us_smb_78313/product/TV271VC/A?fnode=MTY1NDA0Nw&mco=MTQyNTAwMjA
-T