À propos des protocoles de système de fichiers compatibles

Filestore est compatible avec les protocoles de système de fichiers suivants:

NFSv3

  • Disponible dans tous les services tiers.
  • Il est compatible avec la communication bidirectionnelle entre le client et le serveur.
    • Utilise plusieurs ports.
    • Crée un canal de confiance pour le trafic et les opérations réseau.
  • Offre une configuration rapide pour l'accès POSIX standard.

NFSv4.1

  • Disponible dans les niveaux de service zonal, régional et d'entreprise.
  • Compatible avec les configurations de pare-feu modernes et compatible avec les exigences de conformité en matière de sécurité réseau.
    • La communication est toujours initiée par le client et toujours gérée via un seul port de serveur, 2049.
    • Compatible avec l'authentification du client et du serveur.

Chaque protocole est le plus adapté à des cas d'utilisation spécifiques. Le tableau suivant compare les spécifications de chaque protocole:

Spécification NFSv3 NFSv4.1
Niveaux de service compatibles Tous les services tiers Zonal, régional et entreprise
Communication bidirectionnelle Oui Non. La communication est toujours initiée par le client à l'aide du port serveur 2049.
Authentification Non Oui. Nécessite l'authentification RPCSEC_GSS, implémentée à l'aide de LDAP et de Kerberos, tous deux disponibles dans le service géré pour Microsoft Active Directory.
Compatible avec les listes de contrôle d'accès (LCA) de fichiers ou de répertoires Non Oui. Prend en charge jusqu'à 50 entrées de contrôle des accès (ACE) par liste.
Assistance Groupes Jusqu'à 16 groupes Prise en charge illimitée des groupes lorsque vous êtes connecté à Microsoft AD géré.
Paramètre de sécurité sys : crée un canal de confiance. sys : crée un canal de confiance. krb5. Authentifie le client et le serveur. krb5i. Fournit des vérifications d'authentification et d'intégrité des messages.krb5p. Fournit une authentification, des contrôles d'intégrité des messages et un chiffrement des données en transit.
Latence des opérations Aucun La latence des opérations augmente avec le niveau de sécurité sélectionné.
Type de récupération Sans état Avec état
Type de verrouillage de fichier Network Lock Manager (NLM) La serrure est contrôlée par le client. Verrouillage consultatif basé sur un bail Le verrouillage est contrôlé par le serveur.
Prise en charge des échecs client Non Oui
Compatible avec l'accès aux services privés Non Non

Avantages de NFSv3

Le protocole NFSv3 offre une configuration rapide pour l'accès POSIX standard.

Limites de NFSv3

Voici une liste des limites de NFSv3:

  • L'accès aux services privés n'est pas pris en charge.
  • L'authentification et le chiffrement du client et du serveur sont insuffisants.
  • La gestion des échecs côté client est insuffisante.

Avantages de NFSv4.1

Le protocole NFSv4.1 utilise la méthode Authentification RPCSEC_GSS, qui est implémentée à l'aide de LDAP et de Kerberos pour fournir une authentification client et serveur, des vérifications de l'intégrité des messages et un chiffrement des données en transit.

Ces fonctionnalités de sécurité rendent le protocole NFSv4.1 compatible avec les exigences de conformité modernes en matière de sécurité réseau:

  • Utilise un seul port de serveur, 2049, pour toutes les communications, ce qui simplifie la configuration des pare-feu.

  • Compatible avec les listes de contrôle des accès (LCA) NFSv4.1.

    • Chaque LCA accepte jusqu'à 50 entrées de contrôle des accès (ACE) par fichier ou répertoire. Cela inclut les enregistrements d'héritage.

  • Prise en charge illimitée des groupes lors de l'intégration au service Microsoft AD géré.

  • Améliore la gestion des échecs client grâce au verrouillage consultatif basé sur les baux.

    • Le client doit vérifier la connexion continue avec le serveur. Si le client ne renouvelle pas le bail, le serveur libère le verrouillage et le fichier devient disponible pour tout autre client demandant l'accès via un bail de verrouillage. Dans NFSv3, si un client est supprimé alors qu'il est verrouillé, un autre client (tel qu'un nouveau nœud GKE) ne peut pas accéder au fichier.

  • Compatible avec la reprise après sinistre avec état.

    • Contrairement à NFSv3, NFSv4.1 est un protocole avec état basé sur TCP et sur les connexions. L'état du client et du serveur dans la session précédente peut être repris après la récupération.

Service géré pour Microsoft Active Directory

Bien que le service géré pour Microsoft Active Directory (service Microsoft AD géré) ne soit pas une exigence stricte, il s'agit de la seule solution gérée par Google Cloud compatible à la fois avec LDAP et Kerberos, deux exigences du protocole NFSv4.1 de Filestore.

Les administrateurs sont vivement encouragés à utiliser le service géré pour Microsoft Active Directory (service Microsoft AD géré) pour implémenter et gérer LDAP et Kerberos.

En tant que solution gérée par Google Cloud, Microsoft AD géré offre les avantages suivants:

  • Propose un déploiement multirégional, avec une compatibilité avec jusqu'à cinq régions sur le même domaine.

    • Réduit la latence en veillant à ce que les utilisateurs et leurs serveurs de connexion respectifs soient plus proches.

  • Compatible avec les normes POSIX RFC 2307 et RFC 2307bis, qui sont des exigences pour l'implémentation de NFSv4.1.

  • Automatise la mise en correspondance des utilisateurs avec les identifiants uniques (UID) et les identifiants uniques globaux (GUID).

  • Vous pouvez créer des utilisateurs et des groupes dans Microsoft AD géré ou les y migrer.

  • Les administrateurs peuvent créer une approbation de domaine avec le domaine Active Directory (AD) et LDAP actuel sur site, autogéré. Avec cette option, la migration n'est pas nécessaire.

  • Fournit un contrat de niveau de service.

Contrôle des accès et comportements supplémentaires

  • Les ACE NFSv4.1 Filestore sont gérés sous Linux à l'aide des commandes suivantes:

    • nfs4_setfacl: créez ou modifiez des ACE sur un fichier ou un répertoire.
    • nfs4_getfacl: liste les ACE sur un fichier ou un répertoire.

  • Chaque ACL accepte jusqu'à 50 ACE. Six entrées sont réservées aux ACE générées automatiquement créées par les opérations chmod client. Ces ACE peuvent être modifiés après leur création.

    Les enregistrements ACE générés automatiquement représentant les bits de mode sont listés dans l'ordre de priorité suivant:

    • DENY and ALLOW ACEs pour OWNER@
    • DENY and ALLOW ACEs pour GROUP@

    • DENY and ALLOW ACEs pour EVERYONE@

      Si de tels ACE sont déjà présents, ils seront réutilisés et modifiés en fonction des nouveaux bits de mode appliqués.

  • Filestore NFSv4.1 ne permet de vérifier l'accès requis que dans le mode POSIX RWX (lecture, écriture et exécution). Il ne fait pas la distinction entre les opérations write append et write qui modifient le contenu ou la spécification SETATTR. L'utilitaire nfs4_setfacl accepte également RWX comme raccourci et active automatiquement tous les indicateurs appropriés.

  • nfs4_getfacl ne traduit pas le principal par lui-même. L'utilitaire nfs4_getfacl affiche les valeurs numériques UID et GUID pour les principaux. Par conséquent, les principaux spéciaux OWNER@, GROUP@ et EVERYONE@ s'affichent.

  • Que vous utilisiez Managed Microsoft AD ou non, lorsque vous travaillez avec AUTH-SYS et l'utilitaire nfs4_setfacl, les administrateurs doivent spécifier les valeurs numériques UID et GUID, et non les noms d'utilisateur. Cet utilitaire ne peut pas traduire les noms en ces valeurs. Si l'ID n'est pas fourni correctement, l'instance Filestore utilise par défaut l'ID nobody.

  • Lorsque vous spécifiez des autorisations d'écriture pour un fichier, ou même des fichiers affectés par un ACE hérité, l'ACE doit inclure à la fois les indicateurs w (écriture) et a (ajout).

  • Lorsque vous vérifiez les autorisations pour SETATTR, la réponse renvoyée est semblable à POSIX comme suit:

    • Le super-utilisateur ou l'utilisateur ROOT peut tout faire.
    • Seul le propriétaire du fichier peut définir les bits de mode, les LCA et les codes temporels sur une heure et un groupe spécifiques, comme l'un des GUID auxquels il appartient.
    • Les utilisateurs autres que le propriétaire du fichier peuvent consulter les attributs, y compris la LCA.

  • Un seul ACE englobe à la fois les autorisations effectives et les autorisations par héritage uniquement. Contrairement aux autres implémentations NFSv4.1, Filestore ne réplique pas automatiquement les ACE hérités dans le but de distinguer les ACE efficaces et les ACE hérités uniquement.

Limites de NFSv4.1

Voici la liste des limites de NFSv4.1:

  • Le protocole NFSv4.1 ne peut pas être combiné aux fonctionnalités suivantes:

  • Le protocole NFSv4.1 n'est pas compatible avec AUDIT and ALARM ACEs. Filestore n'est pas compatible avec l'audit des accès aux données.

  • Une fois configurés, ne supprimez pas Microsoft AD géré et l'appairage réseau. Le partage Filestore devient alors inaccessible lorsqu'il est installé sur un client, ce qui rend vos données inaccessibles. Google Cloud n'est pas responsable des pannes causées par des actions d'administrateur ou d'utilisateur.

  • Lorsque vous utilisez l'un des paramètres de sécurité Kerberos authentifiés, les utilisateurs peuvent s'attendre à une latence d'opération. Les taux de latence varient en fonction du niveau de service et du paramètre de sécurité spécifié. La latence augmente à mesure que le niveau de sécurité augmente.

  • L'audit des accès aux données n'est pas accepté.

  • La solution NFSv4.1 Filestore nécessite l'authentification RPCSEC_GSS. Cette méthode d'authentification n'est implémentée qu'avec LDAP et Kerberos, tous deux disponibles dans Microsoft AD géré. Les autres mécanismes d'authentification ne sont pas acceptés.

  • L'accès aux services privés n'est pas pris en charge.

  • Si vous souhaitez qu'une instance Filestore rejoigne Microsoft AD géré via un VPC partagé, vous devez utiliser gcloud ou l'API Filestore. Vous ne pouvez pas joindre l'instance à Microsoft AD géré à l'aide de la console Google Cloud.

  • Le nom de domaine Microsoft AD géré ne doit pas dépasser 56 caractères.

  • Pour créer une instance d'entreprise, vous devez exécuter des opérations directement via l'API Filestore. Pour en savoir plus, consultez la section Niveaux de service.

  • Lors de la restauration d'une sauvegarde, la nouvelle instance doit utiliser le même protocole que l'instance source.

Étape suivante