I know of at least one large customer who is successfully using Journal
Based Backup in a SAN cluster
environment.
The ReadDirectoryChangesW api works with any local (non network) disk and
will work
with network drives but the Journal Daemon blocks specifying network
drives because
the API limits the notification buffer size for these types of drives to
64K or less which
essentially makes it unusable.
As mentioned if the previous append SAN drives are considered local
resources.
I have written several utilities for interrogating the file system and
profiling file system change activity
which are helpful in determining if a Journal Based Backup is viable in a
particular
environment.
If you are interested in obtaining these utilities on an AS IS basis
please send me a note
directly.
There are some limitations in running multiple Journal Based Backup
processes
(via multiple schedules or whatever) which have been somewhat addressed in
the latest
release (5.20) and fixtest (5.16.2) which may come into play in a cluster
environment,
so please consider applying the latest fixtest (and reading the relevant
portions
of the readme file) if the target environment has multiple Journal Based
Backups
scheduled which may run concurrently.
I'm not sure I understand the following statement:
>>> I'm going to defer to Andy Raibeck on the official answer on this
>>> one.Does it work? The answer I got was
>>> that this was not supported, because the TSM Journal Service cannot be
>>> restarted on the second
>>> half of the cluster if a failover occurs. But if you are willing to
live
>>> with this limitation, it does work. You
>>> can have the journal service monitor the shared resources, and it will
>>> journal them. It just won't work in
>>> the event of a failover. The journal will not be valid, and you will
have
>>> to resort to a "normal" incremental backup.
If the journal service is installed on both nodes in the cluster and the
journal service is configured to
journal the shared resources the same I don't see any reason why failover
wouldn't work (clustering
isn't my area of expertise so I could be wrong...).
The journal service should be installed on both nodes in the cluster with
identical configuration
for shared journaled resources.
The shared resource(s) being journaled should be offline and deferred on
one node in the cluster,
and online (being journaled) on the other node.
When a failover occurs the shared resource(s) should go offline on the
node which is failing over,
and should come online on the node which is being failed over to.
Since the PreserveDbOnExit setting is used the journal db should remain
valid and journal based
backups should resume uninterrupted.
Again, I'm not sure why this would work, but perhaps there is something I
am missing.
Sample configuration settings for a shared resource with Journal daemon
running on both nodes
in cluster:
[JournaledFileSystemSettings.D:\]
; Journal DB must always be accessible from each node is cluster
JournalDir=d:\tsmjournal
; Journal will remain valid if journal fs goes offline and comes backup
online
; such as is the case if journal daemon stops/restarts
PreserveDBOnExit=1
; Fs will go in defer mode if it is not available on the node which the
journal daemon is
; running on, will come online as soon as it becomes available
DeferFsMonStart=1
;
;Interval in seconds to check availability of deferred FS
DeferRetryInterval=30
;
; Prevents error messages from being logged when FS is offline but
deferred via prior setting
logFsErrors=0
Pete Tanenhaus, TSM Client Development
Pete Tanenhaus
Tivoli Storage Solutions Software Development
email: tanenhau AT us.ibm DOT com
tieline: 320.8778, external:
"Those who refuse to challenge authority are condemned to conform to it"
---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 07/13/2003
10:40 AM ---------------------------
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: MSCS Win2K, TSM Journal Backups and SAN attached disks!!!
See answers below:
At 04:07 PM 7/11/2003 +0100, you wrote:
>*SMers,
>
>I understand from searching back on the list that this one might be a
>bit of a hot potato, but here goes anyway:
>
>We'd ideally like to set up TSM Journaling on a Win2K MSCS Cluster using
>TSM 4.2 Client with SAN attached disk.
>
>So, my questions are:
>
> o) Does the TSM Journal Engine support SAN-attached disks - I
>recall something about the Win32 api ReadDirectoryChangesW only
>monitoring 'local' file system changes - does this preclude SAN attached
>disk?
A SAN-attached disk is considered a local file system. Yes, this
would be "journalable". (Is that even a word?)
> o) Would this work in an MSCS cluster?
I'm going to defer to Andy Raibeck on the official answer on this
one.Does it work? The answer I got was
that this was not supported, because the TSM Journal Service cannot be
restarted on the second
half of the cluster if a failover occurs. But if you are willing to live
with this limitation, it does work. You
can have the journal service monitor the shared resources, and it will
journal them. It just won't work in
the event of a failover. The journal will not be valid, and you will have
to resort to a "normal" incremental backup.
>Has anyone done this, or tried to? Any advice?
>
>Any help greatly received, as always!
>
>Rgds,
>
>David McClelland
>Global Management Systems
>Reuters Ltd
>
>
>--------------------------------------------------------------- -
> Visit our Internet site at http://www.reuters.com
>
>Get closer to the financial markets with Reuters Messaging - for more
>information and to register, visit http://www.reuters.com/messaging
>
>Any views expressed in this message are those of the individual
>sender, except where the sender specifically states them to be
>the views of Reuters Ltd.
Dave Canan
TSM Performance
IBM Advanced Technical Support
ddcanan AT us.ibm DOT com
|
