Desplegar Elasticsearch y Kibana
Elasticsearch es un motor de búsqueda de código abierto y de grado empresarial. Accesible a través de una API extensa, Elasticsearch puede alimentar búsquedas rápidas que admiten sus aplicaciones de detección de datos. Puede escalar miles de servidores y acomodar petabytes de datos. Su gran capacidad resulta directamente de su elaborada arquitectura distribuida.
Los casos de uso más comunes para Elasticsearch son la analítica que utiliza extracciones de datos superrápidas de orígenes de datos estructurados y no estructurados, y la búsqueda de texto completo alimentada por un lenguaje de consulta extenso y autocompletación.
Arquitectura
Esta arquitectura de referencia muestra un despliegue en cluster de Elasticsearch y Kibana.

Descripción de la ilustración elk-oci.png
Esta arquitectura tiene los siguientes componentes:
- Dominios de disponibilidad
Los dominios de disponibilidad son centros de datos independientes e independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como energía o refrigeración, o la red de dominio de disponibilidad interna. Por lo tanto, es poco probable que un fallo en un dominio de disponibilidad afecte a los otros dominios de disponibilidad de la región.
- Dominios de Fallos
Un dominio de fallo es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad tiene tres dominios de fallos con energía y hardware independientes. Cuando distribuye recursos en varios dominios de fallos, las aplicaciones pueden tolerar fallos físicos del servidor, mantenimiento del sistema y fallos de energía dentro de un dominio de fallos.
- Host de Bastion
El host bastion es una instancia informática que sirve como punto de entrada seguro y controlado a la topología desde fuera de la nube. El host bastión se aprovisiona típicamente en una zona desmilitarizada (DMZ). Permite proteger los recursos sensibles colocándolos en redes privadas a las que no se puede acceder directamente desde fuera de la nube. La topología tiene un punto de entrada único y conocido que puede supervisar y auditar regularmente. Por lo tanto, puede evitar exponer los componentes más sensibles de la topología sin comprometer el acceso a ellos.
- Equilibrador de carga
El equilibrador de carga equilibra las operaciones de índice con los nodos de datos y el acceso de Kibana a los nodos maestros. Utiliza dos listeners, uno para Kibana y otro para acceso a datos de índice, mediante backends de nodo maestro y backends de nodo de datos. El equilibrador de carga está en una subred pública con una dirección IP pública.
- Nodos maestros
Los nodos maestros realizan tareas de gestión de cluster, como crear índices y reequilibrar particiones horizontales. No almacenan datos. Tres nodos maestros (recomendados para clusters más grandes) se despliegan en tres dominios de fallos para garantizar una alta disponibilidad.
- Nodos de datos
Tres nodos de datos se despliegan en tres dominios de fallos para una alta disponibilidad. Recomendamos instancias informáticas optimizadas para memoria porque Elasticsearch depende de la cantidad de memoria disponible. Cada nodo de datos está configurado con un almacenamiento de bloques GiB 200. Además de las máquinas virtuales, Oracle Cloud Infrastructure ofrece potentes instancias de hardware dedicado que están conectadas en clusters a una infraestructura de red de 25 Gb sin sobresuscripción. Esta configuración garantiza una baja latencia y un alto rendimiento, que proporcionan cargas de trabajo de transmisión distribuidas de alto rendimiento.
- Kibana
Al igual que los nodos maestros, Kibana tiene requisitos de recursos relativamente ligeros. La mayoría de los cálculos son empujados a Elasticsearch. En este despliegue, Kibana se ejecuta en los nodos maestros.
Recomendaciones
Sus requisitos pueden diferir de la arquitectura descrita aquí. Utilice las siguientes recomendaciones como punto de partida.
- VCN
Al crear un VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque en función del número de recursos que tiene previsto asociar a subredes en VCN. Utilice bloques CIDR que estén dentro del espacio de direcciones IP privadas estándar.
Después de crear un VCN, puede cambiar, agregar y eliminar sus bloques CIDR.
Cuando diseñe las subredes, tenga en cuenta sus requisitos de flujo de tráfico y seguridad. Conecte todos los recursos dentro de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
Utilice subredes regionales.
- Grupos de seguridad de red (NSG)
Puede utilizar NSG para definir un juego de reglas de entrada y salida que se aplican a VNIC específicas. Recomendamos utilizar NSG en lugar de listas de seguridad, porque los NSG permiten separar la arquitectura de subred de VCN de los requisitos de seguridad de la aplicación. En la arquitectura de referencia, toda la comunicación de red se controla a través de NSG.
- Almacenamiento de bloques
Esta arquitectura utiliza 200 GB de almacenamiento en bloque. Le recomendamos que configure un gestor de volúmenes lógico (LVM) para permitir que el volumen crezca si necesita más espacio. Cada volumen en bloque está configurado para utilizar un rendimiento equilibrado y proporciona IOPS de 35K y MBps 480 de rendimiento global.
- Formas informáticas
Esta arquitectura utiliza una forma de máquina virtual (VM.Standard2.24) para todos los nodos de datos. Estas instancias de cálculo pueden transferir tráfico a 25 Gbps y proporcionar 320 GB de RAM.
Consideraciones
- Rendimiento
Elasticsearch depende de la cantidad de memoria disponible. Para obtener el mejor rendimiento, utilice formas informáticas que le proporcionen una buena cantidad de memoria. Puede utilizar formas de metal desnudo, donde puede obtener hasta 768 GB de RAM.
- Disponibilidad
Los dominios de fallo proporcionan la mejor resiliencia dentro de un dominio de disponibilidad. Si necesita mayor disponibilidad, considere el uso de varios dominios de disponibilidad o varias regiones para su despliegue.
- Escalabilidad
Aunque puede escalar los nodos maestros y de datos manualmente dentro y fuera, recomendamos usar el autocaling para minimizar la posibilidad de que los servicios se mueran de hambre por los recursos bajo cargas altas. Una estrategia de autocalificación debe tener en cuenta tanto los nodos maestros como los de datos.
- Costo
El costo del despliegue de Elasticsearch depende de los requisitos de memoria y disponibilidad. Las formas informáticas que elija tienen un mayor impacto en los costos asociados con esta arquitectura.
Desplegar
El código necesario para desplegar esta arquitectura de referencia está disponible en GitHub. Puede extraer el código a Oracle Cloud Infrastructure Resource Manager con un solo clic, crear la pila y desplegarlo. También puede descargar el código de GitHub en el equipo, personalizar el código y desplegar la arquitectura mediante la CLI de Terraform.
- Desplegar mediante Oracle Cloud Infrastructure Resource Manager:
- Haga clic en
Si aún no ha iniciado sesión, introduzca las credenciales de arrendamiento y usuario.
- Revise y acepte los términos y condiciones.
- Seleccione la región en la que desea desplegar la pila.
- Siga las instrucciones y peticiones de datos en pantalla para crear la pila.
- Después de crear la pila, haga clic en Acciones de Terraform y seleccione Plan.
- Espere a que se complete el trabajo y revise el plan.
Para realizar cualquier cambio, vuelva a la página Detalles de Pila, haga clic en Editar Pila y realice los cambios necesarios. A continuación, vuelva a ejecutar la acción Plan.
- Si no son necesarios otros cambios, vuelva a la página Detalles de Pila, haga clic en Acciones de Terraform y seleccione Aplicar.
- Haga clic en
- Despliegue mediante la CLI de Terraform:
- Vaya a GitHub.
- Descargue o clone el código en su computadora local.
- Siga las instrucciones de
cluster/single-ad/README.md
.
Cambiar log
Este log muestra sólo los cambios significativos:
9 de diciembre de 2020 | Se han agregado instrucciones para desplegar la arquitectura mediante Oracle Cloud Infrastructure Resource Manager. |
29 de mayo de 2021 | Botón Desplegar en Oracle Cloud agregado. |
21 de junio de 2021 | Enlace del botón Desplegar en Oracle Cloud actualizado. |