Comunicación transparente entre procesos

La comunicación transparente entre procesos ( TIPC ) es un servicio de comunicación entre procesos (IPC) de Linux diseñado para funcionar en todo el clúster. A veces se lo presenta como Cluster Domain Sockets , en contraste con el conocido servicio Unix Domain Socket ; este último funciona solo en un único núcleo.

Algunas características de TIPC:

• Direccionamiento de servicios: direccionar servicios en lugar de sockets
• Seguimiento de servicios: suscríbase para vincular o desvincular direcciones de servicio a sockets
• Servicio IPC de todo el clúster: la ubicación del servicio es transparente para el remitente
• Mensajería de datagramas con unidifusión, anycast y multidifusión: entrega no confiable
• Mensajería orientada a la conexión : entrega confiable
• Mensajería grupal: mensajería de datagramas con entrega confiable
• Seguimiento de la topología del clúster: suscríbase para obtener nodos del clúster agregados o perdidos
• Seguimiento de conectividad: suscríbase para recibir actualizaciones o deshabilitar enlaces individuales entre nodos
• Descubrimiento automático de nuevos nodos del clúster
• Escala hasta 1000 nodos con detección de fallas de segunda velocidad
• Muy buen desempeño
• Implementado como módulo de kernel en árbol en kernel.org

El protocolo TIPC está disponible como módulo en el núcleo principal de Linux y, por lo tanto, en la mayoría de las distribuciones de Linux. El proyecto TIPC también proporciona implementaciones de código abierto del protocolo para otros sistemas operativos, incluidos VxWorks de Wind River y Solaris de Sun Microsystems . Las aplicaciones TIPC suelen estar escritas en C (o C++ ) y utilizan sockets de la familia de direcciones AF_TIPC. También está disponible soporte para Go , D , Perl , Python y Ruby .

Una aplicación TIPC puede utilizar tres tipos de direcciones.

• Dirección de servicio . Este tipo de dirección consta de un identificador de tipo de servicio de 32 bits y un identificador de instancia de servicio de 32 bits . El identificador de tipo normalmente lo determina y codifica el programador de la aplicación del usuario, pero es posible que su valor deba coordinarse con el de otras aplicaciones que puedan estar presentes en el mismo clúster. El identificador de instancia suele calcularlo el programa en función de criterios específicos de la aplicación.

• Rango de servicio . Este tipo de dirección representa un rango de direcciones de servicio del mismo tipo y con instancias entre un límite de rango inferior y uno superior . Al vincular un socket a este tipo de dirección, se puede lograr que represente muchas instancias, algo que ha resultado útil en muchos casos.
• Dirección de socket . Esta dirección es una referencia a un socket específico en el clúster. Contiene un número de puerto de 32 bits y un número de nodo de 32 bits . El sistema genera el número de puerto cuando se crea el socket y el número de nodo se establece mediante la configuración o, a partir de Linux 4.17, se genera a partir de la identidad del nodo correspondiente. Una dirección de este tipo se puede utilizar para conectarse o para enviar mensajes de la misma manera que se pueden utilizar las direcciones de servicio, pero solo es válida mientras exista el socket al que se hace referencia.

Un socket puede estar vinculado a varias direcciones o rangos de servicios diferentes, al igual que diferentes sockets pueden estar vinculados a la misma dirección o rango de servicios. Las vinculaciones también se califican con un ámbito de visibilidad , es decir, visibilidad local del nodo o visibilidad global del clúster.

Los mensajes de datagramas son unidades de datos discretas de entre 1 y 66.000 bytes de longitud que se transmiten entre conectores no conectados. Al igual que sus homólogos UDP , no se garantiza que los datagramas TIPC lleguen a su destino, pero sus posibilidades de entrega son mucho mejores que las de los primeros. Debido a la garantía de entrega de la capa de enlace, el único factor limitante para la entrega de datagramas es el tamaño del búfer de recepción del conector. El remitente también puede aumentar las posibilidades de éxito al dar a su conector una prioridad de importancia de entrega adecuada . Los datagramas se pueden transmitir de tres formas diferentes.

• Unicast . Si se indica una dirección de socket, el mensaje se transmite a ese socket exacto. En TIPC, el término unicast se reserva para indicar este modo de direccionamiento.
• Anycast . Cuando se utiliza una dirección de servicio, puede haber varios destinos coincidentes y el método de transmisión se convierte en lo que a menudo se denomina anycast , es decir, se puede seleccionar cualquiera de los destinos coincidentes. La función interna que traduce de la dirección de servicio a la dirección de socket utiliza un algoritmo round-robin para disminuir el riesgo de sesgo de carga entre los destinos.
• Multidifusión . El tipo de dirección de rango de servicio también funciona como dirección de multidifusión . Cuando una aplicación especifica un rango de servicio como dirección de destino, se envía una copia del mensaje a todos los sockets coincidentes en el clúster. Cualquier socket vinculado a una instancia de servicio coincidente dentro del rango de multidifusión indicado recibirá una copia del mensaje. La multidifusión TIPC aprovechará el uso de multidifusión UDP o difusión Ethernet siempre que sea posible.

Las conexiones se pueden establecer de la misma manera que con TCP , mediante accept()y connect()en sockets SOCK_STREAM . Sin embargo, en TIPC el cliente y el servidor utilizan direcciones o rangos de servicio en lugar de números de puerto y direcciones IP. TIPC también ofrece dos alternativas a este escenario de configuración estándar.

• Los sockets se pueden crear como SOCK_SEQPACKET, lo que implica que el intercambio de datos debe realizarse en unidades de mensajes de un máximo de 66.000 bytes.
• Un cliente puede inicializar una conexión simplemente enviando un mensaje de datos a un socket que la acepta. Asimismo, el socket del servidor generado puede responder con un mensaje de datos al cliente para completar la conexión. De esta manera, TIPC proporciona un mecanismo de configuración de conexión implícito , también conocido como 0-RTT , que ahorra mucho tiempo en muchos casos.

La propiedad más distintiva de las conexiones TIPC sigue siendo su capacidad de reaccionar rápidamente a la pérdida de contacto con el socket par, sin recurrir al latido activo del corazón del vecino.

• Cuando un socket se cierra sin gracia, ya sea por parte del usuario o debido a un fallo del proceso, el código de limpieza del socket del núcleo emitirá por iniciativa propia un mensaje FIN/ERROR al par.
• Cuando se pierde el contacto con un nodo del clúster, la capa de enlace local enviará mensajes FIN/ERROR a todos los sockets que tengan conexiones hacia ese nodo. El tiempo de detección de fallas del nodo par se puede configurar hasta 50 ms, mientras que el valor predeterminado es 1500 ms.

La mensajería grupal es similar a la mensajería de datagramas, como se describió anteriormente, pero con control de flujo de extremo a extremo y, por lo tanto, con garantía de entrega. Sin embargo, existen algunas diferencias notables.

• La mensajería sólo se puede realizar dentro de un grupo cerrado de sockets miembros.

  

• Un socket se une a un grupo mediante una dirección de servicio, donde el campo de tipo indica la identidad del grupo y el campo de instancia indica la identidad del miembro. Por lo tanto, un miembro solo puede vincularse a una única dirección de servicio.
• Al enviar un mensaje anycast , el algoritmo de búsqueda aplica el algoritmo round-robin regular, pero también considera la carga actual, es decir, la ventana de envío anunciada, en los receptores potenciales antes de seleccionar uno.
• La multidifusión se realiza mediante una dirección de servicio, no un rango, por lo que una copia del mensaje enviado llegará a todos los miembros que se hayan unido al grupo con exactamente esa dirección.
• Hay un modo de transmisión grupal que transmite un mensaje a todos los miembros del grupo, sin tener en cuenta su identidad.
• Se garantiza la secuencialidad de los mensajes, incluso entre los modos de transmisión.

Al unirse a un grupo, un miembro puede indicar si desea recibir eventos de ingreso o de abandono de otros miembros del grupo. Esta función aprovecha la función de seguimiento del servicio y el miembro del grupo recibirá los eventos en el socket de miembro correspondiente.

Una aplicación accede al servicio de seguimiento abriendo una conexión con el servidor de topología interno de TIPC, utilizando una dirección de servicio reservada. A continuación, puede enviar uno o más mensajes de suscripción de servicio al servicio de seguimiento, indicando la dirección o el rango de servicio que desea rastrear. A cambio, el servicio de topología envía mensajes de eventos de servicio a la aplicación siempre que las direcciones coincidentes estén vinculadas o no vinculadas por sockets dentro del clúster. Un evento de servicio contiene el rango de servicio coincidente encontrado, más el número de puerto y nodo del socket vinculado o no vinculado. Hay dos casos especiales de seguimiento de servicio:

• Seguimiento de la topología del clúster . Cuando TIPC establece contacto con otro nodo, crea internamente un enlace local de nodo, utilizando un tipo de servicio reservado, en la tabla de enlaces de servicios. Esto permite que las aplicaciones del nodo realicen un seguimiento de los nodos pares a los que se puede acceder en cualquier momento.
• Seguimiento de la conectividad del clúster . Cuando TIPC establece un nuevo enlace con otro nodo, crea internamente un enlace local de nodo, utilizando un tipo de servicio reservado, en la tabla de enlaces del nodo. Esto permite que las aplicaciones del nodo realicen un seguimiento de todos los enlaces en funcionamiento con los nodos pares en cualquier momento.

Aunque la mayoría de las suscripciones de servicios están dirigidas al servidor de topología local del nodo, es posible establecer conexiones con los servidores de otros nodos y observar sus enlaces locales. Esto puede resultar útil si, por ejemplo, un suscriptor de conectividad desea crear una matriz de toda la conectividad en el clúster, sin limitarse a lo que se puede ver desde el nodo local.

Una red TIPC consta de elementos de procesamiento individuales o nodos . Los nodos pueden ser procesadores físicos, máquinas virtuales o espacios de nombres de red, por ejemplo, en forma de contenedores Docker. Esos nodos se organizan en un clúster de acuerdo con su identidad de clúster asignada . Todos los nodos que tengan la misma identidad de clúster establecerán vínculos entre sí, siempre que la red esté configurada para permitir el descubrimiento mutuo de vecinos entre ellos. Solo es necesario cambiar la identidad del clúster de su valor predeterminado si los nodos en diferentes clústeres potencialmente pueden descubrirse entre sí, por ejemplo, si están conectados a la misma subred. Los nodos en diferentes clústeres no pueden comunicarse entre sí mediante TIPC.

Antes de Linux 4.17, los nodos debían tener configurado un número o dirección de nodo de 32 bits único , que debía cumplir con ciertas restricciones. A partir de Linux 4.17, cada nodo tiene una identidad de nodo de 128 bits que debe ser única dentro del clúster del nodo. El número de nodo se calcula entonces como un hash único garantizado a partir de esa identidad.

Si el nodo formará parte de un clúster, el usuario puede confiar en la capacidad de configuración automática del nodo, donde la identidad se genera cuando se conecta la primera interfaz, o puede configurar la identidad explícitamente, por ejemplo, a partir del nombre de host del nodo o un UUID. Si un nodo no formará parte de un clúster, su identidad puede permanecer en el valor predeterminado, cero.

La detección de vecinos se realiza mediante multidifusión UDP o difusión L2, cuando está disponible. Si la infraestructura no admite difusión o multidifusión, la detección se puede realizar mediante direcciones IP configuradas explícitamente.

Un clúster está formado por nodos interconectados mediante uno o dos enlaces. Un enlace constituye un servicio de transporte de paquetes fiable, a veces denominado capa de enlace de datos "L2.5".

• Garantiza la entrega y secuencialidad de todos los paquetes.
• Actúa como un tronco para las conexiones entre nodos y realiza un seguimiento de las mismas.

  

  • Cuando se pierde todo contacto con el nodo par, se notifica a los sockets con conexiones a ese par para que puedan romper las conexiones.
• Cada punto final realiza un seguimiento de los enlaces de direcciones del nodo par en la réplica local de la tabla de enlaces de servicio.
  • Cuando se pierde el contacto con el nodo par, se eliminan todos los enlaces de ese par y se emiten eventos de seguimiento de servicio a todos los suscriptores coincidentes.
• Cuando no hay tráfico regular de paquetes de datos, cada enlace se supervisa activamente mediante sondeos/latidos.
  • La tolerancia de detección de fallas se puede configurar de 50 ms a 30 segundos; la configuración predeterminada es 1,5 segundos.
• Por razones de rendimiento y redundancia, es posible establecer dos enlaces por par de nodos, en interfaces de red separadas.
  • Se puede configurar un par de enlaces para compartir carga o para funcionamiento activo-en espera.
  • Si un enlace falla, se producirá una conmutación por error sin perturbaciones al enlace restante, si lo hubiera.

Desde Linux 4.7, TIPC viene con un algoritmo de monitoreo de vecinos jerárquico autoadaptativo, pendiente de patente, único en su tipo. Este algoritmo de monitoreo de anillos superpuestos , en realidad una combinación del monitoreo de anillos y el protocolo Gossip , permite establecer clústeres de malla completa de hasta 1000 nodos con un tiempo de detección de fallas de 1,5 segundos, mientras que en clústeres más pequeños puede ser mucho más corto.

TIPC ofrece un rendimiento excepcional, especialmente en lo que respecta a los tiempos de latencia de ida y vuelta. Entre nodos, suele ser un 33 % más rápido que TCP, entre nodos, dos veces más rápido para mensajes pequeños y siete veces más rápido para mensajes grandes. Entre nodos, ofrece un rendimiento máximo entre un 10 y un 30 % inferior al de TCP, mientras que su rendimiento entre nodos es entre un 25 y un 30 % superior. El equipo de TIPC está estudiando actualmente cómo añadir compatibilidad con GSO/GRO para la mensajería entre nodos, con el fin de igualar a TCP incluso en este caso.

Si bien está diseñado para poder utilizar todo tipo de medios de transporte, a partir de mayo de 2018 ^[actualizar]las implementaciones admiten UDP , Ethernet e InfiniBand . La implementación de VxWorks también admite memoria compartida a la que pueden acceder varias instancias del sistema operativo que se ejecutan simultáneamente en el mismo hardware.

Actualmente, la seguridad debe ser proporcionada por el medio de transporte que lleva TIPC. Cuando se ejecuta a través de UDP, se puede utilizar IPSec; cuando se utiliza Ethernet, MACSec es la mejor opción. El equipo de TIPC está estudiando actualmente cómo admitir TLS o DTLS, ya sea de forma nativa o mediante una adición a OpenSSL.

Este protocolo fue desarrollado originalmente por Jon Paul Maloy en Ericsson entre 1996 y 2005 y fue utilizado por esa empresa en aplicaciones de clúster durante varios años, antes de ser lanzado posteriormente a la comunidad de código abierto e integrado en el núcleo principal de Linux. Desde entonces ha experimentado numerosas mejoras y actualizaciones, todas realizadas por un equipo de proyecto TIPC dedicado con participantes de varias empresas. La herramienta de gestión para TIPC es parte del paquete de herramientas iproute2 que viene de serie con todas las distribuciones de Linux.

• Proute2
• Sitio web de IProute2
• Página de inicio de TIPC
• Página del proyecto TIPC en SourceForge
• Descargas de demostraciones y utilidades en SourceForge