Hello Eric,
It is very interesting usage of HACMP cluster. I have a few questions:
1) Are you using standard HACMP (PowerHA) or something called GEO....?
2) Are you using only TCP/IP heartbeat between cluster nodes?
3) What kind of SAN disk subsystems are you using?
4) What kind of mirroring technology are you using?
5) What is the relationship between disk mirroring and HACMP failover?
6) How you are testing secondary location? How to go back to normal mode after
testing?
Thank you very much in advance.
Kindest regards,
Grigori G. Solonovitch
Senior Technical Architect Ahli United Bank Kuwait www.ahliunited.com.kw
Please consider the environment before printing this E-mail
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Loon, EJ van - SPLXO
Sent: 02 04 2012 11:57 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] RFE 17805
Hi Shawn!
To clarify myself I will explain our current setup.
Primary location: IBM frame with one of the AIX HACMP cluster nodes, the
diskpool located on a SAN attached storage box, mirrored to the remote location
and the library containing the primary storage pool.
Secondary location: IBM frame with the other HACMP cluster node, the mirror of
the diskpool located on a SAN attached storage and the library containing the
copy storage pool.
If the primary location is lost, I loose one of the cluster nodes (this is
fixed by switching to the remote location), the mirror copy of the diskpool (no
problem) and the whole primary tapepool, because the library is gone too.
Kind regards,
Eric van Loon
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Shawn Drew
Sent: vrijdag 30 maart 2012 16:24
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: RFE 17805
Ok, so this is for an "active-active" cluster relying on a active-passive
backup solution.
As far as tape goes, after a DR situation, what if you just mark the individual
primary-tapes as destroyed instead of making the whole pool unavailable. It
should still grab from scratch and just create new volumes in the primary pool.
I've never done this, but I can't see why the primary pool wouldn't be
available for backup functions. You can then rebuild the pool slowly, in the
background, with restore-stg from the copypool.
Disk solutions also add functions for a more seamless failover (vtl
replication, svc, srdf, etc),
Regards,
Shawn
________________________________________________
Shawn Drew
Internet
Eric-van.Loon AT KLM DOT COM
Sent by: ADSM-L AT VM.MARIST DOT EDU
03/30/2012 04:03 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU
To
ADSM-L
cc
Subject
Re: [ADSM-L] RFE 17805
Hi Shawn!
You stated: "I guess I don't see the point of failing over backup functions".
Like I mentioned in my earlier reply: we are running a lot of Oracle nodes
which are also configured to be high available. So they are running on a
cluster, spread over two different locations. If one of the locations is hit by
a disaster, the cluster switches to the other location and everything is up and
running again.
Oracle uses archive logs. These logs are filled and the only way to flush them
is to make a archive log backup. If that's not possible (which is the case if
you lost your primary pool) the archive log becomes full and the database
simply stops.
Kind regards,
Eric van Loon
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Shawn Drew
Sent: donderdag 29 maart 2012 23:54
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: RFE 17805
We have a dual Data Center with tape libraries at both sites. Each site
provides production services for the local backups and DR services for the
other site.
In the case of a site disaster, all the hosts that would need backups also
go with it. Their DR counterparts are already configured for backups
at
the DR site to the local TSM servers. We failover the TSM instances,
but
only for restore services (from the copy pools). I guess I don't see the point
of failing over backup functions (as opposed to restore functions)
Is the ultimate goal to make sure the DR backups occur to the same nodenames so
it's a seamless backup history?
Regards,
Shawn
Internet
r.post AT PLCS DOT NL
Sent by: ADSM-L AT VM.MARIST DOT EDU
03/29/2012 04:09 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU
To
ADSM-L
cc
Subject
Re: [ADSM-L] RFE 17805
Hi,
node replication is nice, but there is no automatic failover, yet.
So, in a dual-DC setup you can failover TSM in HACMP, but it's completely
useless, same for replication, noting automatic. Now, what do you do when
everything (and I mean everything; mainframe LPARS, databases, file servers,
application servers, NAS filers, everything) fails over in a dual-DC setup but
you have to manually reconfigure either every TSM client in the node
replication setup, or all of your TSM storage pools. Either way your crucial
databases have stopped archiving their logs and filled up the active log
filespace long before 24x7 staff even comes round to calling the TSM admins.
On 29 mrt. 2012, at 20:23, John Monahan wrote:
> I believe TSM 6.3 node replication is one answer to your request.
>
>
>
> _______________________________________
> John Monahan
> Delivery Consultant
> Logicalis, Inc.
>
> _______________________________________
> Business and technology working as one
>
> This e-mail message is intended only for the confidential and
privileged
use of the addressee (or others authorized to receive for the addressee).
If you are not an intended recipient, please delete the e-mail and any
attachments and notify the sender immediately
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
Of
Loon, EJ van - SPLXO
> Sent: Thursday, March 29, 2012 3:31 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: RFE 17805
>
> Hi Remco!
> I totally agree!
> In our shop we had to create a dedicated server to enable backups in
case of a disaster. It contains a standby primary pool with 500 tapes, just
sitting there, costing money. This pool is located on the remote location and
is readonly. When the primary pool is lost, we have to make this pool readwrite
so backups can continue.
> In this case you can see that the primary focus of development is
still
on restore, while backing up became equally vital. Oracle database rely on a
frequent backup of the archive logs. When they become full, Oracle simply stops.
> I voted for your RFE and request others to do the same. It takes just
one minute of your time.
> Kind regards,
> Eric van Loon
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
Of
Remco Post
> Sent: woensdag 28 maart 2012 20:43
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: RFE 17805
>
> Hi all,
>
> I submitted a RFE for TSM regarding the behavior of copy pools.
>
> You can find the RFE via
> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRFEs and
search for RFE ID 17805.
>
> I'd like to invite all off you to vote on this RFE if you find it
useful, so that development can get a good idea of how important this FRE would
be to the customers.
>
> Below you find the input I submitted:
>
> Description: For one storage pool to be an exact replica of
another
> pool and be equivalent in every way, to the extend that if one pool
becomes unavailable all activity continues on the remaining pool, including
write activity.
>
> This would also involve changing the behavior of commands like delete
volume, migration, etc.
>
> Use case: In a dual-site setup with two tape libraries,
one
would
> want operations to continue as seamless as possible in case of a site
disaster. Current copy storage pools can't be promoted to primary pools, so
with the current technology one has to create new storage pools on the second
site, even though a copy storage pool is already available.
>
> Business justification: there are many dual site setup
with IBM and its
> customers. All data in a TSM server environment (disk) can be
mirrored,
but as soon as the primary tape storage pools become unavailable, there is a
lot of manual intervention involved before normal operations can continue.
>
> --
> Met vriendelijke groeten/Kind Regards,
>
> Remco Post
> r.post AT plcs DOT nl
> +31 6 248 21 622
> ********************************************************
> For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
its employees shall not be liable for the incorrect or incomplete transmission
of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
> ********************************************************
>
--
Met vriendelijke groeten/Kind Regards,
Remco Post
r.post AT plcs DOT nl
+31 6 248 21 622
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender. Any use not in accord with its
purpose, any dissemination or disclosure, either whole or partial, is
prohibited except formal approval. The internet can not guarantee the integrity
of this message. BNP PARIBAS (and its subsidiaries) shall
(will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
********************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
********************************************************
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender. Any use not in accord with its
purpose, any dissemination or disclosure, either whole or partial, is
prohibited except formal approval. The internet can not guarantee the integrity
of this message. BNP PARIBAS (and its subsidiaries) shall
(will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
********************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
********************************************************
Please consider the environment before printing this Email.
CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail
message and any attachments hereto may be legally privileged and confidential.
The information is intended only for the recipient(s) named in this message. If
you are not the intended recipient you are notified that any use, disclosure,
copying or distribution is prohibited. If you have received this in error
please contact the sender and delete this message and any attachments from your
computer system. We do not guarantee that this message or any attachment to it
is secure or free from errors, computer viruses or other conditions that may
damage or interfere with data, hardware or software.
|
