Instalar o Omnissa Access

Para implantar o Omnissa® Access™ no Control Plane, siga as instruções fornecidas neste guia.

Esta seção, Instalação do Omnissa Access, do guia Instalar e configurar o Omnissa Access, orienta você ao longo de todo o processo de implantação do Omnissa Access em seu ambiente. Ela inclui uma visão geral da implantação, uma descrição dos componentes da plataforma que compõem um cluster do Omnissa Access, a arquitetura de implantação compatível e uma sequência de instalação em etapas que o conduz desde a preparação inicial da máquina virtual até a criação do locatário, seja com o Access Wizard ou, se preferir ter controle direto sobre cada etapa, manualmente.

O armazenamento NFS será necessário se você planeja configurar um site de recuperação de desastre (DR) para a sua implantação. Consulte Configurar a Recuperação de desastre para Omnissa Access para conferir os pré-requisitos.

Após concluir a instalação, o guia prossegue com tópicos de configuração e gerenciamento que o ajudarão a preparar e operar sua implantação.

Após concluir a configuração, você pode usar o console do Omnissa Access para gerenciar usuários e grupos, configurar e gerenciar políticas de autenticação e acesso, adicionar recursos ao catálogo e gerenciar direitos a esses recursos. Você também pode configurar a integração do Workspace ONE UEM e iniciar o Hub Services.

Visão geral da arquitetura

O Omnissa Access é executado como um conjunto de microsserviços conteinerizados gerenciados pelo Control Plane. Os serviços que compõem o Omnissa Access são distribuídos em um cluster de máquinas virtuais dedicadas, todas executando o AlmaLinux 9.6, e são implantados e operados como cargas de trabalho independentes. Como os serviços são separados, eles podem ser atualizados, reiniciados, dimensionados e recuperados individualmente.

O Control Plane

O Control Plane é a plataforma que instala, executa, dimensiona e monitora os serviços que compõem uma implantação do Omnissa Access. Ele coordena todos os serviços no cluster usando três serviços de plataforma:

• O Nomad agenda e orquestra as cargas de trabalho do serviço.
• O Consul fornece a detecção de serviços e comunicação interna segura entre serviços.
• O Vault armazena e gerencia segredos, certificados e tokens.

Categorias de serviços

Uma implantação do Omnissa Access é composta por três categorias de serviços:

Tipos de nós

Um cluster do Omnissa Access é criado de três tipos de máquina virtual, além de um balanceador de carga:

• Nó de bootstrap: o controlador de implantação. Você executa a interface de linha de comando do WSO desse nó para implantar e operar o cluster.
• Nós de infraestrutura/plataforma: hospedam os serviços da Plataforma e os serviços de Infraestrutura.
• Nós do Omnissa Access: hospedam os serviços do Omnissa Access. Os serviços de plataforma também são executados nesses nós.
• Balanceador de carga: distribui o tráfego pelos Nós do Omnissa Access e fornece alta disponibilidade para os serviços do Access.

Os serviços de plataforma são executados nos nós de Infraestrutura/Plataforma e nos nós do Omnissa Access, para que a orquestração, a detecção de serviços e o gerenciamento de segredos continuem funcionando em todo o cluster, em vez de depender de qualquer nó único.

A CLI do WSO

A CLI do WSO (Interface de linha de comando do Workspace ONE) é a principal interface para a implantação e operação do Omnissa Access. Execute os comandos da interface de linha de comando do WSO pelo Nó de bootstrap.

Visão geral da implantação

O Omnissa Access é implantado na plataforma do Control Plane em várias fases. Cada fase depende da conclusão bem-sucedida da fase anterior.

Fases da implantação

1. Preparar máquinas virtuais.
2. Implante as máquinas virtuais.
3. Implantar o Omnissa Access: escolha uma opção:
   • Opção 1: usar o Access Wizard.
   • Opção 2: manualmente, passo a passo.

Arquitetura de implantação

Certifique-se de que os seguintes detalhes relacionados à arquitetura sejam atendidos, conforme exigido pelo Omnissa Access:

• Máquinas virtuais necessárias

  Tipo de nó	Contagem	Finalidade
  Nós de infraestrutura/plataforma	3	Serviços de infraestrutura
  Nós do Omnissa Access	2 para pequeno e médio 3 para grande	Serviços de aplicativo do Access
  Nó de bootstrap	1	Controlador de implantação
  Balanceador de carga	0	Para HA (alta disponibilidade) dos serviços do Access

  Nota: os serviços de plataforma são executados nos nós de Infraestrutura/Plataforma e nos nós do Omnissa Access.

• Alocação de serviços

  Nó	Serviços
  Nós de infraestrutura/plataforma	Nomad, Consul, Vault, Postgres, Redis, Kafka, OpenSearch
  Nós do Omnissa Access	Serviços de Nomad, Consul, Vault, Access
  Nó de bootstrap	Implantação/Operações administrativas

  Certifique-se de que todos os nós atendam aos seguintes requisitos:

  • Executem o AlmaLinux 9.6
  • Possuam endereços IP estáticos
  • Possuam nomes de host exclusivos
  • Possuam acesso SSH a partir do nó de bootstrap

• Configuração do balanceador de carga

  Configure o balanceador de carga e adicione os nós do serviço de acesso upstream, permitindo que o balanceador de carga seja redirecionado para qualquer um dos nós. Consulte Usar um balanceador de carga ou proxy reverso para habilitar o acesso externo ao Omnissa Access para conhecer os requisitos de configuração.

• Resolução de DNS

  • Entrada DNS: certifique-se de que uma entrada de DNS resolva para o IP do FQDN (IP do balanceador de carga).

    tenant.example.com

• Requisitos de certificado

  • Nome Comum (CN): nome do host do balanceador de carga (tenant.example.com).

  • Nomes Alternativos da Entidade (SANs):

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

    Certifique-se de que a parte do domínio de todas as entradas SAN corresponda ao domínio usado pelo balanceador de carga e pelos nós do cluster.

    Notas:

    • Você pode optar por usar um certificado curinga, como *.tenant.example.com para abranger todos os SANs.
    • Se você não estiver usando a autenticação baseada em certificado, tenant.example.com será o único SAN necessário. Você pode omitir tenant-cert.example.com e tenant-amsso.example.com.

  Referência de CSR

  Use uma das seguintes configurações dependendo do seu tipo de certificado.

  Certificado curinga

  [ 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 não curinga (todos os SANs necessários)

  Se você não estiver usando um certificado curinga, liste cada Nome Alternativo da Entidade explicitamente.

  [ 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