🇪🇸
Omnileads Docs
ComunidadForo
Español
Español
  • 👶Introducción a OMniLeads
    • Características Generales de OMniLeads
    • Arquitectura y componentes
  • 🚀Instalación de OMniLeads
    • Deploy utilizando Docker
      • Deploy en Docker-Destkop
      • Deploy en Docker para VPS Cloud o VM
      • Deploy en Docker para VPS Cloud o VM con Bucket Externo
    • Deploy utilizando Ansible
      • Deploy en AIO (All-In-One)
      • Deploy en AIT (All-In-Three)
      • Deploy en HA (High Availability)
      • Backups, Restores, Upgrades y Rollbacks
      • Migración desde CentOS7
    • OMniLeads Enterprise
    • Deploy en Entornos de Desarrollo
    • First Login
    • Certificados TLS/SSL
    • Monitoreo y Observabilidad
    • Consideraciones de Seguridad
  • ⚙️Configuración inicial
  • 🪪Autenticación LDAP
  • 🎞️Video Llamadas (Pro)
    • Configuración Inicial
    • Wordpress Plugin
    • Webphone Demo
    • Embebiendo el Webphone
  • 🎯CX Survey (Pro)
    • Reportería
  • 📈Reportes Premium (Pro)
    • Reportes de Actividad
    • Analizando Resultados
  • 🔊Text To Speech - TTS (Pro)
  • ☎️Configuración del Canal de Voz
    • Parámetros generales del SIP trunk
  • 🆗Configuración del Canal de Whatsapp (Pro)
    • OMniLeads y GupShup
    • Dar de Alta Whatsapp Business en GupShup
    • Plantillas de Mensajes y Grupos Horarios
    • Proveedores
    • Lineas
  • 🚧Wallboard for Business (Pro)
    • Creación de un Wallboard
    • Agregando Widgets y Páginas "realtime"
    • Explorando Widgets y Métricas
  • 📤Mensajes Masivos (Pro)
    • Creación de Envios
    • Campañas de Turnos
    • Exportación de Resultados
  • 💬Campañas de Contacto
    • Campaña Entrante
      • Enrutamiento de llamadas entrantes
      • Derivación de llamadas entrantes desde la PBX hacia OMniLeads
      • Enrutamiento condicionado por rango de tiempo
      • IVR - Interactive Voice Response
      • Identificación de llamada entrante
      • Ejecución de dialplan personalizado
    • Campaña Manual
    • Campaña Preview
    • Campaña Dialer
    • Campaña de Whatsapp
  • 🎧Manual de agente
    • Login Logout
    • Llamadas manuales desde listado de contactos
    • Llamadas preview
    • Llamadas en dialer
    • Llamadas entrantes
    • Llamadas entre agentes
    • Listado de Contactos
    • Mensajes de Whatsapp
  • 🛑Métricas, grabaciones y supervisión
    • Grabaciones
    • Reportes de campañas entrantes
    • Reportes de campañas salientes
    • Reporte general de llamadas
    • Reportes de agente
    • Reportes de Whatsapp
    • Reportes de Conversaciones
    • Supervisión
  • 📊Auditoría de gestiones
  • ☎️Integración entre OMniLeads y PBXs
  • 🛠️Gestiones del administrador IT
  • 🧩Integración con CRM
    • Interacción desde OMniLeads hacia el CRM
    • Interacción desde el CRM hacia OMniLeads
  • 🔐Consideraciones sobre seguridad
  • 📌OMniLeads RESTful API
    • API de sesión de Agente en Asterisk
  • 🗒️Release Notes
  • ❤️Comunidad
  • 🎇Acerca De
Con tecnología de GitBook
En esta página
  • OMniLeads en un Cluster HA
  • Comprendiendo el Archivo de Inventario
  • Ahora sí, manos a la Obra!
  1. Instalación de OMniLeads
  2. Deploy utilizando Ansible

Deploy en HA (High Availability)

Última actualización hace 1 año

OMniLeads en un Cluster HA

Mediante este método de instalación, es posible desplegar la Suite de OMniLeads en una disposición de Cluster de Alta Disponibilidad, agrupando contenedores según el siguiente esquema:

Para ello, se requieren de cuatro instancias de Linux (con cualquier sistema operativo moderno) con acceso a Internet. Dado que Ansible utiliza un proceso de conexión SSH (secure shell) para acceder a la instancia y ejecutar su playbook, es requisito obligatorio contar con la llave pública SSH y el archivo known_hosts configurado oportunamente en cada host.

Comprendiendo el Archivo de Inventario

Debajo se especifica un archivo de inventario genérico para un típico despliegue en el esquema de Cluster HA. En su primera sección se listan los diferentes hosts por tenant y por tipo de deployment a ejecutar (ha_instances):

En su segunda sección, el archivo de inventario permite parametrizar variables de entorno necesarias para la acción. Nota: Por default, todas ellas afectan de manera directa a TODAS las instancias declaradas, a menos que una variable (o grupo de variables) sea especificada en la sección del host (o grupo de hosts) en cuestión.

Finalmente, la última sección comprende a la agrupación de hosts en función de la arquitectura seleccionada. En nuestro caso, bajo las etiquetas omnileads_aio y ha_omnileads_sql, se listarian los hosts correspondientes a la/s instancia/s que se pretende/n deployar ("_aio" hará referencia a los nodos A y B de HA para Aplicación, mientras que "_sql" hará referencia a los nodos read-only y read-write de PostgreSQL).

Debajo se muestra un ejemplo:

#############################################################################################################
# -- In this section the hosts are grouped based on the type of deployment (AIO, Cluster & Cluster HA).     #
#############################################################################################################

omnileads_aio: 
  hosts:
    #tenant_example_1:
    #tenant_example_2:
    #tenant_example_3:
    #tenant_example_4:
    #tenant_example_7_aio_A:
    #tenant_example_7_aio_B:

################################################    
omnileads_data:   
  hosts:
    #tenant_example_5_data:  
    
omnileads_voice:
  hosts:
    #tenant_example_5_voice:

omnileads_app:
  hosts:
    #tenant_example_5_app:

################################################
ha_omnileads_sql:
  hosts:
    #tenant_example_7_sql_A:
    #tenant_example_7_sql_B:

Ahora sí, manos a la Obra!

Como primer paso, procedemos a crear la carpeta instances en el directorio raíz. Seguido a ello, en su interior crearemos una subcarpeta donde alojaremos el archivo de inventario de ejemplo provisto por el repositorio:

Nota: Si bien estamos dentro de un repositorio versionado, el nombre "instances" está reservado y es ignorado por el repositorio a partir del archivo .gitignore.

mkdir instances
mkdir instances/omlclusterha
cp inventory.yml instances/omlclusterha

De acuerdo a lo comprendido en las secciones del archivo de inventario, declararemos nuestra futura instancia de OMniLeads en HA en la sección de ha_instances. En nuestro caso, usaremos el nombre de ejemplo "eucalipto" para definir el tenant:

    ha_instances:
      children:
        eucalipto:
          hosts:
            eucalipto_sql_A:
              tenant_id: eucalipto_sql_A
              ansible_host: 172.16.101.101
              omni_ip_lan: 172.16.101.101              
              ha_rol: main
            eucalipto_sql_B:
              tenant_id: eucalipto_sql_B
              ansible_host: 172.16.101.102
              omni_ip_lan: 172.16.101.102
              ha_rol: backup
            eucalipto_aio_A:
              tenant_id: eucalipto_aio_A
              ansible_host: 172.16.101.109
              omni_ip_lan: 172.16.101.109
              ha_rol: main
            eucalipto_aio_B:
              tenant_id: eucalipto_aio_B
              ansible_host: 172.16.101.110
              omni_ip_lan: 172.16.101.110
              ha_rol: backup              
          vars:            
            infra_env: lan
            omnileads_ha: true
            ha_vip_nic: ens18
            netaddr: 172.16.101.0/16
            netprefix: 16
            ha_vip_nic: ens18             
            postgres_1: 172.16.101.101
            postgres_2: 172.16.101.102
            aio_1: 172.16.101.109
            aio_2: 172.16.101.110
            omnileads_vip: 172.16.101.200
            postgres_rw_vip: 172.16.101.201
            postgres_ro_vip: 172.16.101.202
            bucket_url: https://172.16.101.100:9000
            bucket_access_key: mYLcr7sdsahfaklsdx5vEbe7PO
            bucket_secret_key: v1Dl34Q29Bv6ruaWSjkdhajskhdajks7cUAEvSVfAtvGkR
            bucket_name: eucalipto

Es importante especificar el escenario en el que se trabajará. Si usaremos un VPS, el entorno a configurar será "cloud", y será "lan" si se usa una Virtual Machine. Definiremos para ello la variable de entorno infra_env según sea el caso: "cloud" (por default) o "lan".

Las variables tenant_id (nombre del tenant) y ansible_host (dirección IP que deberá alcanzar Ansible para ejecutar la Playbook) son mandatorias para especificar al tenant. A su vez, se listan un conjunto de variables necesarias para el correcto funcionamieto del cluster HA:

  • ha_vip_nic: este parámetro hace referencia a la IP virtual a asignar al cluster. En un entorno de alta disponiblidad debemos indicar a cada nodo del cluster su condición inicial (ha_rol), de esta manera se especifica el nombre de la NIC sobre la cual la VIP se establecerá.

  • omnileads_ha: este parámetro instruye a Ansible a correr ciertas tasks de playbook relacionadas a configuración de HA

  • netaddr y netprefix: parámetros utilizados para describir la red y máscara del entorno.

  • postgres_1: dirección IP del nodo 1 de PostgreSQL

  • postgres_2: dirección IP del nodo 2 de PostgreSQL

  • aio_1: dirección IP del nodo 1 de App

  • aio_2: dirección IP del nodo 2 de App

  • omnileads_vip: dirección IP virtual para el acceso HTTPS del cluster HA

  • postgres_rw_vip: dirección IP del nodo RW (read-write) de PostgreSQL

  • postgres_ro_vip: dirección IP del nodo RO (read-only) de PostgreSQL

  • bucket_url: la url del bucket externo (object storage)

El resto de los paráemtros se pueden customizar a gusto.

Finalmente, debemos asegurarnos de que la última sección contenga a los hosts del cluster correspondiente al tenant HA (tanto en _aio como en _sql). Debajo un ejemplo sobre nuestro tenant "eucalipto":

#############################################################################################################
# -- In this section the hosts are grouped based on the type of deployment (AIO, Cluster & Cluster HA).     #
#############################################################################################################

omnileads_aio:
  hosts:
    #tenant_example_1:
    #tenant_example_2:
    #tenant_example_3:
    #tenant_example_4:
    eucalipto_aio_A:
    eucalipto_aio_B:

################################################    
omnileads_data:
  hosts:
    #tenant_example_5_data:  
    
omnileads_voice:
  hosts:
    #tenant_example_5_voice:

omnileads_app:
  hosts:
    #tenant_example_5_app:

################################################
ha_omnileads_sql:
  hosts:
    eucalipto_sql_A:
    eucalipto_sql_B:

Con el archivo de inventario configurado, procedemos a ejecutar la acción de instalación del nuevo tenant:

./deploy.sh --action=install --tenant=omlclusterha

En el apartado de , se pueden revisar los pasos necesarios para obtener el primer acceso a la UI con usuario Administrador.

Para mayor información, sugerimos visitar la documentación expuesta en el .

🚀
First Login
repositorio oficial del proyecto