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.
Ajuste del tamaño
El tamaño le ayuda a determinar el tipo de instancia, la cantidad de nodos de datos y los requisitos de almacenamiento correctos para su entorno de destino. Le recomendamos que primero mida el tamaño por almacenamiento y, después, por CPUs. Si ya usas Elasticsearch o OpenSearch, el tamaño generalmente seguirá siendo el mismo. Sin embargo, debes identificar el tipo de instancia equivalente a tu entorno actual. Para ayudar a determinar el tamaño correcto, te recomendamos que sigas las siguientes pautas.
Almacenamiento
El dimensionamiento del clúster comienza con la definición de los requisitos de almacenamiento. Identifique el almacenamiento sin procesar que necesita para su clúster. Esto se determina evaluando los datos generados por el sistema de origen (por ejemplo, los servidores que generan registros o el tamaño sin procesar del catálogo de productos). Tras identificar la cantidad de datos sin procesar de los que dispone, utilice la siguiente fórmula para calcular los requisitos de almacenamiento. A continuación, puede utilizar el resultado como punto de partida para su PoC.
storage needed = (daily source data in bytes × 1.45)
(number_of_replicas + 1) × number of days retained
La fórmula tiene en cuenta lo siguiente:
-
El tamaño del disco de un índice varía, pero suele ser un 10 por ciento más grande que los datos de origen.
-
Linux reserva una sobrecarga del sistema operativo del 5 por ciento para la recuperación del sistema y para evitar problemas de desfragmentación del disco.
-
OpenSearch reserva el 20 por ciento del espacio de almacenamiento de cada instancia para fusiones de segmentos, registros y otras operaciones internas.
-
Recomendamos conservar un 10 por ciento de almacenamiento adicional para minimizar el impacto de los fallos en los nodos y de las interrupciones en las zonas de disponibilidad.
En conjunto, estos gastos generales y las reservas requieren un 45 por ciento de espacio adicional, en función de los datos sin procesar reales de la fuente. Por eso se multiplican los datos de origen por 1,45. A continuación, multiplique esto por el número de copias de datos (por ejemplo, una principal más el número de réplicas que vaya a utilizar). El número de réplicas depende de sus requisitos de capacidad de recuperación y rendimiento. Para un caso de uso medio, se empieza con una réplica principal y una réplica. Por último, multiplique por el número de días que desee conservar los datos en un nivel de almacenamiento activo.
Amazon OpenSearch Service ofrece niveles de almacenamiento en caliente, caliente y frío. El nivel de almacenamiento en caliente utiliza UltraWarm almacenamiento. UltraWarm proporciona una forma rentable de almacenar grandes cantidades de datos de solo lectura en Amazon OpenSearch Service. Los nodos de datos estándar utilizan almacenamiento en caliente, que adopta la forma de almacenes de instancias o volúmenes de Amazon Elastic Block Store (Amazon EBS) adjuntos a cada nodo. El almacenamiento en caliente proporciona el rendimiento más rápido posible para la indexación y la búsqueda de nuevos datos. UltraWarm los nodos utilizan Amazon Simple Storage Service (Amazon S3) como almacenamiento y una sofisticada solución de almacenamiento en caché para mejorar el rendimiento. Para los índices en los que no está escribiendo activamente o consultando con menos frecuencia y que no tienen los mismos requisitos de rendimiento, UltraWarm ofrece costos significativamente más bajos por GiB de datos. Para obtener más información UltraWarm, consulte la documentación de AWS.
Al crear un dominio de OpenSearch servicio y utilizar almacenamiento activo, es posible que necesite definir el tamaño del volumen de EBS. Depende del tipo de instancia que elija para los nodos de datos. Puede usar la misma fórmula de requisitos de almacenamiento para determinar el tamaño del volumen de las instancias respaldadas por Amazon EBS. Recomendamos usar volúmenes gp3 para las familias de instancias T3, R5, R6G, M5, M5g, C5 y C6g de última generación. Con los volúmenes gp3 de Amazon EBS, puede aprovisionar el rendimiento independientemente de la capacidad de almacenamiento. Los volúmenes gp3 de Amazon EBS también ofrecen un mejor rendimiento de referencia, con un coste por GB un 9,6 por ciento inferior al de los volúmenes gp2 existentes en servicio. OpenSearch Con gp3, también obtiene un almacenamiento más denso en las familias de instancias R5, R6g, M5 y M6g, lo que puede ayudarlo a optimizar aún más sus costos. Puede crear volúmenes de EBS hasta la cuota admitida. Para obtener más información sobre las cuotas, consulta las cuotas OpenSearch de Amazon Service.
Para los nodos de datos que tienen unidades NVM Express (NVMe), como las instancias i3 y r6gd, el tamaño del volumen es fijo, por lo que los volúmenes de EBS no son una opción.
Número de nodos y tipos de instancias
La cantidad de nodos se basa en la cantidad de nodos CPUs necesarios para operar la carga de trabajo. El número de CPUs se basa en el recuento de fragmentos. Una entrada indexada OpenSearch se compone de varios fragmentos. Al crear un índice, se especifica el número de fragmentos del índice. Por lo tanto, debe hacer lo siguiente:
-
Calcule el número total de fragmentos que desea almacenar en el dominio.
-
Determine la CPU.
-
Encuentre el tipo y el número de nodos más rentables que le proporcionen la cantidad CPUs y el almacenamiento necesarios.
Este suele ser un punto de partida. Realice pruebas para determinar si el tamaño estimado cumple sus requisitos funcionales y no funcionales.
Determinar la estrategia de indexación y el recuento de fragmentos
Una vez que conozca los requisitos de almacenamiento, podrá decidir cuántos índices necesita e identificar el número de fragmentos de cada uno. Por lo general, los casos de uso de las búsquedas tienen uno o varios índices, cada uno de los cuales representa una entidad o un catálogo en los que se pueden realizar búsquedas. Para los casos de uso del análisis de registros, un índice puede representar un archivo de registro diario o semanal. Una vez que haya decidido cuántos índices, comience con la siguiente guía de escala y determine el recuento de fragmentos adecuado:
-
Busque casos de uso: de 10 a 30 GB por fragmento
-
Casos de uso del análisis de registros: 50 GB/fragmento
Puede dividir el volumen total de datos de un índice único por el tamaño del fragmento que desee utilizar en su caso de uso. Esto le dará el número de fragmentos del índice. Identificar el número total de fragmentos le ayudará a encontrar los tipos de instancias correctos que se adapten a su carga de trabajo. Los fragmentos no deben ser demasiado grandes ni demasiado numerosos. Los fragmentos grandes pueden dificultar la recuperación en caso de un error, pero dado que cada fragmento consume cierta cantidad de CPU y memoria, tener demasiados fragmentos pequeños puede provocar problemas de rendimiento y errores. OpenSearch out-of-memory Además, el desequilibrio en la asignación de los fragmentos a los nodos de datos puede provocar sesgos. Cuando tenga índices con múltiples particiones, intente hacer que el recuento de particiones sea un múltiplo par del recuento de nodos de datos. Esto ayuda a garantizar que las particiones se distribuyan de manera uniforme entre los nodos de datos y evita los nodos activos. Por ejemplo, si tiene 12 particiones principales, el recuento de nodos de datos debe ser 2, 3, 4, 6 o 12. Sin embargo, el recuento de particiones es secundario al tamaño de la partición; si tiene 5 GiB de datos, debe seguir utilizando una sola partición. Equilibrar el número de fragmentos de réplica de manera uniforme en toda la zona de disponibilidad también ayuda a mejorar la resiliencia.
Utilización de la CPU
El siguiente paso es identificar cuántos CPUs necesita para su carga de trabajo. Recomendamos empezar con un recuento de CPU 1,5 veces mayor que el de los fragmentos activos. Un fragmento activo es cualquier fragmento de un índice que recibe un número considerable de escrituras. Utilice el recuento de fragmentos principales para determinar los fragmentos activos de los índices que reciben numerosas solicitudes de lectura o escritura. Para el análisis de registros, solo el índice actual suele estar activo. En los casos de uso de búsqueda, todos los fragmentos principales se considerarán fragmentos activos. Aunque recomendamos 1,5 CPU por fragmento activo, esto depende en gran medida de la carga de trabajo. Asegúrese de probar y monitorear el uso de la CPU y escalarlo en consecuencia.
Una práctica recomendada para mantener el uso de la CPU es asegurarse de que el dominio de OpenSearch servicio cuente con recursos suficientes para realizar sus tareas. Un clúster que utilice la CPU de forma constante y elevada puede degradar la estabilidad del clúster. Cuando el clúster esté sobrecargado, el OpenSearch servicio bloqueará las solicitudes entrantes, lo que provocará el rechazo de las solicitudes. Esto es para evitar que el dominio falle. Las pautas generales sobre el uso de la CPU se situarán en torno al 60 por ciento de media y el 80 por ciento de utilización máxima de la CPU. Los picos ocasionales del 100 por ciento siguen siendo aceptables y es posible que no requieran escalarlos ni reconfigurarlos.
Tipos de instancias
Amazon OpenSearch Service te permite elegir entre varios tipos de instancias. Puede elegir los tipos de instancias que mejor se adapten a su caso de uso. Amazon OpenSearch Service admite las familias de instancias R, C, M, T e I. Puede elegir una familia de instancias en función de la carga de trabajo: optimizada para memoria, optimizada para cómputo o mixta. Después de identificar una familia de instancias, elige el tipo de instancia de última generación. Por lo general, recomendamos Graviton y las generaciones posteriores porque están diseñadas para ofrecer un rendimiento mejorado con costes más bajos en comparación con las instancias de la generación anterior.
En función de las diversas pruebas que se realizaron para casos de uso de búsquedas y análisis de registros, recomendamos lo siguiente:
-
Para los casos de uso del análisis de registros, una pauta general es empezar con la familia R de instancias Graviton para nodos de datos. Le recomendamos que realice pruebas, establezca puntos de referencia para sus requisitos e identifique el tamaño de instancia adecuado para su carga de trabajo.
-
Para los casos de uso de búsqueda, recomendamos usar instancias Graviton de las familias R y C para los nodos de datos, ya que los casos de uso de búsqueda requieren más CPU en comparación con los casos de uso de análisis de registros. Para cargas de trabajo más pequeñas, puedes usar las instancias Graviton de la familia M tanto para la búsqueda como para los registros. Las instancias de la familia I ofrecen NVMe unidades y las utilizan clientes con requisitos de búsqueda de baja latencia e indexación rápida.
El clúster está compuesto por nodos de datos y nodos de administrador de clústeres. Si bien los nodos maestros dedicados no procesan solicitudes de búsqueda ni de consulta, su tamaño es proporcional al tamaño y el número de instancias, índices y particiones que son capaces de administrar. La documentación de AWS proporciona una matriz que recomienda un tipo mínimo de instancia de administrador de clústeres dedicado.
AWS ofrece aplicaciones generales (M6g), optimizadas para cómputo (C6g) y optimizadas para memoria (R6g y R6gd) para la OpenSearch versión 7.9 o posterior de Amazon Service con procesadores Graviton2 de AWS.
La familia de instancias Graviton2 reduce la latencia de indexación hasta un 50 por ciento y mejora el rendimiento de las consultas hasta un 30 por ciento en comparación con las instancias basadas en Intel de la generación anterior disponibles en OpenSearch servicio (M5, C5, R5).
