ADSM-L

Re: [ADSM-L] RFE 17805

2012-04-02 12:54:20
Subject: Re: [ADSM-L] RFE 17805
From: Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 2 Apr 2012 12:49:05 -0400
Just like scripting an "upd stg" in order to migrate data on a daily
basis, you can have a failover script update a device class

Regards,
Shawn
________________________________________________
Shawn Drew





Internet
r.post AT PLCS DOT NL

Sent by: ADSM-L AT VM.MARIST DOT EDU
04/02/2012 12:20 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] RFE 17805






and in what world is updating the device class not an intervention?

On 2 apr. 2012, at 18:07, Shawn Drew wrote:

> When you fail over the database, the primary pool is still defined.  You
> just need to update the device class to point to the DR library.
> the existing tape volumes are all destroyed, but you can backup to the
> pool anyway.  It will grab new scratch tapes.
> You can automate that.
>
> Regards,
> Shawn
> ________________________________________________
> Shawn Drew
>
>
>
>
>
> Internet
> r.post AT PLCS DOT NL
>
> Sent by: ADSM-L AT VM.MARIST DOT EDU
> 04/02/2012 11:54 AM
> Please respond to
> ADSM-L AT VM.MARIST DOT EDU
>
>
> To
> ADSM-L
> cc
>
> Subject
> Re: [ADSM-L] RFE 17805
>
>
>
>
>
>
> 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
>
>
>
> 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



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.

<Prev in Thread] Current Thread [Next in Thread>