Almacenamiento en la era de la IA (4/4): disponibilidad

Hemos recorrido el estado del arte, el rendimiento y la seguridad. Cierra la serie la propiedad de la que dependen todas las demás: la disponibilidad. Un almacenamiento rapidísimo y perfectamente cifrado no vale nada si un fallo tumba una factoría de inferencia bajo SLA, detiene un entrenamiento de miles de GPUs o deja que un dataset de petabytes se corrompa en silencio. Y a la escala de la IA, los fallos no son un evento excepcional: son el régimen permanente de operación. La diferencia está en cómo se convive con ellos: el entrenamiento se reanuda desde un checkpoint; una factoría de inferencia, en cambio, no puede permitirse parar, y debe seguir respondiendo mientras un componente falla por debajo. Veremos ambos casos, con el foco puesto en el servicio continuo.

Disponibilidad y durabilidad no son lo mismo

Conviene empezar separando dos conceptos que se confunden a menudo. La disponibilidad mide qué fracción del tiempo el dato es accesible; la durabilidad mide la probabilidad de no perderlo. Un sistema puede ser muy duradero pero poco disponible (los datos están a salvo pero ahora mismo no se pueden leer) y viceversa.

La disponibilidad se modela con la conocida relación entre tiempo medio entre fallos y tiempo medio de reparación:

$$A = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}$$

De ahí salen los “nueves” que todo el mundo cita, cuya traducción a tiempo de inactividad anual conviene tener interiorizada:

Disponibilidad“Nueves”Inactividad anual
99,9 %tres nueves~8,8 horas
99,99 %cuatro nueves~52,6 minutos
99,999 %cinco nueves~5,3 minutos
99,9999 %seis nueves~32 segundos

Un detalle que sorprende a quien viene del mundo on-premise: los servicios de almacenamiento de cloud público no suelen ofrecer un SLA superior a cuatro nueves (99,99 %). AWS S3, por ejemplo, garantiza 99,99 % de disponibilidad por región. Los seis nueves son territorio de cabinas empresariales en configuración stretch cluster: Pure Storage los ofrece en esa topología, frente a “cinco nueves y pico” en nodo único. La fórmula deja claro por qué reducir el MTTR —recuperar rápido— suele ser más rentable que perseguir un MTBF imposible.

Durabilidad: los “once nueves” y lo que esconden

La durabilidad se expresa en cifras que parecen de marketing pero tienen un significado preciso. Los “once nueves” de S3 (99,999999999 %) significan que, si almacenas diez millones de objetos, esperarías perder uno cada diez mil años. ¿Cómo se llega ahí? AWS parte de las tasas de fallo irrecuperable del hardware, replica en tres zonas de disponibilidad independientes por región y aplica erasure coding con fragmentación solapada. La advertencia honesta es que no existe un estándar acordado de cómo se calculan los nueves: cada fabricante usa su metodología, y comparar cifras de durabilidad entre proveedores es, en rigor, comparar supuestos.

El mecanismo que produce esas cifras estratosféricas es la combinación de redundancia e independencia de fallos. Si un sistema guarda cada objeto de forma que tolere la pérdida de varios fragmentos, y distribuye esos fragmentos en dominios de fallo independientes —discos, nodos, racks, zonas de disponibilidad distintas—, la probabilidad de perder simultáneamente todos los fragmentos necesarios se vuelve astronómicamente pequeña. La palabra clave es independientes: si los fragmentos comparten un punto único de fallo —la misma fuente de alimentación, el mismo conmutador, la misma zona—, la independencia es ficticia y la durabilidad calculada, una ilusión. Buena parte de las pérdidas de datos reales en sistemas teóricamente durables provienen de correlaciones de fallo que el modelo no contempló: un lote de discos defectuosos del mismo fabricante, un error de software que corrompe todas las réplicas a la vez, un borrado accidental que se propaga. La durabilidad de verdad exige diversidad, no solo cantidad.

Para anclar esos supuestos en la realidad hay una fuente impagable: las estadísticas de discos de Backblaze. En sus datos de 2025 (publicados en febrero de 2026) la tasa anualizada de fallos (AFR) de su flota de 344.196 discos bajó al 1,36 %, desde el 1,55 % de 2024, lo más bajo desde 2022; el AFR de por vida se mantiene estable en el 1,30 %. Los discos de 14-16 TB ya son el 52 % de la flota y los de 20 TB o más rondan el 23 %. Estos números son la materia prima con la que se calcula cualquier durabilidad creíble.

Pero el fallo total del disco no es la amenaza más insidiosa. Lo es la corrupción silenciosa (bit rot). Los discos enterprise tienen una tasa de error de lectura no recuperable del orden de un bit por cada ( 10^{14} ) bits leídos —unos 11 TB—, y esa tasa apenas ha mejorado mientras la capacidad se disparaba. Un estudio clásico de NetApp sobre 1,53 millones de discos durante 41 meses encontró más de 400.000 discordancias de checksum, de las cuales 30.000 no fueron detectadas por el controlador RAID y solo aparecieron durante el scrubbing; los discos nearline se corrompen a diez veces la tasa de los enterprise. La lección: a escala de petabytes, el scrubbing periódico y los checksums de extremo a extremo (como los de ZFS) no son opcionales, porque la corrupción que el RAID no ve es la que destruye un dataset de entrenamiento sin avisar.

Redundancia: por qué el RAID clásico ya no basta

La forma tradicional de tolerar fallos de disco —el RAID con paridad— se ha vuelto problemática precisamente por el crecimiento de la capacidad. El motivo es el tiempo de reconstrucción. La velocidad de escritura secuencial de los discos no ha crecido al ritmo de su capacidad, de modo que reconstruir un disco grande tarda cada vez más: un HDD nearline de 16 TB en RAID 5 puede tardar entre 24 y 72 horas en reconstruirse. Durante esa ventana, el array está degradado y expuesto a un segundo fallo.

Y hay un riesgo más sutil. Reconstruir un disco obliga a leer todos los demás por completo, lo que multiplica la exposición a un error de lectura no recuperable. Reconstruir un RAID 5 de ocho discos de 8 TB implica leer 56 TB; con discos enterprise eso supone alrededor de un 30 % de probabilidad de toparse con un URE que aborte la reconstrucción, y con discos de consumo la probabilidad se acerca al 96 %. Por eso RAID 5 está, sencillamente, deprecado para arrays nuevos con discos de más de 4 TB. A esto se suma el write hole: si un corte de energía interrumpe una escritura, datos y paridad pueden quedar desincronizados y corromper el array —ZFS lo elimina con copy-on-write—.

La respuesta moderna tiene dos piezas. La primera es el erasure coding (códigos Reed-Solomon, esquemas ( k+m )): el objeto se divide en ( k ) fragmentos de datos y ( m ) de paridad, y cualquier ( k ) de los ( k+m ) bastan para reconstruirlo. Su eficiencia frente a la replicación es notable. El overhead de almacenamiento es:

$$O = \frac{k+m}{k}$$

Un esquema ( k=4 ), ( m=2 ) da un overhead de 1,5 —1 TB lógico ocupa 1,5 TB físicos y tolera dos fallos simultáneos— frente al factor 3 de la replicación triple. A escala de exabytes, esa diferencia entre 1,5 y 3 es decisiva en coste. El precio del erasure coding es más CPU en escrituras y reconstrucciones y una operativa más compleja, por lo que la replicación sigue prefiriéndose para datos sensibles a la latencia que se leen localmente.

La segunda pieza es el RAID declustered (dRAID): en lugar de concentrar la reconstrucción en un disco spare dedicado, distribuye la I/O de rebuild entre todos los discos del pool. El efecto sobre el tiempo de recuperación es drástico: un disco de 20 TB que en RAID tradicional tardaría más de 60 horas puede resilverarse en menos de 15 porque todos los discos supervivientes contribuyen a la vez. OpenZFS dRAID e IBM Storage Scale lo implementan. La idea de fondo conecta con la fórmula de disponibilidad: si no puedes evitar el fallo, minimiza el MTTR repartiendo el trabajo de recuperación.

Hay una variable que amplifica todo esto y que el flash ha cambiado de raíz: la velocidad del medio durante la reconstrucción. Reconstruir 10 TB sobre HDD, cuya transferencia ronda los 300 MB/s, puede llevar más de 55 horas; sobre SSD, con transferencias por encima de 6.000 MB/s, baja a menos de 3 —veinte veces más rápido—. Cuando se combina flash con dRAID, la ventana de vulnerabilidad tras un fallo se reduce de días a horas o minutos, y con ella la probabilidad de un segundo fallo concurrente que provoque pérdida de datos. Esta es una de las razones de fondo por las que las plataformas all-flash se han impuesto en IA: no solo rinden más, sino que se recuperan antes, y a esta escala la velocidad de recuperación es seguridad de los datos.

Replicación y RPO/RTO: cuánto puedes perder y cuánto puedes esperar

Para tolerar el fallo de un sitio entero entran en juego la replicación y dos métricas que todo plan de continuidad debe fijar: el RPO (Recovery Point Objective, la máxima pérdida de datos aceptable, medida en tiempo) y el RTO (Recovery Time Objective, el máximo tiempo de inactividad aceptable).

La replicación síncrona espeja cada escritura a un segundo emplazamiento antes de confirmarla, garantizando un RPO de cero —cero pérdida de datos—, pero su alcance está limitado por la latencia: en la práctica exige enlaces metropolitanos por debajo de unos 10 ms, y no sirve para distancias intercontinentales. La replicación asíncrona confirma la escritura localmente y propaga después, lo que permite cualquier distancia geográfica a cambio de un RPO de minutos u horas. Las topologías de stretch cluster activo-activo (como Pure ActiveCluster) consiguen RPO y RTO cero dentro del rango metropolitano, y algunas añaden un tercer sitio asíncrono para combinar consistencia local y protección geográfica. La decisión es siempre el mismo triángulo: distancia, coste y pérdida tolerable. No se pueden optimizar las tres a la vez.

Conviene desmontar un mito sobre la alta disponibilidad de los arrays. Se suele asumir que “activo-activo” es siempre superior a “activo-pasivo”, pero hay un matiz de rendimiento que importa. En una configuración activo-pasivo, el controlador secundario asume la carga tras un fallo sin haber estado sirviendo I/O, de modo que el rendimiento posterior al failover es predecible. En activo-activo, ambos controladores sirven carga en operación normal; cuando uno falla, el superviviente debe absorber su propia carga más la transferida, y puede no cumplir el SLA de rendimiento justo cuando más se necesita. No hay una respuesta universal: la elección depende de si se prioriza el rendimiento agregado en operación normal o la garantía de rendimiento en modo degradado. Lo que sí es innegociable son las actualizaciones no disruptivas (NDU): una cabina de IA seria se actualiza con el sistema encendido y sirviendo I/O, usando la misma rutina de failover dinámico que emplea ante un fallo. Si una actualización exige parar, esa cabina no está a la altura de una carga crítica.

El régimen de fallo permanente: por qué importa a la inferencia

Aquí es donde la disponibilidad del almacenamiento de IA se separa de todo lo anterior: a la escala de la IA, los fallos de hardware no son raros, son continuos. El dato más citado procede del entrenamiento de Llama 3 de Meta sobre un cluster de 16.384 GPUs H100: durante 54 días sufrió 419 fallos inesperados de componentes, un fallo de media cada tres horas, con un MTBF del cluster de aproximadamente 1,8 horas. Más del 66 % de las interrupciones se debieron a fallos de hardware —GPU defectuosas, memoria HBM3, SRAM, switches y cables de red—.

Aunque la cifra procede de un entrenamiento, la estadística subyacente se aplica igual a una factoría de inferencia: el mismo hardware falla a la misma tasa, y una flota de inferencia de cientos o miles de GPUs verá caer componentes a diario. La diferencia está en la respuesta. El entrenamiento absorbe el fallo reanudando desde un checkpoint; la inferencia lo absorbe con redundancia y conmutación en caliente, porque no puede pararse. En ambos casos, el almacenamiento es la pieza que hace posible la recuperación: en entrenamiento, como medio donde vive el checkpoint; en inferencia, como repositorio replicado desde el que se levanta al instante una réplica que sustituya a la caída. Por eso conviene entender bien el mecanismo de checkpointing aunque la factoría sea de inferencia: es el mismo principio de “asumir el fallo y recuperar rápido” llevado a su forma más extrema.

La razón es puramente estadística. Si un componente individual tiene un MTBF dado, el MTBF de un cluster de ( N ) componentes idénticos se reduce de forma inversamente proporcional:

$$\text{MTBF}{\text{cl}} = \frac{\text{MTBF}{\text{dev}}}{N}$$

Aunque cada GPU fallara solo una vez cada seis años (unas 50.000 horas), un cluster de 100.000 GPUs vería un fallo cada media hora, y uno de un millón, cada tres minutos. Esta es la realidad operativa que ningún diseño de almacenamiento de IA puede ignorar.

¿Cómo se convive con esto? Con checkpointing, que es tanto una herramienta de rendimiento (lo vimos en el artículo 2) como el mecanismo central de resiliencia: tras un fallo, el entrenamiento reanuda desde el último checkpoint en lugar de empezar de cero, salvando potencialmente semanas de cómputo. Esto invierte la relación habitual: el almacenamiento no es solo lo que hay que proteger, sino el instrumento que protege a la GPU. Existe incluso un debate de fondo —Epoch AI argumenta que con checkpointing basado en memoria distribuida entre GPUs, en lugar de basado en almacenamiento, los fallos de hardware dejarían de limitar el tamaño de los entrenamientos incluso más allá del millón de GPUs—. Sea cual sea el enfoque, la conclusión para el arquitecto es que la disponibilidad del subsistema de checkpointing es la disponibilidad del entrenamiento.

Un detalle revelador de los datos de Meta es que más de dos tercios de las interrupciones fueron de hardware —GPU, HBM3, SRAM, conmutadores y cables—, y que el almacenamiento, cuando está bien diseñado, no figura entre las causas principales de fallo, sino entre los mecanismos de recuperación. Esto invierte la psicología habitual del arquitecto de almacenamiento: a esta escala su trabajo no consiste tanto en evitar que su subsistema falle —aunque debe hacerlo— como en garantizar que, cuando falle cualquier otra cosa, el entrenamiento pueda reanudarse rápido. El almacenamiento de un clúster de IA es, en buena medida, infraestructura de resiliencia para el resto del clúster. Dimensionar el ancho de banda de escritura del checkpointing y la velocidad de relectura tras un reinicio es, por tanto, una decisión de disponibilidad de todo el sistema, no una métrica aislada de la cabina.

Disponibilidad en una factoría de inferencia: el servicio no para

Todo lo anterior —fallos a escala, checkpointing, MTBF de clústeres— está descrito desde la óptica del entrenamiento, que es un trabajo por lotes: si se cae, se reanuda y se pierde tiempo, pero nadie está esperando al otro lado. Una factoría de inferencia es lo contrario: un servicio en línea sometido a un SLA, donde cada segundo de indisponibilidad es una petición fallida y, a menudo, una penalización contractual. Su disponibilidad se diseña con otra mentalidad.

El primer principio es que el plano de servicio debe sobrevivir al fallo de cualquier componente sin interrumpir las peticiones. Eso implica réplicas redundantes de cada modelo servido, balanceo que retira automáticamente una réplica caída, y —en el plano de almacenamiento— que ninguno de los cuatro planos de la factoría sea un punto único de fallo. El repositorio de modelos debe estar replicado y disponible, porque si se cae no se pueden arrancar réplicas nuevas justo cuando se necesitan para sustituir a las que fallan. La base de datos vectorial de RAG necesita su propia alta disponibilidad, porque sin ella el servicio degrada su calidad o deja de responder. Y la capa de KV-cache, aunque sea efímera, condiciona la latencia: perder una caché compartida obliga a recomputar y dispara el TTFT de golpe para todos los clientes afectados.

El segundo principio es la actualización de modelos sin downtime. En una factoría de inferencia los modelos se rotan con frecuencia —versiones nuevas, ajustes, rollbacks—, y hacerlo sin cortar el servicio exige patrones de despliegue progresivo: blue-green (levantar la versión nueva en paralelo y conmutar el tráfico cuando está caliente) o canary (enviar una fracción del tráfico a la versión nueva y ampliarla si se comporta). Ambos patrones tienen una implicación de almacenamiento directa: durante la transición conviven dos conjuntos de pesos en el repositorio y, a veces, en la HBM, lo que exige capacidad y ancho de banda de carga para que la versión nueva esté lista antes de recibir tráfico. Un repositorio de modelos lento no solo retrasa el autoescalado: ralentiza cada despliegue y alarga la ventana de riesgo.

El tercer principio es el autoescalado elástico, que convierte el tiempo de cold start —el de cargar pesos desde el almacenamiento, que vimos en el artículo de rendimiento— en una métrica de disponibilidad. Si arrancar una réplica nueva tarda minutos porque el repositorio es lento, la factoría no absorbe los picos y degrada o rechaza peticiones precisamente cuando más demanda hay. La elasticidad real de una factoría de inferencia está limitada por la velocidad a la que su almacenamiento entrega los modelos. Por eso muchas instalaciones mantienen una reserva de pesos en flash local caliente y usan rutas de carga aceleradas: la disponibilidad bajo carga variable se gana, en buena parte, en la capa de almacenamiento.

El cuarto principio es la redundancia del propio plano de servicio, que se puede dimensionar con números. Si una réplica de servicio tiene una disponibilidad individual ( a ) (limitada por su GPU, su nodo y su acceso al almacenamiento), un servicio con ( n ) réplicas independientes en el que basta una para responder alcanza una disponibilidad de:

$$A = 1 - (1 - a)^{n}$$

La fórmula explica por qué la redundancia es tan eficaz: con réplicas razonablemente disponibles, cada réplica adicional añade nueves al servicio. Pero su hipótesis es la misma que vimos en la durabilidad: la independencia. Si todas las réplicas dependen del mismo repositorio de modelos, de la misma base de datos vectorial o de la misma capa de KV-cache, ese componente compartido es el verdadero límite de la disponibilidad por mucho que se multipliquen las réplicas de GPU. De ahí que, en una factoría de inferencia, replicar y dar alta disponibilidad a los planos de almacenamiento —repositorio, vector DB, caché— sea tan importante como replicar las propias GPU de servicio: son ellos, y no el cómputo, los puntos únicos de fallo que suelen pasarse por alto.

La conclusión es que en una factoría de inferencia la disponibilidad del almacenamiento se mide en términos de servicio continuo: no “¿cuánto tardo en recuperar el dato?” sino “¿sigue respondiendo el servicio mientras se cae un componente, se actualiza un modelo o se duplica la demanda?”. Es un objetivo de cinco o seis nueves sobre un sistema vivo, no de durabilidad sobre un archivo en reposo.

Recuperación ante desastres: la regla 3-2-1 y el problema del petabyte

Para el desastre mayor —pérdida de un sitio, ataque destructivo— la referencia sigue siendo la regla 3-2-1: tres copias del dato, en dos tipos de medio distintos, con al menos una fuera del emplazamiento. Su evolución en 2025 le añade dos exigencias: inmutabilidad (la copia off-site debe ser inalterable, conectando con la defensa anti-ransomware del artículo de seguridad) y recuperabilidad verificada (un backup que no se ha probado restaurar no es un backup).

A escala de IA aparece un obstáculo físico difícil de eludir: el tiempo de recuperación de datasets masivos. Restaurar petabytes desde una copia off-site puede tardar días o semanas sobre conexiones estándar, un RTO inaceptable para muchas operaciones. Las organizaciones con petabytes ni siquiera pueden hacer el backup inicial a cloud por internet convencional; necesitan transferencia física o enlaces dedicados. Dimensionar la recuperación —no solo la copia— es donde fallan la mayoría de los planes de DR de IA.

Cuando la nube también cae

Conviene recordar que delegar en un hyperscaler no elimina el problema, solo lo traslada. 2025 dejó un recordatorio contundente: la gran caída de AWS del 19-20 de octubre de 2025, originada por una condición de carrera en un microservicio interno de DynamoDB que generó un registro DNS vacío, cascadeó a EC2 y se prolongó unas quince horas, con más de diecisiete millones de reportes y servicios globales caídos. Hubo precedentes en julio de 2024 (us-east-1, por Kinesis) y febrero de 2025 (Estocolmo). La moraleja para una arquitectura de IA crítica es la de siempre: la resiliencia multirregión o multinube es una decisión de diseño consciente, no una propiedad que se hereda por contratar cloud.

La tendencia: almacenamiento que se cura solo

El vector de evolución para 2026 es la incorporación de IA a la propia capa de almacenamiento para defensa self-healing: predicción de fallos antes de que ocurran, tiering y migración automáticos, remediación previa y recuperación instantánea ante ransomware. El hardware de almacenamiento “ya no es pasivo”, como vimos en seguridad. A escala de exabyte, el almacenamiento de objetos se consolida como núcleo por combinar durabilidad masiva con metadatos flexibles y versionado, mientras la cinta resurge como tier de archivo activo para datasets de IA, combatiendo el coste del flash y el HDD. Con un crecimiento de datos del 30-40 % anual, la automatización de la resiliencia deja de ser una comodidad para convertirse en una necesidad: a esa escala, ningún equipo humano gestiona los fallos a mano.

Las garantías comerciales se han movido en la misma dirección. Algunos fabricantes ofrecen ya SLA contractuales que antes eran impensables: Pure, con su modelo Evergreen//One, anuncia hasta diez SLA garantizados distintos, incluyendo seis nueves de uptime, cero pérdida de datos, un colchón de capacidad y cero tiempo de parada planificado por actualizaciones, además de un SLA específico de recuperación tras ciberataque que garantiza arrays limpios. Sea cual sea el fabricante, la tendencia indica un cambio de modelo: de vender hardware a garantizar resultados de disponibilidad. Para el arquitecto, esto traslada parte del riesgo al proveedor, pero no exime de diseñar: un SLA contractual compensa económicamente una caída, no la evita, y la continuidad de un entrenamiento de millones de euros no se restaura con una nota de crédito.

La disponibilidad se gobierna con observabilidad

Ninguna de estas técnicas funciona a ciegas. Sostener la disponibilidad a escala de IA exige observabilidad: monitorización del estado de cada disco (con telemetría tipo SMART y predicción de fallos), del progreso y la integridad de los scrubs, de la latencia de replicación frente a su objetivo de RPO, y de la salud de los checkpoints —que se escriben, sí, pero también que se pueden releer—. La métrica que más engaña es la del backup que nunca se ha restaurado: una copia no verificada es una hipótesis, no una garantía. La disciplina operativa que distingue a una infraestructura resiliente es la prueba periódica de recuperación, a escala realista, midiendo el RTO real frente al objetivo. A la escala de petabytes y miles de GPU, lo que no se mide no se puede garantizar, y lo que no se ensaya tiende a fallar precisamente el día que se necesita.

Para llevarse a casa, y cierre de la serie

La disponibilidad del almacenamiento de IA se diseña sobre cuatro pilares: redundancia eficiente (erasure coding y dRAID en lugar de RAID clásico, que ya no aguanta los discos grandes), durabilidad verificada (con scrubbing y checksums frente a la corrupción silenciosa), replicación con RPO/RTO explícitos según la criticidad, y una resiliencia de pipeline que asume el fallo como estado normal y se apoya en el checkpointing. La fórmula de disponibilidad recuerda la prioridad práctica: cuando no puedes evitar el fallo —y a escala de IA no puedes—, lo que marca la diferencia es recuperar rápido.

Con esto cerramos la serie. El estado del arte nos dio el mapa; el rendimiento, la razón de ser; la seguridad, la protección; y la disponibilidad, la garantía de que todo lo anterior siga estando ahí mañana. En la era de la IA, el almacenamiento ha dejado de ser el sótano silencioso del datacenter para convertirse en lo que decide si las GPU —el recurso más caro y escaso— trabajan o esperan.

Ver también

Fuentes