Cache de Host Local

Para garantir que o banco de dados do site Citrix Virtual Apps and Desktops esteja sempre disponível, a Citrix recomenda começar com uma implantação de SQL Server tolerante a falhas, seguindo as melhores práticas de alta disponibilidade da Microsoft. (Para recursos de alta disponibilidade do SQL Server suportados, consulte Bancos de Dados.) No entanto, problemas e interrupções de rede podem fazer com que os usuários não consigam se conectar aos seus aplicativos ou desktops.

O recurso Cache de Host Local permite que as operações de intermediação de conexão em um site continuem quando ocorre uma interrupção. Uma interrupção ocorre quando a conexão entre um Delivery Controller™ e o banco de dados do site falha em um ambiente Citrix® local. O Cache de Host Local é ativado quando o banco de dados do site fica inacessível por 90 segundos.

A partir do XenApp e XenDesktop 7.16, o recurso de leasing de conexão (um recurso de alta disponibilidade predecessor em versões anteriores) foi removido do produto e não está mais disponível.

Conteúdo dos dados

O Cache de Host Local inclui as seguintes informações, que são um subconjunto das informações no banco de dados principal:

• Identidades de usuários e grupos que têm direitos atribuídos a recursos publicados do site.
• Identidades de usuários que estão usando atualmente, ou que usaram recentemente, recursos publicados do site.
• Identidades de máquinas VDA (incluindo máquinas de Acesso Remoto a PC) configuradas no site.
• Identidades (nomes e endereços IP) de máquinas cliente Citrix Receiver™ que estão sendo ativamente usadas para se conectar a recursos publicados.

Ele também contém informações para conexões atualmente ativas que foram estabelecidas enquanto o banco de dados principal estava indisponível:

• Resultados de qualquer análise de endpoint de máquina cliente realizada pelo Citrix Receiver.
• Identidades de máquinas de infraestrutura (como servidores NetScaler Gateway e StoreFront™) envolvidas com o site.
• Datas, horários e tipos de atividade recente dos usuários.

Como funciona

O gráfico a seguir ilustra os componentes do Cache de Host Local e os caminhos de comunicação durante as operações normais.

Durante operações normais

• O broker principal (Serviço de Broker Citrix) em um Controller aceita solicitações de conexão do StoreFront. O broker se comunica com o banco de dados do site para conectar usuários a VDAs que estão registrados no Controller.
• O Serviço de Sincronização de Configuração Citrix (CSS) verifica com o broker aproximadamente a cada 5 minutos para ver se alguma alteração foi feita. Essas alterações podem ser iniciadas pelo administrador (como a alteração de uma propriedade de grupo de entrega) ou ações do sistema (como atribuições de máquina).

• Se uma alteração de configuração ocorreu desde a verificação anterior, o CSS sincroniza (copia) informações para um broker secundário no Controller. (O broker secundário também é conhecido como Serviço de Alta Disponibilidade.)

  Todos os dados de configuração são copiados, não apenas os itens que mudaram desde a verificação anterior. O CSS importa os dados de configuração para um banco de dados Microsoft SQL Server Express LocalDB no Controller. Este banco de dados é referido como o banco de dados do Cache de Host Local. O CSS garante que as informações no banco de dados do Cache de Host Local correspondam às informações no banco de dados do site. O banco de dados do Cache de Host Local é recriado a cada sincronização.

  O Microsoft SQL Server Express LocalDB (usado pelo banco de dados do Cache de Host Local) é instalado automaticamente quando você instala um Controller. (Você pode proibir esta instalação ao instalar um Controller a partir da linha de comando.) O banco de dados do Cache de Host Local não pode ser compartilhado entre Controllers. Você não precisa fazer backup do banco de dados do Cache de Host Local. Ele é recriado toda vez que uma alteração de configuração é detectada.

• Se nenhuma alteração ocorreu desde a última verificação, nenhum dado é copiado.

O gráfico a seguir ilustra as alterações nos caminhos de comunicação se o broker principal perder contato com o banco de dados do site (uma interrupção começa).

Durante uma interrupção

Quando uma interrupção começa:

• O broker secundário começa a escutar e processar solicitações de conexão.
• Quando a interrupção começa, o broker secundário não possui dados de registro VDA atuais, mas quando um VDA se comunica com ele, um processo de registro é acionado. Durante esse processo, o broker secundário também obtém informações de sessão atuais sobre esse VDA.
• Enquanto o broker secundário está lidando com as conexões, o Principal de Intermediação continua a monitorar a conexão. Quando a conexão é restaurada, o Principal de Intermediação instrui o broker secundário a parar de escutar informações de conexão, e o Principal de Intermediação retoma as operações de intermediação. Na próxima vez que um VDA se comunicar com o Principal de Intermediação, um processo de registro é acionado. O broker secundário remove quaisquer registros de VDA restantes da interrupção anterior. O CSS retoma a sincronização de informações quando descobre que ocorreram alterações de configuração na implantação.

No caso improvável de uma interrupção começar durante uma sincronização, a importação atual é descartada e a última configuração conhecida é usada.

O log de eventos fornece informações sobre sincronizações e interrupções.

Não há limite de tempo imposto para operar no modo de interrupção.

A transição entre o modo normal e o modo de interrupção não afeta as sessões existentes. Ela afeta apenas o lançamento de novas sessões.

Você também pode acionar intencionalmente uma interrupção. Consulte Forçar uma interrupção para obter detalhes sobre o porquê e como fazer isso.

Sites com vários Controllers

Entre suas outras tarefas, o CSS fornece rotineiramente ao broker secundário informações sobre todos os Controllers na zona. (Se sua implantação não contiver várias zonas, esta ação afeta todos os Controllers no site.) Tendo essa informação, cada broker secundário conhece todos os brokers secundários pares em execução em outros Controllers na zona.

Os brokers secundários se comunicam entre si em um canal separado. Esses brokers usam uma lista alfabética de nomes FQDN das máquinas em que estão sendo executados para determinar (eleger) qual broker secundário intermediará as operações na zona se ocorrer uma interrupção. Durante a interrupção, todos os VDAs se registram no broker secundário eleito. Os brokers secundários não eleitos na zona rejeitam ativamente as solicitações de conexão de entrada e de registro de VDA.

Se um broker secundário eleito falhar durante uma interrupção, outro broker secundário é eleito para assumir, e os VDAs se registram no broker secundário recém-eleito.

Durante uma interrupção, se um Controller for reiniciado:

• Se esse Controller não for o broker eleito, a reinicialização não terá impacto.
• Se esse Controller for o broker eleito, um Controller diferente é eleito, fazendo com que os VDAs se registrem. Depois que o Controller reiniciado liga, ele assume automaticamente a intermediação, o que faz com que os VDAs se registrem novamente. Nesse cenário, o desempenho pode ser afetado durante os registros.

Se você desligar um Controller durante as operações normais e depois ligá-lo durante uma interrupção, o Local Host Cache não poderá ser usado nesse Controller se ele for eleito como o broker.

Os logs de eventos fornecem informações sobre as eleições.

O que está indisponível durante uma interrupção e outras diferenças

Não há limite de tempo imposto para operar no modo de interrupção. No entanto, a Citrix recomenda restaurar a conectividade o mais rápido possível.

Durante uma interrupção:

• Você não pode usar o Studio.

• Você tem acesso limitado ao PowerShell SDK.

  • Você deve primeiro:
    • Adicionar uma chave de registro EnableCssTestMode com o valor 1: New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
    • Usar a porta 89: Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ControllerDNSName, DesktopGroupName, RegistrationState
  • Após executar esses comandos, você pode acessar:
    • Todos os cmdlets Get-Broker*.
• As credenciais do hipervisor não podem ser obtidas do Serviço de Host. Todas as máquinas estão no estado de energia desconhecido e nenhuma operação de energia pode ser emitida. No entanto, as VMs no host que estão ligadas podem ser usadas para solicitações de conexão.
• Uma máquina atribuída pode ser usada somente se a atribuição ocorreu durante as operações normais. Novas atribuições não podem ser feitas durante uma interrupção.
• O registro e a configuração automáticos de máquinas de Acesso Remoto a PC não são possíveis. No entanto, as máquinas que foram registradas e configuradas durante a operação normal são utilizáveis.
• Aplicativos hospedados em servidor e usuários de desktop podem usar mais sessões do que seus limites de sessão configurados, se os recursos estiverem em zonas diferentes.
• Os usuários podem iniciar aplicativos e desktops apenas a partir de VDAs registrados na zona que contém o broker secundário atualmente ativo/eleito. Lançamentos entre zonas (de um broker secundário em uma zona para um VDA em uma zona diferente) não são suportados durante uma interrupção.
• Se ocorrer uma interrupção do banco de dados do site antes que uma reinicialização agendada comece para VDAs em um grupo de entrega, as reinicializações começarão quando a interrupção terminar. Isso pode ter resultados não intencionais. Para obter mais informações, consulte Reinicializações agendadas atrasadas devido a interrupção do banco de dados.
• Preferência de zona não pode ser configurada. Se configurada, as preferências não são consideradas para o lançamento da sessão.
• Restrições de tags onde as tags são usadas para designar zonas não são suportadas para lançamentos de sessão. Quando tais restrições de tags são configuradas e a opção verificação avançada de integridade de uma loja StoreFront está habilitada, as sessões podem falhar intermitentemente ao iniciar.

Suporte a aplicativos e desktops

O LHC suporta os seguintes tipos de VDAs e modelos de entrega:

Observação:

Habilitar o acesso a VDAs de desktop gerenciados por energia em grupos de entrega agrupados não afeta como a propriedade ShutdownDesktopsAfterUse configurada funciona durante as operações normais. Quando o acesso a esses desktops durante o LHC é habilitado, os VDAs não reiniciam automaticamente após a conclusão do evento LHC. Os VDAs de desktop gerenciados por energia em grupos de entrega agrupados podem reter dados de sessões anteriores até que os VDAs reiniciem. Uma reinicialização do VDA pode ocorrer quando um usuário faz logoff do VDA durante operações não-LHC ou quando os administradores reiniciam o VDA.

Habilitar LHC para VDAs agrupados de SO de sessão única gerenciados por energia usando o Web Studio

Usando o Web Studio, você pode tornar essas máquinas disponíveis para novas conexões durante eventos LHC por grupo de entrega:

• Para habilitar esse recurso durante a criação do grupo de entrega, consulte Criar grupos de entrega.
• Para habilitar esse recurso para um grupo de entrega existente, consulte Gerenciar grupos de entrega.

Observação:

Essa configuração está disponível no Web Studio apenas para grupos de entrega de desktop agrupados que fornecem VDAs gerenciados por energia.

Habilitar LHC para VDAs agrupados de SO de sessão única gerenciados por energia usando o PowerShell

Para habilitar o LHC para VDAs em um grupo de entrega específico, siga estas etapas:

1. Habilite este recurso no nível do site executando este comando:

   Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

2. Habilite o LHC para um grupo de entrega executando este comando com o nome do grupo de entrega especificado:

   Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true

Para alterar a disponibilidade padrão do LHC para grupos de entrega agrupados recém-criados com VDAs gerenciados por energia, execute o seguinte comando:

Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true

Considerações sobre o tamanho da RAM

O serviço LocalDB pode usar aproximadamente 1,2 GB de RAM (até 1 GB para o cache do banco de dados, mais 200 MB para executar o SQL Server Express LocalDB). O broker secundário pode usar até 1 GB de RAM se uma interrupção durar por um período prolongado com muitos logons ocorrendo (por exemplo, 12 horas com 10 mil usuários). Esses requisitos de memória são adicionais aos requisitos normais de RAM para o Controller, então você pode precisar aumentar a quantidade total de capacidade de RAM.

Se você usar uma instalação do SQL Server Express para o banco de dados do site, o servidor terá dois processos sqlserver.exe.

Considerações sobre a configuração de núcleos de CPU e soquetes

A configuração da CPU de um Controller, particularmente o número de núcleos disponíveis para o SQL Server Express LocalDB, afeta diretamente o desempenho do Local Host Cache, ainda mais do que a alocação de memória. Essa sobrecarga da CPU é observada apenas durante o período de interrupção, quando o banco de dados está inacessível e o broker secundário está ativo.

Embora o LocalDB possa usar vários núcleos (até 4), ele é limitado a um único soquete. Adicionar mais soquetes não melhorará o desempenho (por exemplo, ter 4 soquetes com 1 núcleo cada). Em vez disso, a Citrix recomenda usar vários soquetes com vários núcleos. Nos testes da Citrix, uma configuração 2x3 (2 soquetes, 3 núcleos) proporcionou melhor desempenho do que as configurações 4x1 e 6x1.

Considerações sobre armazenamento

À medida que os usuários acessam recursos durante uma interrupção, o LocalDB cresce. Por exemplo, durante um teste de logon/logoff executado a 10 logons por segundo, o banco de dados cresceu 1 MB a cada 2-3 minutos. Quando a operação normal é retomada, o banco de dados local é recriado e o espaço é liberado. No entanto, espaço suficiente deve estar disponível na unidade onde o LocalDB está instalado para permitir o crescimento do banco de dados durante uma interrupção. O Local Host Cache também incorre em mais E/S durante uma interrupção: aproximadamente 3 MB de gravações por segundo, com várias centenas de milhares de leituras.

Considerações de desempenho

Durante uma interrupção, um broker secundário lida com todas as conexões, então em sites (ou zonas) que fazem balanceamento de carga entre vários Controllers durante operações normais, o broker secundário eleito pode precisar lidar com muito mais solicitações do que o normal durante uma interrupção. Portanto, as demandas de CPU serão maiores. Cada broker secundário no site (zona) deve ser capaz de lidar com a carga adicional imposta pelo banco de dados do Local Host Cache e todos os VDAs afetados, porque o broker secundário eleito durante uma interrupção pode mudar.

Limites de VDI:

• Em uma implantação VDI de zona única, até 10.000 VDAs podem ser tratados de forma eficaz durante uma interrupção.
• Em uma implantação VDI multizona, até 10.000 VDAs em cada zona podem ser tratados de forma eficaz durante uma interrupção, até um máximo de 40.000 VDAs no site. Por exemplo, cada um dos seguintes sites pode ser tratado de forma eficaz durante uma interrupção:
  • Um site com quatro zonas, cada uma contendo 10.000 VDAs.
  • Um site com sete zonas, uma contendo 10.000 VDAs e seis contendo 5.000 VDAs cada.

Durante uma interrupção, o gerenciamento de carga dentro do site pode ser afetado. Os avaliadores de carga (e especialmente as regras de contagem de sessões) podem ser excedidos.

Durante o tempo que leva para todos os VDAs se registrarem em um broker secundário, esse serviço pode não ter informações completas sobre as sessões atuais. Assim, uma solicitação de conexão de usuário durante esse intervalo pode resultar no lançamento de uma nova sessão, mesmo que a reconexão a uma sessão existente fosse possível. Este intervalo (enquanto o “novo” broker secundário adquire informações de sessão de todos os VDAs durante o novo registro) é inevitável. As sessões que estão conectadas quando uma interrupção começa não são impactadas durante o intervalo de transição, mas novas sessões e reconexões de sessão podem ser.

Este intervalo ocorre sempre que os VDAs devem se registrar:

• Uma interrupção começa: Ao migrar de um broker principal para um broker secundário.
• Falha do broker secundário durante uma interrupção: Ao migrar de um broker secundário que falhou para um broker secundário recém-eleito.
• Recuperação de uma interrupção: Quando as operações normais são retomadas e o broker principal retoma o controle.

Você pode diminuir o intervalo reduzindo o valor do registro HeartbeatPeriodMs do Citrix Broker Protocol (padrão = 600000 ms, que são 10 minutos). Este valor de heartbeat é o dobro do intervalo que o VDA usa para pings, então o valor padrão resulta em um ping a cada 5 minutos.

Por exemplo, o seguinte comando altera o heartbeat para cinco minutos (300000 milissegundos), o que resulta em um ping a cada 2,5 minutos:

New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000

Tenha cuidado ao alterar o valor do heartbeat. Aumentar a frequência resulta em maior carga nos Controllers durante os modos normal e de interrupção.

O intervalo não pode ser totalmente eliminado, independentemente da rapidez com que os VDAs se registrem.

O tempo necessário para sincronizar entre os brokers secundários aumenta com o número de objetos (como VDAs, aplicativos, grupos). Por exemplo, sincronizar 5000 VDAs pode levar 10 minutos ou mais para ser concluído.

Diferenças em relação às versões do XenApp 6.x

Embora esta implementação do Local Host Cache compartilhe o nome do recurso Local Host Cache no XenApp 6.x e versões anteriores do XenApp, há melhorias significativas. Esta implementação é mais robusta e imune à corrupção. Os requisitos de manutenção são minimizados, como a eliminação da necessidade de comandos dsmaint periódicos. Este Local Host Cache é uma implementação tecnicamente diferente.

Gerenciar Local Host Cache

Para que o Local Host Cache funcione corretamente, a política de execução do PowerShell em cada Controller deve ser definida como RemoteSigned, Unrestricted ou Bypass.

SQL Server Express LocalDB

O software Microsoft SQL Server Express LocalDB que o Local Host Cache usa é instalado automaticamente quando você instala um Controller ou atualiza um Controller de uma versão anterior à 7.9. Apenas o broker secundário se comunica com este banco de dados. Você não pode usar cmdlets do PowerShell para alterar nada sobre este banco de dados. O LocalDB não pode ser compartilhado entre Controllers.

O software de banco de dados SQL Server Express LocalDB é instalado independentemente de o Local Host Cache estar ativado.

Para evitar sua instalação, instale ou atualize o Controller usando o comando XenDesktopServerSetup.exe e inclua a opção /exclude "Local Host Cache Storage (LocalDB)". No entanto, tenha em mente que o recurso Local Host Cache não funcionará sem o banco de dados, e você não pode usar um banco de dados diferente com o broker secundário.

A instalação deste banco de dados LocalDB não tem efeito sobre se você instala o SQL Server Express para uso como banco de dados do site.

Para obter informações sobre como substituir uma versão anterior do SQL Server Express LocalDB por uma versão mais recente, consulte Substituir SQL Server Express LocalDB.

Configurações padrão após a instalação e atualização do produto

Durante uma nova instalação do Citrix Virtual Apps and Desktops (versão mínima 7.16), o Cache de Host Local é ativado.

Após uma atualização (para a versão 7.16 ou posterior), o Cache de Host Local é ativado se houver menos de 10.000 VDAs em toda a implantação.

Ativar e desativar o Cache de Host Local

• Para ativar o Cache de Host Local, digite:

  Set-BrokerSite -LocalHostCacheEnabled $true

  Para determinar se o Cache de Host Local está ativado, digite Get-BrokerSite. Verifique se a propriedade LocalHostCacheEnabled é True.

• Para desativar o Cache de Host Local, digite:

  Set-BrokerSite -LocalHostCacheEnabled $false

Lembre-se: A partir do XenApp e XenDesktop 7.16, o leasing de conexão (o recurso que precedeu o Cache de Host Local a partir da versão 7.6) foi removido do produto e não está mais disponível.

Verificar se o Cache de Host Local está funcionando

Para verificar se o Cache de Host Local está configurado e funcionando corretamente:

• Certifique-se de que as importações de sincronização sejam concluídas com sucesso. Verifique os logs de eventos.
• Certifique-se de que o banco de dados SQL Server Express LocalDB foi criado em cada Delivery Controller. Isso confirma que o broker secundário pode assumir, se necessário.
  • No servidor Delivery Controller, navegue até C:\Windows\ServiceProfiles\NetworkService.
  • Verifique se HaDatabaseName.mdf e HaDatabaseName_log.ldf são criados.
• Forçar uma interrupção nos Delivery Controllers. Depois de verificar que o Local Host Cache funciona, lembre-se de colocar todos os Controllers de volta no modo normal. Isso pode levar aproximadamente 15 minutos.

Logs de eventos

Os logs de eventos indicam quando ocorrem sincronizações e interrupções. Nos logs do visualizador de eventos, o modo de interrupção é referido como modo HA.

Serviço de Sincronização de Configuração:

Durante as operações normais, os seguintes eventos podem ocorrer quando o CSS importa os dados de configuração para o banco de dados do Local Host Cache usando o broker do Local Host Cache.

• 503: O Serviço de Sincronização de Configuração do Citrix recebeu uma configuração atualizada. Este evento indica o início do processo de sincronização.
• 504: O Serviço de Sincronização de Configuração do Citrix importou uma configuração atualizada. A importação da configuração foi concluída com êxito.
• 505: O Serviço de Sincronização de Configuração do Citrix falhou em uma importação. A importação da configuração não foi concluída com êxito. Se uma configuração anterior bem-sucedida estiver disponível, ela será usada se ocorrer uma interrupção. No entanto, ela estará desatualizada em relação à configuração atual. Se não houver configuração anterior disponível, o serviço não poderá participar do balanceamento de sessão durante uma interrupção. Nesse caso, consulte a seção Solução de problemas e entre em contato com o Suporte Citrix.
• 507: O Serviço de Sincronização de Configuração do Citrix abandonou uma importação porque o sistema está no modo de interrupção e o broker do Local Host Cache está sendo usado para balanceamento. O serviço recebeu uma nova configuração, mas a importação foi abandonada porque ocorreu uma interrupção. Este é o comportamento esperado.
• 510: Nenhum dado de configuração do Serviço de Configuração recebido do Serviço de Configuração primário.
• 517: Houve um problema na comunicação com o Broker primário.
• 518: O script de sincronização de configuração foi abortado porque o Broker secundário (Serviço de Alta Disponibilidade) não está em execução.

Serviço de Alta Disponibilidade:

Este serviço também é conhecido como broker do Local Host Cache.

• 3502: Ocorreu uma interrupção e o broker do Local Host Cache está realizando operações de balanceamento.
• 3503: Uma interrupção foi resolvida e as operações normais foram retomadas.
• 3504: Indica qual broker do Local Host Cache foi eleito, além de outros brokers do Local Host Cache envolvidos na eleição.
• 3507: Fornece uma atualização de status do Local Host Cache a cada 2 minutos, indicando que o modo Local Host Cache está ativo no broker eleito. Contém um resumo da interrupção, incluindo duração da interrupção, registro de VDA e informações da sessão.
• 3508: Anuncia que o Local Host Cache não está mais ativo no broker eleito e que as operações normais foram restauradas. Contém um resumo da interrupção, incluindo duração da interrupção, número de máquinas que se registraram durante o evento do Local Host Cache e número de inicializações bem-sucedidas durante o evento LHC.
• 3509: Notifica que o Local Host Cache está ativo no(s) broker(s) não eleito(s). Contém uma duração de interrupção a cada 2 minutos e indica o broker eleito.
• 3510: Anuncia que o Local Host Cache não está mais ativo no(s) broker(s) não eleito(s). Contém a duração da interrupção e indica o broker eleito.

Forçar uma interrupção

Você pode querer forçar deliberadamente uma interrupção.

• Se sua rede estiver caindo e voltando repetidamente. Forçar uma interrupção até que os problemas de rede sejam resolvidos evita a transição contínua entre os modos normal e de interrupção (e as frequentes tempestades de registro de VDA resultantes).
• Para testar um plano de recuperação de desastres.
• Para ajudar a garantir que o Local Host Cache esteja funcionando corretamente.
• Ao substituir ou fazer a manutenção do servidor de banco de dados do site.

Para forçar uma interrupção, edite o registro de cada servidor que contém um Delivery Controller. Em HKLM\Software\Citrix\DesktopServer\LHC, crie e defina OutageModeForced como REG_DWORD para 1. Essa configuração instrui o broker do Local Host Cache a entrar no modo de interrupção, independentemente do estado do banco de dados. Definir o valor como 0 tira o broker do Local Host Cache do modo de interrupção.

Para verificar eventos, monitore o arquivo de log Current_HighAvailabilityService em C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.

Solucionar problemas

Várias ferramentas de solução de problemas estão disponíveis quando uma importação de sincronização para o banco de dados do Cache de Host Local falha e um evento 505 é registrado.

Rastreamento CDF: Contém opções para os módulos ConfigSyncServer e BrokerLHC. Essas opções, juntamente com outros módulos do broker, provavelmente identificarão o problema.

Relatório: Se uma importação de sincronização falhar, você pode gerar um relatório. Este relatório para no objeto que causa o erro. Este recurso de relatório afeta a velocidade de sincronização, então a Citrix recomenda desativá-lo quando não estiver em uso.

Para habilitar e produzir um relatório de rastreamento CSS, digite o seguinte comando:

New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1

O relatório HTML é publicado em C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html.

Após a geração do relatório, digite o seguinte comando para desabilitar o recurso de relatório:

Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0

Exportar a configuração do broker: Fornece a configuração exata para fins de depuração.

Export-BrokerConfiguration | Out-File <file-pathname>

Por exemplo, Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.

Comandos PowerShell do Cache de Host Local

Você pode gerenciar o Cache de Host Local (LHC) em seus Delivery Controllers usando comandos PowerShell.

O módulo PowerShell está localizado no seguinte local nos Delivery Controllers:

C:\Program Files\Citrix\Broker\Service\ControlScripts

Importante:

Execute este módulo apenas nos Delivery Controllers.

Importar módulo PowerShell

Para importar o módulo, execute o seguinte no seu Delivery Controller.

cd C:\Program Files\Citrix\Broker\Service\ControlScripts Import-Module .\HighAvailabilityServiceControl.psm1

Comandos PowerShell para gerenciar o LHC

Os comandos a seguir ajudam a ativar e gerenciar o modo LHC nos Delivery Controllers.

Observação:

• Use a porta 89 ao executar os cmdlets Get-Broker* no Delivery Controller. Por exemplo:
  • Get-BrokerMachine -AdminAddress localhost:89
• Quando não está no modo LHC, o Broker LHC no Delivery Controller contém apenas informações de configuração.
• Durante o modo LHC, o Broker LHC no Delivery Controller eleito contém as seguintes informações:
  • Estados dos recursos
  • Detalhes da sessão
  • Registros de VDA
  • Informações de configuração