# Deploy en HA (High Availability)
## 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 [First Login](/instalacion-de-omnileads/first-login.md), 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 [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.omnileads.net/instalacion-de-omnileads/deploy-utilizando-ansible/deploy-en-ha-high-availability.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.