Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Puede usar contenedores de blobs montados en NFS con Azure HPC Cache. Obtenga más información sobre la compatibilidad con el protocolo NFS 3.0 en Azure Blob Storage en el sitio de documentación de Blob Storage.
Azure HPC Cache utiliza el almacenamiento de blobs habilitado para NFS dentro de su tipo de destino de almacenamiento ADLS-NFS. Estos destinos de almacenamiento son similares a los destinos de almacenamiento NFS normales, pero también tienen cierta superposición con destinos de blobs de Azure normales.
En este artículo se explican las estrategias y limitaciones que debe comprender al usar los destinos de almacenamiento de ADLS-NFS.
También debe leer la documentación del blob NFS, especialmente estas secciones que describen escenarios compatibles e incompatibles, y ofrecen sugerencias de solución de problemas.
- Introducción a las características
- Consideraciones de rendimiento
- Problemas y limitaciones conocidos
- Guía paso a paso y de solución de problemas
Descripción de los requisitos de coherencia
HPC Cache requiere una coherencia sólida para los destinos de almacenamiento de ADLS-NFS. De forma predeterminada, el almacenamiento de blobs habilitado para NFS no actualiza estrictamente los metadatos de archivo, lo que impide que HPC Cache compare con precisión las versiones de archivo.
Para solucionar esta diferencia, Azure HPC Cache deshabilita automáticamente el almacenamiento en caché de atributos NFS en cualquier contenedor de blobs habilitado para NFS que se use como destino de almacenamiento.
Esta configuración persiste durante la vigencia del contenedor, incluso si la quita de la memoria caché.
Carga previa de datos con el protocolo NFS
En un contenedor de blobs habilitado para NFS, el mismo protocolo que se usó cuando se creó solo puede editar un archivo. Es decir, si usa la API REST de Azure para rellenar un contenedor, no puede usar NFS para actualizar esos archivos. Dado que Azure HPC Cache solo usa NFS, no puede editar los archivos creados con la API REST de Azure. (Más información sobre los problemas conocidos con las API de Blob Storage)
No es un problema para la memoria caché si el contenedor está vacío o si los archivos se crearon mediante NFS.
Si los archivos del contenedor se crearon con la API REST de Azure Blob en lugar de NFS, Azure HPC Cache se restringe a estas acciones en los archivos originales:
- Enumere el archivo en un directorio.
- Lea el archivo (y manténgalo en la memoria caché para las lecturas posteriores).
- Eliminar el archivo.
- Vacía el archivo (truncarlo en 0).
- Guarde una copia del archivo. La copia se marca como un archivo creado por NFS y se puede editar mediante NFS.
Azure HPC Cache no puede editar el contenido de un archivo que se creó mediante REST. Esto significa que la memoria caché no puede guardar un archivo cambiado de un cliente de vuelta al destino de almacenamiento.
Es importante comprender esta limitación, ya que puede causar problemas de integridad de datos si usa modelos de uso de almacenamiento en caché de lectura y escritura en archivos que no se crearon con NFS.
Sugerencia
Obtenga más información sobre el almacenamiento en caché de lectura y escritura en Descripción de los modelos de uso de caché.
Escenarios de caché de escritura
Estos modelos de uso de caché incluyen caché de escritura:
- Más del 15% de operaciones de escritura
- Más del 15% en operaciones de escritura, comprobando el servidor de respaldo por cambios cada 30 segundos
- Más del 15% de operaciones de escritura, comprobando el servidor de respaldo para cambios cada 60 segundos
- Mayor que 15% escrituras, reescritura en el servidor cada 30 segundos
Los modelos de uso de caché de escritura deben usarse solo en archivos creados mediante NFS.
Si intenta usar el almacenamiento en caché de escritura en ficheros creados mediante REST, se podrían perder los cambios en el fichero. Esto se debe a que la memoria caché no intenta guardar las modificaciones de archivos en el contenedor de almacenamiento inmediatamente.
A continuación se muestra cómo intentar almacenar en caché las escrituras en archivos creados por REST pone en riesgo los datos:
La memoria caché acepta modificaciones de los clientes y devuelve un mensaje de confirmación en cada cambio.
La memoria caché mantiene el archivo modificado en su almacenamiento y espera cambios adicionales.
Una vez transcurrido algún tiempo, la memoria caché intenta guardar el archivo cambiado en el contenedor back-end. En este momento, recibirá un mensaje de error porque intenta escribir en un archivo creado por REST con NFS.
Es demasiado tarde para indicar al equipo cliente que no se aceptaron sus cambios y que la memoria caché no tiene forma de actualizar el archivo original. Por lo tanto, se perderán los cambios de los clientes.
Escenarios de lectura en el almacenamiento en caché
Los escenarios de almacenamiento en caché de lectura son adecuados para los archivos creados con NFS o la API REST de Azure Blob.
Estos modelos de uso usan solo el almacenamiento en caché de lectura:
- Lectura intensiva, escrituras poco frecuentes
- Los clientes escriben en el destino NFS, omitiendo la memoria caché.
- Leer pesado, comprobar el servidor de respaldo cada 3 horas
Puede usar estos modelos de uso con archivos creados por la API REST o por NFS. Las escrituras NFS enviadas desde un cliente al contenedor back-end seguirán fallando, pero fallarán inmediatamente y devolverán inmediatamente un mensaje de error al cliente.
Un flujo de trabajo de almacenamiento en caché de lectura puede seguir implicando cambios en los archivos, siempre y cuando no se almacenen en caché. Por ejemplo, los clientes pueden acceder a los archivos del contenedor, pero escribir sus cambios como un nuevo archivo, o bien podrían guardar archivos modificados en una ubicación diferente.
Limitaciones de Recognize Network Lock Manager (NLM)
Los contenedores de blobs habilitados para NFS no admiten Network Lock Manager (NLM), que es un protocolo NFS usado habitualmente para proteger los archivos frente a conflictos.
Si el flujo de trabajo NFS se escribió originalmente para sistemas de almacenamiento de hardware, las aplicaciones cliente podrían incluir solicitudes NLM. Para solucionar esta limitación al mover el proceso al almacenamiento de blobs habilitado para NFS, asegúrese de que los clientes deshabiliten NLM cuando monten la memoria caché.
Para deshabilitar NLM, use la opción -o nolock en el comando mount de los clientes. Esta opción impide que los clientes soliciten bloqueos NLM y reciban errores en respuesta. La nolock opción se implementa de forma diferente en diferentes sistemas operativos; compruebe la documentación del sistema operativo cliente (man 5 nfs) para obtener más información.
Simplifique la escritura en contenedores habilitados para NFS con HPC Cache.
Azure HPC Cache puede ayudar a mejorar el rendimiento de una carga de trabajo que incluye escribir cambios en un destino de almacenamiento de ADLS-NFS.
Note
Debe usar NFS para rellenar el contenedor de almacenamiento de ADLS-NFS si desea modificar sus archivos a través de Azure HPC Cache.
Una de las limitaciones descritas en el artículo Consideraciones de rendimiento sobre blobs habilitados para NFS es que el almacenamiento ADLS-NFS no es muy eficaz al sobrescribir los archivos ya existentes. Si usa Azure HPC Cache con almacenamiento de blobs montado en NFS, la caché controla las reescrituras intermitentes a medida que los clientes modifican un archivo activo. La latencia de escritura de un archivo en el contenedor de fondo es invisible para los clientes.
Tenga en cuenta las limitaciones descritas anteriormente en Datos de carga previa con el protocolo NFS.