Obrigado pelos seus comentários.
Limites de capacidade do usuário para serviços híbridos baseados em Expressway
Comentários?O serviço de chamada híbrido na arquitetura Call Connector perdeu o fim da vida útil (EOL), portanto, o serviço não é mais suportado oficialmente. O Call Connector não deve ser considerado para o planejamento futuro da capacidade da Expressway para serviços híbridos.
Este artigo não aborda o planejamento de capacidade para a integração do Hybrid Calendar Service Cisco TMS com o Office 365 ou a integração do Cisco TMS com o Google Calendar. Para obter informações sobre capacidade, consulte o Guia de implantação Cisco Webex do Hybrid Calendar Service.
Fornecemos este artigo para abordar suas questões de planejamento de capacidade e explicar como calculamos a escala do usuário. Para modelar seu cenário, experimente a calculadora de capacidade de serviços híbridos.
Considerações de planejamento
Ao planejar a capacidade do Expressway para sua população de usuários de serviços híbridos, considere as seguintes questões:
-
Quais serviços híbridos você precisa?
O Expressway pode hospedar conectores para Hybrid Call Service, Hybrid Calendar Service e Hybrid Message Service.
-
Quantos usuários você tem, para cada serviço?
Quanto mais usuários você tiver para cada serviço, maior a probabilidade de você querer dedicar clusters do Expressway aos serviços. Para populações menores, executar vários conectores em um cluster compartilhado (coresidência) é uma opção válida.
-
Suas necessidades vão mudar?
Talvez você queira começar aos poucos, com um cluster Expressway fornecendo serviços a um grupo de pioneiros em sua organização, e planejar o crescimento para uma implantação futura. Você pode migrar de um modelo compartilhado para um modelo dedicado ou escalar seu cluster existente para atender às suas necessidades em constante evolução.
Fatores contribuintes
Definimos a capacidade de um cluster em termos das seguintes variáveis:
-
Tamanho do nó — cada máquina virtual Expressway tem um “tamanho de VM” que é determinado no momento da instalação pelos recursos atribuídos à VM. Os guias de instalação do Expressway descrevem esses requisitos. Se você já tem um Expressway, pode ler o tamanho da VM na página da interface do Expressway.
-
Contagem de nós — Um cluster Expressway pode ter entre um e seis nós. Eles devem ter o mesmo tamanho de nó e executar a mesma versão do software.
-
Estratégia de continuidade do serviço — Os serviços usam estratégias para garantir o serviço contínuo aos usuários. O Calendar Service e o Message Service usam uma estratégia de failover.
As estratégias estão detalhadas na tabela Estratégias de continuidade de serviços e escala de clusters dedicados.
-
Coresidência — quando os conectores compartilham um cluster Expressway, os recursos disponíveis para cada serviço são significativamente menores em comparação com o cluster dedicado.
Também pode haver outros serviços baseados no Expressway em seu host de conectores, como chamadas entre empresas (B2B) ou Mobile and (MRA). Remote Access Nos cenários limitados em que esse tipo de coresidência é suportado, os números da escala que documentamos aqui são restritos ao que testamos. Além do descrito neste artigo, o cluster Expressway do host do conector não deve ser compartilhado com outros serviços; isso não é suportado.
-
Limitações específicas do serviço — Por exemplo, o Conector de Calendário é destinado principalmente a Microsoft Exchange usuários e oferece suporte a um número limitado de usuários do Office 365.
Cálculos para clusters dedicados de vias expressas
Estabelecemos um limite rígido para o número de usuários do serviço que um único Expressway dedicado pode gerenciar (um “cluster de um”), com base nas evidências que reunimos em testes e ensaios.
| Tamanho do nó do Expressway | Escala de serviço de calendário híbrido | Escala de serviço de mensagens híbridas |
|---|---|---|
| 1. Pequeno | 5000 | 5000 |
| 2. Médio | 10000 | 6500 |
| 3. Grande | 15000 | 15000 |
Usamos os algoritmos de continuidade de serviço para extrapolar os números de um único nó para vários clusters de nós, conforme explicado na tabela a seguir. Se você quiser os resultados sem a explicação, veja:
|
Compare |
Serviço de calendário híbrido |
Serviço de mensagens híbrido |
|---|---|---|
|
1. modelo |
Modelo de failover |
Modelo de failover |
|
2. Descrição |
Atribuímos cada usuário a um nó no cluster. Isso distribui os usuários por todos os nós. Se um nó ficar inativo, recriamos as atribuições do usuário desse nó nos outros nós. Quando o nó volta a funcionar, rebalanceamos as atribuições do usuário em todos os nós ativos. |
Atribuímos cada usuário a um nó no cluster. Isso distribui os usuários por todos os nós. Se um nó ficar inativo, recriamos as atribuições do usuário desse nó nos outros nós. Quando o nó volta a funcionar, rebalanceamos as atribuições do usuário em todos os nós ativos. |
|
3. Fórmula |
U CalN = (N-1) * U cal1 |
U msgN = (N-1) * U msg1 |
|
4. Definições |
Onde: U CalN é o cluster de capacidade N para usuários do Calendar Service. N é a contagem de nós U cal1 é a capacidade de um único nó para usuários do Calendar Service |
Onde: U MsgN é o cluster de capacidade N para usuários do Serviço de Mensagens. N é a contagem de nós U msg1 é a capacidade de nó único para usuários do Serviço de Mensagens |
|
5. Notas |
Se N=1, não haverá failover. O failover é automático e obrigatório se N>1. Se N = 2, a capacidade é a mesma que se N = 1, com melhor continuidade do serviço. A escala se beneficia de N>=3 ou usando um tamanho de nó maior. |
Se N=1, não haverá failover. O failover é automático e obrigatório se N>1. Se N = 2, a capacidade é a mesma que se N = 1, com melhor continuidade do serviço. A escala se beneficia de N>=3 ou usando um tamanho de nó maior. |
Cálculos para clusters compartilhados do Expressway
Nosso algoritmo pressupõe que os conectores coresidentes compartilham proporcionalmente os recursos de um único nó. Esse algoritmo define de forma conservadora o limite para cada tipo de usuário no nó.
Por exemplo, a tabela a seguir mostra o número máximo de usuários para todos os casos dedicados e os casos de coresidência em uma única via expressa média.
| Objetivo da via expressa | Usuários do serviço de calendário | Usuários do serviço de mensagens |
|---|---|---|
|
| ||
| Dedicado ao serviço de calendário |
10,000 |
— |
|
Dedicado ao serviço de mensagens |
— |
6,500 |
|
Compartilhado pelo serviço de calendário e pelo serviço de mensagens |
4,000 |
4,000 |
|
Compartilhado por serviços de calendário, chamadas e mensagens |
2,300 |
2,300 |
Não listamos exaustivamente todos os estados de coresidência para todos os tamanhos de clusters. Em vez disso, você pode monitorar a capacidade de sua implantação existente de Serviços Híbridos ou usar a calculadora para planejar uma nova implantação.
A calculadora permite que você escolha conectores, tamanho e contagem de nós, para que você possa modelar sua implantação. O restante desta seção explica como ele calcula os números de usuários do seu modelo.
Assim como fizemos com o Expressway dedicado, extrapolamos o algoritmo para Expressways compartilhados para determinar os números de usuários de vários nós. A diferença dos casos dedicados é que aplicamos o cálculo apropriado da continuidade do serviço para obter a escala do usuário para um serviço específico no cluster. Não podemos calcular a escala de usuários do cluster porque o cluster hospeda estratégias concorrentes de continuidade de serviços baseadas no usuário.
|
Objetivo do cluster |
Usuários do Hybrid Message Service para 1,2 e 3 nós | ||
|---|---|---|---|
|
Dedicado ao serviço de mensagens |
6,500 |
6,500 |
13,000 |
Fatores contribuintes adicionais
Pode haver demandas concorrentes sobre os recursos do cluster que diminuirão a capacidade do usuário. Estes são os exemplos conhecidos:
Serviço de calendário — O host do conector também pode atender usuários do O365. Os números e cálculos mostrados aqui pressupõem que somente sua infraestrutura local do Exchange forneça o Serviço de Calendário. Para saber mais sobre o serviço de calendário “híbrido”, temos alguns números e gráficos na seção Serviço de calendário deste artigo.
Processamento de chamadas — O host do conector também pode processar a sinalização de chamadas e a mídia. Essa é efetivamente uma integração de “empresa a empresa” entre sua organização e a nuvem Webex. Isso reduz a capacidade conforme descrito em Coresidência com outras soluções Expressway.
Você pode usar o Control Hub para visualizar um valor percentual da capacidade atual do usuário de cada um dos seus recursos do Hybrid Services Expressway. Uma barra colorida indica se a capacidade está dentro dos limites aceitáveis. Essa visualização permite avaliar a integridade de suas implantações de serviços híbridos e orienta você sobre quando você precisa de mais vias expressas.
-
Verde — Suas vias expressas estão dentro dos limites de capacidade aceitáveis. (1%–60%)
-
Âmbar — Você tem vias expressas suficientes, mas está perto de atingir os limites de capacidade. (61%–90%)
-
Vermelho — Você não tem vias expressas suficientes e precisa adicionar mais. (91% ou mais)
Se seus Expressways estiverem em um grupo de recursos, o indicador de capacidade aparecerá sob uma exibição filtrada dos clusters no grupo de recursos.
-
Para implantações sem grupos de recursos (padrão):
-
Na visualização do cliente em https://admin.webex.com, acesse e, em seguida, vá até os cartões de serviço híbridos para ver a porcentagem da capacidade usada nos recursos do Expressway para cada serviço.
-
-
Para implantações com grupos de recursos:
-
Se o valor da capacidade for N/A, escolha um grupo de recursos em Filtro para revisar os grupos de recursos e a capacidade.
O valor é atualizado para mostrar a porcentagem da capacidade usada para clusters nesse grupo de recursos e a codificação por cores para indicar a integridade.
-
Coisas para manter em mente
-
A capacidade do cluster varia de acordo com o tamanho do nó, o número de nós no cluster Expressway, quantos serviços estão em execução no cluster e a estratégia de alta disponibilidade ou failover. Para obter mais informações, consulte as seções individuais de calendário e escala de mensagens.
-
A coresidência reduz a escala de usuários dos serviços existentes; o algoritmo de capacidade pressupõe que cada usuário esteja usando todos os serviços.
Recomendamos a coresidência quando você estiver testando vários serviços ou se tiver uma implantação em pequena escala. Para serviços em produção ou para implantações em grande escala, recomendamos que você execute os diferentes serviços híbridos em clusters dedicados do Expressway.
O que fazer a seguir
Para adicionar mais Expressways for Hybrid Services, use as etapas do guia de implantação para registrar hosts de conectores na nuvem e adicioná-los aos clusters existentes:
A capacidade de um cluster Expressway de atender usuários do Hybrid Calendar Service depende do tamanho dos nós constituintes do Expressway-C, do número de nós no cluster do Expressway e da estratégia de continuidade do serviço.
A tabela a seguir mostra o número máximo de usuários em um único Expressway dedicado aos diferentes ambientes de calendário híbrido.
|
Ambiente de calendário |
Via expressa pequena |
Via expressa média |
Grande via expressa |
|---|---|---|---|
|
Somente para Exchange local |
5.000 usuários |
10.000 usuários |
15.000 usuários |
|
Somente Office 365* |
1.000 usuários |
1.000 usuários |
1.000 usuários |
|
Exchange local e Office 365* (implantações híbridas do Exchange) |
Máximo de 1.000 usuários do Office 365 de um total de 5.000 usuários |
Máximo de 1.000 usuários do Office 365 de um total de 10.000 usuários |
Máximo de 1.000 usuários do Office 365 de um total de 15.000 usuários |
* Para evitar essa limitação de escala, recomendamos que você use o Serviço de Calendário baseado em nuvem em vez do conector local. Para o calendário híbrido baseado em Expressway, a limitação da capacidade de usuário do Office 365 para 1.000 por cluster é independente do tamanho ou da contagem de nós do cluster; essa limitação deriva da interação com o serviço de nuvem da Microsoft e não da escala da implantação local do Expressway.
Observe que a capacidade do usuário é a mesma para um cluster de um nó e para um cluster de dois nós. Isso ocorre porque o Calendar Service usa o failover para melhorar a continuidade do serviço. Todos os usuários são atribuídos a um nó quando há dois nós no cluster; o outro nó é um backup redundante. Consulte Planejando a capacidade do cluster Expressway para usuários de serviços híbridos para obter uma explicação detalhada.
A capacidade de um cluster Expressway para usuários do Hybrid Calendar Service depende principalmente do tamanho e do número de nós no cluster e da estratégia de continuidade do serviço. A tabela a seguir mostra a capacidade máxima total do usuário que o cluster pode manipular à medida que você aumenta os nós (ou o tamanho do OVA do nó) em um único cluster dedicado.
Em um ambiente híbrido do Exchange com usuários do Office 365, há um limite de 1.000 usuários do Office 365 por cluster, independente da contagem ou tamanho de nós do cluster. O serviço baseado em nuvem é o método preferido para lidar com usuários do Office 365. É altamente recomendável que você hospede apenas temporariamente os usuários do Office 365 no Expressway.
Essa limitação deriva da interação com o serviço de nuvem da Microsoft e não da escala da implantação local do Expressway. Por exemplo, se você tiver um único nó pequeno do Expressway, sua capacidade será limitada a 1.000 usuários do Office 365 e 4.000 Microsoft Exchange usuários. Se você tiver um cluster de 6 nós pequenos, sua capacidade será limitada a 1.000 usuários do Office 365 mais 24.000 Microsoft Exchange usuários.
|
Tamanho do nó do Expressway |
1 ou 2 nós* |
3 nós |
4 nós |
5 nós |
6 nós |
|---|---|---|---|---|---|
|
1. Pequeno |
5K |
10K |
15K |
20K |
25K |
|
2. Médio |
10K |
20K |
30K |
40K |
50K |
|
3. Grande |
15K |
30K |
45K |
60K |
75K |
* Observe que a capacidade do usuário é a mesma para um cluster de um nó e para um cluster de dois nós. Isso ocorre porque o Calendar Service usa o failover para melhorar a continuidade do serviço. Todos os usuários são atribuídos a um nó quando há dois nós no cluster; o outro nó é um backup redundante. Consulte Planejando a capacidade do cluster Expressway para usuários de serviços híbridos para obter uma explicação detalhada.
Atribuição de usuários entre hosts e clusters
Por padrão, o serviço de calendário híbrido atribui e distribui automaticamente os usuários de maneira uniforme em todos os conectores de calendário em um cluster. A atribuição é dinâmica com base na disponibilidade, e o administrador não tem controle sobre a qual nó específico um usuário individual está atribuído.
Nos casos em que uma organização tem mais de um cluster, a distribuição de usuários é baseada em vários fatores, incluindo disponibilidade do cluster, atribuição atual (para reduzir oscilações durante a recuperação de falhas) e uma ordem de classificação com base na maior preferência de cluster. O administrador também tem a capacidade de atribuir um usuário ou grupo de usuários a um grupo de recursos. Os grupos de recursos são específicos do cluster, portanto, permitem que os administradores restrinjam a atribuição de determinados conjuntos de usuários a um cluster específico.
Com essa compreensão básica da atribuição de usuários e levando em conta os pré-requisitos do Expressway Calendar Connector, um administrador pode implantar a capacidade apropriada em grande escala para sua organização. Vejamos um exemplo de organização de 126.000 usuários a serem habilitados para o Serviço de Calendário Híbrido, considerando os seguintes parâmetros:
-
Clusters Expressway de 6 nós usando o modelo OVA grande (limite de 15.000 usuários por nó)
-
Não são necessários grupos de recursos
A fórmula de capacidade para um único cluster, U calN = (N-1) * U cal1 em que N=6 e U cal1 =15.000 (usando o modelo OVA grande) gera no máximo 75.000 usuários. Com um total de 126.000 usuários na implantação do serviço de calendário, vários clusters de host do Calendar Connector são necessários. Os usuários seriam distribuídos igualmente, conforme mostrado na figura a seguir:
O Hybrid Calendar Service adiciona usuários ao cluster A primeiro até que o cluster atinja a capacidade de 75.000 usuários e, em seguida, atribui os usuários restantes ao cluster B. Os usuários são distribuídos aleatoriamente e igualmente em todos os nós do cluster. Este exemplo mostra uma distribuição igual dos nós de host do Calendar Connector (dentro de cada um dos dois clusters) nos data centers RTP e PDX. Cada nó usa o mesmo modelo OVA e segue as diretrizes de alta disponibilidade do Expressway. O Calendar Connector usa a lógica de agrupamento do Expressway em um modelo de redundância 5+1 para permitir cenários de alta disponibilidade.
Com todos os usuários atribuídos a um conector de calendário, vamos agora examinar o que acontece quando há uma falha em um cluster. A figura a seguir mostra uma falha em um único nó. Os usuários que foram atribuídos ao nó com falha, 5A no cluster A, agora fizeram o failover para os nós restantes nesse cluster. A capacidade de um único nó permite até 15.000 usuários e cada nó restante no cluster A adiciona 2.500 usuários que foram originalmente atribuídos ao nó 5A. Não há alteração ou impacto no cluster B ou nos usuários atribuídos ao cluster B.
O cluster A ainda está na capacidade máxima e cada um dos nós operacionais do cluster agora está na capacidade máxima, 15.000 usuários/nó. Portanto, se outro nó no cluster A ficar indisponível, como o nó 4A na figura a seguir, o cluster B agora será responsável por receber a carga adicional do usuário. Os 15.000 usuários do nó 4A agora são transferidos para o cluster B e distribuídos igualmente em todos os nós do cluster B.
Quando os nós 4A e 5A se recuperarem, os usuários no cluster A serão redistribuídos entre os nós do cluster. Os usuários que fizeram o failover para o cluster B permanecem no cluster B durante essa fase de recuperação para evitar atribuições desnecessárias de usuários entre os clusters, conforme mostrado na figura a seguir.
Um item importante a ser observado ao planejar uma implantação em grande escala do Serviço de Calendário Híbrido é entender o impacto de uma falha caso ela ocorra na implantação. Se usarmos a mesma implantação de 126.000 usuários, mas perdermos um data center inteiro, é possível que os usuários não sejam atribuídos a um nó do Calendar Connector. Para evitar uma interrupção do serviço nesse tipo de cenário, o cliente precisaria de um terceiro cluster para redistribuir e lidar com os usuários afetados.
A capacidade de um cluster Expressway de atender usuários de mensagens híbridas depende do tamanho dos nós constituintes do Expressway, do número de nós no cluster e da estratégia de continuidade do serviço.
A tabela a seguir mostra o número máximo de usuários em uma única via expressa usada para a mensagem híbrida.
|
Via expressa pequena |
Via expressa média |
Grande via expressa |
|---|---|---|
|
5.000 usuários |
6.500 usuários |
15.000 usuários |
Os números de usuário são os mesmos para um cluster de um nó e para um cluster de dois nós. Isso ocorre porque o Serviço de Mensagens usa o failover para melhorar a continuidade do serviço. Os usuários são distribuídos uniformemente entre os vários nós do cluster: se um nó falhar, os usuários desse nó serão atribuídos aos outros nós.
Este tópico é sobre o compartilhamento de um conector host Expressway entre os conectores de vários serviços híbridos, incluindo o Serviço de Calendário e o Serviço de Mensagens. O host do conector não é compartilhado com outras soluções baseadas em Expressway, como MRA e B2B.
A capacidade do cluster host de conectores depende do tamanho dos nós constituintes do Expressway, do número de nós, dos conectores que estão em execução no cluster e da estratégia de continuidade do serviço. Consulte Planejando a capacidade do cluster Expressway para usuários de serviços híbridos para obter uma explicação detalhada desses fatores.
Há também uma calculadora para você modelar diferentes clusters de host de conectores e ver quantos usuários de cada serviço seu cluster proposto pode suportar.
Em geral, recomendamos a coresidência somente para implantações menores de até dois nós. Se sua implantação exceder a capacidade de um par de nós, você deverá mover os conectores para clusters do Expressway dedicados a cada serviço híbrido específico.
Exemplo: escala de host de conectores com três conectores coresidentes
A tabela a seguir mostra um exemplo de escala e coresidência. Ele fornece o número máximo de usuários por cluster, para cada serviço, com especificações diferentes do cluster host do conector. O cluster é compartilhado entre o Calendário Híbrido (usando seu Exchange local), a chamada híbrida e o Serviço de Mensagens Híbrido.
|
Serviço |
Dois pequenos nós |
Dois nós médios |
Dois nós grandes |
|---|---|---|---|
|
Usuários do Calendar Service |
1,300 |
2,300 |
3,000 |
|
Usuários do Serviço de Mensagens |
1,300 |
2,300 |
3,000 |
Introdução
Este tópico é sobre o compartilhamento de um conector hospedeiro Expressway com outras soluções baseadas em Expressway. Quando você opta por hospedar conectores em um Expressway que está usando para outros fins, as seguintes advertências importantes se aplicam:
-
Não podemos oferecer suporte ao modelo de escalabilidade que se aplica a um host de conector dedicado Expressway. Os números de usuário obtidos ao ler os outros tópicos deste artigo ou usar a calculadora não se aplicam quando o host do conector é compartilhado com outros serviços do Expressway.
-
As combinações de serviços baseados em Expressway e conectores de serviços híbridos descritas neste artigo, e os números de usuários associados, são os únicos cenários suportados. Não testamos outros cenários e você não pode esperar que eles funcionem em seu ambiente.
Serviço de calendário baseado em Expressway com conector de chamadas e passagem de serviço de chamadas
Nesse cenário, conectores de calendário híbrido do cluster Expressway de dois nós. O cluster também está fazendo a travessia de chamadas para outras soluções de chamadas da Cisco (mídia e sinalização SIP).
A tabela mostra os diferentes ambientes de calendário que você pode usar com o conector baseado em Expressway. O conector de calendário baseado em Expressway não é suportado em clusters com mais de dois nós. Use o conector baseado em nuvem para obter maior escala com o Office 365 (consulte Escala do serviço de calendário).
|
Serviço |
Cluster de dois pequenos nós |
Cluster de dois nós médios |
Cluster de dois nós grandes | |
|---|---|---|---|---|
|
Serviço de calendário |
Exchange local |
500 usuários |
1.000 usuários |
1.000 usuários |
|
Office 365 † |
500 usuários |
1.000 usuários |
1.000 usuários | |
|
Exchange e Office 365 locais (implantações híbridas do Exchange) |
Máximo de 500 usuários para ambos |
Máximo de 1.000 usuários para ambos |
Máximo de 1.000 usuários para ambos | |
|
Traversal de chamadas |
200 sessões de áudio 100 sessões de vídeo |
200 sessões de áudio 100 sessões de vídeo |
1.000 sessões de áudio 500 sessões de vídeo | |
† Para evitar essa limitação de escala, recomendamos que você use o Serviço de Calendário baseado em nuvem em vez do conector local. Para o calendário híbrido baseado em Expressway, a limitação da capacidade de usuário do Office 365 para 1.000 por cluster é independente do tamanho ou da contagem de nós do cluster; essa limitação deriva da interação com o serviço de nuvem da Microsoft e não da escala da implantação local do Expressway.
Calendário com celular e Remote Access
Nesse cenário, um cluster MRA de uma ou duas pequenas VMs do Expressway está hospedando o Calendar Connector. Esse cenário pressupõe que o cluster seja usado somente para o MRA e os dois conectores. O cluster está limitado a um ou dois nós pequenos.
|
Objetivo da via expressa |
Cluster de um pequeno Expressway-C |
Conjunto de dois pequenos Expressway-Cs |
|---|---|---|
|
Usuários do Serviço de Calendário (conector local para o Exchange) |
500 usuários |
500 usuários |
|
Celular e Remote Access usuários |
100 |
100 |
