If you are journaling for DR, then putting the receivers in a different ASP
that has a it own Raid Sets gives you the following ability.

If you loose the system ASP, you can restore the System ASP without loosing
the data in say ASP2 where your receivers are. Apply last nights backups
and then apply your journaled data.
If you loose say ASP2 and if it only contains journal receivers then that
is all you have lost.
If say ASP2 shares a RAID Set with the System ASP and you looses that RAID
set then you have lost BOTH ASPs

We used to put journal receivers in a different ASP for performance
reasons. This moved the addition disk I/O of writing the journal entries to
different disk. I have had IBM tell me with today's systems with much
faster drivers, large cache controllers etc, many systems don't 'need' to
put them in a separate ASP. Again that 2nd ASP needs to be on its own RAID
set to isolate that I/O. Putting ASP2 on the same RAID set as the ASP1
really doesn't isolate the IO

On Thu, Jan 9, 2014 at 2:41 PM, Bakutis, Becky <
BBakutis@xxxxxxxxxxxxxxxxxxxx> wrote:

We currently have a separate ASP for journal receivers on a busy system.
We will soon be upgrading the hardware. Someone mentioned, for DR and
performance reasons, to make sure no raid set crosses over into another ASP
when configuring the new hardware. Is this a valid concern and worth the

Becky Bakutis

Republic Services
W: 480.627.2760

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].