IBM Storage Ceph acelera el rendimiento del clúster, pero la prueba de referencia está por llegar
IBM Storage Ceph acelera el rendimiento del clúster en la versión 9.9.2 al mover los metadatos a los que se accede con frecuencia a un almacenamiento más rápido, en lugar de dejarlos en dispositivos más lentos.
La versión del 14 de octubre introduce BlueFS Spillover Cleaner, un mecanismo automatizado de organización por niveles para los metadatos gestionados mediante RocksDB. IBM afirma que la función debería mejorar la consistencia y reducir la latencia en cargas de trabajo importantes. Sin embargo, su anuncio no incluye resultados de pruebas de referencia.
Esa ausencia crea la tensión central. IBM ha abordado un problema real de rendimiento dentro de los clústeres Ceph con medios mixtos, pero los compradores aún necesitan evidencia a nivel de carga de trabajo. La versión cuestiona la idea de que mejorar un clúster de almacenamiento distribuido siempre exige más memoria flash, más nodos o una gran renovación de hardware.
También ejerce presión sobre las implementaciones comunitarias de Ceph y las plataformas de almacenamiento competidoras. Los administradores deben determinar ahora si la colocación automatizada de metadatos ofrece mejoras significativas sin añadir riesgos inaceptables de migración, supervisión o actualización.
IBM Storage Ceph acelera el rendimiento del clúster mediante la organización de metadatos por niveles
El cambio importante no es un nuevo protocolo de almacenamiento. Es una decisión automatizada sobre dónde mantiene Ceph sus metadatos más activos.
IBM Storage Ceph 9.9.2 estuvo disponible de forma general el 14 de octubre de 2026. IBM describe el producto como una plataforma definida por software con soporte empresarial que proporciona almacenamiento en bloques, archivos y objetos mediante una única pila tecnológica.
La función de rendimiento central de esta versión es BlueFS Spillover Cleaner. IBM también denomina al mecanismo subyacente Intelligent BlueFS Tiering Manager.
BlueFS es un pequeño sistema de archivos utilizado por BlueStore, el backend de almacenamiento de Ceph, para gestionar archivos de RocksDB. RocksDB es una base de datos integrada de clave-valor que registra metadatos internos, incluidas las asignaciones entre objetos lógicos y almacenamiento físico.
Un dispositivo de almacenamiento Ceph puede utilizar varios niveles de medios. El dispositivo WAL aloja el registro de escritura anticipada, mientras que un dispositivo DB opcional almacena metadatos de RocksDB. El dispositivo principal aloja los datos de objetos y también puede recibir metadatos que ya no caben en otros lugares.
Los administradores suelen colocar las funciones DB y WAL en dispositivos SSD o NVMe. Así pueden mantener grandes conjuntos de datos de objetos en discos duros menos costosos.
Esta arquitectura crea un modo de fallo importante. Cuando el dispositivo DB rápido se llena, los archivos de RocksDB pueden desbordarse hacia el dispositivo de datos principal. Un disco duro puede proporcionar capacidad suficiente, pero el acceso a los metadatos se vuelve más lento y menos predecible tras ese desbordamiento.
El nuevo gestor examina continuamente los patrones de acceso a archivos. Según el resumen de la versión 9.9.2 de IBM, reubica los archivos a los que se accede con frecuencia en el dispositivo DB y desplaza los menos activos hacia medios más lentos.
El mecanismo se asemeja a la gestión de caché, pero opera sobre archivos de RocksDB en lugar de objetos de aplicaciones. Intenta reservar la capacidad limitada de alta velocidad para los metadatos que contribuyen más directamente a las cargas de trabajo activas.
Esta distinción importa. Las aplicaciones no necesitan identificar metadatos activos ni emitir comandos especiales de colocación. La capa de almacenamiento supervisa la actividad y modifica la ubicación de los archivos en segundo plano.
El informe inicial de rendimiento sostiene que esta disposición mantiene los metadatos de alto valor en medios más rápidos. También debería evitar que los archivos de base de datos inactivos consuman indefinidamente la escasa capacidad de SSD.
IBM afirma que el resultado es un acceso a metadatos más eficiente, menor latencia y un rendimiento de clúster más consistente. Estas afirmaciones siguen siendo declaraciones del proveedor hasta que pruebas independientes midan el efecto con cargas de trabajo repetibles.
IBM Storage Ceph 9.9.2 también incluye actualizaciones más amplias. Estas abarcan la gestión de puertas de enlace NVMe/TCP, exploración de objetos S3, cuarentena de CephFS, conmutación por error de NFS, integración de SMB y administración de clústeres.
Varias incorporaciones siguen siendo vistas previas tecnológicas. La deduplicación completa de objetos, la migración transparente de estado de NFS, el soporte SMB para macOS y el acceso SMB mediante S3 no se presentan todos como funciones maduras para producción.
BlueFS Spillover Cleaner es diferente porque aborda el núcleo RADOS, la capa de objetos distribuida que sustenta los servicios de Ceph. Por tanto, sus efectos pueden alcanzar cargas de trabajo expuestas mediante múltiples interfaces.
La función también se dirige a un problema operativo recurrente en lugar de añadir otro método de acceso. IBM intenta extraer un rendimiento más estable de hardware que muchos clientes ya utilizan.
Eso hace que esta actualización sea más importante de lo que su descripción limitada sugiere. A los compradores de almacenamiento se les ofrece un mecanismo de software que podría retrasar la expansión de hardware, siempre que la mejora se mantenga en condiciones reales de implementación.
Por qué la colocación de metadatos se convierte en un problema de rendimiento para todo el clúster
Una pequeña cantidad de metadatos mal ubicados puede influir en un conjunto de datos mucho mayor porque cada operación sobre objetos depende de asignaciones internas precisas.
Ceph distribuye información entre muchos demonios de almacenamiento de objetos, conocidos como OSD. Cada OSD gestiona un dispositivo de almacenamiento local y participa en la replicación, recuperación, reequilibrio y operaciones de clientes.
BlueStore escribe datos directamente en dispositivos de bloques sin procesar. Utiliza RocksDB para los metadatos que describen dónde residen los objetos y sus componentes. BlueFS proporciona servicios de sistema de archivos a esa base de datos.
Una búsqueda de metadatos es pequeña en comparación con una gran transferencia de objetos. Sin embargo, las búsquedas retrasadas pueden situarse en la ruta crítica de muchas solicitudes de aplicaciones. El efecto se hace más visible cuando las cargas de trabajo generan grandes cantidades de operaciones pequeñas o aleatorias.
El rendimiento también puede volverse inconsistente en lugar de uniformemente lento. Una solicitud puede acceder a metadatos en un SSD, mientras que otra toca un archivo de RocksDB que se desbordó hacia un disco duro.
El rendimiento medio puede ocultar esa diferencia. Las plataformas de bases de datos, las máquinas virtuales y la analítica interactiva suelen responder de forma más visible a la latencia de cola larga que al ancho de banda secuencial destacado.
Por eso importa la decisión de IBM de automatizar la colocación. Un clúster puede tener dispositivos DB rápidos instalados y, aun así, utilizarlos de forma deficiente después de que cambie su huella de metadatos.
El crecimiento puede generar esa condición gradualmente. Más objetos, instantáneas, buckets o grupos de colocación aumentan la presión sobre los metadatos incluso si el hardware subyacente sigue funcionando correctamente.
Los eventos operativos pueden añadir más tensión. El reequilibrio, la recuperación, la compactación y las actividades de mantenimiento pueden alterar los patrones de acceso o competir por los recursos del dispositivo.
Los administradores pueden dimensionar los dispositivos DB y supervisar el desbordamiento, pero los planes estáticos no siempre se ajustan a cargas de trabajo cambiantes. Un clúster diseñado para objetos grandes puede recibir más adelante muchos archivos pequeños o imágenes de máquinas virtuales que cambian rápidamente.
BlueFS Spillover Cleaner intenta hacer adaptable el nivel rápido. Promueve archivos activos de RocksDB y degrada los más fríos según el acceso observado.
El concepto es fácil de entender, pero su implementación plantea preguntas difíciles. El gestor debe identificar patrones útiles sin crear un exceso de E/S en segundo plano. También debe evitar mover archivos con tanta frecuencia que la organización por niveles consuma el beneficio que busca.
IBM no ha publicado en su anuncio los umbrales de la política ni un modelo detallado de decisión. Por ello, los compradores carecen de una visión clara de la rapidez con la que el gestor reacciona a los cambios de carga de trabajo.
También necesitan saber cómo se comporta la función durante la compactación. RocksDB reorganiza periódicamente los archivos de datos, creando actividad de escritura que puede cambiar los tamaños de archivo y los patrones de acceso.
El limpiador podría ser especialmente valioso en clústeres híbridos que combinan discos duros de alta capacidad con dispositivos SSD más pequeños para metadatos. Esos sistemas muestran la mayor diferencia de rendimiento entre los medios DB y SLOW.
Los clústeres totalmente flash presentan un caso distinto. Mover metadatos entre dos niveles flash aún puede importar, pero la diferencia de latencia puede ser menor. La CPU, la red o la serialización del software podrían convertirse en la limitación dominante.
La guía de hardware de IBM recalca que Storage Ceph puede ejecutarse en sistemas comerciales no propietarios. Es compatible con procesadores Intel y AMD x86-64, mientras que la versión 9.9.0 añadió soporte completo para ARM.
Esta flexibilidad de hardware es fundamental para el atractivo de Ceph. También significa que ninguna afirmación única de rendimiento puede representar todas las implementaciones.
El tipo de unidad, el diseño de red, la densidad de OSD, la asignación de CPU, el dominio de fallo, la política de protección de datos y el tamaño de los objetos pueden modificar los resultados. Una función de organización por niveles hereda esa variabilidad.
Por tanto, la promesa práctica es más limitada que simplemente hacer Ceph más rápido. IBM Storage Ceph acelera el rendimiento del clúster cuando el desbordamiento de metadatos constituye un cuello de botella significativo y sigue habiendo capacidad DB rápida disponible.
Esa condición existirá en muchos sistemas de medios mixtos, pero no en todos. Los compradores deberían identificar primero el origen de su latencia antes de considerar una actualización como solución universal.
La verdadera competencia es la optimización de software frente a la expansión de hardware
El argumento más sólido de IBM es que una colocación más inteligente puede recuperar rendimiento sin obligar a los clientes a sustituir el nivel de capacidad del clúster.
Una respuesta habitual a la presión sobre el almacenamiento es añadir recursos. Los administradores pueden instalar dispositivos DB más grandes, sustituir discos duros por SSD, añadir nodos o rediseñar la red.
Estas acciones pueden funcionar, pero afectan a los presupuestos, los calendarios de mantenimiento, la planificación de fallos y la capacidad física. Ampliar un clúster distribuido también puede provocar movimiento de datos antes de que los nuevos recursos aporten todo su beneficio.
BlueFS Spillover Cleaner ofrece otra vía. Busca mejorar el valor de la memoria flash ya instalada al priorizar continuamente los metadatos activos.
Esto establece el principal adversario de la versión: optimización dirigida por software frente a expansión liderada por hardware. IBM apuesta a que la inteligencia de colocación puede posponer al menos algunos cambios de infraestructura.
La empresa no elimina la necesidad de planificación de capacidad. Un nivel DB gravemente subdimensionado no puede retener todos los archivos activos, independientemente de lo bien que el software los clasifique.
Tampoco puede la organización de metadatos por niveles reparar una red saturada o un procesador sobrecargado. No convertirá el almacenamiento de objetos en discos duros en una matriz totalmente flash para todas las cargas de trabajo.
Su valor reside en evitar el desperdicio. Si los metadatos inactivos ocupan medios rápidos mientras los metadatos activos se encuentran en dispositivos más lentos, comprar más hardware trata el síntoma sin corregir la colocación.
El cambio también refuerza el argumento de la edición empresarial frente a las operaciones Ceph de tipo hágalo usted mismo. Ceph comunitario sigue siendo abierto y altamente configurable, pero las organizaciones deben integrar, validar, supervisar y dar soporte a la configuración elegida.
IBM empaqueta código Ceph con versiones probadas, interfaces de gestión, procesos de actualización, opciones de hardware y soporte empresarial. Un gestor automatizado de organización por niveles ofrece a los compradores otra razón para comparar la distribución con soporte frente a las implementaciones mantenidas internamente.
No se trata de un simple conflicto entre software propietario y código abierto. IBM Storage Ceph sigue basándose en Ceph, e IBM contribuye dentro del ecosistema más amplio.
La verdadera distinción se refiere a la responsabilidad operativa. Los usuarios de la comunidad pueden ajustar los sistemas directamente, mientras que los clientes de IBM pagan por un ciclo de vida seleccionado y una implementación con soporte.
Red Hat también ofrece tecnología Ceph empresarial a través de Red Hat Ceph Storage e integraciones de plataforma. IBM asumió la responsabilidad de la oferta Ceph empresarial de Red Hat en 2023, incorporando Ceph a su cartera más amplia de almacenamiento.
Los proveedores tradicionales de almacenamiento adoptan otro enfoque. A menudo combinan software propietario con hardware estrictamente controlado, lo que reduce las variaciones de configuración pero limita la flexibilidad del hardware estándar.
IBM ocupa un punto intermedio. Ofrece almacenamiento definido por software con soporte, nodos validados opcionales y opciones de implementación que van más allá de un único modelo de appliance.
El gestor de rendimiento encaja bien en esa posición. IBM puede mejorar el comportamiento mediante software mientras preserva la capacidad de elección del hardware.
La versión 9.9.2 también incluye actualizaciones graduales sin tiempo de inactividad para las instancias de RADOS Gateway. IBM afirma que las nuevas versiones de RGW pueden iniciarse junto a las instancias existentes mientras las solicitudes activas finalizan en las versiones anteriores.
Esta función refuerza el argumento operativo. El rendimiento importa, pero las empresas también evalúan si el mantenimiento interrumpe las aplicaciones compatibles con S3.
La versión añade controles de ciclo de vida mejorados para grupos de gateways NVMe/TCP. Los administradores obtienen una gestión ampliada de hosts, acceso, redes y visualización a través del panel.
Estos cambios no aceleran directamente RocksDB. Reducen el coste administrativo asociado a los servicios de bloques y objetos, lo que influye en el valor total de una distribución empresarial.
Las versiones anteriores de Ceph de IBM ya buscaban mejorar el rendimiento mediante otros mecanismos. Storage Ceph 8.0 incluyó mejoras en snapshots y mantuvo el backend Crimson como vista previa tecnológica.
Crimson es una arquitectura OSD más reciente, diseñada en torno al procesamiento asíncrono y la eficiencia de las CPU modernas. Aborda un problema más amplio de ejecución de software que el desbordamiento de metadatos.
La versión 9.9.0 también activó por defecto optimizaciones de codificación de borrado para los pools recién creados. IBM afirma que estas optimizaciones reducen el relleno y mejoran el comportamiento de operaciones de E/S pequeñas en configuraciones compatibles.
Este cambio beneficia a las cargas de trabajo de RBD, CephFS y objetos que contienen objetos pequeños o acceso aleatorio. Las cargas de trabajo de objetos secuenciales de gran tamaño obtienen menos beneficios, según la guía de optimización de IBM.
En conjunto, estos avances muestran una estrategia por capas. IBM está mejorando la eficiencia de la protección de datos, la ejecución de OSD, la ubicación de metadatos, la gestión de protocolos y los flujos de trabajo administrativos.
BlueFS Spillover Cleaner destaca porque aborda un desajuste inmediato entre el almacenamiento rápido y el lento. Promete un mejor comportamiento sin exigir cambios en las aplicaciones.
La cuestión competitiva pasa ahora a ser medible. ¿Puede la ubicación dirigida por software proporcionar una mejora suficiente como para retrasar la ampliación de hardware, o simplemente suaviza un cuello de botella limitado?
Lo que no muestra la afirmación de rendimiento de IBM
La versión identifica un mecanismo creíble, pero IBM no ha aportado suficientes datos para cuantificar su efecto en cargas de trabajo de producción.
Ni el anuncio de IBM ni el informe inicial incluyen resultados de benchmarks estandarizados para BlueFS Spillover Cleaner. No hay comparaciones publicadas de IOPS, rendimiento o latencia entre configuraciones con la función activada y desactivada.
IBM tampoco proporciona una distribución de latencia de cola. Esta omisión importa porque un rendimiento más consistente es uno de los beneficios declarados.
Los promedios por sí solos no resolverían la cuestión. Los compradores necesitan datos de percentiles que muestren si la función reduce las operaciones lentas ocasionales después del desbordamiento de metadatos.
El anuncio no especifica un clúster de prueba. Los lectores no pueden evaluar los tipos de unidades, las proporciones de dispositivos DB, las velocidades de red, los recuentos de OSD, la configuración de replicación ni los perfiles de objetos.
Tampoco separa los efectos de la función entre el acceso a bloques, archivos y objetos. Cada servicio exige requisitos distintos a la capa RADOS.
Una carga de trabajo de máquinas virtuales podría priorizar operaciones aleatorias de bloques pequeños. Un repositorio S3 podría contener objetos secuenciales grandes, mientras que una canalización de datos podría generar millones de archivos pequeños.
El valor del limpiador puede variar drásticamente entre estos casos. Un benchmark centrado en un dispositivo DB deliberadamente insuficiente podría exagerar los beneficios para clústeres correctamente aprovisionados.
A la inversa, una prueba breve podría subestimar la función. La organización automática por niveles necesita tiempo suficiente y variación en la carga de trabajo para reconocer los archivos activos y reorganizar su ubicación.
El movimiento en segundo plano crea otra incertidumbre. Las promociones y degradaciones consumen ancho de banda de E/S, y la versión no proporciona mediciones de esa sobrecarga.
Los administradores deberían preguntar cómo evita el sistema las oscilaciones. Una carga de trabajo que cambia rápidamente podría hacer que los archivos alternen entre niveles, salvo que la política aplique umbrales estables.
También deberían examinar el comportamiento de recuperación. Los clústeres Ceph pueden generar una intensa actividad interna después de fallos de dispositivos o nodos, precisamente cuando la latencia predecible cobra importancia.
La versión no explica si el limpiador se pausa, cambia prioridades o continúa moviendo archivos durante la recuperación. Estas decisiones podrían influir tanto en el tráfico de aplicaciones como en el tiempo de reparación.
El comportamiento durante las actualizaciones merece una atención similar. Las implementaciones existentes necesitan saber si el gestor se inicia automáticamente, requiere configuración o realiza una redistribución inicial.
El resumen público de IBM no proporciona una matriz de compatibilidad para todas las disposiciones históricas. Los compradores deberían verificar los requisitos previos en la documentación y probar un clúster representativo antes de activarlo en producción.
La capacidad sigue siendo un límite estricto. El limpiador puede clasificar los metadatos, pero no puede crear más espacio DB. Un conjunto de metadatos constantemente activos y mayor que el dispositivo rápido seguirá desbordándose.
La mejora también podría revelar otra limitación. Cuando la búsqueda de metadatos se vuelve más rápida, la saturación de red o el procesamiento de CPU podrían limitar las ganancias globales.
Esto no invalida el diseño de IBM. Define el límite de la afirmación.
La guía de arquitectura de Ceph describe un sistema distribuido cuyo comportamiento depende de componentes de almacenamiento, redes y software que interactúan entre sí. Optimizar una ruta no garantiza una mejora equivalente en el ámbito de la aplicación.
Por ello, las organizaciones deberían tratar IBM Storage Ceph 9.9.2 como una actualización verificable, no como sustituto de la observabilidad. Antes de implementarla, los equipos deberían registrar la latencia, el rendimiento, la utilización de dispositivos y las condiciones de desbordamiento de referencia.
Deberían reproducir cargas de trabajo representativas después de la actualización. Las pruebas deberían incluir tráfico en estado estable, cambios bruscos de carga, compactación de RocksDB, recuperación y operaciones de mantenimiento.
Los equipos deberían comparar la latencia por percentiles, no solo los promedios. También deberían seguir cuánto volumen de datos se mueve entre los dispositivos DB y SLOW.
Un resultado satisfactorio mostraría que los metadatos más activos permanecen en medios rápidos sin actividad disruptiva en segundo plano. También demostraría un beneficio a nivel de aplicación, no solo una disposición de almacenamiento más limpia.
Los benchmarks independientes siguen siendo especialmente importantes para las compras. IBM vende Storage Ceph como software, servicio y oferta combinada con hardware validado.
Estos modelos de implementación no producirán resultados idénticos. Los compradores necesitan evidencia de configuraciones que se parezcan a sus propios entornos.
La conclusión prudente es sencilla. IBM ha descrito una forma técnicamente plausible de reducir una fuente de latencia de Ceph, pero la evidencia pública se detiene antes de cuantificar su impacto.
Tres señales mostrarán si la mejora importa
La siguiente prueba es si el mecanismo de ubicación de IBM produce ganancias repetibles fuera de un anuncio de lanzamiento.
La primera señal es la publicación de benchmarks. IBM, sus socios o evaluadores independientes deberían comparar la versión 9.9.2 con el limpiador activado y desactivado sobre hardware idéntico.
Las pruebas útiles incluirían dispositivos de datos de discos duros combinados con dispositivos DB NVMe. Deberían informar de la latencia media y por percentiles, IOPS, rendimiento, sobrecarga de movimiento y ocupación del nivel DB.
Los perfiles independientes deberían cubrir máquinas virtuales, objetos S3 pequeños, objetos grandes y operaciones de CephFS intensivas en metadatos. Estos resultados reforzarían la afirmación de IBM si las mejoras se mantienen consistentes en más de una carga de trabajo.
Los resultados limitados a una demostración deliberadamente restringida debilitarían la interpretación más amplia. Aun así, podrían demostrar el mecanismo, pero no su valor general en producción.
La segunda señal es la evidencia operativa de clústeres actualizados. Los administradores deberían observar si los archivos RocksDB activos permanecen en dispositivos rápidos tras semanas de demanda cambiante.
Un comportamiento estable respaldaría el argumento de optimización mediante software de IBM. Migraciones frecuentes, amplificación de escritura inesperada o ajustes complejos inclinarían la ventaja hacia dispositivos DB más grandes y disposiciones estáticas más sencillas.
Las implementaciones reales también deberían revelar cómo se comporta el limpiador durante la recuperación y la compactación. Estos períodos pueden distinguir una política eficaz de otra optimizada para condiciones limpias de laboratorio.
La tercera señal es el paso de IBM de la descripción de funciones a una guía detallada de ciclo de vida. La documentación debería explicar valores predeterminados, umbrales, métricas de supervisión, alertas, comportamiento de reversión y requisitos previos de actualización.
Una guía clara indicaría que IBM espera un uso amplio en producción. Una documentación limitada sugeriría que los clientes deberían avanzar mediante implementaciones estrechamente supervisadas.
Las respuestas de competidores y del proyecto upstream importan, pero son secundarias. La evidencia decisiva procederá de los datos de rendimiento y la experiencia operativa, no de las comparaciones de marketing.
Los clientes también deberían seguir el trabajo continuo de IBM en Crimson. La organización por niveles de metadatos mejora la ubicación de archivos, mientras que Crimson apunta a la eficiencia dentro de la ruta de software OSD.
Si ambos maduran con éxito, IBM podrá argumentar que los límites de rendimiento de Ceph son cada vez más abordables mediante software. Esto reforzaría su posición frente a la expansión centrada en hardware y los sistemas de almacenamiento propietarios.
Las optimizaciones de codificación de borrado ofrecen otro punto de referencia. Muestran que IBM ya está cambiando el comportamiento predeterminado allí donde considera que las ganancias de eficiencia son lo bastante maduras para nuevos pools.
BlueFS Spillover Cleaner solo ganará una confianza similar cuando los clientes comprendan su comportamiento bajo carga sostenida. La ubicación automática debe seguir siendo predecible cuando el hardware falla o la demanda cambia de forma repentina.
La lección más amplia va más allá de Ceph. Los sistemas de almacenamiento modernos dependen cada vez más de pequeños niveles de medios rápidos que coordinan pools de capacidad mucho mayores.
Gestionar bien ese nivel rápido puede importar tanto como su tamaño nominal. Una mala ubicación desperdicia flash, mientras que un movimiento descontrolado puede generar su propia penalización de rendimiento.
IBM Storage Ceph acelera el rendimiento del clúster al convertir la ubicación de metadatos en un proceso activo. Es un cambio arquitectónico significativo, incluso sin un benchmark destacado.
Sin embargo, la arquitectura es solo el inicio de la decisión de compra. Los equipos empresariales necesitan saber cuánto disminuye la latencia, qué cargas de trabajo se benefician y qué coste operativo acompaña al movimiento.
La versión ofrece a los administradores un experimento concreto. Identifiquen clústeres con desbordamiento de BlueFS, establezcan una referencia, actualicen un entorno controlado y observen tanto la latencia de las aplicaciones como la actividad en segundo plano.
Si el limpiador promociona de forma consistente los archivos adecuados, IBM habrá demostrado que el software puede recuperar rendimiento del almacenamiento híbrido existente. Si las ganancias siguen siendo limitadas, la ampliación de hardware conservará su papel habitual.
Por ahora, IBM Storage Ceph 9.9.2 merece atención porque apunta a un cuello de botella específico mediante un mecanismo coherente. El siguiente paso corresponde a los operadores y evaluadores independientes.
¿Confirmarán los clústeres reales que la ubicación automatizada de metadatos retrasa la próxima compra de hardware, o revelarán que el cuello de botella simplemente se desplaza a otro lugar?
