ADSM-L

Re: [ADSM-L] RFE 17805

2012-03-31 13:23:49
Subject: Re: [ADSM-L] RFE 17805
From: Remco Post <r.post AT PLCS DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sat, 31 Mar 2012 19:17:17 +0200
On 30 mrt. 2012, at 16:24, Shawn Drew wrote:

> Ok, so this is for an "active-active" cluster relying on a active-passive
> backup solution.
> 

or an active-passive cluster relying on an active-passive tsm server cluster.

> 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.
> 

not, have you ever tried setting your library on fire together with your TSM 
server and be able to provide backup services to the surviving environment. 
Some of the environments that TSM is used in rely on very high availability of 
crucial servers... think banks and airlines. Having some applications go down 
results in immediate media attention as the least costly consequence....

> Disk solutions also add functions for a more seamless failover (vtl
> replication, svc, srdf, etc),
> 

Yes, VTL's do, sometimes.

Of course, this is not for everybody. But I know at least a few TSM customers 
in the Netherlands alone that could very well use this feature.

> 
> 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.

-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.post AT plcs DOT nl
+31 6 248 21 622

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