Resumo

  • RSerPool mantém um conjunto de Pool Elements elegíveis para novas seleções. RFC 3237 exige que um elemento desregistrado possa continuar servindo conexões iniciadas antes da retirada. Estado de membresia e trabalho ativo seguem relógios diferentes.
  • RFC 5351 ajuda a descobrir outro servidor e oferece mecanismos opcionais de cookie e business card. Nenhum deles decide se uma operação antiga foi confirmada, se o estado transferido é suficiente ou se repetir a solicitação é seguro.
  • Uma drenagem verificável precisa separar elegibilidade, readiness, sessões antigas, commit, replicação, identidade, retry e resultado. Usar apenas a presença no handlespace produz desligamentos prematuros e recuperações fictícias.

A retirada correta produzia um estado intermediário

Um pool é um conjunto de servidores que oferece a mesma função de aplicação. Cada Pool Element registra sua presença via ASAP; Pool Users resolvem o handle por um servidor ENRP e recebem candidatos.

O modelo de requisitos não reduz a vida do elemento a “dentro” e “fora”. Depois do desregistro, ele deixa de receber novas conexões, mas continua atendendo as que já existiam. O objetivo é evitar interrupção durante manutenção, substituição ou redução de capacidade.

Esse estado intermediário precisa existir também na operação. O handlespace responde quem pode ser selecionado agora. Ele não enumera necessariamente toda sessão que ainda executa em um elemento retirado.

Uma automação que encerra o processo assim que o registro desaparece contradiz o significado da drenagem. Para provar término seguro, é preciso contar sessões, identificar operações em fase crítica, esperar seus recibos ou transferi-las segundo uma regra da aplicação.

Registrar cedo demais era o erro simétrico

Se desregistro não significa vazio, registro não significa pronto para toda carga. Um elemento pode anunciar o endereço antes de terminar a replicação, aquecer caches, carregar chaves ou aplicar políticas de tenant.

RSerPool registra transporte, política de seleção, identificador e tempo de vida. O protocolo de aplicação entre Pool User e Pool Element permanece específico e é configurado separadamente.

A organização precisa de um gate de readiness acima da membresia. Esse gate pode exigir versão correta, estado mínimo de replicação, acesso ao armazenamento, material criptográfico e teste de uma operação representativa.

Sem essa separação, o rollout alterna dois riscos: registra cedo e envia solicitações a um processo ainda incompleto; ou remove e mata cedo, destruindo sessões que deveriam terminar.

O handle tinha escopo, não soberania global

RFC 5351 descreve o pool handle como uma cadeia de bytes única num handlespace plano de escopo operacional limitado. A administração de handles não era tratada. RFC 3237 exige outros mecanismos para interoperar entre espaços.

Uma resolução bem-sucedida prova que o escopo consultado reconhece o nome. Não prova que outra organização usa a mesma semântica, que o endereço pertence à mesma jurisdição ou que o usuário está autorizado.

Esse limite é particularmente importante em disaster recovery. Levar o mesmo texto de handle a outro domínio não transporta automaticamente confiança, dados, chaves ou consentimento. O escopo deve aparecer no registro e na interface.

A coordenação mínima funciona porque não tenta governar toda a aplicação. O problema surge quando um nome local é apresentado como certificado global de serviço equivalente.

A sincronização do ENRP não esvaziava o processo

Servidores ENRP trocam alterações, comparam checksums e ressincronizam partes do handlespace. Na falha de um Home ENRP, os pares negociam takeover. O registro distribuído evita um ponto único de falha.

Essa sincronização não observa memória da aplicação, filas internas nem transações em andamento. Todos os ENRP podem concordar que o elemento saiu enquanto milhares de sessões antigas permanecem corretamente nele.

Também há atraso inevitável. Um membro pode cair após responder ao keep-alive. Uma baixa pode estar em propagação. RFC 5352 admite cache com stale timer e uso de entradas ainda consideradas recentes.

O relatório de manutenção deve, portanto, combinar recibos: desregistro aceito, propagação observada, novas seleções zeradas, sessões antigas drenadas, commits finais persistidos e resultado externo confirmado.

A seleção escolhia o próximo, não resolvia o anterior

Round Robin, Random, Priority e políticas de carga determinam o próximo candidato. RFC 5356 exige uma definição comum de carga no pool, mas deixa seu significado para a aplicação.

Uma política pode escolher perfeitamente o menor valor e ainda enviar a sessão para um elemento sem o estado necessário. O “melhor” nó para trabalho novo pode ser o pior para recuperar trabalho antigo.

O exemplo de RFC 5351 usa algo como GETNEXTSERVER: informa que o candidato anterior falhou e recebe outro segundo a melhor informação disponível. Essa operação não revela se a solicitação anterior não começou, estava em curso ou foi confirmada sem resposta.

A fila, pagamento ou alteração de política exige ID de operação e fronteira de commit. Sem eles, repetir no novo elemento pode criar duplicação. Resolver o próximo servidor é apenas um passo da recuperação.

O cookie carregava estado sem explicar sua suficiência

Um Pool Element pode enviar um cookie; o usuário conserva o último e o apresenta ao novo elemento. Para o usuário, o conteúdo é opaco. A assinatura recomendada protege origem e integridade, e RFC 5352 deixa os detalhes de verificação fora do escopo.

O último cookie recebido pode anteceder a última transação confirmada. Pode pertencer a uma versão incompatível ou não conter autorização atual. Assinatura válida não transforma conteúdo antigo em estado completo.

Cookie e business card não são capacidades obrigatórias uniformes em todos os papéis. A equipe não pode inferir state transfer só porque o elemento participa do pool.

Cada aplicação deve declarar dono do esquema, versão, validade, momento de emissão, significado de commit, chave, rotação e comportamento diante de incompatibilidade. O mecanismo comum transporta bytes; a aplicação decide se eles restauram algo.

A business card era uma preferência, não uma prova

O elemento pode sugerir outro membro para failover, talvez por carga ou por acreditar que ele tem estado mais atualizado. Isso ajuda a ordenar a busca.

Mas a recomendação envelhece. O destino pode falhar, atrasar a réplica ou não aceitar aquele principal. O critério de “next best” pode diferir do requisito de recuperação.

Preservar a provenance evita inflar a mensagem: “recomendado pelo elemento antigo às 14:03” é auditável; “destino de recuperação garantido” exigiria contato, autenticação, versão e estado verificados.

O conselho pode ser usado sem virar autoridade. Essa é uma distinção pequena na interface e grande no risco.

SCTP mantinha um caminho diferente de manter uma sessão

SCTP oferece multihoming e monitoramento de caminho. Uma associação pode usar outro endereço do mesmo endpoint. RFC 9260 substituiu RFC 4960 e preserva essa distinção de transporte.

Trocar para outro Pool Element cruza um limite maior. O novo processo pode ter memória, armazenamento e contexto de segurança diferentes. Path failover não equivale a server failover; server failover não equivale a session recovery.

A telemetria precisa nomear cada evento. “Failover” sem camada faz um gráfico parecer bom enquanto sessões foram reiniciadas, operações repetidas ou autoridade perdida.

Para exatamente-uma-vez, o elemento novo precisa reconhecer o mesmo identificador e consultar estado durável, ou a aplicação precisa compensar. Nenhuma propriedade do caminho SCTP cria isso por si.

A segurança do pool não herdava a autorização do usuário

RFC 5355 documenta inscrições falsas, ENRP malicioso, resolução adulterada, replay e DoS. Autenticação mútua e autorização protegem o mapa de membros, usando TLS e PSK no modelo de um domínio administrativo.

Essas garantias dizem quem pode participar da infraestrutura. Não dizem quem pode executar uma operação de negócio no novo elemento. O principal da aplicação deve ser autenticado e autorizado novamente quando necessário.

RFC 3237 deixa compartilhamento de contexto de segurança fora do escopo. Uma conexão segura nova não prova continuidade da autoridade antiga. Estado de sessão, revogação e restrição regional continuam locais à aplicação.

Disponibilidade não pode se tornar exceção de acesso. Os mesmos controles devem ser aplicados durante failover, quando a pressão por rapidez costuma ser maior.

Dez recibos definem uma drenagem real

O handle existe no escopo; o elemento consta da visão; a política o seleciona; o transporte o alcança; a aplicação e o principal são aceitos; o estado da operação antiga é conhecido; o estado transferido é autêntico, fresco, completo e compatível; o retry é seguro; o efeito é persistido; o resultado externo é confirmado.

Na retirada, acrescenta-se a prova de que novas seleções cessaram e sessões antigas terminaram. O desregistro é necessário, mas não encerra o conjunto.

IANA mantém tipos de mensagem, parâmetros, erros e políticas RSerPool. Esse registro prova coordenação de símbolos, não implantação ou saúde atual.

As notas de Lu Heng sobre especificação mínima e camadas de realidade oferecem lentes declaradas: membresia é estado simbólico; sessão e resultado são estado operacional. Os fatos vêm dos RFCs e da IANA.