Planejamento de capacidade do App-V
Aplica-se ao Windows Server 2016
As recomendações a seguir podem ser usadas como uma linha de base para ajudar a determinar informações de planejamento de capacidade apropriadas à infraestrutura de App-V da sua organização.
Importante
Use as informações nesta seção apenas como um guia geral para planejar sua implantação do App-V. Os requisitos de capacidade do sistema dependerão dos detalhes específicos do seu ambiente de hardware e aplicativo. Além disso, os números de desempenho exibidos neste documento são exemplos e seus resultados podem variar.
Determinar o escopo do projeto
Antes de projetar a infraestrutura do App-V, determinar quais aplicativos estarão disponíveis virtualmente e também identificar os usuários de destino e suas localizações. Essas informações determinarão que tipo de infraestrutura de App-V seu projeto deve implementar. Você deve basear suas decisões sobre o escopo do projeto nas necessidades específicas da sua organização.
| Tarefa | Mais informações |
|---|---|
| Determinar o escopo do aplicativo | A infraestrutura do App-V pode ser configurada de diferentes maneiras, dependendo de quais aplicativos você deseja virtualizar. Essa personalização na configuração significa que sua primeira tarefa é definir quais aplicativos você deseja virtualizar. |
| Determinar o escopo de localização | "Escopo de localização" refere-se aos locais físicos em que você planeja executar os aplicativos virtualizados (por exemplo, em toda a empresa ou em um local geográfico específico). Ele também pode se referir à população de usuários que executará os aplicativos virtuais (por exemplo, um único departamento). Você deve obter um mapa de rede que inclua os caminhos de conexão, a largura de banda disponível para cada local, o número de usuários usando aplicativos virtualizados e a velocidade do link WAN. |
Determinar qual infraestrutura do App-V é necessária
Você também pode gerenciar seu ambiente App-V usando uma solução ESD (distribuição de software eletrônico), como o Microsoft Systems Center Configuration Manager. Para obter mais informações, consulte Como implantar pacotes de App-V usando a distribuição de software eletrônico.
Modelo autônomo— O modelo autônomo permite que aplicativos virtuais sejam habilitados para Windows Installer para distribuição sem streaming. O App-V no modo Autônomo só precisa do sequenciador e do cliente; nenhum componente extra é necessário. Os aplicativos estão preparados para virtualização usando um processo chamado sequenciamento. Para obter mais informações, confira Planejamento para a implantação do Sequenciador do App-V e do Cliente. O modelo autônomo é recomendado para os seguintes cenários:
- Quando há usuários remotos desconectados que não podem se conectar à infraestrutura do App-V.
- Quando você está executando um sistema de gerenciamento de software, como Configuration Manager.
- Quando limitações de largura de banda de rede inibem a distribuição de software eletrônico.
Modelo completo de infraestrutura– o modelo completo de infraestrutura fornece recursos de distribuição, gerenciamento e relatórios de software; ele também inclui o streaming de aplicativos em toda a rede. O modelo de infraestrutura completa do App-V consiste em um ou mais servidores de gerenciamento do App-V que podem ser usados para publicar aplicativos para todos os clientes. A publicação coloca os ícones e atalhos do aplicativo virtual no computador de destino. Ele também pode transmitir aplicativos para usuários locais. Para obter mais informações sobre como instalar o servidor de gerenciamento, consulte Planejamento para implantação do Servidor App-V. O modelo de infraestrutura completo é recomendado para os seguintes cenários:
- Quando você quiser usar o Servidor de Gerenciamento para publicar o aplicativo para os computadores de destino.
- Para provisionamento rápido de aplicativos para computadores de destino.
- Quando você quiser usar relatórios do App-V.
Importante
O modelo de infraestrutura completa do App-V exige que a Microsoft SQL Server armazene dados de configuração. Para obter mais informações, confira Configurações com suporte para App-V.
Diretrizes de dimensionamento de servidor de ponta a ponta
A seção a seguir descreve o dimensionamento e o planejamento do App-V de ponta a ponta. Para obter informações mais específicas, consulte as seções subsequentes.
Observação
O tempo de resposta de ida e volta no cliente é o tempo gasto pelo computador que executa o cliente App-V para receber uma notificação bem-sucedida do servidor de publicação. O tempo de resposta de ida e volta no servidor de publicação é o tempo gasto pelo computador que executa o servidor de publicação para receber uma atualização de metadados de pacote bem-sucedida do servidor de gerenciamento.
- 20.000 clientes podem direcionar um único servidor de publicação para obter as atualizações de pacote em um tempo aceitável de ida e volta (<3 segundos).
- Um único servidor de gerenciamento pode dar suporte a até 50 servidores de publicação para atualizações de metadados de pacote em um tempo aceitável de ida e volta (<5 segundos).
Recomendações de planejamento de capacidade do Servidor de Gerenciamento do App-V
Os servidores de publicação do App-V exigem o servidor de gerenciamento para solicitações de atualização de pacote e respostas de atualização de pacote. Em seguida, o servidor de gerenciamento envia as informações para o banco de dados de gerenciamento para recuperar informações. Para obter mais informações sobre configurações com suporte para servidor de gerenciamento do App-V, confira Configurações com suporte para App-V.
Observação
O tempo padrão de atualização no servidor de publicação do App-V é de dez minutos.
Quando vários servidores de publicação simultâneos contatarem um único servidor de gerenciamento para atualizações de metadados de pacote, os três fatores a seguir influenciarão o tempo de resposta de ida e volta do servidor de publicação:
- O número de servidores de publicação que fazem solicitações simultâneas.
- O número de grupos de conexão configurados no servidor de gerenciamento.
- O número de grupos de acesso configurados no servidor de gerenciamento.
A tabela a seguir descreve cada fator que afeta o tempo de ida e volta com mais detalhes.
Observação
O tempo de resposta de ida e volta é o tempo gasto pelo computador que executa o servidor de publicação do App-V para receber uma atualização de metadados de pacote bem-sucedida do servidor de gerenciamento.
| Fatores que afetam o tempo de resposta de ida e volta | Descrição |
|---|---|
| O número de servidores de publicação solicitando simultaneamente atualizações de metadados de pacote. | Um único servidor de gerenciamento pode responder a até 320 servidores de publicação solicitando simultaneamente metadados de publicação. Por exemplo, em um caso com 30 servidores de publicação solicitando simultaneamente metadados de publicação, o tempo de resposta de ida e volta é de cerca de 40 segundos, enquanto para menos de 50 servidores é menor que 5 segundos. De 50 a 320 servidores de publicação, a equipe de resposta aumenta linearmente (aproximadamente 2×). |
| O número de grupos de conexão configurados no servidor de gerenciamento. | Para até 100 grupos de conexão, não há nenhuma alteração significativa no tempo de resposta de ida e volta no servidor de publicação. Para grupos de conexão de 100 a 400, há um pequeno aumento linear no tempo de resposta de ida e volta. |
| O número de grupos de acesso configurados no servidor de gerenciamento. | Para até 40 grupos de acesso, há um aumento linear (aproximadamente 3×) no tempo de resposta de ida e volta no servidor de publicação. |
A tabela a seguir exibe valores de exemplo para cada um dos fatores anteriores. Em cada variação, 120 pacotes são atualizados do servidor de gerenciamento do App-V.
| Cenário | Variação | Número de grupos de conexões | Número de grupos de acesso | Número de servidores de publicação | Tipo de conexão de rede | Tempo de resposta de ida e volta (segundos) | Utilização da CPU do servidor de gerenciamento |
|---|---|---|---|---|---|---|---|
| Os servidores de publicação entram em contato com o servidor de gerenciamento para publicar metadados ao mesmo tempo | Número de servidores de publicação. | 0 0 0 0 0 0 |
1 1 1 1 1 1 |
50 100 200 300 315 320 |
LAN | 5 10 19 32 30 37 |
17 17 17 15 17 15 |
| A publicação de metadados contém grupos de conexão | Número de grupos de conexões | 10 20 100 150 300 400 |
1 1 1 1 1 1 |
100 100 100 100 100 100 |
LAN | 10 11 11 16 22 25 |
17 19 22 19 20 20 |
| Os metadados de publicação contêm grupos de acesso | Número de grupos de acesso | 0 0 0 0 |
1 10 20 40 |
100 100 100 100 |
LAN | 10 43 153 535 |
17 26 24 24 |
A utilização da CPU do computador que executa o servidor de gerenciamento é cerca de 25%, independentemente do número de servidores de publicação direcionados a ele. A Microsoft SQL Server transações de banco de dados/s, solicitações em lote/s e conexões de usuário são idênticas, independentemente do número de servidores de publicação. Por exemplo, transações/s são aproximadamente 30, solicitações em lote aproximadamente 200 e o usuário se conecta aproximadamente seis.
Por meio de uma implantação distribuída geograficamente, em que o servidor de gerenciamento e os servidores de publicação utilizam uma rede de vínculo lento entre eles, o tempo de resposta de ida e volta nos servidores de publicação está dentro dos limites de tempo aceitáveis (<5 segundos), mesmo para 100 solicitações simultâneas em um único servidor de gerenciamento.
| Cenário | Variação | Número de grupos de conexões | Número de grupos de acesso | Número de servidores de publicação | Tipo de conexão de rede | Tempo de resposta de ida e volta (segundos) | Utilização da CPU do servidor de gerenciamento (em %) |
|---|---|---|---|---|---|---|---|
| Conexão de rede entre o servidor de publicação e o servidor de gerenciamento | Rede de link lento de 1,5 Mbps | 0 0 |
1 1 |
50 100 |
DSL do cabo de 1,5 Mbps | 4 5 |
1 2 |
| Conexão de rede entre o servidor de publicação e o servidor de gerenciamento | Rede LAN/WiFi | 0 0 |
1 1 |
100 200 |
WiFi | 11 20 |
15 17 |
Se o servidor de gerenciamento e os servidores de publicação estão conectados em uma rede de link lenta ou em uma rede de alta velocidade, o servidor de gerenciamento pode lidar com aproximadamente 15.000 solicitações de atualização de pacote em 30 minutos.
Recomendações de planejamento de capacidade do Servidor de Relatórios do App-V
Os clientes do App-V enviam dados de relatório para o servidor de relatórios. O servidor de relatórios então registra as informações no banco de dados do Microsoft SQL Server e retorna uma notificação bem-sucedida de volta ao computador que executa o cliente App-V. Para obter mais informações sobre as configurações com suporte do Servidor de Relatórios do App-V, consulte Configurações com suporte para App-V.
Observação
O tempo de resposta de ida e volta é o tempo gasto pelo computador que executa o cliente App-V para enviar as informações de relatório para o servidor de relatórios e receber uma notificação bem-sucedida do servidor de relatórios.
| Cenário | Resumo |
|---|---|
| Vários clientes do App-V enviam informações de relatório ao servidor de relatórios simultaneamente. | O tempo de resposta de ida e volta do servidor de relatórios é de 2,6 segundos para 500 clientes. O tempo de resposta de ida e volta do servidor de relatórios é de 5,65 segundos para 1000 clientes. O tempo de resposta de ida e volta aumenta linearmente dependendo do número de clientes. |
| Solicitações por segundo processadas pelo servidor de relatórios. | Um único servidor de relatórios e um único banco de dados podem processar um máximo de 139 solicitações por segundo. A média é de 121 solicitações/segundo. Com a ajuda de dois servidores de relatório que relatam para o mesmo banco de dados do Microsoft SQL Server, a média de solicitações/segundo, como um único servidor de relatórios, é de cerca de 127, com um máximo de 278 solicitações/segundo. Um único servidor de relatórios pode processar 500 conexões simultâneas/ativas. Um único servidor de relatórios pode processar um máximo de 1.500 conexões simultâneas. |
| Banco de dados de relatórios. | A contenção de bloqueio no computador que executa o Microsoft SQL Server é o fator limitante para solicitações/segundo. A taxa de transferência e o tempo de resposta são independentes do tamanho do banco de dados. |
Calcular atraso aleatório
O atraso aleatório especifica o atraso máximo (em minutos) para que os dados sejam enviados ao servidor de relatórios. Quando a tarefa agendada é iniciada, o cliente gera um atraso aleatório entre 0 e ReportingRandomDelay e aguardará a duração especificada antes de enviar dados.
Atraso aleatório = 4 × número de clientes/solicitações médias por segundo.
Exemplo: o atraso aleatório para 500 clientes com 120 solicitações por segundo é 4 × 500/120 = cerca de 17 minutos.
Recomendações de planejamento de capacidade do servidor de publicação do App-V
Os computadores que executam o cliente App-V se conectam ao servidor de publicação do App-V para enviar uma solicitação de atualização de publicação e receber uma resposta. O tempo de resposta de ida e volta é medido no computador que executa o cliente App-V, enquanto o tempo do processador é medido no servidor de publicação. Para obter mais informações sobre configurações compatíveis com o Servidor de Publicação do App-V, confira Configurações com suporte para App-V.
Importante
A lista a seguir exibe os fatores main a serem considerados ao configurar o servidor de publicação do App-V:
- O número de clientes que se conectam simultaneamente a um único servidor de publicação.
- O número de pacotes em cada atualização.
- A largura de banda de rede disponível em seu ambiente entre o cliente e o servidor de publicação do App-V.
| Cenário | Resumo |
|---|---|
| Vários clientes do App-V se conectam a um único servidor de publicação simultaneamente. | Um servidor de publicação que executa processadores dual core pode responder a no máximo 5.000 clientes solicitando uma atualização simultaneamente. Para 5.000 a 10.000 clientes, o servidor de publicação requer um quad core mínimo. Para 10.000 a 20.000 clientes, o servidor de publicação deve ter núcleos quad duplos para tempos de resposta mais eficientes. Um servidor de publicação com um quad core pode atualizar até 10.000 pacotes em três segundos. (Dá suporte a 10.000 clientes simultâneos.) |
| Número de pacotes em cada atualização. | O aumento do número de pacotes aumentará o tempo de resposta em cerca de 40% (até 1.000 pacotes). |
| Rede entre o cliente App-V e o servidor de publicação. | Em uma rede lenta (largura de banda de 1,5 Mbps), há um aumento de 97% no tempo de resposta em comparação com a LAN (até 1.000 usuários). |
Observação
O uso da CPU do servidor de publicação é sempre alto durante o intervalo de tempo em que deve processar solicitações simultâneas (>90% na maioria dos casos). O servidor de publicação pode lidar com cerca de 1.500 solicitações de cliente em um segundo.
| Cenário | Variação | Número de clientes do App-V | Número de pacotes | Configuração do processador no servidor de publicação | Tipo de conexão de rede | Tempo de ida e volta do cliente app-V (em segundos) | Utilização da CPU do servidor de publicação (em %) |
|---|---|---|---|---|---|---|---|
| O cliente app-V envia a solicitação de atualização de publicação e recebe a resposta, cada solicitação que contém 120 pacotes | Número de clientes | 100 1,000 5,000 10,000 |
120 120 120 120 |
Dual Core Dual Core Quad Core Quad Core |
LAN | 1 2 2 3 |
100 99 89 77 |
| Vários pacotes em cada atualização. | Número de pacotes | 1,000 1,000 |
500 1,000 |
Quad Core | LAN | 2 3 |
92 91 |
| Rede entre o cliente e o servidor de publicação. | Rede de link lento de 1,5 Mbps | 100 500 1,000 |
120 120 120 |
Quad Core | Rede intracontinental de 1,5 Mbps | 3 10 (taxa de falha de 0,2%). 7 (taxa de falha de 1%). |
Recomendações de planejamento de capacidade de streaming do App-V
Os computadores que executam o cliente App-V transmitem o pacote de aplicativos virtuais do servidor de streaming. O tempo de resposta de ida e volta é medido no computador que executa o cliente App-V e é o tempo necessário para transmitir todo o pacote.
Importante
A lista a seguir identifica os fatores main a serem considerados ao configurar o servidor de streaming do App-V:
- O número de clientes que streaming pacotes de aplicativos simultaneamente de um único servidor de streaming.
- O tamanho do pacote que está sendo transmitido.
- A largura de banda de rede disponível em seu ambiente entre o cliente e o servidor de streaming.
| Cenário | Resumo |
|---|---|
| Vários clientes do App-V transmitem aplicativos de um único servidor de streaming simultaneamente. | Se o número de clientes transmitindo simultaneamente do mesmo servidor aumentar, haverá uma relação linear com o tempo de download/streaming do pacote. |
| Tamanho do pacote que está sendo transmitido. | O tamanho do pacote tem um impacto significativo no tempo de streaming/download apenas para pacotes maiores com um tamanho de cerca de 1 GB. Para tamanhos de pacote que variam de 3 MB a 100 MB, o tempo de streaming varia de 20 segundos a 100 segundos, com 100 clientes simultâneos. |
| Rede entre o cliente App-V e o servidor de streaming. | Em uma rede lenta (largura de banda de 1,5 Mbps), há um aumento de 70 a 80% no tempo de resposta em comparação com a LAN (até 100 usuários). |
A tabela a seguir exibe valores de exemplo para cada um dos fatores da lista anterior:
| Cenário | Variação | Número de clientes do App-V | Tamanho de cada pacote | Tipo de conexão de rede | Tempo de ida e volta no cliente App-V (em segundos) |
|---|---|---|---|---|---|
| Vários clientes do App-V transmitindo pacotes de aplicativos virtuais de um servidor de streaming. | Número de clientes. | 100 200 1,000 100 200 1,000 |
3,5 MB 3,5 MB 3,5 MB 5 MB 5 MB 5 MB |
LAN | 29 39 391 35 68 461 |
| Tamanho de cada pacote que está sendo transmitido. | Tamanho de cada pacote. | 100 200 100 200 |
21 MB 21 MB 109 MB 109 MB |
LAN | 33 83 100 160 |
| Conexão de rede entre o cliente e o servidor de streaming do App-V. | Rede de link lento de 1,5 Mbps. | 100 100 |
3,5 MB 5 MB |
Rede intracontinental de 1,5 Mbps | 102 121 |
Cada servidor de streaming do App-V deve ser capaz de lidar com um mínimo de 200 clientes transmitindo simultaneamente aplicativos virtualizados.
Observação
O tempo real que ele levará para transmitir é determinado principalmente pelo número de clientes que transmitem simultaneamente, número de pacotes, tamanho do pacote, atividade de rede do servidor e condições de rede.
Por exemplo, um usuário médio pode transmitir um pacote de 100 MB em menos de 2 minutos, quando 100 clientes simultâneos são transmitidos do servidor. No entanto, um pacote de tamanho 1 GB pode levar até 30 minutos. Na maioria dos ambientes do mundo real, a demanda de streaming não é distribuída uniformemente, você precisará entender os requisitos de streaming de pico aproximados presentes em seu ambiente para dimensionar corretamente o número de servidores de streaming necessários.
O número de clientes que um servidor de streaming pode dar suporte pode ser aumentado e os requisitos de streaming de pico reduzidos se você pré-armazenar em cache seus aplicativos. Você também pode aumentar o número de clientes que um servidor de streaming pode dar suporte usando a entrega de streaming sob demanda e transmitir pacotes otimizados.
Combinando funções de servidor App-V
Descontando requisitos de escala e tolerância a falhas, o número mínimo de servidores que um local com conectividade do Active Directory precisa funcionar é 1. Esse servidor hospedará as funções de servidor de gerenciamento, servidor de gerenciamento e Microsoft SQL Server. Essa cobertura significa que você pode organizar funções de servidor em qualquer combinação que desejar, pois elas não entram em conflito entre si.
Não obstante os requisitos de dimensionamento, o número mínimo de servidores que uma implementação tolerante a falhas precisa funcionar é quatro. O servidor de gerenciamento e as funções do Microsoft SQL Server dão suporte à colocação em configurações tolerantes a falhas. O serviço do servidor de gerenciamento pode ser combinado com qualquer uma das funções, mas continua sendo um único ponto de falha.
Embora existam muitas estratégias e tecnologias de tolerância a falhas que você pode usar, nem todas são aplicáveis a um determinado serviço. Além disso, se as funções App-V forem combinadas, as incompatibilidades resultantes poderão fazer com que determinadas opções de tolerância a falhas parem de funcionar.