Planejamento de capacidade para mobilidade
Tópico modificado em: 2011-12-05
Determinar a quantidade de capacidade que você precisa para mobilidade é um processo iterativo de estimativa de seu uso de mobilidade, medição de sua capacidade atual, planejamento para capacidade adicional e monitoramento dos principais indicadores de desempenho. A figura a seguir ilustra as fases envolvidas no planejamento de capacidade e os fatores envolvidos em cada fase.
Fluxo de trabalho do planejamento de capacidade
.jpg "015701c0-77a2-4622-9c01-76576dea0140")
Esta seção descreve os fatores que precisam ser considerados enquanto realiza uma estimativa de seu uso de mobilidade e fornece diretrizes para determinar o dimensionamento que você precisa para implantar a mobilidade.
Para obter detalhes sobre como monitorar indicadores de uso e desempenho, veja o seguinte:
Para obter detalhes sobre como monitorar a memória do servidor, consulte Monitoramento de limites de capacidade de memória do servidor.
Para obter detalhes sobre como monitorar o uso de mobilidade, consulte Monitorando o uso do serviço de mobilidade.
Para obter detalhes sobre o monitoramento de arquivos de log de rastreamento do IIS, consulte Monitoramento de arquivos de log de rastreamento de solicitação do IIS.
Para obter detalhes sobre os contadores de desempenho que você pode usar para monitorar a mobilidade, consulte Contadores de desempenho de mobilidade.
Para obter detalhes sobre como configurar o Serviço de Mobilidade para alto desempenho, consulte Configurando o serviço de mobilidade para alto desempenho.
Fatores que influenciam a capacidade
Três fatores influenciam seu planejamento de capacidade para Servidores Front-End executando o Serviço de Mobilidade do Microsoft Lync Server 2010:
Modelo de usuário
Características do dispositivo móvel
RAM disponível
Modelo de usuário
O modelo de usuário descrito nesta seção fornece a base para as medições e recomendações de planejamento de capacidade para mobilidade.
Número médio de contatos por usuário
| Categoria de contatos | Número médio por usuário |
|---|---|
Todos os contatos |
80 |
Contatos da empresa |
64 |
Contatos federados |
8 |
Contatos PIC |
6 |
Grupos de distribuição |
2 |
Contatos usados com mais frequência |
15 |
Contatos usados mais recentemente |
10 |
Atividade diária por usuário
| Atividade diária | Número durante o horário de trabalho | Número fora do horário de trabalho |
|---|---|---|
Entradas em aplicativo móvel |
10 |
2 |
Chamadas telefônicas (número) |
10 |
2 |
Chamadas telefônicas (duração) |
2 minutos por chamada |
2 minutos por chamada |
Conferências |
1 por semana |
0 |
Participantes por conferência |
<10 |
0 |
Alterações de nota de status |
1 |
0 |
Exibições do cartão de visita |
6 |
1 |
Exibições da Lista de contatos |
9 |
1 |
Rolagens pela Lista de contatos |
3 |
0 |
Pesquisas de GAL (Lista de endereços global) |
5* |
- |
Atualizações de presença manuais |
0,5 |
0 |
Total de atualizações de presença por contato |
6 |
0 |
Encaminhamento de chamada |
0,5 |
0 |
Sessões de IM (mensagens instantâneas) (número) |
3 |
1 |
Sessões de IM (duração) |
6 minutos por sessão; 1 mensagem por 30 segundos |
6 minutos por sessão; 1 mensagem por 30 segundos |
Pesquisas de calendário (conexões com Serviços Web do Exchange) |
11 |
3 |
* Número de pesquisas GAL = 1 pesquisa manual por dia + pesquisas automáticas em nome das mensagens instantâneas e chamadas de saída. Ou seja, 1 + 2 (mensagens instantâneas) + 2 (chamadas) =5.
Características do dispositivo móvel
Os dispositivos móveis suportados para mobilidade executam diversos sistemas operacionais. A forma com a qual um sistema operacional gerencia os aplicativos quando um usuário troca para um aplicativo diferente influencia o planejamento de capacidade. Os sistemas operacionais podem ser divididos nas duas categorias a seguir para o planejamento de capacidade:
Segundo plano habilitado Quando um usuário altera para um aplicativo móvel diferente nos dispositivos móveis Apple e Windows Phone, o aplicativo móvel Lync 2010 vai para segundo plano e perde a conexão com o Lync Server 2010. O aplicativo móvel é reativado por uma notificação por push ou quando o usuário traz manualmente o aplicativo para o primeiro plano.
Sempre conectado Quando um usuário troca para um aplicativo móvel diferente em dispositivos móveis Android e Nokia, o aplicativo móvel Lync 2010 mantém a conexão com o Lync Server 2010, contanto que o usuário permaneça conectado.
Os dispositivos móveis Android e Nokia criam uma carga maior em servidores, pois mantêm a conexão com o servidor mesmo quando o usuário não está usando ativamente o aplicativo móvel.
Memória disponível
As diretrizes de dimensionamento descritas mais tarde nesta seção o ajudarão a definir a quantidade de memória necessária para mobilidade. Para determinar a quantidade de memória física disponível em seus servidores, use o contador de desempenho Memória, Mbytes Disponíveis. Esse contador de desempenho indica a quantidade de memória física em megabytes disponível para execução dos processos. Se a quantidade de memória disponível para a execução dos processos for menor do que cinco por cento (5%) do total de memória física, o servidor não terá memória suficiente, o que pode aumentar a paginação.
Diretrizes de dimensionamento
O Serviço de Mobilidade usa memória adicional, recursos de processador e recursos de rede no Servidores Front-End. quando você planeja a capacidade, é necessário entender o impacto da carga de mobilidade sobre o Pool de Front-Ends e decidir se você precisa de mais hardware para a carga de mobilidade. Use os exemplos de dimensionamento na tabela a seguir para ajudar a determinar se é preciso ter mais hardware e quanto.
Os exemplos na tabela têm base em algumas fórmulas e suposições. As fórmulas e suposições usam as seguintes definições:
AC significa o número de aplicativos móveis que estão sempre conectados no modelo de usuário.
BE significa o número de aplicativos móveis que estão habilitados para segundo plano no modelo de usuário.
As fórmulas e suposições são as seguintes:
Memória de destino (TM) em Mbytes = 164 + (AC * 534 + BE * 400) / 1024.
TM é a memória mínima exigida.
Com o modelo de usuário descrito anteriormente, o número de conexões com o Pool de Front-Ends é de AC * 2 + BE * .20.
A memória medida pode ser superior (até 1 MB por ponto de extremidade) quando não há pressão por memória no servidor. A memória de destino pode ser superior se seu modelo de usuário for mais agressivo, por exemplo, quando há mais chamadas de áudio/vídeo (A/V) ou contatos etc.
O número de conexões criadas por segundo é menor ou igual a 30/segundo por 1.000 usuários. Esse número depende das configurações do pool de conexões no balanceador de carga de hardware e em configurações keep-alive.
A tabela a seguir mostra exemplos do dimensionamento para 50% dos usuários sempre conectados no modelo de usuário.
Exemplos de dimensionamento
| Número de usuários | Memória (MB) | CPU média | Máximo de CPU |
|---|---|---|---|
1.000 |
620,05 |
1% |
2,5% |
2.000 |
1076,11 |
6% |
8% |
3.000 |
1532,16 |
14% |
18% |
4.000 |
1988,22 |
14% |
18% |
5.000 |
2444,27 |
14% |
18% |
Exemplos de cenário
Os exemplos a seguir mostram como as diretrizes de dimensionamento são aplicadas a uma empresa fictícia de grande porte e a um Pool de Front-Ends que inclui dois servidores.
Empresa de grande porte
A Contoso implantou 75.000 usuários em três pools com quatro Servidores Front-End em cada pool. A planeja habilitar os serviços de mobilidade para 30.000 usuários.
Durante a fase de planejamento, os administradores da Contoso capturaram os seguintes dados:
Cada Servidor Front-Endtem 3 GB de memória disponível.
A utilização da CPU é menor que 60%.
Todos os usuários têm um dispositivo móvel iPhone ou Windows Phone.
O modelo de usuário da Contoso é semelhante ao modelo de usuário de planejamento de capacidade descrito anteriormente nesta seção.
O mínimo necessário é de memória para cada servidor 164 + 2500 * 400 / 1024 = 1.133 MB. Quando há memória disponível, mais memória pode ser alocada aos aplicativos móveis, pois a memória é liberada conforme o necessário, até 2,7 GB. Em ambas as situações, a Contoso não precisa atualizar o hardware do Servidor Front-End.
.gif "note") Observação: |
|---|
| A meta para utilização de CPU para mobilidade é uma média de 10%. A Contoso precisa monitorar o tempo de processador da CPU à medida que chega perto do limite de servidor de 70%. |
Pool de Front-Ends com dois servidores
A Contoso implantou 8.000 usuários em um Pool de Front-Ends com dois servidores. A Contoso planeja habilitar os serviços de mobilidade para todos os usuários.
Durante a fase de planejamento, os administradores da Contoso capturaram os seguintes dados:
Cada Servidor Front-Endtem 2,5 GB de memória disponível.
A utilização da CPU é menor que 60%.
Todos os usuários têm um dispositivo móvel Nokia ou Android.
O modelo de usuário da Contoso é semelhante ao modelo de usuário de planejamento de capacidade descrito anteriormente nesta seção.
O mínimo necessário é de memória para cada servidor 164 + 4000 * 534 / 1024 = 2242 MB. Em teoria, um servidor pode suportar a carga. No entanto, um servidor não suportará a carga se um failover ocorrer entre os dois servidores. Além disso, a utilização da CPU para mobilidade ficará acima de 10% e o limite de 70% de CPU do servidor será atingido.
Nesse cenário, a recomendação é adicionar um servidor ao pool. A nova distribuição de carga é de 2667 (ou seja, 8000/3) usuários por Servidor Front-End. O custo de mobilidade adicional é de 2667 * 534 / 1024 = 1390 MB.
Com a adição de um servidor, caso ocorra a falha de um servidor, cada um desses três servidores no pool aceitará 1.300 usuários adicionais e o aumento na carga será de 600 MB. Com a nova distribuição de carga, a utilização de CPU também permanecerá abaixo do limite de 70% do servidor.