Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Selección de tipos de instancias y pruebas
Después de calcular sus requisitos de almacenamiento y elegir el número de particiones que necesita, puede comenzar a tomar decisiones sobre el equipo. Los requisitos del equipo varían enormemente en función de la carga de trabajo, pero aquí también ofrecemos algunas recomendaciones básicas.
En general, [los límites de almacenamiento](limits.md) para cada tipo de instancia se corresponden con la cantidad de CPU y memoria que podría necesitar para las cargas de trabajo. Por ejemplo, una instancia `m6g.large.search` tiene un tamaño de volumen de EBS máximo de 512 GiB, 2 núcleos de vCPU y 8 GiB de memoria. Si el clúster tiene muchas particiones, realiza un gran número de altas, actualiza documentos frecuentemente o procesa un gran número de consultas, esos recursos podrían ser insuficientes para sus necesidades. Si su clúster entra dentro de una de estas categorías, empiece con una configuración más cercana a 2 núcleos de vCPU y 8 GiB de memoria para cada 100 GiB de su requisito de almacenamiento.
**sugerencia**
Para ver un resumen de los recursos de hardware que se asignan a cada tipo de instancia, consulta los [precios OpenSearch de Amazon Service](https://aws.amazon.com/opensearch-service/pricing/).
Aun así, estos recursos podrían ser insuficientes. Algunos OpenSearch usuarios afirman que necesitan muchas veces esos recursos para cumplir sus requisitos. Para encontrar el equipo correcto para la carga de trabajo, debe realizar una estimación inicial fundamentada, probarla con cargas de trabajo representativas, ajustarla y probarla de nuevo.
## Paso 1: realizar una estimación inicial
Para empezar, recomendamos un mínimo de tres nodos para evitar posibles OpenSearch problemas, como un estado *cerebral dividido* (cuando un fallo en la comunicación provoca que un clúster tenga dos nodos maestros). Aunque tenga tres [nodos maestros dedicados](managedomains-dedicatedmasternodes.md), seguiremos recomendando que tenga un mínimo de dos nodos de datos para la replicación.
## Paso 2: calcular los requisitos de almacenamiento por nodo
Si tuviera un requisito de almacenamiento de 184 GiB y el número mínimo recomendado de tres nodos, usaría la ecuación 184 / 3 = 61 GiB para encontrar la cantidad de almacenamiento que necesita cada nodo. En este ejemplo, podría elegir tres instancias `m6g.large.search`, donde cada una con un volumen de almacenamiento de EBS de 90 GiB para no quedarse corto y tener un margen de crecimiento para el futuro. Esta configuración proporciona 6 núcleos de vCPU y 24 GiB de memoria, por lo que resulta adecuada para las cargas de trabajo más ligeras.
Para ver un ejemplo más sustancial, considere un requisito de almacenamiento de 14 TiB (14 336 GiB) y una carga de trabajo pesada. En este caso, podría decidir empezar con 2 \* 144 = 288 núcleos de vCPU y 8 \* 144 = 1 152 GiB de memoria. Estos números se corresponden con aproximadamente 18 instancias `i3.4xlarge.search`. Si no necesita el almacenamiento local rápido, también puede probar con 18 instancias `r6g.4xlarge.search`, cada una con un volumen de almacenamiento de EBS de 1 TiB.
Si el clúster incluye cientos de terabytes de datos, consulte [Escala de petabytes en Amazon Service OpenSearch](petabyte-scale.md).
## Paso 3: realizar pruebas representativas
Tras configurar el clúster, puede [añadir los índices](indexing.md) utilizando el número de fragmentos que calculó anteriormente, realizar algunas pruebas representativas con los clientes utilizando un conjunto de datos realista y [supervisar CloudWatch las métricas](managedomains-cloudwatchmetrics.md) para ver cómo gestiona el clúster la carga de trabajo.
## Paso 4: suceder o iterar
Si el rendimiento satisface sus necesidades, las pruebas se realizan correctamente y CloudWatch las métricas son normales, el clúster está listo para usarse. Recuerde [configurar CloudWatch alarmas](cloudwatch-alarms.md) para detectar un uso deficiente de los recursos.
Si el desempeño no es aceptable, no se superan las pruebas o los valores de `CPUUtilization` o `JVMMemoryPressure` son altos, es posible que tenga que elegir un tipo de instancia diferente (o agregar instancias) y continuar con las pruebas. A medida que agrega instancias, reequilibra OpenSearch automáticamente la distribución de los fragmentos en todo el clúster.
Debido a que es más fácil medir el exceso de capacidad en un clúster sobrealimentado que el déficit en uno infraalimentado, recomendamos comenzar con un clúster más grande de lo que crea necesario. A continuación, debe realizar pruebas y reducir verticalmente el tamaño hasta tener un clúster eficiente con los recursos adicionales precisos para garantizar operaciones estables durante los períodos de mayor actividad.
Los clústeres en producción o los clústeres con estados complejos se benefician de los [nodos maestros dedicados](managedomains-dedicatedmasternodes.md), que mejoran el desempeño y la fiabilidad del clúster.