User Functions
Don't have an account yet? Sign up as a New User
Who's Online
Guest Users: 7
|
| View previous topic :: View next topic |
| Author |
Message |
SS
partially protected
Joined: 25 Feb 2010
Posts: 6
|
 Posted: Tue Mar 09, 2010 12:20 pm Post subject: |
 |
|
[quote="staze"] | SS wrote: | | daver wrote: |
This is simple. Create two RAID1's during initial setup. When dragging LUNs into the Metadata pool, simply drag both of these RAID1's into it and you're good to go. Obviously, you'll have to do away with the two spares in the top chassis for this. You'll still have the protection of the spares located in the JBOD as they can span enclosures. This definitely strays from Apple's recommended practices but then again, this particular configuration isn't exactly posted on their website either. If you'd like help scripting the LUN creation when you decide to try this, get in touch with me and I'll whip something up for you. |
Since I haven't tried this, or seen anything about it, I'm curious. Isn't this basically creating a RAID 10 array for the MD, or does Xsan just seen that if there are two RAID1's, it sticks the journal on one, and the MD on the other?
Has there been any testing with using SAS drives for MD rather than the standard SATA drives? Of course, you'd want a J class to be 13 SATA's, and 3 SAS drives to allow a spare for each type of LUN (Data and MD, respectively). But, 15k SAS drives seem like they'd be faster than the dual RAID1 idea, as well as the fact that putting MD on a 1TB RAID1 seems kinda, overkill. =P |
Hi staze,
It's my understanding by default, the journal gets placed on the first LUN in the metadata storage pool. The metadata gets striped across both.
As for testing with a SAS MDL, we don't do it in-house here [at Promise]. However, there may be a few people on this forum that may have tried it.....abstractrude  ? |
|
| Back to top |
|
 |
abstractrude
Xsan Master
Joined: 13 Mar 2008
Posts: 865
|
| Posted: Tue Mar 09, 2010 12:48 pm Post subject: |
|
|
| there is a guy snfsguy on here, i wonder what he thinks. I have used a metadata SAS solution in a lab but not in production. It seemed faster under multiple requests but didnt get to spend enough time to actually benchmark it. |
|
| Back to top |
|
|
ravi
Xsan Master
Joined: 06 Mar 2008
Posts: 149
|
| Posted: Wed Mar 10, 2010 11:49 am Post subject: |
|
|
| SS wrote: |
I haven't experimented with metadata LUNs set to write-back cache, so I can't speak to this; I'd imagine it would make less of an impact if this was the case. However - you are correct - the load from the metadata IO will be spread across two controllers (assuming that you have the LUN affinities set correctly) and two LUNs, thereby increasing performance.
|
Hi Steve
This paragraph picked my curiosity. As far as the metadata LUNs set to write-back, if you look at StorNext tuning guidelines all the way from their draft document at ADIC to various definitive versions at Quantum, it is consistent and they state (see the RAID Cache Configuration section):
"For example, write-back caching is absolutely essential for metadata stripe groups to achieve high metadata operations throughput.
However, there are a few drawbacks to consider as well. For example, read-ahead caching improves sequential read performance but might reduce random performance. Write-back caching is critical for small write performance but may limit peak large I/O throughput."
The second part of your paragraph is not clear to me. We are talking about random I/O pattern of small transactions, so seek time vs transfer time comes into play. Probably you mean concurrency of metadata operations here to the two stripe groups.
The best approach (from my point of view) would be to use one separate RAID1 stripe group for journal data and one or (more) RAID1 stripe group(s) for the metadata. In Xsan you will have to forgo to GUI of course, but it is easy in StorNext.
And yes, SAS drives make a big difference because of their IOPS performance, especially in demanding environments.
[Edited to complete my thoughts.] |
|
| Back to top |
|
|
rickw
JBOD
Joined: 13 Mar 2010
Posts: 1
|
| Posted: Sat Mar 13, 2010 6:43 pm Post subject: |
|
|
Hi All,
After reading through the complete thread there is one thing that is missing, that needs to be considered. For small files the Standard configs in the GUI, including dual RAID 1 raids in the MD (it certainly helps to some extent) really don't help that much (apart from raising the buffer cache for the MDCs).
Tweaking the Promise,or in fact any other raid box does help, but the StorNext troubleshooting guide and the terminal now need to become your friend.
I am currently writing an article to back up my demo at Advanced Camp and Macworld on Splitting the MetaData and Journal Luns. This technique is recommend by StoreNext ( in the fine print) to get the best performance. You should also consider the tuning of the Xsan/Storenext cache parameters. This makes a huge difference in access speed to the MD LUNS, as noted above.
For those a bit gun shy on the terminal there are a a couple of simple steps to get a separate MD and Journal LUN set and you can still monitor the whole thing in the GUI as well after the fact. I am just finalising the test on a couple of configs before releasing the paper, to verify that what I have been investigating is correct. Hopefully I will upload it to Xsanity in the next week or so.
On another note, as Ravi correctly identified, SAS drives (at 15,000 RPM) will help considerably, however if you throw enough RAM into your MDC's most of the MD will live in cache.
Another point, due to the difference in speed of the SAS and SATA drives, they vibrate at different frequencies. This can be destructive to the drives in the enclosure over time, therfore best practice states that drives of different spin type should never be put in the same enclosure.
Cheers,
Rick |
|
| Back to top |
|
|
ravi
Xsan Master
Joined: 06 Mar 2008
Posts: 149
|
| Posted: Sun Mar 14, 2010 4:02 am Post subject: |
|
|
| rickw wrote: | Hi All,
I am currently writing an article to back up my demo at Advanced Camp and Macworld on Splitting the MetaData and Journal Luns. This technique is recommend by StoreNext ( in the fine print) to get the best performance. You should also consider the tuning of the Xsan/Storenext cache parameters. This makes a huge difference in access speed to the MD LUNS, as noted above.
For those a bit gun shy on the terminal there are a a couple of simple steps to get a separate MD and Journal LUN set and you can still monitor the whole thing in the GUI as well after the fact. I am just finalising the test on a couple of configs before releasing the paper, to verify that what I have been investigating is correct. Hopefully I will upload it to Xsanity in the next week or so.
|
Hi Rick, Looking forward to that article. It appears that you and I are largely in agreement, though personally I wouldn't recommend any of these if one is gun shy on the Terminal  |
|
| Back to top |
|
|
staze
Been around the blocks
Joined: 15 Oct 2007
Posts: 25
|
| Posted: Mon Mar 15, 2010 2:08 am Post subject: |
|
|
| rickw wrote: |
On another note, as Ravi correctly identified, SAS drives (at 15,000 RPM) will help considerably, however if you throw enough RAM into your MDC's most of the MD will live in cache.
|
Rick, so one thing I've noticed is, in the GUI, you cannot set the buffer above 1536MB even if your MDCs have 8GB of ram. Have you set it higher than this by editing the volumename.cfg and had this work? I'd love to up the buffer cache size, but last time I asked about it, the only responses I got were "where did you get this info?"
If SAS drives vibration is an issue, then the obvious next step would be some SSDs for MD. Anyone tried that? Then I don't think you'd need to worry about splitting the journal and MD since obviously, IOPS is no longer an issue with SSDs. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
Xsanity Forum
Forum Search
Forum Help
Log in to check messages
Xsanity Articles
