If it can be made accessible by human intervention you could also script it a
kind of post action after the hacmp start script.
If library A is unavailable, activate policy set "disaster" or some update copy
group script.
Also useful when the primary library is unavailable a longer time.
Jeroen Hooft
On 2 apr. 2012, at 17:57, "Remco Post" <r.post AT PLCS DOT NL> wrote:
> On 2 apr. 2012, at 17:00, Shawn Drew wrote:
>
>> So in the original post, I think it was mentioned that there were 2 tape
>> libraries. One in the DR site.
>> If you have all copypool volumes there and have some scratch tapes, I
>> don't see how any functions are missed.
>> You can backup directly to the primary pool in the DR site immediately.
>
> that is where you are wrong, there is no primary pool on the dr site... at
> least not one that can be accessed without some human intervention.
>
>> is only the existing volumes that are
>> offline (but available through copypool) New volumes are available from
>> the scratch tapes.
>>
>> Regards,
>> Shawn
>> ________________________________________________
>> Shawn Drew
>>
>>
>>
>>
>>
>> Internet
>> Eric-van.Loon AT KLM DOT COM
>>
>> Sent by: ADSM-L AT VM.MARIST DOT EDU
>> 04/02/2012 04:57 AM
>> Please respond to
>> ADSM-L AT VM.MARIST DOT EDU
>>
>>
>> To
>> ADSM-L
>> cc
>>
>> 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
>> ********************************************************
>>
>>
>>
>>
>> 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.
>
> --
> Met vriendelijke groeten/Kind Regards,
>
> Remco Post
> r.post AT plcs DOT nl
> +31 6 248 21 622
|
