Solución de problemas de configuración de NAS y destinos de almacenamiento NFS
En este artículo se proporcionan soluciones para algunos errores de configuración comunes y otros problemas que podrían evitar que Azure HPC Cache agregara un sistema de almacenamiento NFS como destino de almacenamiento.
En este artículo se incluyen detalles sobre cómo comprobar los puertos y cómo habilitar el acceso necesario a un sistema NAS. También se incluye información detallada sobre problemas menos habituales que podrían provocar errores a la hora de crear un destino de almacenamiento NFS.
Sugerencia
Antes de usar esta guía, lea Requisitos previos de los destinos de almacenamiento NFS.
Si la solución al problema no está incluida aquí, abra una incidencia de soporte técnico para que el servicio de soporte técnico de Microsoft pueda trabajar con usted a fin de investigar y solucionar el problema.
Proporción de suficientes subprocesos de conexión
Los sistemas de HPC Cache grandes realizan varias solicitudes de conexión a un destino de almacenamiento. Por ejemplo, si el destino de almacenamiento usa el módulo nfs-kernel-server de Ubuntu Linux, el número predeterminado de subprocesos de demonio NFS puede llegar a ocho como mínimo. Aumente el número de subprocesos a 128 o 256, que son números más razonables para admitir una instancia de HPC Cache mediana o grande.
Puede comprobar o establecer el número de subprocesos en Ubuntu mediante el valor RPCNFSDCOUNT en /etc/init.d/nfs-kernel-server.
Comprobación de configuración de puertos
Azure HPC Cache necesita acceso de lectura y escritura a varios puertos UDP/TCP en el sistema de almacenamiento de NAS de back-end. Asegúrese de que se puede acceder a estos puertos en el sistema NAS y también de que se permite el tráfico a estos puertos a través de los firewalls entre el sistema de almacenamiento y la subred de caché. Es posible que deba trabajar con los administradores de firewall y red para que el centro de datos compruebe esta configuración.
Los puertos son diferentes para los sistemas de almacenamiento de los distintos proveedores, así que compruebe los requisitos del sistema al configurar un destino de almacenamiento.
En general, la caché necesita acceso a estos puertos:
| Protocolo | Puerto | Servicio |
|---|---|---|
| TCP/UDP | 111 | rpcbind |
| TCP/UDP | 2049 | NFS |
| TCP/UDP | 4045 | nlockmgr |
| TCP/UDP | 4046 | mountd |
| TCP/UDP | 4047 | status |
Para conocer los puertos concretos necesarios para el sistema, use el siguiente comando rpcinfo. Este comando indica los puertos y presenta los resultados pertinentes en una tabla. (Use la dirección IP del sistema en lugar del término <storage_IP>).
Puede emitir este comando desde cualquier cliente Linux que tenga instalada infraestructura de NFS. Si usa un cliente dentro de la subred del clúster, también puede ayudar a verificar la conectividad entre la subred y el sistema de almacenamiento.
rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t
Asegúrese de que todos los puertos devueltos por la consulta rpcinfo permitan tráfico sin restricciones desde la subred de Azure HPC Cache.
Compruebe estos valores en el propio NAS y en cualquier firewall entre el sistema de almacenamiento y la subred de caché.
Comprobación de la configuración de root squash
La configuración de root squash puede interrumpir el acceso a los archivos si no están configurados correctamente. Debe comprobar que la configuración de cada exportación de almacenamiento y de las directivas de acceso de cliente de HPC Cache coincidentes sea la adecuada.
Root squash impide que las solicitudes de un superusuario local raíz en el cliente se envíen a un sistema de almacenamiento back-end como raíz. Reasigna las solicitudes de raíz a un identificador de usuario (UID) sin privilegios, como "nobody".
Sugerencia
Las versiones anteriores de Azure HPC Cache necesitaban sistemas de almacenamiento NAS para permitir el acceso raíz desde HPC Cache. Ahora, no es necesario permitir el acceso raíz en una exportación de destino de almacenamiento a menos que desee que los clientes HPC Cache tengan acceso raíz a la exportación.
Root squash se puede configurar en un sistema de HPC Cache en estos lugares:
En Azure HPC Cache: use directivas de acceso de cliente para configurar root squash para los clientes que coincidan con las reglas de filtro específicas. Las directivas de acceso de cliente forman parte de cada ruta de acceso del espacio de nombres de destino de almacenamiento NFS.
La directiva de acceso de cliente predeterminada no es squash root.
En la exportación de almacenamiento: puede configurar el sistema de almacenamiento para reasignar las solicitudes entrantes de raíz a un identificador de usuario (UID) sin privilegios.
Si el sistema de almacenamiento exporta squash root, debe actualizar la regla de acceso de cliente HPC Cache para ese destino de almacenamiento para que incluya squash root. En caso contrario, puede tener problemas de acceso al intentar leer o escribir en el sistema de almacenamiento back-end mediante HPC Cache.
En esta tabla se muestra el comportamiento de diferentes escenarios de squash root cuando se envía una solicitud de cliente como UID 0 (raíz). No se recomienda el escenario marcado con * porque puede provocar problemas de acceso.
| Configuración | UID enviados desde el cliente | UID enviado desde HPC Cache | UID eficaz en el almacenamiento back-end |
|---|---|---|---|
| sin squash root | 0 (raíz) | 0 (raíz) | 0 (raíz) |
| squash root solo en HPC Cache | 0 (raíz) | 65534 (nadie) | 65534 (nadie) |
| *squash root solo en el almacenamiento NAS | 0 (raíz) | 0 (raíz) | 65534 (nadie) |
| squash root en HPC Cache y NAS | 0 (raíz) | 65534 (nadie) | 65534 (nadie) |
(UID 65534 es un ejemplo; al activar squash root en una directiva de acceso de cliente, puede personalizar el valor de UID).
Comprobación del acceso en las rutas de acceso de directorio
En el caso de los sistemas NAS que exportan directorios jerárquicos, compruebe que Azure HPC Cache tiene el acceso adecuado para cada nivel de exportación en la ruta de acceso a los archivos que está usando.
Por ejemplo, un sistema podría mostrar tres exportaciones como estas:
/ifs/ifs/accounting/ifs/accounting/payroll
La exportación /ifs/accounting/payroll es un elemento secundario de /ifs/accounting, y /ifs/accounting, a su vez, es un elemento secundario de /ifs.
Si agrega la exportación de payroll como destino de almacenamiento de HPC Cache, la caché monta /ifs/ en realidad y accede al directorio payroll directamente desde allí. Por lo tanto, Azure HPC Cache el acceso necesario a /ifs para acceder a la exportación /ifs/accounting/payroll.
Este requisito está relacionado con la forma en que la caché indexa archivos y evita colisiones de archivos mediante identificadores de archivo que proporciona el sistema de almacenamiento.
Un sistema NAS con exportaciones jerárquicas puede proporcionar diferentes identificadores de archivo para el mismo archivo si este se recupera de distintas exportaciones. Por ejemplo, un cliente podría montar /ifs/accounting y acceder al archivo payroll/2011.txt. Otro cliente monta /ifs/accounting/payroll y accede al archivo 2011.txt. En función de cómo asigne identificadores de archivo el sistema de almacenamiento, es posible que estos dos clientes reciban el mismo archivo con diferentes identificadores de archivo (uno para <mount2>/payroll/2011.txt y otro para <mount3>/2011.txt).
El sistema de almacenamiento de back-end mantiene los alias internos de los identificadores de archivo, pero Azure HPC Cache no puede indicar qué identificadores de archivo de su índice hacen referencia al mismo elemento. Por lo tanto, es posible que la caché tenga diferentes escrituras almacenadas en caché del mismo archivo y aplique los cambios de forma incorrecta porque no sabe que se trata del mismo archivo.
Para evitar esta posible colisión de archivos entre archivos de varias exportaciones, Azure HPC Cache monta automáticamente la exportación más superficial disponible en la ruta de acceso (/ifs en el ejemplo) y usa el identificador de archivo proporcionado por esa exportación. Si varias exportaciones usan la misma ruta de acceso base, Azure HPC Cache necesita acceso a esa ruta.
Ajuste de restricciones de tamaño de paquete de VPN
Si tiene una VPN entre la caché y el dispositivo NAS, la VPN podría bloquear los paquetes de Ethernet de 1500 bytes de tamaño completo. Podría tener este problema si no se completan los intercambios grandes entre NAS y la instancia de Azure HPC Cache, pero las actualizaciones más pequeñas funcionan según lo previsto.
No hay una manera sencilla de saber si el sistema tiene este problema o no, a menos que conozca los detalles de configuración de la VPN. Estos son algunos métodos que pueden ayudarle a detectar este problema.
Use rastreadores de paquetes en ambos lados de la VPN para detectar qué paquetes se transfieren correctamente.
Si la VPN permite comandos ping, puede probar el envío de un paquete de tamaño completo.
Ejecute un comando ping a través de la VPN a NAS con estas opciones. (Use la dirección IP del sistema de almacenamiento en lugar del valor <storage_IP>).
ping -M do -s 1472 -c 1 <storage_IP>Estas son las opciones del comando:
-M do: No fragmentar-c 1: Enviar solo un paquete-s 1472: Establecer el tamaño de la carga en 1472 bytes. Esta es la carga de tamaño máxima de un paquete de 1500 bytes después de tener en cuenta la sobrecarga de Ethernet.
Una respuesta exitosa se ve así:
PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data. 1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 msSi se produce un error de ping con 1472 bytes, es probable que se trate de un problema de tamaño del paquete.
Para corregir el problema, es posible que tenga que configurar el bloqueo de MSS en la VPN para que el sistema remoto detecte correctamente el tamaño máximo del marco. Lea la documentación de parámetros de IPsec/IKE de VPN Gateway para obtener más información.
En algunos casos, puede resultar útil cambiar la configuración de MTU para Azure HPC Cache a 1400. Sin embargo, si restringe la MTU en la memoria caché, también debe restringir la configuración de MTU para los clientes y sistemas de almacenamiento de back-end que interactúan con la memoria caché. Para obtener más información, lea Configuración de valores adicionales de Azure HPC Cache.
Comprobación del estilo de seguridad de ACL
Algunos sistemas NAS usan un estilo de seguridad híbrido que combina listas de control de acceso (ACL) con seguridad POSIX o UNIX tradicional.
Si el sistema notifica su estilo de seguridad como UNIX o POSIX sin incluir el acrónimo "ACL", este problema no le afecta.
En el caso de los sistemas que usan ACL, Azure HPC Cache debe realizar un seguimiento de los valores adicionales específicos del usuario para controlar el acceso a los archivos. Esto se hace mediante la habilitación de una caché de acceso. No hay un control orientado al usuario para activar la caché de acceso, pero puede abrir una incidencia de soporte técnico para solicitar que se habilite para los destinos de almacenamiento afectados en el sistema de caché.
Pasos siguientes
Si tiene un problema que no se haya tratado en este artículo, póngase en contacto con soporte técnico para obtener ayuda de expertos.