Partilhar via

Perguntas Frequentes (FAQ) do Traffic Manager

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 os clientes ao 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 Gestor de Tráfego não fornece um ponto de extremidade ou endereço IP para que os clientes se conectem. 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 persistentes?

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 terminais que utilizam o Azure App Service, consulte configurar um nome de domínio personalizado para uma aplicação web no Azure App Service usando o Traffic Manager.

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 aplicações que o utilizam não reiniciam 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 Gestor de Tráfego se integra com aplicações ao nível do DNS, requer uma consulta DNS adicional para ser inserida na cadeia de resolução de 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 – Sub-rede do Cliente em Consultas DNS fornece um mecanismo de extensão para DNS (EDNS0) que 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 os seus dados não refletem as informações de estado de saúde mais recentes que o Traffic Manager obteve através dos seus agentes.

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 agregadas ao nível do perfil ou detalhar ainda mais para ver o volume de consultas em que foram devolvidos pontos finais específicos. 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 é conhecida por ser vulnerável, no entanto, o TLS 1.2 e posteriores oferecem 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 Manager 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.

Quais pacotes de codificação TLS são suportados pelo Gerenciador de Tráfego do Azure?

O Azure Traffic Manager suporta pacotes de codificação TLS modernos para TLS 1.2 e TLS 1.3 para garantir comunicações seguras. Os seguintes pacotes de codificação são suportados:

TLS 1.3 Pacotes de codificação

Estes estão associados ao Protocolo 772 (que corresponde ao TLS 1.3):

Suíte Cipher Protocolo
TLS_AES_256_GCM_SHA384 772
TLS_AES_128_GCM_SHA256 772

TLS 1.2 Suítes Cifradas

Estes estão associados ao Protocolo 771 (TLS 1.2) e/ou 65277 (usado por alguns sistemas como um código interno/personalizado para TLS 1.2):

Suíte Cipher Protocolos
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 771, 65277
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 771, 65277
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 771, 65277
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 771, 65277
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 771, 65277
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 771, 65277
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 771, 65277
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 771, 65277

Esses pacotes de codificação fornecem criptografia forte e são compatíveis com os padrões de segurança modernos. O Traffic Manager negocia automaticamente o melhor pacote de codificação disponível durante o processo de handshake TLS.

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.

Observação

Poderá haver cenários onde poderá necessitar de capacidades tanto de desempenho como de roteamento geográfico; nestes 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 endpoint precisa estar localizado fisicamente na mesma região para 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 US-Central do Azure pode ter todos os utilizadores na Í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 Gestor de Tráfego não realiza failover para outro endereço de rede, mesmo quando a região atribuída é "mãe" da região atribuída ao endereço de rede que ficou inativo (por exemplo, se um endereço de rede com a região Espanha ficar inativo, não fazemos failover para outro endereço de rede com a região Europa atribuída). 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á ser redirecionado 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 utilizar versões mais antigas da API, qualquer perfil retornado que contenha endpoints com uma atribuição de região geográfica não terá essa atribuição exibida.

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 se oferece para conjuntos específicos de utilizadores identificados pelo IP de origem das suas solicitações DNS. 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.

Observação

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 tenhas um ponto de extremidade de reserva no teu perfil, uma vez que o Gestor de Tráfego retorna uma resposta NXDOMAIN se uma solicitação chegar e não estiver mapeada para nenhum ponto de extremidade, ou se estiver mapeada para um ponto de extremidade, mas esse ponto de extremidade não estiver saudável.

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 MultiValue retorna múltiplos endpoints íntegros numa única resposta de consulta. A principal vantagem disto é que, se um endpoint estiver com problemas, o cliente tem mais opções para tentar novamente sem precisar fazer outra chamada DNS (que pode devolver o mesmo valor de uma 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 tiver "configuração dupla" para endereços IPv4 e IPv6 e você desejar oferecer ao chamador ambas as opções ao iniciar 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 o MultiValue não retorna mais do que esse número de pontos de extremidade saudáveis 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 endpoints seja retornado em cada consulta. Isto também é devido ao fato de que alguns dos endpoints podem não estar funcionais, caso isso aconteça, eles não serão incluídos na resposta.

Medidas Reais de Utilizadores

Quais são os benefícios de usar as Medições do Utilizador 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 Reais do Utilizador excluindo a 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. Estas informações são então reportadas de volta ao serviço Gestor 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 de Utilizador 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 Gestor de Tráfego opera separadamente da componente de medição de utilizadores reais e, apesar de ser uma ótima ideia tê-los ambos no mesmo site, não é necessário que estejam juntos.

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 residem os utilizadores que estão a ligar-se 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 a ser encaminhados.
  • 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 o estoque 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 a nível agregado o tráfego recebido pelo seu perfil e seus endpoints. Ele também permite que acompanhe o estado de integridade dos endpoints expondo os resultados da verificação de integridade. Quando precisar ir além disso e entender a experiência do utilizador final ao se conectar ao Azure a um nível regional, a Vista de Tráfego pode ser usada para alcançar 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 utilizadores estão se conectando, o Traffic View 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 gera os seus resultados processando os dados a partir dos sete dias anteriores ao dia da visualização por si. Esta é uma janela em movimento e os dados mais recentes são usados cada vez que você visita.

Como o Traffic View gere pontos finais 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 este mapeamento de região do Azure, as métricas de latência dessa região do Azure serão usadas quando se cria a saída para a Vista 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 defeito, a Vista de Tráfego está desativada num perfil.

Observação

Caso tenha habilitado a Visualização de Tráfego ao nível da assinatura durante o período de visualização, agora precisará reativá-la para cada um dos perfis sob essa 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 do Traffic View?

O preço da Visão Geral do Tráfego é baseado no número de pontos de dados usados para gerar o resultado. 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 Traffic Manager

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

Usar pontos de extremidade de assinaturas múltiplas não é viável com as Aplicações 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 utilizar o Gestor de Tráfego com pontos de extremidade de mais de uma subscrição. 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 o Azure CLI.

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 continuam a ser cobradas à tarifa de Pontos de Extremidade do Azure.

O Traffic Manager suporta terminais IPv6?

Sim, o Traffic Manager oferece suporte completo a endpoints IPv6. O Gerenciador de Tráfego fornece servidores de nomes endereçáveis IPv4 e IPv6, permitindo que os clientes se conectem perfeitamente usando qualquer um dos protocolos. Os clientes IPv6 podem fazer solicitações DNS diretamente por meio de serviços DNS recursivos habilitados para IPv6, e o Gerenciador de Tráfego pode responder com o nome DNS ou endereço IP do ponto de extremidade IPv6, permitindo total compatibilidade com redes IPv6.

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 terminais do Tráfego Manager Azure não permitem que mais de um terminal de Aplicação Web da mesma região do Azure seja adicionado ao mesmo perfil do Tráfego Manager.

Como posso transferir os endpoints do Azure do meu perfil do gestor de tráfego para outro grupo de recursos ou subscrição?

Os endpoints do Azure associados a um perfil do Traffic Manager são rastreados utilizando os respetivos 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 endpoint.

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 de pontos finais 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 Gestor de Tráfego usam global como localização, sobrepondo o padrão do grupo de recursos.

Como determino a saúde 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 monitorizar a saúde de seus pontos de extremidade e ver uma representação visual dos mesmos. Para obter mais informações sobre como usar o Azure Monitor, consulte a documentação do Monitoramento do Azure.

Posso monitorizar 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 de DNS ao adicionar um endpoint?

O Gerenciador de Tráfego suporta a adição de pontos de extremidade usando três maneiras de referenciá-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 endpoint?

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 definidos nos 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. 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:

Pedido de consulta de entrada Tipo de ponto final Resposta fornecida
QUALQUER A / AAAA / CNAME Ponto final de destino
Um A / CNAME Ponto final de destino
Um AAAA SEM DADOS
AAAA AAAA / CNAME Ponto final de destino
AAAA Um SEM DADOS
CNAME CNAME Ponto final de destino
CNAME A / AAAA SEM DADOS

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

Pedido de consulta de entrada Tipo de ponto final Resposta fornecida
QUALQUER Mistura de A e AAAA Destinos Finais
Um Mistura de A e AAAA Apenas pontos finais de destino do tipo A
AAAA Mistura de A e AAAA Apenas endpoints de destino do tipo AAAA
CNAME Mistura de A e AAAA SEM DADOS

Posso usar um perfil com endpoints endereçados IPv4 / IPv6 num perfil aninhado?

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

Parei um endpoint de aplicação Web no meu perfil no Traffic Manager, mas não estou a receber tráfego, mesmo após reiniciar. Como posso corrigir isso?

Quando um ponto de extremidade de uma aplicação Web do Azure é parado, o Gestor de Tráfego para de verificar a sua integridade e só reinicia as verificações de integridade 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 ligação, dentro do tempo limite, esse ponto de extremidade será marcado como saudável.

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, o sistema aguarda uma resposta SYN-ACK do ponto de extremidade durante um tempo (especificado nas definições de limite de tempo).

  • Se uma resposta SYN-ACK for recebida dentro do período de tempo limite especificado nas definições de monitorização, esse endpoint será considerado funcional. 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 Gestor de Tráfego move os meus utilizadores de um endpoint não saudável?

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 Traffic Manager sonde os endpoints com mais frequência ao definir 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 endpoint seja marcado como não saudável. Este valor pode ser tão baixo quanto 0, caso em que o endpoint é marcado como não saudável 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 up-toque o Gerenciador de Tráfego possui.

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. Caso precise utilizar uma configuração de monitorização diferente para apenas um ponto de extremidade, é possível definir esse ponto de extremidade num perfil aninhado cujas configurações de monitorização sejam diferentes do perfil principal.

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

O Gestor de Tráfego permite que o utilizador especifique cabeçalhos personalizados nas verificações de integridade HTTP(S) que inicia nos seus endpoints. 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

Que cabeçalho de host é usado pelas verificações de saúde do endpoint?

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 endereços IP listados para garantir que as conexões de entrada desses endereços IP sejam autorizadas nos endpoints para verificar o estado de integridade.

Exemplo usando o Azure PowerShell:

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

Observação

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 Gestor de Tráfego que chegam ao seu endpoint depende de:

  • 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 estado de saúde dos endereços de rede num perfil. Isto pode ser visto como uma agregação de todos os pontos de extremidade dentro de um perfil (por exemplo, 75% de seus pontos de extremidade estão íntegros) ou ao nível de cada ponto de extremidade. As métricas do Gestor de Tráfego são expostas através do Azure Monitor e pode utilizar os seus recursos de alerta para receber notificações quando houver uma alteração no estado de saúde 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 Gerenciador de Tráfego suporta?

É possível aninhar perfis até 10 níveis de profundidade. "Não é permitido usar 'loops'."

Posso misturar outros tipos de pontos de extremidade com perfis filho aninhados no mesmo perfil do Traffic Manager?

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 existe impacto negativo nos preços ao utilizar 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 sobre um perfil pai que retorna um endpoint 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 de um perfil pai pode receber uma resposta DNS com um endpoint 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 saúde diretamente no perfil filho. Em vez disso, a saúde das extremidades do perfil infantil é usada para calcular a saúde geral do perfil infantil. 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 saúde do Gerenciador de Tráfego para um endpoint aninhado.

Estado do Monitor de Perfil da Criança Status do Monitor de Ponto Final Pai Observações
Desativado. O perfil da criança foi desativado. Parado O estado do ponto de extremidade pai é Stopped, não Disabled. O estado Disabled é reservado para indicar que o utilizador desativou o endpoint no perfil pai.
Degradado. Pelo menos um terminal de perfil de criança está em um Degraded estado. Online: o número de Online endpoints no perfil de filho é no mínimo o valor de MinChildEndpoints.
CheckingEndpoint: o número de endpoints de Online mais CheckingEndpoint no perfil filho é pelo menos o valor de MinChildEndpoints.
Degradado: caso contrário.		 O tráfego é encaminhado para um endpoint de status CheckingEndpoint. Se MinChildEndpoints estiver definido como muito alto, o ponto de extremidade será sempre degradado.
Através da Internet. Pelo menos um endpoint de perfil de criança está em um Online estado. Nenhum ponto de extremidade está no estado Degraded. Ver supra.
VerificaçãoDePontosFinais Pelo menos um ponto de extremidade de perfil de criança é CheckingEndpoint. Nenhum endpoint é Online ou Degraded Mesmo que acima.
Inativo. Todos os pontos de extremidade de perfil filho são Disabled ou Stopped, ou este 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 Azure Cloud Services Extended Support Endpoints ao meu perfil do Traffic Manager?

Para adicionar pontos de extremidade do Azure Cloud Extended a um perfil do Gestor de Tráfego, o grupo de recursos deve ter compatibilidade com a API de Gestão de Serviços do Azure (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: