Skip to main content

16 de julho de 2026

Implantando o Omnissa Access em um centro de dados secundário para failover e redundância

Para fornecer recursos de failover caso o centro de dados principal do Omnissa Access fique indisponível, você deve implantar o Omnissa Access em um centro de dados secundário.

Usando um centro de dados secundário, os usuários finais podem fazer login e usar os aplicativos com tempo mínimo de inatividade. Além disso, com um centro de dados secundário, você pode atualizar o Omnissa Access para a próxima versão com tempo de inatividade mínimo. Consulte Atualizar o Omnissa Access com tempo de inatividade mínimo.

Mostramos aqui uma implantação típica usando um centro de dados secundário.

Diagrama de implantação típica usando um centro de dados secundário

Para obter informações sobre a versão correta do conector a ser usada com o repositório ThinApp para aplicativos empacotados ThinApp, o Integration Broker para recursos publicados Citrix e o Horizon Connection Server para áreas de trabalho e aplicativos Horizon, consulte a nota importante correspondente em Preparando para Instalar o Omnissa Access.

Siga essas orientações para uma implantação de vários centros de dados.

  • Implantação em cluster: você deve implantar um conjunto de dispositivos virtuais do Omnissa Access em dois centros de dados separados.

    • Um conjunto de três ou mais dispositivos virtuais do Omnissa Access como um cluster em um centro de dados.
    • Outro conjunto de três ou mais dispositivos virtuais do Omnissa Access como outro cluster em um segundo centro de dados. Consulte Configurar um centro de dados secundário para o Omnissa Access para obter mais informações.
  • Banco de dados: o Omnissa Access usa o banco de dados para armazenar dados. Para a implantação de vários centros de dados, a replicação do banco de dados entre os dois centros de dados é crucial. Consulte a documentação de seu banco de dados a respeito de como definir um banco de dados em vários centros de dados. Por exemplo, com o SQL Server, é preferível usar a implantação Always On. Para obter mais informações, consulte Visão geral doa grupos de disponibilidade do Always On (SQL Server) no site da Microsoft. As funcionalidades do Omnissa Access foram projetadas para latência mínima entre o banco de dados e o dispositivo Omnissa Access. Portanto, os dispositivos em um centro de dados são projetados para se conectar ao banco de dados no mesmo centro de dados.

  • Não Ativo-Ativo: o Omnissa Access não oferece suporte a uma implantação Ativo-Ativo, na qual os usuários podem ser atendidos por ambos os centros de dados simultaneamente. O centro de dados secundário é do tipo espera quente e pode ser usado para fornecer a continuidade dos negócios para os usuários finais. Os dispositivos Omnissa Access no centro de dados secundário estão em modo somente leitura. Assim, após um failover nesse centro de dados, a maioria das operações de administração, como adicionar usuários ou aplicativos, ou autorizar usuários, não funcionará.

  • Failback para um principal: na maior parte dos casos de falha, você poderá executar failback para o centro de dados principal já que o centro de dados voltou ao normal. Consulte Failback no centro de dados primário para o Omnissa Access para obter informações.

  • Promover um secundário a principal: se ocorrer uma falha estendida no centro de dados, o centro de dados secundário poderá ser promovido a principal. Consulte Promover um centro de dados secundário a um centro de dados primário para o Omnissa Access para obter informações.

  • Nome de Domínio Totalmente Qualificado: o nome de domínio totalmente qualificado para acessar o Omnissa Access deve ser o mesmo em todos os centro de dados.

  • Auditorias: o Omnissa Access usa o OpenSearch incorporado ao dispositivo Omnissa Access para auditoria, relatórios e logs de sincronização de diretório. Crie clusters do OpenSearch separados em cada centro de dados. Consulte Configurar um centro de dados secundário para o Omnissa Access para obter mais informações.

  • Active Directory: o Omnissa Access pode se conectar ao Active Directory usando a API LDAP ou a Autenticação Integrada do Windows. Com ambos os métodos, o Omnissa Access pode usar registros SRV do Active Directory para acessar o controlador de domínio apropriado em cada centro de dados.

  • Aplicativos Windows: o Omnissa Access oferece suporte ao acesso a aplicativos Windows usando o ThinApp e a aplicativos e áreas de trabalho Windows usando as tecnologias Horizon ou Citrix. É importante fornecer esses recursos a partir de um centro de dados que esteja mais próximo do usuário, também denominado Geo-Affinity.

    Importante: para obter informações sobre a versão correta do conector a ser usada com o repositório ThinApp para aplicativos empacotados ThinApp, o Integration Broker para recursos publicados Citrix e o Horizon Connection Server para áreas de trabalho e aplicativos Horizon, consulte a nota correspondente em Preparando para Instalar o Omnissa Access

    Observe o seguinte a respeito dos recursos do Windows:

    • ThinApps: o Omnissa Access oferece suporte a Sistemas de Arquivos Distribuídos do Windows como um repositório ThinApp. Use a documentação do Windows Distributed File Systems (Sistemas de arquivos distribuídos no Windows) para definir políticas adequadas relacionadas especificamente ao local.
    • Horizon (com Arquitetura Cloud Pod): o Omnissa Access oferece suporte à Arquitetura Horizon Cloud Pod. A Arquitetura do Horizon Cloud Pod oferece o Geo-Affinity usando direitos globais. Consulte "Integrando Implantações da Arquitetura Cloud Pod" em Configurar Recursos no Omnissa Access para obter informações. Nenhuma alteração adicional é necessária para uma implantação de vários centros de dados do Omnissa Access.
    • O Horizon (sem a Arquitetura do Cloud Pod) — caso a Arquitetura do Horizon Cloud Pod não esteja habilitada em seu ambiente, você não poderá habilitar o Geo-Affinity. Após um evento de failover, você pode alternar manualmente o Omnissa Access para executar recursos do Horizon a partir dos pods do Horizon configurados no centro de dados secundário. Consulte Configurar ordem de failover do Horizon e dos recursos publicados pela Citrix para obter mais informações.
    • Recursos Citrix — Assim como acontece com o Horizon (sem a Arquitetura do Cloud Pod), você não poderá habilitar o Geo-Affinity para os recursos Citrix. Após um evento de failover, você pode alternar manualmente o Omnissa Access para executar recursos Citrix a partir dos XenFarms configurados no centro de dados secundário. Consulte Configurar ordem de failover do Horizon e dos recursos publicados pela Citrix para obter mais informações.

Esta página foi útil?

Enviar feedback sobre este tópico

Este tópico foi útil?

Não inclua informações pessoais ou confidenciais.

Gerando o link…