Recomendamos encarecidamente que todos los usuarios de Búsqueda de aplicaciones mantengan sus implementaciones actualizadas con la última versión disponible para tener acceso a nuevas funciones, actualizaciones de seguridad y mejoras de rendimiento. Esta guía está diseñada para ayudar a los clientes a través del proceso de actualización, para minimizar el impacto de una actualización en los entornos de producción y para garantizar la seguridad de los datos durante una actualización. Finalmente, la guía ayuda a los usuarios de App Search a solucionar cualquier problema que pueda ocurrir durante una actualización.

Pssst ... ¿Está buscando instrucciones para actualizar de 7.5 a 7.6? ¡Lee la guía!

Antes de que empieces

Antes de intentar una actualización de un clúster de Búsqueda de aplicaciones a una versión más nueva, debe seguir algunos pasos para garantizar la seguridad de sus datos y aumentar la probabilidad de una actualización exitosa:

1. Antes de actualizar los servidores de producción, pruebe las actualizaciones en un entorno de desarrollo para familiarizarse con el proceso.
   • El uso de una instantánea Elasticsearch creada a partir de una implementación de producción puede ser la mejor opción para probar completamente el proceso de actualización sin arriesgar la disponibilidad del servicio o la consistencia de los datos.
2. Deje de escribir en su clúster Elasticsearch:
   • Si ejecuta App Search versión 7.6 o posterior, habilite el modo de solo lectura para garantizar una instantánea coherente de sus datos.
   • Para las versiones anteriores a la 7.6, detenga manualmente todas las operaciones de escritura / indexación en su clúster en la fuente.
3. Haga una copia de seguridad de sus datos con instantáneas de Elasticsearch . Para volver a una versión anterior de Búsqueda de aplicaciones, debe tener una copia de seguridad de sus datos almacenados en Elasticsearch.

Resumen del proceso de actualización

La forma en que actualice la Búsqueda de aplicaciones dependerá de muchos factores:

• El modo de implementación, ya sea autogestionado o Elastic Cloud
• Su capacidad para crear instantáneas de Elasticsearch y recuperarse de ellas
• Recursos disponibles. ¿Puede activar un nuevo clúster de Elasticsearch y / o nuevas instancias de Búsqueda de aplicaciones mientras se ejecuta la infraestructura anterior?

A continuación describiremos diferentes escenarios para el proceso de actualización, pero primero, aquí hay una descripción general del proceso de actualización de Búsqueda de aplicaciones para ayudarlo a navegar por los diferentes enfoques descritos más adelante en esta guía:

• La Búsqueda de aplicaciones usa Elasticsearch como su único almacén de datos. El clúster Elasticsearch se usa para datos de capa de control (motores, configuraciones, etc.), documentos, índices de búsqueda, registros de API y eventos analíticos.
• Cada vez que se inicia una nueva instancia de Búsqueda de aplicaciones, verifica cada índice dentro del clúster Elasticsearch para ver si necesita actualizarse a una versión más nueva. Cuando su estructura cambia, tenemos que reindexar los datos almacenados en un índice. 
• Todas las actualizaciones se realizan de forma no destructiva y se realizan automáticamente. Los índices existentes nunca se eliminan y solo creamos nuevos índices con una copia de los datos.
• Si hay varias instancias de Búsqueda de aplicaciones que comienzan en un solo clúster de Elasticsearch, utilizarán un mecanismo de bloqueo distribuido para coordinar el proceso de actualización y garantizar que se realice de manera coherente. Creamos un registro de bloqueo de instalación en Elasticsearch para hacer esto.
• Hasta que se complete el proceso de actualización, la nueva versión de Búsqueda de aplicaciones no comenzará a atender solicitudes de API.

Dados los detalles del proceso de actualización descrito anteriormente, hay algunas opciones diferentes disponibles para realizar una actualización de una implementación de Búsqueda de aplicaciones en función de su capacidad para manejar el tiempo de inactividad de Búsqueda de aplicaciones durante una actualización y para cambiar la configuración del cliente de Búsqueda de aplicaciones después de una actualización:

1. Actualización simple en el lugar (con tiempo de inactividad, sin cambios del lado del cliente) : reemplace un conjunto de instancias de Búsqueda de aplicaciones con un nuevo conjunto que ejecute una versión más nueva. En otras palabras, debería cerrar la instancia, actualizar los paquetes, luego iniciarla nuevamente y dejar que las instancias migren los datos si es necesario. 
2. Actualizaciones basadas en instantáneas (sin tiempo de inactividad, se necesitan cambios en el lado del cliente) : cree una instantánea de un clúster Elasticsearch utilizado por App Search, restaure la instantánea en un nuevo clúster Elasticsearch y luego inicie la Búsqueda de aplicaciones en el nuevo clúster.
3. Actualizaciones in situ en modo de solo lectura (tiempo de inactividad de escritura, sin cambios en el lado del cliente) : cambie un clúster al modo de solo lectura, inicie nuevas instancias de Búsqueda de aplicaciones para realizar la actualización, cierre instancias antiguas y elimine el modo de solo lectura .

Desafortunadamente, no podemos prescribir la mejor ruta de actualización para su situación específica. Dependerá de sus requisitos para la disponibilidad del servicio de Búsqueda de aplicaciones, de las capacidades de la plataforma que está utilizando para administrar la implementación y de los recursos disponibles, etc. Consulte los detalles a continuación para comprender mejor los pros y los contras de cada ruta de actualización.

Actualización en el lugar con tiempo de inactividad

Si puede manejar el tiempo de inactividad del servicio de búsqueda de aplicaciones, el método de actualización más fácil es una actualización en el lugar. Recomendamos este método a todos los clientes que puedan programar una ventana de mantenimiento para su servicio o para aplicaciones que no sean de misión crítica basadas en la Búsqueda de aplicaciones.

Este método de actualización tiene algunas características que lo hacen excepcionalmente adecuado para muchas implementaciones:

• No es necesaria una nueva infraestructura : todo se hace en el lugar y no es necesario aprovisionar ninguna instancia nueva de Elasticsearch o App Search.
• No es necesario cambiar las configuraciones del cliente : todos sus clientes API pueden usar los mismos puntos finales API antes y después de la actualización, ya que las nuevas instancias de App Search simplemente reemplazarán a las existentes.

Las desventajas de este método:

• Se requiere tiempo de inactividad : debe cerrar todas sus instancias de Búsqueda de aplicaciones para realizar la actualización y su servicio no estará disponible hasta que se complete la actualización. Con una planificación adecuada, el período de inactividad puede reducirse significativamente, pero el tiempo de inactividad sigue siendo inevitable.
• Más difícil de revertir : si su actualización falla por algún motivo, no recomendamos volver a la versión anterior de Búsqueda de aplicaciones debido a posibles problemas con el conjunto de datos parcialmente migrado en Elasticsearch. Tendría que restaurar desde una copia de seguridad para volver a su estado original, lo que prolongaría el tiempo de inactividad.

Estos son los pasos simples que debe seguir:

1. Detenga TODAS sus instancias de Búsqueda de aplicaciones.
2. Haga una copia de seguridad de sus datos de Elasticsearch, utilizando instantáneas .
3. Actualice los paquetes de búsqueda de aplicaciones en sus servidores o cambie las etiquetas de imagen del contenedor para que apunten a la última versión si usa Docker o Kubernetes.
4. Inicie la nueva versión de App Search, y las nuevas instancias se encargarán de coordinar y realizar la actualización antes de iniciar y aceptar su tráfico API.

Actualizaciones basadas en instantáneas

Para situaciones en las que el tiempo de inactividad de la Búsqueda de aplicaciones no es aceptable o en los casos en que desea garantizar una reversión, sin importar lo que ocurra durante una actualización, la forma más segura de realizar la actualización es mediante la clonación de una implementación basada en instantáneas.

Como puede ver, este proceso es mucho más complicado, pero garantiza la consistencia de los datos y le permite realizar una migración sin un tiempo de inactividad de la API de búsqueda. Estas son las ventajas de este método:

• No se requiere tiempo de inactividad de la API de búsqueda : tanto la implementación anterior de App Search como la nueva pueden manejar el tráfico de búsqueda durante todo el proceso de actualización, lo que significa que sus clientes no deberían notar la migración en absoluto.
• Fácil de revertir : si observa algún problema con la nueva implementación (B) de la Búsqueda de aplicaciones, puede volver a intentar la migración tantas veces como sea necesario, ya que su implementación original sigue siendo funcional.

El método tiene algunas desventajas importantes:

• La necesidad de infraestructura adicional : debe aprovisionar un nuevo clúster de Elasticsearch e implementar un conjunto de nuevas instancias de Búsqueda de aplicaciones durante la actualización. Esto requiere un poco de coordinación y recursos informáticos adicionales durante el proceso de actualización.
  • Para algunas implementaciones, es posible reducir los clústeres Elasticsearch y App Search antes de usar el hardware liberado para proporcionar nuevas instancias, pero los detalles de esa operación están más allá del alcance de esta guía.
• La necesidad de cambiar la configuración del cliente : sus clientes API deben cambiarse al nuevo punto final de implementación después de realizar la actualización. 
  • Tenga en cuenta: puede enviar su tráfico a través de un equilibrador de carga (ELB, ALB, etc.) o un CDN para mantener estable su punto final de API mientras reemplaza el clúster de búsqueda de aplicaciones detrás del proxy.

Estos son los pasos que debe seguir:

1. Dejar de escribir en su implementación de búsqueda de aplicaciones (A):
   1. A partir de 7.6.0, puede usar la función de solo lectura de Búsqueda de aplicaciones para bloquear la implementación y garantizar una migración consistente.
   2. Para todas las versiones inferiores a 7.6.0, debe detener las escrituras manualmente (deshabilitar sus trabajos de indexación, etc.) o usar la API Elasticsearch para poner un bloqueo de escritura en todos los índices de Búsqueda de aplicaciones.
2. Cree una copia de seguridad de su clúster Elasticsearch (A) utilizando instantáneas.
3. Cree un nuevo clúster Elasticsearch (B) y restaure datos de la última instantánea.
4. Implemente un nuevo conjunto de instancias de Búsqueda de aplicaciones (B) utilizando el nuevo clúster Elasticsearch (B) como el almacén de datos.
5. En este punto, debe tener dos implementaciones de búsqueda de aplicaciones separadas, ambas con los mismos datos. Debe verificar para asegurarse de que la nueva implementación (B) le parezca correcta.
6. Cambie el tráfico API de la implementación original de Búsqueda de aplicaciones (A) a la nueva (B).
7. Cierre los viejos clústeres de Búsqueda de aplicaciones y Elasticsearch.

Actualización in situ con modo de solo lectura (solo 7.6)

Finalmente, para situaciones en las que no tiene la capacidad de aprovisionar una nueva infraestructura durante una actualización, pero programar el tiempo de inactividad de la Búsqueda de aplicaciones no es una opción, a partir de la Búsqueda de aplicaciones 7.6.1 puede realizar una actualización en el lugar usando solo lectura de la Búsqueda de aplicaciones modo .

Este método tiene las siguientes ventajas:

• No se requiere tiempo de inactividad de la API de búsqueda: las instancias de búsqueda de aplicaciones antiguas y nuevas pueden manejar el tráfico de búsqueda durante todo el proceso de actualización, lo que significa que los clientes no deberían verse afectados por la migración.
• No es necesario cambiar las configuraciones del cliente : todos sus clientes API pueden usar los mismos puntos finales API antes y después de la actualización, ya que las nuevas instancias de Búsqueda de aplicaciones simplemente reemplazarán a las existentes.
• No es necesaria una nueva infraestructura : todo se puede hacer en el lugar y no es necesario aprovisionar ninguna instancia nueva de Elasticsearch o App Search.

La única desventaja comparativa de este método de actualización es que hace que sea más difícil retroceder si la actualización falla por algún motivo. Si experimenta algún problema durante la actualización, no recomendamos habilitar las escrituras en la versión anterior de Búsqueda de aplicaciones debido a posibles problemas con el conjunto de datos parcialmente migrado en Elasticsearch. Tendría que restaurar desde una copia de seguridad para volver a su estado original, lo que puede requerir tiempo de inactividad.

Estos son los pasos que debe seguir:

1. Dejar de escribir en su implementación de búsqueda de aplicaciones:
   1. Si es posible, detenga sus solicitudes de indexación en la fuente (deshabilite las tareas de indexación, etc.).
   2. Habilite el modo de solo lectura en su clúster de Búsqueda de aplicaciones.
2. Haga una copia de seguridad de sus datos de Elasticsearch (usando instantáneas).
3. Inicie un nuevo conjunto de instancias de Búsqueda de aplicaciones que ejecuten la última versión del producto:
   1. Puede realizar una actualización continua: detener, actualizar e iniciar una instancia a la vez.
   2. O bien, puede aprovisionar una nueva flota completa de instancias de Búsqueda de aplicaciones.
4. Las nuevas instancias de búsqueda de aplicaciones realizarán una actualización y luego estarán disponibles para servir su tráfico de API de búsqueda.
5. Una vez que se estén ejecutando nuevas instancias de App Search, detenga las instancias anteriores de App Search.
6. Finalmente, elimine el modo de solo lectura del clúster y vuelva a habilitar sus trabajos de indexación. Es posible que deba volver a intentar cualquier solicitud de indexación que pueda haber fallado durante la actualización.

Actualizaciones en Elastic Cloud

Al implementar la Búsqueda de aplicaciones en Elastic Cloud, tiene acceso a dos rutas de actualización separadas según su tolerancia al tiempo de inactividad de la Búsqueda de aplicaciones:

1. La ruta de actualización predeterminada (a través de Cloud Console) se realiza en el lugar mediante un reinicio completo del clúster, lo que significa que la Búsqueda de aplicaciones no estará disponible durante la actualización. En futuras versiones de Búsqueda de aplicaciones, este modo permitirá actualizaciones en el lugar a través del modo de solo lectura , pero a partir de 7.6.0 se requiere tiempo de inactividad.

2. Si el tiempo de inactividad es inaceptable para su caso de uso, recomendamos un proceso de actualización basado en instantáneas , que implica tomar una instantánea de su implementación (idealmente en modo de solo lectura ) y luego crear una nueva implementación de Búsqueda de aplicaciones a partir de la instantánea utilizando una Búsqueda de aplicaciones más nueva versión. Tenga en cuenta: El proceso de actualización basado en instantáneas requiere cambios del lado del cliente para cambiar a los usuarios a otra implementación, pero garantiza la disponibilidad del servicio durante el proceso de actualización. Si desea mantener estable la configuración de su cliente, puede proxy su tráfico API a través de un equilibrador de carga (ELB, ALB, etc.) o un punto final CDN.

Tenga en cuenta: si está utilizando Elastic Cloud o ECE versiones 2.4.0 a 2.4.4, existe un problema conocido con las actualizaciones de la Búsqueda de aplicaciones de las versiones 7.5 a 7.6 (las actualizaciones sucesivas podrían provocar una pérdida limitada de datos si modifica activamente nuevos motores durante el proceso de actualización). Como solución alternativa, antes de actualizar las instancias de Búsqueda de aplicaciones 7.5 a 7.6, puede detener el tráfico hacia esas instancias haciendo clic en el botón Detener enrutamiento en la IU. Una vez que todas las instancias 7.5 ya no estén enrutando el tráfico, es seguro realizar la actualización haciendo clic en el botón Actualizar .

Solución de problemas de actualizaciones de Búsqueda de aplicaciones

Al igual que con cualquier actualización de software, siempre existe la posibilidad de que las cosas no salgan según el plan. Esto significa que debe planificar y prepararse para la posibilidad de que falle la actualización de la Búsqueda de aplicaciones. Puede revisar la comparación de los diferentes métodos de actualización anteriores y asegurarse de que se sienta cómodo con los riesgos asociados con su método de actualización preferido antes de comenzar el proceso de actualización.

Si experimenta una falla en la actualización, la información a continuación lo ayudará a identificar las causas del problema y le permitirá volver a intentar la actualización si es necesario. La Búsqueda de aplicaciones debería poder recuperarse de muchas fallas potenciales, lo que significa que debería poder volver a intentar una actualización si falla.

Si falla la actualización de la Búsqueda de aplicaciones, haga lo siguiente:

1. Consulte los registros de la aplicación App Search de la nueva implementación: log / app-search.log o /var/log/app-search/app-search.log, para ver los detalles de lo que sucedió.

2. Si la actualización falló debido a un problema con Elasticsearch que puede solucionar, hágalo y vuelva a intentar la actualización iniciando nuevamente una nueva instancia de Búsqueda de aplicaciones.

3. Si el proceso falla constantemente, retroceda utilizando un método específico para su ruta de actualización preferida.

4. Capture el archivo app-search.log y presente un caso de soporte con Elastic si necesita más ayuda para solucionar el proceso de actualización.