- Community Home
- >
- Storage
- >
- Entry Storage Systems
- >
- Disk Enclosures
- >
- Re: CA XP Journal, Journal groups etc
Disk Enclosures
1752647
Members
5335
Online
108788
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-09-2009 04:40 AM
тАО07-09-2009 04:40 AM
CA XP Journal, Journal groups etc
Hi
We're starting to implement CA XP Journal and looking for how existing users configure their environment in terms of journal groups, CT groups, HORCM etc.
We have 2 RAID groups on separate ACP pairs dedicated for journal volumes, which as per recommendations are striped 14+2 into 16 equally sized CVS. With this we can either create 1 large journal group, or up to 16 smaller ones (I believe this is the maximum number unless you meet specific shared memory requirements).
We have a number of HPUX and Linux machines which will be replicated. In an ideal world each one of these would be separately manageable, i.e. separate CT group so any individual host can be managed by horctakeover et al. However this means (as far as I can tell) 1 journal group per CT and therefore a maximum of 16 manageable hosts. Furthermore if some are busier than others, they all have the same amount of journal space.
With experimenting I see that it's possible to create 1 large journal group then have individual ldevs in PAIR or PSUS status within the same CT/Journal group, so we can test mount individual machines at the remote site, but major work such as horctakeover etc applies to the entire journal group.
So how do other people do it. Do you have one big Journal Group (and therefore 1 CT group) and accept that it's all or nothing. Do you have a journal group for categorized selections of machines? Do you have one group per host and accept that some will have journal space to cope with longer outages than others? Do you compromise journal log performance by having individually sized CVS's on a per-group basis based on expected throughput?
Any other thoughts?
Thanks.
We're starting to implement CA XP Journal and looking for how existing users configure their environment in terms of journal groups, CT groups, HORCM etc.
We have 2 RAID groups on separate ACP pairs dedicated for journal volumes, which as per recommendations are striped 14+2 into 16 equally sized CVS. With this we can either create 1 large journal group, or up to 16 smaller ones (I believe this is the maximum number unless you meet specific shared memory requirements).
We have a number of HPUX and Linux machines which will be replicated. In an ideal world each one of these would be separately manageable, i.e. separate CT group so any individual host can be managed by horctakeover et al. However this means (as far as I can tell) 1 journal group per CT and therefore a maximum of 16 manageable hosts. Furthermore if some are busier than others, they all have the same amount of journal space.
With experimenting I see that it's possible to create 1 large journal group then have individual ldevs in PAIR or PSUS status within the same CT/Journal group, so we can test mount individual machines at the remote site, but major work such as horctakeover etc applies to the entire journal group.
So how do other people do it. Do you have one big Journal Group (and therefore 1 CT group) and accept that it's all or nothing. Do you have a journal group for categorized selections of machines? Do you have one group per host and accept that some will have journal space to cope with longer outages than others? Do you compromise journal log performance by having individually sized CVS's on a per-group basis based on expected throughput?
Any other thoughts?
Thanks.
GTCI
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-09-2009 10:07 AM
тАО07-09-2009 10:07 AM
Re: CA XP Journal, Journal groups etc
Hi,
maybe this could help you:
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01702212/c01702212.pdf?jumpid=reg_R1002_USEN
maybe this could help you:
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01702212/c01702212.pdf?jumpid=reg_R1002_USEN
the pain is one part of the reality
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2009 01:27 AM
тАО07-10-2009 01:27 AM
Re: CA XP Journal, Journal groups etc
Thanks but I already have that manual. It describes how it works, but not how best to configure it in a specific environment.
Does no one use CA Journal on XP's in a running environment?
Does no one use CA Journal on XP's in a running environment?
GTCI
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-15-2009 11:57 PM
тАО07-15-2009 11:57 PM
Re: CA XP Journal, Journal groups etc
Hi
Usually people use 1 JNL group per host
1. to reduce impact on number of hosts, when some human error happens in configuring, horcmtakeover, extending JNL group. If there are number of hosts in 1 JNL group and something goes wrong in JNL group, it may affect all hosts.
2. If we have 1 JNL per host, it is easy to plan and extend the particular hosts JNL Group. for eg. there is 1 JNL group for 10 hosts, out of 10 hosts, we have 1 host which fills up JNL faster, we have to extend whole JNL group unnecessarily, instead we if we have 1 JNL group per host, we can extend the particular JNL and we can just change the setting for each JNL"
3.If there is a situation when a user wants to decommission one cluster host there we need to reduce the JNL size which is risky job. Instead if we have 1 JNL per host, we can just delete the JNL group and free the JNL LUN/s.
Usually people use 1 JNL group per host
1. to reduce impact on number of hosts, when some human error happens in configuring, horcmtakeover, extending JNL group. If there are number of hosts in 1 JNL group and something goes wrong in JNL group, it may affect all hosts.
2. If we have 1 JNL per host, it is easy to plan and extend the particular hosts JNL Group. for eg. there is 1 JNL group for 10 hosts, out of 10 hosts, we have 1 host which fills up JNL faster, we have to extend whole JNL group unnecessarily, instead we if we have 1 JNL group per host, we can extend the particular JNL and we can just change the setting for each JNL"
3.If there is a situation when a user wants to decommission one cluster host there we need to reduce the JNL size which is risky job. Instead if we have 1 JNL per host, we can just delete the JNL group and free the JNL LUN/s.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP