Fault Tolerance

La pestaña FAULT TOLERANCE le permite definir reglas de tolerancia a fallas para un servicio específico, así como administrar las reglas ya creadas. Para acceder a él, seleccione el servicio para el que desea crear una regla en la lista de la pantalla Services (o después de hacer clic en una malla en la pantalla Meshes).

Pestaña «Fault Tolerance»

La creación de tales reglas hace que su sistema de microservicios sea más resistente, lo que limita el impacto de fallas, los picos de latencia y otros problemas de la red.

Para crear una nueva regla para el servicio seleccionado, haga clic en el botón ADD NEW RULE. A continuación, aparecerá un menú con cuatro funciones: Circuit Breaker, Request Timeout, Fault Injection y Retry.

Dado que Sensedia Service Mesh es una aplicación Kubernetes-native, también es posible configurar estas reglas desde la línea de comando usando kubectl. El recuadro «Creando una regla desde la línea de comando» en la sección de cada funcionalidad contiene un archivo .yaml de ejemplo para hacerlo.

Vea cómo configurar una regla para cada uno de ellos a continuación.

Permisos de acceso

Las acciones que puede realizar en esta pantalla dependen de los permisos establecidos para su usuario en Sensedia Access Control.

La siguiente tabla muestra los posibles permisos y sus acciones:

Permiso	Descripción
List Circuit Breakers	Permite ver en la lista de reglas la información básica de una regla de Circuit Breaker creada para un servicio.
List Fault Injections	Permite ver en la lista de reglas la información básica de una regla de Fault Injection creada para un servicio.
List Timeouts	Permite ver en la lista de reglas la información básica de una regla de Request Timeout creada para un servicio.
List Retries	Permite ver en la lista de reglas la información básica de una regla de Retry creada para un servicio.
Read Circuit Breakers	Permite ver la configuración de una regla de Circuit Breaker creada para un servicio. Sin embargo, no permite la edición de la regla.
Read Fault Injections	Permite ver la configuración de una regla de Fault Injection creada para un servicio. Sin embargo, no permite la edición de la regla.
Read Timeouts	Permite ver la configuración de una regla de Request Timeout creada para un servicio. Sin embargo, no permite la edición de la regla.
Read Retries	Permite ver la configuración de una regla de Retry creada para un servicio. Sin embargo, no permite la edición de la regla.
Write Circuit Breakers	Permite editar, eliminar y crear una regla de Circuit Breaker para un servicio.
Write Fault Injections	Permite editar, eliminar y crear una regla de Fault Injection para un servicio.
Write Timeouts	Permite editar, eliminar y crear una regla de Request Timeout para un servicio.
Write Retries	Permite editar, eliminar y crear una regla de Retry para un servicio.

Permiso

Descripción

List Circuit Breakers

Permite ver en la lista de reglas la información básica de una regla de Circuit Breaker creada para un servicio.

List Fault Injections

Permite ver en la lista de reglas la información básica de una regla de Fault Injection creada para un servicio.

List Timeouts

Permite ver en la lista de reglas la información básica de una regla de Request Timeout creada para un servicio.

List Retries

Permite ver en la lista de reglas la información básica de una regla de Retry creada para un servicio.

Read Circuit Breakers

Permite ver la configuración de una regla de Circuit Breaker creada para un servicio. Sin embargo, no permite la edición de la regla.

Read Fault Injections

Permite ver la configuración de una regla de Fault Injection creada para un servicio. Sin embargo, no permite la edición de la regla.

Read Timeouts

Permite ver la configuración de una regla de Request Timeout creada para un servicio. Sin embargo, no permite la edición de la regla.

Read Retries

Permite ver la configuración de una regla de Retry creada para un servicio. Sin embargo, no permite la edición de la regla.

Write Circuit Breakers

Permite editar, eliminar y crear una regla de Circuit Breaker para un servicio.

Write Fault Injections

Permite editar, eliminar y crear una regla de Fault Injection para un servicio.

Write Timeouts

Permite editar, eliminar y crear una regla de Request Timeout para un servicio.

Write Retries

Permite editar, eliminar y crear una regla de Retry para un servicio.

Circuit Breaker

Circuit Breaker (disyuntor) es un mecanismo que permite limitar el impacto de fallas y retrasos en la red, rechazando nuevas peticiones cuando se alcanzan ciertos límites. Una de las ventajas de tener un disyuntor configurado es que al interrumpir un flujo de comunicación defectuoso, se evita la propagación en cadena de las fallas. Puede establecer límites de llamadas para hosts individuales en un servicio, como la cantidad de conexiones simultáneas o llamadas fallidas realizadas a ese host. También puede configurar la regla para detectar y eliminar temporalmente los hosts que presenten errores en la conexión.

Creando una regla de Circuit Breaker

En la pantalla Services (o en la pantalla Meshes, después de seleccionar la malla correspondiente), seleccione el servicio para el que desea crear la regla.

Haga clic en la pestaña FAULT TOLERANCE y luego en el botón ADD NEW RULE. Seleccione la opción Circuit Breaker.

Aparecerá una pantalla con dos opciones: CONNECTION POOL y OUTLIER DETECTION.

Opciones de disyuntores

Estas opciones requieren una configuración específica, que se mostrará cuando se active la opción correspondiente.

Connection Pool

La configuración de la opción CONNECTION POOL permite rechazar nuevas peticiones cuando el número de conexiones simultáneas y el número de peticiones superan los valores informados.

Puede configurar la regla para peticiones HTTP, peticiones TCP o ambas:

Configuración del disyuntor por Connection Pool

Para el caso de las peticiones HTTP, los campos a rellenar son:

Max Requests Per Connection: número máximo de peticiones por conexión.
Max Pending Requests: número máximo de peticiones pendientes (en cola).

Para las peticiones TCP, deben introducirse los siguientes valores:

Max Connections: número máximo de conexiones simultáneas.
TCP connection timeout: tiempo de espera para una conexión TCP. Debe informarse en formato de duración (ejemplos: 1h, 1m, 1s, 1ms).

Outlier Detection

La funcionalidad de outlier detection monitorea el estado de cada host y elimina de la conexión el que presenta un cierto número de errores consecutivos.

Configuración del disyuntor por Outlier Detection

Para configurar la opción OUTLIER DETECTION, es necesario completar los siguientes campos:

Base Ejection Time: duración mínima de eyección. El host permanecerá retirado durante un periodo de tiempo igual al producto de la duración mínima de eyección y el número de veces que ya ha sido retirado.
Consecutive Errors: número de errores consecutivos para que un host sea retirado de la conexión.
Injection Analysis Interval: intervalo de tiempo entre cada exploración de análisis.
Max Ejection Percent: porcentaje máximo de hosts que pueden ser eyectados.

Una vez que haya rellenado los campos, haga clic en el botón SAVE para crear la regla.

Es posible combinar las funcionalidades de connection pool y outlier detection en la misma regla.

Creando una regla desde la línea de comando

Para crear una regla de circuit breaker a través de kubectl, aplica un archivo .yaml como el del siguiente ejemplo:

apiVersion: networking.sensedia.com/v1
kind: CircuitBreaker
metadata:
  name: players-cb
spec:
  connectionPool:
    http:
      http1MaxPendingRequests: 1
      maxRequestsPerConnection: 1
    tcp:
      connectTimeout: 10ms
      maxConnections: 1
  enabled: true
  outlierDetection:
    baseEjectionTime: 3m
    consecutive5xxErrors: 1
    interval: 1s
    maxEjectionPercent: 100
  serviceName: players

La configuración de la regla en este archivo se realiza a través de los siguientes campos:

.kind: especifica el tipo de objeto que se va a crear; en este caso, un objeto del tipo CircuitBreaker;
.metadata.name: define un nombre para identificar el recurso;
.spec.enabled: habilita (enabled: true) o deshabilita (enabled: false) la regla;
.spec.serviceName: especifica el servicio para el que se creará la regla;

Los campos de .spec.connectionPool se refieren a la configuración de la opción Connection Pool:

.spec.connectionPool.http.http1MaxPendingRequests: número máximo de peticiones que se pondrán en cola;
.spec.connectionPool.http.maxRequestsPerConnection: número máximo de peticiones por conexión;
.spec.connectionPool.tcp.connectTimeout: tiempo de espera para una conexión TCP, en formato de duración;
.spec.connectionPool.tcp.maxConnections: número máximo de conexiones simultáneas.

Los campos de .spec.outlierDetection se refieren a la configuración de la opción Outlier Detection:

.spec.outlierDetection.baseEjectionTime: duración mínima de eyección del host;
.spec.outlierDetection.consecutive5xxErrors: número de errores consecutivos aceptados antes de que un host sea retirado de la conexión;
.spec.outlierDetection.interval: intervalo de tiempo entre cada exploración de análisis;
.spec.outlierDetection.maxEjectionPercent: porcentaje máximo de hosts que pueden ser eyectados.

En una regla, es posible configurar solo una opción de circuit breaker (Connection Pool o Outlier Detection) o ambas opciones.

Gestión de una regla creada

Al crear la regla, será redirigido a la pantalla de visualización de la pestaña FAULT TOLERANCE del servicio correspondiente, donde podrá gestionar la regla creada.

Visualización de una regla de Circuit Breaker creada

Esta pantalla muestra la siguiente información sobre la regla:

valores establecidos para connection pool (columna CONNECTION POOL);
valores establecidos para outlier detection (columna OUTLIER DETECTION);
estado de la regla, que puede ser «aprovisionado» (PROVISIONED) o «desactivado» (DISABLED) — (columna STATUS);
fecha y hora de creación de la regla (columna CREATED AT).

Además de ver esta información, es posible deshabilitar o habilitar la regla mediante el botón situado en la columna ENABLED.

A través de los iconos contenidos en la columna ACTIONS puede:

editar la configuración de la regla ();
eliminar la regla ().

Solo es posible tener una regla de Circuit Breaker configurada por servicio. Si ya ha creado una, la opción «Circuit Breaker» ya no estará disponible en la lista del botón ADD NEW RULE para ese servicio.

Ejemplo de configuración

En el ejemplo que se muestra en la imagen a continuación, estamos configurando un disyuntor para limitar el número de conexiones, peticiones por conexión y de peticiones pendientes en uno y el tiempo de conexión TCP en 10 milisegundos. Además, establecemos la regla para verificar los hosts en busca de posibles fallas cada 1 segundo y para eliminar un host del load balancing pool durante al menos 3 minutos si obtiene un error 5xx. En el último caso, permitimos que se elimine hasta el 100% de los hosts.

Ejemplo de configuración de Circuit Breaker

Request Timeout

La funcionalidad Request Timeout permite tratar la latencia en las llamadas a los servicios de forma sencilla. El hecho de que un servicio tarde más de lo habitual en responder puede afectar a todo el sistema, ya que este retraso se propagará a través de la red. Al establecer una regla de request timeout se especifica el tiempo máximo de espera de una respuesta de un servicio determinado. Si una llamada a este servicio tarda más del tiempo especificado en completarse, se terminará (se devuelve un error «timeout»). Por lo tanto, este retraso no afecta a otros microservicios y no impacta en el tiempo de respuesta de la aplicación en su conjunto.

Configurar una regla de request timeout en Sensedia Service Mesh es sencillo, como se muestra a continuación.

Creación de una regla de Request Timeout

En la pantalla Services (o en la pantalla Meshes, después de seleccionar la malla correspondiente), seleccione el servicio para el que desea crear la regla.

Haga clic en la pestaña FAULT TOLERANCE y luego en el botón ADD NEW RULE. Seleccione la opción Request Timeout.

En la siguiente pantalla, deberá completar un solo campo:

Duration: tiempo de espera para que se complete una petición. El valor debe ser informado en formato de duración (ejemplos: 1m, 1s, 1ms).

Creación de una regla de Request Timeout

Después de completar el campo, haga clic en el botón SAVE para crear la regla.

Creando una regla desde la línea de comando

Para configurar una regla de request timeout desde la línea de comando, simplemente aplique un archivo .yaml como el del ejemplo siguiente a través de kubectl:

  apiVersion: networking.sensedia.com/v1
  kind: Timeout
  metadata:
    name: timeout-matches
  spec:
    serviceName: matches
    duration: 1s

En este archivo, el tipo de objeto Timeout se especifica en el campo .kind y el tiempo de espera para las peticiones (el timeout), en el campo .spec.duration (es el mismo parámetro introducido en el campo Duration de la interfaz de Sensedia Service Mesh).

En el campo .spec.serviceName debe especificar el servicio para el cual se creará la regla.

En el campo .metadata.name debe introducir un nombre para identificar el recurso.

El ejemplo en el archivo anterior define un timeout de un segundo para el servicio matches.

Gestión de una regla creada

Cuando se crea una regla desde la interfaz de Sensedia Service Mesh o desde la línea de comando, puede visualizarla en la pestaña FAULT TOLERANCE del servicio correspondiente.

Visualización de una regla de Request Timeout creada

Aquí se presenta la siguiente información sobre la regla:

valor especificado para el parámetro Duration (columna DURATION);
estado de la regla, que puede ser «aprovisionado» (PROVISIONED) o «desactivado» (DISABLED) — (columna STATUS);
fecha y hora de creación de la regla (columna CREATED AT).

Además, es posible desactivar o activar la regla mediante el botón situado en la columna ENABLED.

A través de los iconos contenidos en la columna ACTIONS puede:

actualizar la configuración de la regla ();
eliminar la regla ().

Solo puede tener una regla de Request Timeout por servicio. Si ya ha creado una, la opción «Request Timeout» ya no estará disponible en la lista del botón ADD NEW RULE para ese servicio.

Fault Injection

La funcionalidad Fault Injection permite configurar la inyección de fallas en la red. Con esto, puede probar la resistencia de su sistema de microservicios y ver el impacto de posibles fallas en la aplicación en su conjunto. Es útil, por ejemplo, para verificar que sus políticas de recuperación de fallas son adecuadas para su sistema, evitando así la falta continua de disponibilidad de los servicios esenciales en su aplicación.

Creación de una regla de Fault Injection

En la pantalla Services (o en la pantalla Meshes, después de seleccionar la malla correspondiente), seleccione el servicio para el que desea crear la regla.

Haga clic en la pestaña FAULT TOLERANCE y luego en el botón ADD NEW RULE. Seleccione la opción Fault Injection.

A continuación se mostrará una pantalla con dos opciones de fallas: HTTP ABORT y HTTP DELAY. Los campos a completar dependen del tipo de falla a configurar.

Opciones de Fault Injection

HTTP Abort

Al configurar la opción HTTP ABORT, puede observar cómo se comportará su aplicación cuando surjan fallas HTTP en el sistema. Puede especificar el código de estado HTTP que se devolverá, así como el porcentaje de peticiones que se verán afectadas por la falla.

Configuración de la inyección de HTTP Abort

La configuración de la inyección de HTTP Abort requiere completar los siguientes campos:

HTTP Status Code: código de estado HTTP que se devolverá para las peticiones al servicio correspondiente. Ejemplo: 503.
Requests percent: porcentaje de peticiones que se abortarán con el código de error especificado en el campo HTTP Status Code. El valor introducido debe ser un número entero mayor que cero.

HTTP Delay

Configurar la opción HTTP DELAY le permite agregar un retraso en la respuesta de un servicio específico. Con esto, es posible simular el aumento de la latencia de la red o la situación de sobrecarga de un servicio.

Configuración de la inyección de HTTP Delay

Los siguientes campos son obligatorios para configurar la inyección de HTTP Delay:

Fixed Delay: retraso que se agregará al tiempo de respuesta del servicio. El valor debe ser informado en el formato de duración. Ejemplos: 1h, 1m, 1s, 1ms.
Requests percent: porcentaje de peticiones en las que se inyectará el retraso. El valor introducido debe ser un número entero mayor que cero.

Una vez que haya completado los campos necesarios para el tipo de falla que desea, haga clic en el botón SAVE para crear la regla.

Es posible combinar los dos tipos de fallas (HTTP Abort y HTTP Delay) en la misma regla.

Creando una regla desde la línea de comando

También es posible crear una regla de fault injection mediante kubectl, aplicando un archivo .yaml como el del siguiente ejemplo:

  apiVersion: networking.sensedia.com/v1
  kind: FaultInjection
  metadata:
    name: fault-injection
  spec:
    serviceName: matches
    enabled: true
    abort:
      httpStatusCode: 500
      percentage:
        value: 10
    delay:
      fixedDelay: 2s
      percentage:
        value: 10

La configuración de la regla en este archivo se realiza a través de los siguientes campos:

.kind: especifica el tipo de objeto a crear; en este caso, FaultInjection;
.metadata.name: define un nombre para identificar el recurso;
.spec.serviceName: se utiliza para especificar el servicio para el que se creará la regla;
.spec.enabled: le permite habilitar (enabled: true) o deshabilitar (enabled: false) la regla;
.spec.abort.httpStatusCode: campo para especificar el código de estado HTTP que se devolverá al configurar la inyección de HTTP Abort;
.spec.abort.percentage.value: especifica el porcentaje de peticiones que se abortarán al configurar la inyección de HTTP Abort;
.spec.delay.fixedDelay: define el retraso que se añadirá al tiempo de respuesta del servicio al configurar la inyección de HTTP Delay;
.spec.delay.percentage.value: porcentaje de peticiones en las que se inyectará el retraso al configurar la inyección de HTTP Delay.

El archivo .yaml del ejemplo anterior establece una regla de fault injection que añade un retraso de dos segundos al 10% de las llamadas realizadas al servicio matches y define que el 10% de las peticiones a este servicio serán abortadas con el código de estado HTTP 500.

Es posible, en una regla, definir un solo tipo de falla (HTTP Abort o HTTP Delay) o combinar los dos tipos (HTTP Abort y HTTP Delay).

Gestión de una regla creada

La regla de fault injection creada será visible en la pantalla de visualización de la pestaña FAULT TOLERANCE del servicio correspondiente.

Visualización de la regla de Fault Injection creada

Aquí puede ver la siguiente información sobre la regla:

valores establecidos para HTTP Delay (columna DELAY). Si esta opción no se ha definido en la regla, se muestra el mensaje «Not defined»;
valores establecidos para HTTP Abort (columna ABORT). Si esta opción no se ha definido en la regla, se muestra el mensaje «Not defined»;
estado de la regla, que puede ser «aprovisionado» (PROVISIONED) o «desactivado» (DISABLED) — (columna STATUS);
fecha y hora de creación de la regla (columna CREATED AT).

El botón situado en la columna ENABLED le permite deshabilitar o habilitar la regla.

A través de los iconos contenidos en la columna ACTIONS puede:

editar la configuración de la regla ();
eliminar la regla ().

Solo es posible tener configurada una regla de Fault Injection por servicio. Si ya existe una, la opción «Fault Injection» ya no estará disponible en la lista del botón ADD NEW RULE para ese servicio.

Retry

La funcionalidad Retry le permite determinar el número máximo de reintentos para conectarse a un servicio en caso de que falle una llamada. El objetivo de esta funcionalidad es evitar que las llamadas a un servicio fallen de forma permanente debido a problemas temporales de red o servicio. El ajuste adecuado de los parámetros de Retry es importante para garantizar que los microservicios estén disponibles y evitar que los reintentos mal configurados ralenticen la respuesta de la aplicación.

A continuación se explica cómo configurar una regla de Retry para un servicio específico en Sensedia Service Mesh.

Creación de una regla de Retry

En la pantalla Services de la interfaz de Sensedia Service Mesh (o en la pantalla Meshes, después de seleccionar la malla correspondiente), seleccione el servicio para el que desea crear la regla.

Haz clic en la pestaña FAULT TOLERANCE y luego en el botón ADD NEW RULE. Selecciona la opción Retry.

Se abrirá una ventana modal con dos campos para configurar la regla:

Creación de una regla de Retry a través de la interfaz de Sensedia Service Mesh

Los campos disponibles para completar en esta pantalla son los siguientes:

Retry quantity: número máximo de reintentos de conexión al servicio correspondiente si la llamada inicial falla. Campo obligatorio.
Per try timeout: Tiempo de espera de éxito de conexión en cada reintento. Este campo es opcional. Debe indicarse como duración (ejemplos: 1m, 1s, 1ms).

Después de introducir los valores deseados, haga clic en el botón SAVE para crear la regla.

Creando una regla desde la línea de comando

Para crear una regla de Retry mediante kubectl, aplica un archivo .yaml como en el siguiente ejemplo:

apiVersion: networking.sensedia.com/v1
kind: Retry
metadata:
  name: my-service-retry
  namespace: test
spec:
  enabled: true
  perTryTimeout: 1s
  quantity: 2
  serviceName: my-service

La configuración de la regla en este archivo se realiza a través de los siguientes campos:

.kind: tipo de objeto a crear;
.metadata.name: nombre para identificar el recurso;
.metadata.namespace: namespace en el que se creará el recurso;
.spec.enabled: habilita (enabled: true) o deshabilita (enabled: false) la regla;
.spec.perTryTimeout: tiempo de espera para el éxito de la conexión, incluida la llamada inicial y los reintentos. Debe indicarse como duración (ejemplos: 1m, 1s, 1ms);
.spec.quantity: número máximo de reintentos de conexión al servicio correspondiente si la llamada inicial falla;
.spec.serviceName: servicio al que se aplicará la regla.

El ejemplo del archivo anterior define un número máximo de dos reintentos de conexión al servicio my-service si la llamada inicial falla, cada uno con un tiempo de espera de 1 segundo.

Gestión de una regla creada

Una regla de Retry creada aparecerá en la pantalla de vista previa de la pestaña FAULT TOLERANCE para el servicio correspondiente:

Visualización de una regla de Retry creada

En esta pantalla se muestra la siguiente información sobre la regla:

valor especificado para el parámetro «Retry quantity» (columna QUANTITY);
valor especificado para el parámetro «Per try timeout» (columna TIMEOUT);
estado de la regla, que puede ser «aprovisionado» (PROVISIONED) o «deshabilitado» (DISABLED) — (columna STATUS);
fecha y hora de creación de la regla (columna CREATED AT).

Además de ver esta información, puedes deshabilitar o habilitar la regla a través del botón ubicado en la columna ENABLED.

La columna ACTIONS contiene iconos que te permiten:

editar la configuración de la regla ();
eliminar la regla ().

Solo puedes tener una regla de Retry por servicio. Si ya has creado una, la opción «Retry» ya no estará disponible en la lista del botón ADD NEW RULE para ese servicio.

Thanks for your feedback!

EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]