Grupos replicados (por defecto)

La configuración predeterminada de ODF utiliza la replicación de tres vías. Cada dato se almacena en tres copias repartidas entre distintos nodos, lo que ofrece protección frente a hasta dos fallos simultáneos de disco o de nodo.

• Ventajas: arquitectura sencilla, lecturas rápidas, recuperación rápida y latencia predecible.
• Aumento del uso: 3x de almacenamiento bruto por cada byte de datos utilizables.

¿Qué ocurre cuando se pierden copias ( rep3 )?:

El parámetro min_size controla el número mínimo de copias que deben estar disponibles antes de que Ceph permita la E/S. ODF establece por defecto un conjunto de grupos de min_size=2 rep3, y esta configuración se aplica mediante requireSafeReplicaSize: true, lo que significa que, cuando hay 2 o 3 copias disponibles, las operaciones de lectura y escritura se realizan con normalidad. Cuando solo hay una copia disponible, Ceph bloquea las operaciones de E/S para evitar una mayor inconsistencia en los datos.

Este comportamiento es un mecanismo de seguridad deliberado que da prioridad a la integridad de los datos frente a la disponibilidad.

El periodo comprendido entre la pérdida de la segunda copia y la finalización de la repliación es el más peligroso. Durante este tiempo, un tercer fallo provoca la pérdida permanente de datos. Esta es la razón por la que la planificación de la capacidad es importante, ya que la velocidad de repluración de Ceph depende del ancho de banda disponible del clúster y del espacio libre. Un clúster sobrecargado o casi lleno tarda más en volver a replicarse, lo que prolonga el tiempo de vulnerabilidad.

En el caso de los grupos de rep2, la progresión es más agresiva. Si se pierde una copia, sólo queda una. Con ( min_size=2 por defecto), la E/S se bloquea inmediatamente en los PG afectados hasta que el OSD que falta vuelva a estar disponible o se replique una nueva copia. Con min_size=1, la E/S continúa en la única copia restante, pero un segundo fallo provoca la pérdida permanente de los datos.

El complemento ODF de Red Hat OpenShift Kubernetes Service crea automáticamente únicamente grupos de rep3 con ocs-storagecluster-cephblockpool. Rep2 El complemento no crea grupos. Debes crear manualmente un CephBlockPool personalizado con replicated.size: 2 y el correspondiente StorageClass. Para obtener más información, consulta Creación de un entorno de StorageClass personalizado para la virtualización.

Dado que rep2 ofrece menos tolerancia a fallos que rep3, evalúe si el ahorro en almacenamiento justifica el mayor riesgo para su carga de trabajo.

IBM Recomienda la replicación de tres vías para todas las cargas de trabajo de virtualización en producción, con el fin de garantizar la disponibilidad y la durabilidad de los datos.

Grupos codificados por borrado

Para entornos en los que la eficiencia de la capacidad de almacenamiento es una prioridad, ODF también admite pools con código de borrado (EC). EC divide los datos en bloques de datos k y bloques de paridad m, lo que reduce el uso de almacenamiento bruto en comparación con la replicación, al tiempo que sigue ofreciendo tolerancia a fallos.

Estado de soporte: La codificación de borrado para RBD y CephFS en ODF es una función en fase de vista previa para desarrolladores, introducida por primera vez en ODF 4.20. Las funciones de la versión preliminar para desarrolladores no están compatibles con el uso en producción. Además, no están incluidos en la gestión de incidencias del portal de clientes de Red Hat. Antes de ODF 4.20, solo RGW (almacenamiento de objetos) EC estaba disponible como versión preliminar para desarrolladores (de ODF 4.16 ). Aunque el motor de almacenamiento Ceph subyacente admite sobrescrituras EC para RBD desde la versión Luminous (2017), el operador ODF y su modelo de despliegue gestionado aún no certifican pools EC para cargas de trabajo de almacenamiento de bloques de producción. Prevé utilizar grupos replicados ( rep2 o rep3 ) para todo el almacenamiento de producción VM, y evalúa los grupos EC únicamente para entornos que no sean de producción, en los que las limitaciones de la versión preliminar para desarrolladores sean aceptables.

La siguiente tabla compara todos los tipos de grupos disponibles a modo de referencia.

Las siguientes listas recogen las consideraciones clave sobre la codificación de borrado.

• Los grupos EC tienen una latencia de escritura mayor que los grupos replicados debido al cálculo de la paridad y a la necesidad de escribir más fragmentos por operación.
• Los pools EC ofrecen un rendimiento de lectura secuencial competitivo, pero pueden mostrar IOPS de escritura aleatoria reducidas.
• El número de dominios de fallo debe ser, como mínimo, k+m. En un clúster de 3 nodos, solo son posibles rep2, rep3 y ec-2-1.
• Para un clúster de 6 nodos, están disponibles todos los tipos de grupo enumerados anteriormente.

Grupo de réplicas únicas (no resiliente, solo para desarrollo y pruebas)

A partir de la versión del complemento ODF 4.14, Red Hat OpenShift Kubernetes Service admite un grupo de réplicas único ( rep1 ) a través del parámetro addSingleReplicaPool. Este parámetro crea un grupo de bloques no resistente de Ceph sin replicación de datos, en el que cada bloque de datos se almacena una sola vez.

Para habilitar el grupo de réplicas único al implementar ODF, utiliza el siguiente comando

ibmcloud oc cluster addon enable openshift-data-foundation -c <cluster_name> \
  --version <version> \
  --param "addSingleReplicaPool=true"

Este comando crea un StorageClass: adicional

• ocs-storagecluster-ceph-non-resilient-rbd: Almacenamiento de bloques de réplica única con vinculación de volúmenes WaitForFirstConsumer.

Con él se sigue creando el grupo estándar replica-3 (ocs-storagecluster-cephblockpool). La reserva no resistente es una opción independiente y optativa.

Un único grupo de réplicas tiene los siguientes casos de uso.

• Entornos de desarrollo y pruebas: aquellos en los que la durabilidad de los datos no es fundamental y se da prioridad al ahorro en los costes de almacenamiento.
• Aplicaciones con replicación integrada: estas aplicaciones gestionan su propia redundancia de datos en la capa de aplicación. Estas aplicaciones mantienen múltiples copias en los distintos nodos, lo que significa que la replicación a nivel de almacenamiento es redundante.

El grupo de réplicas único proporciona tolerancia cero a los fallos. El fallo de un único OSD o nodo provoca la pérdida permanente e irrecuperable de todos los datos de ese OSD. No se dispone de una segunda copia para la recuperación. La documentación de IBM Cloud advierte explícitamente de que esta opción aumenta el riesgo de pérdida de datos, corrupción de datos y posible inestabilidad del sistema. Para más información, consulte la documentación de Ceph.

Limitaciones:

• Solo almacenamiento en bloques: el almacenamiento de archivos no es compatible con una única réplica.
• Requiere discos adicionales: al menos un disco NVMe utilizable adicional por nodo, además de los que utiliza el grupo replica-3. Sin este disco adicional, los OSD de replica-1 no se inician y el clúster de almacenamiento permanece en estado de progreso.
• Un pool por dominio de fallo: ODF crea un CephBlockPool no resistente por dominio de fallo, con volúmenes que se vinculan mediante el uso de WaitForFirstConsumer para validar la localidad de los datos.
• No recomendado para discos raíz de cargas de trabajo de máquinas virtuales: Si el OSD que aloja un disco raíz falla, la carga de trabajo de la máquina virtual se pierde permanentemente. Utilice el pool no resistente sólo para discos de datos desechables en cargas de trabajo de máquinas virtuales dev o de prueba.

Para las cargas de trabajo de virtualización en producción, utilice siempre grupos de replica-3 (o, como mínimo, replica-2 ).

VMware vSAN comparación de migraciones

Para los equipos que están migrando desde VMware vSAN™, estos tipos de grupos de Ceph se corresponden con las políticas de almacenamiento habituales de vSAN:

Principales diferencias con vSAN:

• Mínimos de host más pequeños: Ceph separa el quórum del clúster de la ubicación de los datos. Un grupo de rep3 solo necesita tres hosts, ya que cada host almacena una copia completa. vSAN RAID-1 FTT=2 necesita cinco hosts.
• rep2 Se ajusta a la norma vSAN RAID-1: La mayoría de las implementaciones de vSAN utilizan FTT=1, que almacena dos copias. El documento rep2 de Ceph es el equivalente directo.
• ec-3-1 Coincide con vSAN RAID-5: Ambos utilizan una disposición 3+1 y logran un uso de 1.33x, la opción más eficiente en cuanto a espacio para la tolerancia a un único fallo.
• ec-4-2 Coincide con vSAN RAID-6: Ambos utilizan una configuración 4+2 y consiguen un uso de 1.5x con tolerancia a dos fallos.
• ec-2-1 y ec-2-2 no tienen un equivalente directo en vSAN: configuraciones de Ceph EC más pequeñas con menos fragmentos de datos, lo que se traduce en un mayor uso por byte, pero requiere menos hosts. Sacrifican la eficiencia de almacenamiento a cambio de unos requisitos de número de hosts más reducidos.

Capacidad de planificación

Al planificar su clúster ODF, tenga en cuenta el uso de almacenamiento bruto de la política de protección de datos que haya elegido. La capacidad utilizable es inferior a la capacidad NVMe bruta total.

La fórmula de la capacidad útil es Usable capacity = Total raw NVMe capacity / Replication or EC overhead factor.

Consulte el siguiente ejemplo de cálculos para un clúster de 3 nodos con 8 unidades NVMe de 3.2 TB por nodo ( 76.8 TB en bruto en total):

Estimación de la capacidad de carga de trabajo de la máquina virtual: Una carga de trabajo de máquina virtual típica con un disco raíz de 30 GB y un disco de datos de 100 GB utiliza 130 GB de almacenamiento utilizable. Con rep3, esa carga de trabajo de máquina virtual requiere 390 GB de almacenamiento bruto. En el clúster de 3 nodos anterior, se podrían aprovisionar aproximadamente 196 cargas de trabajo de máquinas virtuales de este tamaño. En la práctica, mantenga el uso de Ceph por debajo del 75% para mantener el rendimiento y apoyar las operaciones de recuperación.

El rendimiento de Ceph se degrada a medida que aumenta el uso del clúster. ODF activa la CephOSDNearFull alerta Prometheus cuando cualquier OSD supera el 75 % de uso. Al alcanzar el 85 %, Ceph establece el indicador nativo nearfull OSD (mon_osd_nearfull_ratio) y ODF activa la alerta CephOSDCriticallyFull. Al alcanzar el 90 %, Ceph detiene las operaciones de rellenado y recuperación en el OSD afectado (mon_osd_backfillfull_ratio). Al alcanzar el 95 %, Ceph marca el OSD full (mon_osd_full_ratio), bloquea todas las escrituras y emite HEALTH_ERR. Planifique su capacidad de modo que el uso se mantenga por debajo del 70 % durante el funcionamiento normal, dejando margen para la recuperación de datos y el reequilibrio durante el mantenimiento de los nodos o en caso de fallos.

Para comprobar el uso actual del clúster, ejecuta el siguiente comando :

oc exec -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) -- ceph df

Número de nodos de trabajo y topología

La topología del dominio de fallos que utiliza el complemento ODF de IBM Cloud depende de la configuración de su clúster:

• Clústeres multizona (3 zonas de disponibilidad): El dominio de fallo está configurado en zone. Los nodos de trabajo se distribuyen entre las distintas zonas, y el ODF debe crecer en múltiplos de 3 para mantener el equilibrio entre las zonas. Para obtener una disponibilidad, un rendimiento y una seguridad de los datos óptimos, utilice 3, 6 o 9 nodos en el clúster de almacenamiento ODF; cada zona recibirá el mismo número de nodos.
• Clústeres de una sola zona o clústeres con menos de tres zonas de disponibilidad: el escalado flexible se activa automáticamente y el dominio de fallo se establece en host. Puedes empezar con 3 nodos e ir añadiendo nodos de uno en uno.

Todos los nodos que participan en el clúster de almacenamiento ODF deben ser bare metal. No se admite la mezcla de nodos virtualizados y bare-metal dentro del mismo clúster ODF.

En el caso de los clústeres multizona: añadir nodos en cantidades que no sean múltiplos de 3 provoca un desequilibrio entre las zonas. Con 4 nodos, una zona recibe 2 nodos, mientras que las demás reciben 1 cada una, lo que da lugar a una distribución desigual del peso de los OSD, una ubicación de datos subóptima, un uso desigual y OSD parcialmente inactivos.

En el caso de los clústeres multizona, amplíe siempre en múltiplos de 3 para mantener una topología de zonas equilibrada.

oc get nodes -l node-role.kubernetes.io/worker= \
  -o custom-columns='NAME:.metadata.name,RACK:.metadata.labels.topology\.kubernetes\.io/rack'

Planes de suscripción ODF

Elige el plan que mejor se adapte a tus necesidades:

• Essentials

  • Coste reducido
  • Solo para implementación en modo interno
  • No admite la recuperación ante desastres, los clústeres extendidos ni las implementaciones en modo externo
  • Ideales para entornos de pruebas y desarrollo, pruebas de concepto o implementaciones a pequeña escala

• Avanzado

  • Conjunto completo de funciones que incluye recuperación ante desastres, clústeres extendidos, implementación en modo externo, cifrado granular avanzado y compatibilidad con múltiples clústeres
  • Recomendado para cargas de trabajo de virtualización en producción con máquinas virtuales

Ambos planes incluyen compresión BlueStore en grupos de bloques, aprovisionamiento ligero, instantáneas y clonación. Las diferencias entre los planes se refieren a la recuperación ante desastres, la granularidad del cifrado y la flexibilidad de implementación, más que a las características de eficiencia de almacenamiento.

ODF sólo admite la deduplicación para el almacenamiento de objetos a través de Multicloud Object Gateway (MCG). El almacenamiento en bloque no admite la deduplicación. Esta asistencia se aplica tanto a los planes Essentials como a los Advanced. La deduplicación Ceph ascendente para RBD sigue siendo experimental y no está certificada para su uso en ODF.

Para obtener más información, consulta ODF: Conceptos básicos frente a Avanzado.

Tipo de almacenamiento

• Seleccione Almacenamiento local.
• El almacenamiento local utiliza el almacenamiento de instancia NVMe local disponible en los nodos de trabajador bare metal.
• Las unidades NVMe ofrecen una latencia reducida y un elevado rendimiento en IOPS, requisitos imprescindibles para los discos de las cargas de trabajo de las máquinas virtuales.

Perfil de recursos ODF

ODF proporciona tres perfiles de asignación de recursos que controlan la CPU y la memoria que se reserva para los demonios Ceph.

• Lean: Asignación mínima de recursos. El perfil Lean es adecuado para entornos con recursos limitados, pruebas, desarrollo y pruebas de concepto. No se recomienda el uso de Lean para cargas de trabajo de virtualización en producción.
• Equilibrado: El perfil por defecto en Red Hat OpenShift Kubernetes Service. El perfil Equilibrado proporciona un equilibrio entre el consumo de recursos y el rendimiento para cargas de trabajo de uso general.
• Rendimiento: Asigna más CPU y memoria a los demonios de Ceph, lo que reduce el riesgo de cuellos de botella por parte de los demonios. Ideal para cargas de trabajo con un elevado número de IOPS, un gran número de servidores virtuales y aplicaciones exigentes.

Para implementaciones bare-metal con unidades NVMe locales, utilice el perfil de recursos Performance. Los nodos bare-metal con 8 o más unidades NVMe por nodo generan un elevado número de OSD por host. Con el perfil Balanced, los límites de CPU y memoria del daemon de Ceph suelen alcanzarse antes de que se sature el hardware NVMe subyacente, lo que limita las IOPS y aumenta la latencia. El perfil Performance es el perfil mínimo recomendado para cargas de trabajo de virtualización de Red Hat OpenShift en entornos de producción sobre hardware físico.

Los requisitos de recursos que se muestran en la consola web Red Hat OpenShift durante la instalación de ODF se calculan dinámicamente en función del recuento de OSD del clúster. Por lo tanto, los clústeres con más unidades NVMe requieren proporcionalmente más recursos. Los valores no son fijos. Compruebe siempre los requisitos mostrados en la consola para su configuración de clúster específica.

El perfil se selecciona durante la creación de StorageSystem a través de la pantalla Configure Performance de la consola web Red Hat OpenShift. Los daemons de Ceph con recursos insuficientes pueden convertirse en un cuello de botella oculto, lo que provoca una reducción de las IOPS o una latencia mayor de la que puede ofrecer el hardware de almacenamiento subyacente.

Haga coincidir sus perfiles de servidor bare metal con los requisitos de recursos mostrados para el perfil elegido: IBM Cloud Perfiles de servidor VPC bare metal.

Una ligera sobresuscripción de recursos suele ser aceptable en un servidor bare metal. Sin embargo, nunca asigne recursos significativamente inferiores a los requisitos mínimos indicados, ya que ello reduce el rendimiento y la estabilidad de ODF.

Número de discos OSD por nodo

• Determina el número de unidades NVMe locales disponibles en cada servidor bare metal.
• Asegúrese de que el número de OSD configurados por nodo no supere el número de unidades NVMe utilizables.
• Se recomienda utilizar un OSD por unidad NVMe para obtener un rendimiento óptimo y aislar los fallos.
• Asegúrese de que el número de discos OSD coincida normalmente con el número de unidades NVMe por nodo bare metal. El cálculo de la capacidad de almacenamiento que se muestra en la interfaz de usuario no refleja la capacidad útil real en el caso de las configuraciones de almacenamiento local y puede ignorarse.

Al seleccionar nodos durante la creación de un clúster de StorageSystem, evite seleccionar todos los nodos del clúster. Al seleccionar todos los nodos se crea un sistema de equilibrio de carga ( LocalVolumeSet, LVS) sin nodeSelector. Cualquier nodo de trabajo que se añada al clúster en el futuro será detectado automáticamente por ODF, incluso si no está destinado al almacenamiento. Los nodos que se detecten de forma inesperada deben eliminarse manualmente del LVS. Para evitarlo, selecciona únicamente los nodos de tu grupo de trabajadores de almacenamiento dedicado o asegúrate de que dichos nodos tengan la etiqueta cluster.ocs.openshift.io/openshift-storage antes de crear un StorageSystem.

Por defecto StorageClass para el cluster

Tras la implementación de ODF, suelen crearse los siguientes archivos de configuración ( followingStorageClasses ):

• ocs-storagecluster-ceph-rbd: Almacenamiento en bloque
• ocs-storagecluster-cephfs: Almacenamiento de archivos
• ocs-storagecluster-ceph-rgw: Almacenamiento de objetos

Para que las cargas de trabajo utilicen automáticamente almacenamiento en bloques persistente de alto rendimiento respaldado por ODF sin necesidad de configuración adicional, seleccione Usar dispositivo de bloques Ceph RADOS (RBD) como clase de almacenamiento predeterminada o configure manualmente RBD (ocs-storagecluster-ceph-rbd) como StorageClass predeterminado para el clúster una vez instalado el complemento ODF.

1. Marcar RBD como predeterminado:

   oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

2. Si es necesario, elimina el valor predeterminado de la configuración predeterminada establecida anteriormente:

   oc patch storageclass <previous-default-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
   

Lista de comprobación de la configuración de ODF

• El clúster contiene al menos un grupo de servidores bare metal
• Red Hat OpenShift Versión 4.17 o superior
• El complemento ODF y el operador están instalados y en funcionamiento
• Los servidores bare metal disponen de suficientes unidades NVMe locales utilizables
• El perfil de recursos seleccionado coincide con la capacidad del nodo
• Los clústeres de almacenamiento ODF utilizan un mínimo de 3 nodos; los clústeres multizona deben utilizar múltiplos de 3 (3, 6, 9, …) para mantener el equilibrio de la zona
• Todos los nodos participantes en ODF son de metal desnudo
• Se crea el RBD StorageClass y se establece preferentemente como predeterminado
• El estado del clúster ODF es Listo (oc get storagecluster -n openshift-storage)
• El estado de Ceph es HEALTH_OK (oc -n openshift-storage rsh $(oc get pod -l app=rook-ceph-tools -o name) ceph status)

Requisitos previos: Instalar el operador de virtualización Red Hat OpenShift

Antes de utilizar la virtualización Red Hat OpenShift en IBM Cloud, comprueba que el operador de virtualización Red Hat OpenShift esté instalado en tu clúster de Red Hat OpenShift Kubernetes Service.

El operador de virtualización Red Hat OpenShift permite la gestión de cargas de trabajo de máquinas virtuales nativas de Kubernetes. También proporciona los controladores, CRD e integraciones necesarios con componentes de almacenamiento y redes.

Para más información, consulte Red Hat OpenShift Virtualization en IBM Cloud.

Uso del almacenamiento ODF para cargas de trabajo de máquinas virtuales

Red Hat OpenShift Data Foundation (ODF) proporciona almacenamiento persistente definido por software para cargas de trabajo de virtualización que se ejecutan en Red Hat OpenShift. Cuando se utiliza ODF como backend de almacenamiento para máquinas virtuales, es fundamental seleccionar el StorageClass adecuado para garantizar el rendimiento, la estabilidad y la compatibilidad total con todas las funciones.

Debe especificar el StorageClass adecuado para las siguientes situaciones:

• Se crean servidores virtuales
• Los servidores virtuales se importan o se clonan
• Los servidores virtuales se migran a un clúster de Red Hat OpenShift Kubernetes Service

Virtualización por defecto StorageClass

Cuando se instala el Operador de virtualización de Red Hat OpenShift y hay un clúster ODF disponible, se crea automáticamente un clúster de StorageClass optimizado para cargas de trabajo de virtualización:

• ocs-storagecluster-ceph-rbd-virtualization

Esto es StorageClass:

• Ajustado para patrones de E/S de disco como lecturas aleatorias, escrituras y rendimiento sostenido
• Validada para operaciones del ciclo de vida de la virtualización como inicio, parada, migración en vivo e instantáneas
• Totalmente compatible y recomendado para entornos de virtualización de producción Red Hat OpenShift

Para la mayoría de los casos de uso, utilice este StorageClass sin modificaciones.

Requisitos de almacenamiento para la migración en vivo

La migración en vivo mueve la carga de trabajo de una máquina virtual en ejecución de un nodo trabajador a otro sin tiempo de inactividad. Para que la migración en vivo tenga éxito, el almacenamiento debe ser accesible desde los nodos de origen y destino simultáneamente. La migración en vivo requiere las siguientes configuraciones.

• ReadWriteMany modo de acceso en PVCs de carga de trabajo de máquinas virtuales. Ceph RBD soporta RWX en modo bloque, que es la configuración por defecto para la virtualización ODF StorageClass.
• El StorageClassocs-storagecluster-ceph-rbd-virtualization viene preconfigurado con soporte ReadWriteMany a través del modo de bloques RBD. Los servidores virtuales que utilizan este StorageClass pueden migrar sin necesidad de configuración adicional.
• El genérico ocs-storagecluster-ceph-rbd StorageClass utiliza por defecto el modo de acceso ReadWriteOnce. Los servidores virtuales que utilizan PVCs RWO no pueden realizar la migración en vivo. La migración falla porque el PVC no se puede montar en el nodo de destino mientras está conectado al origen.

Si creas un customStorageClasses s para servidores virtuales que necesitan migración en vivo, comprueba que los PVC se hayan creado con y accessModes: [ReadWriteMany] volumeMode: Block.

La migración en vivo también requiere:

• Configuración del operador de virtualización Red Hat OpenShift con una política de migración adecuada
• Comprobación de que el nodo de destino dispone de suficiente CPU y memoria

Virtualización específica comparada con RBD genérico StorageClass

Aunque las máquinas virtuales pueden utilizar un RBD genérico de Ceph StorageClass,, el StorageClass específico para la virtualización está optimizado para las características únicas de E/S y ciclo de vida de los discos de carga de trabajo de las máquinas virtuales.

Los RBD genéricos StorageClasses siguen siendo adecuados para cargas de trabajo en contenedores, pero se recomienda utilizar los específicos para virtualización StorageClass para los entornos de virtualización en producción.

Creación de un sitio StorageClass personalizado para la virtualización

En algunos casos, es posible que necesite un sitio StorageClass personalizado para satisfacer requisitos específicos de rendimiento, resistencia o capacidad.

Para crear un StorageClass personalizado, primero debes crear un CephBlockPool personalizado. Al crear un pool personalizado, debe configurar targetSizeRatio en el pool. Sin esta configuración, el escalador automático de grupos de ubicación de Ceph asigna solo un grupo de ubicación al grupo de recursos. Esta asignación provoca que todas las operaciones de E/S se concentren en un único OSD, lo que da lugar a un rendimiento inferior al del grupo predeterminado.

Cuando cree un StorageClass personalizado para cargas de trabajo de virtualización, compruebe que los siguientes parámetros están configurados correctamente.

• Suministrador

  El StorageClass debe utilizar el aprovisionador Ceph RBD CSI proporcionado por ODF:

  openshift-storage.rbd.csi.ceph.com
  

  Este aprovisionador permite el aprovisionamiento dinámico de volúmenes Ceph RBD respaldados por el clúster ODF.

• Agrupación de almacenamiento

  Especifique el CephBlockPool que respalda los discos de carga de trabajo de la máquina virtual. Puede seleccionar una de las opciones siguientes:

  • Grupo de bloques por defecto. El pool de bloques Ceph replicado en 3 direcciones por defecto creado por ODF:

      ocs-storagecluster-cephblockpool
      ```
  
  - Piscina de bloques a medida. Una dirección definida por el usuario CephBlockPool. El pool debe incluir los siguientes ajustes para evitar problemas de rendimiento:
  
  ```yaml
        apiVersion: ceph.rook.io/v1
        kind: CephBlockPool
        metadata:
        name: my-custom-pool
        namespace: openshift-storage
       spec:
         failureDomain: zone          # Default for multi-zone clusters — data copies spread across zones; use host for single-zone flexible-scaling clusters
         deviceClass: ssd             # Match OSD device class
         enableCrushUpdates: true     # Keep CRUSH rules current on topology changes
         enableRBDStats: true         # Enable per-volume I/O monitoring
         replicated:
          size: 3
          requireSafeReplicaSize: true
              targetSizeRatio: 0.1       # CRITICAL — prevents 1-PG bottleneck
          ```
      The `targetSizeRatio` instructs the placement group autoscaler to proportionally preallocate placement groups based on the expected capacity share. Without it, the pool receives 1 PG and all I/O is funneled through a single OSD.
      
  

• Características de la imagen

  La página StorageClass debe incluir las características de la imagen RBD que son críticas para el rendimiento de la carga de trabajo:

  imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
  

  Características de la imagen RBD y su finalidad

  Característica	Finalidad
  exclusive-lock	Activa la caché de escritura y las optimizaciones de escritura única. Sin esta función, las IOPS de escritura pueden ser hasta 7x peores.
  object-map	Permite el seguimiento de mapa de bits de objetos asignados para imágenes dispersas.
  fast-diff	Acelera las operaciones de snapshot diff y DataVolume clone para tiempos de arranque más rápidos.
  deep-flatten	Hace que los clones sean totalmente independientes una vez aplastados.
  layering	Activa la clonación de copia en escritura necesaria para la clonación de DataVolume.

• Opciones de mapas

  mapOptions: krbd:rxbounce
  

  Esta opción soluciona los problemas de corrupción de datos que se producen al utilizar el controlador RBD del núcleo con servidores virtuales de Windows. Obliga al núcleo a utilizar un búfer de rebote para los datos recibidos con el fin de garantizar la compatibilidad. Esta opción debe configurarse en todos los StorageClasses de carga de trabajo.

• Ejemplo completo de StorageClass personalizado

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: my-custom-virt-sc
  provisioner: openshift-storage.rbd.csi.ceph.com
  parameters:
    clusterID: <your-cluster-id>
    pool: my-custom-pool
    imageFormat: "2"
    imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
    mapOptions: krbd:rxbounce
    csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
    csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
    csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
    csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
    csi.storage.k8s.io/fstype: ext4
  reclaimPolicy: Delete
  allowVolumeExpansion: true
  volumeBindingMode: Immediate
  

  Para encontrar el clusterID para su cluster, ejecute el siguiente comando :

  oc get sc ocs-storagecluster-ceph-rbd -o jsonpath='{.parameters.clusterID}'
  

  Para los grupos con codificación de borrado (solo en versión preliminar para desarrolladores), consulta Descripción de la protección de datos, añade dataPool que apunte al grupo EC y mantén pool apuntando al grupo replicado por defecto:

  parameters:
    pool: ocs-storagecluster-cephblockpool   # Replicated pool for metadata
    dataPool: my-ec-pool                      # EC pool for data blocks
  

Compresión

ODF admite la compresión en línea BlueStore en los grupos de bloques Ceph, lo que puede reducir el almacenamiento en bruto utilizado por los discos. La compresión se aplica de forma transparente en la capa OSD, por lo que la carga de trabajo de la máquina virtual y su sistema operativo invitado no detectan que los datos están comprimidos.

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: compressed-block-pool
  namespace: openshift-storage
spec:
  failureDomain: zone          # Default for multi-zone clusters; use host for single-zone flexible-scaling clusters
  deviceClass: ssd
  enableCrushUpdates: true
  enableRBDStats: true
  replicated:
    size: 3
    requireSafeReplicaSize: true
    targetSizeRatio: 0.1
  parameters:
    compression_mode: "aggressive"

Cifrado

ODF admite el cifrado de datos en reposo en varias capas que puedes activar de forma independiente.

• IBM Cloud Cifrado de infraestructura: cifrado completo del disco en unidades NVMe físicas, gestionado por IBM Cloud.
• Cifrado de todo el clúster ODF: todos los discos OSD de Ceph se cifran con dm-crypt a nivel de dispositivo. Habilitado a través de encryption.clusterWide: true en el CR del clúster de almacenamiento. Protege contra el robo físico de discos.
• Cifrado por volumen de ODF: los volúmenes RBD individuales se cifran mediante LUKS2, cada uno con su propia clave de cifrado de datos. Ofrece aislamiento de inquilinos y gestión granular de claves.

En Red Hat OpenShift Kubernetes Service, ODF se integra con IBM Key Protect como servicio externo de gestión de claves tanto para el cifrado de todo el clúster como para el cifrado por volumen. Cuando se activa el cifrado por volumen, ODF crea automáticamente -encrypted StorageClass variantes (por ejemplo, ocs-storagecluster-ceph-rbd-encrypted).

Optimización del rendimiento de Ceph para servidores bare-metal con NVMe

La configuración predeterminada de Ceph está optimizada para cargas de trabajo generales. Los siguientes valores de parámetros se han validado en el perfil bare-metal mx2d.metal.96x768 y aumentan significativamente las IOPS y reducen la latencia para las cargas de trabajo de disco VM en dicho perfil. Si utilizas un perfil de servidor físico diferente, tómalos como referencia inicial y ajusta los valores en función del número de unidades NVMe y de la CPU disponible de tu perfil específico.

Aplica cada parámetro utilizando el ceph config set comando del pod Ceph toolbox:

TOOLS_POD=$(oc get pod -n openshift-storage -l app=rook-ceph-tools -o name)
# OSD memory and shard tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_memory_target 8589934592
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_shards_ssd 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_threads_per_shard_ssd 2
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd bluestore_prefer_deferred_size_ssd 0
# RocksDB tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_write_buffer_size 268435456
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_write_buffer_number 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_background_jobs 12

Tras aplicar los cambios, comprueba que la configuración se haya aceptado:

oc exec -n openshift-storage ${TOOLS_POD} -- ceph config dump | grep -E "osd_memory_target|osd_op_num_shards|bluestore_prefer_deferred|rocksdb"

No es necesario reiniciar los pods de OSD para aplicar los cambios ceph config set. Ceph aplica la configuración de forma dinámica. Sin embargo, los cambios en la caché de BlueStore (osd_memory_target) solo surten pleno efecto después de que se haya reciclado cada pod de OSD. Puedes reciclar los pods de OSD de uno en uno durante una ventana de mantenimiento sin interrumpir las operaciones de E/S.

Referencia de rendimiento: Las pruebas internas realizadas en un clúster mx2d.metal.96x768 de 3 nodos con 200 máquinas virtuales y IOPS ilimitadas demostraron que la combinación de 16 fragmentos, 8 GB de memoria OSD y un búfer de escritura de 256 MB RocksDB alcanzaba aproximadamente 194.000 IOPS y un rendimiento de 758 MB/s. El aumento del número de fragmentos de 8 a 16 produjo sistemáticamente la mayor mejora individual en IOPS en todas las configuraciones de prueba.

Copia de seguridad basada en instantáneas

ODF soporta Kubernetes VolumeSnapshots para volúmenes Ceph RBD. Para tomar una instantánea de un disco, utilice el siguiente comando :

oc apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-vm-snapshot
spec:
  volumeSnapshotClassName: ocs-storagecluster-rbdplugin-snapclass
  source:
    persistentVolumeClaimName: my-vm-data-disk
EOF

VolumeSnapshots se copian al escribir y se crean casi al instante. Puede utilizarlos para restaurar la carga de trabajo de una máquina virtual a un estado anterior o para clonar un disco. La virtualización de Red Hat OpenShift también proporciona una API integrada de instantáneas y restauraciones VM que captura el estado completo de la carga de trabajo de la máquina virtual —incluida la configuración y todos los discos— en una sola operación.

Puesta en reposo de cargas de trabajo de máquinas virtuales para instantáneas coherentes con la aplicación

Cuando se realiza una instantánea de una carga de trabajo de una máquina virtual en ejecución, los datos del disco deben encontrarse en un estado coherente. Sin quiescing, la instantánea captura lo que haya en el disco en ese instante, incluyendo transacciones parcialmente escritas, búferes sucios y E/S en vuelo. Este proceso genera una instantánea coherente con el fallo, lo que podría requerir una recuperación a nivel de aplicación al restaurar los datos.

Para obtener instantáneas coherentes con la aplicación, congele el sistema de archivos invitado antes de la instantánea y descongélelo después. Red Hat OpenShift La virtualización automatiza este proceso mediante el agente invitado de QEMU.

El controlador de instantáneas detecta el agente invitado QEMU. Antes de realizar la instantánea, se ejecuta un comando guest-fsfreeze-freeze que detiene todas las operaciones de E/S de los sistemas de archivos. La instantánea VolumeSnapshot se realiza mientras el sistema de archivos está congelado. Una vez finalizada la instantánea, un comando guest-fsfreeze-thaw reanuda la E/S. El estado de la instantánea indica el nivel de consistencia alcanzado. Consulte la siguiente tabla para conocer el significado de cada estado.

Se recomienda instalar el agente invitado de QEMU en todas las máquinas virtuales de producción. En los servidores Linux, utiliza el siguiente comando.

# RHEL / CentOS / Fedora
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
# Ubuntu / Debian
sudo apt-get install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

Para huéspedes Windows, instale el paquete de controladores VirtIO, que incluye el servicio de agente huésped QEMU.

Hooks personalizados de congelación/descongelación para aplicaciones: para bases de datos y otras aplicaciones con estado que requieran una suspensión adicional más allá de la congelación del sistema de archivos, coloque scripts de hooks personalizados dentro de la carga de trabajo de la máquina virtual invitada en /etc/qemu-ga/fsfreeze-hook.d/. El agente invitado ejecuta automáticamente estos scripts con un argumento freeze antes de que se congele el sistema de archivos y con un argumento thaw después de que se descongele el sistema de archivos. Los registros de ejecución de los ganchos se escriben en /var/log/qga-fsfreeze-hook.log.

Por ejemplo, el siguiente gancho de congelación PostgreSQL puede colocarse en /etc/qemu-ga/fsfreeze-hook.d/postgresql.sh:

#!/bin/bash
case "$1" in
  freeze)
    sudo -u postgres psql -c "SELECT pg_backup_start('snapshot');" 2>/dev/null || true
    ;;
  thaw)
    sudo -u postgres psql -c "SELECT pg_backup_stop();" 2>/dev/null || true
    ;;
esac

VMware Comparación: Este ejemplo es análogo al script de pre-congelación y post-descongelación de VMware que se utiliza con VMware Tools para crear instantáneas coherentes con la aplicación. El agente invitado de QEMU desempeña la misma función que las herramientas de VMware para la suspensión de instantáneas.

Cambiadas las limitaciones del seguimiento de bloques

El seguimiento de bloques modificados permite realizar copias de seguridad incrementales identificando únicamente los bloques que han cambiado desde la última copia de seguridad. El VADP (API de vStorage s para la protección de datos) de VMware utiliza este mecanismo para proporcionar copias de seguridad incrementales eficientes.

CBT no está disponible para ODF y Ceph RBD en Red Hat OpenShift Virtualization. Actualmente, las copias de seguridad se basan en instantáneas completas, lo que puede dar lugar a ventanas de copia de seguridad más largas y a un mayor consumo de almacenamiento.

El desarrollo de la TCC está en marcha a múltiples niveles:

Aunque Ceph RBD admite la rbd diff capacidad subyacente de identificar bloques modificados entre instantáneas, esta capacidad aún no está disponible a través de la API de seguimiento de bloques modificados (CSI Changed Block Tracking API) de Kubernetes. Hasta que no se disponga de la pila completa (API CSI CBT + compatibilidad con el controlador Ceph CSI + integración con KubeVirt ), no estarán disponibles las copias de seguridad incrementales a nivel de bloque.

Soluciones de copia de seguridad

Varios proveedores de soluciones de copia de seguridad ofrecen soluciones para la virtualización Red Hat OpenShift que funcionan dentro del modelo actual basado en instantáneas:

• Veeam® Kasten: Kubernetes-protección de datos nativa con soporte de virtualización Red Hat OpenShift y capacidades de instantáneas incrementales para ODF. Para obtener más información, consulte la arquitectura de referencia de Veeam Kasten.
• Trilio para Kubernetes: Copia de seguridad y recuperación para cargas de trabajo de virtualización Red Hat OpenShift con integración ODF. Para obtener más información, consulte Trilio Red Hat OpenShift Virtualization support.
• Copia de seguridad de Veritas NetBackup: Enterprise con soporte de virtualización Red Hat OpenShift. Para obtener más información, consulte NetBackup: protección integral de los datos empresariales.

Recomendaciones para las migraciones VMware

Si su entorno actual VMware se basa en copias de seguridad incrementales basadas en CBT, tenga en cuenta las siguientes recomendaciones:

• Planifica copias de seguridad completas. Evalúa tus ventanas de copia de seguridad y tus requisitos de almacenamiento basándote en copias de seguridad completas VolumeSnapshots en lugar de copias de seguridad incrementales.
• Evalúe las herramientas de copia de seguridad nativas de Kubernetes. Veeam Kasten y Trilio están diseñados para la virtualización de Kubernetes y Red Hat OpenShift, y funcionan dentro del modelo de instantáneas actual.
• Utilizar la eficacia de las instantáneas Ceph. Las instantáneas de Ceph RBD son de tipo copy-on-write y utilizan almacenamiento únicamente para los bloques modificados tras la creación de la instantánea, lo que hace que el almacenamiento continuo de las instantáneas sea más eficiente que las copias completas.

Supervisar la salud de ODF y Ceph

La supervisión periódica del clúster de almacenamiento ODF es esencial para mantener la disponibilidad y el rendimiento. En la siguiente sección se describen comandos clave y sus resultados.

TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc exec -n openshift-storage ${TOOLS_POD} -- ceph status

  cluster:
    id:     a1b2c3d4-...
    health: HEALTH_OK          ← What you want to see
  services:
    mon: 3 daemons             ← Should be 3 (quorum)
    mgr: 1 active              ← Manager daemon running
    osd: 24 osds: 24 up, 24 in ← All OSDs healthy (should match your NVMe count)
  data:
    pools:   4 pools, 353 pgs
    objects: 12.5k objects, 48 GiB
    usage:   152 GiB used, 69 TiB / 70 TiB avail   ← Cluster usage

oc exec -n openshift-storage ${TOOLS_POD} -- ceph health detail

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree

oc exec -n openshift-storage ${TOOLS_POD} -- ceph df

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd pool stats

Actualización de ODF en Red Hat OpenShift Kubernetes Service

El complemento IBM Cloud ( Red Hat OpenShift ) de Data Foundation (ODF) aplica automáticamente las actualizaciones de z-stream dentro de la misma versión menor. Estas actualizaciones se gestionan a través de IBM Cloud.

Sin embargo, las actualizaciones de versión principales y secundarias (por ejemplo, 4.18 → 4.19 ) no son automáticas. Sigue el procedimiento de actualización manual para garantizar la seguridad de los datos y la estabilidad del clúster.

La actualización de ODF en un clúster Red Hat OpenShift Kubernetes Service consta de dos fases principales, ambas necesarias para que la actualización se realice correctamente.

1. Actualice o sustituya los nodos trabajadores ODF.

   • ODF se basa en nodos de trabajo dedicados o etiquetados para alojar componentes de almacenamiento.
   • Durante una actualización mayor o menor, estos nodos de trabajo deben actualizarse o sustituirse para alinearse con las versiones Red Hat OpenShift y ODF de destino.
   • Este proceso ayuda a garantizar que los pods ODF (como los OSD, MON y gestores Ceph) se reprogramen correctamente y sigan funcionando sin pérdida de datos.
   • Asegúrese de que la capacidad sea la adecuada y de que los nodos estén en buen estado antes de iniciar este paso para mantener la disponibilidad del almacenamiento.

2. Actualice el complemento ODF.

   • Una vez actualizados o sustituidos los nodos trabajadores, actualice el complemento ODF.
   • Este paso actualiza los operadores ODF, los controladores CSI y los componentes relacionados a la versión de destino.
   • Una vez finalizada la actualización del complemento, el clúster reconcilia automáticamente los recursos ODF y aplica los cambios necesarios.

   Ejecuta la validación posterior a la actualización para confirmar:

   • Salud del clúster ODF y Ceph
   • StorageClasses disponibilidad
   • Operaciones de lectura y escritura en PVC realizadas con éxito por las aplicaciones

Para obtener más información, consulte Actualización de ODF en clústeres VPC.

Ampliación del almacenamiento ODF en Red Hat OpenShift Kubernetes Service

Por lo tanto, a medida que aumentan sus cargas de trabajo y crecen las necesidades de almacenamiento, resulta esencial ampliar su infraestructura de almacenamiento. La ampliación en ODF es una operación clave del Día 2 que permite aumentar la capacidad de almacenamiento, mejorar el rendimiento y mantener la resistencia sin interrumpir las aplicaciones en ejecución.

En los entornos IBM Cloud Red Hat OpenShift Kubernetes Service, la expansión suele implicar la ampliación del grupo de trabajadores de almacenamiento. Esta operación se realiza con un tiempo de inactividad mínimo, lo que permite un crecimiento sin interrupciones de su clúster de almacenamiento.

1. Añade nodos de trabajo a tu clúster de VPC. En el caso de clústeres multizona en los que el clúster de almacenamiento abarca tres zonas de disponibilidad, añada nodos de trabajo en múltiplos de tres para mantener el equilibrio entre zonas (por ejemplo, 3, 6 o 9). En el caso de los clústeres de una sola zona con escalado flexible habilitado, se pueden añadir nodos de uno en uno.

2. Una vez añadidos los nodos, regístralos en ODF. Si ODF se ejecuta en todos los nodos de trabajo de su clúster, los nuevos nodos se añaden automáticamente a la topología de almacenamiento. Si ODF se ejecuta solo en un subconjunto de nodos de trabajo, pasa al siguiente paso.

3. Si ODF se ejecuta en todos los nodos trabajadores de su clúster, los nuevos nodos trabajadores se añaden automáticamente a la topología del clúster de almacenamiento ODF. Si ODF se ejecuta solo en un subconjunto de nodos de trabajo, especifica los parámetros <workerNodes> privados en tu recurso personalizado OcsCluster. Añada los nombres de los nuevos nodos trabajadores a su despliegue ODF editando la definición de recursos personalizada. Modifica el recurso personalizado OcsCluster de la siguiente manera:

   • Buscar ocscluster

     oc get ocscluster
     

   • Edita el archivo de recursos personalizados de ocscluster y añade nuevos nodos de trabajo

     oc edit ocscluster <ocs cluster name> -o yaml
     

   • Guarda el archivo de recursos personalizados OcsCluster para volver a aplicarlo a tu clúster.

4. Aumenta el valor de 'numOfOsd' en tu recurso personalizado OcsCluster para permitir que OCS implemente componentes ODF en los nodos de trabajo recién añadidos y aprovisione OSD adicionales en el clúster de almacenamiento.

   El ajuste de 'numOfOsd' depende tanto del número de discos OSD por nodo como del número de nodos añadidos. Por ejemplo, si cada nodo tiene 8 discos NVMe dedicados a los OSD, añadir 3 nodos aumenta el número de 'numOfOsd' en 8, mientras que añadir 6 nodos lo aumenta en 16.

5. Comprueba el resultado ejecutando el siguiente comando :

   oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree
   

6. Comprueba que los nuevos nodos de trabajo se hayan añadido y estén distribuidos de forma uniforme en cada zona (en el caso de clústeres multizona) o que aparezcan como grupos de hosts individuales (en el caso de clústeres de escalado flexible de una sola zona), junto con el número correspondiente de OSD asignados a cada nodo.

Para obtener más información, consulta « Ampliar ODF añadiendo nodos de trabajo a tu clúster de VPC ».

Escalado flexible

El complemento ODF de IBM Cloud utiliza diferentes topologías de dominios de fallo en función de la configuración de su clúster:

• Clústeres multizona (3 zonas de disponibilidad): El dominio de fallo está configurado en zone. Los OSD se aprovisionan en múltiplos de 3, un conjunto por zona, para mantener la replicación de datos y la alta disponibilidad entre zonas. El clúster de almacenamiento debe ampliarse en múltiplos de 3 para mantener el equilibrio entre las zonas.
• Clústeres de una sola zona o clústeres con menos de tres zonas de disponibilidad: el escalado flexible se activa automáticamente. El dominio de fallo está configurado en host, lo que significa que cada nodo individual constituye un dominio de fallo distinto. Puedes añadir un nodo cada vez y ampliar el almacenamiento de forma granular.

A partir de ODF 4.21, el comportamiento de escalado flexible se determina automáticamente durante la implementación inicial en función de la topología del clúster y no se puede modificar posteriormente.

En una implementación de zona única o de escalado flexible, un grupo de replica-3 sigue funcionando aunque se pierda un único host. En una implementación multizona, un grupo de replica-3 sigue funcionando aunque se pierda una zona completa. Evalúa si la topología de tu clúster y su tolerancia a fallos asociada cumplen tus requisitos de resiliencia antes de implementar ODF en producción.

Para consultar el conjunto completo de parámetros de los complementos y los pasos de instalación desde la consola, véase Implementación de una base de datos de OpenShift en clústeres de VPC.

Rendimiento durante la ampliación de nodos: al añadir un nodo a un clúster ODF de escalado flexible, se activa el reequilibrio de datos de Ceph. En la prueba interna que se describe a continuación, las IOPS y el rendimiento se mantuvieron estables, mientras que la latencia de escritura aumentó temporalmente. En pruebas internas realizadas en un clúster de 3 nodos con 100 máquinas virtuales a 50 000 IOPS, se observaron los siguientes resultados:

La latencia de escritura vuelve a los valores normales una vez finalizado el reequilibrio. Planifica la incorporación de nodos durante los periodos de menor actividad de VM si tus cargas de trabajo son sensibles a los picos de latencia de escritura.