Autor: Francisco

Notas técnicas variadas sobre Vertica: cómo consultar la configuración de balanceo de carga entre nodos, cómo listar los nodos del clúster, y recomendaciones actualizadas de hardware para dimensionar un clúster nuevo.

1. Ver el tipo de balanceo de carga configurado

SELECT currentclientbalancingpolicy FROM vs_global_settings;

SELECT currentclientbalancingpolicy FROM vs_global_settings;

Vertica, al ser un motor distribuido (MPP), puede repartir las conexiones de clientes entre los distintos nodos del clúster de varias formas. Las políticas típicas que puede devolver esta consulta son:

• NONE — sin balanceo; el cliente siempre se conecta al nodo especificado explícitamente en la cadena de conexión.
• ROUNDROBIN — reparte las conexiones entrantes de forma secuencial entre todos los nodos disponibles, en turnos.
• RANDOM — asigna cada conexión nueva a un nodo elegido al azar entre los disponibles.

El balanceo de carga a nivel de conexión evita que todos los clientes se concentren en un solo nodo (normalmente el nodo inicial/coordinador), distribuyendo la carga de sesiones activas de forma más pareja entre todo el clúster.

2. Ver los nodos del clúster

SELECT node_name, node_address FROM nodes;

SELECT node_name, node_address FROM nodes;

La tabla de catálogo nodes es la referencia base para saber qué nodos componen el clúster y su dirección de red asociada. Para un diagnóstico más completo del estado de cada nodo (no solo su existencia), conviene ampliar la consulta:

SELECT node_name, node_address, node_state, node_type
FROM nodes;

SELECT node_name, node_address, node_state, node_type
FROM nodes;

node_state revela si el nodo está UP, DOWN, o en otro estado de transición — información crítica antes de asumir que el clúster completo está sano solo porque la consulta a nodes devolvió resultados (un nodo puede seguir apareciendo en el catálogo aunque esté caído).

Recomendaciones de hardware para Vertica

Memoria RAM

Referencia oficial: Vertica Generic Hardware Guide.

Alta disponibilidad: mínimo de nodos

Para tolerar la falla de un solo nodo sin que la base de datos completa quede inaccesible, la recomendación oficial es un mínimo de 3 nodos en el clúster — con menos de eso, la pérdida de un nodo puede dejar el clúster sin quórum suficiente para seguir operando.

Ejemplo en AWS EC2

Para una instancia c3.4xlarge (8 vCPUs), se recomiendan al menos 64–96 GB de RAM, siguiendo la misma proporción de GB por núcleo. Referencia: AWS EC2 Virtual Cores.

Consideraciones adicionales de CPU

Vertica es un motor particularmente sensible a la velocidad de reloj del procesador (CPU-bound), más que a la cantidad bruta de núcleos. Cuando se debe elegir entre un procesador más rápido con menos núcleos, o uno más lento con más núcleos, generalmente conviene priorizar la velocidad de reloj — más núcleos ayudan principalmente a que el clúster procese varias consultas y cargas de datos en paralelo, pero no aceleran una consulta individual tanto como un reloj más rápido.

Homogeneidad del hardware entre nodos

Se recomienda que todos los nodos del clúster tengan una configuración de hardware similar (CPU, velocidad de reloj, núcleos, memoria, versión de sistema operativo). Vertica no está probado oficialmente sobre clústeres con hardware heterogéneo — funcionalmente puede operar así, pero el rendimiento general del clúster queda limitado al del nodo más lento.

Resumen práctico

• Antes de dar por sano un clúster, verificar tanto la existencia de los nodos (SELECT * FROM nodes) como su estado real (node_state = 'UP').
• Al dimensionar hardware nuevo, partir de la regla de 8–12 GB de RAM por núcleo físico como mínimo razonable, ajustando hacia arriba según la intensidad de la carga analítica esperada.
• Mantener el hardware homogéneo entre todos los nodos del mismo clúster para evitar cuellos de botella causados por el nodo más débil.
• Nunca desplegar un clúster productivo con menos de 3 nodos si la alta disponibilidad es un requisito.