Cache do host local
Para garantir que o banco de dados do site do Citrix Virtual Apps and Desktops esteja sempre disponível, a Citrix recomenda começar com uma implantação do SQL Server tolerante a falhas, seguindo as práticas recomendadas de alta disponibilidade da Microsoft. (Para recursos de alta disponibilidade do SQL Server compatíveis, consulte Bancos de dados.) No entanto, problemas de rede e interrupções podem resultar em usuários que não conseguem se conectar a seus aplicativos ou áreas de trabalho.
O recurso de Cache de host local permite que as operações de troca 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 concessão 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 de 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 aos recursos publicados no site.
- Identidades de usuários que estão usando atualmente, ou que usaram recentemente, recursos publicados no site.
- Identidades de máquinas VDA (incluindo máquinas Remote PC Access) configuradas no site.
- Identidades (nomes e endereços IP) de máquinas cliente Citrix Receiver que estão sendo usadas ativamente para a conexão 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 análises de ponto de extremidade de máquina cliente realizadas pelo Citrix Receiver.
- Identidades de máquinas de infraestrutura (como servidores NetScaler Gateway e StoreFront) envolvidas em operações do site.
- Data, hora e tipo das atividades recentes 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 as operações normais
- O agente principal (Citrix Broker Service) em um Controller aceita solicitações de conexão do StoreFront. O agente se comunica com o banco de dados do site para conectar usuários com VDAs que estão registrados no Controller.
- O Citrix Config Synchronizer Service (CSS) consulta o agente a cada minuto, aproximadamente, para ver se foi feita alguma alteração. As alterações podem ser iniciadas pelo administrador (como alterar uma propriedade de grupo de entrega) ou podem ser ações do sistema (como atribuições de máquina).
-
Se uma alteração de configuração tiver ocorrido desde a verificação anterior, o CSS sincroniza (copia) as informações com um agente secundário no Controller. (O agente 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 foram alterados desde a verificação anterior. O CSS importa os dados de configuração para um banco de dados do Microsoft SQL Server Express LocalDB no Controller. Esse 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 toda vez que a sincronização ocorre.
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 essa instalação ao instalar um Controller usando a linha de comando.) O banco de dados do cache de host local não pode ser compartilhado entre os 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 tiver ocorrido desde a última verificação, nenhum dado será copiado.
O gráfico a seguir ilustra as alterações nos caminhos de comunicação se o agente principal perder o contato com o banco de dados do site (quando uma interrupção começa).
Durante uma interrupção
Quando uma interrupção começa:
- O agente secundário começa a escutar e processar as solicitações de conexão.
- Quando a interrupção começa, o agente secundário não tem dados de registro do VDA atuais, mas quando o VDA se comunica com ele, um processo de registro é disparado. Durante esse processo, o agente secundário também obtém as informações de sessão atuais sobre o VDA.
- Enquanto o agente secundário está lidando com as conexões, o Brokering Principal continua a monitorar a conexão. Quando a conexão é restaurada, o Brokering Principal instrui o agente secundário a parar de escutar informações de conexão, e o Brokering Principal retoma as operações de intermediação. A próxima vez que um VDA se comunicar com o Brokering Principal, um processo de registro é disparado. O agente secundário remove quaisquer registros de VDA restantes da interrupção anterior. O CSS retoma a sincronização de informações quando detecta 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. Isso afeta apenas a inicialização de novas sessões.
Você também pode disparar uma interrupção intencionalmente. Consulte Forçar uma interrupção para obter detalhes sobre por que e como fazer isso.
Sites com vários Controllers
Entre suas outras tarefas, o CSS rotineiramente fornece ao agente secundário informações sobre todos os Controllers na zona. (Se a sua implantação não contiver várias zonas, essa ação afetará todos os Controllers no site.) Tendo essa informação, cada agente secundário sabe sobre todos os agentes secundários de pares em execução em outros Controllers na zona.
Os agentes secundários comunicam-se uns com os outros em um canal separado. Esses agentes usam uma lista alfabética de nomes FQDN das máquinas em que estão sendo executados para determinar (eleger) qual agente secundário intermediará as operações na zona se ocorrer uma interrupção. Durante a interrupção, todos os VDAs se registram no agente secundário eleito. Os agentes secundários não eleitos na zona rejeitam ativamente as solicitações de entrada de conexão e registro de VDA.
Se um agente secundário eleito falhar durante uma interrupção, outro agente secundário é eleito para assumir o controle, e os VDAs se registram no agente secundário recém-eleito.
Durante uma interrupção, se um Controller for reiniciado:
- Se esse Controller não for o agente eleito, a reinicialização não terá impacto.
- Se esse Controller for o agente eleito, um Controller diferente será 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 ligá-lo durante uma interrupção, o Cache de host local não pode ser usado nesse Controller se for eleito como o agente.
Os logs de eventos fornecem informações sobre as escolhas.
O que não está disponí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 SDK do PowerShell.
- Você deve primeiro:
- Adicionar uma chave de registro
EnableCssTestModecom um valor de 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, ContollerDNSName, DesktopGroupName, RegistrationState
- Adicionar uma chave de registro
- Depois de executar esses comandos, você pode acessar:
- Todos os cmdlets
Get-Broker*. - Os cmdlets de gerenciamento de energia
New-BrokerHostingPowerAction,Set-BrokerHostingPowerActioneRemove-BrokerHostingPowerAction.
- Todos os cmdlets
- Você deve primeiro:
- As credenciais do Hypervisor não podem ser obtidas do Host Service. Todas as máquinas estão em um 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 só pode ser usada 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ática de máquinas Remote PC Access 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 no servidor e usuários de área de trabalho 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 áreas de trabalho somente a partir de VDAs registrados na zona que contém o agente secundário eleito/ativo atualmente. As inicializações entre zonas (de um agente secundário em uma zona para um VDA em uma zona diferente) não são suportadas durante uma interrupção.
- Se uma interrupção do banco de dados do site ocorrer antes de uma reinicialização programada começar para os VDAs em um grupo de entrega, as reinicializações começam quando a interrupção termina. Isso pode ter resultados inesperados. Para obter mais informações, consulte Reinicializações agendadas atrasadas devido à interrupção do banco de dados.
- A preferência de zona não pode ser configurada. Se configuradas, as preferências não serão consideradas na inicialização da sessão.
- A opção de restrições de tag está ativada, as sessões podem falhar de forma intermitente na inicialização.
Suporte a aplicativos e áreas de trabalho
O cache de host local oferece suporte a aplicativos e áreas de trabalho hospedados em servidor e a áreas de trabalho estáticas (atribuídas).
O cache de host local oferece suporte a VDAs de área de trabalho em grupos de entrega em pool, como se segue:
-
Por padrão, os VDAs de áreas de trabalho com gerenciamento de energia em grupos de entrega em pool (criados pelo MCS ou Citrix Provisioning) que têm a propriedade
ShutdownDesktopsAfterUseativada são colocados no modo de manutenção quando ocorre uma interrupção. Você pode alterar esse padrão, para permitir que essas áreas de trabalho sejam usadas durante uma interrupção.No entanto, você não pode contar com o gerenciamento de energia durante a interrupção. (O gerenciamento de energia é retomado depois das operações normais serem retomadas.) Além disso, essas áreas de trabalho podem conter dados do usuário anterior, porque não foram reiniciadas.
-
Para substituir o comportamento padrão, ele deve ser ativado em todo o site e em cada grupo de entrega afetado. Execute os seguintes cmdlets do PowerShell.
Em todo o site:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $truePara cada grupo de entrega afetado, execute o seguinte comando do PowerShell:
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $trueAtivar esse recurso no site e nos grupos de entrega não afeta como a propriedade configurada
ShutdownDesktopsAfterUsefunciona durante as operações normais. Quando esse recurso é ativado, os VDAs não são reinicializados automaticamente após a conclusão do evento do LHC. Os VDAs de área de trabalho com gerenciamento de energia em grupos de entrega agrupados em pool podem reter dados de sessões anteriores até que o VDA seja reinicializado. Isso pode ocorrer quando um usuário se desconecta do VDA durante operações que não são do LHC ou quando a reinicialização pode ser acionada manualmente.
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 agente secundário pode usar até 1 GB de RAM se uma interrupção durar por um intervalo prolongado com muitos logons ocorrendo (por exemplo, 12 horas com 10.000 usuários). Esses requisitos de memória são além dos requisitos normais de RAM para o Controller, portanto, portanto, pode ser necessário aumentar a quantidade total da 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 de configuração do núcleo e do soquete da CPU
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 cache de host local, mais ainda do que a alocação de memória. Essa sobrecarga de CPU é observada somente durante o período de interrupção quando o banco de dados fica inacessível e o agente secundário está ativo.
Embora o LocalDB possa usar vários núcleos (até 4), ele é limitado a apenas um único soquete. Adicionar mais soquetes não melhora o desempenho (por exemplo, ter 4 soquetes com 1 núcleo cada). Em vez disso, a Citrix recomenda o uso de 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 em execução a 10 logons por segundo, o banco de dados aumentou 1 MB a cada 2 a 3 minutos. Quando a operação normal é retomada, o banco de dados local é recriado e o espaço é retornado. No entanto, deve haver espaço suficiente disponível na unidade onde o LocalDB está instalado para permitir o aumento do banco de dados durante uma interrupção. O cache de host local 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 agente secundário lida com todas as conexões, portanto, em sites (ou zonas) que fazem o balanceamento de carga entre vários Controllers durante operações normais, o agente secundário eleito precisa lidar com muito mais solicitações do que o normal durante uma interrupção. Portanto, as demandas de CPU serão maiores. Cada agente secundário no site (zona) deve ser capaz de lidar com a carga adicional imposta pelo banco de dados do cache de host local e todos os VDAs afetados, porque o agente secundário eleito durante uma interrupção pode mudar.
Limites de VDI:
- Em uma implantação de VDI de zona única, até 10.000 VDAs podem ser manipulados de forma eficaz durante uma interrupção.
- Em uma implantação de VDI de várias zonas, até 10.000 VDAs em cada zona podem ser manipulados 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 manipulado 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 no site pode ser afetado. Os avaliadores de carga (especialmente, regras de contagem de sessões) podem ser excedidos.
Durante o tempo que demora até que todos os VDAs se registrem em um agente secundário, o serviço pode ficar sem informações completas sobre as sessões atuais. Assim, a solicitação de conexão de um usuário durante esse intervalo pode resultar no início de uma nova sessão, mesmo que a reconexão com uma sessão existente tenha sido possível. Esse intervalo (quando o “novo” agente secundário adquire informações de sessão de todos os VDAs durante o novo registro) é inevitável. As sessões que são conectadas quando uma interrupção começa não são afetadas durante o intervalo de transição, mas as novas sessões e as reconexões de sessão podem ser afetadas.
Esse intervalo ocorre sempre que os VDAs devem se registrar:
- Uma interrupção começa: ao migrar de um agente principal para um agente secundário.
- Falha do agente secundário durante uma interrupção: ao migrar de um agente secundário que falhou para um agente secundário recém-eleito.
- Recuperação de uma interrupção: quando as operações normais são retomadas e o agente principal retoma o controle.
Você pode diminuir o intervalo diminuindo o valor do registro HeartbeatPeriodMs do Citrix Broker Protocol (padrão = 600000 ms, que é 10 minutos). Esse valor de pulsação é o dobro do intervalo que o VDA usa para pings, assim, o valor padrão resulta em um ping a cada 5 minutos.
Por exemplo, o comando a seguir altera a pulsação 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
Atenção ao alterar o valor da pulsação. Aumentar a frequência resulta em maior carga nos Controllers durante os modos normal e de interrupção.
O intervalo não pode ser eliminado inteiramente, não importando a rapidez com que os VDAs se registram.
O tempo necessário para sincronizar entre agentes 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 concluir.
Diferenças das versões do XenApp 6.x
Embora essa implementação do cache de host local compartilhe o nome do recurso Cache de Host Local no XenApp 6.x e versões anteriores do XenApp, há melhorias significativas. Essa 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. Esse cache de host local é uma implementação totalmente diferente, tecnicamente.
Gerenciar cache de host local
Para que o cache de host local funcione corretamente, a política de execução do PowerShell de cada Controller deve ser definida como RemoteSigned, Unrestricted ou Bypass.
SQL Server Express LocalDB
O software Microsoft SQL Server Express LocalDB que o cache de host local usa é instalado automaticamente quando você instala um Controller ou atualiza um Controller de uma versão anterior à 7.9. Somente o agente secundário se comunica com esse banco de dados. Você não pode usar cmdlets do PowerShell para alterar nada sobre esse banco de dados. O LocalDB não pode ser compartilhado entre Controllers.
O software do banco de dados do SQL Server Express LocalDB é instalado independentemente de o cache de host local 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 Cache de Host Local não funciona sem o banco de dados, e você não pode usar um banco de dados diferente com o agente secundário.
A instalação desse banco de dados LocalDB não tem efeito sobre se você instala ou não 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 o 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 cache de host local
-
Para ativar o cache de host local, insira:
Set-BrokerSite -LocalHostCacheEnabled $truePara determinar se o cache de host local está ativado, insira
Get-BrokerSite. Verifique se a propriedadeLocalHostCacheEnabledéTrue. -
Para desativar o cache de host local, insira:
Set-BrokerSite -LocalHostCacheEnabled $false
Lembre-se: a partir do XenApp e XenDesktop 7.16, a concessão de conexão (o recurso que precedeu o Cache de Host Local começando com a versão 7.6) foi removida 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 êxito. Verifique os logs de eventos.
- Certifique-se de que o banco de dados do SQL Server Express LocalDB foi criado em cada Delivery Controller. Isso confirma que o agente secundário pode assumir, se necessário.
- No servidor do Delivery Controller, vá para
C:\Windows\ServiceProfiles\NetworkService. - Confirme que
HaDatabaseName.mdfeHaDatabaseName_log.ldfforam criados.
- No servidor do Delivery Controller, vá para
- Force uma interrupção nos controladores de entrega. Depois de verificar se o Cache de Host Local 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 do evento, o modo da interrupção é referido como HA mode.*
Config Synchronizer Service:
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 Cache de Host Local usando o agente de cache de host local.
- 503: o Citrix Config Sync Service recebeu uma configuração atualizada. Esse evento indica o início do processo de sincronização.
- 504: o Citrix Config Sync Service importou uma configuração atualizada. A importação da configuração foi concluída com sucesso.
- 505: o Citrix Config Sync Service falhou na importação. A importação da configuração não foi concluída com sucesso. Se uma configuração anteriormente bem-sucedida estiver disponível, ela será usada se ocorrer uma interrupção. No entanto, ela não estará atualizada com a configuração atual. Se não houver nenhuma configuração anterior disponível, o serviço não poderá participar da intermediação de sessão durante uma interrupção. Nesse caso, consulte a seção de Resolução de problemas e entre em contato com o Suporte Citrix.
- 507: o Citrix Config Sync Service abandonou uma importação porque o sistema está no modo de interrupção e o agente de cache de host local está sendo usado para a intermediação. O serviço recebeu uma nova configuração, mas a importação foi abandonada porque ocorreu uma interrupção. Esse é o comportamento esperado.
- 510: não há dados de configuração do Configuration Service recebidos do Configuration Service principal.
- 517: houve um problema de comunicação com o agente primário.
- 518: script Config Sync anulado porque o agente secundário (High Availability Service) não está em execução.
High Availability Service:
Este serviço também é conhecido como agente de cache de host local.
- 3502: ocorreu uma interrupção e o agente de cache de host local está executando operações de intermediação.
- 3503: uma interrupção foi resolvida e as operações normais foram retomadas.
- 3504: indica qual agente de Cache de Host Local é eleito, além de outros agentes de Cache de Host Local envolvidos na eleição.
Forçar uma interrupção
Você pode, deliberadamente, forçar uma interrupção.
- Se a operação da sua rede é interrompida 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 tempestades de registros de VDA frequentes resultantes).
- Para testar um plano de recuperação de desastres.
- Para ajudar a garantir que o Cache de Host Local está funcionando corretamente.
- Durante a substituição ou 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 agente de Cache de Host Local a entrar no modo de interrupção, independentemente do estado do banco de dados. Definir o valor para 0 retira o agente de Cache de Host Local 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 é publicado.
CDF tracing: contém opções para os módulos ConfigSyncServer e BrokerLHC. Essas opções, juntamente com outros módulos de agentes, provavelmente identificarão o problema.
Report: se uma importação de sincronização falhar, você pode gerar um relatório. Esse relatório para no objeto que está causando o erro. Esse recurso de relatório afeta a velocidade de sincronização, portanto, a Citrix recomenda desativá-lo quando não estiver em uso.
Para ativar e produzir um relatório de rastreamento CSS, insira 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.
Depois que o relatório for gerado, insira o seguinte comando para desativar o recurso de relatório:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
Export the broker configuration: 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.