Hoy, me gustaría hablar sobre la resiliencia al fracaso, que es un tema importante de un reciente patente Qumulo ha sido otorgada.
En el sistema distribuido de Qumulo contamos con dos recursos de vital importancia para almacenar de manera confiable los archivos de nuestros usuarios. En primer lugar, son los medios de almacenamiento. Esto puede ser SSD, HDD o incluso almacenamiento de blobs en la nube. Para mis propósitos aquí, simplemente llamaremos disco a cualquier unidad de almacenamiento direccionable de forma independiente y que falle de forma independiente. A continuación, necesitamos un servidor conectado a la red (computación), que usamos para ejecutar nuestro software, así como para abordar tanto al usuario como a los discos. Puede ser una máquina física en un centro de datos o una máquina virtual en la nube pública. Juntos, llamamos clúster a todos los servidores y almacenamiento disponibles para nuestro software.
Todo el hardware falla y todos los servicios pueden perder datos. Es responsabilidad de Qumulo mantener la plena operatividad a través de cualquier combinación razonable de fallas y nunca perder los datos del cliente. Para cada clúster, definimos algunas fallas simultáneas de servidor y disco, que debemos soportar en función de las necesidades del cliente. Luego usamos una técnica conocida como codificación de borrado para proteger a los clientes de fallas tanto en el servidor como en el disco. Le recomiendo que lea nuestro publicación sobre codificación de borrado si no lo ha hecho, pero resumiré los puntos más importantes aquí.
Un concepto clave en los sistemas de archivos redundantes tolerantes a fallas como Qumulo es la "eficiencia". Esto se refiere a la cantidad de datos que un cliente puede almacenar en el clúster después de descontar el espacio que necesita el software del sistema de archivos. En las instalaciones, los discos siempre están conectados a los servidores y, por lo tanto, si el servidor no estaba disponible, tampoco lo estaban los datos. Eso limita la eficiencia máxima de cualquier esquema basado en codificación utilizado para proteger datos. Por ejemplo, un clúster de cuatro servidores solo puede tener datos codificados con una eficiencia del 75 % si el cliente desea seguir operando con acceso de solo lectura a todos los datos con 1 servidor fuera de línea. Si queremos escribir en una fracción del almacenamiento fuera de línea, nos limitamos a codificar con una eficiencia de no más del 66 %.
A escalas moderadas, un clúster de ocho servidores que permite dos fallas de servidor simultáneas tiene las mismas restricciones de eficiencia de codificación que el clúster de cuatro servidores que permite una falla de servidor. Puede extrapolar proporcionalmente este argumento a tamaños de clúster cada vez más grandes.
Nuestra solución a este problema fue modelar cuidadosamente el tiempo medio de pérdida de datos (MTTDL) con varias combinaciones de fallas del servidor y del disco, y luego permitir solo configuraciones que superen un umbral muy alto. En clústeres grandes, la eficiencia de codificación puede llegar al 90 %.
Esa solución es lo más cercana posible a la óptima en las instalaciones, pero podemos hacerlo mejor en la nube. En las nubes, Qumulo utiliza almacenamiento remoto. Usos de Qumulo en Azure como servicio Almacenamiento de blobs de Azure para sus necesidades de almacenamiento. Dado que el almacenamiento de Qumulo no está físicamente en el servidor, nuestro servicio puede aplicar la misma lógica anterior a los discos. Debido a que hay proporcionalmente muchos más discos que servidores en un clúster típico, nuestro servicio puede alcanzar una eficiencia mucho mayor a pequeña escala. En teoría, podríamos alcanzar ese marcador de eficiencia del 90 % en nuestro clúster de Azure de menor escala. En las nubes con medios de almacenamiento fiables como Azure, podemos llegar incluso al 95 % de eficiencia.
NUESTRO Equipo de ingeniería recientemente entregó una mejora de producto aprovechando este enfoque patentado. Los "discos flotantes" permiten a Qumulo como servicio reasignar el almacenamiento remoto a un servidor diferente si el servidor que lo alojaba anteriormente se desconecta. Esto nos permitirá admitir menos del 50 % de los servidores que fallan simultáneamente, al tiempo que nos permite ser mucho más eficientes a pequeña escala. Así es como se ve construir un verdadero servicio de almacenamiento nativo en la nube.
