Design de hierarquia do CMG

Aplica-se a: Configuration Manager (branch atual)

Se você tem um site de administração central (CAS), um site principal autônomo ou um pequeno laboratório de teste, projete o cmg (gateway de gerenciamento de nuvem) para esse ambiente. Este artigo fornece as informações para ajudá-lo a decidir como posicionar o CMG em seu ambiente.

Crie o CMG no site de camada superior da hierarquia. Se for um CAS, crie pontos de conexão CMG em sites primários filho. O componente do gerenciador de serviços na nuvem está no ponto de conexão de serviço, que também está no CAS. Esse design pode compartilhar o serviço em diferentes sites principais, se necessário.

Você pode criar vários serviços CMG no Azure e criar vários pontos de conexão CMG. Vários pontos de conexão CMG fornecem balanceamento de carga do tráfego do cliente do CMG para as funções locais.

Outros fatores, como o número de clientes a gerenciar, também afetam o design do CMG. Para obter mais informações, consulte Performance and scale.

Exemplos de design

Exemplo 1: site principal autônomo

A Contoso tem um site principal autônomo em um datacenter local em sua sede na cidade de Nova York.

  • Eles criam um CMG na região do Azure dos EUA Leste para reduzir a latência da rede.
  • Eles criam dois pontos de conexão CMG, ambos vinculados ao serviço CMG único.

À medida que os clientes circulam pela Internet, eles se comunicam com o CMG na região do Azure dos EUA Leste. O CMG encaminha essa comunicação por meio de ambos os pontos de conexão CMG.

Exemplo 2: Hierarquia

Fourth Coffee tem um CAS em um datacenter local em sua sede em Seattle. Um site principal está no mesmo datacenter, e o outro site principal está em seu principal escritório europeu em Paris.

  • No CAS, eles criam um serviço CMG na região do Azure do Oeste dos EUA. Eles dimensionam o número de VMs para a carga esperada de clientes roaming em toda a hierarquia.
  • No site principal baseado em Seattle, eles criam um ponto de conexão CMG vinculado ao CMG único.
  • No site primário baseado em Paris, eles criam um ponto de conexão CMG vinculado ao cmg único.

À medida que os clientes circulam pela Internet, eles se comunicam com o CMG na região do Azure dos EUA Ocidental. O CMG encaminha essa comunicação para o ponto de conexão CMG no site principal atribuído do cliente.

Dica

Você não precisa implantar mais de um CMG para fins de localização geográfica. O cliente do Configuration Manager não é afetado principalmente pela leve latência que pode ocorrer com o serviço de nuvem, mesmo quando geograficamente distante.

Ambientes de teste

Muitas organizações têm ambientes separados para produção, teste, desenvolvimento ou garantia de qualidade. Ao planejar a implantação do CMG, considere as seguintes perguntas:

  • Quantos locatários do Azure AD sua organização tem?

    • Há um locatário separado para teste?
    • As identidades de usuários e dispositivos estão no mesmo locatário?
  • Quantas assinaturas há em cada locatário?

    • Há assinaturas específicas para teste?

O serviço do Azure do Configuration Manager para gerenciamento de nuvem dá suporte a vários locatários. Vários sites do Configuration Manager podem se conectar ao mesmo locatário. Um único site pode implantar vários serviços CMG em assinaturas diferentes. Vários sites podem implantar serviços CMG na mesma assinatura. O Configuration Manager oferece flexibilidade dependendo do ambiente e dos requisitos de negócios.

Para obter mais informações, consulte as seguintes perguntas frequentes: As contas de usuário devem estar no mesmo locatário do Azure AD que o locatário associado à assinatura que hospeda o serviço de nuvem CMG?

Grupos de limite

Você pode associar um CMG a um grupo de limites. Essa configuração permite que os clientes padrão ou recaam para o CMG para comunicação do cliente de acordo com as relações de grupo de limite. Esse comportamento é especialmente útil em cenários de filial e VPN. Você pode direcionar o tráfego do cliente para longe de links WAN caros e lentos para, em vez disso, usar serviços mais rápidos Microsoft Azure.

A partir da versão 2006, os clientes intranet podem acessar um ponto de atualização de software habilitado para CMG quando são atribuídos a um grupo de limites. Para obter mais informações, consulte Configure bordery groups.

Os clientes baseados na Internet não dependem de grupos de limite. Eles só usam fontes de conteúdo voltados para a Internet ou na nuvem. Se você estiver usando apenas CMGs habilitados para conteúdo para esses tipos de clientes, não precisará incluí-los em grupos de limite.

Se você quiser que os clientes em sua rede interna recebam conteúdo de um CMG, ele precisa estar no mesmo grupo de limite que os clientes. Por padrão, os clientes priorizam as fontes baseadas em nuvem pela última vez em sua lista de fontes de conteúdo. Esse comportamento é porque há um custo associado ao download de conteúdo do Azure. As fontes baseadas em nuvem geralmente são usadas como uma fonte de fallback para clientes baseados em intranet. Se você quiser um design na nuvem primeiro, projete seus grupos de limite para atender a esse requisito comercial. Para obter mais informações, consulte Configure bordery groups. Para obter mais informações sobre a prioridade de local de conteúdo e quando os clientes baseados em intranet usam uma fonte de conteúdo baseada em nuvem, consulte Content source priority.

Mesmo que você instale o CMG em uma região específica do Azure, os clientes não estão cientes das regiões do Azure. Eles selecionam aleatoriamente um CMG disponível como fonte de conteúdo. Se você tiver CMGs em várias regiões e um cliente receber mais de um na lista de locais de conteúdo, ele pode não baixar o conteúdo da mesma região do Azure.

Próximas etapas

Em seguida, revise os recursos e configurações compatíveis com o CMG: