Arquitectura del clúster: Control Plane y User Plane
Dentro del clúster, los componentes se dividen entre el Control Plane y el User Plane.
El User Plane realiza las funciones de procesamiento del tráfico: recepción, procesamiento y transmisión del tráfico de los abonados.
Una de las funciones clave del User Plane es el DPI, un sistema de clasificación del tráfico por sesiones y aplicaciones. Los nodos DPI reciben paquetes, procesan conexiones, aplican las políticas necesarias y recopilan estadísticas de consumo de los abonados. Estos son los nodos que se añaden cuando es necesario aumentar la capacidad o que se retiran del servicio para realizar tareas de mantenimiento.
Figura 1 — Arquitectura del clúster
El Control Plane almacena el estado de las sesiones de los abonados y asigna el User Plane. En función del número de nodos activos, determina qué nodo atiende a un abonado concreto, qué parámetros y servicios están asociados a él y realiza la migración de la sesión cuando cambia esta asignación.
El requisito del que se deriva todo lo demás
Empecemos no por la escalabilidad en sí, sino por la limitación que la hace más compleja.
La clasificación del tráfico y la tarificación por servicio requieren que ambas direcciones de una conexión sean procesadas por el mismo nodo DPI (User Plane).
Además, la unidad de servicio no es una dirección IP individual ni siquiera una conexión concreta. Un abonado puede utilizar varios servicios simultáneamente, tener varias conexiones, utilizar IPv4 y IPv6 o compartir el acceso a Internet con otros dispositivos. Por lo tanto, un abonado puede tener varias conexiones y direcciones, pero desde el punto de vista del servicio todas pertenecen a una única sesión de servicio. Esta sesión se convierte en la unidad de escalabilidad: todas las conexiones asociadas al abonado deben procesarse conjuntamente por el mismo nodo de procesamiento de tráfico y el mismo nodo de control.
La unidad de escalabilidad no es un flujo, una dirección ni una conexión individual, sino la propia sesión de servicio junto con todos sus parámetros: conexiones, direcciones IPv4 e IPv6, plan tarifario, cuota y datos de tarificación. Esta es la unidad de distribución y no puede dividirse entre varios nodos.
Figura 2 — Sesión de servicio: todas las conexiones y direcciones de un abonado forman una única unidad de servicio
Si los paquetes pertenecientes a la misma conexión TCP llegan a nodos diferentes, esto puede provocar la interrupción de la conexión, la pérdida del contexto de clasificación y la división de una misma sesión entre varios nodos para la tarificación del tráfico.
Esto resulta especialmente evidente en el caso de NAT. Si la traducción de dirección y puerto se almacena en el nodo anterior mientras el siguiente paquete llega a un nodo nuevo, el nuevo nodo no encontrará la entrada correspondiente y el tráfico será descartado. En una conexión establecida, esto provocará una interrupción.
Dos formas de distribuir los abonados entre los nodos y en qué se diferencian
¿Cómo distribuir las nuevas sesiones entre los nodos de modo que los paquetes de cada sesión concreta siempre lleguen al mismo nodo?
Hashing por identificador de abonado
Uno de los métodos habituales y eficaces consiste en calcular un hash a partir del par IMSI/APN de la sesión PDN del abonado. Tomamos el identificador del abonado, IMSI+APN, calculamos su hash, comparamos el resultado con la lista de nodos activos y obtenemos el número del nodo al que debe enviarse la sesión. Como un abonado tiene un único IMSI, todas sus sesiones dentro del mismo APN, independientemente de la dirección IP utilizada (IPv4 o IPv6), se dirigen al mismo nodo de procesamiento. Este método no requiere sincronizar el estado entre los nodos: siempre que cada uno tenga la misma información sobre la composición del clúster, todos calculan de forma independiente el mismo hash y el mismo número de nodo.
Cuando se añade un nuevo nodo, un algoritmo como Maglev o Randevu reconstruye la distribución de modo que el enrutamiento cambie solo para una parte mínima de los abonados: aproximadamente 1/(N+1) del total cuando el clúster crece de N a N+1 nodos. El resto continúa siendo atendido por los mismos nodos.
Pero este método también tiene una limitación fundamental: el algoritmo no tiene en cuenta el estado actual de la sesión en el nodo.
En cuanto se añade un nuevo nodo al clúster, el resultado del hash cambia para algunos abonados. El algoritmo dirige sus nuevas conexiones a otro nodo. Al mismo tiempo, el nodo anterior puede seguir teniendo el contexto de servicio de estos abonados: información sobre las conexiones, contadores de consumo y otros datos necesarios para procesar las sesiones actuales. El nuevo nodo todavía no dispone de este estado. Si la nueva distribución se aplica inmediatamente, las sesiones activas terminarán en nodos que no tienen su contexto. Por lo tanto, no basta con garantizar que cada conexión individual llegue al nodo correcto. El contexto asociado al abonado también debe mantenerse íntegro.
Asignación inicial y migración controlada
El hashing resuelve solo una parte del problema: la distribución inicial. La siguiente pregunta es: «¿Qué hacer con las sesiones que ya están activas?». Para resolver este problema, conviene separar dos procesos: la asignación inicial de las nuevas sesiones y la migración controlada de las ya existentes.
Migración controlada
El hashing se sigue utilizando para las nuevas sesiones: distribuye la carga de forma rápida y uniforme y, al mismo tiempo, sirve como mecanismo de respaldo si el Control Plane deja de estar disponible temporalmente. Sin embargo, las sesiones activas requieren un mecanismo independiente que permita redistribuirlas gradualmente.
De esto se encarga PCEF, un componente del Control Plane. Cuando cambia el número de nodos DPI, PCEF recorre todas sus sesiones. Para cada una, compara la asignación actual al nodo con la asignación objetivo calculada mediante hashing consistente teniendo en cuenta el nuevo número de nodos. Si son diferentes, PCEF cambia la sesión al nodo objetivo. Así se implementa una migración gradual del User Plane.
Por lo tanto, cuando se añade un nuevo nodo de procesamiento de tráfico, el Control Plane no necesita recalcular todo el sistema desde cero. En su lugar, puede seleccionar sesiones concretas para la migración.
La escalabilidad del propio Control Plane —es decir, de las instancias de PCEF— funciona de forma similar. Cuando aumenta su número, cada PCEF activo recorre las sesiones que atiende actualmente y libera aquellas que, según el nuevo hash, deberían pertenecer ahora a la instancia recién añadida. Si el número de instancias de PCEF disminuye, por ejemplo, porque una de ellas falla, las instancias restantes recorren no solo sus propias sesiones, sino todas las sesiones almacenadas en el almacenamiento compartido. Identifican las que han quedado sin propietario y asumen aquellas que, según el hash actual, ahora les corresponden.
Figura 3 — Dos formas de distribuir las sesiones de los abonados entre los nodos
Por ejemplo, un operador añade un nuevo nodo DPI. Las nuevas conexiones comienzan a asignarse a él inmediatamente. A continuación, el Control Plane selecciona gradualmente algunas sesiones activas y las traslada desde los nodos sobrecargados. Una vez preparado el estado, se cambia la asignación y el tráfico posterior sigue la nueva ruta.
Para el abonado, nada cambia en lo fundamental: la videollamada continúa, la descarga de un archivo no tiene que comenzar de nuevo y los datos de tarificación acumulados se conservan.
El propio balanceador de carga de salida del UP (UP load balancer) no toma la decisión sobre la redistribución. Recibe la orden, prepara el estado de la sesión y continúa procesándola después del cambio. Esta es una diferencia fundamental con una arquitectura en la que cada nodo calcula de forma independiente su asignación mediante un hash.
De este modo, las funciones quedan claramente separadas: el Control Plane calcula la asignación objetivo y realiza la migración, mientras que el User Plane procesa el tráfico de acuerdo con dicha asignación.
Más información sobre el Control Plane y el User Plane en el artículo — CUPS para PCEF/PGW: por qué separar el Control Plane y el User Plane en el núcleo móvil.
El coste del control
Para que la migración controlada funcione correctamente, es necesario garantizar la coherencia de los datos que PCEF utiliza para tomar decisiones, controlar la velocidad de migración y gestionar las sesiones cuyo estado no puede migrarse de forma segura, como ocurre con NAT.
Coherencia de la información sobre los nodos
Los nodos del User Plane no calculan las asignaciones por sí mismos: las reciben del Control Plane y las aplican al procesar el tráfico. Por eso es importante garantizar que cada nodo trabaje realmente con la versión actualizada.
Cada vez que cambia el número de nodos, PCEF calcula el nodo objetivo para cada sesión basándose en el nuevo número de nodos DPI, que obtiene de Consul. Si hay varias instancias de PCEF en el clúster, es importante que todas vean el mismo número de nodos en el mismo momento. De lo contrario, diferentes instancias de PCEF pueden calcular distintos nodos objetivo para una misma sesión y la distribución dejará de ser coherente.
La migración requiere tiempo
Migrar una sola sesión lleva una fracción de segundo, pero puede haber millones de sesiones y es necesario migrarlas de forma secuencial, no todas a la vez. La migración requiere tiempo, pero las sesiones activas no se interrumpen.
No todo se puede migrar
Por último, no todas las sesiones son igual de fáciles de migrar. Algunas partes de su estado pueden copiarse de forma segura a otro nodo, mientras que otras están estrechamente vinculadas al hardware concreto en el que se creó la sesión. NAT es uno de estos casos: la entrada de traducción de dirección y puerto existe únicamente en la memoria de un nodo concreto y no puede recrearse simplemente en otro nodo sin riesgo de perder conexiones ya establecidas.
Estas sesiones se gestionan de otra manera: no mediante una migración, sino mediante una finalización natural. El nodo deja de aceptar nuevas sesiones, mientras que las existentes continúan siendo atendidas en él hasta que finalizan de forma natural.
Cómo comprobar que funciona: tres criterios medibles
Todo lo descrito anteriormente —el hashing basado en IMSI y la migración controlada— existe para garantizar tres propiedades concretas que pueden medirse sobre tráfico real, en lugar de limitarse a declararlas.
| Propiedad | Cómo se comprueba | Si no se cumple |
| Ambas direcciones de la sesión en el mismo nodo | Se comprueba si el tráfico entrante y saliente de una misma sesión se procesa en el mismo nodo | La tarificación y la clasificación por servicio pueden ser incompletas |
| Migración sin pérdida de paquetes | Se comprueba si el tráfico continúa sin interrupciones mientras se migra la sesión | El abonado puede experimentar una interrupción de la conexión |
| Migración sin pérdida de datos de tarificación | Se comprueba si el volumen total de datos contabilizados en el nodo original y en el nuevo coincide con el consumo real | Un error de tarificación puede detectarse solo al generar el informe final |
La tercera propiedad merece una atención especial. Durante la migración controlada, el nodo original envía los datos finales de consumo antes de que finalice la sesión. El Control Plane los combina con los datos del nuevo nodo y ajusta el umbral de consumo. De esta forma, los datos no se pierden ni se contabilizan dos veces.
Al mismo tiempo, no es necesario cerrar y volver a abrir la sesión de tarificación. El abonado continúa utilizando el servicio sin interrupciones y el consumo sigue contabilizándose teniendo en cuenta los datos de ambos nodos.
Qué aporta este enfoque de escalabilidad
La principal ventaja de este enfoque es que el operador puede cambiar la composición de la infraestructura sin una redistribución masiva de las sesiones activas. Un nuevo nodo puede utilizarse inmediatamente para las nuevas conexiones, mientras que las sesiones existentes pueden migrarse gradualmente según sea necesario.
Esto produce varios efectos prácticos:
- La capacidad puede aumentarse sin detener la red. El nuevo nodo comienza a aceptar conexiones inmediatamente, mientras que las sesiones activas se migran en segundo plano.
- La carga se redistribuye de forma selectiva. Un nodo sobrecargado se descarga exactamente en la medida necesaria, en lugar de recalcular todas las conexiones.
- El estado del abonado se mantiene íntegro. Las conexiones, direcciones, plan tarifario, cuota y tarificación por servicio permanecen asociadas al abonado en lugar de dividirse entre varios nodos.
- Los trabajos de mantenimiento planificados no se convierten en conmutaciones de emergencia. Cuando un nodo se retira del servicio, sus sesiones pueden migrarse previamente a otros nodos en lugar de interrumpir todas las conexiones al mismo tiempo.
El crecimiento de la red se mide en terabits, mientras que el resultado de la escalabilidad se percibe a nivel de una conexión individual. Una arquitectura en la que la unidad de distribución no es un flujo ni siquiera una sesión individual, sino el abonado junto con todo lo asociado a él, simplemente no permite pasar por alto este requisito en la fase de diseño.
