Información acerca de los protocolos de sistemas de archivos compatibles

Filestore admite los siguientes protocolos de sistemas de archivos:

NFSv3

  • Disponible en todos los niveles de servicio.
  • Admite la comunicación bidireccional entre el cliente y el servidor.
    • Usa varios puertos.
    • Crea un canal de confianza para el tráfico y las operaciones de red.
  • Ofrece una configuración rápida para el acceso a POSIX estándar.

NFSv4.1

  • Disponible en las plataformas zonales, regionales y los niveles de servicio empresariales.
  • Es compatible con las configuraciones de firewall modernas y admite los requisitos de cumplimiento de seguridad de la red.
    • El cliente siempre inicia la comunicación y siempre se entrega a través de un solo puerto de servidor, 2049.
    • Admite la autenticación de clientes y servidores.

Cada protocolo es más adecuado para casos de uso específicos. En la siguiente tabla, se compara las especificaciones de cada protocolo:

Especificación NFSv3 NFSv4.1
Niveles de servicio admitidos Todos los niveles de servicio Zonal, regional y empresarial
Comunicación bidireccional Sí No. El cliente siempre inicia la comunicación con el puerto del servidor 2049.
Autenticación No Sí. Requiere autenticación RPCSEC_GSS, implementada con LDAP y Kerberos, que están disponibles en el servicio administrado para Microsoft Active Directory.
Admite Listas de control de acceso (LCA) a archivos o directorios. No Sí. Admite hasta 50 entradas de control de acceso (ACE) por lista.
Compatibilidad con Grupos Hasta 16 grupos Compatibilidad ilimitada con grupos cuando te conectas a Microsoft AD administrado.
Configuración de seguridad sys Crea un canal de confianza. sys: Crea un canal de confianza. krb5. Autentica el cliente y el servidor. krb5i. Proporciona autenticación y verificaciones de integridad de los mensajes.krb5p Proporciona autenticación, verificaciones de integridad de los mensajes y encriptación de datos en tránsito.
Latencia de las operaciones Ninguno La latencia de las operaciones aumenta con el nivel de seguridad seleccionado.
Tipo de recuperación Sin estado Con estado
Tipo de bloqueo de archivos Administrador de bloqueo de red (NLM). El cliente controla la cerradura. Bloqueo de aviso basado en el arrendamiento El servidor controla el bloqueo.
Admite fallas del cliente No Sí
Admite conexiones de servicios privados (PSC) No No

Beneficios de NFSv3

El protocolo NFSv3 ofrece una configuración rápida para el acceso POSIX estándar.

Limitaciones de NFSv3

La siguiente es una lista de las limitaciones de NFSv3:

Beneficios de NFSv4.1

El protocolo NFSv4.1 usa la autenticación RPCSEC_GSS. que se implementa usando LDAP y Kerberos para brindar a los clientes y del servidor, verificaciones de integridad de los mensajes y datos en tránsito la encriptación.

Estas capacidades de seguridad hacen que el protocolo NFSv4.1 sea compatible con las requisitos de cumplimiento de seguridad de red:

  • Usa un solo puerto de servidor, 2049, para todas las comunicaciones, lo que ayuda a simplificar parámetros de configuración de firewall.

  • Admite listas de control de acceso (LCA) a los archivos NFSv4.1.

    • Cada LCA admite hasta 50 entradas de control de acceso (ACE) por archivo o . Esto incluye los registros de herencia.

  • Compatibilidad ilimitada con grupos cuando se usa la integración administrada de Microsoft AD.

  • Admite un mejor manejo de fallas del cliente con bloqueos de asesoramiento basados en arrendamientos.

    • El cliente debe verificar la conexión continua con el servidor. Si el cliente no renueva la asignación, el servidor libera el bloqueo y el archivo Está disponible para cualquier otro cliente que solicite acceso a través de un alquiler. En NFSv3, si se borra un cliente mientras está bloqueado, otro cliente, como un nuevo nodo de GKE, no puede acceder al archivo.

  • Admite la recuperación con estado.

    • A diferencia de NFSv3, NFSv4.1 es un protocolo con estado basado en TCP y en la conexión. Se puede reanudar el estado del cliente y del servidor en la sesión anterior después de la recuperación.

Servicio administrado para Microsoft Active Directory

Si bien el Servicio administrado para Microsoft Active Directory (Microsoft AD administrado) no es un requisito estricto, es la única solución administrada por Google Cloud que admite LDAP y Kerberos, ambos requisitos para el protocolo NFSv4.1 de Filestore.

Se recomienda a los administradores que usen Servicio administrado para Microsoft Active Directory (Microsoft AD administrado) para implementar y administrar LDAP y Kerberos.

Como solución administrada por Google Cloud, Microsoft AD administrado proporciona la los siguientes beneficios:

  • Ofrece implementación multirregional, que admite hasta cinco regiones en el mismo dominio.

    • Reduce la latencia, ya que garantiza que los usuarios y sus respectivos servidores de acceso estén conectados. tienen más proximidad.

  • Admite POSIX RFC 2307 y RFC 2307bis para la implementación de NFSv4.1.

  • Automatiza el identificador único (UID) y el usuario del identificador único global (GUID) la asignación.

  • Los usuarios y grupos pueden crearse o migrarse a Microsoft AD administrado.

  • Los administradores pueden crear una confianza de dominio con el dominio de Active Directory (AD) y LDAP local y autoadministrado actual. Con esta opción, no es necesaria la migración.

  • Proporciona un ANS.

Control de acceso y comportamientos adicionales

  • Los ACE de NFSv4.1 de Filestore se administran en Linux con los siguientes comandos:

    • nfs4_setfacl: Crear o editar los ACE en un archivo o directorio.
    • nfs4_getfacl: Enumera las ACE en un archivo o directorio.

  • Cada LCA admite hasta 50 ACE. Se reservan seis entradas para las métricas ACE creados por operaciones del cliente chmod. Estos ACE pueden modificarse después de de la creación de cuentas de servicio.

    Los registros ACE generados automáticamente que representan los bits de modo se enumeran en el siguiente orden de prioridad:

    • DENY and ALLOW ACEs para el período OWNER@
    • DENY and ALLOW ACEs para el período GROUP@

    • DENY and ALLOW ACEs para EVERYONE@

      Si ya están presentes, se volverán a usar y modificar según los nuevos bits de modo aplicados.

  • Filestore NFSv4.1 admite verificar el acceso requerido solo en Modo POSIX RWX (lectura, escritura y ejecución). No diferenciará entre las operaciones write append y write que modifican el contenido o la especificación SETATTR. La utilidad nfs4_setfacl también acepta RWX como un atajo y activa automáticamente todas las marcas adecuadas.

  • La nfs4_getfacl no realiza ninguna traducción del principal por su cuenta. El La utilidad nfs4_getfacl mostrará los valores numéricos UID y GUID para el valor principales. Como resultado, se mostrarán los principales especiales de OWNER@, GROUP@ y EVERYONE@.

  • Independientemente de si se usa Microsoft AD administrado, cuando se trabaja con AUTH-SYS y la utilidad nfs4_setfacl, los administradores deben especificar el los valores numéricos UID y GUID, no los nombres de usuario. Esta compañía eléctrica no puede hacer lo siguiente: traducir nombres a estos valores. Si no se proporciona correctamente, la instancia de Filestore usará el ID nobody de forma predeterminada.

  • Al especificar los permisos de escritura para un archivo, o incluso para los archivos afectados Si tienes un ACE heredado, este debe incluir w (escritura) y a (anexo) marcas.

  • Cuando verificas los permisos de SETATTR, la respuesta que se muestra es similar a lo siguiente: POSIX de la siguiente manera:

    • El superusuario o el usuario ROOT pueden hacer cualquier cosa.
    • Solo el propietario del archivo puede establecer los bits de modo, las LCA y las marcas de tiempo en un una hora y un grupo específicos, como uno de los GUID a los que pertenece.
    • Los usuarios que no sean el propietario del archivo pueden ver los atributos, incluida la LCA.

  • Un solo ACE abarca permisos eficaces y solo heredados. Contrario a otras implementaciones de NFSv4.1, Filestore no hará automáticamente replicar ACES heredado con el propósito de distinguir entre y de solo heredar.

Limitaciones de NFSv4.1

La siguiente es una lista de limitaciones de NFSv4.1:

  • El protocolo NFSv4.1 no se puede combinar con las siguientes funciones:

  • El protocolo NFSv4.1 no admite AUDIT and ALARM ACEs. Filestore no admite la auditoría de acceso a los datos.

  • Una vez configurado, no borres Microsoft AD administrado ni el intercambio de tráfico entre redes. Si lo haces, no se podrá acceder al recurso compartido de Filestore mientras esté activado en un cliente, lo que hace que tus datos sean inaccesibles. Google Cloud no es responsable de las interrupciones causadas por acciones del administrador o del usuario.

  • Cuando se usa cualquiera de los parámetros de configuración de seguridad de Kerberos autenticados, los usuarios pueden esperar latencia en algunas operaciones. Las tasas de latencia varían según el nivel de servicio el parámetro de configuración de seguridad especificado. La latencia aumenta con cada aumento de seguridad a nivel de organización.

  • No se admite la auditoría de acceso a los datos.

  • La solución Filestore NFSv4.1 requiere autenticación RPCSEC_GSS. Este método de autenticación solo se implementa mediante LDAP y Kerberos, que están disponibles en Microsoft AD administrado. No se admiten otros mecanismos de autenticación.

  • Carece de compatibilidad con la conexión a servicios privados (PSC).

  • Si quieres que una instancia de Filestore se una a Microsoft AD administrado a través de una VPC compartida, debes usar gcloud o Filestore API de gcloud. No puedes unir la instancia a Microsoft AD administrado con el Consola de Google Cloud

  • El nombre de dominio de Microsoft AD administrado no debe superar los 56 caracteres.

  • Para crear una instancia empresarial, debes ejecutar operaciones directamente a través de la API de Filestore. Para obtener más información, consulta Niveles de servicio.

  • Cuando restableces una copia de seguridad, la instancia nueva debe usar el mismo protocolo que la instancia de origen.

¿Qué sigue?