Partilhar via

Perguntas Frequentes (FAQ) do Traffic Manager

  • Artigo

Noções básicas do Traffic Manager

Que endereço IP utiliza o Gestor de Tráfego?

Conforme explicado em Como funciona o Gerenciador de Tráfego, o Gerenciador de Tráfego funciona no nível do Sistema de Nomes de Domínio (DNS). Ele envia respostas DNS para direcionar clientes para o ponto de extremidade de serviço apropriado. Em seguida, os clientes ligam-se diretamente ao ponto final de serviço e não através do Gestor de Tráfego.

Portanto, o Gerenciador de Tráfego não fornece um ponto de extremidade ou endereço IP para os clientes se conectarem. Se você quiser um endereço IP estático para seu serviço, ele deve ser configurado no serviço, não no Gerenciador de Tráfego.

Que tipos de tráfego podem ser encaminhados usando o Gerenciador de Tráfego?

Conforme explicado em Como funciona o Gerenciador de Tráfego, um ponto de extremidade do Gerenciador de Tráfego pode ser qualquer serviço voltado para a Internet hospedado dentro ou fora do Azure. Assim, o Traffic Manager pode encaminhar o tráfego originado da Internet pública para um conjunto de pontos finais que também estão voltados para a Internet. Se você tiver pontos de extremidade dentro de uma rede privada (por exemplo, uma versão interna do Balanceador de Carga do Azure) ou tiver usuários fazendo solicitações DNS dessas redes internas, não poderá usar o Gerenciador de Tráfego para rotear esse tráfego.

O Traffic Manager suporta sessões "adesivas"?

Conforme explicado em Como funciona o Gerenciador de Tráfego, o Gerenciador de Tráfego funciona no nível DNS. Utiliza respostas DNS para direcionar os clientes para o ponto final de serviço apropriado. Os clientes se conectam ao ponto de extremidade do serviço diretamente, não por meio do Gerenciador de Tráfego. Portanto, o Gerenciador de Tráfego não vê o tráfego HTTP entre o cliente e o servidor.

Além disso, o endereço IP de origem da consulta DNS recebida pelo Traffic Manager pertence ao serviço DNS recursivo, não ao cliente. Portanto, o Traffic Manager não tem como rastrear clientes individuais e não pode implementar sessões 'pegajosas'. Esta limitação é comum a todos os sistemas de gestão de tráfego baseados em DNS e não é específica do Gestor de Tráfego.

Por que estou vendo um erro HTTP ao usar o Gerenciador de Tráfego?

Conforme explicado em Como funciona o Gerenciador de Tráfego, o Gerenciador de Tráfego funciona no nível DNS. Utiliza respostas DNS para direcionar os clientes para o ponto final de serviço apropriado. Em seguida, os clientes ligam-se diretamente ao ponto final de serviço e não através do Gestor de Tráfego. O Gestor de Tráfego não vê tráfego HTTP entre cliente e servidor. Portanto, qualquer erro HTTP apresentado deverá ser proveniente da aplicação. Para que o cliente se conecte ao aplicativo, todas as etapas de resolução de DNS são concluídas. Isso inclui qualquer interação que o Gerenciador de Tráfego tenha no fluxo de tráfego do aplicativo.

Por conseguinte, uma investigação mais aprofundada deve centrar-se no pedido.

O cabeçalho de host HTTP enviado do navegador do cliente é a fonte mais comum de problemas. Verifique se o aplicativo está configurado para aceitar o cabeçalho de host correto para o nome de domínio que você está usando. Para pontos de extremidade usando o Serviço de Aplicativo do Azure, consulte configurando um nome de domínio personalizado para um aplicativo Web no Serviço de Aplicativo do Azure usando o Gerenciador de Tráfego.

Como posso resolver um problema 500 (Erro Interno do Servidor) ao usar o Gerenciador de Tráfego?

Se o seu cliente ou aplicativo receber um erro HTTP 500 ao usar o Gerenciador de Tráfego, isso pode ser causado por uma consulta DNS obsoleta. Para resolver o problema, limpe o cache DNS e permita que o cliente emita uma nova consulta DNS.

Quando um ponto de extremidade de serviço não responde, os clientes e aplicativos que estão usando esse ponto de extremidade não são redefinidos até que o cache DNS seja atualizado. A duração do cache é determinada pelo tempo de vida (TTL) do registro DNS. Para obter mais informações, consulte Gerenciador de tráfego e o cache DNS.

Consulte também as seguintes perguntas frequentes relacionadas neste artigo:

Qual é o impacto no desempenho da utilização do Gestor de Tráfego?

Conforme explicado em Como funciona o Gerenciador de Tráfego, o Gerenciador de Tráfego funciona no nível DNS. Como os clientes se conectam diretamente aos seus pontos de extremidade de serviço, não há impacto no desempenho ao usar o Gerenciador de Tráfego depois que a conexão é estabelecida.

Como o Gerenciador de Tráfego se integra a aplicativos no nível DNS, ele requer uma pesquisa de DNS adicional para ser inserida na cadeia de resolução DNS. O impacto do Traffic Manager no tempo de resolução do DNS é mínimo. O Gestor de Tráfego utiliza uma rede global de servidores de nomes e utiliza redes anycast para garantir que as consultas DNS são sempre encaminhadas para o servidor de nomes disponível mais próximo. Além disso, o cache de respostas DNS significa que a latência DNS adicional incorrida ao usar o Gerenciador de Tráfego se aplica apenas a uma fração de sessões.

O método Performance roteia o tráfego para o ponto de extremidade disponível mais próximo. O resultado líquido é que o impacto global no desempenho associado a este método deve ser mínimo. Qualquer aumento na latência do DNS deve ser compensado pela menor latência da rede até o ponto de extremidade.

Que protocolos de aplicação posso utilizar com o Gestor de Tráfego?

Conforme explicado em Como funciona o Gerenciador de Tráfego, o Gerenciador de Tráfego funciona no nível DNS. Quando a pesquisa de DNS estiver concluída, os clientes se conectam ao ponto de extremidade do aplicativo diretamente, não por meio do Gerenciador de Tráfego. Portanto, a conexão pode usar qualquer protocolo de aplicativo. Se você selecionar TCP como o protocolo de monitoramento, o monitoramento da integridade do ponto final do Gerenciador de Tráfego poderá ser feito sem usar nenhum protocolo de aplicativo. Se você optar por ter a integridade verificada usando um protocolo de aplicativo, o ponto de extremidade precisará ser capaz de responder a solicitações HTTP ou HTTPS GET.

Posso usar o Traffic Manager com um nome de domínio "nu"?

Sim. Para saber como criar um registro de alias para o apex do nome de domínio para fazer referência a um perfil do Gerenciador de Tráfego do Azure, consulte Configurar um registro de alias para dar suporte a nomes de domínio do apex com o Gerenciador de Tráfego.

O Gerenciador de Tráfego considera o endereço de sub-rede do cliente ao lidar com consultas DNS?

Sim. Além do endereço IP de origem da consulta DNS (geralmente o endereço IP do resolvedor DNS), o Gerenciador de Tráfego também considera o endereço de sub-rede do cliente se ele estiver incluído na consulta DNS enviada pelo resolvedor de DNS que faz a solicitação em nome do usuário final. Esses endereços IP são usados para otimizar métodos geográficos, de desempenho e de roteamento de sub-rede. Especificamente, RFC 7871 – Client Subnet in DNS Queries fornece um mecanismo de extensão para DNS (EDNS0) pode passar o endereço de sub-rede do cliente de resolvedores que o suportam.

O que é o DNS TTL e como ele afeta meus usuários?

Quando uma consulta DNS chega ao Gerenciador de Tráfego, ela define um valor na resposta chamado time-to-live (TTL). Esse valor, cuja unidade é em segundos, indica aos resolvedores de DNS a jusante por quanto tempo essa resposta deve ser armazenada em cache. Embora não seja garantido que os resolvedores de DNS armazenem esse resultado em cache, o cache permite que eles respondam a quaisquer consultas subsequentes fora do cache em vez de ir para os servidores DNS do Gerenciador de Tráfego. Isso afeta as respostas da seguinte forma:

  • um TTL mais alto reduz o número de consultas que chegam aos servidores DNS do Gerenciador de Tráfego, o que pode reduzir o custo para um cliente, já que o número de consultas atendidas é um uso faturável.
  • um TTL mais alto pode potencialmente reduzir o tempo necessário para fazer uma pesquisa de DNS.
  • um TTL mais alto também significa que seus dados não refletem as informações de integridade mais recentes que o Gerenciador de Tráfego obteve por meio de seus agentes de sondagem.

Quão alto ou baixo posso definir o TTL para respostas do Traffic Manager?

Você pode definir, em um nível por perfil, o TTL DNS para ser tão baixo quanto 0 segundos e tão alto quanto 2.147.483.647 segundos (o intervalo máximo compatível com RFC-1035). Um TTL de 0 significa que os resolvedores de DNS downstream não armazenam em cache as respostas de consulta e espera-se que todas as consultas cheguem aos servidores DNS do Gerenciador de Tráfego para resolução.

Como posso entender o volume de consultas que chegam ao meu perfil?

Uma das métricas fornecidas pelo Traffic Manager é o número de consultas respondidas por um perfil. Você pode obter essas informações em uma agregação de nível de perfil ou dividi-las ainda mais para ver o volume de consultas onde pontos de extremidade específicos foram retornados. Além disso, você pode configurar alertas para notificá-lo se o volume de resposta da consulta cruzar as condições definidas. Para obter mais detalhes, métricas e alertas do Gerenciador de Tráfego.

Quando excluo um perfil do Gerenciador de Tráfego, qual é o tempo antes que o nome do perfil esteja disponível para reutilização?

Quando você exclui um perfil do Gerenciador de Tráfego, o nome de domínio associado é reservado por um período de tempo. Outros perfis do Traffic Manager no mesmo locatário podem reutilizar imediatamente o nome. No entanto, um locatário diferente do Azure não pode usar o mesmo nome de perfil até que a reserva expire. Esse recurso permite que você mantenha a autoridade sobre os namespaces que você implanta, eliminando preocupações de que o nome possa ser tomado por outro locatário.

Por exemplo, se o nome do perfil do Gerenciador de Tráfego for label1, label1.trafficmanager.net será reservado para seu locatário, mesmo que você exclua o perfil. Namespaces filho, como xyz.label1 ou 123.abc.label1 também são reservados. Quando a reserva expira, o nome é disponibilizado para outros inquilinos. O nome associado a um perfil desativado é reservado indefinidamente. Para perguntas sobre o período de tempo em que um nome é reservado, entre em contato com o representante da sua conta.

Qual versão do TLS é exigida pelo Gerenciador de Tráfego?

A implementação da Microsoft de versões mais antigas do TLS não é considerada vulnerável, no entanto, o TLS 1.2 e posteriores oferecem uma segurança aprimorada com recursos como sigilo de encaminhamento perfeito e pacotes de codificação mais fortes. Para melhorar a segurança e fornecer a melhor criptografia da categoria para seus dados, o Gerenciador de Tráfego exige que as interações com serviços sejam protegidas usando o Transport Layer Security (TLS) 1.2 ou posterior antes de 28 de fevereiro de 2025. O suporte do Traffic Manger para TLS 1.0 e 1.1 terminará nesta data. Essa data pode ser diferente da data de desativação do TLS 1.0 e TLS 1.1 em todo o Azure.

Ação recomendada

Para evitar interrupções de serviço, os recursos que interagem com o Gerenciador de Tráfego devem usar o TLS 1.2 ou posterior.

  • Se os recursos já estiverem usando exclusivamente o TLS 1.2 ou posterior, você não precisará tomar outras medidas.
  • Se os recursos ainda dependerem do TLS 1.0 ou 1.1, faça a transição para o TLS 1.2 ou posterior até 28 de fevereiro de 2025.

Para obter informações sobre como migrar do TLS 1.0 e 1.1 para o TLS 1.2, consulte Resolvendo o problema do TLS 1.0.

Método de roteamento de tráfego geográfico do Gerenciador de Tráfego

Quais são alguns casos de uso em que o roteamento geográfico é útil?

O tipo de roteamento geográfico pode ser usado em qualquer cenário em que um cliente do Azure precise distinguir seus usuários com base em regiões geográficas. Por exemplo, usando o método de roteamento de tráfego geográfico, você pode oferecer aos usuários de regiões específicas uma experiência de usuário diferente daqueles de outras regiões. Outro exemplo é o cumprimento de mandatos locais de soberania de dados que exigem que os usuários de uma região específica sejam atendidos apenas por pontos finais nessa região.

Como posso decidir se devo usar o método de roteamento de desempenho ou o método de roteamento geográfico?

A principal diferença entre esses dois métodos de roteamento populares é que, no método de roteamento de desempenho, seu objetivo principal é enviar tráfego para o ponto de extremidade que pode fornecer a menor latência para o chamador, enquanto que, no roteamento geográfico, o objetivo principal é impor uma cerca geográfica para seus chamadores para que você possa encaminhá-los deliberadamente para um ponto de extremidade específico. A sobreposição acontece porque há uma correlação entre proximidade geográfica e menor latência, embora isso nem sempre seja verdade. Pode haver um ponto de extremidade em uma geografia diferente que possa fornecer uma melhor experiência de latência para o chamador e, nesse caso, o roteamento de desempenho envia o usuário para esse ponto de extremidade, mas o roteamento geográfico sempre os envia para o ponto de extremidade que você mapeou para sua região geográfica. Para deixar ainda mais claro, considere o seguinte exemplo - com o roteamento geográfico, você pode fazer mapeamentos incomuns, como enviar todo o tráfego da Ásia para pontos de extremidade nos EUA e todo o tráfego dos EUA para pontos de extremidade na Ásia. Nesse caso, o roteamento geográfico deliberadamente faz exatamente o que você configurou para fazer e a otimização de desempenho não é uma consideração.

Nota

Pode haver cenários em que você pode precisar de recursos de desempenho e roteamento geográfico, pois esses cenários os perfis aninhados podem ser uma ótima escolha. Por exemplo, você pode configurar um perfil pai com roteamento geográfico para enviar todo o tráfego da América do Norte para um perfil aninhado que tenha pontos de extremidade nos EUA e usar o roteamento de desempenho para enviar esse tráfego para o melhor ponto de extremidade dentro desse conjunto.

Quais são as regiões suportadas pelo Traffic Manager para roteamento geográfico?

A hierarquia de país/região usada pelo Gerenciador de Tráfego pode ser encontrada aqui. Embora esta página seja mantida atualizada com quaisquer alterações, você também pode recuperar programaticamente as mesmas informações usando a API REST do Gerenciador de Tráfego do Azure.

Como o gerenciador de tráfego determina de onde um usuário está consultando?

O Gestor de Tráfego analisa o IP de origem da consulta (provavelmente é um resolvedor de DNS local que faz a consulta em nome do utilizador) e utiliza um IP interno para um mapa de região para determinar a localização. Este mapa é atualizado continuamente para dar conta das mudanças na internet.

É garantido que o Traffic Manager pode determinar corretamente a localização geográfica exata do usuário em todos os casos?

Não, o Gestor de Tráfego não pode garantir que a região geográfica que inferimos do endereço IP de origem de uma consulta DNS corresponda sempre à localização do utilizador devido às seguintes razões:

  • Primeiro, conforme descrito nas perguntas frequentes anteriores, o IP de origem que vemos é o de um resolvedor de DNS fazendo a pesquisa em nome do usuário. Embora a localização geográfica do resolvedor de DNS seja um bom proxy para a localização geográfica do usuário, ela também pode ser diferente, dependendo da pegada do serviço de resolução de DNS e do serviço de resolução de DNS específico que um cliente escolheu usar. Como exemplo, um cliente localizado na Malásia pode especificar nas configurações de seu dispositivo usar um serviço de resolvedor de DNS cujo servidor DNS em Cingapura pode ser escolhido para lidar com as resoluções de consulta para esse usuário/dispositivo. Nesse caso, o Traffic Manager só pode ver o IP do resolvedor que corresponde à localização de Singapura. Além disso, consulte as perguntas frequentes anteriores sobre o suporte ao endereço de sub-rede do cliente nesta página.

  • Em segundo lugar, o Gerenciador de Tráfego usa um mapa interno para fazer a conversão do endereço IP para a região geográfica. Embora este mapa seja validado e atualizado continuamente para aumentar sua precisão e levar em conta a natureza evolutiva da internet, ainda há a possibilidade de que nossas informações não sejam uma representação exata da localização geográfica de todos os endereços IP.

Um ponto de extremidade precisa estar fisicamente localizado na mesma região com a qual está configurado para roteamento geográfico?

Não, a localização do ponto de extremidade não impõe restrições sobre quais regiões podem ser mapeadas para ele. Por exemplo, um ponto de extremidade na região do Azure Central dos EUA pode ter todos os usuários da Índia direcionados a ele.

Posso atribuir regiões geográficas a pontos de extremidade em um perfil que não está configurado para fazer roteamento geográfico?

Sim, se o método de roteamento de um perfil não for geográfico, você poderá usar a API REST do Gerenciador de Tráfego do Azure para atribuir regiões geográficas a pontos de extremidade nesse perfil. Para perfis de tipo de roteamento não geográfico, essa configuração é ignorada. Se você alterar esse perfil para o tipo de roteamento geográfico posteriormente, o Gerenciador de Tráfego poderá usar esses mapeamentos.

Por que estou recebendo um erro quando tento alterar o método de roteamento de um perfil existente para Geográfico?

Todos os pontos de extremidade sob um perfil com roteamento geográfico precisam ter pelo menos uma região mapeada para ele. Para converter um perfil existente em tipo de roteamento geográfico, primeiro você precisa associar regiões geográficas a todos os seus pontos de extremidade usando a API REST do Azure Traffic Manager antes de alterar o tipo de roteamento para geográfico. Se estiver usando o portal, primeiro exclua os pontos de extremidade, altere o método de roteamento do perfil para geográfico e, em seguida, adicione os pontos de extremidade junto com o mapeamento de região geográfica.

Uma região pode ser atribuída a apenas um ponto de extremidade dentro de um perfil se estiver usando o método de roteamento geográfico. Se esse ponto de extremidade não for um tipo aninhado com um perfil filho anexado a ele, se esse ponto de extremidade não estiver íntegro, o Gerenciador de Tráfego continuará a enviar tráfego para ele, pois a alternativa de não enviar tráfego não é melhor. O Gerenciador de Tráfego não faz failover para outro ponto de extremidade, mesmo quando a região atribuída é um "pai" da região atribuída ao ponto de extremidade que não foi íntegro (por exemplo, se um ponto de extremidade que tem a região Espanha não estiver íntegro, não fazemos failover para outro ponto de extremidade que tenha a região Europa atribuída a ele). Isso é feito para garantir que o Gerenciador de Tráfego respeite os limites geográficos que um cliente configurou em seu perfil. Para obter o benefício de fazer failover para outro ponto de extremidade quando um ponto de extremidade não estiver íntegro, é recomendável que as regiões geográficas sejam atribuídas a perfis aninhados com vários pontos de extremidade dentro dele, em vez de pontos de extremidade individuais. Dessa forma, se um ponto de extremidade no perfil filho aninhado falhar, o tráfego poderá fazer failover para outro ponto de extremidade dentro do mesmo perfil filho aninhado.

Há alguma restrição na versão da API que suporta esse tipo de roteamento?

Sim, apenas a versão da API 2017-03-01 e mais recente suporta o tipo de roteamento geográfico. As versões mais antigas da API não podem ser usadas para criar perfis do tipo de roteamento geográfico ou atribuir regiões geográficas a pontos de extremidade. Se uma versão mais antiga da API for usada para recuperar perfis de uma assinatura do Azure, nenhum perfil do tipo de roteamento geográfico será retornado. Além disso, ao usar versões de API mais antigas, qualquer perfil retornado que tenha pontos de extremidade com uma atribuição de região geográfica não tem sua atribuição de região geográfica mostrada.

Método de roteamento de tráfego de sub-rede do Gerenciador de Tráfego

Quais são alguns casos de uso em que o roteamento de sub-rede é útil?

O roteamento de sub-rede permite diferenciar a experiência que você oferece para conjuntos específicos de usuários identificados pelo IP de origem de suas solicitações DNS, endereço IP. Um exemplo seria mostrar conteúdo diferente se os usuários estiverem se conectando a um site da sede da sua empresa. Outra seria restringir os utilizadores de determinados ISPs a apenas acederem a pontos finais que suportem apenas ligações IPv4 se esses ISPs tiverem um desempenho inferior quando o IPv6 é utilizado.

Outra razão para usar o método de roteamento de sub-rede é em conjunto com outros perfis em um conjunto de perfis aninhados. Por exemplo, se você quiser usar o método de roteamento geográfico para delimitação geográfica de seus usuários, mas para um ISP específico quiser fazer um método de roteamento diferente, poderá ter um perfil com o método de roteamento de sub-rede como o perfil pai e substituir esse ISP para usar um perfil filho específico e ter o perfil geográfico padrão para todos os outros.

Nota

O Azure Traffic Manager suporta endereços IPv6 em substituições de sub-rede para perfis de sub-rede. Esse recurso permite um controle mais granular sobre o roteamento de tráfego com base no endereço IP de origem das consultas DNS, incluindo endereços IPv4 e IPv6.

Como é que o Traffic Manager sabe o endereço IP do utilizador final?

Os dispositivos de usuário final normalmente usam um resolvedor de DNS para fazer a pesquisa de DNS em seu nome. O IP de saída desses resolvedores é o que o Traffic Manager vê como o IP de origem. Além disso, o método de roteamento de sub-rede também procura ver se há informações de EDNS0 Extended Client Subnet (ECS) que foram passadas com a solicitação. Se houver informações do ECS, esse é o endereço usado para determinar o roteamento. Na ausência de informações ECS, o IP de origem da consulta é usado para fins de roteamento.

Como posso especificar endereços IP ao usar o roteamento de sub-rede?

Os endereços IP a serem associados a um ponto de extremidade podem ser especificados de duas maneiras. Primeiro, você pode usar a notação de octeto decimal pontilhado quádruplo com endereços iniciais e finais para especificar o intervalo (por exemplo, 1.2.3.4-5.6.7.8 ou 3.4.5.6-3.4.5.6). Em segundo lugar, você pode usar a notação CIDR para especificar o intervalo (por exemplo, 1.2.3.0/24). Você pode especificar vários intervalos e pode usar ambos os tipos de notação em um conjunto de intervalos. Aplicam-se algumas restrições.

  • Não é possível sobrepor intervalos de endereços, pois cada endereço IP precisa ser mapeado para apenas um único ponto de extremidade
  • O endereço inicial não pode ser mais do que o endereço final
  • Para a notação CIDR, o endereço IP antes do '/' deve ser o endereço de rede desse intervalo (por exemplo, 1.2.3.0/24 é válido, mas 1.2.3.4.4/24 NÃO é válido)

Como posso especificar um ponto de extremidade de fallback ao usar o roteamento de sub-rede?

Em um perfil com roteamento de sub-rede, se você tiver um ponto de extremidade sem sub-redes mapeadas para ele, qualquer solicitação que não corresponda a outros pontos de extremidade será direcionada para aqui. É altamente recomendável que você tenha esse ponto de extremidade de fallback em seu perfil, pois o Gerenciador de Tráfego retorna uma resposta NXDOMAIN se uma solicitação chegar e ela não for mapeada para nenhum ponto de extremidade ou se estiver mapeada para um ponto de extremidade, mas esse ponto de extremidade não estiver íntegro.

O que acontece se um ponto de extremidade estiver desabilitado em um perfil de tipo de roteamento de sub-rede?

Em um perfil com roteamento de sub-rede, se você tiver um ponto de extremidade desabilitado, o Gerenciador de Tráfego se comportará como se esse ponto de extremidade e os mapeamentos de sub-rede que ele tem não existissem. Se uma consulta que teria correspondido ao seu mapeamento de endereço IP for recebida e o ponto de extremidade estiver desativado, o Gerenciador de Tráfego retornará um ponto de extremidade de fallback (um sem mapeamentos) ou, se esse ponto de extremidade não estiver presente, retornará uma resposta NXDOMAIN.

Método de roteamento de tráfego MultiValue do Traffic Manager

Quais são alguns casos de uso em que o roteamento MultiValue é útil?

O roteamento de vários valores retorna vários pontos de extremidade íntegros em uma única resposta de consulta. A principal vantagem disso é que, se um ponto de extremidade não estiver íntegro, o cliente terá mais opções para tentar novamente sem fazer outra chamada DNS (que pode retornar o mesmo valor de um cache upstream). Isso é aplicável a aplicativos sensíveis à disponibilidade que desejam minimizar o tempo de inatividade. Outro uso para o método de roteamento MultiValue é se um ponto de extremidade é "dual-homed" para endereços IPv4 e IPv6 e você deseja dar ao chamador ambas as opções para escolher quando ele inicia uma conexão com o ponto de extremidade.

Quantos pontos de extremidade são retornados quando o roteamento MultiValue é usado?

Você pode especificar o número máximo de pontos de extremidade a serem retornados e MultiValue não retorna mais do que muitos pontos de extremidade íntegros quando uma consulta é recebida. O valor máximo possível para esta configuração é 10.

Obterei o mesmo conjunto de pontos de extremidade quando o roteamento MultiValue for usado?

Não podemos garantir que o mesmo conjunto de pontos de extremidade seja retornado em cada consulta. Isso também é afetado pelo fato de que alguns dos endpoints podem não ser íntegros, momento em que não serão incluídos na resposta

Medidas Reais de Utilizadores

Quais são os benefícios de usar as Medições do Usuário Real?

Quando você usa o método de roteamento de desempenho, o Gerenciador de Tráfego escolhe a melhor região do Azure para seu usuário final se conectar, inspecionando o IP de origem e a Sub-rede do Cliente EDNS (se transmitidos) e verificando-a em relação à inteligência de latência de rede mantida pelo serviço. As Medições de Usuários Reais aprimoram isso para sua base de usuários finais, fazendo com que a experiência deles contribua para essa tabela de latência, além de garantir que essa tabela abranja adequadamente as redes de usuários finais de onde seus usuários finais se conectam ao Azure. Isso leva a uma maior precisão no roteamento do seu usuário final.

Posso usar Medições de Usuário Real com regiões que não são do Azure?

As Medições de Usuário Real medem e relatam apenas a latência para alcançar as regiões do Azure. Se você estiver usando o roteamento baseado em desempenho com pontos de extremidade hospedados em regiões que não sejam do Azure, ainda poderá se beneficiar desse recurso ao aumentar as informações de latência sobre a região representativa do Azure que você selecionou para ser associada a esse ponto de extremidade.

Qual método de roteamento se beneficia das Medições de Usuário Real?

As informações adicionais obtidas por meio de Medições de Usuário Real são aplicáveis apenas para perfis que usam o método de roteamento de desempenho. O link Medições do Usuário Real está disponível em todos os perfis quando você o visualiza por meio do portal do Azure.

Preciso ativar as Medições de Usuário Real em cada perfil separadamente?

Não, você só precisa ativá-lo uma vez por assinatura e todas as informações de latência medidas e relatadas estão disponíveis para todos os perfis.

Como faço para desativar as Medições de Usuário Real para minha assinatura?

Você pode parar de acumular encargos relacionados a Medições de Usuário Real quando parar de coletar e enviar de volta medições de latência do seu aplicativo cliente. Por exemplo, ao medir JavaScript incorporado em páginas da Web, você pode parar de usar esse recurso removendo o JavaScript ou desativando sua invocação quando a página é renderizada.

Você também pode desativar as Medições do Usuário Real excluindo sua chave. Depois de excluir a chave, todas as medidas enviadas ao Gerenciador de Tráfego com essa chave são descartadas.

Posso usar Medições de Usuário Real com aplicativos cliente que não sejam páginas da Web?

Sim, o Real User Measurements foi concebido para ingerir dados recolhidos através de diferentes tipos de clientes de utilizadores finais. Este FAQ é atualizado à medida que novos tipos de aplicativos cliente são suportados.

Quantas medições são feitas cada vez que minha página da Web habilitada para Medições de Usuário Real é renderizada?

Quando o Real User Measurements é usado com o JavaScript de medição fornecido, cada renderização de página resulta em seis medições sendo feitas. Em seguida, eles são relatados de volta ao serviço Gerenciador de Tráfego. Você será cobrado por esse recurso com base no número de medições relatadas ao serviço Gerenciador de Tráfego. Por exemplo, se o utilizador navegar para fora da sua página Web enquanto as medições estão a ser feitas, mas antes de serem comunicadas, essas medições não são consideradas para efeitos de faturação.

Existe um atraso antes que o script Real User Measurements seja executado na minha página da Web?

Não, não há nenhum atraso programado antes que o script seja invocado.

Posso usar Medições de Usuário Real apenas com as regiões do Azure que quero medir?

Não, cada vez que é invocado, o script Medições do Usuário Real mede um conjunto de seis regiões do Azure conforme determinado pelo serviço. Esse conjunto muda entre diferentes invocações e, quando um grande número dessas invocações acontece, a cobertura de medição se estende por diferentes regiões do Azure.

Posso limitar o número de medições efetuadas a um número específico?

O JavaScript de medição está incorporado na sua página Web e tem controlo total sobre quando iniciar e parar de o utilizar. Desde que o serviço Gerenciador de Tráfego receba uma solicitação para uma lista de regiões do Azure a serem medidas, um conjunto de regiões será retornado.

Posso ver as medições feitas pelo meu aplicativo cliente como parte das Medições do Usuário Real?

Como a lógica de medição é executada a partir do seu aplicativo cliente, você tem controle total do que acontece, incluindo ver as medições de latência. O Gestor de Tráfego não apresenta uma vista agregada das medições recebidas sob a chave associada à sua subscrição.

Posso modificar o script de medição fornecido pelo Traffic Manager?

Embora você esteja no controle do que está incorporado em sua página da Web, desencorajamos fortemente que você faça quaisquer alterações no script de medição para garantir que ele meça e relate as latências corretamente.

Será possível que outras pessoas vejam a chave que eu uso com as Medições do Usuário Real?

Quando você incorpora o script de medição em uma página da Web, é possível que outras pessoas vejam o script e sua chave RUM (Real User Measurements). Mas é importante saber que essa chave é diferente do seu ID de assinatura e é gerada pelo Gerenciador de Tráfego para ser usada apenas para essa finalidade. Conhecer sua chave RUM não comprometerá a segurança da sua conta do Azure.

Os outros podem abusar da minha chave RUM?

Embora seja possível que outras pessoas usem sua chave para enviar informações erradas para o Azure, algumas medições erradas não alterarão o roteamento, pois ele é levado em conta junto com todas as outras medições que recebemos. Se você precisar alterar suas chaves, você pode regenerar a chave no momento em que a chave antiga é descartada.

Preciso de colocar o JavaScript de medição em todas as minhas páginas web?

As Medições do Usuário Real oferecem mais valor à medida que o número de medições aumenta. Dito isto, é sua decisão se você precisa colocá-lo em todas as suas páginas da web ou em algumas selecionadas. Nossa recomendação é começar colocando-o em sua página mais visitada, onde se espera que um usuário permaneça nessa página cinco segundos ou mais.

As informações sobre os meus utilizadores finais podem ser identificadas pelo Gestor de Tráfego se eu utilizar as Medições de Utilizadores Reais?

Quando o JavaScript de medição fornecido é usado, o Gerenciador de Tráfego tem visibilidade do endereço IP do cliente do usuário final e do endereço IP de origem do resolvedor DNS local que ele usa. O Traffic Manager usa o endereço IP do cliente somente depois de tê-lo truncado para não ser capaz de identificar o usuário final específico que enviou as medições.

A página da Web que mede as Medições de Usuários Reais precisa estar usando o Gerenciador de Tráfego para roteamento?

Não, não é necessário utilizar o Gestor de Tráfego. O lado de roteamento do Gerenciador de Tráfego opera separadamente da parte de Medição de Usuário Real e, embora seja uma ótima ideia tê-los ambos na mesma propriedade da Web, eles não precisam estar.

Preciso hospedar algum serviço em regiões do Azure para usar com as Medições de Usuário Real?

Não, você não precisa hospedar nenhum componente do lado do servidor no Azure para que as Medições de Usuário Real funcionem. A imagem de pixel único baixada pelo JavaScript de medição e o serviço que a executa em diferentes regiões do Azure é hospedada e gerenciada pelo Azure.

Meu uso de largura de banda do Azure aumentará quando eu usar as Medições de Usuário Real?

Como mencionado na resposta anterior, os componentes do lado do servidor das Medições de Usuário Real são de propriedade e gerenciados pelo Azure. Isso significa que o uso da largura de banda do Azure não aumentará porque você usa Medições de Usuário Real. Isso não inclui nenhum uso de largura de banda fora do que o Azure cobra. Minimizamos a largura de banda usada baixando apenas uma única imagem de pixel para medir a latência em uma região do Azure.

Vista de Tráfego

O que faz o Traffic View?

A Vista de Tráfego é uma funcionalidade do Gestor de Tráfego que o ajuda a compreender melhor os seus utilizadores e a sua experiência. Ele usa as consultas recebidas pelo Gerenciador de Tráfego e as tabelas de inteligência de latência de rede que o serviço mantém para fornecer o seguinte:

  • As regiões onde os usuários residem que estão se conectando aos seus pontos de extremidade no Azure.
  • O volume de usuários que se conectam a partir dessas regiões.
  • As regiões do Azure para as quais eles estão sendo roteados.
  • A experiência de latência dos usuários roteando para essas regiões do Azure.

Essas informações estão disponíveis para você consumir por meio de sobreposição de mapa geográfico e visualizações tabulares no portal, além de estarem disponíveis como dados brutos para download.

Como posso beneficiar da utilização da Vista de Tráfego?

A Vista de Tráfego dá-lhe uma vista geral do tráfego que os seus perfis do Gestor de Tráfego recebem. Em particular, ele pode ser usado para entender de onde sua base de usuários se conecta e, igualmente importante, qual é a experiência média de latência deles. Em seguida, você pode usar essas informações para localizar áreas nas quais precisa se concentrar, por exemplo, expandindo sua pegada do Azure para uma região que possa atender a esses usuários com latência mais baixa. Outra perceção que você pode obter ao usar a Visualização de Tráfego é ver os padrões de tráfego para diferentes regiões, o que, por sua vez, pode ajudá-lo a tomar decisões sobre como aumentar ou diminuir a invenção nessas regiões.

Qual é a diferença entre a Vista de Tráfego e as métricas do Gestor de Tráfego disponíveis através do Azure monitor?

O Azure Monitor pode ser usado para entender em um nível agregado o tráfego recebido pelo seu perfil e seus pontos de extremidade. Ele também permite que você acompanhe o status de integridade dos pontos de extremidade expondo os resultados da verificação de integridade. Quando você precisa ir além disso e entender a experiência do usuário final se conectando ao Azure em um nível regional, o Modo de Exibição de Tráfego pode ser usado para isso.

A Visualização de Tráfego usa informações de sub-rede do cliente EDNS?

As consultas DNS servidas pelo Azure Traffic Manager consideram as informações do ECS para aumentar a precisão do roteamento. Mas ao criar o conjunto de dados que mostra de onde os usuários estão se conectando, a Exibição de Tráfego está usando apenas o endereço IP do resolvedor DNS.

Quantos dias de dados utiliza a Vista de Tráfego?

A Vista de Tráfego cria a sua saída processando os dados dos sete dias anteriores ao dia anterior em que são visualizados por si. Esta é uma janela em movimento e os dados mais recentes são usados cada vez que você visita.

Como o Modo de Exibição de Tráfego lida com pontos de extremidade externos?

Quando você usa pontos de extremidade externos hospedados fora das regiões do Azure em um perfil do Gerenciador de Tráfego, pode optar por mapeá-lo para uma região do Azure, que é um proxy para suas características de latência (isso é de fato necessário se você usar o método de roteamento de desempenho). Se tiver esse mapeamento de região do Azure, as métricas de latência dessa região do Azure serão usadas ao criar a saída do Modo de Exibição de Tráfego. Se nenhuma região do Azure for especificada, as informações de latência ficarão vazias nos dados desses pontos de extremidade externos.

Preciso ativar a Visualização de Tráfego para cada perfil na minha assinatura?

Durante o período de pré-visualização, a Vista de Tráfego foi ativada ao nível da subscrição. Como parte das melhorias que fizemos antes da disponibilidade geral, agora você pode habilitar a Visualização de Tráfego em um nível de perfil, permitindo que você tenha uma habilitação mais granular desse recurso. Por padrão, o Modo de Exibição de Tráfego está desabilitado para um perfil.

Nota

Se você habilitou a Visualização de Tráfego em um nível de assinatura durante o tempo de visualização, agora precisará reativá-la para cada um dos perfis dessa assinatura.

Como posso desativar a Vista de Tráfego?

Você pode desativar a Visualização de Tráfego para qualquer perfil usando o Portal ou a API REST.

Como funciona a faturação da Vista de Tráfego?

O preço da Visualização de Tráfego é baseado no número de pontos de dados usados para criar a saída. Atualmente, o único tipo de dados suportado são as consultas que o seu perfil recebe. Além disso, você só será cobrado pelo processamento que foi feito quando a Visualização de Tráfego estiver ativada. Isso significa que, se você ativar a Visualização de Tráfego por algum período de tempo em um mês e desativá-la em outros horários, apenas os pontos de dados processados enquanto você tinha o recurso ativado contam para sua fatura.

Pontos finais do Gestor de Tráfego

Posso utilizar o Gestor de Tráfego com terminais de várias subscrições?

Não é possível usar pontos de extremidade de várias assinaturas com os Aplicativos Web do Azure. Os Aplicativos Web do Azure exigem que qualquer nome de domínio personalizado usado com Aplicativos Web seja usado apenas em uma única assinatura. Não é possível usar aplicativos Web de várias assinaturas com o mesmo nome de domínio.

Para outros tipos de endpoint, é possível usar o Gerenciador de Tráfego com pontos de extremidade de mais de uma assinatura. No Gerenciador de Recursos, os pontos de extremidade de qualquer assinatura podem ser adicionados ao Gerenciador de Tráfego, desde que a pessoa que configura o perfil do Gerenciador de Tráfego tenha acesso de leitura ao ponto de extremidade. Essas permissões podem ser concedidas usando o controle de acesso baseado em função do Azure (função RBAC do Azure). Pontos de extremidade de outras assinaturas podem ser adicionados usando o Azure PowerShell ou a CLI do Azure.

Posso usar o Gerenciador de Tráfego com slots de 'Preparo' do Serviço de Nuvem?

Sim. Os slots de 'preparação' do Serviço de Nuvem podem ser configurados no Gerenciador de Tráfego como pontos de extremidade externos. As verificações de integridade ainda são cobradas na taxa de Pontos de Extremidade do Azure.

O Traffic Manager suporta terminais IPv6?

Atualmente, o Gerenciador de Tráfego não fornece servidores de nomes endereçáveis por IPv6. No entanto, o Gerenciador de Tráfego ainda pode ser usado por clientes IPv6 que se conectam a pontos de extremidade IPv6 se o servidor DNS recursivo do cliente suportar IPv4. Um cliente não faz solicitação de DNS diretamente ao Gerenciador de Tráfego. Em vez disso, o cliente usa um serviço DNS recursivo. Um cliente somente IPv6 envia solicitações para o serviço DNS recursivo via IPv6. O serviço recursivo deve então ser capaz de contatar os servidores de nomes do Gerenciador de Tráfego usando IPv4. O Gestor de Tráfego responde com o nome DNS ou endereço IP do ponto de extremidade.

Posso usar o Gerenciador de Tráfego com mais de um aplicativo Web na mesma região?

Normalmente, o Gerenciador de Tráfego é usado para direcionar o tráfego para aplicativos implantados em diferentes regiões. No entanto, ele também pode ser usado quando um aplicativo tem mais de uma implantação na mesma região. Os pontos de extremidade do Azure do Gerenciador de Tráfego não permitem que mais de um ponto de extremidade de Aplicativo Web da mesma região do Azure seja adicionado ao mesmo perfil do Gerenciador de Tráfego.

Como faço para mover os pontos de extremidade do Azure do meu perfil do Gerenciador de Tráfego para um grupo de recursos ou assinatura diferente?

Os pontos de extremidade do Azure associados a um perfil do Gerenciador de Tráfego são rastreados usando suas IDs de recurso. Quando um recurso do Azure que está sendo usado como um ponto de extremidade (por exemplo, IP Público, Serviço de Nuvem Clássico, WebApp ou outro perfil do Gerenciador de Tráfego usado de maneira aninhada) é movido para um grupo de recursos ou assinatura diferente, sua ID de recurso é alterada. Nesse cenário, atualmente, você deve atualizar o perfil do Gerenciador de Tráfego excluindo primeiro e, em seguida, adicionando novamente os pontos de extremidade ao perfil.

Para obter mais informações, consulte Para mover um ponto de extremidade.

O Azure Traffic Manager suporta Mecanismos de Extensão IPv6 para DNS (ECS)?

O Azure Traffic Manager suporta endereços IPv6 com Mecanismos de Extensão para DNS (ECS). Isso significa que, quando uma consulta DNS inclui informações do ECS, o Gerenciador de Tráfego do Azure pode usar o endereço IP de origem dentro do ECS para tomar decisões inteligentes de roteamento.

O suporte para IPv6 ECS traz várias vantagens:

  • Localização melhorada: Ao considerar o endereço IPv6 no ECS, o Gestor de Tráfego pode encaminhar os utilizadores para o ponto de extremidade mais próximo ou mais apropriado, melhorando a experiência do utilizador com latência reduzida.
  • Controle de tráfego aprimorado: o IPv6 ECS permite decisões de roteamento de tráfego mais granulares, permitindo um melhor gerenciamento do tráfego global e da distribuição.

Ao usar o IPv6 ECS, é importante garantir que seus pontos de extremidade estejam configurados corretamente para lidar com o tráfego IPv6. Verifique também se sua infraestrutura DNS, incluindo resolvedores recursivos, é capaz de lidar com informações do ECS com endereços IPv6.

Monitorização do ponto final do Gestor de Tráfego

O Gerenciador de Tráfego é resiliente a falhas de região do Azure?

O Gerenciador de Tráfego é um componente fundamental da entrega de aplicativos altamente disponíveis no Azure. Para oferecer alta disponibilidade, o Traffic Manager deve ter um nível excepcionalmente alto de disponibilidade e ser resiliente a falhas regionais.

Por design, os componentes do Gerenciador de Tráfego são resilientes a uma falha completa de qualquer região do Azure. Essa resiliência se aplica a todos os componentes do Gerenciador de Tráfego: os servidores de nomes DNS, a API, a camada de armazenamento e o serviço de monitoramento de ponto final.

No caso improvável de uma interrupção de toda uma região do Azure, espera-se que o Gerenciador de Tráfego continue a funcionar normalmente. Os aplicativos implantados em várias regiões do Azure podem contar com o Gerenciador de Tráfego para direcionar o tráfego para uma instância disponível de seu aplicativo.

Como é que a escolha da localização do grupo de recursos afeta o Gestor de Tráfego?

O Traffic Manager é um serviço único e global. Não é regional. A escolha do local do grupo de recursos não faz diferença para os perfis do Gerenciador de Tráfego implantados nesse grupo de recursos.

O Azure Resource Manager exige que todos os grupos de recursos especifiquem um local, que determina o local padrão para os recursos implantados nesse grupo de recursos. Quando você cria um perfil do Gerenciador de Tráfego, ele é criado em um grupo de recursos. Todos os perfis do Gerenciador de Tráfego usam global como local, substituindo o padrão do grupo de recursos.

Como determino a integridade atual de cada ponto de extremidade?

O status de monitoramento atual de cada ponto de extremidade, além do perfil geral, é exibido no portal do Azure. Essas informações também estão disponíveis por meio da API REST do Monitor de Tráfego, cmdlets do PowerShell e CLI do Azure entre plataformas.

Você também pode usar o Azure Monitor para acompanhar a integridade de seus pontos de extremidade e ver uma representação visual deles. Para obter mais informações sobre como usar o Azure Monitor, consulte a documentação do Monitoramento do Azure.

Posso monitorar pontos de extremidade HTTPS?

Sim. O Traffic Manager suporta sondagem por HTTPS. Configure HTTPS como o protocolo na configuração de monitoramento.

O gestor de tráfego não pode fornecer qualquer validação de certificado, incluindo:

  • Os certificados do lado do servidor não são validados
  • Os certificados SNI do lado do servidor não são validados
  • Não há suporte para certificados de cliente

Utilizo um endereço IP ou um nome DNS ao adicionar um ponto de extremidade?

O Gerenciador de Tráfego oferece suporte à adição de pontos de extremidade usando três maneiras de encaminhá-los:

  • Como um nome DNS
  • Como um endereço IPv4
  • Como um endereço IPv6

Se o ponto de extremidade for adicionado como um endereço IPv4 ou IPv6, a resposta da consulta será do tipo de registro A ou AAAA, respectivamente. Se o ponto de extremidade foi adicionado como um nome DNS, a resposta da consulta é do tipo de registro CNAME. Adicionar pontos de extremidade como endereço IPv4 ou IPv6 só é permitido se o ponto de extremidade for do tipo Externo.

Todos os métodos de roteamento e configurações de monitoramento são suportados pelos três tipos de endereçamento de ponto final.

Que tipos de endereços IP posso usar ao adicionar um ponto de extremidade?

O Gerenciador de Tráfego permite que você use endereços IPv4 ou IPv6 para especificar pontos de extremidade. Existem algumas restrições, que estão listadas abaixo:

  • Endereços que correspondem a espaços de endereços IP privados reservados não são permitidos. Esses endereços incluem aqueles chamados em RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544 e RFC 5771.
  • O endereço IP não deve conter números de porta (você pode especificar as portas a serem usadas nas definições de configuração do perfil).
  • Não há dois pontos de extremidade no mesmo perfil que possam ter o mesmo endereço IP de destino.

Posso usar diferentes tipos de endereçamento de ponto final em um único perfil?

N.º O Gerenciador de Tráfego não permite que você misture tipos de endereçamento de ponto de extremidade dentro de um perfil, exceto no caso de um perfil com tipo de roteamento MultiValue, onde você pode misturar tipos de endereçamento IPv4 e IPv6.

O que acontece quando o tipo de registro de uma consulta de entrada é diferente do tipo de registro associado ao tipo de endereçamento dos pontos de extremidade?

Quando uma consulta é recebida em relação a um perfil, o Gerenciador de Tráfego primeiro localiza o ponto de extremidade que precisa ser retornado de acordo com o método de roteamento especificado e o status de integridade dos pontos de extremidade. Em seguida, ele examina o tipo de registro solicitado na consulta de entrada e o tipo de registro associado ao ponto de extremidade antes de retornar uma resposta com base na tabela abaixo.

Para perfis com qualquer método de roteamento diferente de MultiValue:

Solicitação de consulta de entrada Tipo de ponto final Resposta fornecida
QUALQUER A / AAAA / CNAME Ponto final de destino
A A / CNAME Ponto final de destino
A AAAA NODATA
AAAA AAAA / CNAME Ponto final de destino
AAAA A NODATA
CNAME CNAME Ponto final de destino
CNAME A / AAAA NODATA

Para perfis com método de roteamento definido como MultiValue:

Solicitação de consulta de entrada Tipo de ponto final Resposta fornecida
QUALQUER Mix de A e AAAA Pontos de avaliação de destino
A Mix de A e AAAA Apenas pontos finais de destino do tipo A
AAAA Mix de A e AAAA Somente pontos de extremidade de destino do tipo AAAA
CNAME Mix de A e AAAA NODATA

Posso usar um perfil com pontos de extremidade endereçados IPv4 / IPv6 em um perfil aninhado?

Sim, você pode, com a exceção de que um perfil do tipo MultiValue não pode ser um perfil pai em um conjunto de perfis aninhado.

Parei um ponto de extremidade de aplicativo Web no meu perfil do Gerenciador de Tráfego, mas não estou recebendo nenhum tráfego, mesmo depois de reiniciá-lo. Como posso corrigir isso?

Quando um ponto de extremidade de aplicativo Web do Azure é interrompido, o Gerenciador de Tráfego para de verificar sua integridade e reinicia as verificações de integridade somente depois de detetar que o ponto de extremidade foi reiniciado. Para evitar esse atraso, desative e reative esse ponto de extremidade no perfil do Gerenciador de Tráfego depois de reiniciar o ponto de extremidade.

Posso usar o Gerenciador de Tráfego mesmo que meu aplicativo não tenha suporte para HTTP ou HTTPS?

Sim. Você pode especificar TCP como o protocolo de monitoramento e o Gerenciador de Tráfego pode iniciar uma conexão TCP e aguardar uma resposta do ponto de extremidade. Se o ponto de extremidade responder à solicitação de conexão com uma resposta para estabelecer a conexão, dentro do período de tempo limite, esse ponto de extremidade será marcado como íntegro.

Que respostas específicas são necessárias do ponto de extremidade ao usar o monitoramento TCP?

Quando o monitoramento TCP é usado, o Gerenciador de Tráfego inicia um handshake TCP de três vias enviando uma solicitação SYN para o ponto de extremidade na porta especificada. Em seguida, ele aguarda uma resposta SYN-ACK do ponto de extremidade por um período de tempo (especificado nas configurações de tempo limite).

  • Se uma resposta SYN-ACK for recebida dentro do período de tempo limite especificado nas configurações de monitoramento, esse ponto de extremidade será considerado íntegro. Um FIN ou FIN-ACK é a resposta esperada do Gerenciador de Tráfego quando ele encerra regularmente um soquete.
  • Se uma resposta SYN-ACK for recebida após o tempo limite especificado, o Gerenciador de Tráfego responderá com um RST para redefinir a conexão.

Com que rapidez o Gerenciador de Tráfego afasta meus usuários de um ponto de extremidade não íntegro?

O Gerenciador de Tráfego fornece várias configurações que podem ajudá-lo a controlar o comportamento de failover do seu perfil do Gerenciador de Tráfego da seguinte maneira:

  • você pode especificar que o Gerenciador de Tráfego sonde os pontos de extremidade com mais freqüência definindo o Intervalo de Sondagem em 10 segundos. Isso garante que qualquer ponto de extremidade que não esteja íntegro possa ser detetado o mais rápido possível.
  • Você pode especificar quanto tempo esperar até que uma solicitação de verificação de integridade atinja o tempo limite (o valor mínimo de tempo limite é de 5 segundos).
  • Você pode especificar quantas falhas podem ocorrer antes que o ponto de extremidade seja marcado como não íntegro. Esse valor pode ser baixo como 0, caso em que o ponto de extremidade é marcado como não íntegro assim que falha na primeira verificação de integridade. No entanto, usar o valor mínimo de 0 para o número tolerado de falhas pode levar a que os pontos finais sejam retirados da rotação devido a quaisquer problemas transitórios que possam ocorrer no momento da sondagem.
  • você pode especificar o tempo de vida (TTL) para que a resposta DNS seja tão baixa quanto 0. Isso significa que os resolvedores de DNS não podem armazenar a resposta em cache e cada nova consulta obtém uma resposta que incorpora as informações de integridade mais atualizadas que o Gerenciador de Tráfego tem.

Usando essas configurações, o Gerenciador de Tráfego pode fornecer failovers em menos de 10 segundos depois que um ponto de extremidade não estiver íntegro e uma consulta DNS for feita no perfil correspondente.

Como posso especificar diferentes configurações de monitoramento para diferentes pontos de extremidade em um perfil?

As configurações de monitoramento do Gerenciador de Tráfego estão em um nível por perfil. Se você precisar usar uma configuração de monitoramento diferente para apenas um ponto de extremidade, isso pode ser feito tendo esse ponto de extremidade como um perfil aninhado cujas configurações de monitoramento são diferentes do perfil pai.

Como posso atribuir cabeçalhos HTTP às verificações de integridade do Gerenciador de Tráfego aos meus pontos de extremidade?

O Gerenciador de Tráfego permite que você especifique cabeçalhos personalizados nas verificações de integridade HTTP(S) que inicia em seus pontos de extremidade. Se quiser especificar um cabeçalho personalizado, você pode fazer isso no nível do perfil (aplicável a todos os pontos de extremidade) ou especificá-lo no nível do ponto de extremidade. Se um cabeçalho for definido em ambos os níveis, o especificado no nível do ponto final substituirá o nível de perfil 1. Um caso de uso comum para isso é especificar cabeçalhos de host para que as solicitações do Gerenciador de Tráfego possam ser roteadas corretamente para um ponto de extremidade hospedado em um ambiente multilocatário. Outro caso de uso disso é identificar solicitações do Gerenciador de Tráfego a partir dos logs de solicitação HTTP(S) de um ponto de extremidade

Qual cabeçalho de host as verificações de integridade do endpoint usam?

Se nenhuma configuração de cabeçalho de host personalizado for fornecida, o cabeçalho de host usado pelo Gerenciador de Tráfego será o nome DNS do destino do ponto de extremidade configurado no perfil, se estiver disponível.

Quais são os endereços IP de onde provêm as verificações de integridade?

Consulte este artigo para saber como recuperar as listas de endereços IP dos quais as verificações de integridade do Gerenciador de Tráfego podem se originar. Você pode usar a API REST, a CLI do Azure ou o Azure PowerShell para recuperar a lista mais recente. Revise os IPs listados para garantir que as conexões de entrada desses endereços IP sejam permitidas nos pontos de extremidade para verificar seu status de integridade.

Exemplo usando o Azure PowerShell:

$serviceTags = Get-AzNetworkServiceTag -Location eastus
$result = $serviceTags.Values | Where-Object { $_.Name -eq "AzureTrafficManager" }
$result.Properties.AddressPrefixes

Nota

Os endereços IP públicos podem ser alterados sem aviso prévio. Certifique-se de recuperar as informações mais recentes usando a API de descoberta de marca de serviço ou o arquivo JSON baixável.

Quantas verificações de integridade para o meu endpoint posso esperar do Gerenciador de Tráfego?

O número de verificações de integridade do Gerenciador de Tráfego que chegam ao seu ponto de extremidade depende do seguinte:

  • O valor que você definiu para o intervalo de monitoramento (intervalo menor significa mais solicitações chegando ao seu ponto de extremidade em um determinado período de tempo).
  • o número de locais de onde as verificações de integridade se originam (os endereços IP de onde você pode esperar essas verificações estão listados nas perguntas frequentes anteriores).

Como posso ser notificado se um dos meus endpoints cair?

Uma das métricas fornecidas pelo Traffic Manager é o status de integridade dos pontos de extremidade em um perfil. Você pode ver isso como um agregado de todos os pontos de extremidade dentro de um perfil (por exemplo, 75% dos seus pontos de extremidade estão íntegros) ou, em um nível por ponto final. As métricas do Gerenciador de Tráfego são expostas por meio do Azure Monitor e você pode usar seus recursos de alerta para receber notificações quando houver uma alteração no status de integridade do seu ponto de extremidade. Para obter mais informações, consulte Métricas e alertas do Gerenciador de Tráfego.

Perfis aninhados do Traffic Manager

Como configuro perfis aninhados?

Os perfis do Gerenciador de Tráfego Aninhado podem ser configurados usando o Gerenciador de Recursos do Azure e as APIs REST clássicas do Azure, cmdlets do Azure PowerShell e comandos da CLI do Azure entre plataformas. Eles também são suportados por meio do novo portal do Azure.

Quantas camadas de aninhamento o Traffic Manger suporta?

Você pode aninhar perfis de até 10 níveis de profundidade. 'Loops' não são permitidos.

Posso misturar outros tipos de ponto de extremidade com perfis filho aninhados, no mesmo perfil do Gerenciador de Tráfego?

Sim. Não há restrições sobre como você combina pontos de extremidade de diferentes tipos dentro de um perfil.

Como o modelo de cobrança se aplica aos perfis aninhados?

Não há impacto negativo nos preços do uso de perfis aninhados.

A faturação do Gestor de Tráfego tem dois componentes: verificações do estado de funcionamento dos pontos finais e milhões de consultas DNS

  • Verificações de integridade do ponto de extremidade: não há cobrança para um perfil filho quando configurado como um ponto de extremidade em um perfil pai. O monitoramento dos pontos finais no perfil da criança é cobrado da maneira usual.
  • Consultas DNS: cada consulta é contada apenas uma vez. Uma consulta em relação a um perfil pai que retorna um ponto de extremidade de um perfil filho é contada apenas em relação ao perfil pai.

Para obter detalhes completos, consulte a página de preços do Gerenciador de Tráfego.

Existe um impacto no desempenho de perfis aninhados?

Não, não há impacto no desempenho ao usar perfis aninhados.

Os servidores de nomes do Gerenciador de Tráfego atravessam a hierarquia de perfis internamente ao processar cada consulta DNS. Uma consulta DNS para um perfil pai pode receber uma resposta DNS com um ponto de extremidade de um perfil filho. Um único registro CNAME é usado se você estiver usando um único perfil ou perfis aninhados. Não há necessidade de criar um registro CNAME para cada perfil na hierarquia.

Como o Gerenciador de Tráfego calcula a integridade de um ponto de extremidade aninhado em um perfil pai?

O perfil pai não executa verificações de integridade diretamente na criança. Em vez disso, a integridade dos pontos finais do perfil de criança é usada para calcular a integridade geral do perfil de criança. Essas informações são propagadas para cima na hierarquia de perfil aninhado para determinar a integridade do ponto de extremidade aninhado. O perfil pai usa essa integridade agregada para determinar se o tráfego pode ser direcionado para a criança.

A tabela a seguir descreve o comportamento das verificações de integridade do Gerenciador de Tráfego para um ponto de extremidade aninhado.

Status do Monitor de Perfil Infantil Status do Monitor de Ponto Final Pai Notas
Desativado. O perfil da criança foi desativado. Parado O estado do ponto de extremidade pai é Stopped, não Disabled. O Disabled estado é reservado para indicar que você desabilitou o ponto de extremidade no perfil pai.
Degradado. Pelo menos um ponto de extremidade de perfil filho está em um Degraded estado. Online: o número de pontos de Online extremidade no perfil filho é pelo menos o valor de MinChildEndpoints.
CheckingEndpoint: o número de pontos de Online extremidade mais CheckingEndpoint no perfil filho é pelo menos o valor de MinChildEndpoints.
Degradado: caso contrário.		 O tráfego é roteado para um ponto de extremidade de status CheckingEndpoint. Se MinChildEndpoints estiver definido como muito alto, o ponto de extremidade será sempre degradado.
Através da Internet. Pelo menos um ponto de extremidade de perfil filho é um Online estado. Nenhum ponto de extremidade está no Degraded estado. Ver supra.
CheckingEndpoints. Pelo menos um ponto de extremidade de perfil filho é CheckingEndpoint. Nenhum ponto de extremidade é Online ou Degraded Mesmo que acima.
Inativo. Todos os pontos de extremidade de perfil filho são ou Disabled Stopped, ou esse perfil não tem pontos de extremidade. Parado

Importante

Ao gerenciar perfis filho em um perfil pai no Gerenciador de Tráfego do Azure, um problema pode ocorrer se você desabilitar e habilitar simultaneamente dois perfis filho. Se essas ações ocorrerem ao mesmo tempo, pode haver um breve período em que ambos os pontos de extremidade estão desativados, levando o perfil pai a entrar em um estado comprometido.

Para evitar esse problema, tenha cuidado ao fazer alterações simultâneas em perfis de criança. Considere escalonar ligeiramente essas ações para evitar interrupções não intencionais na configuração de gerenciamento de tráfego.

Por que não consigo adicionar Pontos de extremidade de Suporte Estendido dos Serviços de Nuvem do Azure ao meu perfil do Gerenciador de Tráfego?

Para adicionar pontos de extremidade do Azure Cloud Extended a um perfil do Gerenciador de Tráfego, o grupo de recursos deve ter compatibilidade com a API do Azure Service Management (ASM). Os perfis localizados no grupo de recursos mais antigo devem aderir aos padrões da API ASM, que proíbem a inclusão de pontos de extremidade de endereço IP público ou pontos de extremidade de uma assinatura diferente da do perfil. Para resolver isso, considere mover seu perfil do Gerenciador de Tráfego e recursos associados para um novo grupo de recursos compatível com a API ASM.

Passos seguintes: