Informazioni sui protocolli di file system supportati

Filestore supporta i seguenti protocolli di file system:

NFSv3

  • Disponibile in tutti i livelli di servizio.
  • Supporta la comunicazione bidirezionale tra il client e il server.
    • Utilizza più porte.
    • Crea un canale attendibile per il traffico e le operazioni di rete.
  • Offre la configurazione rapida per l'accesso POSIX standard.

NFSv4.1

  • Disponibile a livello di zona, regione ai livelli di servizi aziendali.
  • Compatibile con le configurazioni di firewall moderne e supporta i requisiti di conformità per la sicurezza di rete.
    • La comunicazione è sempre avviata dal cliente e realizzata sempre tramite su una singola porta del server, 2049.
    • Supporta l'autenticazione di client e server.

Ogni protocollo è più adatto a casi d'uso specifici. La tabella seguente mette a confronto le specifiche di ciascun protocollo:

Specifica NFSv3 NFSv4.1
Livelli di servizio supportati Tutti i livelli di servizio A livello di zona, di regione e di livello enterprise
Comunicazione bidirezionale No. La comunicazione viene sempre avviata dal client utilizzando la porta del server 2049.
Autenticazione No Sì. Richiede l'autenticazione RPCSEC_GSS, implementata utilizzando LDAP e Kerberos, entrambi disponibili in Managed Service for Microsoft Active Directory.
Supporta gli elenchi di controllo dell'accesso (ACL) di file o directory No Sì. Supporta fino a 50 voci di controllo dell'accesso (ACE) per elenco.
Assistenza di Gruppi Fino a 16 gruppi Supporto di gruppi illimitati quando è collegata a Microsoft AD gestito.
Impostazione di sicurezza sys. Crea un canale attendibile. sys. Crea un canale attendibile. krb5. Autentica il client e il server. krb5i. Fornisce controlli di autenticazione e integrità del messaggio.krb5p. Fornisce autenticazione, controlli di integrità dei messaggi e crittografia dei dati in transito.
Latenza delle operazioni Nessuno La latenza delle operazioni aumenta con il livello di sicurezza selezionato.
Tipo di recupero Stateless Stateful
Tipo di blocco dei file Network Lock Manager (NLM). Il blocco è controllato dal client. Blocco degli avvisi basati sul leasing. La serratura è controllata dal server.
Supporta gli errori del client No
Supporta l'accesso privato ai servizi No No

Vantaggi di NFSv3

Il protocollo NFSv3 offre una rapida configurazione per l'accesso POSIX standard.

Limitazioni NFSv3

Di seguito è riportato un elenco delle limitazioni di NFSv3:

  • Non offre assistenza per l'accesso privato ai servizi.
  • Manca l'autenticazione e la crittografia client e server.
  • Manca la gestione degli errori del client.

Vantaggi di NFSv4.1

Il protocollo NFSv4.1 utilizza il metodo RPCSEC_GSS Authentication, che viene implementato utilizzando LDAP e Kerberos per fornire autenticazione del client e del server, controlli di integrità dei messaggi e crittografia dei dati in transito.

Queste funzionalità di sicurezza rendono il protocollo NFSv4.1 compatibile con i moderni requisiti di conformità alla sicurezza di rete:

  • Utilizza una singola porta del server, 2049, per tutte le comunicazioni, contribuendo a semplificare le configurazioni del firewall.

  • Supporta gli elenchi di controllo dell'accesso ai file (ACL) NFSv4.1.

    • Ogni ACL supporta fino a 50 voci di controllo dell'accesso (ACE) per file o . Sono inclusi i record di eredità.
  • Supporto per gruppi illimitati quando si utilizza l'integrazione di Microsoft Active Directory gestito.

  • Supporta una gestione migliore degli errori del client con il blocco di consulenza basato su lease.

    • Il client deve verificare la connessione continua con il server. Se il client non rinnova il lease, il server rilascia il blocco e il file disponibile per qualsiasi altro cliente che richiede l'accesso tramite leasing del blocco. In NFSv3, se un client viene eliminato mentre è bloccato, il file non può essere acceduto da un altro client, ad esempio un nuovo nodo GKE.
  • Supporta il recupero stateful.

    • A differenza di NFSv3, NFSv4.1 è un protocollo stateful basato su TCP e connessione. È possibile riprendere lo stato del client e del server nella sessione precedente dopo il ripristino.

Managed Service for Microsoft Active Directory

Anche se Managed Service for Microsoft Active Directory (Managed Microsoft AD) non è un requisito rigoroso, è l'unica soluzione gestita da Google Cloud che supporta sia LDAP sia Kerberos, entrambi requisiti per il protocollo NFSv4.1 di Filestore.

Consigliamo vivamente agli amministratori di utilizzare Servizio gestito per Microsoft Active Directory (Microsoft AD gestito) per implementare e gestire LDAP e Kerberos.

Essendo una soluzione gestita da Google Cloud, Microsoft Active Directory gestito offre i seguenti vantaggi:

  • Offre il deployment in più regioni, supportando fino a cinque regioni nello stesso dominio.

    • Riduce la latenza garantendo che gli utenti e i rispettivi server di accesso si trovino vicinanza.
  • Supporta POSIX RFC 2307 e RFC 2307bis, requisiti per l'implementazione di NFSv4.1.

  • Automatizza l'identificatore univoco (UID) e l'utente identificatore univoco globale (GUID) il mapping.

  • Gli utenti e i gruppi possono essere creati in Managed Microsoft AD o di cui è possibile eseguire la migrazione.

  • Gli amministratori possono creare un trust di dominio con l'attuale dominio Active Directory (AD) e LDAP on-premise autogestito. Con questa opzione, la migrazione non è necessaria.

  • Fornisce uno SLA.

Controllo dell'accesso e comportamenti aggiuntivi

  • Le ACE NFSv4.1 di Filestore vengono gestite su Linux utilizzando i seguenti comandi:

    • nfs4_setfacl: crea o modifica i permessi ACE in un file o una directory.
    • nfs4_getfacl: elenca le Esperimenti campagna AdWords in un file o in una directory.
  • Ogni ACL supporta fino a 50 Esperimenti campagna AdWords. Sei voci riservate per la generazione automatica Esperimenti campagna AdWords creati dalle operazioni del client chmod. Questi ACE possono essere modificati dopo la creazione.

    I record ACE generati automaticamente che rappresentano i bit di modalità sono elencati nel nel seguente ordine di priorità:

    • DENY and ALLOW ACEs per il OWNER@
    • DENY and ALLOW ACEs per il GROUP@
    • DENY and ALLOW ACEs per EVERYONE@

      Se questi ACE sono già presenti, verranno riutilizzati e modificati in base ai nuovi bit di modalità applicati.

  • Filestore NFSv4.1 supporta il controllo dell'accesso richiesto solo in Modalità POSIX RWX (lettura, scrittura ed esecuzione). Non distinguerà Operazioni write append e write che modificano il contenuto o SETATTR la specifica del container. L'utilità nfs4_setfacl accetta anche RWX come scorciatoia e attiva automaticamente tutti i flag appropriati.

  • nfs4_getfacl non esegue alcuna traduzione dell'entità autonomamente. L'utilitànfs4_getfacl mostrerà i valori numerici UID e GUID per i principali. Di conseguenza, verranno visualizzati gli elementi speciali OWNER@, GROUP@ e EVERYONE@.

  • Indipendentemente dall'utilizzo di AD Microsoft gestito, quando si lavora con AUTH-SYS e l'utilità nfs4_setfacl, gli amministratori devono specificare UID e GUID numerici, non i nomi utente. Questa utilità non è in grado di traduci i nomi in questi valori. Se non è specificato correttamente, L'istanza Filestore utilizzerà per impostazione predefinita l'ID nobody.

  • Quando specifichi le autorizzazioni di scrittura per un file o anche per i file interessati da un ACE ereditato, l'ACE deve includere sia i flag w (scrittura) sia a (accodamento).

  • Quando controlli le autorizzazioni per SETATTR, la risposta restituita è simile a POSIX nel seguente modo:

    • Il super user o l'utente ROOT può fare qualsiasi cosa.
    • Solo il proprietario del file può impostare bit di modalità, ACL e timestamp un orario e un gruppo specifici, ad esempio uno dei GUID a cui appartiene.
    • Gli utenti diversi dal proprietario del file possono visualizzare gli attributi, incluso l'ACL.
  • Un singolo ACE include sia le autorizzazioni effettive sia quelle di sola ereditarietà. Contrariamente ad altre implementazioni NFSv4.1, Filestore replicare ACES ereditati al fine di distinguere tra ed ereditare solo gli Esperimenti campagna AdWords.

Limitazioni di NFSv4.1

Di seguito è riportato un elenco delle limitazioni di NFSv4.1:

  • Il protocollo NFSv4.1 non può essere combinato con le seguenti funzionalità:

  • Il protocollo NFSv4.1 non supporta AUDIT and ALARM ACEs. Filestore non supporta il controllo dell'accesso ai dati.

  • Una volta configurati, non eliminare AD Microsoft gestito e il peering di rete. In questo modo, la condivisione Filestore sarà inaccessibile mentre è montata su un client, rendendo i dati inaccessibili. Google Cloud non è responsabile di interruzioni causate da azioni dell'amministratore o dell'utente.

  • Quando utilizzano una qualsiasi delle impostazioni di sicurezza Kerberos autenticate, gli utenti possono è previsto una latenza delle operazioni. Le percentuali di latenza variano in base al livello di servizio dell'impostazione di sicurezza specificata. La latenza aumenta con ogni livello di sicurezza.

  • Il controllo dell'accesso ai dati non è supportato.

  • La soluzione Filestore NFSv4.1 richiede l'autenticazione RPCSEC_GSS. Questo metodo di autenticazione viene implementato solo utilizzando LDAP e Kerberos, entrambi disponibili in Microsoft AD gestito. Non sono supportati altri meccanismi di autenticazione.

  • Non offre assistenza per l'accesso privato ai servizi.

  • Se vuoi che un'istanza Filestore partecipi a Managed Microsoft AD attraverso un VPC condiviso, devi usare gcloud o Filestore tramite Google Cloud CLI o tramite l'API Compute Engine. Non puoi unire l'istanza a Microsoft Active Directory gestito utilizzando nella console Google Cloud.

  • Il nome di dominio Microsoft Active Directory gestito non deve superare i 56 caratteri.

  • Per creare un'istanza Enterprise, devi eseguire le operazioni direttamente tramite l'API Filestore. Per ulteriori informazioni, consulta Livelli di servizio.

  • Quando ripristini un backup, la nuova istanza deve utilizzare lo stesso protocollo dell'istanza di origine.

Passaggi successivi