Múltiples clústeres de QueryGrid Manager - Teradata QueryGrid

Teradata® QueryGrid™ Guía de instalación y uso- 3.00

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
Lake
VMware
Product
Teradata QueryGrid
Release Number
3.00
Published
Marzo de 2023
Language
Español
Last Update
2023-04-04
dita:mapPath
es-ES/dtm1676313130103.ditamap
dita:ditavalPath
ft:empty
dita:id
B035-5991
Product Category
Analytical Ecosystem

Los nodos de origen de datos se pueden administrar mediante hasta tres clústeres de QueryGrid Manager si se habilita la compatibilidad con múltiples clústeres de QueryGrid Manager. El servicio tdqg-node se conecta a múltiples clústeres de QueryGrid Manager para detectar los servicios de QueryGrid que se implementarán en los nodos. Al habilitar la compatibilidad con múltiples clústeres de QueryGrid Manager, un ecosistema puede comunicarse entre clústeres y orígenes de datos sin las complicaciones de crear silos entre clústeres.

Al habilitar la compatibilidad con varios clústeres de QueryGrid Manager, se define un clúster principal y los demás clústeres se consideran secundarios. El clúster principal se utiliza para determinar la configuración global, como la versión del servicio tdqg-node, que debe ser la versión 02.11 o una posterior. La versión del servicio tdqg-node de origen de datos no puede ser superior a la versión de cualquier QueryGrid Manager de los clústeres. Hay dos maneras de agregar los orígenes de datos a varios clústeres de QueryGrid Manager:
  • Instalación automática: permite agregar el clúster de QueryGrid Manager actual como el nuevo clúster principal o secundario sin quitarlo de los clústeres existentes.
  • Importación de sistema: permite agregar un nuevo clúster de QueryGrid Manager como clúster principal o secundario mediante la importación del sistema y los nodos de otro clúster de QueryGrid Manager. Está disponible como herramienta de línea de comandos o en el portlet QueryGrid de Viewpoint.

Casos de uso

Una de las principales razones para mantener varios clústeres es mantener un clúster de desarrollo independiente de un clúster de producción. Un origen de datos de producción o desarrollo puede formar parte del clúster de producción y desarrollo. Esto permite que el sistema de desarrollo se inicialice con datos de producción sin dejar de mantener entornos separados. Otra razón para tener varios clústeres es mantener el clúster interno de Full Vantage aislado de la implementación del ecosistema de QueryGrid Manager, al tiempo que permite que Analytics Database pertenezca tanto al clúster interno de Vantage como al clúster de ecosistemas.

Consideraciones de uso

Cuando un sistema forma parte de varios clústeres de QueryGrid Manager, los números de puerto de tejido y los nombres de enlace que implican ese sistema deben ser únicos entre los clústeres. Cuando QueryGrid Manager detecta conflictos de nombre de puerto o enlace de tejido, esos conflictos se notifican como un problema en el portlet QueryGrid de Viewpoint.

Cuando hay un conflicto, el tejido o el enlace que han estado en existencia por más tiempo tienen prioridad. Esto ayuda a evitar que los nuevos cambios interrumpan la funcionalidad de trabajo.

Para resolver un conflicto, cambie el número de puerto o el nombre del enlace en conflicto en uno de los clústeres. Recuerde también actualizar la definición del servidor externo después de cambiar el nombre del enlace.

Todos los nodos dentro de un sistema deben tener el mismo clúster principal. Es posible que los nodos difieran en lo que es el clúster principal en función de la configuración del nodo local. Cuando esto ocurre, se notifica un problema en el portlet QueryGrid. El clúster principal también aparece en la sección de nodo y los detalles del nodo del portlet QueryGrid. Para establecer el clúster principal de un sistema, utilice el comando set-primary.sh.