La comunicación transparente entre procesos ( TIPC ) es un servicio de comunicación entre procesos (IPC) en Linux diseñado para operaciones en todo el clúster. A veces se presenta como Cluster Domain Sockets , en contraste con el conocido servicio Unix Domain Socket ; el último trabajando solo en un solo kernel.
Características
Algunas características de TIPC:
- Direccionamiento de servicios: servicios de direcciones en lugar de sockets
- Seguimiento del servicio: suscríbase para vincular / desvincular direcciones de servicio a sockets
- Servicio de IPC en todo el clúster: la ubicación del servicio es transparente para el remitente
- Mensajería de datagramas con unidifusión, anycast y multicast, entrega no confiable
- Mensajería orientada a la conexión , entrega confiable
- Mensajería grupal, mensajería de datagramas con entrega confiable
- Seguimiento de topología de clúster, suscríbase para nodos de clúster agregados / perdidos
- Seguimiento de la conectividad, suscríbase para activar / desactivar enlaces individuales entre nodos
- Descubrimiento automático de nuevos nodos de 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
Implementaciones
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 el soporte para Go , D , Perl , Python y Ruby .
Servicio de direccionamiento
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 lo determina y codifica normalmente el programador de la aplicación de usuario, pero su valor puede tener que coordinarse con otras aplicaciones que pueden estar presentes en el mismo grupo. El identificador de instancia a menudo lo calcula el programa, basándose en 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 superior e inferior . Al vincular un socket a este tipo de dirección, se puede hacer 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 número de puerto lo genera el sistema cuando se crea el socket, y el número de nodo se establece mediante la configuración o, desde Linux 4.17, se genera a partir de la identidad de nodo correspondiente. Una dirección de este tipo se puede usar para conectarse o para enviar mensajes de la misma manera que se pueden usar las direcciones de servicio, pero solo es válida mientras exista el conector referenciado.
Un conector puede estar vinculado a varias direcciones o rangos de servicio diferentes, al igual que diferentes conectores pueden estar vinculados a la misma dirección o rango de servicio. Los enlaces también se califican con un alcance de visibilidad , es decir, visibilidad global de clúster o local de nodo.
Mensajería de datagramas
Los mensajes de datagramas son unidades de datos discretas entre 1 y 66.000 bytes de longitud, transmitidas entre sockets no conectados. Al igual que sus contrapartes UDP, no se garantiza que los datagramas TIPC lleguen a su destino, pero sus posibilidades de ser entregados siguen siendo mucho mejores que para 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 socket. El remitente también puede aumentar las posibilidades de éxito, dando a su enchufe 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 unidifusión está reservado para indicar este modo de direccionamiento.
- Anycast . Cuando se usa 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, que se puede seleccionar cualquiera de los destinos coincidentes. La función interna que se traduce de la dirección de servicio a la dirección de socket utiliza un algoritmo de operación por turnos para disminuir el riesgo de sesgo de carga entre los destinos.
- Multidifusión . El tipo de dirección del 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 del 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 la multidifusión UDP o la transmisión Ethernet siempre que sea posible.
Mensajería orientada a la conexión
Las conexiones se pueden establecer de la misma forma que con TCP, mediante accept () y connect () en sockets SOCK_STREAM. Sin embargo, en TIPC, el cliente y el servidor usan 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 ocurrir 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 de aceptación. Del mismo modo, 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 en muchos casos ahorra tiempo.
La propiedad más distintiva de las conexiones TIPC sigue siendo su capacidad para reaccionar rápidamente a la pérdida de contacto con el conector del par, sin recurrir a los latidos del corazón del vecino activo.
- Cuando un socket se cierra de manera descortés, ya sea por parte del usuario o debido a un bloqueo del proceso, el código de limpieza del socket del kernel 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 emitirá mensajes FIN / ERROR a todos los sockets que tengan conexiones hacia ese nodo. El tiempo de detección de fallos del nodo par se puede configurar hasta 50 ms, mientras que el valor predeterminado es 1500 ms.
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 extremo a extremo y, por lo tanto, con garantía de entrega. Sin embargo, existen algunas diferencias notables.
- La mensajería solo se puede realizar dentro de un grupo cerrado de sockets de 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.
- Cuando se envía 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 han unido al grupo con exactamente esa dirección.
- Existe un modo de transmisión grupal que transmite un mensaje a todos los miembros del grupo, sin considerar su identidad de miembro.
- La secuencialidad de los mensajes está garantizada, incluso entre los modos de transmisión.
Al unirse a un grupo, un miembro puede indicar si desea recibir eventos para unirse o abandonar 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 conector correspondiente.
Seguimiento de servicios
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 al servicio al servicio de seguimiento, indicando la dirección del servicio o el rango 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:
- Seguimiento de topología de clústeres . Cuando TIPC establece contacto con otro nodo, crea internamente un enlace local de nodo, utilizando un tipo de servicio reservado, en la tabla de enlace de servicio. Esto hace posible que las aplicaciones en el nodo realicen un seguimiento de los nodos pares accesibles en cualquier momento.
- Seguimiento de la conectividad del clúster . Cuando TIPC establece un nuevo enlace a otro nodo, crea internamente un enlace local de nodo, utilizando un tipo de servicio reservado, en la tabla de enlace del nodo. Esto hace posible que las aplicaciones en el nodo realicen un seguimiento de todos los enlaces de trabajo a los nodos pares en cualquier momento.
Aunque la mayoría de las suscripciones de servicio 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 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 de acuerdo con 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. Solo es necesario cambiar la identidad del clúster de su valor predeterminado si los nodos de diferentes clústeres pueden 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.
Antes de Linux 4.17, los nodos deben configurarse con un número o dirección de nodo único de 32 bits , que debe 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 de esa identidad.
Si el nodo será 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 UUID. Si un nodo no formará 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 difusión L2, cuando esté disponible. Si falta el soporte de difusió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".
- Garantiza la entrega y secuencialidad de todos los paquetes.
- Actúa como un tronco para las conexiones entre nodos y realiza un seguimiento de ellas.
- 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 servicios.
- Cuando se pierde el contacto con el nodo par, todos los enlaces de ese par se eliminan y los eventos de seguimiento del servicio se envían 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; el valor predeterminado es 1,5 segundos.
- Por motivos de rendimiento y redundancia, es posible establecer dos enlaces por par de nodos, en interfaces de red independientes.
- Se puede configurar un par de enlaces para compartir carga o activo-en espera.
- Si un enlace falla, habrá una conmutación por error sin perturbaciones en el enlace restante, si lo hubiera.
Escalabilidad de clústeres
Desde Linux 4.7, TIPC viene con un algoritmo de monitoreo de vecinos jerárquico autoadaptativo único, pendiente de patente. Este algoritmo de monitoreo de anillos superpuestos , en realidad una combinación de monitoreo de anillos y el protocolo Gossip , hace posible 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 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, intranodo 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% más bajo que el TCP, mientras que su rendimiento entre nodos es entre un 25 y un 30% más alto. El equipo de TIPC está estudiando actualmente cómo agregar soporte GSO / GRO para mensajería intranodo, con el fin de igualar TCP incluso aquí.
Medios de transporte
Aunque 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.
Seguridad
Actualmente, la seguridad debe ser proporcionada por los medios de transporte que llevan TIPC. Cuando se ejecuta a través de UDP, IPSec se puede usar, cuando está en 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.
Historia
Este protocolo fue desarrollado originalmente por Jon Paul Maloy en Ericsson durante 1996-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 kernel de Linux convencional. 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 administración para TIPC es parte del paquete de herramientas iproute2 que viene de serie con todas las distribuciones de Linux.
Enlaces de referencia
- Iproute2
- Sitio web de IProute2
- Página de inicio de TIPC
- Página del proyecto TIPC en SourceForge
- Descargas de demostraciones y utilidades en SourceForge