Preguntas frecuentes sobre Amazon OpenSearch Service

Sí. Puede crear un nuevo dominio de Amazon OpenSearch Service mediante el asistente de creación de dominios de la consola con unos pocos clics. Cuando crea un dominio nuevo, puede especificar el número de instancias, los tipos de instancias y los volúmenes de EBS que desea asignar al dominio. Con la consola también puede modificar o eliminar dominios de Amazon OpenSearch Service existentes.

Sí, Amazon OpenSearch Service se integra con Amazon VPC. Cuando se elige el acceso de VPC, las direcciones IP de su VPC se adjuntan a su dominio de Amazon OpenSearch Service y todo el tráfico de red permanece dentro de la red de AWS. No es posible obtener acceso a él mediante Internet. Además, puede usar grupos de seguridad y políticas de IAM para restringir el acceso a sus dominios de Amazon OpenSearch Service.

Sí. AWS CloudFormation es compatible con Amazon OpenSearch Service. Para obtener más información, consulte la documentación de referencia sobre las plantillas de CloudFormation.

Sí. Puede configurar nodos principales dedicados para sus dominios. Al elegir una configuración principal dedicada, puede especificar el tipo y el número de instancias.

Sí. Puede crear varios índices de Elasticsearch u OpenSearch en el mismo dominio de Amazon OpenSearch Service. Elasticsearch y OpenSearch distribuyen automáticamente los índices y cualquier réplica asociada entre las instancias asignadas al dominio.

Amazon OpenSearch Service admite tres opciones para la ingesta de datos:

• Para grandes volúmenes de datos, recomendamos Amazon Kinesis Data Firehose, un servicio completamente administrado cuya escala se ajusta automáticamente para adaptarse al rendimiento de los datos y no necesita administración permanente. También puede transformar, procesar por lotes y comprimir los datos antes de cargarlos.
• Amazon OpenSearch Service admite la integración con Logstash. Puede configurar el dominio de Amazon OpenSearch Service como el almacén de datos para todos los registros que provengan de su implementación de Logstash.
• Puede utilizar las API nativas de OpenSearch o Elasticsearch (hasta la versión 7.10), como las API de índice y en bloque, para cargar datos en el dominio.

Sí. Amazon OpenSearch Service admite la integración con Logstash. Puede configurar el dominio de Amazon OpenSearch Service como almacén backend de todos los registros procedentes de la implementación de Logstash. Puede configurar el control del acceso en el dominio de Amazon OpenSearch Service de manera que usen la firma de solicitudes para autenticar las llamadas hechas desde la implementación de Logstash o bien políticas de IAM basadas en recursos para incluir las direcciones IP de las instancias en las que se ejecuta la implementación de Logstash.

Sí. Amazon OpenSearch Service ofrece capacidades de visualización con la tecnología de OpenSearch Dashboards y Kibana (versiones 1.5 a 7.10).

Puede elegir entre almacenamiento en instancias local o volúmenes de EBS. Durante la creación de dominios, si selecciona el almacenamiento en EBS, puede aumentar o disminuir el volumen del almacenamiento según sea necesario.

Puede elegir entre volúmenes de EBS de IOPS aprovisionadas, de uso general o magnéticos.

Sí. Amazon OpenSearch Service implementa el almacenamiento en función de la elección de la instancia o del tamaño del volumen EBS asociado. El almacenamiento máximo por nodo es de 24 TB con instancias R6g.12xlarge con almacenamiento EBS gp3. Con un número máximo predeterminado de 80 nodos de datos permitidos por dominio de Amazon OpenSearch Service, puede asignar unos 1920 TB de almacenamiento a un único dominio. Puede solicitar un aumento del límite del servicio de hasta 200 instancias por dominio, creando un caso con AWS Support Center. Con 200 instancias, puede asignar aproximadamente 3 PB de almacenamiento en un único dominio.

Si implementa sus instancias de datos en una única zona de disponibilidad, sus instancias maestras dedicadas también se implementan en la misma zona de disponibilidad. Sin embargo, si implementa sus instancias de datos en dos o tres zonas de disponibilidad, Amazon OpenSearch Service distribuye automáticamente las instancias maestras dedicadas en las tres zonas de disponibilidad. La excepción a esta regla se produce si una región tiene solo dos zonas de disponibilidad o si selecciona un tipo de instancias de antigua generación para las instancias maestras que no está disponible en todas las zonas de disponibilidad. Para obtener más detalles, consulte nuestra documentación.

Para cargas de trabajo de producción, recomendamos implementar sus instancias de datos en tres zonas de disponibilidad, ya que ofrece mejor disponibilidad. Asimismo, recomendamos instancias de aprovisionamiento en múltiplos de tres para una distribución uniforme de las zonas de disponibilidad. En regiones donde no se dispone de tres zonas de disponibilidad, recomendamos el uso de una implementación de dos zonas de disponibilidad con un número par de instancias de datos. En todos los casos, recomendamos el aprovisionamiento de tres instancias principales dedicadas.

Puede habilitar implementaciones de tres zonas de disponibilidad para dominios nuevos y existentes utilizando la consola de AWS, la CLI o los SDK. Para obtener más detalles, consulte nuestra documentación.

No. Amazon OpenSearch Service no cobra por habilitar la implementación de tres zonas de disponibilidad. Solo paga por el número de instancias en su dominio, no el número de zonas de disponibilidad que se implementan.

Todos los dominios configurados para múltiples zonas de disponibilidad tendrán activado el reconocimiento de zona para garantizar que los fragmentos están distribuidos en las zonas de disponibilidad. En la consola, puede ahora puede elegir explícitamente implementaciones de dos o tres zonas de disponibilidad. Los dominios previamente configurados con la opción de "reconocimiento de zona" se seguirán implementado en dos zonas de disponibilidad, salvo que se reconfiguren. Para obtener más detalles, consulte nuestra documentación.

Si una o más instancias en una zona de disponibilidad son inaccesibles o no funcionales, Amazon OpenSearch Service automáticamente intenta mostrar nuevas instancias en la misma zona de disponibilidad para sustituir las instancias afectadas. En el caso aislado de que no puedan mostrarse nuevas instancias en la zona de disponibilidad, Amazon OpenSearch Service mostrará nuevas instancias en las zonas de disponibilidad disponibles si el dominio se ha configurado para implementar instancias en múltiples zonas de disponibilidad. Una vez que el problema con las zonas de disponibilidad se resuelve, Amazon OpenSearch Service reequilibra las instancias de tal manera que estén igualmente distribuidas en las zonas de disponibilidad configuradas para el dominio. Para obtener más detalles, consulte nuestra documentación.

Incluso cuando se configure una réplica, recomendamos tres zonas de disponibilidad. Si se produce una interrupción de zonas de disponibilidad en tres dominios de zonas de disponibilidad, solo se pierde un tercio de su capacidad, pero si la interrupción se produce en dos dominios de zonas de disponibilidad, se pierde la mitad de su capacidad, lo cual puede ser más perjudicial. Además, en un dominio de tres zonas de disponibilidad, cuando una zona de disponibilidad se interrumpe, Amazon OpenSearch Service puede seguir usando las dos zonas de disponibilidad restantes y seguir admitiendo la reproducción en las zonas de disponibilidad. En un dominio de dos zonas de disponibilidad, se pierde la reproducción entre las zonas de disponibilidad si se interrumpe una zona de disponibilidad, lo cual puede reducir aún más la disponibilidad. Para obtener más detalles, consulte nuestra documentación.

La cantidad de zonas de disponibilidad que implementa su dominio debe concordar con la cantidad de subredes que se han configurado para su dominio de VPC. Debe configurar al menos tres subredes en su dominio de VPC para habilitar una implementación de tres zonas de disponibilidad. Para obtener más detalles sobre la configuración de VPC, consulte nuestra documentación.

Sí. Los programas con acceso a la Internet pública pueden obtener acceso a los dominios de Amazon OpenSearch Service a través de un punto de enlace público. Si su centro de datos ya se encuentra conectado a Amazon VPC mediante Direct Connect o tunelización SSH, también puede usar el acceso de VPC. En ambos casos, puede configurar grupos de seguridad y políticas de IAM para permitir que los programas en ejecución en servidores externos a AWS puedan obtener acceso a sus dominios de Amazon OpenSearch Service. Haga clic aquí para obtener más información sobre las solicitudes firmadas.

Para migrar datos de un clúster de Elasticsearch u OpenSearch existente, debe crear una instantánea de un clúster existente y almacenarla en su bucket de Amazon S3. Luego puede crear un nuevo dominio de Amazon OpenSearch Service y cargar los datos de la instantánea en el dominio de Amazon OpenSearch Service recién creado mediante la API de restauración.

Amazon OpenSearch Service permite controlar el ajuste del escalado de los dominios de Amazon OpenSearch Service mediante la consola, la API y la CLI. Puede escalar el dominio de Amazon OpenSearch Service a través de la incorporación, eliminación o modificación de instancias o volúmenes de almacenamiento en función de las necesidades de la aplicación. Amazon OpenSearch Service se integra con Amazon CloudWatch para proporcionar métricas acerca del estado de los dominios de Amazon OpenSearch Service y permitirle tomar las decisiones de ajuste de escalado adecuadas en relación con sus dominios.

Ajustar la escala del dominio de Amazon OpenSearch Service mediante la incorporación o modificación de instancias y volúmenes de almacenamiento es una operación que se efectúa en línea y no genera tiempo de inactividad.

Sí. Si habilita réplicas para sus índices de OpenSearch o Elasticsearch y utiliza varias zonas de disponibilidad, Amazon OpenSearch Service distribuye automáticamente las particiones principales y de réplica entre las instancias en diferentes zonas de disponibilidad.

Sí. Amazon OpenSearch Service muestra varias métricas de rendimiento a través de Amazon CloudWatch, como el número de nodos, el estado del clúster, los documentos donde se pueden hacer búsquedas, las métricas de EBS (si corresponden), la CPU, la memoria y el uso del disco para los nodos maestros y de datos. En la documentación del servicio encontrará la lista completa de las métricas disponibles de CloudWatch.

Sí. AWS CloudTrail es un servicio web que registra las llamadas del API de AWS de su cuenta y le entrega logs. El historial de llamadas al API de AWS creado por AWS CloudTrail permite realizar análisis de seguridad, un seguimiento de cambios implementados en recursos y auditorías de conformidad. Obtenga más información sobre AWS CloudTrail en la página de detalles de AWS CloudTrail y habilítelo a través de la página de inicio de la consola de administración de AWS en CloudTrail.

Una instantánea es una copia de su dominio de Amazon OpenSearch Service hecha en un momento determinado.

La creación de instantáneas puede resultar útil en caso de que se produzcan pérdidas de datos por errores en los nodos o en el caso poco frecuente de que el hardware presente algún error. Puede usar las instantáneas para recuperar su dominio de Amazon OpenSearch Service o crear un dominio nuevo de Amazon OpenSearch Service con datos cargados con anterioridad. Las copias de seguridad también suelen utilizarse con fines de archivado. Las snapshots se almacenan en Amazon S3.

Sí. De forma predeterminada, Amazon OpenSearch Service crea automáticamente instantáneas por horas de cada dominio de Amazon OpenSearch Service y las retiene 14 días.

Amazon OpenSearch Service retiene las instantáneas por horas automatizadas de los últimos 14 días.

Las instantáneas por horas automatizadas no generan cargos adicionales. Las instantáneas se almacenan de forma gratuita en un bucket de S3 de Amazon OpenSearch Service y se encontrarán disponibles con fines de recuperación de nodos.

Sí. Puede usar la API de instantáneas para crear instantáneas manuales adicionales además de las diarias automatizadas que crea Amazon OpenSearch Service. Las snapshots manuales se almacenan en el bucket de S3 y conllevan los cargos por uso pertinentes de Amazon S3.

Sí. Los clientes pueden crear un nuevo dominio de Amazon OpenSearch Service y cargar los datos de la instantánea en el dominio de Amazon OpenSearch Service recién creado con la API de restauración de OpenSearch o Elasticsearch.

Al eliminar un dominio, también se eliminan las instantáneas diarias retenidas en Amazon OpenSearch Service. Antes de eliminar un dominio, puede crear una instantánea del dominio en sus propios buckets de S3 mediante el proceso de creación de instantáneas manuales. Si borra un dominio de Amazon OpenSearch Service, las instantáneas almacenadas en el bucket de S3 no se verán afectadas.

Amazon OpenSearch Service muestra tres registros de Elasticsearch u OpenSearch a través de Amazon CloudWatch Logs: registros de error, registros lentos de búsqueda y registros lentos de índice. Estos registros son útiles para resolver problemas de rendimiento y estabilidad con un dominio propio.

Los registros lentos son archivos de registros que ayudan a monitorear el rendimiento de varias etapas de una operación. OpenSearch y Elasticsearch presentan dos tipos de registros lentos:

• Logs lentos de índice: suministran información acerca del proceso de indexación y se pueden utilizar para ajustar la configuración del índice.
• Registros lentos de búsqueda: suministran información acerca de la velocidad con la que se realizan consultas y recuperaciones. Estos registros ayudan a ajustar el rendimiento de cualquier tipo de operación de búsqueda en OpenSearch o Elasticsearch.

Para leer detalles completos acerca de los registros lentos, consulte la documentación de OpenSearch.

Los registros lentos se pueden activar mediante el clic de un botón a partir de la consola o a través de nuestras CLI y API. Para leer más detalles, consulte nuestra documentación.

Sí. Puede actualizar la configuración de un índice específico para activar o desactivar los registros lentos en él. Para obtener más detalles, consulte nuestra documentación.

No. Activar los registros lentos en Amazon OpenSearch Service habilita la opción para publicar los registros generados en Amazon CloudWatch Logs para índices en un dominio determinado. Sin embargo, para generar los registros, debe actualizar la configuración de uno o más índices para iniciar el proceso de generación de registros. Si desea obtener más detalles acerca del ajuste de configuración de índices para habilitar los registros lentos, consulte nuestra documentación.

La generación de archivos de registro depende de la configuración del índice. Para deshabilitar la generación de archivos de registro debe actualizar la configuración del índice. Si desea obtener más detalles acerca del ajuste de configuración de índices para activar los registros lentos, consulte nuestra documentación.

Solo puede modificar la granularidad de la generación de registros en los registros lentos. OpenSearch y Elasticsearch muestran varios niveles de generación de registros para los registros lentos. Debe ajustar el nivel adecuado en la configuración de su índice. Si desea leer más detalles acerca del ajuste de configuración de índices para activar los registros lentos, consulte la documentación de OpenSearch.

Cuando se habilitan los registros lentos o de error, Amazon OpenSearch Service comienza a publicar los registros generados en CloudWatch Logs. Amazon OpenSearch Service no cobra la habilitación de registros. Sin embargo, se aplican cargos de CloudWatch estándar.

OpenSearch usa Apache Log4j 2 y sus niveles de registro integrados (de menor a mayor severidad) de TRACE, DEBUG, INFO, WARN, ERROR y FATAL. Si habilita los registros de errores, Amazon OpenSearch Service publica líneas de registro de WARN, ERROR y FATAL, y selecciona errores del nivel DEBUG en CloudWatch. Para obtener más detalles, consulte nuestra documentación.

Los registros de error se pueden activar mediante el clic de un botón a partir de la consola de AWS o a través de nuestras CLI y API. Para leer más detalles, consulte nuestra documentación.

No, los registros de error se muestran para el dominio entero. Es decir, una vez activados, se pondrán a disposición las entradas de registro de todos los índices del dominio.

No, los registros de error solo se encuentran disponibles para las versiones de Elasticsearch 5.x y posteriores.

Sí. Cada entrada de registro publicada en CloudWatch estará limitada a 255 000 caracteres. Si una entrada de log excede este número, se cortará cuando llegue a los 255 000 caracteres.

Los registros lentos solo son necesarios cuando se desea resolver problemas relacionados con índices o ajustar el rendimiento. La estrategia recomendada es activar la generación de registros únicamente en aquellos índices para los que necesita obtener información de rendimiento adicional. Además, una vez que se finaliza la investigación, debería deshabilitar la generación de registros para no incurrir en costos adicionales. Para obtener más detalles, consulte nuestra documentación.

CloudWatch permite utilizar los registros de diferentes maneras. Puede ver datos de registros, exportarlos a S3 o procesarlos en tiempo real. Si desea obtener más información, consulte la guía para desarrolladores de CloudWatch Logs.

Sí. Los registros lentos se pueden habilitar en todas las versiones de OpenSearch y Elasticsearch compatibles con Amazon OpenSearch Service. Sin embargo, existen pequeñas diferencias en la manera en la que puede especificarse la configuración de registros en cada versión de Elasticsearch. Consulte nuestra documentación para obtener más detalles.

No habrá tiempos de inactividad. Cada vez que se actualice el estatus de los registros, implementaremos un clúster nuevo en segundo plano y reemplazaremos el clúster existente por el nuevo. Esto proceso no provocará tiempo de inactividad. Sin embargo, como se implementa un clúster nuevo, la actualización del estatus del registro no será instantánea.

Actualmente, Amazon OpenSearch Service admite la actualización de versiones local para dominios con cualquier versión de OpenSearch o versiones 5.x y posteriores de Elasticsearch. Las versiones de destino que se admiten para la actualización son 5.6, 6.3, 6.4, 6.5, 6.7, 6.8, 7.1, 7.4, 7.7, 7.8, 7.9 y 7.10. Para obtener más detalles, consulte nuestra documentación.

Consulte nuestra documentación para leer detalles acerca de cómo migrar a partir de varias versiones de Elasticsearch.

No. El dominio permanecerá disponible durante todo el proceso de actualización. Sin embargo, una parte del proceso de actualización incluye la reubicación de particiones, por lo que podría afectarse el rendimiento del dominio. Recomendamos realizar la actualización cuando la carga del dominio sea baja.

La actualización de versión local se encuentra disponible únicamente para dominios con Elasticsearch 5.x o superior. Si su dominio tiene la versión 5.x o superior, puede ejecutar la comprobación de elegibilidad de actualización para comprobar si el dominio se puede actualizar a la versión que desea. Para obtener más información, consulte la documentación.

Si desea obtener una lista detallada de las pruebas que ejecutamos para validar los requisitos de la actualización, consulte nuestra documentación.

No. Una vez que se active la actualización de versión local, no podrá realizar cambios en la configuración del dominio hasta que la actualización se complete o falle. Puede leer y escribir datos mientras se realiza la actualización. También puede eliminar el dominio, en cuyo caso la actualización finaliza y el dominio se elimina.

El proceso de actualización de versión toma una instantánea del sistema automáticamente y solo inicia la actualización si la instantánea se realiza correctamente. Si la actualización se está llevando a cabo cuando llega el momento de iniciar la instantánea automatizada, esta se omite y se lleva a cabo al día siguiente.

Amazon OpenSearch Service ejecuta un conjunto de pruebas antes de desencadenar la actualización para detectar la presencia de errores conocidos que pudieran bloquear la actualización. Si no se encuentran errores, el servicio toma una instantánea del dominio e inicia el proceso de actualización si la instantánea se lleva a cabo correctamente. La actualización no se activa si se encuentran problemas durante cualquiera de estos pasos.

Si los problemas son menores y pueden corregirse, Amazon OpenSearch Service intenta resolverlos automáticamente y desbloquear la actualización. Sin embargo, si un problema bloquea la actualización, el servicio revierte el estado a la instantánea que se tomó antes de la actualización y registra el error. Si desea obtener más detalles acerca de la visualización de los registros del progreso de la actualización, consulte nuestra documentación.

Sí. Puede ver los registros de actualizaciones en la consola de AWS o solicitarlos con la CLI o los SDK. Para obtener más información consulte nuestra documentación.

No. Una vez que se inicia la actualización, no es posible detenerla ni cancelarla hasta que finalice o falle.

Sí. Sin embargo, si desea conservar todos los dominios en la misma versión, recomendamos ejecutar la comprobación de elegibilidad de la actualización en todos los dominios antes de actualizarlos. Este paso adicional puede ayudar a detectar problemas en un dominio que tal vez no estén presentes en los demás.

En función del volumen de los datos y del tamaño del clúster, las actualizaciones pueden demorar desde unos pocos minutos a unas pocas horas en completarse.

No. En una actualización de versión local, todos los datos del clúster se almacenan como parte del proceso de actualización. Si solo desea actualizar el dominio, puede tomar una instantánea de los datos, eliminar todos los índices del dominio y, a continuación, iniciar una actualización de versión local. Opcionalmente, puede crear un dominio independiente con la versión más nueva y, a continuación, restaurar los datos en dicho dominio.

No. Si necesita volver a una versión anterior, póngase en contacto con AWS Support para restaurar la instantánea automática, previamente actualizada en un nuevo dominio. Si toma una instantánea manual del dominio original, puede llevar a cabo este paso por su cuenta.

Multi-AZ con modo de espera es una nueva opción de implementación para Amazon OpenSearch Service que permite una alta disponibilidad y un rendimiento uniforme para las cargas de trabajo críticas de las empresas. Con Multi-AZ con modo de espera, los clústeres administrados por OpenSearch Service resisten los errores de la infraestructura, como caídas de nodos o errores en una única zona de disponibilidad, lo que garantiza que no se vean afectados el rendimiento ni la disponibilidad, incluso en caso de que se produzca un error en una única zona de disponibilidad. Multi-AZ con modo de espera ofrece la ventaja adicional de simplificar la configuración y la administración de los clústeres al aplicar las prácticas recomendadas y reducir la complejidad.

Para habilitar Multi-AZ con modo de espera, los clústeres administrados deben cumplir las siguientes condiciones:

• Ejecutar OpenSearch 1.3 o una versión más reciente.
• Implementar en las regiones de AWS con tres zonas de disponibilidad. Actualmente, la región de AWS del norte de California no admite tres zonas de disponibilidad y, por lo tanto, no es apta para Multi-AZ con modo de espera.
• El número de nodos de datos debe ser un múltiplo de tres.
• El número de copias de datos (primaria y réplica) debe ser un múltiplo de tres.
• Siga las pautas de tamaño del líder (el tamaño recomendado se basa en la cantidad de nodos, la cantidad de particiones y la cantidad de asignaciones del clúster).

Con Multi-AZ con modo de espera, Amazon OpenSearch Service detecta y se recupera automáticamente de algunos de los errores de la infraestructura. Amazon OpenSearch Service conmuta automáticamente por error los nodos activos a los nodos en espera en menos de un minuto cuando se produce alguno de los siguientes eventos:

• Pérdida de una zona de disponibilidad activa o de todos los nodos de una zona de disponibilidad activa
• Pérdida de conectividad a una zona de disponibilidad activa
• Error de hardware de instancia en la zona de disponibilidad activa
• Error de almacenamiento en un nodo de la zona de disponibilidad activa

Actualmente, Multi-AZ con modo de espera no cubre los siguientes eventos:

• Pérdida del cuórum principal, ya que la recuperación después de este evento puede tardar varios minutos
• Pérdida de varias zonas de disponibilidad
• Pérdida de conectividad con una región
• Pérdida de más del 50 % de los nodos en más de una zona de disponibilidad
• Tiempo de inactividad que se debe a una computación o almacenamiento insuficientes como resultado de un cambio en las características de la carga de trabajo
• Tiempo de inactividad que se debe a consultas no deseadas
• Pérdida de uno o más servicios de los que depende Amazon OpenSearch Service, como ARPS y ALB
• Tiempo de inactividad de OpenSearch Dashboard durante las actualizaciones de la versión

No. En principio, las pautas de tamaño son las mismas. Multi-AZ con modo de espera tiene requisitos previos que simplifican el modelo mental necesario para establecer el tamaño del clúster. La forma de pensar en el tamaño de un clúster administrado consiste en analizar la capacidad necesaria para atender la carga de trabajo y, a continuación, agregar un 50 % para garantizar la redundancia. La principal diferencia entre la opción actual de “reconocimiento de zona” y la opción Multi-AZ con modo de espera es la forma en que se gestiona la capacidad redundante o adicional para mantener la disponibilidad. Multi-AZ con modo de espera requiere que haya al menos una copia de los datos en cada zona de disponibilidad, a fin de que pueda reservar de forma explícita la capacidad de una zona de disponibilidad como modo de espera. Esta capacidad en espera actúa como objetivo de conmutación por error durante una interrupción de zona de disponibilidad o un error de instancia. El modelo actual requiere que mantenga niveles óptimos de recursos para atender su carga de trabajo. Debe seguir supervisando su clúster para detectar problemas de tamaño y tomar acciones correctivas a medida que cambien las características de la carga de trabajo.

No. Amazon OpenSearch Service funciona según un modelo de responsabilidad compartida. Usted es responsable de garantizar que el tamaño del clúster se ajuste a su carga de trabajo. Multi-AZ con modo de espera simplifica el modelo mental de configuración de su clúster. Debe seguir supervisando las métricas de error y latencia, junto con el almacenamiento, la utilización de la CPU y la RAM, para detectar señales de que el clúster está sobrecargado y es posible que deba escalarse.

No. La característica Multi-AZ con modo de espera está disponible sin costo adicional. Sigue pagando por los recursos implementados en el clúster para satisfacer su carga de trabajo. Si su clúster ya sigue las prácticas recomendadas y tiene al menos tres copias de los datos para un clúster de tres zonas de disponibilidad, es poco probable que incurra en costos adicionales al cambiarse a Multi-AZ con modo de espera. Sin embargo, si su clúster tiene un tamaño insuficiente o no tiene suficiente capacidad redundante para atender su carga de trabajo, tendrá que agregar capacidad para pasar a Multi-AZ con modo de espera a fin de mejorar la disponibilidad y el rendimiento. La capacidad en espera se reserva a partir de la capacidad total configurada.

Mediante el acuerdo de nivel de servicios de Amazon OpenSearch Service se garantiza un porcentaje de tiempo de actividad mensual de al menos el 99,9 % para Amazon OpenSearch Service.

Tendrá derecho a un crédito de SLA para Amazon OpenSearch Service de acuerdo con el SLA de Amazon OpenSearch Service si las implementaciones Multi-AZ en Amazon OpenSearch Service tienen un porcentaje de tiempo de actividad mensual inferior al 99,9 % durante cualquier ciclo de facturación mensual.

Para obtener información completa sobre todos los términos y las condiciones del SLA, así como detalles sobre cómo enviar una reclamación, consulte la página con detalles del SLA de Amazon OpenSearch Service.

La búsqueda entre clústeres es una característica de Elasticsearch y OpenSearch que permite hacer consultas y agregación en dos clústeres conectados. Para que funcione, se debe configurar una conexión unidireccional atenuada entre los clústeres participantes.

Los dominios que participen en una búsqueda en clústeres deben cumplir los siguientes requisitos:

• Estar en la versión 6.8 de OpenSearch o Elasticsearch o en una posterior
• Tener el cifrado en tránsito habilitado
• Tener activado el control de acceso de alta precisión (FGAC)
• sus versiones deben cumplir las mismas reglas que la actualización de versión continua

Actualmente, los tipos de instancias que admiten la búsqueda en clústeres son los siguientes:

• Familias i2 e i3
• Familias r3, r4 y r5
• Familias m4 y m5
• Familias c4 y c5
• Familia Graviton

Debido a limitaciones técnicas, las instancias de las familias t2 y m3 no admiten la búsqueda en clústeres.

Sí. Los dominios participantes pueden pertenecer a dos cuentas de AWS diferentes.

Sí.

Para comenzar a utilizar la búsqueda entre clústeres, consulte la documentación aquí.

La replicación entre clústeres es una nueva capacidad que permite a los clientes de Amazon OpenSearch Service automatizar los índices de copia y sincronización de un clúster a otro con baja latencia en las mismas regiones de AWS o en regiones diferentes.

Los dominios que participen en una replicación entre clústeres deben cumplir los siguientes requisitos:

• estar en la versión 7.10 de Elasticsearch
• tener el cifrado en tránsito habilitado
• Tener activado el control de acceso de alta precisión (FGAC)
• sus versiones deben cumplir las mismas reglas que la actualización de versión continua

Sí. Los dominios de dos regiones de AWS diferentes pueden participar en la replicación entre clústeres.

No. La implementación actual de la replicación entre clústeres no es compatible con Ultrawarm, ni Cold Storage.

Sí. Deberá pagar los cargos estándar por transferencia de datos de AWS correspondientes a los datos transferidos desde y hacia Amazon OpenSearch Service.

Anunciamos el proyecto OpenSearch, una bifurcación de Elasticsearch y Kibana impulsada por la comunidad y de código abierto, el 12 de abril de 2021. Nos hemos comprometido a invertir a largo plazo en OpenSearch para garantizar que los usuarios sigan disponiendo de un conjunto de búsqueda y análisis seguro, de alta calidad y totalmente de código abierto, con un plan de desarrollo enriquecido de funcionalidades nuevas e innovadoras. Este proyecto incluye OpenSearch (derivado de Elasticsearch 7.10.2) y OpenSearch Dashboards (derivado de Kibana 7.10.2). Lanzamos la versión 1.0 de OpenSearch el 12 de julio de 2021. Como parte de nuestro compromiso a largo plazo con OpenSearch, agregamos compatibilidad con OpenSearch 1.0 en el servicio administrado el 7 de septiembre de 2021 y cambiamos el nombre de Amazon Elasticsearch Service a Amazon OpenSearch Service. Junto con OpenSearch 1.0, seguimos ofreciendo compatibilidad con las versiones heredadas de Elasticsearch hasta la 7.10 en el servicio. Aparte del cambio de nombre, puede estar seguro de que seguiremos ofreciendo la misma gran experiencia sin que ello afecte a las operaciones en curso, la metodología de desarrollo o el uso empresarial. Más información sobre OpenSearch aquí: https://opensearch.org

Nos hemos esforzado para que este cambio de nombre sea lo más sencillo posible para usted. Hay aspectos, como las nuevas API de SDK o configuración, que requieren su intervención para asegurarse de que obtenga los mejores beneficios del servicio. Aunque el SDK existente seguirá funcionando desde el punto de vista de la compatibilidad, cualquier nueva funcionalidad que requiera nuevas API de configuración solo se implementará en el nuevo SDK. Por ello, le recomendamos que se cambie al nuevo SDK. Además, independientemente del nuevo SDK, le recomendamos que traslade sus políticas de IAM existentes para utilizar las API de configuración renombradas. A partir de ahora, sus políticas de IAM existentes seguirán funcionando con la anterior definición de API. Sin embargo, pasaremos a la nueva validación de permisos basada en la API y, finalmente, le pediremos que utilice las nuevas API en sus políticas (específicamente para las API donde hay un cambio de nombre, por ejemplo, CreateElasticsearchDomain a CreateDomain). Consulte la documentación para obtener más detalles.

No. Desde el punto de vista de la compatibilidad con versiones anteriores, nos aseguraremos de que su configuración actual siga funcionando con OpenSearch 1.0. Sin embargo, recomendamos que, con el tiempo, se cambie al último SDK para obtener una experiencia más limpia y actualizada, como se mencionó anteriormente.

No. No hay cambios en los precios.

OpenSearch incluye cierto código de Elasticsearch con licencia de Apache de Elasticsearch B.V. y otro código fuente. Elasticsearch B.V. no es el origen de ese otro código fuente. ELASTICSEARCH es una marca registrada de Elasticsearch B.V.

La actualización a OpenSearch 1.x garantiza que la infraestructura de búsqueda se base en un proyecto de código abierto con licencia de Apache dinámico en crecimiento y proporciona acceso a una gran cantidad de mejoras y características innovadoras que están disponibles en OpenSearch 1.2 (en la fecha de publicación del presente documento).  Seguridad de nivel empresarial, alertas, administración del ciclo de vida de los datos, observabilidad, detección de anomalías basada en ML, etc. son algunas de las características de OpenSearch Service, sin tarifas de licencia adicionales.

Utilizamos un proceso de despliegue azul/verde (BG) durante la actualización. Durante un BG, el servicio agrega nodos al clúster de OpenSearch Service en la nueva configuración y versión, migra datos desde los nodos anteriores y elimina dichos nodos anteriores cuando se completa la migración de datos. Durante un BG, tanto la búsqueda como la indexación de las API están disponibles y funcionan con normalidad. Aunque BG no está diseñado para interferir con las solicitudes de consulta e indexación, algunos cambios (especialmente aquellos que implican modificaciones en la configuración relacionada con la seguridad) pueden hacer que los paneles no estén disponibles durante el período de cambio.

OpenSearch admite varias versiones de Elasticsearch y OpenSearch, algunas de las cuales ya tienen fechas de finalización del soporte estándar y extendido anunciadas. Para obtener una lista completa de las versiones del motor y las fechas de soporte correspondientes, consulte la documentación. Para obtener más información sobre el soporte extendido, consulte el soporte extendido. 

AWS mantiene 19 versiones de Apache-2.0 con licencia de Elasticsearch. En este momento, ninguna de estas versiones está en desuso ni está prevista para ello.

Sí, la actualización desencadenará un proceso de despliegue de BG. Revise los pasos y la planificación aquí.

Trabaje con su equipo de cuentas de AWS para obtener información sobre su situación específica con las RI.

El proyecto OpenSearch 1.0 es una bifurcación de Elasticsearch 7.10.2 de código abierto. Es compatible con Elasticsearch 7.10: no necesita cambiar su uso. Para realizar una migración, puede actualizar el dominio a la versión Elasticsearch 7.10 desde cualquier versión anterior de las series 6.x y 7.x, hacer una instantánea y restaurar esa instantánea en un dominio que ejecute OpenSearch Service 1.x. Algunos clientes o herramientas incluyen comprobaciones de versión que pueden hacer que el cliente o la herramienta no funcionen con OpenSearch Service. Cuando actualice, habilite el modo de compatibilidad para evitar estas comprobaciones de versión.

En algunos casos, puede continuar utilizando los clientes existentes. Las API y la funcionalidad de búsqueda principal son compatibles con la versión 7.10.2 de Elasticsearch. Si tiene clientes más antiguos, estos comprueban la versión o bien aprovechan la funcionalidad que está dirigida a versiones anteriores de Elasticsearch, como las versiones principales 5 o 6, por lo que le sugerimos que intente llevar a sus clientes a un estándar mínimo de soporte como la versión 7.10.2, para garantizar que le transición se realice sin problemas.

El proyecto OpenSearch es compatible con una amplia gama de clientes que se han creado específicamente para abordar las versiones de OpenSearch del motor en Amazon OpenSearch Service. Compare el cliente con la lista de los últimos clientes de OpenSearch y los lenguajes de programación compatibles para esos clientes.

Puede habilitar la característica de modo de compatibilidad para interoperar con clientes de otros proveedores, pero recuerde comprobar la versión que notifica OpenSearch. Habilite esta configuración para garantizar que el servicio responda con la versión 7.10.2 a los clientes desarrollados antes de la introducción del motor de OpenSearch Service.

Los índices de Elasticsearch 5.x no son compatibles con Elasticsearch 7.10 u OpenSearch 1.x. Debe crear un nuevo índice y cargar datos desde su origen. Si está ejecutando una carga de trabajo de análisis de registros, puede evaluar si la estrategia de retención de datos es compatible con la ejecución en paralelo mientras crea un conjunto de datos completo en el nuevo dominio.

Sí. Póngase en contacto con [email protected] para solicitar una lista de socios para su región, sector y complejidad del proyecto. La Red de socios de AWS (APN) está capacitada y tiene la experiencia necesaria para ayudarle con las actualizaciones. 

OpenSearch 1.0 es una bifurcación de Elasticsearch 7.10.2. OpenSearch y Elasticsearch son compatibles. Si habilita el modo de compatibilidad, los clientes de Elasticsearch también serán compatibles con OpenSearch 1.0.

Amazon OpenSearch Service no ofrece ni ofrecerá versiones del motor de Elasticsearch posteriores a la versión 7.10.2.

Tal y como AWS anunció cuando bifurcamos Elasticsearch, nuestra intención era crear una comunidad próspera en torno a OpenSearch y así ha sido. Hemos publicado una hoja de ruta para OpenSearch completa, con contribuciones de la comunidad y consenso sobre las prioridades de las características. Haremos todo lo que sea posible para mantener la compatibilidad con Elasticsearch. Nuestro objetivo es crecer junto con la comunidad y los clientes de Amazon OpenSearch Service.

Puede actualizar directamente a OpenSearch Service 1.0 desde las versiones 6.8.0 a 7.10.2 de Elasticsearch y Kibana, y abrir distro para Elasticsearch (ODFE) 1.x. En el caso de las actualizaciones graduales de ODFE a OpenSearch, recomendamos primero actualizar a ODFE 1.13 y luego actualizar a OpenSearch 1.0.

Los recursos de migración están aquí:

Migraciones de análisis

Migración a Amazon OpenSearch Service

Todas las versiones del motor que se lanzan en OpenSearch Service están cubiertas por defecto por el soporte estándar. Como parte del soporte estándar, AWS ofrece correcciones de errores y actualizaciones de seguridad periódicas. Cuando finaliza el soporte estándar para una versión, AWS ofrece un período de soporte extendido de al menos 12 meses después de la fecha de finalización del soporte estándar. Durante el período de soporte extendido, AWS proporcionará correcciones de seguridad críticas y parches del sistema operativo. Esto le da más tiempo para planificar la actualización a una versión de motor compatible más reciente. Cuando ejecute una versión con soporte extendido, se le cobrará una tarifa plana/hora de instancia normalizada (NIH), además de los costos estándar de instancia y almacenamiento. Consulte la documentación para obtener más información sobre el soporte extendido y la programación de las distintas versiones. Para obtener información sobre precios, consulte la página de precios.

No. Los dominios que ejecuten versiones que hayan llegado al final del soporte estándar pasarán automáticamente a estar cubiertos por el soporte extendido y se les cobrará el precio correspondiente. Una vez que actualice su dominio a una versión más reciente con el soporte estándar, se dejará de facturar el soporte extendido.

A los dominios que cuenten con soporte extendido se les cobrará una tarifa fija adicional/hora de instancia normalizada (NIH), además del precio estándar de instancia y almacenamiento. Consulte la página de precios para ver los precios exactos por región. El soporte extendido se cobrará automáticamente a su dominio al día siguiente de la finalización del soporte estándar. Si su dominio ejecuta una versión con fechas de soporte estándar y extendido publicadas (consulte aquí para obtener más información), le enviaremos una notificación en su panel de salud personal, en la consola del servicio OpenSearch y a través de eventos de EventBridge, 3 meses antes de que finalice la fecha de soporte estándar. Para obtener más información sobre la supervisión de las notificaciones en OpenSearch Service, consulte la documentación aquí.

A los dominios que ejecuten versiones con soporte extendido se les cobrará una tarifa fija adicional/hora de instancia normalizada (NIH). Los NIH se calculan como un factor del tamaño de la instancia (por ejemplo, mediana o grande) y del número de horas de la instancia. Por ejemplo, si ejecuta una instancia de m7g.medium.search durante 24 horas en el este de EE. UU. (Virginia del Norte), cuyo precio es de 0,068 USD por hora (a petición), normalmente pagará 1,632 USD (0,068 x 24 USD) como costo de la instancia. Si está ejecutando una versión con soporte extendido, pagará 0,0065 USD/NIH adicionales, que se calculan como 0,0065 USD x 24 (número de horas de instancia) x 2 (factor de normalización del tamaño; 2 para instancias de tamaño mediano), lo que equivale a 0,312 USD para soporte extendido durante 24 horas. El importe total que pagará durante 24 horas será la suma del costo de uso estándar de la instancia (sin incluir el almacenamiento) y el costo de la asistencia ampliada, que es de 1,944 USD (1,632 USD+0,312 USD). Consulte la documentación para obtener más información.

Puede actualizar su dominio a una versión de motor que esté cubierta por el soporte estándar. Una versión está cubierta por el soporte estándar hasta la fecha de finalización publicada del soporte estándar o si no se ha anunciado ninguna fecha de finalización del soporte estándar para la versión.

No. Le recomendamos que actualice a una versión que esté cubierta por el soporte estándar o extendido o a una versión para la que no se haya anunciado el fin del soporte. Una vez que finalice el soporte extendido para una versión, los dominios que ejecuten esa versión específica no recibirán correcciones de errores ni actualizaciones de seguridad.

Una vez que finalice el soporte extendido para una versión, los dominios que ejecuten esa versión específica no recibirán correcciones de errores ni actualizaciones de seguridad. Le recomendamos encarecidamente que actualice su dominio a una versión compatible antes de que finalice el soporte extendido para una versión específica. Si necesita más ayuda, póngase en contacto con AWS Support.

Sí. Mientras la versión del motor que desea utilizar esté cubierta por el soporte extendido, puede seguir utilizando el servicio como de costumbre, sin restricciones.

Como parte del soporte extendido, AWS proporciona correcciones de seguridad críticas y parches del sistema operativo según sea necesario.

Sí, en función de la versión desde la que actualice y a la que esté actualizando. Consulte la documentación aquí para obtener una lista de las rutas de actualización compatibles. Cuando cambia de versiones antiguas, como ES 1.5 o ES 2.3, no admitimos las actualizaciones locales. Consulte la documentación aquí para obtener instrucciones sobre cómo actualizar sus dominios con versiones antiguas.

Esta integración sin ETL con Amazon DynamoDB reduce la complejidad operativa a la hora de organizar la replicación de datos desde un almacén de datos operativos a un almacén de datos de búsqueda. Las canalizaciones de datos que se utilizan para mantener sincronizados distintos almacenes de datos pueden resultar complicadas y costosas de crear y administrar, y presentan errores intermitentes difíciles de rastrear. Esta integración permite a los clientes de Amazon DynamoDB obtener resultados de búsqueda casi en tiempo real a partir de sus datos transaccionales al ofrecer una solución totalmente administrada para que los datos operativos de Amazon DynamoDB estén disponibles en Amazon OpenSearch Service a los pocos segundos de escribirse.

La integración sin ETL de Amazon OpenSearch Service con Amazon DynamoDB utiliza la ingesta de Amazon OpenSearch para transferir sin problemas los datos operativos de Amazon DynamoDB a Amazon OpenSearch Service. Para habilitar la integración, los clientes primero deben elegir la tabla de Amazon DynamoDB cuyos datos deben replicarse. La característica de integración sin ETL configura una canalización de ingesta de Amazon OpenSearch en la cuenta del cliente que se encarga de replicar los datos en un clúster administrado o una colección sin servidor de Amazon OpenSearch Service. La ingesta de Amazon OpenSearch comprende la estructura de las tablas de Amazon DynamoDB y, a continuación, ejecuta un clúster administrado o una colección sin servidor de Amazon OpenSearch Service con los datos existentes de las tablas de DynamoDB. De manera opcional, los clientes pueden especificar un esquema para los índices que se crearán en Amazon OpenSearch Service. Todas las actualizaciones de la tabla de DynamoDB también se replican en Amazon OpenSearch Service sin la intervención manual de los clientes.

Esta característica sin ETL utiliza la ingesta de Amazon OpenSearch para mover los datos de Amazon DynamoDB a Amazon OpenSearch Service y aprovecha las capacidades nativas de transformación de datos de las canalizaciones de la ingesta de Amazon OpenSearch para agregar y filtrar los datos mientras están en movimiento. Al trasladar los datos de una tabla de Amazon DynamoDB, es posible que los clientes deseen eliminar algunos campos o crear campos nuevos en función de las agregaciones en los campos existentes. Opcionalmente, los clientes también pueden escribir una lógica personalizada para la ingesta de Amazon OpenSearch a fin de lograr una capacidad de transformación personalizada. Para otros usuarios, que solo desean trasladar todos sus datos del origen al receptor, la ingesta de Amazon OpenSearch proporciona esquemas listos para usar para que puedan realizar las integraciones con tan solo unos pocos clics.

Para garantizar que la ingesta de Amazon OpenSearch cuente con los permisos necesarios para replicar los datos en estos dos sistemas, la característica de integración sin ETL crea un rol de IAM con los permisos necesarios para leer datos de las tablas de Amazon DynamoDB y escribir en un dominio o colección de Amazon OpenSearch. Luego, las canalizaciones de la ingesta de Amazon OpenSearch asumen este rol para garantizar que siempre se mantenga la postura de seguridad correcta al mover los datos del origen al destino.

Puede ver todas las métricas relacionadas con su integración sin ETL con Amazon DynamoDB en los paneles proporcionados por la ingesta de Amazon OpenSearch, junto con los registros en tiempo real de Amazon CloudWatch. Esto permite a los clientes configurar alertas personalizadas que se activan cuando se superan los umbrales definidos por el usuario.

El motor de consultas de OpenSearch Service se ha rediseñado para permitir el análisis de los datos operativos almacenados en almacenes de objetos en la nube, como Amazon S3 y lagos de datos basados en S3. Lo hace sin duplicar datos. Cuando los segundos marcan la diferencia, los clientes pueden aumentar el rendimiento de sus consultas y crear paneles de carga rápida mediante las capacidades de aceleración de consultas integradas en la nueva integración.

Para comenzar desde la consola de administración de AWS, los clientes configuran un nuevo origen de datos desde un dominio de OpenSearch Service existente que ejecute la versión 2.11 o una versión posterior de OpenSearch Service. Al configurar el nuevo origen de datos de Direct Query, los clientes deberán proporcionar acceso de lectura y escritura a Amazon S3 y al Catálogo de datos de AWS Glue para facilitar la consulta de datos en Amazon S3 desde OpenSearch Service. Los clientes pueden personalizar las políticas de IAM para restringir el acceso a buckets específicos en Amazon S3 o a los recursos del catálogo de datos de AWS Glue. Tras configurar el nuevo origen de datos en la consola, los clientes acudirán a OpenSearch Service para configurar controles de acceso basados en roles, aceleraciones para agilizar el rendimiento de las consultas y, opcionalmente, paneles listos para usar para plantillas de tipos de registro populares, como registros de flujo de VPC, registros del balanceador de carga elástico y registros de NGINX. A los clientes se les factura por los recursos de cómputo consumidos en forma de unidades informáticas de OpenSearch (OCU; se aplicarán tarifas de uso) de consulta directa. Tras configurar el nuevo origen de datos, los clientes pueden empezar a consultar sus datos directamente desde la API de OpenSearch o los paneles de OpenSearch.

Los clientes solo pagan por los recursos que consume su carga de trabajo. OpenSearch Service solo cobra por el cómputo necesario para consultar directamente datos externos, así como para mantener índices opcionales en OpenSearch Service. La capacidad de cómputo se mide en unidades de cómputo de OpenSearch (OCU), que son las mismas unidades que utilizan Amazon OpenSearch sin servidor y la ingesta de Amazon OpenSearch. La cantidad de OCU corresponde directamente a la vCPU y la memoria necesarias para consultar o mantener índices basados en los datos. Los clientes verán una entrada para el cómputo en horas de OCU con la etiqueta de consulta directa. Las OCU se facturan por hora con granularidad por minuto. Si no hay consultas ni actividades de indexación activas, no se consume ninguna OCU. Los costos de Amazon S3 o el catálogo de datos de AWS Glue se facturarán por separado en la cuenta del cliente. Para obtener más información sobre los precios, visite la página de precios de Amazon OpenSearch Service.