Results 1 to 12 of 12
  1. #1
    Senior Member GregE's Avatar
    Join Date
    May 2006
    Posts
    2,100
    Thanks
    9
    Thanked 17 Times in 16 Posts

    Default Replication Requirements

    TSM Server 5.5
    Solaris 10

    Searching the forum, I've seen some discussion of this, almost. So I thought I'd post a new thread.

    In reading this technote, I'm now starting to think about how "consistency" can be achieved..
    http://www-01.ibm.com/support/docvie...&cc=us&lang=en

    We're now looking at IBM XIV SAN storage, and likely DataDomain storage (file and VTL) for deduplicated file/VTL storage. We'll have a production site, and a DR site with another identical TSM server, offline, and another XIV SAN and DataDomain device. So we'll be replicating DB, logs, and storage pools to the DR site. I know we can use the XIV and DataDomain replication software, BUT that doesn't address the "collective consistency" requirement of the vital TSM pieces. The TSM pieces need to replicate as a group, otherwise the DR site may have something in a storage pool that it doesn't yet have in it's copy of the TSM DB....etc etc..

    How is this achieved?

    ***Update: OK I found something in the XIV Copy Services redbook....
    Consistency groups (CG): A consistency group is a set of related volumes on the same
    XIV Storage System that are treated as a single consistent unit. Consistency groups are
    supported within Remote Mirroring.


    The XIV documentation answers how it's done inside XIV, where the TSM db, logs, and primary disk storage pools are. Then a question is, how to ensure that the TSM db, logs, and DataDomain file/VTL primary storage pools remain consistent as a group since the live TSM db and logs are on the XIV system, not DataDomain.
    Last edited by GregE; 06-03-2010 at 02:22 PM.

  2. #2
    Senior Member GregE's Avatar
    Join Date
    May 2006
    Posts
    2,100
    Thanks
    9
    Thanked 17 Times in 16 Posts

    Default

    Does anyone replicate/mirror their primary disk pools to a DR site?

    Am I correct to be concerned?
    Last edited by GregE; 06-03-2010 at 12:42 PM.

  3. #3
    Member JeanSeb's Avatar
    Join Date
    Aug 2008
    Location
    Quebec City
    Posts
    181
    Thanks
    6
    Thanked 2 Times in 2 Posts

    Default

    Personally, I don't need a "Hot" site. I can have a failover site from which I will be serving yesterday backups from the last database backup after restoring my TSM instance. So the "synchronous" database/log replication was never an issue (and too much of an hassle frankly). I'm replicating the DBB and active data pool once a day, and have agreed to a reasonable SLA with my boss.

    Are you in such an High availibility environnement that you need to be able to serve backups the minute after a disaster?

    Good question nonetheless, I will be following this thread with interest as I do aspire to be that efficient

  4. #4
    Senior Member GregE's Avatar
    Join Date
    May 2006
    Posts
    2,100
    Thanks
    9
    Thanked 17 Times in 16 Posts

    Default

    Well, this will be a new architecture for us, and the restore point objective is still not definitely defined. BUT, I have heard 4 hours for the most critical systems. Regular backups will not be able to accomodate that, so we'll have to use synchronization at the SAN/DataDomain level.

    I am following this thread with interest as well.

  5. #5
    Member
    Join Date
    Jun 2008
    Location
    Montreal, Canada
    Posts
    115
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    We have a similar situation here. Our TSM server setup looks like JeanSeb where we send our DBbackup to DR site via a scheduled SFTP script daily. VTL also replicates to DR site.

    Critical servers have their LUNs replicate to the DR site.

    In case of DR we send our copypool tapes over to DR site as well (not all servers backup to VTL). We restore yesterday's TSM db

    The consistency thing seemed to be too much of a hassle.

  6. #6
    Senior Member GregE's Avatar
    Join Date
    May 2006
    Posts
    2,100
    Thanks
    9
    Thanked 17 Times in 16 Posts

    Default

    Thanks all.

    Just had a DataDomain tech in for assessment. I asked my question. Apparently I'm thinking too deep in the weeds. A major bank he works with runs TSM and just moved into several DataDomain appliances. They recently did their DR testing and things worked fine.

  7. #7
    Senior Member THE_WIPET's Avatar
    Join Date
    May 2006
    Location
    Montreal
    Posts
    562
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default

    Phil: Do you use TSM to replicate your VTL or you use the VTL replication software?
    We have a VTL and maybe looking for another one at or DR site so any hint on this is apreciated!.

  8. #8
    Senior Member GregE's Avatar
    Join Date
    May 2006
    Posts
    2,100
    Thanks
    9
    Thanked 17 Times in 16 Posts

    Default

    TSM (any release thus far) is not aware of VTL replication. If you replicate VTL it's done at the VTL level and TSM has no knowledge of that second copy.

    TSM would only be doing it if it's a "normal" TSM primary pool to copy pool backup, but I assume that's not what you're referring to.

    Here's a discussion on it. The intial post is describing what you are asking, that being can TSM be the pilot that is guiding the VTL replication. Answer to that is no.
    http://adsm.org/forum/showthread.php?t=21055

  9. #9
    Member
    Join Date
    Jun 2008
    Location
    Montreal, Canada
    Posts
    115
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by THE_WIPET View Post
    Phil: Do you use TSM to replicate your VTL or you use the VTL replication software?
    We have a VTL and maybe looking for another one at or DR site so any hint on this is apreciated!.

    We use the VTL to replicate and deduplicate (IBM TS7650G)

  10. #10
    Senior Member GregE's Avatar
    Join Date
    May 2006
    Posts
    2,100
    Thanks
    9
    Thanked 17 Times in 16 Posts

    Default

    Questions Phil.....
    Are you replicating your TSM DB and Logs to your secondary site via SAN replication? Have your DR tests been smooth?

  11. #11
    Senior Member THE_WIPET's Avatar
    Join Date
    May 2006
    Location
    Montreal
    Posts
    562
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default

    GregE: i'm aware that TSM is not "VTL Replication aware" But I know that certain setup use only 1 Online pool, and use the replication software from the VTL to replicate that pool. This with the DB and logs with a sleeping TSM server. If the "Primary crash" they boot the other server with the replicat enable. This setup is reptty interesting but to my eye's one big flaw, if a volumes is corrupted, there is no turning back.

    Thank phill will read the info of your VTL. We are using a EMC EDL 4106.

  12. #12
    Senior Member GregE's Avatar
    Join Date
    May 2006
    Posts
    2,100
    Thanks
    9
    Thanked 17 Times in 16 Posts

    Default

    Quote Originally Posted by THE_WIPET View Post
    if a volumes is corrupted, there is no turning back.
    I agree, and that part bothers me. For a DR site, we "could" have primary pools, replicated from the primary site, and that's it, but that brings up what you've mentioned.

    Therefore, it will be best to have copy pools at the DR site, and not only replicate primary to primary, but let TSM normal primary-to-copy pool backup happen as well.

Similar Threads

  1. DataDomain Replication
    By GregE in forum TSM Server
    Replies: 17
    Last Post: 06-25-2010, 03:14 PM
  2. DB Replication at night
    By rahulpawar in forum TSM Server
    Replies: 0
    Last Post: 09-22-2009, 06:30 AM
  3. Tsm 5.5 certification requirements
    By tsmuser13 in forum Training and Certification
    Replies: 3
    Last Post: 08-04-2009, 09:24 AM
  4. Replication
    By tsmlover in forum TSM Server
    Replies: 2
    Last Post: 03-31-2009, 10:07 AM
  5. AIX server requirements
    By etchingsj in forum Capacity Planning
    Replies: 7
    Last Post: 10-03-2008, 05:18 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •