ADSM-L

[ADSM-L] Simultaneous copy and compatible data formats/device types

2017-08-15 17:37:58
Subject: [ADSM-L] Simultaneous copy and compatible data formats/device types
From: Skylar Thompson <skylar2 AT U.WASHINGTON DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 15 Aug 2017 21:36:27 +0000
 Content preview:  Hi TSMers, We're experimenting with simultaneous copy for
   one of our TSM servers, which gets very few, but very large, files every day
    from one of its clients (10000 - 20000 files, each 10GB - 1TB). It also has
    clients that send millions of small files, so we'd like the big data to end
    up directly on tape so that our disk spool can accept the small files. We
    use LTO7 for onsite data and LTO6 for offsite data. [...]

 Content analysis details:   (0.7 points, 5.0 required)

  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.7 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
 -0.0 RP_MATCHES_RCVD        Envelope sender domain matches handover relay 
domain
X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134]
X-Barracuda-Start-Time: 1502832991
X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
X-Barracuda-URL: https://148.100.49.28:443/cgi-mod/mark.cgi
X-Barracuda-Scan-Msg-Size: 3072
X-Virus-Scanned: by bsmtpd at marist.edu
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 
QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.41979
        Rule breakdown below
         pts rule name              description
        ---- ---------------------- 
--------------------------------------------------

Hi TSMers,

We're experimenting with simultaneous copy for one of our TSM servers,
which gets very few, but very large, files every day from one of its
clients (10000 - 20000 files, each 10GB - 1TB). It also has clients that
send millions of small files, so we'd like the big data to end up directly
on tape so that our disk spool can accept the small files. We use LTO7 for
onsite data and LTO6 for offsite data.

Our storage hierarchy looks like this:

DISK-BK-PRI-LTO7 - This is the top-level disk storage pool. Relevant
configuration:
   * DEVCLASS: DISK
   * NEXTSTGPOOL: DESPOT-ONSITE-LTO7
   * AUTOCOPY: MIGRATION
   * COPYSTGPOOLS: DESPOT-OFFSITE-LTO6
   * MAXSIZE: 10G
   * DATAFORMAT: NATIVE

DESPOT-ONSITE-LTO7 - This is the primary tape storage pool. Relevant
configuration:
   * DEVCLASS: DESPOT-LTO7
   * NEXTSTGPOOL: NONE
   * AUTOCOPY: ALL
   * COPYSTGPOOLS: DESPOT-OFFSITE-LTO6
   * MAXSIZE: NONE
   * DATAFORMAT: NATIVE

DESPOT-OFFSITE-LTO6 - This is the copy tape storage pool
   * DEVCLASS: DESPOT-LTO6
   * DATAFORMAT: NATIVE

Our device classes look like this:

DESPOT-LTO7:
   * DEVTYPE: LTO
   * FORMAT: ULTRIUM7C
DESPOT-LTO6:
   * DEVTYPE: LTO
   * FORMAT: ULTRIUM6C

It seems like this should work, yet we get messages like this when running
migrations from DISK-BK-PRI-LTO7 to DESPOT-ONSITE-LTO7 and
DESPOT-OFFSITE-LTO6:

08/06/2017 16:41:18      ANR1927W Autocopy process 9138 stopped for storage pool
                          DESPOT-OFFSITE-LTO6. The data format or device type 
was
                          not compatible with the data format or device type of
                          the primary pool. (SESSION: 116305, PROCESS: 9138)

Oddly, though, we don't see similar messages for client backups that
cut-through DISK-BK-PRI-LTO7 directly to tape due to its MAXSIZE setting,
so it seems like simultaneous copy is working for clients but not for
migrations.

I'm trying to figure out if this error message is referring strictly to the
storage pool DATAFORMAT parameter and device class DEVTYPE parameter, or if
it is more general, and I can't find anything one way or the other. IBM has
this documentation:

https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.0/com.ibm.itsm.srv.doc/c_simulwrite_limitations.html

Which says that you can use different device classes for simultaneous copy
as long as the data formats are "compatible" but never defines
"compatible". I have a PMR open with IBM, and they're claiming that
different LTO generations are incompatible, but I can't find any evidence
that that's accurate, especially given that client simultaneous copy is
working.

So I guess my question is - what have other people's experiences and
expectations been with simultaneous copy? Have you gotten a similar setup
to work properly?

Thanks!

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

<Prev in Thread] Current Thread [Next in Thread>
  • [ADSM-L] Simultaneous copy and compatible data formats/device types, Skylar Thompson <=

ADSM.ORG Privacy and Data Security by KimLaw, PLLC