Domina herramientas y mejores prácticas de DevOps - DevOps Knowledge Hub Domina herramientas y mejores prácticas de DevOps - DevOps Knowledge Hub

Guía paso a paso para configurar un clúster básico de tres nodos

Aprenda a configurar rápidamente un clúster de Elasticsearch básico y resistente de tres nodos. Este tutorial paso a paso cubre la configuración esencial en `elasticsearch.yml`, el arranque del descubrimiento del clúster usando `cluster.initial_master_nodes`, el inicio de los servicios y la verificación del estado y la replicación de fragmentos entre los nodos usando comandos prácticos de cURL.

Guía paso a paso para configurar un clúster básico de tres nodos

Un clúster de Elasticsearch de tres nodos es la forma más pequeña que consideraría un clúster real en lugar de un laboratorio. Puede elegir un maestro por mayoría, mantener las réplicas alejadas de los primarios y sobrevivir a la pérdida de un nodo si los datos y los roles están configurados de manera sensata. Aún así no es magia. Tres máquinas virtuales pequeñas con discos llenos no se comportarán como una plataforma de búsqueda resistente solo porque sean tres.

Esta guía utiliza un diseño moderno básico de Elasticsearch: tres nodos, todos elegibles como maestro y capaces de manejar datos, en direcciones de red privadas. Ese es un punto de partida razonable para un entorno pequeño. Las implementaciones de producción más grandes a menudo separan nodos maestros dedicados, niveles de datos, nodos de ingesta, nodos de aprendizaje automático y nodos solo de coordinación. Comience de manera simple aquí, luego divida los roles cuando la carga de trabajo lo justifique.

Los ejemplos asumen hosts Linux e instalaciones de paquetes o archivos. Ajuste los comandos de servicio para su entorno.

Antes de editar la configuración

Necesita tres hosts o máquinas virtuales separadas. No ponga tres "nodos" en una computadora portátil y lo llame altamente disponible. Pueden ser útiles para probar el descubrimiento, pero comparten el mismo dominio de falla.

Cada host necesita:

  • La misma versión de Elasticsearch.
  • Una IP privada estable o un nombre DNS.
  • Conectividad de transporte entre nodos en el puerto 9300 por defecto.
  • Acceso HTTP en el puerto 9200 desde su host de administración o balanceador de carga, si es necesario.
  • Suficiente disco para fragmentos primarios y réplicas.
  • Sincronización de tiempo a través de NTP o un servicio similar.
  • Una ruta de datos configurada en almacenamiento local o adjunto confiable.

Las distribuciones recientes de Elasticsearch incluyen un JDK incluido. Si su empaquetado o versión requiere un JDK externo, use la versión de Java compatible para esa versión de Elasticsearch en lugar de adivinar.

Use direcciones privadas en discovery.seed_hosts. Evite IPs públicas a menos que tenga un diseño muy específico y controles de red sólidos.

Para esta guía, los nodos son:

node-1  10.0.10.11
node-2  10.0.10.12
node-3  10.0.10.13

Configurar ajustes comunes del clúster

En cada nodo, edite elasticsearch.yml. La ubicación del archivo depende del método de instalación. Las instalaciones de paquetes comúnmente usan /etc/elasticsearch/elasticsearch.yml; las instalaciones de archivos usan config/elasticsearch.yml bajo el directorio extraído.

Establezca el mismo nombre de clúster en los tres nodos:

cluster.name: my-three-node-cluster

Establezca los hosts de semilla de descubrimiento en los tres nodos:

discovery.seed_hosts:
  - 10.0.10.11:9300
  - 10.0.10.12:9300
  - 10.0.10.13:9300

Establezca los nodos maestros iniciales solo para el primer arranque:

cluster.initial_master_nodes:
  - node-1
  - node-2
  - node-3

Los valores deben coincidir con node.name, no con direcciones IP, a menos que los nombres de sus nodos sean cadenas similares a IP. Esta configuración es solo para formar un clúster completamente nuevo. Después de que el clúster se haya formado con éxito, elimine cluster.initial_master_nodes de todos los nodos y manténgalo fuera de futuros reinicios. Dejarlo puede causar confusión durante la recuperación de desastres o intentos de rearranque accidentales.

Enlace a la interfaz privada o un valor de host seguro:

network.host: 10.0.10.11
http.port: 9200
transport.port: 9300

Use la propia IP de cada nodo para network.host. 0.0.0.0 es conveniente en ejemplos, pero en producción puede exponer Elasticsearch en interfaces que no pretendía. Si la configuración automática de seguridad está habilitada en su versión, también deberá tener en cuenta los certificados TLS, la inscripción y la autenticación.

Configurar el nombre de cada nodo

En el nodo 1:

node.name: node-1
network.host: 10.0.10.11
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

En el nodo 2:

node.name: node-2
network.host: 10.0.10.12
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

En el nodo 3:

node.name: node-3
network.host: 10.0.10.13
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

Si ejecuta varios nodos en una máquina para una prueba, use valores separados de path.data y path.logs. Para clústeres reales, un nodo por host suele ser el modelo más limpio.

Elegir roles de nodo

Para un clúster pequeño de tres nodos, los tres nodos pueden llevar los roles estándar:

node.roles: [ master, data, ingest, remote_cluster_client ]

Esto le da tres nodos elegibles como maestro, por lo que la elección del maestro funciona por mayoría. Con tres nodos elegibles como maestro, el clúster puede perder uno y aún así elegir o mantener un maestro. Si faltan dos, no puede tomar decisiones seguras sobre el estado del clúster.

Para un clúster más grande, los nodos dedicados elegibles como maestro suelen ser mejores porque el trabajo pesado de datos o ingesta no puede privar a las funciones del maestro. Eso es un refinamiento de escalado, no un requisito para esta configuración básica.

Verificar los conceptos básicos del sistema operativo y la red

Antes de iniciar Elasticsearch, pruebe la conectividad de transporte entre cada par de nodos:

nc -vz 10.0.10.11 9300
nc -vz 10.0.10.12 9300
nc -vz 10.0.10.13 9300

Ejecute esos desde cada nodo cuando sea posible. Los firewalls y los grupos de seguridad en la nube deben permitir el tráfico de transporte de nodo a nodo. El puerto HTTP 9200 es para clientes y llamadas de administración; el puerto de transporte 9300 es lo que los nodos del clúster usan para comunicarse entre sí.

También verifique la propiedad de los archivos en los directorios de datos y registros. El proceso de Elasticsearch debe poder escribir en ambos.

Iniciar los nodos

Para instalaciones de paquetes con systemd:

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch
sudo journalctl -u elasticsearch -f

Para instalaciones de archivos durante las pruebas:

bin/elasticsearch

Inicie los tres nodos. No tienen que iniciarse en un orden perfecto, pero observe los registros. Quiere ver que el clúster se forme una vez y que los nodos se unan a él. Si un nodo dice que no puede descubrir un maestro, concéntrese en node.name, cluster.name, discovery.seed_hosts, la conectividad de transporte y la configuración de TLS/seguridad.

Una vez que el clúster se forme, elimine cluster.initial_master_nodes de la configuración de cada nodo y reinicie más tarde durante una ventana planificada si es necesario. No lo elimine mientras aún está intentando arrancar por primera vez.

Verificar el estado del clúster

Desde un host que pueda alcanzar el puerto 9200:

curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

Un clúster nuevo sin índices de usuario puede mostrar verde con cero fragmentos. Los campos a verificar son status, number_of_nodes y number_of_data_nodes.

Para una vista compacta:

curl -s "http://10.0.10.11:9200/_cat/health?v"

Luego verifique la membresía de nodos:

curl -s "http://10.0.10.11:9200/_cat/nodes?v&h=ip,name,roles,master,cpu,heap.percent,ram.percent,disk.used_percent"

Debería ver los tres nodos. Un nodo tendrá el marcador de maestro elegido. Los tres deberían mostrar los roles que espera.

Crear un índice de prueba con réplicas

Cree un índice de prueba para confirmar la ubicación de los fragmentos:

curl -X PUT "http://10.0.10.11:9200/test-data-index?pretty"   -H 'Content-Type: application/json'   -d '{
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    }
  }'

Verifique los fragmentos:

curl -s "http://10.0.10.11:9200/_cat/shards/test-data-index?v"

Con tres fragmentos primarios y una réplica, debería ver seis copias de fragmentos distribuidas entre los nodos. Elasticsearch evitará colocar una réplica en el mismo nodo que su primario.

Si el clúster está amarillo, pregunte por qué:

curl -X GET "http://10.0.10.11:9200/_cluster/allocation/explain?pretty"   -H 'Content-Type: application/json'   -d '{}'

Las causas comunes son no tener suficientes nodos de datos elegibles, marcas de agua de disco, asignación deshabilitada o reglas de conciencia de asignación que no coinciden con sus atributos de nodo.

Probar el comportamiento ante falla de un nodo

En una prueba que no sea de producción, detenga un nodo:

sudo systemctl stop elasticsearch

Verifique el estado desde otro nodo:

curl -s "http://10.0.10.12:9200/_cluster/health?pretty"

El clúster aún debería tener un maestro porque dos de los tres nodos elegibles como maestro permanecen. Dependiendo del tiempo, la reubicación de fragmentos y la colocación de réplicas, el estado puede ser verde o amarillo mientras Elasticsearch reacciona. Inicie el nodo nuevamente y observe la recuperación:

sudo systemctl start elasticsearch
curl -s "http://10.0.10.12:9200/_cat/recovery?v&active_only=true"

Esta prueba vale la pena hacerla antes de que el clúster sea importante. Le enseña cómo se ve una recuperación normal, para que un incidente real sea menos sorprendente.

Algunas barreras de seguridad de producción

Habilite y comprenda la seguridad para su versión de Elasticsearch. No exponga una API HTTP no autenticada a Internet o a una red interna amplia.

Realice instantáneas antes de depender del clúster. Las réplicas protegen contra la pérdida de nodos; las instantáneas protegen contra la eliminación, corrupción y errores operativos.

Monitoree el uso del disco, la presión del montón JVM, el recuento de nodos, el estado del clúster, las tareas pendientes y el éxito de las instantáneas. Un clúster de tres nodos es resistente solo si tiene suficiente capacidad para recuperarse.

Mantenga modestos los recuentos de fragmentos. Muchos fragmentos pequeños crean sobrecarga. Un clúster básico puede verse abrumado por miles de índices pequeños incluso cuando el volumen de datos no es grande.

Finalmente, documente la configuración de arranque y elimine cluster.initial_master_nodes después de la formación. La mayoría de los problemas de configuración de tres nodos provienen de pequeñas discrepancias: nombres de nodos que no coinciden con los nombres de arranque, puertos de transporte bloqueados, directorios de datos reutilizados de clústeres antiguos o suposiciones sobre los valores predeterminados de seguridad. Verifique esos primero antes de cambiar configuraciones más exóticas.

Notas de seguridad para versiones actuales de Elasticsearch

Muchas instalaciones modernas de Elasticsearch habilitan funciones de seguridad durante la configuración. Eso significa que las llamadas HTTP pueden requerir HTTPS, un certificado CA y credenciales. Si su clúster se configuró automáticamente con TLS, una verificación de estado puede verse más así:

curl --cacert /etc/elasticsearch/certs/http_ca.crt \
  -u elastic \
  https://10.0.10.11:9200/_cluster/health?pretty

No deshabilite la seguridad solo para que funcione un comando de tutorial. En su lugar, ajuste los ejemplos para sus rutas de certificados y cuentas de servicio. Para producción, cree usuarios nombrados o claves API con los privilegios que necesitan en lugar de usar el superusuario integrado para el trabajo diario.

El TLS de transporte también puede afectar la unión de nodos. Si los nodos no pueden unirse y los registros mencionan confianza de certificados, discrepancia de SAN, fallo de handshake o errores de transporte remoto, verifique los certificados antes de cambiar la configuración de descubrimiento. Una lista perfecta de discovery.seed_hosts no ayudará a los nodos que se rechazan mutuamente durante el handshake TLS.

Fallos comunes de inicio

Si los nodos no forman un clúster, verifique primero las cosas simples.

cluster.name debe coincidir en todos los nodos. Un nodo con un nombre de clúster diferente no se unirá solo porque aparece en la lista de hosts de semilla.

node.name debe coincidir con los valores utilizados en cluster.initial_master_nodes durante el primer arranque. Si la configuración dice node-1 pero el arranque lista es-node-1, el descubrimiento puede estancarse.

El puerto de transporte debe ser accesible entre nodos. El acceso HTTP en 9200 no es suficiente. Use nc, inspección de grupos de seguridad o capturas de paquetes si es necesario.

Los directorios de datos no deben contener metadatos de un clúster antiguo a menos que tenga la intención de unirse exactamente a ese clúster. Reutilizar un disco de una prueba anterior puede producir errores confusos sobre UUIDs de clúster o arranque inseguro.

La memoria y las comprobaciones de arranque son importantes al enlazar a una dirección que no sea de bucle local. Elasticsearch puede aplicar comprobaciones para descriptores de archivos, memoria virtual, bloqueo de memoria y configuración de descubrimiento. Lea el registro de inicio en lugar de reintentar a ciegas.

Después de que el clúster esté funcionando

Cree un repositorio de instantáneas antes de que el clúster lleve datos importantes. Las réplicas no son copias de seguridad. Una mala eliminación, error de mapeo o error de aplicación se replicará rápidamente a cada copia.

Registre los nombres de nodos, IPs, roles, rutas de datos, ubicaciones de certificados e historial de arranque en su runbook. Durante una interrupción, nadie quiere ingeniería inversa para saber si node-2 se supone que es elegible como maestro.

Configure alertas para pérdida de nodo, estado rojo, estado amarillo prolongado, marcas de agua de disco, presión del montón JVM, instantáneas fallidas y elecciones de maestro frecuentes. Un clúster de tres nodos le da espacio para sobrevivir a una falla, pero solo si nota y repara antes de la segunda falla.

Planifique la capacidad teniendo en cuenta la recuperación. Si cada nodo funciona con un uso de disco muy alto, perder un nodo puede dejar muy poco espacio para que las réplicas se reconstruyan. Los clústeres saludables necesitan capacidad de repuesto, no solo suficiente espacio para los primarios de hoy.

Práctica de reinicio gradual

Practique un reinicio gradual antes de necesitar uno para una actualización de paquete. Reinicie un nodo, espere a que se reincorpore, confirme el estado y la recuperación, luego pase al siguiente nodo. No reinicie los tres nodos a la vez a menos que esté haciendo intencionalmente un apagado completo del clúster.

Una secuencia simple es:

sudo systemctl restart elasticsearch
curl -s "http://10.0.10.11:9200/_cat/nodes?v"
curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

Si el clúster tiene fragmentos grandes, considere si la asignación retrasada debe ajustarse antes de los reinicios planificados. El objetivo es evitar la reconstrucción innecesaria de réplicas cuando un nodo volverá en unos minutos. Después del mantenimiento, verifique que la asignación esté habilitada y que se eliminen las configuraciones temporales.

También pruebe el comportamiento del cliente. Las aplicaciones deben usar más de un punto final de Elasticsearch o un balanceador de carga que elimine los nodos fallidos. Un clúster de tres nodos ayuda solo si los clientes pueden alcanzar los nodos restantes saludables cuando un nodo está caído.

Un último hábito ayuda: mantenga una copia del elasticsearch.yml final para cada nodo en la gestión de configuración. Las ediciones manuales realizadas durante la configuración tienden a desviarse, y la desviación es exactamente lo que hace que el próximo reemplazo de nodo sea más difícil de lo necesario.