Instalar Omnissa Access

Para implementar Omnissa® Access™ en el plano de control, siga las instrucciones incluidas en esta guía.

Esta sección de la guía Instalar y configurar Omnissa Access muestra el proceso completo para implementar Omnissa Access en su entorno. Incluye una descripción general de la implementación, una explicación de los componentes de la plataforma que conforman un clúster de Omnissa Access, la arquitectura de implementación compatible y una secuencia de instalación por fases que le guiará desde la preparación inicial de la máquina virtual hasta la creación de inquilinos (ya sea mediante Access Wizard o, si prefiere tener un control directo sobre cada paso, de forma manual).

El almacenamiento NFS es necesario si tiene pensado configurar un sitio de recuperación ante desastres (DR) para su implementación. Consulte los requisitos en Configuración de la recuperación ante desastres para Omnissa Access.

Una vez completada la instalación, la guía continúa con temas de configuración y administración que le ayudarán a preparar y gestionar su implementación.

Una vez completada la configuración, podrá utilizar la consola de Omnissa Access para administrar usuarios y grupos, configurar y administrar directivas de acceso y autenticación, y agregar recursos al catálogo y administrar autorizaciones para dichos recursos. También puede configurar la integración de Workspace ONE UEM e iniciar Hub Services.

Descripción general de la arquitectura

Omnissa Access se ejecuta como un conjunto de microservicios en contenedores administrados por el plano de control. Los servicios que componen Omnissa Access se distribuyen en un clúster de máquinas virtuales dedicadas, todas ellas con AlmaLinux 9.6, y se implementan y operan como cargas de trabajo independientes. Como cada servicio se ejecuta de forma independiente, los servicios se pueden actualizar, reiniciar, escalar y recuperar de forma individual.

El plano de control

El plano de control es la plataforma que instala, ejecuta, escala y supervisa los servicios que componen una implementación de Omnissa Access. Coordina todos los servicios del clúster mediante tres servicios de plataforma:

• Nomad programa y orquesta las cargas de trabajo de los servicios.
• Consul proporciona descubrimiento de servicios y comunicación interna segura entre los servicios.
• Vault almacena y administra secretos, certificados y tokens.

Categorías de servicios

Una implementación de Omnissa Access consta de tres categorías de servicios:

Tipos de nodos

Un clúster de Omnissa Access se compone de tres tipos de máquinas virtuales y un equilibrador de carga:

• Nodo de arranque: el controlador de la implementación. Ejecute la CLI de WSO desde este nodo para implementar y operar el clúster.
• Nodos de infraestructura/plataforma: alojan los servicios de plataforma y los servicios de infraestructura.
• Nodos de Omnissa Access: alojan los servicios de Omnissa Access. Los servicios de plataforma también se ejecutan en estos nodos.
• Equilibrador de carga: distribuye el tráfico entre los nodos de Omnissa Access y proporciona alta disponibilidad para los servicios de Access.

Los servicios de plataforma se ejecutan tanto en los nodos de infraestructura/plataforma como en los nodos de Omnissa Access, por lo que la orquestación, el descubrimiento de servicios y la administración de secretos siguen funcionando en todo el clúster, en lugar de depender de un único nodo.

La CLI de WSO

La CLI de WSO (interfaz de línea de comandos de Workspace ONE) es la interfaz principal para implementar y operar Omnissa Access. Ejecute los comandos de la CLI de WSO desde el nodo de arranque.

Descripción general de la implementación

Omnissa Access se implementa en la plataforma del plano de control en varias fases. Cada fase depende de que la fase anterior se haya completado correctamente.

Fases de implementación

1. Preparar las máquinas virtuales.
2. Implementar las máquinas virtuales.
3. Implementar Omnissa Access. Elija una opción:
   • Opción 1: usando Access Wizard.
   • Opción 2: manualmente, paso a paso.

Arquitectura de implementación

Asegúrese de que se cumplan los siguientes detalles relacionados con la arquitectura, según sea necesario, para Omnissa Access:

• Máquinas virtuales necesarias

  Tipo de nodo	Recuento	Propósito
  Nodos de infraestructura/plataforma	3	Servicios de infraestructura
  Nodos de Omnissa Access	2 para implementaciones pequeñas y medianas 3 para implementaciones grandes	Servicios de la aplicación Access
  Nodo de arranque	1	Controlador de implementación
  Equilibrador de carga	-	Para alta disponibilidad de los servicios de Access

  Nota: Los servicios de plataforma se ejecutan tanto en los nodos de infraestructura/plataforma como en los nodos de Omnissa Access.

• Colocación de servicios

  Nodo	Servicios
  Nodos de infraestructura/plataforma	Nomad, Consul, Vault, Postgres, Redis, Kafka, OpenSearch
  Nodos de Omnissa Access	Nomad, Consul, Vault, servicios de Access
  Nodo de arranque	Implementación/Operaciones administrativas

  Asegúrese de que todos los nodos cumplan los siguientes requisitos:

  • Ejecutar AlmaLinux 9.6
  • Tener direcciones IP estáticas
  • Tener nombres de host únicos
  • Tener acceso SSH desde el nodo de arranque

• Configuración de equilibrador de cargas

  Configure su equilibrador de carga y agregue sus nodos de servicio de Access en la parte superior de la cadena, de modo que el equilibrador de carga pueda redireccionar el tráfico a cualquiera de los nodos. Consulte Usar un equilibrador de carga o un proxy inverso para habilitar el acceso externo a Omnissa Access para consultar los requisitos de la configuración.

• Resolución de DNS

  • Entrada DNS: Asegúrese de que la entrada DNS apunte a la dirección IP del FQDN (dirección IP del equilibrador de carga).

    tenant.example.com

• Requisitos de certificados

  • Nombre común (CN): Nombre de host del equilibrador de carga (tenant.example.com).

  • Nombres alternativos del firmante (SAN):

    • Ejemplos:
      • tenant.example.com
      • tenant-cert.example.com
      • tenant-amsso.example.com

    Asegúrese de que la parte correspondiente al dominio de todas las entradas SAN coincida con el dominio utilizado por el equilibrador de carga y los nodos del clúster.

    Notas:

    • Puede optar por utilizar un certificado comodín, como *.tenant.example.com, para cubrir todos los SAN.
    • Si no utiliza la autenticación basada en certificados, tenant.example.com es el único SAN obligatorio. Puede omitir tenant-cert.example.com y tenant-amsso.example.com.

  Referencia de CSR

  Utilice una de las siguientes configuraciones en función del tipo de certificado.

  Certificado comodín

  [ req ]
  default_bits       = 2048
  prompt             = no
  default_md         = sha256
  distinguished_name = dn
  req_extensions     = req_ext
  
  [ dn ]
  CN = *.tenant.example.com
  
  [ req_ext ]
  subjectAltName = @alt_names
  
  [ alt_names ]
  DNS.1 = *.tenant.example.com
  

  Certificado no comodín (se requieren todos los SAN)

  Si no utiliza un certificado comodín, enumere explícitamente cada nombre alternativo de firmante.

  [ req ]
  default_bits       = 2048
  prompt             = no
  default_md         = sha256
  distinguished_name = dn
  req_extensions     = req_ext
  
  [ dn ]
  CN = tenant.example.com
  
  [ req_ext ]
  subjectAltName = @alt_names
  
  [ alt_names ]
  DNS.1 = tenant.example.com
  DNS.2 = tenant-cert.example.com
  DNS.3 = tenant-amsso.example.com