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
- Cuando un nodo de los nodos 3 a 7 está inactivo o cuando uno o dos nodos de los nodos 8 a 18 están inactivos:
- La vIP sigue disponible.
- El consumo y el reenvío de registros continúan funcionando.
- Las funcionalidades limitadas se ven afectadas. Por ejemplo, la consulta se ve afectada. Dado que no hay alta disponibilidad (HA) de registro, la consulta no incluye los resultados de los nodos que están inactivos.
- Cuando el nodo principal está inactivo, además del comportamiento anterior:
- Existen algunas limitaciones de la interfaz de usuario, como las estadísticas y los detalles de la página del clúster.
- No se pueden agregar nodos nuevos.
- No se pueden eliminar los nodos existentes.
- Cuando hay más nodos inactivos, el clúster presenta un estado incorrecto y las funcionalidades adicionales no están disponibles. Siempre que un nodo está activo y en ejecución, se pueden enviar registros directamente al nodo. El reenvío de registros y las consultas en ejecución en el nodo continúan funcionando.
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.
