Requisitos de estabilidad de la red e integridad de los datos para las implementaciones en la nube de Tulip

Descripción general

Se requiere una conexión de red estable y de alta calidad para que las implementaciones de Tulip Cloud mantengan el rendimiento en tiempo real y la integridad de los datos. Este artículo define los requisitos de red cuantificables —ancho de banda, latencia, fluctuación y pérdida de paquetes— que debe cumplir una implementación de Tulip, explica los riesgos técnicos de la inestabilidad de la red (incluida la pérdida de datos en la cola de activación y los fallos de cumplimiento de ALCOA) y ofrece recomendaciones a nivel físico, lógico y de aplicación para mitigar dichos riesgos.

La estabilidad es más importante que la velocidad bruta: una conexión inestable con un jitter elevado o una pérdida intermitente de paquetes puede provocar una pérdida de datos silenciosa y permanente, incluso en enlaces de gran ancho de banda. Para cumplir los requisitos de este artículo se requiere un enfoque en dos partes —una infraestructura de TI/red robusta y una arquitectura de aplicaciones resiliente— que funcionen conjuntamente.

Para consultar la lista de dominios y direcciones IP específicos que debes incluir en la lista de permitidos para tu instancia de Tulip Cloud, consulta los requisitos de red para la implementación de Tulip Cloud.

¿A quién va dirigido este artículo?

Este artículo resulta especialmente útil para usuarios avanzados de Tulip que están realizando implementaciones en entornos a gran escala. Si acaba de implementar Tulip en su organización o se encuentra actualmente en un periodo de prueba, es probable que esta información sea más avanzada de lo que sus necesidades actuales requieren.

Utilice los enlaces de la derecha para acceder al contenido del tema que desee.

Resumen ejecutivo

Este documento describe los requisitos de red fundamentales para garantizar el rendimiento, la estabilidad y la integridad de los datos de una implementación de Tulip Cloud.

Puntos clave

La estabilidad es más importante que la velocidad: una conexión por cable estable de 15 Mbps es muy superior a una conexión inestable de más de 100 Mbps con alta fluctuación o pérdida de paquetes.

La inestabilidad de la red provoca pérdida de datos: las conexiones intermitentes, la alta latencia o la pérdida de paquetes no solo provocan «lentitud». Provocan que la cola de activación se sature y descarte eventos, lo que conduce a una pérdida permanente de datos y a fallos críticos en la integridad de los datos (ALCOA).

La mitigación requiere una solución en dos partes: se necesitan tanto una infraestructura de TI robusta (que cumpla los requisitos que se indican a continuación) como una arquitectura de aplicaciones resiliente (por ejemplo, desacoplando la lógica mediante automatizaciones).

Políticas de infraestructura crítica

Por defecto, se utiliza Ethernet por cable: todos los reproductores Tulip fijos deben utilizar Ethernet por cable y blindada.

Configurar y supervisar los proxies y los cortafuegos: todos los dominios de Tulip incluidos en la lista de permitidos deben estar configurados para el paso de SSL/TLS (véase la lista de permitidos). Se debe minimizar la inspección profunda de paquetes (DPI) y supervisar de forma proactiva el rendimiento de los cortafuegos y los proxies.

Lista de comprobación de la preparación de la red por estación

Para cada estación de Tulip Player, comprueba:* [ ] Tipo de conexión: los reproductores fijos utilizan Ethernet por cable y apantallada (STP, Cat6a o superior).* [ ] Ancho de banda: al menos 15 Mbps disponibles tanto en descarga como en subida; nunca por debajo de 10 Mbps por estación activa o del mínimo calculado (véase «Requisitos de red cuantificables»)* [ ] Latencia: la latencia media de ida y vuelta (RTT) a your-instance.tulip.co es < 80 ms; el RTT máximo es < 100 ms*[ ] Fluctuación: La fluctuación ($RTT_{máx}-RTT_{promedio}$) es inferior a 10 ms (y siempre inferior a 30 ms)* [ ] Pérdida de paquetes: La pérdida de paquetes medida es del 0 % durante el funcionamiento normal y inferior al 0,1 % en las pruebas de peor caso.* [ ] Tiempo de actividad: La ruta desde el reproductor hasta Tulip Cloud no depende de conexiones inestables (WiFi ad hoc, redes de invitados, VPN con caídas frecuentes, etc.)* [ ] Proxies / cortafuegos: Todos los dominios de Tulip incluidos en la lista de permitidos están configurados para el paso directo de SSL/TLS sin interceptación de SSL, reescritura de protocolos, manipulación ni almacenamiento en caché, y preferiblemente sin DPI.* [ ] WebSockets: Los proxies y cortafuegos permiten conexiones WebSocket de larga duración a través del puerto 443 sin problemas de tiempo de inactividad ni de reinicio de la conexión.
[ ] Actividad de los procesos*: Los dispositivos (especialmente los móviles) están configurados para* evitar la hibernación agresiva de procesos en segundo plano*, la optimización de la batería o las políticas del sistema operativo que suspendan el Tulip Player, o que limiten las solicitudes de red, las conexiones TCP o las conexiones WebSocket mientras están en uso.* [ ]* Aplicaciones resilientes*: Las aplicaciones críticas de esta estación siguen los* patronesde arquitectura de aplicaciones resilientes*(minimizar la frecuencia de eventos y las llamadas a la API en las rutas de activación críticas durante el flujo de trabajo del operador, dar prioridad a las tablas de Tulip y minimizar los conectores de larga duración).

Riesgos de inestabilidad e integridad de los datos

En esta sección se explica por qué es fundamental disponer de una conexión estable y cuáles son los riesgos técnicos que afectan al rendimiento y a la integridad de los datos.

Más allá del simple retraso en los mensajes, la conectividad intermitente o la pérdida de paquetes pueden dar lugar a dos problemas principales: 1. Pérdida de eventos y de datos. Cuandola red es inestable o está desconectada, las acciones del operador (como pulsaciones de botones, entradas de dispositivos o escaneos de códigos de barras) siguen generando eventos. Estos eventos se acumulan en una cola. Dado que esta cola tiene un límite finito (100 eventos por defecto), si se supera mientras se espera a que la red se recupere, todos los nuevos eventos entrantes se descartan y se pierden de forma permanente. 2. Sobrecarga del sistema y lentitud por «puesta al día»: cuandose restablece la conectividad tras una interrupción, todo el volumen acumulado de eventos en cola (hasta 100) intentará ejecutarse en rápida sucesión. Esto puede provocar una carga repentina y masiva en la plataforma Tulip y en cualquier sistema de terceros conectado (a través de Connector Functions). Especialmente cuando se coordina entre varias estaciones que se vuelven a conectar debido a un problema de conectividad de red compartido. Esta avalancha de «puesta al día» puede ser una fuente de ralentización y sobrecarga considerables, y también puede provocar la limitación de la API (errores HTTP 429) y nuevos fallos.

Cómo los problemas de red provocan la pérdida de datos en la cola de disparadores

Para comprender este riesgo, es esencial saber cómo se ejecutan los desencadenadores. Consulta la sección «Desencadenantes» para obtener más detalles.* Cola de un solo hilo: el motor de ejecución de desencadenantes de Tulip funciona con una cola secuencial de un solo hilo. Cada evento de desencadenante (por ejemplo, «botón pulsado») se añade a esta cola y debe completar todas sus acciones antes de que el siguiente evento de la cola pueda siquiera comenzar.* «Atasco» de red: una interrupción de la red o una inestabilidad grave provoca que las acciones dentro de un disparador (como «Crear registro de tabla» o «Ejecutar Connector Function ») se cuelguen o entren en un estado de reintento prolongado. Por ejemplo, a partir de la versión LTS15, una acción de tabla que falle se reintentará durante un máximo de 2 minutos.* El cuello de botella: este único disparador lento bloquea toda la cola. Mientras está bloqueada, las acciones posteriores del operador (por ejemplo, 99 pulsaciones más de botones) llenan la cola.* Eventos descartados: una vez alcanzado el límite de la cola (por defecto, 100 eventos), todos los eventos posteriores se cancelan y se descartan. Esto significa que, si un operador escanea un artículo número 101 durante la interrupción de la red, ese evento se pierde para siempre y no se procesará cuando se restablezca la red.

Incluso cuando la cola no está llena, la inestabilidad general de la red puede provocar que fallen las llamadas individuales a la interfaz de programación de aplicaciones ( Connector Functions, API). Estas acciones no se reintentan (a diferencia de las acciones de tabla en LTS15) y pueden dar lugar a fallos silenciosos en los datos y a problemas de integridad.

Factores de riesgo de pérdida de datos

El riesgo de pérdida de datos durante una conectividad de red deficiente no es uniforme. Aumenta considerablemente en el caso de arquitecturas de aplicaciones con un «alto volumen de eventos». Descubre aquí las mejores prácticas para estas aplicaciones.

El riesgo es mucho mayor si sus aplicaciones presentan:* Una alta frecuencia de eventos: aplicaciones que generan muchos eventos en poco tiempo. Esto incluye el escaneo rápido de códigos de barras, entradas frecuentes desde dispositivos o activaciones de temporizadores a intervalos cortos (por ejemplo, cada 30 segundos).* Desencadenantes complejos: desencadenantes que ejecutan muchas acciones secuenciales, especialmente múltiples llamadas a la API (Connector Functions) o escrituras en tablas. Cada acción que dependa de la red aumenta el tiempo potencial de «atascos» durante una interrupción del servicio.* Dependencia de Connector Functions: uso de Connector Functions para la captura de datos críticos. Si Connector Function falla debido a un fallo momentáneo de la red, no se volverá a intentar y el disparador fallará, lo que puede detener el proceso o provocar la pérdida de datos. Utilice automatizaciones (y/o funciones) siempre que sea posible.

Cumplimiento de ALCOA en el sector de las ciencias de la vida

Para los clientes del sector de las ciencias de la vida y otros entornos regulados por GxP, estos riesgos de red no son solo problemas de rendimiento, sino amenazas directas para la integridad de los datos y el cumplimiento normativo.

Los riesgos técnicos descritos anteriormente se corresponden directamente con los principios ALCOA:* Inexactos e incompletos: cuando se alcanza el límite de la cola de activadores durante una interrupción del servicio, todos los eventos posteriores se descartan de forma permanente. Si un operador escanea un elemento número 101, ese evento se pierde para siempre. El registro de lote resultante es, en esencia, inexacto e incompleto.* No contemporáneos: Cuando se restablece la conectividad, la avalancha de «puesta al día» ejecuta una acumulación de eventos en cola, a menudo minutos después de que el operador haya realizado la acción. Un auditor que revise un conjunto de marcas de tiempo que estén claramente retrasadas con respecto al proceso real cuestionaría la integridad de la contemporaneidad del registro.* Inexacto (entre sistemas): Connector Functions (las llamadas a la API) no cuentan con reintentos integrados. Un fallo momentáneo de la red puede provocar que un disparador escriba correctamente en una tabla de Tulip (el registro original), pero no consiga actualizar un MES o QMS externo. Esto da lugar a un estado de datos inexacto y desincronizado en todos sus sistemas validados.

Seguir las recomendaciones arquitectónicas de la siguiente sección es esencial para crear un proceso robusto y validable que proteja contra fallos en la integridad de los datos.

Requisitos de red cuantificables

Para evitar los atascos en la cola de activación, la pérdida de eventos y los fallos de integridad de datos mencionados anteriormente, cada estación de Tulip Player debe mantener una conexión persistente y de alta calidad. Las cuatro dimensiones siguientes definen este requisito.

Ancho de banda (rendimiento)

Se trata del «tamaño» de la conexión, que evita la saturación. Aunque las cargas útiles de datos de las aplicaciones suelen ser pequeñas, un ancho de banda insuficiente genera latencia y pérdida de paquetes, lo que a su vez bloquea la cola de activación.

• Recomendación: 15 Mbps por estación activa.
• Mínimo absoluto: 10 Mbps por estación activa, o el ancho de banda requerido calculado, el que sea mayor.
• Límite cuantificable: el ancho de banda mínimo debe superar la tasa de datos base (BDR) de la aplicación, multiplicada por un factor de margen ($H$) de al menos 2,0 (100 %) para tener en cuenta la sobrecarga de la red y las retransmisiones.
  • $R_{pico}$ = Tasa de eventos máxima (eventos por segundo)
  • $S_{event}$ = Carga útil media de datos por evento (bytes, incluidos todos los datos enviados y recibidos por el disparador)
  • $H$ = factor de margen (adimensional), para el que se recomienda que $H > 2,0$

En primer lugar, calcule la tasa de datos base (BDR) en bits por segundo:* $BDR (bps) = R_{pico} \times S_{evento} \times 8$

A continuación, calcule el ancho de banda necesario: * $Ancho de banda necesario (bps) = BDR \times H = R_{pico} \times S_{evento} \times 8 \times H$

En la práctica, si este valor calculado es inferior a 10 Mbps, se deben asignar al menos 10 Mbps por estación activa (y preferiblemente 15 Mbps) para garantizar la compatibilidad futura, proporcionar un margen amplio y tener en cuenta el resto del tráfico en el mismo enlace.

Ejemplo

Si la tasa máxima de eventos en el peor de los casos de tu aplicación es $R_{pico}=2\text{ eventos}/s$ y cada evento envía y recibe aproximadamente $S_{evento}=5.000\text{ bytes}$, entonces:* $BDR = 2 \times 5 000 \times 8 = 80 000 bps$* $Ancho de banda necesario (H = 2,0) = 160 000 bps = 0,16 Mbps$

Aunque el requisito calculado sea bajo, seguimos asignando al menos entre 10 y 15 Mbps por estación.

Latencia (tiempo de ida y vuelta)

Se trata del retraso que tarda un paquete en llegar al servidor y volver. Una latencia elevada aumenta directamente el tiempo de ejecución de todas las acciones de activación que dependen de la red (como una escritura en una tabla o un connector function), lo que hace que toda la cola sea vulnerable a los atascos.

• Recomendación: < 80 ms
• Máximo absoluto: 100 ms (hacia tu dominio [instancia].tulip.co).
• Límite cuantificable: La latencia determina directamente cuánto tardan las acciones dependientes de la red dentro de un disparador. Para evitar que la cola de disparadores se sature, el tiempo total de ejecución de los disparadores aportado por las acciones de red debe ser significativamente menor que el tiempo entre eventos.

Sea:* $R_{pico}$ = tasa máxima de eventos (eventos por segundo)* $T_{entre}$ = tiempo entre eventos (segundos).* $N_{net}$ = número de acciones de red secuenciales en el disparador (p. ej., escrituras en tablas, llamadas a conectores)* $RTT_{avg}$ = latencia media de ida y vuelta (segundos)

El tiempo entre eventos es:* $T_{between}=\frac{1}{R_{peak}}$

Una aproximación sencilla para el tiempo de activación atribuible a la latencia de red es:* $T_{trigger,net}=N_{net}\times RTT_{avg}$

Para mantener una cola en buen estado, es necesario que el tiempo de activación determinado por la red sea considerablemente inferior al tiempo entre eventos.Una regla empírica práctica es:* $N_{net}\times RTT_{avg}\leq 0,25\times T_{between}$* $N_{net}\times RTT_{avg}\leq \frac{0,25}{R_{peak}}$

En otras palabras: la suma de todos los viajes de ida y vuelta consecutivos por la red en un disparador debe ser inferior a una cuarta parte del tiempo esperado entre eventos del operador en condiciones de carga máxima. Si no se cumple esta condición, la cola se irá acumulando gradualmente hasta alcanzar, finalmente, el límite de 100 eventos. Para obtener un rendimiento más fiable, se recomienda mantener $N_{net}\times RTT_{avg}\lt \lt \frac{0,1}{R_{peak}}$

Fluctuación (variación de la latencia)

Se trata de la variación en la latencia. Una conexión con mucho jitter es inestable; un pico repentino de latencia en un solo paquete puede bloquear un disparador con la misma eficacia que una latencia media elevada, obstruyendo la cola y provocando atascos «aleatorios» y la pérdida de eventos.

• Límite cuantificable: La fluctuación es la variación de la latencia a lo largo del tiempo. Un único pico de latencia puede bloquear un disparador con la misma eficacia que una latencia elevada constante.

Sea:* $RTT_{avg}$ = latencia media de ida y vuelta en una ventana de muestreo (segundos)* $RTT_{max}$ = latencia máxima de ida y vuelta observada en la misma ventana (segundos)

Definimos:* $Jitter=RTT_{max}-RTT_{avg}$

Este valor debe mantenerse bajo para garantizar un rendimiento predecible de los disparadores. Para implementaciones de Tulip:* Recomendación: $Jitter$ < 10 ms * Máximo absoluto: $Jitter$ < 30 ms

Si la fluctuación medida se aproxima o supera los 30 ms, los operadores observarán bloqueos «aleatorios» y los disparadores pueden permanecer en estado de ejecución el tiempo suficiente como para bloquear la cola.

Fiabilidad (pérdida de paquetes y tiempo de actividad)

Esta es la dimensión más crítica para la integridad de los datos. La pérdida de paquetes obliga a realizar retransmisiones, lo que puede paralizar un disparador durante segundos, provocando graves atascos en la cola. Las desconexiones (fallos en el tiempo de actividad) son catastróficas, ya que provocan que la cola se llene (100 eventos) y la pérdida permanente de todos los datos posteriores, lo que garantiza que los registros queden incompletos.

• Recomendación: 0 % de pérdida de paquetes y tiempo de actividad constante.
• Máximo absoluto: < 0,1 % de pérdida de paquetes.
• **Límite cuantificable:**La cola de activadores solo puede contener un número limitado de eventos. Cuando la red está inactiva, las acciones de los operadores siguen generando eventos hasta que la cola se llena. Una vez que la cola alcanza su límite, todos los eventos posteriores se descartan y se pierden de forma permanente.

Sea:* $Q_{max}$ = tamaño máximo de la cola (eventos). Actualmente, $Q_{max}=100$ por defecto.* $R_{peak}$ = tasa máxima de eventos durante una interrupción del servicio (eventos por segundo).

La duración máxima tolerable de la interrupción antes de que se empiecen a descartar eventos es:* $T_{outage,max}=\frac{Q_{max}}{R_{peak}}$

Ejemplo: Para una aplicación con una alta tasa de eventos de $R_{peak}=2$ eventos/segundo (p. ej., valores de par rápidos):* $T_{outage,max}=\frac{100}{2}=50$ segundos

En este ejemplo, cualquier interrupción continua de la red que dure más de 50 segundos provocará la pérdida de datos: todos los eventos posteriores a los primeros 100 se descartarán y nunca se procesarán, incluso después de que la red se recupere.

Esta sencilla relación es crucial para la evaluación de riesgos: las aplicaciones con una alta frecuencia de eventos solo toleran interrupciones muy breves antes de que se vea comprometida la integridad de los datos.

Recomendaciones sobre la infraestructura física

Cumplir los requisitos cuantificables de la red no depende únicamente de su proveedor de servicios de Internet (ISP); depende en gran medida de la infraestructura física interna de red de sus instalaciones.

Recomendación por defecto: Ethernet por cable

Para alcanzar los niveles de estabilidad, fiabilidad y baja latencia definidos en la sección anterior, una conexión Ethernet por cable es la recomendación firme y por defecto para todas las estaciones fijas de Tulip Player.

Sin embargo, no se trata de una solución del tipo «configúralo y olvídate». La capa física es un punto de fallo habitual y a menudo pasado por alto que puede provocar pérdidas de paquetes intermitentes y difíciles de diagnosticar.

• Integridad física del cable: los equipos de TI y de operaciones deben gestionar de forma proactiva esta infraestructura. Inspecciona periódicamente los cables en busca de defectos, deshilachamientos o conexiones sueltas. Una causa habitual de fallo es que un carro pase repetidamente por encima de un cable sin blindaje o mal tendido.
• Interferencias electromagnéticas (EMI): En una planta de producción, la maquinaria con fuertes vibraciones, los motores o los equipos de alta tensión pueden provocar interferencias significativas. Utilice cables Ethernet apantallados (por ejemplo, STP, Cat6a o superiores) en estos entornos para proteger contra la degradación de la señal.

Consideraciones sobre el WiFi y los dispositivos móviles

Somos conscientes de que muchos clientes utilizan dispositivos móviles (tabletas, teléfonos) o carros móviles en los casos en que no es viable una conexión por cable. En estos casos, una conexión Wi-Fi estable es un requisito previo para la integridad de los datos.

• Diseño de la red: Debe garantizar una red inalámbrica robusta y diseñada por profesionales. El objetivo es lograr una cobertura homogénea, sin lagunas de cobertura (que provocan desconexiones) y con una superposición mínima entre los puntos de acceso (AP). Un solapamiento excesivo puede hacer que un dispositivo «buscara» entre puntos de acceso, lo que obligaría a una renegociación del DHCP y provocaría un bloqueo de la red que impediría el funcionamiento de la cola de activación.
• Interferencias: El WiFi también es muy susceptible a las interferencias electromagnéticas (EMI) procedentes de la maquinaria. El diseño de la red debe tener esto en cuenta.
• Mayor riesgo: dado que una conexión inalámbrica es, por naturaleza, menos estable que una por cable, resulta aún más crítico que las aplicaciones de estos dispositivos sigan las recomendaciones de la Arquitectura de Aplicaciones Resiliente (como la lógica de desacoplamiento) para protegerse contra los inevitables fallos de red.
• Los sistemas operativos móviles pueden suspender o limitar de forma agresiva las aplicaciones en segundo plano para ahorrar batería. Tulip Player debería quedar exento de dichas políticas mientras esté en uso (se recomienda el modo quiosco o de aplicación bloqueada).

Lista de comprobación de la infraestructura física

Estaciones con cable

• [ ] Tipo de cable: Todos los Tulip Players fijos utilizan cable Ethernet apantallado (STP, Cat6a o superior) en zonas con altas interferencias electromagnéticas (motores, variadores, soldadoras, etc.).
• [ ] Trazado de los cables: No hay cables tendidos por donde circulen habitualmente carros, carretillas elevadoras o sillas; los cables se tendan a través de bandejas, conductos o por el techo siempre que sea posible.
• [ ] Integridad de los cables: Existe un calendario de inspección documentado (por ejemplo, trimestral) para comprobar si hay hilos sueltos, retorcimientos, fundas aplastadas y conexiones flojas.
• [ ] Terminaciones: Todos los conectores y paneles de conexión están correctamente terminados y cuentan con alivio de tensión; no se utilizan cables de conexión «provisionales» como tendidos permanentes.
• [ ] Puertos de conmutador: Los puertos de los dispositivos están configurados en la velocidad y el modo dúplex adecuados, y no comparten enlaces ascendentes sobresuscritos que se saturan habitualmente.
• [ ] Alimentación / PoE: Si se utiliza PoE, el presupuesto de potencia del conmutador no está sobresuscrito; se supervisan y se activan alarmas ante caídas de tensión o reinicios.
• [ ] Supervisión: La supervisión básica de los conmutadores (CPU, memoria, errores de interfaz y utilización) está activada y se revisa periódicamente.

WiFi y dispositivos móviles

• [ ] Diseño profesional: La red inalámbrica ha sido diseñada profesionalmente (o, al menos, se ha realizado un estudio) para la zona de producción en la que operan los dispositivos Tulip.
• [ ] Cobertura: La intensidad de la señal medida a lo largo de todo el recorrido del operador (la «ruta de desplazamiento») muestra una cobertura continua sin zonas muertas que provoquen desconexiones o «caídas libres» en el roaming.
• [ ] Superposición de puntos de acceso: Los puntos de acceso están colocados de forma que se minimice la superposición excesiva; los clientes no «buscan» entre puntos de acceso mientras permanecen estacionarios.
• [ ] Comportamiento de itinerancia: Los umbrales de itinerancia y la selección de banda están ajustados de modo que los dispositivos cambien de punto de acceso con fluidez, sin renegociaciones repetidas de DHCP ni breves caídas de conexión.
• [ ] Interferencias: En la planificación de canales se han tenido en cuenta las fuentes conocidas de interferencias electromagnéticas (maquinaria, soldadoras, motores de gran tamaño, enlaces de microondas, etc.).
• [ ] Segmentación: Los dispositivos Tulip se encuentran en un SSID/VLAN dedicado para sistemas de producción, sin mezclarse con la red WiFi para invitados ni con dispositivos de consumo con alta rotación.
• [ ] Backhaul: Los puntos de acceso (AP) cuentan con enlaces ascendentes fiables y sin congestión; el WiFi gestionado por un controlador o en la nube no funciona cerca de su capacidad máxima.
• [ ] Aplicaciones resilientes: Las aplicaciones que se ejecutan en dispositivos WiFi o móviles siguen más estrictamente la arquitectura de aplicaciones resilientes para tener en cuenta el riesgo intrínsecamente mayor de la conectividad inalámbrica.

Prueba

Recorra una ruta con un «Player» que ejecute «networkCheck» y sus propias herramientas de diagnóstico, y asegúrese de que no se produzcan desconexiones ni picos que superen el umbral durante 10 minutos.

Infraestructura lógica y de seguridad (proxies, cortafuegos y DPI)

Más allá de los cables físicos, la infraestructura lógica de seguridad de la red es la fuente más habitual de latencia «misteriosa», fluctuaciones y fallos de conexión.

• Los proxies y los cortafuegos como cuello de botella: los dispositivos de seguridad (cortafuegos, proxies, CASB, etc.) que realizan inspección profunda de paquetes (DPI) o descifrado SSL/TLS en todo el tráfico son una fuente principal de inestabilidad. Este proceso de inspección en sí mismo añade una latencia significativa y variable (fluctuación) a cada solicitud de red, lo que puede incumplir fácilmente los requisitos de latencia <100 ms y fluctuación <30 ms.
• Supervisar el estado de los dispositivos: Los equipos de red deben supervisar la utilización de la CPU y la memoria de estos dispositivos. Un cortafuegos o un proxy sobrecargado descartará paquetes o introducirá latencia, creando precisamente la inestabilidad que conduce a la pérdida de datos.
• No interfieras en el tráfico de Tulip: la comunicación entre el cliente y la nube de Tulip se basa en protocolos web específicos, incluidos los WebSockets seguros, para la transferencia de datos en tiempo real. Algunas soluciones de seguridad intentan interceptar, reescribir o «alterar» este tráfico HTTPS. Esta interceptación puede interrumpir la conexión WebSocket o marcar erróneamente las llamadas a la API estándar como solicitudes de origen cruzado (CORS), provocando que fallen.
• Requisito: Todos los dominios de Tulip (enumerados en la sección «Lista de permitidos» ) deben estar configurados para el paso directo de SSL/TLS. El tráfico debe eludirse en cualquier sistema de inspección de paquetes (DPI), inspección de protocolos o almacenamiento en caché.

Lista de comprobación

• [ ] Dominios de Tulip excluidos: Todos los dominios de Tulip que figuran en la lista de permitidos están configurados para el paso directo de SSL/TLS y quedan excluidos del descifrado o la interceptación de SSL.
• [ ] Se prefiere que no haya DPI ni reescritura de protocolos: la inspección profunda de paquetes (DPI), la reescritura del protocolo HTTP y el almacenamiento en caché de contenidos están desactivados para el tráfico de Tulip, especialmente para WebSockets.
• [ ] Compatibilidad con WebSocket: los cortafuegos y los proxies permiten conexiones WebSocket de larga duración a través del puerto 443 sin tiempos de espera cortos por inactividad ni reinicios forzados.
• [ ] Supervisión de la capacidad: se supervisan la CPU, la memoria y el rendimiento de los dispositivos de seguridad; se han establecido alertas para casos de alta utilización sostenida que podrían provocar latencia o pérdida de paquetes.
• [ ] Reglas de salida: Las reglas de salida permiten explícitamente los rangos de IP y nombres de host de Tulip (por identificador de jardín), incluidos los puntos finales de almacenamiento de activos (S3/Blob).
• [ ] Comportamiento «fail-open»: siempre que sea posible, el tráfico de Tulip se configura para actuar en modo «fail-open» (o con errores claros y registrados), en lugar de descartar paquetes de forma silenciosa.
• [ ] Control de cambios: Se realiza un seguimiento de cualquier cambio en la configuración del cortafuegos o del proxy que pueda afectar a Tulip y, en el mejor de los casos, se prueba con https://your-account.tulip.co/networkCheck durante las ventanas de cambio.

Arquitectura de aplicaciones resiliente

En esta sección se explica cómo los desarrolladores pueden mitigar los riesgos de la infraestructura.

Los desarrolladores deben diseñar aplicaciones que sean resilientes ante problemas de red intermitentes. Es fundamental garantizar un margen de maniobra para la latencia de red y la degradación menor de la plataforma. Utiliza automatizaciones (y/o funciones siempre que sea posible).

• Prioriza las escrituras en tablas de Tulip: para toda captura de datos críticos, utiliza primero en tu disparador las acciones nativas de Tulip Table «Create Record» o «Store». Estas acciones son más resilientes ante fallos puntuales de red y cuentan con una lógica de reintento integrada (hasta 2 minutos en LTS15).
• Minimiza la frecuencia de eventos: revisa el diseño de tu aplicación. Si un operador puede generar razonablemente 100 eventos (por ejemplo, escaneos) durante una interrupción de red de 2 minutos, tu arquitectura corre un alto riesgo. Considera agrupar las entradas por lotes o simplificar el flujo de trabajo.
• Sigue las prácticas recomendadas de rendimiento: sigue las directrices documentadas para aplicaciones de alto rendimiento que encontrarás aquí. Sobrecargar la plataforma con llamadas de alta frecuencia genera una latencia interna que se asemeja a una red deficiente.

Véase también: Desencadenantes de aplicaciones basados en eventos a través de la máquina «virtual» Tulip

Lista de comprobación

• [ ] Las tablas primero: toda la captura de datos críticos (escaneos, decisiones de los operadores, mediciones) se escribe primero en una tabla de Tulip.
• [ ] Sin llamadas largas a la API en los desencadenantes del operador: los desencadenantes orientados al operador no contienen operaciones de « Connector Functions » de larga duración ni lógica compleja de API externas.
• [ ] Patrón de desacoplamiento: se prefiere el uso de automatizaciones para realizar llamadas a API externas siempre que sea posible.
• [ ] Campos de estado: Las tablas de procesamiento utilizan campos de estado claros (pendiente, en procesamiento, procesado, error) para que los fallos puedan reintentarse o investigarse.
• [ ] Frecuencia de eventos controlada: El diseño de la aplicación no permite a los operadores generar frecuencias de eventos sostenidas que llenarían la cola durante interrupciones breves (véase el cálculo de interrupciones más arriba).
• [ ] Temporizadores y bucles: Los disparadores de temporizador y los bucles no se activan a intervalos innecesariamente cortos (por ejemplo, cada 1-5 segundos) a menos que sea absolutamente necesario y se haya validado.
• [ ] Gestión de errores de los conectores: los conectores de datos ( Connector Functions ) que puedan fallar debido a problemas de red cuentan con mecanismos de gestión de errores y de reintento (preferiblemente a través de automatizaciones, no de activadores de operador).
• [ ] Prácticas recomendadas de rendimiento: Las aplicaciones se ajustan a las prácticas recomendadas de Tulip para aplicaciones de alto rendimiento.

Configuración técnica y resolución de problemas

Si tu red no cumple los requisitos cuantificables descritos anteriormente, o si experimentas problemas de rendimiento que sospechas que están relacionados con la red, sigue los pasos de nuestra guía detallada. Esta guía ofrece un diagrama de flujo priorizado para diagnosticar y resolver problemas de rendimiento de la red, desde comprobaciones básicas hasta análisis avanzados a nivel de paquetes.

Consulta aquí la guía completa de resolución de problemas de red.

Utilidad de prueba de red y WebSocket

Tulip hace un uso extensivo de los WebSockets, un tipo de conexión de larga duración, para permitir actualizaciones en tiempo real. Estos WebSockets utilizan cifrado SSL a través del puerto 443. Algunos proxies no admiten estas conexiones, y es posible que algunos monitores de red deban permitirlas explícitamente. Consulta la sección anterior para comprobar la compatibilidad.

Hay disponible una sencilla utilidad que te ayudará a comprobar la latencia de tu conexión de red y la compatibilidad con WebSockets:

• https://your-account.tulip.co/networkCheckOR
• https://your-account.dmgmori-tulip.com/networkCheckOR
• https://your-account.tulip-serendie.com/networkCheck

Lista de comprobación para la puesta en marcha y la supervisión continua

• [ ] Prueba inicial: para cada nueva estación, ejecuta https://your-account.tulip.co/networkCheck (o la URL de DMG MORI / Serendie) y tus propias pruebas de diagnóstico durante al menos 10-15 minutos con una carga de producción normal.
• [ ] Registrar métricas: Anote la latencia media, mínima y máxima, la fluctuación y cualquier pérdida de paquetes observada; compruebe que cumplen los umbrales indicados en este artículo.
• [ ] Prueba de carga máxima: Repite la prueba durante un periodo conocido de carga máxima en la red de la fábrica (cambio de turno, procesamiento de lotes grandes) para garantizar la estabilidad bajo estrés.
• [ ] Pruebas de regresión tras cambios: Vuelve a ejecutar la prueba tras cualquier cambio significativo en la configuración de la red, el WiFi, el cortafuegos o el proxy que afecte a Tulip.
• [ ] Almacenamiento de referencia: Guarda los resultados de las pruebas (capturas de pantalla o exportaciones) como parte de tus registros de validación y puesta en servicio.
• [ ] Revalidación periódica: programa nuevas pruebas periódicas (por ejemplo, trimestrales) para las estaciones críticas o cuando se implementen nuevas aplicaciones con mayores tasas de eventos.

¿Has encontrado lo que buscabas?

¡También puedes visitar community.tulip.co para publicar tu pregunta o ver si otros usuarios se han enfrentado a un problema similar!