stringtranslate.com

Comunicación transparente entre procesos

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

Características

Algunas características de TIPC:

Ejemplos de direccionamiento y seguimiento de servicios
Ejemplos de direccionamiento y seguimiento de servicios

Implementaciones

El protocolo TIPC está disponible como módulo en el núcleo principal de Linux y, por 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 normalmente están 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 .

Direccionamiento de servicio

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

Direccionamiento del servicio TIPC

Un socket se puede vincular a varias direcciones o rangos de servicios diferentes, del mismo modo que se pueden vincular diferentes sockets a la misma dirección o rango de servicios. Los enlaces también están calificados con un alcance de visibilidad , es decir, visibilidad global del clúster o local del nodo.

Mensajería de datagramas

Los mensajes de datagramas son unidades de datos discretas de entre 1 y 66.000 bytes de longitud, transmitidas entre sockets no conectados. Al igual que sus homólogos UDP , no se garantiza que los datagramas TIPC lleguen a su destino, pero sus posibilidades de ser entregados siguen siendo 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 buffer de recepción del socket. El remitente también puede aumentar las posibilidades de éxito dando a su socket una prioridad de importancia de entrega adecuada . Los datagramas se pueden transmitir de tres formas diferentes.

Mensajería orientada a la conexión

Las conexiones se pueden establecer de la misma forma que con TCP , mediante accept()y connect()sobre 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.

La propiedad más distintiva de las conexiones TIPC sigue siendo su capacidad de reaccionar rápidamente ante la pérdida de contacto con el socket del par, sin recurrir a los latidos activos del vecino.

Mensajería grupal

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

Al unirse a un grupo, un miembro puede indicar si desea recibir eventos de entrada o salida para 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 adecuado.

Seguimiento del servicio

Una aplicación accede al servicio de seguimiento abriendo una conexión al servidor de topología interna de TIPC, utilizando una dirección de servicio reservada. Luego puede enviar uno o más mensajes de suscripción al servicio de seguimiento, indicando la dirección o rango del 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 puerto y el número de nodo del socket vinculado/no vinculado. Hay dos casos especiales de seguimiento de servicios:

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 podría ser útil si, por ejemplo, un suscriptor de conectividad desea crear una matriz de toda la conectividad en todo el clúster, sin limitarse a lo que se puede ver desde el nodo local.

Grupo

Una red TIPC consta de elementos o nodos de procesamiento individuales . 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 según su identidad de clúster asignada . Todos los nodos que tengan la misma identidad de clúster establecerán enlaces entre sí, siempre que la red esté configurada para permitir el descubrimiento mutuo de vecinos entre ellos. Sólo es necesario cambiar la identidad del clúster de su valor predeterminado si los nodos de diferentes clústeres pueden potencialmente descubrirse entre sí, por ejemplo, si están conectados a la misma subred. Los nodos de diferentes clústeres no pueden comunicarse entre sí mediante TIPC.

Dos clústeres TIPC físicamente interconectados, pero lógicamente separados.

Antes de Linux 4.17, los nodos debían configurarse con un número o dirección de nodo único de 32 bits, 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. Luego, el número de nodo se calcula 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 establecer la identidad explícitamente, por ejemplo, desde el host del nodo. nombre o un UUID. Si un nodo no forma parte de un clúster, su identidad puede permanecer en el valor predeterminado, cero.

El descubrimiento de vecinos se realiza mediante multidifusión UDP o transmisión L2, cuando esté disponible. Si falta soporte de transmisión/multidifusión en la infraestructura, el descubrimiento se puede realizar mediante direcciones IP configuradas explícitamente.

Enlaces entre nodos

Un clúster consta de nodos interconectados con uno o dos enlaces. Un enlace constituye un servicio de transporte de paquetes confiable, a veces denominado capa de enlace de datos "L2.5".

Escalabilidad del clúster

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

Actuación

TIPC proporciona 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, dentro de nodos 2 veces más rápido para mensajes pequeños y 7 veces más rápido para mensajes grandes. Entre nodos, proporciona un rendimiento máximo entre un 10% y un 30% menor que TCP, mientras que su rendimiento dentro del nodo es entre un 25% y un 30% mayor. El equipo de TIPC está estudiando actualmente cómo agregar soporte GSO/GRO para mensajería dentro del nodo, para igualar TCP incluso aquí.

Medios de transporte

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

Seguridad

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

Historia

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 a la comunidad de código abierto e integrado en el núcleo principal de Linux. Desde entonces, ha sido objeto de 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 forma parte del paquete de herramientas iproute2 que viene de serie con todas las distribuciones de Linux.

Enlaces de referencia