Cómo funciona el orden de recuperación de almacenar y reenviar

Dos flujos al reconectar: rezago y datos en vivo

En el momento en que se restaura el enlace de un colector al archivo, este tiene un rezago de valores amortiguados que abarcan la interrupción, y a la vez sigue reuniendo valores nuevos en tiempo real. El orden de recuperación es la política que decide cómo se entrelazan y entregan estos dos flujos. Es un problema genuinamente delicado porque los dos flujos se traslapan de una manera que puede confundir al archivo: el rezago lleva marcas de tiempo viejas de durante la interrupción, mientras que el flujo en vivo lleva marcas de tiempo actuales, y entregarlos con descuido puede producir escrituras que saltan atrás y adelante en el tiempo de un modo que el archivo no fue diseñado para manejar con gracia.

La razón por la que esto merece su propia atención, aparte del búfer mismo y de cómo un cliente espera antes de reconectar, es que el comportamiento de recuperación es lo que de verdad mete los datos de la interrupción al archivo correctamente. Un colector podría tener un búfer perfectamente dimensionado que retuvo cada valor durante la interrupción, y aun así corromper la recuperación si volcó ese rezago en el orden equivocado o todo de golpe. El orden de recuperación es la disciplina que convierte un rezago retenido en un relleno limpio de historia en lugar de un desastre de escrituras demoradas y desordenadas que complican cada consulta y cálculo posterior.

Lo que está en juego es máximo para cualquier cosa que lea la historia en orden de tiempo o agregue sobre intervalos. Un total diario, una tendencia, o cualquier cálculo que recorra el archivo cronológicamente depende de que los datos lleguen de una manera que el archivo pueda indexar correctamente por marca de tiempo. Si la recuperación dispersa el rezago sin considerar el orden, el archivo puede almacenar los valores pero presentarlos de forma incómoda, y los consumidores aguas abajo que asumieron un registro cronológico ordenado pueden producir resultados equivocados. Acertar el orden de recuperación es por tanto sobre proteger no solo la presencia de los datos sino su usabilidad.

Drenaje del más antiguo primero y manejo de valores en vivo

El enfoque natural y común es reenviar el rezago amortiguado del más antiguo primero, reproduciendo el período de la interrupción en orden cronológico para que el archivo se rellene desde el inicio del hueco hacia el presente. El drenaje del más antiguo primero significa que el registro del archivo crece hacia adelante en el tiempo conforme se entrega el rezago, lo que coincide con cómo se produjeron originalmente los datos y con cómo el archivo espera que le escriban. También significa que en cualquier punto durante la recuperación, el archivo tiene una historia contigua y correcta hasta algún punto de la interrupción, con el hueco restante encogiéndose desde el extremo lejano, en lugar de un mosaico de puntos dispersos.

Mientras el rezago drena, el colector aún tiene que manejar los valores en vivo que sigue recolectando, y cómo concilia los dos importa. Un enfoque es dar prioridad al flujo en vivo para que los datos actuales nunca se demoren por ponerse al día, mientras el rezago se rellena por detrás; otro es completar el drenaje cronológico para que la historia se reconstruya estrictamente en orden. De cualquier modo, el colector tiene que evitar producir escrituras que el archivo no pueda ordenar, y por eso las marcas de tiempo que lleva cada valor son esenciales: mientras cada valor, del rezago o en vivo, lleve su verdadera hora de recolección, el archivo puede colocarlo correctamente aun si la entrega no es perfectamente secuencial. El objetivo de diseño es entregar el rezago sin nunca perder ni demorar el presente en vivo de forma inaceptable.

La interacción con los datos en vivo es justo por lo que el orden de recuperación es más que solo reproducir un búfer. Si el colector simplemente disparara todo su rezago primero e ignorara la recolección en vivo hasta terminar, los datos actuales se estancarían por lo que dure la recuperación, lo que para una interrupción larga podría significar que el sitio parezca congelado mucho después de que el enlace volvió. A la inversa, si solo reenviara datos en vivo y nunca drenara el rezago, el hueco de la interrupción nunca se rellenaría. Un orden de recuperación viable hace ambas cosas, entregando el rezago de forma constante mientras mantiene fluyendo el flujo en vivo, para que el archivo termine tanto actual como completo.

Limitación del vaciado y recuperación en una flota SCADA

Un peligro sutil al reconectar es que un colector con un rezago grande puede abrumar al archivo intentando entregar todo lo más rápido posible. Si muchos valores llegan en una ráfaga, o si muchos colectores a lo largo de una flota se reconectan a la vez tras un evento de red compartido, la súbita inundación de escrituras de puesta al día puede sobrecargar el archivo, hacerlo lento para todos, o incluso disparar más fallas. La limitación del vaciado es el mecanismo que marca el ritmo del drenaje: el colector reenvía su rezago a una tasa controlada en lugar de tan rápido como el enlace permita, para que la recuperación sea constante y el archivo siga el paso tanto de la puesta al día como de la carga en vivo continua de cada fuente.

La limitación es un equilibrio, porque drenar demasiado despacio significa que el hueco de la interrupción persiste sin rellenar por más tiempo del necesario, mientras que drenar demasiado rápido arriesga la sobrecarga que se pretende prevenir. Una recuperación sensata marca el ritmo del vaciado para avanzar bien en el rezago sin empujar al archivo más allá de lo que puede absorber junto con la operación normal, y puede adaptar la tasa a cómo el archivo va aguantando. El punto es que la recuperación debe ser una puesta al día controlada que converja en un archivo completo y actual, no una estampida que cambie el problema de la interrupción por un problema de sobrecarga.

Esta disciplina de limitación se vuelve esencial a la escala de una flota SCADA, donde un solo evento aguas arriba, como un hipo de red central, puede tumbar el enlace del archivo para muchos colectores de campo a la vez y luego, cuando el enlace vuelve, hacer que todos intenten vaciar sus rezagos simultáneamente. Sin limitación, la recuperación de una interrupción puede convertirse en cascada hacia una sobrecarga que parece una segunda interrupción. Una plataforma como Merobix gestiona la recuperación para que muchos colectores que se reconectan juntos drenen sus búferes de una manera ordenada y a ritmo que rellena cada hueco cronológicamente sin abrumar al archivo. El resultado es que tras incluso una interrupción amplia el historiador converge en un registro completo y correctamente ordenado, que es precisamente lo que los operadores necesitan para confiar en los datos de un gran sistema distribuido.

Preguntas frecuentes