Eventos
31 mar, 23 - 2 abr, 23
Evento de aprendizaje de Fabric, Power BI y SQL más grande. 31 de marzo – 2 de abril. Use el código FABINSIDER para ahorrar $400.
Regístrate hoy¿Qué es BlobFuse? - BlobFuse2
BlobFuse es un controlador del sistema de archivos virtual para Azure Blob Storage. Use BlobFuse para acceder a los datos de blob en bloques existentes de Azure mediante el sistema de archivos de Linux. No se admiten los blobs en páginas.
BlobFuse2 es un proyecto de código abierto que usa la biblioteca de código abierto libfuse (fuse3) para comunicarse con el módulo de kernel FUSE de Linux. BlobFuse2 implementa las operaciones del sistema de archivos mediante las API de REST de Azure Storage.
El proyecto de código abierto BlobFuse2 se puede encontrar en GitHub:
El proyecto BlobFuse2 se publica con la licencia MIT.
En el archivo README de BlobFuse2 hay una lista completa de las características de BlobFuse2. Estas son algunas de las tareas clave que puede realizar mediante BlobFuse2:
- Montar un contenedor de Azure Blob Storage o un sistema de archivos de Azure Data Lake Storage en Linux. (BlobFuse2 admite cuentas de almacenamiento con espacios de nombres planos o espacios de nombres jerárquicos configurados).
- Usar operaciones básicas del sistema de archivos como
mkdir,opendir,readdir,rmdir,open,read,create,write,close,unlink,truncate,statyrename. - Usar el almacenamiento en caché local para mejorar los tiempos de acceso posteriores.
- Obtener información sobre las actividades de montaje y el uso de recursos mediante el Health Monitor de BlobFuse2.
Otras características clave de BlobFuse2 incluyen:
- Streaming para admitir la lectura y escritura de archivos grandes
- Descargas y cargas paralelas para mejorar el tiempo de acceso de los archivos grandes
- Varios montajes en el mismo contenedor para cargas de trabajo de solo lectura
Importante
Debido a problemas conocidos de coherencia de datos al usar versiones anteriores de Blobfuse2 en streaming con block-cache modo, se recomienda encarecidamente que todas las instalaciones de Blobfuse2 se actualicen a la versión 2.3.2 o posterior. Para obtener más información, vea this.
BlobFuse2 tiene más compatibilidad con características y un rendimiento mejorado en varios escenarios de usuario de BlobFuse v1. Para obtener una lista completa de las mejoras, consulte el archivo README de BlobFuse2. Este es un resumen de las mejoras de BlobFuse2 de BlobFuse v1:
- Almacenamiento en caché mejorado
- Más compatibilidad con la administración a través de nuevos comandos de la CLI de Azure
- Más compatibilidad con el registro
- La adición de streaming de escritura para archivos grandes (anteriormente, solo se admitía el streaming de lectura)
- Nuevo Health Monitor de BlobFuse2 para ayudarle a obtener información sobre las actividades de montaje y el uso de recursos
- Opciones de compatibilidad y actualización para usuarios existentes de BlobFuse v1
- Comprobación de versiones y solicitud de actualización
- Compatibilidad con el cifrado de archivos de configuración
Consulte la lista de mejoras de rendimiento de BlobFuse2 de BlobFuse v1.
Las mejoras proporcionadas por BlobFuse2 son razones atractivas para actualizar y migrar a BlobFuse2. Si no está listo para migrar, puede usar BlobFuse2 para montar un contenedor de blobs mediante las mismas opciones de configuración y los parámetros de la CLI de Azure que usó con BlobFuse v1.
La Guía de migración de BlobFuse2 proporciona todos los detalles necesarios para la compatibilidad y la migración de las cargas de trabajo existentes.
BlobFuse2 es compatible con Microsoft si se usa dentro de los límites especificados. Si se produce un problema, notifíquelo en GitHub.
BlobFuse2 no garantiza el cumplimiento al 100 % con POSIX ya que, simplemente, convierte las solicitudes en API de REST de Blob. Por ejemplo, las operaciones de cambio de nombre son atómicas en POSIX, pero no en BlobFuse2.
Consulte la lista completa de diferencias entre un sistema de archivos nativo y BlobFuse2.
De muchas maneras, el almacenamiento montado en BlobFuse2 se puede usar igual que el sistema de archivos nativo de Linux. El esquema de directorio virtual con el uso de la barra oblicua (/) como delimitador es el mismo. Las operaciones básicas del sistema de archivos como mkdir, opendir, readdir, rmdir, open, read, create, write, close, unlink, truncate, stat y rename funcionan igual que en el sistema de archivos de Linux.
BlobFuse2 se diferencia del sistema de archivos de Linux en los siguientes aspectos clave:
Recuento de readdir de vínculos físicos:
Por motivos de rendimiento, BlobFuse2 no notifica correctamente los vínculos físicos dentro de un directorio. El número de vínculos físicos para directorios vacíos se devuelve como 2. El número de directorios no vacíos siempre se devuelve como 3, independientemente del número real de vínculos físicos.
Cambio de nombre no atómico:
Azure Blob Storage no admite operaciones de cambio de nombre atómico. Los nombres de archivo único son en realidad dos operaciones: una copia, seguida de una eliminación del original. El directorio cambia de nombre de forma recursiva, enumera todos los archivos del directorio y cambia el nombre de cada archivo.
Archivos especiales:
BlobFuse2 solo admite directorios, archivos normales y vínculos simbólicos. No se admiten archivos especiales, como archivos de dispositivo, canalizaciones y sockets.
mkfifo:
La creación de Fifo no es compatible con BlobFuse2. Si se intenta realizar esta acción, se produce un error de "función no implementada".
chown y chmod:
Las cuentas de almacenamiento de Data Lake Storage admiten permisos y ACL de objetos, mientras que los blobs en bloques de espacio de nombres plano (FNS) no lo hacen. Como resultado, BlobFuse2 no admite las operaciones
chownychmodpara los contenedores de blobs en bloques montados. Las operaciones se admiten para Data Lake Storage.Archivos o canalizaciones de dispositivo:
BlobFuse2 no admite la creación de canalizaciones o archivos de dispositivo.
Atributos extendidos (x-attrs):
BlobFuse2 no admite operaciones de atributos extendidos (
x-attrs).Streaming de escritura:
El streaming simultáneo de operaciones de lectura y escritura en datos de archivos grandes podría producir resultados imprevisibles. No se admite la escritura simultánea en el mismo blob desde subprocesos diferentes.
El almacenamiento en caché de archivos desempeña un papel importante en la integridad de los datos leídos y escritos en un montaje del sistema de archivos de Blob Storage. Se recomienda el modo de streaming para su uso con archivos grandes, que admite el streaming para las operaciones de lectura y escritura. BlobFuse2 almacena en caché bloques de archivos de streaming en memoria. Para los archivos más pequeños que no constan de bloques, todo el archivo se almacena en memoria. La caché de archivos es el segundo modo. Se recomienda almacenar en caché de archivos para cargas de trabajo que no contengan archivos grandes, como cuando los archivos se almacenan en el disco en su totalidad.
BlobFuse2 admite operaciones de lectura y de escritura. No se garantiza la sincronización continua de los datos escritos en el almacenamiento mediante otras API u otros montajes de BlobFuse2. Para conservar la integridad de los datos, se recomienda que varios orígenes no modifiquen el mismo blob, especialmente al mismo tiempo. Si una o varias aplicaciones intentan escribir en el mismo archivo simultáneamente, los resultados pueden ser inesperados. Según el tiempo de varias operaciones de escritura y la actualización de la memoria caché para cada una, el resultado podría ser que el último escritor gana y se pierden las escrituras anteriores, o generalmente que el archivo actualizado no se encuentre en el estado deseado.
Cuando un archivo es el sujeto de una operación de escritura, los datos se conservan primero en la memoria caché en un disco local. Los datos se escriben en Blob Storage solo después de cerrar el identificador de archivo. Si hay un problema al intentar conservar los datos en Blob Storage, aparecerá un mensaje de error.
Para el streaming durante las operaciones de lectura y escritura, los bloques de datos se almacenan en caché en la memoria a medida que se leen o actualizan. Las actualizaciones se vacían en Azure Storage cuando se cierra un archivo o cuando el búfer se llena de bloques desfasados.
Se admite la lectura del mismo blob desde varios subprocesos simultáneos. Sin embargo, las operaciones de escritura simultáneas pueden dar lugar a resultados inesperados de datos de archivos, incluida la pérdida de datos. Se admite la realización de operaciones de lectura simultáneas y una única operación de escritura, pero es posible que los datos que se leen de algunos subprocesos no sean actuales.
Cuando un contenedor se monta con las opciones predeterminadas, todos los archivos obtendrán 770 permisos y solo serán accesibles para el usuario que realiza el montaje. Para permitir que cualquier usuario acceda al montaje de BlobFuse2, monte BlobFuse2 con la opción --allow-other. También puede configurar esta opción en el archivo de configuración de YAML.
Como se indicó anteriormente, las operaciones chown y chmod se admiten para Data Lake Storage, pero no para blobs en bloques de espacio de nombres sin formato (FNS). La ejecución de una operación chmod en un contenedor de blobs en bloques de FNS montado devolverá un mensaje de éxito, pero la operación no se realizará correctamente.
En esta tabla se muestra cómo se admite esta característica en la cuenta y el efecto en la compatibilidad al habilitar determinadas funcionalidades.
| Tipo de cuenta de almacenamiento | Blob Storage (compatibilidad predeterminada) | Data Lake Storage 1 | Network File System (NFS) 3.0 1 | Protocolo de transferencia de archivos SSH (SFTP) 1 |
|---|---|---|---|---|
| De uso general estándar, v2 |  |
|
|
|
| Blobs en bloques Premium | |
|
|
|
1 Tanto Data Lake Storage como el protocolo Network File System (NFS) 3.0 y el protocolo Secure File Transfer (SFTP) necesitan una cuenta de almacenamiento con un espacio de nombres jerárquico habilitado.