Resumo

  • A RFC 3532 exige que o particionamento dinâmico mantenha o estado existente de um elemento virtual ativo. Ela não obriga todo protocolo a notificar proativamente: o controlador pode descobrir a redução somente quando uma solicitação posterior falha e ele consulta os recursos disponíveis.
  • Uma cadeia verificável separa autoridade, cota anterior, uso corrente, liberação ou recusa, congelamento e drenagem, caminho de ciência, serviços entre partições e resultado da aplicação. “Reparticionamento concluído” não comprova o conjunto.

Uma reinicialização é ruim para continuidade, mas clara para quem audita: existe um antes e um depois visíveis. No particionamento estático descrito pela RFC 3532, controladores afetados são desconectados, o estado configurado em geral é liberado, o elemento virtual sai do ar e depois precisa ser reconstruído. O método dinâmico remove essa interrupção e mantém o estado da partição ativa.

Ao remover a quebra visível, ele não remove a transição. A sessão de controle pode sobreviver com um orçamento desatualizado. Entradas podem continuar instaladas enquanto filas, buffers, conexões ou banda se tornam mais escassos. Estado preservado é uma propriedade; capacidade preservada e resultado preservado são outras.

A RFC 3532 foi publicada em maio de 2003 como Informational e declara que não especifica padrão de Internet. É um documento de requisitos, não um protocolo completo. O foco principal é a divisão de switches GSMP. Para switches não GSMP e encaminhadores por maior prefixo, os requisitos podem ser necessários sem serem suficientes.

O inventário é uma fotografia do elemento, não do acordo entre as partes

O elemento de comutação, SE, encaminha pacotes e oferece recursos divisíveis. Uma partição, ou SE virtual, recebe um conjunto deles. Um controlador opera a partição ativa. O gerenciador de partições, PM, decide quantos elementos virtuais existem e o que cada um recebe.

Há pelo menos três diálogos. O PM determina a alocação com o SE. O controlador programa a partição. PM e controlador podem negociar uma mudança enquanto ela está ativa. Uma linha única dizendo “capacidade atualizada” apaga quem pediu, quem executou, quem utilizava e quem ficou sabendo.

Essas entidades são lógicas e podem estar na mesma máquina ou distribuídas. Separação lógica não prova isolamento físico, processo distinto ou domínio de falha independente. Colocação também não funde suas autoridades. O registro precisa ligar cada função ao principal de execução daquele momento.

O texto usa o exemplo de um proprietário que divide a infraestrutura e aluga o controle de elementos virtuais a terceiros. Isso não comprova contrato algum. Direito comercial, poder do PM, permissão do controlador e cota aplicada pelo SE são quatro afirmações separadas.

Recursos em uso não podem desaparecer para satisfazer a planilha

O SE deve impedir que um controlador use mais que a alocação atual. Essa regra faz valer o novo limite. Ela não autoriza apagar trabalho vivo para que uma redução pareça bem-sucedida.

Se o PM pede ao SE a liberação de recursos de uma partição ativa e qualquer recurso solicitado está em uso, o SE deve negar. A recusa é a resposta protetiva correta. Ela distingue capacidade ociosa, que pode mudar imediatamente, de capacidade ocupada, que exige coordenação.

Depois da recusa, o PM deveria congelar a partição, pedir que o controlador reduza o uso ou combinar as duas ações. Uma partição congelada entrega o que não usa, mantém conexões atuais e devolve recursos conforme elas terminam. Não está normal nem desligada. Está em drenagem.

Por isso, congelamento precisa de cronologia: pedido recusado, volume ocupado, início, contatos com o controlador, conexões encerradas, capacidade devolvida e condição de saída. Um simples campo verdadeiro ou falso não explica se o objetivo foi alcançado nem qual serviço permaneceu.

Se o controlador não liberar o suficiente, o PM pode recorrer ao desligamento virtual, tornando a partição inativa e desconectando seus controladores. Isso evita retenção permanente, mas interrompe. A cota obtida após um desligamento forçado não pode ser vendida como redução dinâmica sem impacto.

O erro posterior pode ser o primeiro aviso legítimo

Um protocolo pode oferecer notificação proativa: o SE informa assincronamente que houve realocação. É o caminho temporal mais claro, mas a RFC não o torna obrigatório para todos, pois exige notificação reativa.

Na forma reativa explícita, uma solicitação futura falha com erro que identifica recursos realocados. Na forma implícita, chega apenas erro genérico, desconhecido ou ligado a recurso. O controlador precisa então consultar a disponibilidade para concluir que a nova alocação causou a falta.

O PM também pode informar o controlador diretamente. Essa rota precisa de autenticação, entrega, recebimento e prova de atualização interna. Mensagem enviada não demonstra que o escalonador adotou a cota. Erro recebido não demonstra interpretação. Consulta ao SE demonstra somente o que ele respondeu naquele instante.

Quatro tempos devem ficar separados: aplicação da cota, chegada do sinal, adaptação do modelo e observação do serviço. O intervalo pode durar uma mensagem, até o próximo pedido, ou até o diagnóstico de um erro genérico. Nele, o SE pode impor corretamente o limite enquanto o controlador age de forma coerente com seu mapa antigo.

Automação deve guardar o caminho exato: aviso proativo, erro explícito, erro implícito mais consulta, ou contato direto. Depois liga versão do modelo, confirmação e nova tentativa do controlador. Sem essa segunda recepção, ciência é inferência.

Consultar todos os recursos ainda não fecha o resultado

O PM deve conseguir consultar recursos do SE, partições configuradas e alocação de cada uma. Para automatizar contato, deve descobrir no SE os endereços dos controladores conectados ao elemento virtual; protocolo e versão também podem ser conhecidos.

Esse inventário confirma o livro do SE e ajuda a achar o destinatário. Ele não confirma entrega de aviso, aceitação do novo orçamento, fim de pedidos excedentes ou continuidade do serviço.

Se o desejado pelo PM diverge do relatado pelo SE, há problema de aplicação ou reconciliação. Se coincidem e o controlador usa a cota antiga, há problema de ciência ou adaptação. Se os três concordam e o usuário falha, a investigação prossegue no plano de dados e na aplicação. Um alerta genérico de sincronismo não deve misturar os casos.

Toda consulta tem tempo e escopo. Identidade do SE, partição, esquema de recursos, valores, horário e hash da resposta devem ficar imutáveis. O inventário atual não reconstrói o que o controlador acreditava quando fez o pedido recusado.

Um serviço entre partições atravessa o limite administrativo

O SE pode oferecer serviço de um elemento virtual a outro, como enlace virtual. Deve expor quais serviços existem, e o PM deve poder configurá-los. Se a mudança adiciona ou remove porta virtual, o SE precisa notificar controladores quando o protocolo suporta isso.

Assim, uma alteração local no livro de cotas pode mudar uma dependência usada por outra partição. A segunda mantém sua própria alocação, mas pode perder porta ou capacidade no enlace. Não ser alvo direto não prova ausência de impacto no resultado.

A validação tem dois conjuntos. Partições representativas fora do impacto devem conservar alocação e identidade de processo. Serviços que cruzam a fronteira alterada precisam ser enumerados e testados. A primeira prova protege contra parada de toda a plataforma; a segunda impede que escopo mínimo ignore dependência real.

Compartilhar chassi, PM, protocolo ou arquivo de configuração não é motivo suficiente para reiniciar tudo. O impacto segue entradas executáveis alteradas, cotas, dependências diretas e migrações necessárias.

Autoridade para repartir não prova direito nem segurança

Somente PM autorizado pode repartir dinamicamente um SE. Deve haver processo seguro pelo qual uma entidade autorizada seleciona o PM controlador, de modo explícito ou por descoberta autorizada. Somente ele ou agente autorizado pode pedir redução ao controlador ou informar aumento.

No sentido inverso, o PM precisa autenticar que o pedido veio de controlador autorizado para o elemento virtual indicado. Isso impede que um ocupante tente redesenhar o orçamento de outro.

Autenticação responde quem apresentou credencial no processo de confiança. Autorização responde se ele pode executar a operação naquela partição. Nenhuma prova direito contratual, suficiência da capacidade, execução efetiva ou resultado.

A seleção do PM deve ser histórica. Se a autoridade muda, credencial válida hoje não legitima ordem antiga. Cada solicitação se liga à seleção, credencial, versão de política, partição e hash vigentes na decisão.

Documentos posteriores não tornam o inventário uma prova de implantação

RFC 3654 e RFC 3746 trataram depois de requisitos e estrutura para separar encaminhamento e controle. RFC 5810 e RFC 5812 especificaram protocolo e modelo ForCES; RFC 7121 tratou alta disponibilidade.

Esse contexto não transforma RFC 3532 em padrão, não cria recibo operacional ausente nem prova que determinado sistema usou ForCES. RFC 3654 e RFC 3746 são Informational; RFC 5810, RFC 5812 e RFC 7121 são Proposed Standard. Cada qual mantém data, estado e escopo.

Metadados, histórico e erratas identificam o documento. Não observam uma partição em execução. Linhagem arquitetural não é adoção.

Uma cadeia que impede o valor atual de apagar a transição

Primeiro registre SE, PM, controlador, partição, mapa físico, seleção do PM, credenciais, política e hash do pedido. Depois fixe recurso determinístico, cota anterior, uso observado e alvo.

Registre a decisão do SE distinguindo liberação do ocioso, recusa por uso, congelamento, liberação negociada e desligamento. Confirme o estado mantido e como o novo limite foi imposto.

Em seguida nomeie a ciência: aviso proativo, erro explícito, erro implícito com consulta ou contato direto. Anexe o modelo atualizado e a nova tentativa. O inventário final do SE complementa, não substitui, a confirmação do controlador.

Por fim teste serviços entre partições, partições não alteradas, capacidade do plano de dados e resultado de aplicação. O PM prova seu pedido; o SE, a cota; o controlador, seu modelo; o serviço, o comportamento; a aplicação, o resultado do usuário.

A frase executiva honesta é: “O gestor autorizado moveu estes recursos livres neste horário; o SE manteve estes estados; o controlador soube por este caminho e adotou este modelo; estas dependências e resultados foram então observados.” O que não foi medido deve continuar desconhecido.

Evidence boundary

Este Article não identifica implementação, fornecedor, operador, SE, PM, controlador, locatário, contrato, pool, partição, implantação, incidente, indisponibilidade, evento de segurança ou resultado de cliente. Não informa adoção atual, capacidade, utilização, perda, latência ou serviço.

A RFC 3532 é tratada como documento Informational de requisitos de maio de 2003, não padrão ou protocolo completo. Sua premissa determinística não se estende a agrupamento estatístico ou superalocação. Materiais GSMP, Megaco e ForCES posteriores mantêm estado próprio e não provam conformidade real.

As notas divulgadas de Heng Lu fornecem lente editorial: limitar autoridade à operação controlada e fechar resultados com evidência de código em execução. Não estabelecem intenção do IETF, comportamento de implementação ou fato de implantação.

A conclusão limitada é que uma partição ativa pode mudar sem reiniciar e o controlador só saber depois por notificação, erro, consulta ou contato. Estado preservado e inventário atualizado são necessários, mas não são resultado do serviço.

Sources