Registros de topologia do GTM: o Longest Match ordena, não escolhe

O balanceamento por topologia dá pontuação aos candidatos a partir de uma lista ordenada de registros, e o que o Longest Match faz de fato é essa ordenação. O primeiro registro que casa com um candidato define a pontuação dele, os registros seguintes ficam sombreados e a maior pontuação vence. É por isso que um wildcard com peso alto pode, sim, vencer um /32 com peso baixo.

O balanceamento por topologia responde a uma pergunta de proximidade: considerando de onde veio a consulta, qual destino deve atendê-la? O mecanismo é uma lista de registros de topologia, e a coisa mais útil para entender sobre ele é o que o Longest Match faz de verdade. A versão que circula por aí diz que vence o registro mais específico que casar com a consulta. A documentação diz algo mais preciso, e essa diferença decide para onde vai o tráfego real.

O registro

Um registro de topologia associa uma origem a um destino e dá um peso a essa associação. A declaração de origem (request source) descreve o (local DNS resolver, o resolver DNS local) que fez a consulta: uma sub-rede IP em notação , uma região definida pelo usuário, um (internet service provider, o provedor de acesso), um país, um continente. A declaração de destino diz onde o peso vai cair: um pool, um data center, uma sub-rede, uma região. E o peso é o número que o balanceamento vai comparar; o manual observa que, no tmsh, o parâmetro de peso se chama score. Qualquer um dos lados pode ser negado com not, e uma assimetria prática vale conhecer logo: registros com destino do tipo data center se aplicam no nível de pool (escolhendo entre virtual servers), e não no nível de wide IP (escolhendo entre pools), porque um pool, em si, não fica dentro de um data center.

Como a origem de uma consulta é o endereço de um LDNS, os tipos de origem que não são sub-rede dependem de classificação: a base de geolocalização embutida, para país, continente e ISP, e as suas próprias definições de gtm region, para regiões, que podem conter sub-redes, países, continentes, ISPs e outras regiões, inclusive aninhadas. Uma observação para implantações modernas: por padrão, o endereço classificado é o do próprio LDNS, e a opção topology-prefer-edns0-client-subnet (global ou por wide IP) faz o match usar o EDNS0 Client Subnet que o resolver repassou, voltando ao endereço de origem quando a consulta não traz essa informação.

O Longest Match ordena a lista

Com o Longest Match habilitado, que é o padrão, o sistema reordena a lista de registros toda vez que a configuração é carregada, e as chaves de ordenação são, nas palavras do manual, a declaração de origem LDNS, a declaração de destino e o peso do registro. Dentro da chave de origem, os tipos seguem uma hierarquia verificada, demonstrada nos exemplos resolvidos do K10721: primeiro vêm as sub-redes IP, ordenadas entre si pela máscara mais longa (um /32 acima de um /24, que fica acima de um /16); depois data centers e pools; depois regiões definidas pelo usuário; depois ISPs; depois países; depois continentes. A mesma hierarquia ordena o lado do destino quando as origens empatam. O K10721 acrescenta as regras de agrupamento em torno dessa hierarquia: registros com negação ficam abaixo dos registros simples, mas acima dos wildcards (curingas), sendo que uma negação do lado do servidor fica acima de uma negação do lado do LDNS, e os registros wildcard (0.0.0.0/0) vão para o fim da lista.

Uma sutileza que decorre dessa hierarquia: para a ordenação, uma região é uma entidade única. Uma região que casa por meio de uma das suas sub-redes não herda a especificidade dessa sub-rede; ela é ordenada no nível de região, sejam quais forem os seus membros.

Desabilite o Longest Match e a ordenação automática some: quem decide qual registro se aplica passam a ser a ordem da lista, que você mantém, e os pesos.

As pontuações decidem

Aqui está a parte que a versão popular deixa escapar. A lista ordenada não é percorrida em busca de um único registro vencedor; ela é usada, como diz o manual, para atribuir pontuações aos pools ou aos membros de pool. O sistema percorre os registros ordenados, e cada destino candidato recebe a sua pontuação do primeiro registro que casa com ele. Qualquer registro posterior que cite um candidato já pontuado simplesmente nunca é usado: fica sombreado (shadowed) pelo anterior. Terminada a passagem, vence o candidato com a maior pontuação atribuída, e pontuações máximas iguais são resolvidas em round robin.

Daí saem duas consequências, e as duas aparecem em produção. Primeira: um registro wildcard com peso 100 vence um registro /32 com peso 5. A especificidade decidiu apenas qual registro pontuou cada candidato, e depois 100 venceu 5. O Longest Match não é uma regra do tipo "o mais específico vence"; é o critério de desempate que decide qual de vários registros que casam fala por um candidato. Segunda: o sombreamento produz resultados que vão mesmo contra a intuição. Um candidato com um registro de peso alto no fim da lista ordenada pode perder porque um registro de peso menor, mais acima na lista, já deu a pontuação dele. A posição na ordenação controla qual peso vale; os pesos controlam quem vence.

Um exemplo resolvido, o mesmo que o pontuador longest-match carrega como demonstração de um clique. São três registros: uma sub-rede /24 que dá 30 ao POOL1, uma região (que contém o /16 em volta daquela sub-rede) que dá 20 ao POOL2 e um wildcard que dá 40 ao POOL2. Uma consulta vinda de dentro do /24 casa com os três. A ordenação põe o registro de sub-rede em primeiro, o de região em segundo e o wildcard por último. O POOL1 recebe 30 do registro de sub-rede; o POOL2 recebe 20 do registro de região, e o wildcard de 40 pontos fica sombreado, nunca é consultado. O POOL1 vence por 30 a 20, apesar de haver um 40 na lista. Apague o registro de região e a pontuação do POOL2 passa a vir do wildcard: 40 vence 30 e a resposta se inverte.

Como usar sem surpresas

Os hábitos operacionais saem direto da mecânica. Mantenha o conjunto de registros pequeno, prefira regiões a longas listas de sub-redes (a dica de eficiência do próprio manual) e evite origens sobrepostas para a mesma aplicação, porque é nas sobreposições que o sombreamento age sem ninguém perceber. Dê a todo registro intencional uma pontuação explícita; um registro criado sem pontuação fica com o peso padrão da , 1, o que quase nunca é a intenção num projeto com pesos. E, quando o Topology roda nos dois níveis, o wide IP escolhendo pools e os pools escolhendo membros, configure o método de fallback de cada pool como None, como manda o manual de Load Balancing: do contrário, uma requisição pode cair num pool sem membros disponíveis e acabar no (o resolver Berkeley Internet Name Domain), enquanto o None deixa o pool vazio passar a requisição para outro pool. O explicador do fluxo de decisão GSLB (global server load balancing) verifica essa combinação, e o pontuador longest-match de topologia GTM mostra a ordenação, as pontuações e o sombreamento de qualquer conjunto de registros que você colar.

As regras de ordenação, o modelo de atribuição de pontuações e os comportamentos demonstrados neste artigo valem para o BIG-IP DNS (antigo GTM, Global Traffic Manager) e vêm do capítulo Topology do manual BIG-IP GTM Load Balancing e do K10721 da F5, conforme os links da lista de fontes da ferramenta; a hierarquia está implementada exatamente até onde essas fontes a confirmam, e a ferramenta sinaliza, em vez de adivinhar, qualquer caso fora dela.