Implemente Elastic en máquinas virtuales de Azure

  • 15 minutos

Las máquinas virtuales de Azure proporcionan a los usuarios de Azure una manera flexible de implementar sus workloads de Elastic nuevas y existentes en la infraestructura en la nube. Esta opción de implementación es mejor para los equipos que necesitan el mayor control sobre la infraestructura para cumplir las restricciones de arquitectura o cumplimiento, como los equipos cuyas cargas de trabajo deben implementarse dentro de su tenant de Azure.

Recuerde que el minorista emergente para el que trabaja usa actualmente Elastic local para administrar las transacciones de ventas. Les gustaría migrar a máquinas virtuales de Azure para mejorar la accesibilidad de los datos para los trabajadores remotos y otros departamentos, a la vez que reducen la carga de mantener la infraestructura.

Aquí, aprenderá los pasos para implementar una carga de trabajo de Elastic en máquinas virtuales de Azure. Los vínculos a las instrucciones a las que se hace referencia en esta unidad se encuentran en la sección Más información del resumen.

Elección del modelo de responsabilidad de implementación

Para una implementación en su propia suscripción de Azure en la infraestructura que controle, cree Azure máquinas virtuales Linux e instale Elasticsearch, Kibana y los componentes de ingesta necesarios mediante paquetes elásticos admitidos. Puede administrar actualizaciones del sistema operativo invitado y de aplicaciones, redes, certificados, control de acceso, capacidad, copias de seguridad y recuperación. Azure administra la infraestructura física subyacente.

Utilice Elastic Support Matrix y la política de versiones para elegir un sistema operativo compatible y una versión de Elastic con mantenimiento. Para una nueva instalación, use las versiones de Elastic Stack coincidentes siguiendo las instrucciones de compatibilidad de instalación. Un valor predeterminado de interfaz no es una directiva de soporte de versión.

En el caso de la infraestructura operada por Elastic, considere Elastic Cloud (Elasticsearch) - servicio ISV nativo de Azure. Cloud Hosted proporciona Elasticsearch administrado y Kibana con integración con Azure y facturación.

Note

El servicio administrado no implementa Elasticsearch en su inquilino de Azure. Un recurso de Azure vinculado no es la propiedad de las VM de respaldo. Elija máquinas virtuales autoadministradas cuando la infraestructura controlada por el cliente sea un requisito. Logstash puede enviar datos a Elastic Cloud, pero el flujo de incorporación del servicio administrado no es un instalador para una máquina virtual de Logstash propiedad del cliente.

Consulte las instrucciones sobre los límites de alojamiento de Azure Native y la conexión de Logstash a Elastic Cloud.

Comparar la alternativa de servicio administrado

La siguiente descripción general es opcional. No es necesario comprar el servicio administrado para completar el ejercicio de máquina virtual. Para comparar la alternativa de servicio administrado, siga estos pasos:

  1. Compruebe los requisitos previos actuales del servicio administrado, incluido el acceso de propietario o colaborador de nivel de suscripción y la elegibilidad de compra de Marketplace. Resuelva los requisitos de consentimiento del inquilino; el creador de la implementación no necesita universalmente ser un administrador del inquilino. No suponga que los créditos de prueba de Azure financian esta compra.
  2. Siga las instrucciones de Crear una aplicación de Elastic. Elija Cloud Hosted para esta comparación y, a continuación, la suscripción, el grupo de recursos, la región admitida y el plan apropiado. Revise los precios reales y los términos de facturación antes de Revisar + crear y Crear.
  3. Abra el despliegue a través de la integración y compruebe el acceso a Elasticsearch/Kibana. El recurso de integración del lado del cliente no es un conjunto de máquinas virtuales de Elasticsearch en su tenant. Logstash sigue siendo un remitente configurado por separado.
  4. Si se requiere acceso privado, siga las instrucciones de Elastic Azure Private Link, incluido el punto de conexión privado, DNS y la directiva de conexión del lado de Elastic. Un punto de conexión privado cambia la conectividad, no la propiedad ni la ubicación del servicio subyacente. Para Cloud Hosted, el inicio de sesión único de la consola de Elastic Cloud no inicia sesión a través del punto de conexión privado de Kibana; use la autenticación de pila admitida o un proveedor de identidades configurado por separado, tal como se describe en esa guía.
  5. Antes de la limpieza, inventaríe todas las implementaciones de la organización de Elastic y compruebe qué suscripción de Azure recibe su factura. Elimine los recursos creados por Azure a través de Azure y siga las instrucciones de eliminación de recursos de Elastic. Elimine solo las implementaciones previstas para el laboratorio; nunca elimine implementaciones no relacionadas para detener la factura de una organización compartida. Siga las restricciones de grupo de recursos de Elastic: no elimine el grupo de recursos de la primera implementación mientras se sigan facturando otras implementaciones a ese grupo.
  6. Inspeccione por separado la suscripción de SaaS de Marketplace y sus términos de contrato. Si se trata de una suscripción de SaaS de laboratorio dedicada, cancele mediante el procedimiento de ciclo de vida de SaaS aplicable. Al eliminar un grupo de recursos o incluso la última implementación, no se establece que se canceló la suscripción comercial.

Aprovisionar e instalar

Cree las máquinas virtuales, el almacenamiento persistente y los controles de red en un grupo de recursos dedicado. Establezca la conectividad de administrador y el acceso saliente explícito para la instalación del paquete. En Ubuntu, siga la guía de Elasticsearch Debian y, a continuación, la guía de Kibana Debian. Configure Logstash opcionalmente por separado.

CLI de Azure y Azure PowerShell pueden automatizar el aprovisionamiento de recursos Azure; también se debe implementar la instalación y configuración del software de Elastic. El aprovisionamiento de una máquina virtual de Azure solo no crea un clúster de Elasticsearch en funcionamiento.

El ejercicio usa una configuración deliberadamente pequeña de cuatro máquinas virtuales: tres nodos de Elasticsearch y un host de Kibana, cada uno con 2 vCPU, 8 GiB RAM y almacenamiento administrado persistente. Proporciona versiones fijas de paquetes, un plan de direcciones privadas, reglas de NSG explícitas y un certificado del navegador independiente. Esto hace que el procedimiento de aprendizaje sea concreto; no hace que esos tamaños sean una recomendación de dimensionamiento para producción.

Dimensionar y hacer la implementación resiliente

Utilice Rally en un entorno de prueba independiente para evaluar cargas de trabajo representativas. Tenga en cuenta el heap de Elasticsearch, la memoria fuera del heap, la caché del sistema de archivos, la capacidad y las IOPS del almacenamiento y el margen para errores. Prefiere el ajuste de tamaño automático predeterminado a menos que tenga un motivo justificado para anularlo.

Tres nodos de datos que también son elegibles como maestros son un punto de partida razonable para clústeres pequeños. En el caso de los índices normales, asegúrese de que haya al menos una réplica asignada y que los clientes puedan llegar a más de un nodo o un punto de conexión con equilibrio de carga adecuado. Tres nodos elegibles como maestros pueden conservar una mayoría de votación después de que falle un nodo. El recuento de nodos por sí solo no garantiza la resistencia de la zona de disponibilidad ni reemplaza las snapshots. Consulte la guía sobre la resiliencia de clústeres pequeños y los roles de los nodos.

Para la disponibilidad de Kibana de producción, use varias instancias con el equilibrio de carga adecuado y una configuración coherente.

Importante

Las instancias de Kibana que comparten un despliegue deben tener los mismos valores de xpack.security.encryptionKey, xpack.reporting.encryptionKey y xpack.encryptedSavedObjects.encryptionKey, además de la misma autenticación y configuración de sesión. Coordine la rotación de claves y la configuración de cookies como se describe en la guía de alta disponibilidad de Kibana. Una segunda máquina virtual configurada de forma independiente no es suficiente.

Logstash es opcional. Impleméntela cuando el diseño de la ingesta necesite sus funcionalidades de entrada, filtrado, enrutamiento o almacenamiento en búfer. La disponibilidad de producción requiere algo más que instalar dos copias: configurar entradas para el equilibrio de carga o la conmutación por error, colas persistentes adecuadas, autenticación de salida y TLS. Siga las instrucciones de implementación y escalado de Logstash. Las colas persistentes son locales para cada instancia; no describa un par de instancias como una cola compartida replicada.

Configuración de identidades y conexiones cifradas

Elasticsearch proporciona un superusuario predefinido elastic . Otros usuarios integrados tienen fines específicos de servicio o supervisión; no eliges sus nombres. Use la inscripción actual de Kibana para configurar la conexión de Kibana con Elasticsearch. Cree identidades con ámbito adecuado o claves de API para aplicaciones, ingesta y acceso humano. En particular, logstash_system es una identidad de supervisión, no una identidad de salida de canalización.

Importante

La autenticación y el cifrado son independientes. Confirme el transporte de Elasticsearch TLS y HTTPS para la API REST, asegúrese de que los clientes confían en la entidad de certificación adecuada y configure HTTPS para el tráfico de explorador a Kibana por separado. La configuración de seguridad automática de Elasticsearch no habilita automáticamente el punto de conexión HTTPS del explorador de Kibana. Restrinja el acceso a la red además de configurar TLS; no resuelva nunca los errores de certificado deshabilitando la verificación.

Consulte las instrucciones sobre los usuarios integrados, la configuración automática de seguridad y sus excepciones, Kibana HTTPS y la seguridad de Logstash.

Decidir si este modelo se ajusta al minorista

Use las VM autoadministradas si los sistemas operativos invitados y la infraestructura controlados por el cliente son requisitos y el equipo puede operarlos. Mover las máquinas virtuales a Azure elimina la administración de hardware físico, no la responsabilidad del sistema operativo invitado, las actualizaciones de Elastic, las instantáneas, los certificados o la capacidad. Si reducir esas responsabilidades operativas es el requisito más sólido, evalúe Elastic Cloud en su lugar. En cualquier caso, prepare y compruebe un plan de migración de datos independiente antes de mover la carga de trabajo existente del minorista.