Skip to main content
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Coherencia

Colaboradores netapp-lhalbert
PDF

La consistencia proporciona un equilibrio entre la disponibilidad de los objetos y la coherencia de dichos objetos en distintos nodos de almacenamiento y sitios. Puede cambiar la consistencia según lo requiera la aplicación.

De forma predeterminada, StorageGRID garantiza la consistencia de lectura tras escritura para los objetos recién creados. Cualquier operación GET posterior a una operación PUT completada con éxito podrá leer los datos recién escritos. Las sobrescrituras de objetos existentes, las actualizaciones de metadatos y las eliminaciones son eventualmente consistentes.

Si desea realizar operaciones de objeto en otra coherencia, puede:

  • Especificar una consistencia paracada cucharón .

  • Especifique una consistencia para Cada operación de API.

  • Cambie la consistencia predeterminada en toda la cuadrícula realizando una de las siguientes tareas:

    • En el Administrador de cuadrícula, vaya a Configuración > Sistema > Configuración de almacenamiento > Consistencia del depósito predeterminado.

    • .

      Nota Un cambio en la consistencia de toda la cuadrícula se aplica solo a los depósitos creados después de que se haya cambiado el valor. Para determinar los detalles de un cambio, consulte el registro de auditoría ubicado en /var/local/log (busque consistencyLevel).

Valores de coherencia

La consistencia afecta cómo se distribuyen los metadatos que StorageGRID utiliza para rastrear objetos entre los nodos. La consistencia afecta la disponibilidad de los objetos para las solicitudes del cliente.

Puede establecer la coherencia de un bloque o una operación de API en uno de los valores siguientes:

  • Todos: Todos los nodos reciben metadatos de objeto inmediatamente o la solicitud fallará.

  • Strong-global: garantiza la consistencia de lectura después de escritura para todas las solicitudes de clientes en todos los sitios. Cuando se configura la semántica de quórum, se aplican los siguientes comportamientos:

    • Permite la tolerancia a fallas del sitio para las solicitudes de los clientes cuando las redes tienen tres o más sitios. Las redes de dos sitios no tendrán tolerancia a fallas del sitio.

    • Las siguientes operaciones S3 no tendrán éxito si un sitio está inactivo:

      • DeleteBucketEncryption

      • PonerBucketBranch

      • PutBucketEncryption

      • PutBucketVersioning

      • PutObjectLegalHold

      • PutObjectLockConfiguration

      • PutObjectRetention

    Si es necesario, puedes "Configurar la semántica de quórum de StorageGRID para lograr una consistencia global sólida" .

  • Strong-site: Los metadatos de objetos se distribuyen inmediatamente a otros nodos en el sitio. Garantiza la coherencia de lectura tras escritura para todas las solicitudes del cliente dentro de un sitio.

  • Read-after-new-write: Proporciona consistencia de lectura después de escritura para nuevos objetos y consistencia eventual para actualizaciones de objetos. Ofrece garantías de alta disponibilidad y protección de datos. Recomendado para la mayoría de los casos.

  • Disponible: Proporciona consistencia eventual tanto para nuevos objetos como para actualizaciones de objetos. Para los cubos S3, utilice solo según sea necesario (por ejemplo, para un depósito que contiene valores de registro que rara vez se leen, o para operaciones HEAD u GET en claves que no existen). No se admite para bloques de FabricPool S3.

Utilice los elementos de consistencia «Read-after-new-write» y «available»

Cuando una operación de CABEZAL u OBTENCIÓN utiliza la consistencia de lectura después de nueva escritura, StorageGRID realiza la búsqueda en varios pasos de la siguiente manera:

  • Primero busca el objeto con una baja consistencia.

  • Si esa búsqueda falla, repite la búsqueda en el siguiente valor de consistencia hasta que alcanza una consistencia equivalente al comportamiento para strong-global.

Si una operación HEAD u GET utiliza la coherencia «Read-after-new-write» pero el objeto no existe, la búsqueda de objetos siempre alcanzará una coherencia equivalente al comportamiento de un nivel global sólido. Debido a que esta consistencia requiere que haya disponibles varias copias de los metadatos del objeto en cada sitio, puede recibir un número elevado de errores de servidor interno 500 si hay dos o más nodos de almacenamiento en el mismo sitio disponibles.

A menos que necesite garantías de consistencia similares a Amazon S3, puede evitar estos errores para las operaciones HEAD y GET estableciendo la consistencia en “Disponible”. Cuando una operación de CABEZAL u OBTENCIÓN utiliza la consistencia «disponible», StorageGRID solo proporciona consistencia eventual. No vuelve a intentar una operación fallida en el aumento de la coherencia, por lo que no es necesario que haya varias copias de los metadatos del objeto disponibles.

Especifique la consistencia para el funcionamiento de la API

Para configurar la coherencia de una operación de API individual, los valores de coherencia deben ser compatibles con la operación y debe especificar la coherencia en el encabezado de solicitud. Este ejemplo establece la coherencia en «sitio fuerte» para una operación GetObject.

GET /bucket/object HTTP/1.1
Date: date
Authorization: authorization name
Host: host
Consistency-Control: strong-site
Nota Debe utilizar la misma consistencia para las operaciones PutObject y GetObject.

Especificar la consistencia para el depósito

Para configurar la coherencia del bloque, puede usar la solicitud StorageGRID"PONGA la consistencia del cucharón". O puede "cambiar la consistencia de un cucharón" hacerlo desde el Administrador de inquilinos.

Al establecer la coherencia de un cucharón, tenga en cuenta lo siguiente:

  • La configuración de la coherencia de un bloque determina la coherencia que se usa para las operaciones S3 realizadas en los objetos del bloque o en la configuración de bloque. No afecta a las operaciones del propio cucharón.

  • La coherencia de una operación API individual anula la coherencia del bloque.

  • En general, los bloques deben utilizar la consistencia predeterminada «Read-after-new-write». Si las solicitudes no funcionan correctamente, cambie el comportamiento del cliente de aplicación si es posible. O bien, configure el cliente para especificar la consistencia de cada solicitud API. Defina la consistencia en el nivel del cucharón sólo como último recurso.

Cómo interactúan la consistencia y las reglas ILM para afectar la protección de datos

Tanto la elección de coherencia como la regla de ILM afectan al modo de protección de los objetos. Estos ajustes pueden interactuar.

Por ejemplo, la consistencia utilizada cuando se almacena un objeto afecta la ubicación inicial de los metadatos del objeto, mientras que el comportamiento de procesamiento seleccionado para la regla de ILM afecta la ubicación inicial de las copias de objetos. Dado que StorageGRID requiere acceso a los metadatos de un objeto y a sus datos para satisfacer las solicitudes de los clientes, seleccionar niveles de protección correspondientes para la coherencia y el comportamiento de ingesta puede proporcionar una mejor protección de datos inicial y respuestas del sistema más predecibles.

Los siguientes "opciones de procesamiento" se encuentran disponibles para las reglas de ILM:

Registro doble

StorageGRID realiza de inmediato copias provisionales del objeto y devuelve la operación correcta al cliente. Las copias especificadas en la regla ILM se realizan cuando es posible.

Estricto

Todas las copias especificadas en la regla de ILM deben realizarse antes de devolver correctamente al cliente.

Equilibrado

StorageGRID intenta realizar todas las copias especificadas en la regla de gestión del ciclo de vida de la información durante el procesamiento; si no es posible, se realizarán copias provisionales y se devolverán correctamente al cliente. Las copias especificadas en la regla ILM se realizan cuando es posible.

Ejemplo de cómo pueden interactuar la regla de consistencia e ILM

Supongamos que tiene una cuadrícula de tres sitios con la siguiente regla ILM y la siguiente consistencia:

  • Regla ILM: Crear tres copias de objetos, una en el sitio local y una en cada sitio remoto. Utilice el comportamiento de ingesta estricto.

  • Consistencia: Fuerte-global (los metadatos del objeto se distribuyen inmediatamente a múltiples sitios).

Cuando un cliente almacena un objeto en la red, StorageGRID realiza tres copias del objeto y distribuye metadatos a varios sitios antes de devolver el éxito al cliente.

El objeto está completamente protegido contra pérdida en el momento del mensaje de ingesta exitosa. Por ejemplo, si el sitio local se pierde poco después de la ingesta, aún existen copias de los datos y metadatos del objeto en los sitios remotos. El objeto es totalmente recuperable desde los otros sitios.

Si, en cambio, utilizara la misma regla ILM y la consistencia del sitio fuerte, el cliente podría recibir un mensaje de éxito después de que los datos del objeto se repliquen en los sitios remotos pero antes de que los metadatos del objeto se distribuyan allí. En este caso, el nivel de protección de los metadatos del objeto no coincide con el nivel de protección de los datos del objeto. Si el sitio local se pierde poco después de la ingesta, se pierden los metadatos del objeto. No se puede recuperar el objeto.

La interrelación entre las reglas de coherencia y de ILM puede ser compleja. Póngase en contacto con NetApp si necesita ayuda.