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.
- 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.