Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

Guarding a Teradata Database Device

Initialize and Guard the Database Devices Using the Standard Initialization Method

search

Please Note:

Initialize and Guard the Database Devices Using the Standard Initialization Method

The following procedure describes how to perform the initial configuration of your database devices using the Standard Initialization Method. This procedure encrypts the existing data in place and does not require you to backup your Teradata database when initially deploying CTE. It may, however, take several hours, or even days, to complete depending on the volume of data, the number of database devices and nodes, and the bandwidth of the storage back-end of database devices.

Warning

For each device, you must designate one and only one of the nodes in the cluster as the initial node. This is the node on which you plan to initialize and guard the device for the first time. The designated node must be the only one that guards the device until the entire initial data transformation process has completed. DO NOT initialize or guard any device on multiple nodes in the cluster simultaneously, because multiple nodes attempting to transform the same data can corrupt the data on the entire device.

  1. Shut down the Teradata Database. You cannot initialize an online database device.

  2. For each device, designate one of the nodes in the cluster as the initial node that you will use for the initial data transformation when the device is guarded for the first time.

  3. Log into the designated node in the Teradata Database Appliance. Type:

     voradmin idt config [ external] [new|xform] [-c <n>] <device-name>

    • [new|xform] (required)

      Indicates whether data already exists on the device. If the device contains no data, specify new. If the device contains data that you want to keep, specify xform. Most installations of Teradata Appliance are expected to have pdisks populated with data, therefore, most often you will use the xform option. When you use xform, CTE will transform all existing data on the device from clear-text to cipher-text as soon as you guard the device on the Appliance. The device will be inaccessible until the transformation is complete, and the device must remain offline to the Teradata Database service during the entire transformation process. No user access will be permitted until all of the data has been transformed.

    • -external (required)

      You must use this option when initializing any Teradata device. With this option, CTE writes the CTE Private Region to a metadata file located in the CTE metadata directory. For details, see Location of the CTE Private Region.

    • -c <n> (optional)

      If you use this option, CTE sets the number of data transformation jobs to run in parallel to the number specified in <n>. <n> can be an integer between 1 and 60, (default: 8).

      Each data transformation job transforms 1MB worth of data and requires CPU resources in addition to three I/O operations as part of data transformation. Each job reads 1MB of data from the device, preserves the data in the CTE private region, rekeys the data to cipher-text, and writes the transformed data to the device. If you increase the number of parallel jobs, the data transformation process will complete faster but there will be an increased performance impact on the system. Only increase the -c option if you are certain that the system resources are available to handle the additional load.

      The value for the -c option you specify here remains in effect for all subsequent data transformations (such as any data rekeys) until you specify a new value.

    • <device-name> (required)

      The name of the Teradata Database device that you want to initialize.

      For example:

      voradmin idt config -external xform -c 20 \
/dev/disk/by-id/tdmp-360080e500043092c0000b46f5c34c018-part3

  4. Repeat the voradmin idt config command for each device that you want to initialize. If you want to distribute the initial data transformation or subsequent rekey load on all of the disks across all the nodes in the cluster, make sure that you run the voradmin idt config command for each device on the node you designated for data transformation, excluding the HSN node. The node on which you run the voradmin idt config command is the node that performs the data transformation on the device. Do not designate the HSN node for data transformation because the devices on the HSN node may be reserved and therefore not available for IO operations.

Guard the Devices as IDT-Capable GuardPoints

Warning

For each device, you must designate a node in the cluster as the initial node on which you plan to initialize and guard the device for the first time. The designated node must be the only one that accesses the device until the entire initial data transformation process has completed. This requires guarding each device at the designated client level rather than at the client group level. DO NOT initialize or guard any device on multiple nodes in the cluster simultaneously, because multiple nodes attempting to transform the same data can corrupt the data on the entire device.

To create an IDT GuardPoint:

  1. On the GuardPoints tab, click Create GuardPoint.

  2. Select a Policy. This is a mandatory field.

    1. Click Select next to the Policy field.

    2. Select an In-place Data Transformation policy. If no policy exists, create one, as described in Creating Policies.

    3. Click Select.

    Note

    When an IDT policy is selected, the read-only In-place Data Transformation toggle is displayed on the Create GuardPoint dialog box.

  3. Select the Type of device to protect. This is a mandatory field. The options for a In-place Data Transformation policy are:

    Type Description
    Auto Raw or Block Device Select for IDT policies for raw (block) devices.
    Manual Raw or Block Device Select for IDT policies for raw (block) devices to be guarded manually.

    Note

    Manual Raw or Block Device are guarded and unguarded (for example, mounted and unmounted) by running the secfsd -guard and secfsd -unguard commands. Do not run the mount and umount commands to swap GuardPoint nodes in a cluster configuration.

  4. Specify the Path to be protected. This is a mandatory field. Options to specify the GuardPoint paths are:

    • Enter/Browse Path: Select this option, and enter the GuardPoint paths by either typing or clicking the Browse button.

    Note

    A maximum of 200 GuardPaths can be specified using the Enter/Browse Path option.

    • Click Browse to select a path by browsing the client file system. This method prevents typographical errors and verifies client availability. This is the recommended method to specify individual paths.

    File system of a client that is not registered with the CipherTrust Manager cannot be browsed.

    • Alternatively, if you know the path, manually enter full paths of one or more directories in the given text box. Enter one path per line.

  5. Make sure the In-place Data Transformation option is selected.

  6. Click Create. A message appears prompting to confirm the reuse of these GuardPoint settings on another path.

    • Click Yes to use the same settings on another path. The Use Settings on Another Path dialog box is displayed. Perform the following steps:

      1. Specify a new Path.

      2. Click Add Path. The newly added path appears under the Paths list on the left. Similarly, add as many paths as required.

      3. Click OK.

    • Click No if you do not want to use the same settings on another path.

    CipherTrust Manager pushes the policy and the GuardPoint configuration to the node in the cluster. The CTE agent on the node writes the IDT Device Header into the CTE Private Region in the local CipherTrust Transparent Encryption metadata directory on the node.

    If this is a new device, the status immediately changes to guarded. If there is existing data on the device, CTE begins transforming the data from clear-text to cipher-text as soon as the GuardPoint configuration is available and the device status changes to guarded. The device will remain inaccessible until this data transformation completes. The length of time required to transform the data depends on the amount of existing data and the number of parallel data transformation jobs specified on the voradmin config command. To see the data transformation progress, use the voradmin idt xform status <device-name> command, as described in Viewing Device and Data Transformation Status.

    Devices with existing data are transformed from clear-text to cipher-text using the encryption key specified in the selected policy through the In-Place Data Transformation (CTE-IDT) process. For details on how CTE does data transformation on IDT GuardPoint, see CipherTrust in-Place Data Transformation for Linux. ccc

    After the device is initialized and guarded, the protected device must be accessed through the device pathname corresponding to the secvm device. For example, if you guard the Linux device /dev/disk/by-id/tdmp-360080e500043092c0000b46f5c34c018-part3, the pathname becomes /dev/secvm/dev/disk/by-id/tdmp-360080e500043092c0000b46f5c34c018-part3 as soon as the process is complete.

  7. After all of the Teradata Database devices have been guarded, disable the guarded IDT-GuardPoints on each designated node and then enable those GuardPoints at the Client Group level on all the nodes in the clique.

  8. After guarding your devices and before starting your database, you must change the current configuration of your cluster to reflect the status of the pdisk devices guarded as IDT GuardPoint. See the Rebuild Vconfig Only option of the Teradata Parallel Upgrade Tool (PUT) service to apply the guarded status of the pdisk devices into your database configuration. The Rebuild vconfig process applies the guarded configuration status of each pdisk and resets the pdisk symbolic link to the CipherTrust Transparent Encryption secvm device.

    Warning

    You must complete this step before starting your database. Failure to do so will result in database failures and potential corruption of your database.

    For example, the pdisk /dev/pdisk/dsk304 is linked to the secvm device after Rebuild Vconfig Only commits the guarded status of pdisk on each node: 

    # ls -l /dev/pdisk/dsk304  
lrwxrwxrwx 1 root root 70 May 18 12:21 /dev/pdisk/dsk304 -> /dev/secvm/dev/disk/by-id/tdmp-360080e500043092c0000b46f5c34c018-part

  9. After all of the Teradata Database devices have been guarded in the clique and the Rebuild Vconfig Only on TDput has been executed, start the Teradata Database, type: 

    # /etc/init.d/tpa start

Viewing Device and Data Transformation Status

After you guard a Teradata Database device, you can view the status of that device using the voradmin idt status [xform] <device-name> command, where:

  • xform (optional)

If you specify this option, CTE shows the status of any data transformation processes happening on the device. If you do not specify this option, CTE displays the IDT Device Header for the device.

  • <device-name> (required)

The name of the Teradata Database device that you want to initialize. This must be the actual device name and not the symbolic pdisk name.

For example, if you want to view the status of device /dev/disk/by-id/tdmp-360080e500043092c0000b46f5c34c018-part3, you would enter: 

 voradmin idt status /dev/disk/by-id/tdmp-360080e500043092c0000b46f5c34c018-part3

If you want to check the data transformation progress on the device /dev/disk/by-id/tdmp-360080e500043092c0000b46f5c34c018-part3, you would enter:

 voradmin idt status xform \
      /dev/disk/by-id/tdmp-360080e500043092c0000b46f5c34c018-part3

The Status field displays In-Progress if a data transformation process is running, and Completed if the process has finished.

On this page