Puede implementar vRealize Log Insight con un solo nodo, un solo clúster o un clúster con reenviadores.
Instalación mediante vRealize Suite Lifecycle Manager
vRealize Suite Lifecycle Manager automatiza las operaciones de instalación, configuración, actualización, revisión, administración de configuración, solución de desviaciones y mantenimiento de los productos en paquetes. Como alternativa a la instalación con vRealize Log Insight, puede instalar vRealize Log Insight mediante vRealize Suite Lifecycle Manager. Debe usar vRealize Suite Lifecycle Manager 1.2 o una versión posterior y vRealize Log Insight 4.5.1 o posterior. Consulte la Documentación de vRealize Suite Lifecycle Manager para obtener más información.
Nodos únicos
Una configuración básica de vRealize Log Insight incluye un solo nodo. Los orígenes de registro pueden ser aplicaciones, registros de SO, registros de máquinas virtuales, hosts, vCenter Server, conmutadores y enrutadores físicos o virtuales, hardware de almacenamiento, etc. Los flujos del registro se transportan al nodo vRealize Log Insight usando syslog (UDP, TCP, TCP+SSL) o CFAPI (el protocolo de consumo nativo vRealize Log Insightmediante HTTP o HTTPS), ya sea en forma directa mediante una aplicación, mediante un concentrador de syslog o mediante el agente de vRealize Log Insight instalado en el origen.
Como práctica recomendada para las implementaciones de un único nodo, se recomienda usar el equilibrador de carga integrado (ILB) de vRealize Log Insight y enviar las consultas y el tráfico de consumo al ILB. Si desea agregar nodos y crear un clúster para la implementación en el futuro, esto no supone una sobrecarga y simplifica la configuración.
Como práctica recomendada, no utilice nodos únicos para los entornos de producción.
Clústeres
Por lo general, los entornos de producción requieren el uso de clústeres. Los clústeres deben cumplir los requisitos siguientes:
- Todos los nodos de los clústeres deben tener el mismo tamaño y estar en el mismo centro de datos.
- El ILB usado con los clústeres requiere que todos los nodos estén en la misma red de Capa 2.
- Las máquinas virtuales de vRealize Log Insight se deben excluir de la protección de VMware NSX Distributed Firewall.
El motivo es que las IP virtuales de los clústeres usan Linux Virtual Server en modo retorno de servidor directo (LVS-DR) para equilibrar la carga. El retorno de servidor directo es más eficaz que enrutar todo el tráfico de respuesta a través de un único miembro del clúster. Sin embargo, también puede parecer tráfico falsificado, que NSX Distributed Firewall bloquea.
Dimensionamiento de clústeres
Una configuración de clúster único de vRealize Log Insight puede incluir de 3 a 18 nodos. La disponibilidad de la función depende del cuórum (número mínimo de nodos en línea/en buen estado), como se describe en la siguiente tabla.
| Número de nodos | Cuórum | Número de nodos que pueden fallar |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7-18* | 4 | 3 |
*Para los clústeres que contienen de 7 a 18 nodos, el cuórum es 4 y 3 nodos pueden fallar.
- La tabla muestra el cuórum que se admite ahora. La columna de cuórum muestra la cantidad mínima de nodos en línea/en buen estado que los clústeres necesitan para proporcionar funcionalidades básicas, como la ingestión de eventos de registro.
- Un clúster se considera en mal estado y no se garantiza que funcione ninguna característica si no se cumple el cuórum.
Para obtener más información sobre el tamaño, consulte Dimensionar el dispositivo virtual de vRealize Log Insight.
Clústeres con reenviadores
Una configuración de clúster de vRealize Log Insight con reenviadores incluye la indexación principal, el almacenamiento y un clúster de consultas con entre 3 y 18 nodos que usan el ILB. Aparece un mensaje de registro en una única ubicación dentro del clúster principal, al igual que sucede con un solo clúster.
El diseño se extiende a través de la adición de múltiples clúster de reenviadores en sitios remotos de clústeres. Cada clúster de reenviador se configura para reenviar todos sus mensajes de registro al clúster principal. Al mismo tiempo, los usuarios se conectan a dicho clúster, aprovechando CFAPI para la compresión y la resiliencia de la ruta de acceso de reenvío. Los clústeres de reenviadores configurados como parte superior del bastidor pueden configurarse con una retención local más grande.
Reenvío para redundancia
Este escenario de implementación de vRealize Log Insight incluye un clúster con reenviador que se extiende y espejea. Se usan dos clústeres principales para indexación, almacenamiento y consulta. Hay un clúster principal en cada centro de datos. Cada uno tiene una conexión front-end con un par de clústeres de reenviadores dedicados. Todos los orígenes de registro de todas las agregaciones de la parte superior del bastidor se concentran en los clústeres de reenviadores. Puede consultar independientemente los mismos registros en ambos clústeres de retención.
Equilibrador de carga integrado de vRealize Log Insight
Para equilibrar el tráfico correctamente entre los nodos de un clúster y para minimizar la sobrecarga administrativa, use el equilibrador de carga integrado (ILB) en todas las implementaciones. Esto garantiza que el tráfico de consumo entrante se acepte, aunque algunos nodos de vRealize Log Insight no estén disponibles.
