Commit ba55e345 authored by Julien Leduc's avatar Julien Leduc
Browse files

[skip ci] Markdown import of GeneralTapeLifecycle in CTA repo from the...

[skip ci] Markdown import of GeneralTapeLifecycle in CTA repo from the document in [Tape TWIKI](https://twiki.cern.ch/twiki/bin/view/TapeOperations/GeneralTapeLifecycle) written by Vlado. This is primarily to ease dev/operation discussion in gitlab issues around a common evolving document.
parent 55dfd3b9
# General Tape Lifecycle Management
The goal of this document is to describe all stages (including the
corresponding commands in CASTOR and CTA) that a tape cartridge goes
through during its life at CERN.
## Order and Delivery
New tape cartridges are usually ordered by a CERN staff member from the Tape Operations team and are entered in EDH. It is *very important* to order good labels of the new tape cartridges. The label sequence numbers *must not* overlap with the existing tape cartridges while the format of the labels should be the same as we already use (with colors (vibrant)with horizondal layout).
Delivery of new tape cartridges is usually 4 weeks from the dispatch of the order. The cartridges are usually delivered directly to the tape vault of building 513 (room 513 S-034)
After delivery, Tape Operations team (primarily DCS) shall reorder the boxes from the pallets such that the numbers follow the order sequentially.
## Inserting into a tape library
Inserting of new tape cartridges into the tape library should be done in batches of 100 in order to not to overflow the virtual I/O slots of the (IBM) tape libraries. Each batch should be consecutive sequence of tapes, starting from the lowest number.
After each batch, the following command needs to be issued on any tape server connected to the library to import the tapes from the virtual I/O slots into the physical home slots (operation does not cause any physical cartridge moves):
* CASTOR: `smc -i`
* CTA: `cta-smc -i`
## Declaring tapes in CASTOR / CTA in the tape pools for labeling
Once the tapes are physically as well as logically in a tape library, they need to be declared in the software that communicates with the tape library:
* CASTOR: `vmgrentertape`
Example: `vmgrentertape -d 9TC -l aul -V L12345 -P tolabel_IBM1L7 --library IBM1L8 <https://twiki.cern.ch/twiki/bin/edit/TapeOperations/IBM1L8?topicparent=TapeOperations.GeneralTapeLifecycle;nowysiwyg=1> --ma IBM-FUJIFILM --ml L --mo LTO`
* CTA: `cta-admin tape add`
Example: `cta-admin tape add -v I12345 --mediatype 3592JD --vendor IBM --logicallibrary IBM455 --tapepool supply_IBM455 --capacity 15000000000000 --disabled false --full false`
Usually, as the tapes are declared, they are put into the corresponding pools for labeling per library.
## Labeling of the tapes
Before the tapes are ready for production, small file (also called VOL1) needs to be written at the begging of each tape cartridge. This process is called labeling and it is used for:
* Initializing tape cartridge at certain capacity (usually the maximum capacity the drive can use on a given cartridge).
* VOL1 file contains the logical label of the cartridge (for example: *L12345*). This is checked on every mount to confirm that the cartridge that was requested by software was indeed mounted in the drive.
* Making data beyond the VOL1 label inaccessible (special firmware would be needed to bypass this).
To perform the labeling, Tape Operations team (primarily DCS) uses wrapper script called |tape-label|. This script needs to be run on a specially dedicated tape server (in order to ensure that no other tapes are mounted there). Example: `tape-label -V L12345 --dstpool supply_IBM1L7 --force`. The script primarily performs series of initial checks and if desired, in the end, it logically moves the tape into the specified tape pool - usually called /supply/.
Internally, the |tape-label| script is using the following command of the higher level software:
* CASTOR: `castor-tape-label`
* CTA: **MISSING** it is also worth mentioning here that a tape drive dedications are also **MISSING**
## Supplying empty tapes to user tape pools
Once the new tape cartridges have been labeled, they are moved into the *supply* tape pools in the corresponding logical library.
Example: *supply_IBM3JD* contains all *3592JD* tape cartridges (at 10 TB capacity) that are physically located in the IBMLIB3.
The assignment of the cartridges from the *supply* tape pools to user tape pools is performed by separate mechanism that is implemented like this:
* CASTOR: The supply mechanism is implemented in Oracle in the Tape Operations Management System [TOMS](https://apex.cern.ch/pls/htmldb_castorns/f?p=TOMS_PROD). It runs every 20 minutes using `dbms_scheduler.create_job` which calls `supply_pools_update` stored procedure. It is explained in great detail at the page where one can select set of supply pools for a user pool: log=in to TOMS and click on *Tape Pools* and then on any value in any row in the *Supply Pools* column to see the description.
* CTA: **MISSING** - see [issue 481](https://gitlab.cern.ch/cta/CTA/issues/481).
## Tape moves between tape pools
Usually, most of the tape cartridges are just filled once and for most of their lifetime, they stay in one tape pool until they are logically emptied (for example by repacking).
However, in some cases, it is necessary to move a tape between tape pools. This can be done by these commands:
* CASTOR: `vmgrmodifytape`
* CTA: `cta-admin tape ch`
## Problem on a tape
If a problem on a tape occurs, this is usually handled by quickly moving accessible data onto another tape and focusing recovery efforts on problematic segments of the tape.
This is described separately:
* CASTOR: [Tape Operations Tape Workflow](https://twiki.cern.ch/twiki/bin/view/TapeOperations/ProblematicTapeWorkflow)
* CTA: **MISSING** for now, but should be covered by the `cta-admin repack` command.
NOTE: Tape Operations team currently also uses `tape-drivetest` and `tape-mediacheck`. While the core functionality of these 2 scripts is in principle independent from the high lever software, they are performing series of checks (such as whether the test tape is empty or whether it is in *erase* test pool) hence they do use the high level commands. The porting of the 2 scripts from CASTOR to CTA should be trivial once the CTA dedications are in place. In addition to this, CTA also mentiones `cta-admin test` and `cta-admin verify` functionality (which might cover some of the usecases of the 2 scripts), but that is not yet implemented.
## Removing tape from library
At the end of the useful life of a tape, it needs to be removed from use. This is done in multiple steps:
1. First the tape is repacked and made empty. This process is similar to the one mentioned in step 7).
2. Then the tape is again labeled (this time without changing the tape pool). The reason for this is to prevent easy access to any data on the tape in case it leaves CERN site. See the above mentioned step 4).
3. Then the tape is ejected from the tape library.
4. At the end the tape is removed from inventory. See the step 9).
As there are usually multiple tapes to be ejected from the tape library, the Tape Operations team (primarily DCS) uses a wrapper script `tape-eject`.
In addition to many checks (whether the tape to eject is in the given tape library, or whether it is empty) that script at it's core uses the following command:
* CASTOR: `smc -e -V vid`
* CTA: `cta-smc -e -V vid`
Please note that (as of May 2019) the `tape-eject` script is yet to be ported to CTA.
## Deleting tape from inventory
Once the tape was physically removed from the tape library, it can then be deleted from the inventory. This is done using the following command:
* CASTOR: `vmgrdeletetape`
* CTA: `cta-admin tape rm`
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment