Asignación de nodos de Elasticsearch específicos a entornos de creación y producción
Puede encontrarse con problemas de rendimiento cuando los entornos de creación y producción comparten el mismo conjunto de nodos de Elasticsearch. Para evitar esto, puede asignar a los servidores roles específicos en un entorno u otro.
Un clúster de Elasticsearch consta de nodos que tienen roles de nodo diferentes, incluidos un nodo elegible maestro, un nodo de datos, un nodo de introducción, un nodo elegible remoto y un nodo de aprendizaje automático. El nodo elegible maestro es responsable del funcionamiento en todo el clúster, como la creación y supresión de índices, el seguimiento de nodo y la asignación de particiones. Es crucial tener un nodo maestro estable para mantener el estado del clúster.
En la implementación de clúster de Elasticsearch predeterminada HCL Commerce, todos los nodos tienen todos los roles de nodo. Si un nodo está ocupado en operaciones de datos y bajo restricciones de recursos mientras también tiene el rol maestro, puede afectar al estado del clúster, que a su vez afecta a la disponibilidad de los datos.
Tanto los entornos de creación como los entornos reales comparten el mismo conjunto de nodos de Elasticsearch para las consultas de datos e Ingest. El tráfico del sitio activo podría verse afectado negativamente por las operaciones de introducción realizadas en el entorno de creación.
Es importante tener en cuenta que en la configuración predeterminada todas las instancias de Commerce combinan los entornos de creación y los entornos reales en un entorno de datos común. Para reducir los retrasos durante la actualización del índice a nivel de escaparate, puede utilizar en su lugar un grupo de nodos de Elasticsearch dual, tal y como se describe en Diseño de un entorno de Elasticsearch con un grupo de nodos dual.
Por estos motivos, es útil asignar nodos de Elasticsearch específicos para los roles maestro y de datos en entornos de creación y en entornos reales. Este documento describe una configuración de ejemplo de un solo nodo en Google Cloud Platform (GCP) utilizando ElasticSearch 7.12.1. Modifíquelo para que se ajuste a sus necesidades.
El diagrama siguiente muestra un ejemplo en el que se han creado dos agrupaciones de nodo diferentes. Para cada agrupación de nodo, se ha implementado un clúster de Elasticsearch para AUTH, LIVE y MASTER. 
- nodegroup
- Convención de nomenclatura de Elasticsearch para asignar servidores de forma lógica a un grupo. Esta asignación lógica se utiliza en los archivos yaml para crear un authpod, livepod y un grupo de masterpod de nodos de Elasticsearch.
- Agrupación de nodos gke
- Agrupación de nodos GKE (máquinas virtuales) que kubernetes puede utilizar para dar soporte a los motores de cálculo de clústeres. Estos grupos se definen durante la creación del clúster GKE y los archivos yaml de ejemplo utilizarán o harán referencia a ellos bajo las propiedades
nodeSelectorutilizando la propiedad: cloud.google.com/gke-nodepool.
node.attr.env que ayuda a definir su rol de Commerce, como en los entornos AUTH o LIVE del clúster. Más información disponible en el archivo yaml también define los roles de Elasticsearch de cada implementación: maestro, archivo de introducción o datos. Para obtener más información sobre las propiedades y los valores que se pueden utilizar en los archivos yaml, consulte: Gráfico de Helm de Elasticsearch en el gráfico de Helm Elastic oficial para obtener documentación de Elasticsearch. Juntos estos valores, junto con los "roles" proporcionados en el archivo yaml, ayudan a definir la configuración que se muestra en el diagrama. Posteriormente, las plantillas utilizan node.attr.env para ayudar a definir los índices que se van a almacenar en cada grupo de nodos.Para obtener información detallada sobre cómo implementar esta configuración, abra un caso con elsoporte de HCL Commerce.