× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Do check with your HA vendor. It used to be strongly recommended to have this configuration (Data in ASP1 Receivers in ASP2+) It's not so much any more even SAP recommends they all be together. Part of this is the flat out number of arms. If you have say 12 arms and you end up with 8 in ASP1 and 4 in ASP2 even if you pull off the two RAID sets scenario that's only 4 arms. Putting everything in ASP1 means 12 arms for everyone in this example. The number of arms in the ASP with the Journal Receivers also affects the size of the journal write buffers. More is better up to something like 12 (memory fail?) disks in the ASP.

- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 1/10/2014 10:54 AM, Bakutis, Becky wrote:

Thanks, with the new hardware I think this is the perfect opportunity to segregate the RAID sets so they don't cross ASPs.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Kirk Goins
Sent: Friday, January 10, 2014 8:30 AM
To: Midrange Systems Technical Discussion
Subject: Re: Creating ASP for Journal Receivers

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 effort?


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.




--
Kirk
--
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.