Journaling - User ASPs Versus the System ASP
Web Doc
Note: This is publication is now archived. For reference only.
Abstract
Factors to consider when deciding whether it makes sense to carve out a user ASP to house journal receivers on the iSeries or System i.
Written by Larry Youngren, Software Engineer
IBM Systems &Technology Group, Development
Development iSeries Journaling
Contents
User ASPs versus the system ASP
A frequently posed question goes something like this, “Years ago I remember being told to always place my journal receivers into a private user ASP. Is that advice still relevant?”
The question regarding use of user ASPs to house your journal receivers is not a clear-cut issue. There are pros and cons of each approach and clearly the justifications for use of a user ASP which existed some years back have diminished somewhat due to more modern hardware and especially for systems that are configured with lots of mammoth-sized IOA write cache.
Some shops originally elected to place their journal receivers on user ASPs primarily for performance reasons (private disk arms, less arm contention). That was a strong argument in the days when each journal deposit led to a disk write and each disk write moved directly from main memory to the disk surface without use of an intervening IOA write cache, or even in the days when the size of IOA write cache was puny.
Those days have passed.
Given sufficient IOA write cache, the performance justification for private disk arms is a tough sell - - even more so as the quantity of bytes beneath each such disk arm has mushroomed as well.
In many shops the temptation, given so much disk capacity per arm, is to configure fewer and fewer disk arms per user ASP - - which is clearly counter-productive when the journal is attempting to schedule overlapped disk writes across multiple arms.
As a consequence, many shops that originally configured user ASPs predominantly for performance reasons have gradually switched to use of the system ASP instead (since it tends to have lots of disk arms) as the repository of their journal receivers. Given sufficient IOA write cache, it's probably not a bad performance choice most of the time.
The appendix of the IBM Redbook Striving for Optimal Journal Performance, SG24-6286, shows a simple analysis you can (and probably should) perform to discern if you've got sufficient IOA write cache to keep up with your journal disk-write traffic volume.
On the other hand, some shops originally elected to configure user ASPs and place their journal receivers thereon not so much for performance reasons but rather because the isolation afforded by the user ASP established a firewall of sorts between the system ASP and the user ASP. Therefore, in the event that some disk failure among the arms within the system ASP forced them to reload/restore their system, they hadn't lost the audit trail afforded by the journal receiver content. Therefore, the user ASP survived and the journal receivers residing thereon could be used to bring all of the restored database files up to date.
Given the fact that disk drives, such as those residing within the system ASP, can indeed fail and that if they did you’d lose both your latest file images and your journal receiver, this justification might still lead some shops to continue to configure and employ user ASPs to house their journal receivers.
But even here there's been a trend brewing. Many shops are increasingly employing remote journal support to send the newest journal deposits, not just to the local journal receiver, but also, in real time, to a remote location. Therefore such shops end up with two copies of their journal entries and hence have less concern about local disk drive loss even if the journal receivers reside within the system ASP of the production machine. Some of these shops have an entire secondary high availability target machine to take over if the source gets in trouble. Others configure remote journal but merely route their journal receivers remotely to a small machine serving as a vault for the receivers. Either way, the fear about disk loss on the primary begins to diminish and hence even these shops whose original motivation was isolation and survivability rather than performance have been gradually migrating away from user ASPs to house their journal receivers.
So who should stay with the user ASP approach?
1) Those who have no electronic remote vault, would be significantly harmed if the last 30 minutes worth of transactions were lost, and are fearful of disk loss.
2) Those who find that the journal and its related performance are the primary bottleneck affecting interactive response time and/or elapsed batch completion time, can't afford or justify additional IOA write cache, and are willing/able to configure a sufficient supply of disk arms to the user ASP to help relieve that performance bottleneck.
As you can see, there's no one simple answer to this perplexing question.
Rather, it often takes experimentation and/or a benchmark to determine whether user ASPs are still justified.
Bottom line: User ASPs are never a bad choice (provided they contain a sufficient number of disk arms and matching IOA write cache) but their justification is a tough sell these days in many shops and the argument for their existence is generally not as strong as it was before remote journal and IOA write cache came along.
A frequently posed question goes something like this, “Years ago I remember being told to always place my journal receivers into a private user ASP. Is that advice still relevant?”
The question regarding use of user ASPs to house your journal receivers is not a clear-cut issue. There are pros and cons of each approach and clearly the justifications for use of a user ASP which existed some years back have diminished somewhat due to more modern hardware and especially for systems that are configured with lots of mammoth-sized IOA write cache.
Some shops originally elected to place their journal receivers on user ASPs primarily for performance reasons (private disk arms, less arm contention). That was a strong argument in the days when each journal deposit led to a disk write and each disk write moved directly from main memory to the disk surface without use of an intervening IOA write cache, or even in the days when the size of IOA write cache was puny.
Those days have passed.
Given sufficient IOA write cache, the performance justification for private disk arms is a tough sell - - even more so as the quantity of bytes beneath each such disk arm has mushroomed as well.
In many shops the temptation, given so much disk capacity per arm, is to configure fewer and fewer disk arms per user ASP - - which is clearly counter-productive when the journal is attempting to schedule overlapped disk writes across multiple arms.
As a consequence, many shops that originally configured user ASPs predominantly for performance reasons have gradually switched to use of the system ASP instead (since it tends to have lots of disk arms) as the repository of their journal receivers. Given sufficient IOA write cache, it's probably not a bad performance choice most of the time.
The appendix of the IBM Redbook Striving for Optimal Journal Performance, SG24-6286, shows a simple analysis you can (and probably should) perform to discern if you've got sufficient IOA write cache to keep up with your journal disk-write traffic volume.
On the other hand, some shops originally elected to configure user ASPs and place their journal receivers thereon not so much for performance reasons but rather because the isolation afforded by the user ASP established a firewall of sorts between the system ASP and the user ASP. Therefore, in the event that some disk failure among the arms within the system ASP forced them to reload/restore their system, they hadn't lost the audit trail afforded by the journal receiver content. Therefore, the user ASP survived and the journal receivers residing thereon could be used to bring all of the restored database files up to date.
Given the fact that disk drives, such as those residing within the system ASP, can indeed fail and that if they did you’d lose both your latest file images and your journal receiver, this justification might still lead some shops to continue to configure and employ user ASPs to house their journal receivers.
But even here there's been a trend brewing. Many shops are increasingly employing remote journal support to send the newest journal deposits, not just to the local journal receiver, but also, in real time, to a remote location. Therefore such shops end up with two copies of their journal entries and hence have less concern about local disk drive loss even if the journal receivers reside within the system ASP of the production machine. Some of these shops have an entire secondary high availability target machine to take over if the source gets in trouble. Others configure remote journal but merely route their journal receivers remotely to a small machine serving as a vault for the receivers. Either way, the fear about disk loss on the primary begins to diminish and hence even these shops whose original motivation was isolation and survivability rather than performance have been gradually migrating away from user ASPs to house their journal receivers.
So who should stay with the user ASP approach?
1) Those who have no electronic remote vault, would be significantly harmed if the last 30 minutes worth of transactions were lost, and are fearful of disk loss.
2) Those who find that the journal and its related performance are the primary bottleneck affecting interactive response time and/or elapsed batch completion time, can't afford or justify additional IOA write cache, and are willing/able to configure a sufficient supply of disk arms to the user ASP to help relieve that performance bottleneck.
As you can see, there's no one simple answer to this perplexing question.
Rather, it often takes experimentation and/or a benchmark to determine whether user ASPs are still justified.
Bottom line: User ASPs are never a bad choice (provided they contain a sufficient number of disk arms and matching IOA write cache) but their justification is a tough sell these days in many shops and the argument for their existence is generally not as strong as it was before remote journal and IOA write cache came along.
Special Notices
The material included in this document is in DRAFT form and is provided 'as is' without warranty of any kind. IBM is not responsible for the accuracy or completeness of the material, and may update the document at any time. The final, published document may not include any, or all, of the material included herein. Client assumes all risks associated with Client's use of this document.