O seguimento de conexións ("conntrack") é unha característica principal da pila de rede do núcleo de Linux. Permite que o núcleo faga un seguimento de todas as conexións ou fluxos de rede lóxicas e, así, identifique todos os paquetes que compoñen cada fluxo para que poidan ser procesados xuntos de forma secuencial.
Conntrack é unha característica importante do núcleo que se usa nalgúns casos básicos:
- NAT depende da información de conntrack polo que pode tratar todos os paquetes do mesmo fluxo por igual. Por exemplo, cando un pod accede a un servizo de Kubernetes, o equilibrador de carga kube-proxy usa NAT para dirixir o tráfico a un pod específico dentro do clúster. Conntrack rexistra que para unha determinada conexión, todos os paquetes ao servizo IP deben enviarse ao mesmo pod e que os paquetes devoltos polo pod de backend deben ser NAT de volta ao pod do que procedeu a solicitude.
- Os firewalls con estado como Calico confían na información de connecttrack para o tráfico de "resposta" na lista branca. Isto permítelle escribir unha política de rede que di "permitir que o meu pod se conecte a calquera enderezo IP remoto" sen ter que escribir unha política para permitir explícitamente o tráfico de resposta. (Sen isto, terías que engadir a regra moito menos segura de "permitir paquetes ao meu pod desde calquera IP".)
Ademais, conntrack adoita mellorar o rendemento do sistema (ao reducir o consumo de CPU e a latencia dos paquetes) xa que só o primeiro paquete dun fluxo
debe pasar por toda a pila de rede para determinar que facer con ela. Mira a publicación "" para ver un exemplo de como funciona isto.
Non obstante, conttrack ten as súas limitacións...
Entón, onde foi todo mal?
A táboa conntrack ten un tamaño máximo configurable e, se se chea, as conexións normalmente comezan a ser rexeitadas ou eliminadas. Hai espazo libre suficiente na táboa para xestionar o tráfico da maioría das aplicacións, e isto nunca se converterá nun problema. Non obstante, hai algúns escenarios nos que pode querer considerar o uso da táboa conntrack:
- O caso máis obvio é se o teu servidor manexa un número extremadamente grande de conexións activas simultáneamente. Por exemplo, se a súa táboa conntrack está configurada para 128k entradas, pero tes >128k conexións simultáneas, seguramente terás un problema.
- Un caso un pouco menos obvio: se o teu servidor procesa un número moi grande de conexións por segundo. Aínda que as conexións sexan de curta duración, Linux seguen sendo monitorizadas durante algún período de tempo (120 segundos por defecto). Por exemplo, se a túa táboa conntrack está configurada para 128k entradas e estás tentando xestionar 1100 conexións por segundo, superarán o tamaño da táboa conntrack aínda que as conexións sexan moi curtas (128k/120s = 1092 conexións/s). ).
Hai varios tipos de nichos de aplicacións que entran nestas categorías. Ademais, se tes moitos actores malos, encher a táboa de conexións do teu servidor con moitas conexións semiabertas podería usarse como parte dun ataque de denegación de servizo (DOS). En ambos os casos, conntrack pode converterse nun pescozo de botella limitante no seu sistema. Nalgúns casos, axustar os parámetros da táboa de conntrack pode ser suficiente para satisfacer as túas necesidades, aumentando o tamaño ou reducindo os tempos de espera de conntrack (pero se o fas mal, terás moitos problemas). Noutros casos será necesario desviar conntrack para tráfico agresivo.
Exemplo real
Poñamos un exemplo específico: un gran provedor de SaaS co que traballamos tiña un número de servidores memcached en hosts (non máquinas virtuais), cada un dos cales procesaba máis de 50 conexións a curto prazo por segundo.
Experimentaron coa configuración de conntrack, aumentando o tamaño das táboas e reducindo o tempo de seguimento, pero a configuración non era fiable, o consumo de RAM aumentou significativamente, o que foi un problema (da orde de GBytes!), e as conexións eran tan curtas que conntrack non o fixo. crear o seu beneficio de rendemento habitual (consumo reducido de CPU ou latencia de paquetes).
Recorreron a Calico como alternativa. As políticas de rede de Calico permítenche non usar conntrack para certos tipos de tráfico (usando a opción de política doNotTrack). Isto deulles o nivel de rendemento que necesitaban, ademais do nivel engadido de seguridade proporcionado por Calico.
A que lonxitude terás que ir para evitar conttrack?
- As políticas de rede de non rastrexar deberían ser xeralmente simétricas. No caso do provedor SaaS: as súas aplicacións executáronse dentro da zona protexida e, polo tanto, mediante a política de rede, podían incluír o tráfico doutras aplicacións específicas ás que se lles permitía acceder a memcached.
- A política de non rastrexar non ten en conta a dirección da conexión. Así, se o servidor memcached é pirateado, teoricamente pode tentar conectarse a calquera dos clientes memcached, sempre que use o porto de orixe correcto. Non obstante, se definiu correctamente a política de rede para os seus clientes memcached, estes intentos de conexión aínda se rexeitarán no lado do cliente.
- A política de non rastrexar aplícase a todos os paquetes, en oposición ás políticas normais, que só se aplican ao primeiro paquete dun fluxo. Isto pode aumentar o consumo de CPU por paquete porque a política debe aplicarse a cada paquete. Pero para conexións de curta duración, este gasto é equilibrado coa redución do consumo de recursos para o procesamento de conntrack. Por exemplo, no caso dun provedor SaaS, o número de paquetes para cada conexión era moi reducido, polo que se xustificaba o consumo adicional de CPU á hora de aplicar políticas a cada paquete.
Imos comezar a probar
Realizamos a proba nun único pod cun servidor Memcached e varios clientes Memcached en nodos remotos para poder executar un gran número de conexións por segundo. O servidor co pod do servidor memcached tiña 8 núcleos e 512k entradas na táboa conntrack (o tamaño da táboa configurado estándar para o host).
Medimos a diferenza de rendemento entre: ningunha política de rede; coa política regular de Calico; e a política de non rastrexar Calico.
Para a primeira proba, establecemos o número de conexións en 4.000 por segundo, polo que poderiamos centrarnos na diferenza no consumo da CPU. Non houbo diferenzas significativas entre ningunha política e a política normal, pero a función de non rastrexar aumentou o consumo de CPU nun 20 %:
Na segunda proba, lanzamos tantas conexións como os nosos clientes puideron xerar e medimos o número máximo de conexións por segundo que podía xestionar o noso servidor memcached. Como era de esperar, os casos de "sen política" e de "política regular" alcanzaron o límite de conntrack de máis de 4,000 conexións por segundo (512k / 120s = 4,369 conexións/s). Cunha política de non rastrexar, os nosos clientes enviaron 60,000 conexións por segundo sen ningún problema. Estamos seguros de que poderiamos aumentar este número engadindo máis clientes, pero cremos que estes números xa son suficientes para ilustrar o punto deste artigo.
Conclusión
Conntrack é unha característica importante do núcleo. Fai o seu traballo perfectamente. A miúdo úsano os compoñentes clave do sistema. Non obstante, nalgúns escenarios específicos, a conxestión debida a conntrack supera os beneficios normais que proporciona. Neste escenario, as políticas de rede de Calico pódense usar para desactivar selectivamente o uso de conntrack ao tempo que aumenta a seguridade da rede. Para o resto do tráfico, conntrack segue a ser o teu amigo!
Lea tamén outros artigos no noso blog:
Fonte: www.habr.com