I do wish TSM would be a fully clustered solution.  With virtual IPs, 
grid/redundant storage, redundant server nodes, virtually unlimited scale 
and everything you need to seamlessly handle any outage.  Many things the 
storage side already has.  Maybe it's not cost effective to develop these 
solutions for "secondary storage"

In reality, I've found this business has always been about wrangling a 
product into submission with scripts, ugly hacks and automation in order 
to get the job done. 

Regards, 
Shawn
________________________________________________
Shawn Drew





Internet
markus.engelhard AT BUNDESBANK DOT DE

Sent by: ADSM-L AT VM.MARIST DOT EDU
04/03/2012 01:50 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] RFE 17805






Dear Remco et al.,

I agree that in a "poor man´s cluster" with only part of the 
infrastructure
failing over, some manual processes have to be initiated:
- I like the policy set solution, as the scripts will also enable just an
outage of one of the libraries
- if you run an active-active and copy-copy setup, you can double the
number of drives for backup (if you copy asynchronously) and set the "DR
pool" as next pool
- I´m not so fond of changing the device classes
- I have not yet meddled with node replication, but I certainly will
(dreaming of a four site low bandwidth disk only environment...)

I had to run these sort of settings in our branch offices with TSM on
windows and LTO1/2 in IBM 3583 back in the TSM 5.3 days, you were really
kept in practice for weekly DRs in these environments!
Finally I was able to consolidate to an enterprise scale. In the end it
boiled down to virtualizing the libraries with near-transparent failover,
just one IO-error and it´s done and self-repairing once both sides are up
and running again. One more point ist having the databases (ERP; ORACLE;
DOMINO; ...) have enough space to survive at least 24 hours without 
dumping
their transaction logs. You have to have at least one of these features
(best both), else the design is to be put to question. Ask the managers if
they want to be enterprise or if they just want to pretend to be...

In the end it would of course be nice to have such a feature, but who will
decide desaster is here? Normally it would be more than a HACMP or 
likewise
failover to declare desaster, time enough to have someone push the button
to run the scripts.

Kind regards,
_____________________________________________________
Markus Engelhard
Dipl. Min.
Deutsche Bundesbank
Zentrale
Produktmanagement Infrastrukturen

Wilhelm-Epstein-Straße 14
60431 Frankfurt am Main

Tel.: 069 9566-6104
Fax: 069 9566-4290
E-Mail: markus.engelhard AT bundesbank DOT de
www.bundesbank.de


--
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet.

Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der
Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch
raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser
Nachricht durchzuführen. Wir schließen außer für den Fall von Vorsatz oder
grober Fahrlässigkeit die Haftung für jeglichen Verlust oder Schäden durch
virenbefallene Software oder E-Mails aus.

Jede von der Bank versendete E-Mail ist sorgfältig erstellt worden, 
dennoch
schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer
irgendwie gearteten Verpflichtung zu Lasten der Bank ausgelegt werden.
______________________________________________________________________

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of  the material in this
e-mail or of parts hereof is strictly forbidden.

We have taken precautions to minimize the risk of transmitting software
viruses but nevertheless advise you to carry out your own virus checks on
any attachment of this message. We accept no liability for loss or damage
caused by software viruses except in case of gross negligence or willful
behaviour.

Any e-mail messages from the Bank are sent in good faith, but shall not be
binding or construed as constituting any kind of obligation on the part of
the Bank.


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.