Arquitetura do cluster: Control Plane e User Plane
Dentro do cluster, os componentes são divididos entre o Control Plane e o User Plane.
O User Plane executa as funções de processamento de tráfego: recebimento, processamento e encaminhamento do tráfego dos assinantes.
Uma das principais funções do User Plane é o DPI — um sistema de classificação de tráfego por sessões e aplicações. Os nós DPI recebem pacotes, processam conexões, aplicam as políticas necessárias e coletam estatísticas de consumo dos assinantes. São esses nós que são adicionados quando é necessário aumentar a capacidade ou retirados de operação para manutenção.
Figura 1 — Arquitetura do cluster
O Control Plane armazena o estado das sessões dos assinantes e atribui o User Plane. Com base no número de nós ativos, ele determina qual nó atende um determinado assinante, quais parâmetros e serviços estão associados a esse assinante e realiza a migração da sessão quando essa atribuição muda.
O requisito do qual todo o resto decorre
Vamos começar não pelo escalonamento em si, mas pela restrição que o torna mais complexo.
A classificação de tráfego e a contabilização por serviço exigem que as duas direções de uma conexão sejam processadas pelo mesmo nó DPI (User Plane).
Além disso, a unidade de serviço não é um endereço IP individual nem mesmo uma única conexão. Um assinante pode usar vários serviços simultaneamente, ter várias conexões, usar IPv4 e IPv6 ou compartilhar o acesso à internet com outros dispositivos. Portanto, um assinante pode ter várias conexões e endereços, mas, do ponto de vista do serviço, eles pertencem a uma única sessão de serviço. Essa sessão se torna a unidade de escalonamento: todas as conexões associadas ao assinante precisam ser processadas em conjunto pelo mesmo nó de processamento de tráfego e pelo mesmo nó de controle.
A unidade de escalonamento não é um fluxo, um endereço ou uma conexão individual, mas a própria sessão de serviço, juntamente com todos os seus parâmetros: conexões, endereços IPv4 e IPv6, plano tarifário, franquia e dados de contabilização. Essa é a unidade de distribuição e ela não pode ser dividida entre nós.
Figura 2 — Sessão de serviço: todas as conexões e endereços de um assinante formam uma única unidade de serviço
Se os pacotes pertencentes à mesma conexão TCP chegarem a nós diferentes, isso pode causar a interrupção da conexão, a perda do contexto de classificação e a divisão de uma única sessão entre vários nós para a contabilização do tráfego.
Isso fica especialmente claro no caso do NAT. Se a tradução de endereço e porta estiver armazenada no nó antigo enquanto o próximo pacote chegar a um novo nó, o novo nó não encontrará a entrada correspondente e o tráfego será descartado. Para uma conexão estabelecida, isso resultará em uma interrupção.
Duas formas de distribuir assinantes entre os nós e as diferenças entre elas
Como distribuir novas sessões entre os nós de modo que os pacotes de cada sessão específica sempre cheguem ao mesmo nó?
Hashing por identificador do assinante
Uma abordagem comum e eficaz é calcular um hash com base no par IMSI/APN da sessão PDN do assinante. Pegamos o identificador do assinante, IMSI+APN, calculamos seu hash, comparamos o resultado com a lista de nós ativos e obtemos o número do nó para o qual a sessão deve ser enviada. Como um assinante possui um único IMSI, todas as suas sessões dentro do mesmo APN, independentemente do endereço IP utilizado (IPv4 ou IPv6), são direcionadas ao mesmo nó de processamento. Essa abordagem não exige sincronização de estado entre os nós: desde que cada nó tenha as mesmas informações sobre a composição do cluster, cada um calcula de forma independente o mesmo hash e o mesmo número de nó.
Quando um novo nó é adicionado, um algoritmo como Maglev ou Randevu reconstrói a distribuição para que o roteamento mude apenas para uma parcela mínima dos assinantes — aproximadamente 1/(N+1) do total quando o cluster cresce de N para N+1 nós. Os demais continuam sendo atendidos pelos mesmos nós.
Mas há também uma limitação fundamental: o algoritmo não leva em consideração o estado atual de uma sessão no nó.
Assim que um novo nó é adicionado ao cluster, o resultado do hash muda para alguns assinantes. O algoritmo direciona suas novas conexões para outro nó. Ao mesmo tempo, o nó anterior ainda pode conter o contexto de serviço desses assinantes: informações sobre conexões, contadores de consumo e outros dados necessários para processar as sessões atuais. O novo nó ainda não possui esse estado. Se a nova distribuição for aplicada imediatamente, as sessões ativas acabarão em nós que não possuem seu contexto. Portanto, não basta garantir que cada conexão individual chegue ao nó correto. O contexto associado ao assinante também precisa permanecer íntegro.
Posicionamento inicial e migração controlada
O hashing resolve apenas uma parte do problema: a distribuição inicial. A próxima pergunta é: “O que fazer com as sessões que já estão ativas?” Para resolver esse problema, é útil separar dois processos: o posicionamento inicial das novas sessões e a migração controlada das sessões existentes.
Migração controlada
O hashing continua sendo usado para novas sessões — ele distribui a carga de forma rápida e uniforme e também funciona como mecanismo de fallback caso o Control Plane fique temporariamente indisponível. Já as sessões ativas precisam de um mecanismo separado que permita redistribuí-las gradualmente.
Isso é feito pelo PCEF, um componente do Control Plane. Quando o número de nós DPI muda, o PCEF percorre todas as suas sessões. Para cada uma delas, compara a atribuição atual ao nó com a atribuição de destino calculada usando hashing consistente com base no novo número de nós. Se forem diferentes, o PCEF direciona a sessão para o nó de destino. É assim que uma migração gradual do User Plane é implementada.
Portanto, quando um novo nó de processamento de tráfego é adicionado, o Control Plane não precisa recalcular todo o sistema do zero. Em vez disso, pode selecionar sessões específicas para migração.
O escalonamento do próprio Control Plane — ou seja, das instâncias do PCEF — funciona de maneira semelhante. Quando o número de instâncias aumenta, cada PCEF ativo percorre as sessões que atende atualmente e libera aquelas que, de acordo com o novo hash, devem pertencer à instância recém-adicionada. Se o número de instâncias do PCEF diminuir — por exemplo, porque uma instância falhou —, as instâncias restantes percorrem não apenas suas próprias sessões, mas todas as sessões no armazenamento compartilhado. Elas identificam as sessões que ficaram sem proprietário e assumem aquelas que, de acordo com o hash atual, agora pertencem a elas.
Figura 3 — Duas formas de distribuir sessões de assinantes entre os nós
Por exemplo, um operador adiciona um novo nó DPI. As novas conexões começam imediatamente a ser atribuídas a ele. Em seguida, o Control Plane seleciona gradualmente algumas sessões ativas e as transfere dos nós sobrecarregados. Depois que o estado é preparado, a atribuição é alterada e o tráfego subsequente segue a nova rota.
Para o assinante, nada muda fundamentalmente: a chamada de vídeo continua, o download de um arquivo não precisa começar novamente e os dados de contabilização acumulados são preservados.
O próprio balanceador de carga do UP não toma a decisão de redistribuição. Ele recebe o comando, prepara o estado da sessão e continua o processamento após a mudança. Essa é uma diferença fundamental em relação a uma arquitetura na qual cada nó calcula sua atribuição de forma independente usando um hash.
Isso cria uma separação clara de funções: o Control Plane calcula a atribuição de destino e realiza a migração, enquanto o User Plane processa o tráfego de acordo com essa atribuição.
Mais informações sobre o Control Plane e o User Plane estão disponíveis no artigo — CUPS para PCEF/PGW: por que separar o Control Plane e o User Plane no núcleo móvel.
O custo do controle
Para que a migração controlada funcione corretamente, é necessário garantir a consistência dos dados usados pelo PCEF para tomar decisões, controlar a velocidade da migração e lidar com sessões cujo estado não pode ser migrado com segurança, como no caso do NAT.
Consistência das informações sobre os nós
Os nós do User Plane não calculam as atribuições por conta própria — eles as recebem do Control Plane e as aplicam durante o processamento do tráfego. Portanto, é importante garantir que cada nó esteja realmente trabalhando com a versão atualizada.
Sempre que o número de nós muda, o PCEF calcula o nó de destino para cada sessão com base no novo número de nós DPI, obtido do Consul. Se houver várias instâncias do PCEF no cluster, é importante que todas vejam o mesmo número de nós ao mesmo tempo. Caso contrário, diferentes instâncias do PCEF podem calcular nós de destino diferentes para a mesma sessão, e a distribuição deixará de ser consistente.
A migração leva tempo
A migração de uma única sessão leva uma fração de segundo, mas pode haver milhões de sessões, e elas precisam ser migradas sequencialmente, e não todas de uma vez. A migração leva tempo, mas as sessões ativas não são interrompidas.
Nem tudo pode ser migrado
Por fim, nem todas as sessões podem ser migradas da mesma forma. Algumas partes de seu estado podem ser copiadas com segurança para outro nó, enquanto outras estão fortemente vinculadas ao hardware específico no qual a sessão foi criada. O NAT é um desses casos: a entrada de tradução de endereço e porta existe apenas na memória de um nó específico e não pode ser simplesmente recriada em outro nó sem o risco de perder conexões já estabelecidas.
Essas sessões são tratadas de outra forma — não por meio de migração, mas por encerramento natural: o nó deixa de aceitar novas sessões, enquanto as existentes continuam sendo atendidas nele até seu encerramento natural.
Como verificar se funciona: três critérios mensuráveis
Tudo o que foi descrito acima — hashing baseado em IMSI e migração controlada — existe para garantir três propriedades específicas que podem ser medidas no tráfego real, em vez de simplesmente declaradas.
| Propriedade | Como verificar | Se a propriedade for violada |
| As duas direções da sessão no mesmo nó | Verificar se o tráfego de entrada e saída da mesma sessão é processado no mesmo nó | A contabilização e a classificação por serviço podem ficar incompletas |
| Migração sem perda de pacotes | Verificar se o tráfego continua sem interrupção enquanto a sessão é migrada | O assinante pode perceber uma interrupção na conexão |
| Migração sem perda de contabilização | Verificar se o volume total contabilizado no nó original e no novo nó corresponde ao consumo real | Um erro de contabilização pode ser detectado apenas quando o relatório final é gerado |
A terceira propriedade merece atenção especial. Durante a migração controlada, o nó original envia os dados finais de consumo antes que a sessão seja concluída. O Control Plane combina esses dados com os dados do novo nó e ajusta o limite de consumo. Dessa forma, os dados não são perdidos nem contabilizados duas vezes.
Ao mesmo tempo, não é necessário fechar e reabrir a sessão de cobrança. O assinante continua usando o serviço sem interrupção, enquanto a contabilização do consumo continua considerando os dados dos dois nós.
O que essa abordagem de escalonamento proporciona
A principal vantagem dessa abordagem é que o operador pode alterar a composição da infraestrutura sem uma redistribuição massiva das sessões ativas. Um novo nó pode ser usado imediatamente para novas conexões, enquanto as sessões existentes podem ser migradas gradualmente conforme necessário.
Isso gera vários efeitos práticos:
- A capacidade pode ser aumentada sem colocar a rede offline. O novo nó começa a aceitar conexões imediatamente, enquanto as sessões ativas são migradas em segundo plano.
- A carga é redistribuída de forma seletiva. Um nó sobrecarregado é aliviado exatamente na medida necessária, em vez de passar por um recálculo completo das conexões.
- O estado do assinante permanece íntegro. Conexões, endereços, plano tarifário, franquia e contabilização por serviço permanecem associados ao assinante, em vez de serem divididos entre vários nós.
- A manutenção planejada não se transforma em uma comutação de emergência. Quando um nó é retirado de operação, suas sessões podem ser migradas previamente para outros nós, em vez de interromper todas as conexões ao mesmo tempo.
O crescimento da rede é medido em terabits, enquanto o resultado do escalonamento é percebido no nível de uma conexão individual. Uma arquitetura na qual a unidade de distribuição não é um fluxo nem mesmo uma sessão individual, mas o assinante junto com tudo o que está associado a ele, simplesmente não permite ignorar esse requisito na etapa de projeto.
