17.10 - Descripción general de los componentes de Teradata Data Mover - Teradata Data Mover

Teradata® Data Mover Guía del usuario

Product
Teradata Data Mover
Release Number
17.10
Release Date
Junio de 2021
Content Type
Guía del usuario
Publication ID
B035-4101-061K-ESN
Language
Español (España)
En la siguiente figura se muestran los principales componentes de Data Mover:
  • El Daemon de Data Mover
  • El agente de Data Mover
  • Las interfaces de usuario:
    • Gráfico (portlet Data Mover)
    • Línea de comandos
    • API RESTful
Al especificar las acciones de trabajo mediante una de las interfaces, el daemon de Data Mover genera pasos del trabajo. A continuación, el daemon de Data Mover distribuye las tareas para cada paso del trabajo entre los agentes de Data Mover, que ejecutan las tareas del trabajo. Data Mover está configurado para notificar el estado del trabajo a Teradata Ecosystem Manager, que puede supervisar y controlar trabajos de Data Mover.
Componentes de Data Mover
Componentes de Data Mover, que muestran la arquitectura y el flujo de movimiento de datos entre sistemas de origen y de destino.

Opciones de implementación de Data Mover

Data Mover se puede implementar utilizando las siguientes plataformas:
  • Servidor de usos múltiples de Teradata (TMS)
  • Máquina virtual en un servidor de usos múltiples de Teradata consolidado (CTMS)
  • Teradata Cloud (antes IntelliCloud)
  • Nube privada en máquina virtual
  • Amazon Web Services (AWS)
  • Microsoft Azure (Azure)
  • Google Cloud

Opciones de transferencia de datos de Data Mover

Data Mover admite la transferencia de datos entre los siguientes sistemas:
Del sistema Al sistema
Vantage local (IntelliFlex) Vantage local (IntelliFlex)
Vantage en la nube (pública o privada) Vantage en la nube (pública o privada)
Vantage local (IntelliFlex) Vantage en la nube (pública o privada)
Vantage en la nube (pública o privada) Vantage local (IntelliFlex)
Teradata Cloud Vantage en la nube (pública o privada)
Vantage en la nube (pública o privada) Teradata Cloud

Daemon de Data Mover

El componente principal de Teradata® Data Mover es el daemon de Data Mover, que puede hacer lo siguiente:

  • Procesa las solicitudes entrantes de una de las interfaces de Data Mover
  • Consulta sistemas Teradata Database para obtener información sobre objetos especificados
  • Genera un plan para copiar objetos desde el sistema de origen al sistema de destino, basado en las especificaciones de trabajo
  • Distribuye trabajo de cada tareas entre los agentes de Data Mover
  • Captura y almacena información de trabajo, como el plan de trabajo y los resultados generados por cada instancia de trabajo
  • Envía información de estado a Teradata Ecosystem Manager y a Server Management.

El daemon de Data Mover utiliza una versión reducida de Teradata Database para almacenar metadatos e información de los trabajos. Todas las comunicaciones entre el daemon de Data Mover y la interfaz de línea de comandos de Data Mover, los agentes de Data Mover u otros componentes externos se realizan a través del bus de Java Message Service (JMS). Todos los mensajes entre estos componentes están en formato XML.

Una de las tareas del daemon de Data Mover consiste en enviar información de estado del trabajo a Teradata Ecosystem Manager y Server Management, lo que permite que se notifiquen los errores críticos a Teradata inmediatamente. El daemon de Data Mover genera información de eventos de Teradata Ecosystem Manager para los trabajos iniciados con el portlet y las interfaces de línea de comandos y, a continuación, envía el estado a Teradata Ecosystem Manager si ese producto está presente y el usuario ha configurado Data Mover para ello.

Archivo de propiedades para el Daemon de Data Mover

El archivo daemon.properties contiene las propiedades de configuración del Daemon de Data Mover.

# Copyright (C) 2009-2021  by Teradata Corporation.
# All Rights Reserved.
# TERADATA CORPORATION CONFIDENTIAL AND TRADE SECRET
#----------------------------------------------------------------------------------------------
# File: "daemon.properties"
#
# Purpose: This file contains all of the properties used by the DM Daemon.
#
# Caution: Do not modify the property names/values in this file unless absolutely sure 
# of the implications to the DM Daemon.
#
# Note: Any line of text in this document that begins with a '#' character is a comment and 
# has no affect on the DM Daemon. However, comments should not be modified.
#
# All properties under LOGGING comment are used for logging purposes
#
#----------------------------------------------------------------------------------------------

# Purpose: The hostname or IP address of the machine running the 
# Java Message Service (JMS) Message Broker.
# Default: localhost
# Other examples include:
# broker.url=10.0.1.199
# broker.url=hostname
# broker.url=[fe80::114:23ff:fe1d:32fb]
broker.url=localhost

# Purpose: The port number on the machine in which the
# Java Message Service (JMS) Message Broker is listening.
# Default: 61616
broker.port=61616

# Purpose: When set to true, a connection to a 
# Secondary Java Message Service (JMS) Message Broker can be
# established in case the Primary Java Message Service (JMS) Broker fails.
# Default: false
cluster.enabled=false

# Purpose: The message time to live in milliseconds; zero is unlimited
# Be SURE to synchronize clocks of all dm hosts so messages do not expire unintentionally
# causing failed or hanging requests to Daemon.
# Default: 1 hr
jms.response.timetolive=3600000

# Purpose: A long-lived server port on the machine running the DM Daemon, which is used for inbound
# socket connections from DM Agents.  
# Default: 25168

# Purpose: When set to true, Fatal Error messages can be sent to TVI
# Default: true
tvi.useLogger=true

# Purpose: Scripts are used to run to collect TVI diagnostic bundles file. 
# DO NOT change this directory location.
tvi.diagnosticbundle.script.dir=/opt/teradata/datamover/support/diagnosticbundle

# Purpose: TVI diagnostic bundle files are saved to this directory
# This value need to be the same as SUPPORT_BUNDLE_DIR in /etc/opt/teradata/sm3g. sm3gnode.conf 
tvi.diagnosticbundle.dir=/var/opt/teradata/datamover/support/diagnosticbundle

# Purpose: The maximum number of jobs allowed to run on the daemon at the same time.
# Additional jobs are placed on the queue and executed when slots become available
# Default: 20
jobExecutionCoordinator.maxConcurrentJobs=20

# Purpose: The maximum number of jobs allowed in the job queue.
# Additional jobs are placed in a higher level memory queue until slots are available in the job queue.
# Default: 20
jobExecutionCoordinator.maxQueuedJobs=20

# Purpose: The hostname or IP address for the ViewPoint Authentication server.
# Default: http://localhost
viewpoint.url=http://dm-vp1

# Purpose: The port number for the ViewPoint Authentication server.
# Default: 80
viewpoint.port=80

# Purpose: The hostname and IP address for the Querygrid Manager servers.
# Support clustered QueryGrid managers, could have upto 2 urls, separate by comma.
# e.g querygrid.manager.urls=https://host1:9443,https://host2:9443
# Default: https://localhost:9443
querygrid.manager.urls=https://localhost:9443

#----------------------LOGGING-------------------------------

# Purpose: Set Logging level to info.  User has 6 options.  
# From most amount of logging to least: trace < debug < info < warn < error < fatal
rootLogger.level=info

# Purpose: Informs the logging application to use a specific appender and it's properties.  DO NOT CHANGE 
appender.rolling.type=RollingFile
appender.rolling.name=RollingFile
appender.rolling.layout.type=PatternLayout
appender.rolling.layout.pattern=%d [%t] %-5p %c{3}(%L) - %m%n
appender.rolling.policies.type=Policies
appender.rolling.policies.size.type=SizeBasedTriggeringPolicy
appender.rolling.strategy.type=DefaultRolloverStrategy
logger.rolling.name=com.teradata
logger.rolling.appenderRef.rolling.ref=RollingFile

# Purpose: Allow's user the ability to change the location of the log file.
# If changing log file location, please give the absolute path of the file;
# for example, /var/log/dmAgent.log
# for windows os: use slash instead of back slash: 
# For Example: C:/Program File/Teradata/Log/dmDaemon.log 
appender.rolling.fileName=/var/opt/teradata/datamover/logs/dmDaemon.log
appender.rolling.filePattern=/var/opt/teradata/datamover/logs/dmDaemon.log.%i

# Purpose: The max size of the logging file before being rolled over to backup files.
appender.rolling.policies.size.size=20MB
# Purpose: The number of backup logging files created, after the max number, the oldest file is erased.
appender.rolling.strategy.max=5

service_user=dmuser

# Purpose: Data Mover Rest Interface for DSA job status notification
dm.rest.endpoint=https://localhost:1443/datamover

# Purpose: DSA Rest Interface for DSA job status notification 
dsa.rest.endpoint=https://localhost:9090/dsa
#------------------------------------------------------------

Agente de Data Mover

El Daemon de Data Mover usa agentes de Data Mover para realizar las tareas de cada trabajo de Data Mover; por lo tanto, se requiere al menos un agente. Varios agentes pueden ejecutar tareas de forma simultánea, lo que mejora el rendimiento. Para maximizar el rendimiento, Teradata recomienda que cada agente resida en su propio servidor, independiente del servidor del daemon de Data Mover. Sin embargo, esto no es obligatorio. Un agente de Data Mover puede ejecutarse en el mismo servidor que el daemon de Data Mover.

El daemon de Data Mover divide el trabajo en tareas, que se ponen en una cola de JMS para el siguiente agente de Data Mover disponible. El agente de Data Mover utiliza una de las siguientes utilidades para llevar a cabo la tarea y, a continuación, espera su siguiente tarea de la cola:

  • Data Stream Architecture (DSA)
  • API de Teradata Parallel Transporter (TPT)
  • Controlador de Teradata JDBC
  • QueryGrid

Archivo de propiedades del agente de Data Mover

El archivo agent.properties contiene las propiedades de configuración del agente de Data Mover.

# Copyright (C) 2009-2021 by Teradata Corporation.
# All Rights Reserved.
# TERADATA CORPORATION CONFIDENTIAL AND TRADE SECRET
#----------------------------------------------------------------------------------------------
# File: "agent.properties"
#
# Purpose: This file contains all of the properties used by the DM Agent.
#
# Caution: Do not modify the property names/values in this file unless absolutely sure 
# of the implications to the DM Agent.
#
# Note: Any line of text in this document that begins with a '#' character is a comment and 
# has no affect on the DM Agent. However, comments should not be modified.
#
# All properties under LOGGING Comment are used for logging purposes
#
#----------------------------------------------------------------------------------------------

# Purpose: The Agent Identifier
# Default: Agent1
agent.id=Agent1

# Purpose: The hostname or IP address of the machine running the 
# Java Message Service (JMS) Message Broker.
# Default: localhost
broker.url=localhost

# Purpose: The port number on the machine in which the
# Java Message Service (JMS) Message Broker is listening.
# Default: 61616
broker.port=61616

# Purpose: When set to true, a connection to a 
# Secondary Java Message Service (JMS) Message Broker can be
# established in case the Primary Java Message Service (JMS) Broker fails.
# Default: false
cluster.enabled=false

# Purpose: Port that will be used by ARC
# Default: 25268

# Purpose: The maximum number of tasks allowed to run on this agent at the same time.
# This property has the side-effect of reducing parallelism among multiple Agents if
# set too high, because one Agent will grab all the tasks on the queue
# Default: 5
agent.maxConcurrentTasks=5

#When set to true, Fatal Error messages can be sent to TVI
tvi.useLogger=true

# Purpose: Scripts are used to run to collect TVI diagnostic bundles file. 
# DO NOT change this directory location.
tvi.diagnosticbundle.script.dir=/opt/teradata/datamover/support/diagnosticbundle

# Purpose: TVI diagnostic bundle files are saved to this directory
# This value need to be the same as SUPPORT_BUNDLE_DIR in /etc/opt/teradata/sm3g. sm3gnode.conf 
tvi.diagnosticbundle.dir=/var/opt/teradata/datamover/support/diagnosticbundle

#----------------------LOGGING-------------------------------

# Purpose: Set Logging level to info.  User has 6 options.  
# From most amount of logging to least: trace < debug < info < warn < error < fatal
rootLogger.level=info

# Purpose: Informs the logging application to use a specific appender and it's properties.  DO NOT CHANGE 
appender.rolling.type=RollingFile
appender.rolling.name=RollingFile
appender.rolling.layout.type=PatternLayout
appender.rolling.layout.pattern=%d [%t] %-5p %c{3}(%L) - %m%n
appender.rolling.policies.type=Policies
appender.rolling.policies.size.type=SizeBasedTriggeringPolicy
appender.rolling.strategy.type=DefaultRolloverStrategy
logger.rolling.name=com.teradata
logger.rolling.appenderRef.rolling.ref=RollingFile

# Purpose: Allow's user the ability to change the location of the log file.
# If changing log file location, please give the absolute path of the file;
# for example, /var/log/dmAgent.log
# for windows os: use slash instead of back slash: 
# For Example: C:/Program File/Teradata/Log/dmAgent.log 
appender.rolling.fileName=/var/opt/teradata/datamover/logs/dmAgent.log
appender.rolling.filePattern=/var/opt/teradata/datamover/logs/dmAgent.log.%i

# Purpose: The max size of the logging file before being rolled over to backup files.
appender.rolling.policies.size.size=10MB
# Purpose: The number of backup logging files created, after the max number, the oldest file is erased.
appender.rolling.strategy.max=3

service_user=dmuser
#------------------------------------------------------------

Portlet Data Mover

El portlet Data Mover le permite configurar, iniciar, editar y supervisar trabajos que copian objetos de base de datos entre los sistemas Teradata Database en una interfaz gráfica de usuario. Debido a que la interfaz para el portlet Data Mover es fácil de usar e intuitiva, puede realizar tareas de copia fácilmente con Data Mover si busca los objetos que desea copiar en la jerarquía de la base de datos del sistema de origen y crea una definición de trabajo. El portlet elimina la necesidad de editar archivos de parámetros XML o de recordar la sintaxis de comandos comunes. Para utilizar el portlet Data Mover, Teradata Viewpoint debe estar instalado.

Interfaz de línea de comandos

La interfaz de la línea de comandos proporciona comandos de configuración que permiten instalar y configurar el sistema de Data Mover, incluido el daemon, los agentes y los comandos de operaciones de trabajo para crear, ejecutar, supervisar, actualizar, editar y eliminar trabajos. Los comandos de configuración ofrecen funciones que se corresponden con las que proporciona el portlet de Configuración de Data Mover. Los comandos de administración de trabajo ofrecen funciones que se corresponden con las que proporciona el portlet de Data Mover. Para obtener una lista de comandos y parámetros válidos, consulte Acerca de los comandos de Data Mover.

Cada comando de la interfaz requiere un conjunto de parámetros para su funcionamiento, que se pueden enumerar como parte de los argumentos de la línea de comandos o especificar en un documento XML. Si el mismo parámetro se define en la línea de comandos y en el archivo XML, la línea de comandos tiene prioridad. Varias instancias de la interfaz de línea de comandos son válidas.

API RESTful

La API RESTful proporciona una funcionalidad similar a la interfaz de línea de comandos. Se puede acceder a la API RESTful desde cualquier servidor Teradata o de terceros mediante cualquier cliente estándar de REST. Las API proporcionan un método programático para crear, ejecutar, supervisar, actualizar, editar, detener, limpiar y eliminar trabajos. Para obtener más información, consulte API RESTful de Data Mover.