Il plug-in Apache Hadoop HDFS fornisce connessioni ai cluster, ricerca dei percorsi e gestione delle policy in GrantForge. L’ID del plug-in e il tipo di servizio sono entrambi hdfs.
Installazione
La distribuzione include il plug-in in plugins/hdfs. Verifica che hdfs sia abilitato in Gestione della piattaforma → Plug-in; ripeti la scansione della directory dopo un aggiornamento.
Aggiungere un servizio di dati
- Apri Permessi sui dati → Servizi di dati, aggiungi un servizio e seleziona HDFS (
hdfs). - Inserisci l’URI del cluster e l’utente di consultazione. Hadoop 2.x usa
webhdfs://namenode:50070; 3.x può usarehdfs://namenode:8020owebhdfs://namenode:9870. Per HTTPS usaswebhdfs://con la porta effettiva del cluster. - Imposta la directory di consultazione e prova la connessione: la directory deve esistere e poter essere elencata. Poi salva il servizio.
| Impostazione | Utilizzo |
|---|---|
fs.default.name |
URI obbligatorio del cluster, senza sottodirectory, credenziali o parametri; HA può usare hdfs://nameservice1 con le proprietà aggiuntive corrispondenti |
username |
Utente di consultazione obbligatorio; con Kerberos, un principal come grantforge@EXAMPLE.COM |
hadoop.security.authentication |
Predefinito simple; scegli kerberos per un cluster Kerberos |
hadoop.security.authorization |
Se Hadoop verifica i permessi, predefinito false; coerente con il core-site.xml del cluster |
hadoop.security.auth_to_local |
Regole di corrispondenza tra principal Kerberos e nomi utente, coerenti con il core-site.xml del cluster |
password / keytab |
Password Kerberos o percorso di un file keytab sul server GrantForge |
kerberos.kdc |
KDC del realm del principal di ricerca, host[:port], separati da virgole; vuoto usa il krb5.conf del server |
dfs.namenode.kerberos.principal, dfs.datanode.kerberos.principal, dfs.secondary.namenode.kerberos.principal |
Principal dei componenti del cluster con Kerberos, come nn/_HOST@EXAMPLE.COM, coerenti con la configurazione del cluster |
lookup.path |
Directory iniziale di ricerca ed esplorazione, predefinita /, ad esempio /data; l’esplorazione resta al suo interno |
lookup.max.entries |
Limite delle scansioni complete, predefinito 10000, intervallo 1..100000 |
hadoop.config |
Un key=value per riga per HA e altre proprietà Hadoop; sovrascrive le impostazioni di connessione omonime |
hadoop.rpc.protection |
authentication, integrity o privacy, secondo il cluster |
ssl.client.truststore.location |
Percorso sul server GrantForge del truststore che verifica i certificati dei NameNode swebhdfs://; vuoto si fida di ciò di cui si fida Java sul server |
ssl.client.truststore.password |
La password del truststore, se è protetto; salvata cifrata |
ssl.client.truststore.type |
jks (predefinito) o pkcs12 |
Con l’estensione degli attributi NameNode abilitata in Hadoop 2.7.7, gli utenti ordinari che interrogano il percorso radice / causano una NullPointerException upstream confermata; imposta lookup.path su una directory esistente come /data (vedi la guida dell’agente).
Kerberos richiede anche un KDC raggiungibile, il krb5.conf del server e regole hadoop.security.auth_to_local e principal di servizio coerenti. L’account di consultazione recupera i metadati delle directory. Testato su cluster Kerberos di tutte e sei le linee: ricerca via swebhdfs (truststore proprio del servizio e SPNEGO) su ogni linea, ricerca ed esplorazione via RPC (keytab o password) su 3.x; credenziali errate, truststore mancante e un client simple falliscono, e i permessi propri del NameNode valgono per l’account di ricerca.
Con Kerberos, GrantForge riutilizza un accesso tra una ricerca e l’altra invece di interrogare il KDC ogni volta: Hadoop rinnova un accesso con keytab quando il ticket sta per scadere, e un accesso con password viene ripetuto quando resta meno di un quinto della vita del ticket (e almeno un minuto); una password cambiata o un keytab aggiornato accedono di nuovo. Ogni servizio usa il proprio truststore, che un ssl-client.xml nel classpath del server non sostituisce.
Un solo GrantForge può raggiungere cluster di più realm Kerberos: indicate in kerberos.kdc di ogni servizio i KDC del suo realm; il realm è quello del principal in username, ad esempio grantforge@BETA.EXAMPLE. GrantForge scrive una configurazione che include il krb5.conf del server e vi aggiunge i realm dei servizi; vale dall’accesso successivo, senza riavvio. Con hadoop.security.auth_to_local vuoto, i principal del realm ricevono regole per il nome breve. L’impostazione non è utilizzabile se il server imposta java.security.krb5.realm e .kdc. Se due servizi indicano KDC diversi per lo stesso realm prevale la ricerca più recente, quindi manteneteli uguali; la fiducia tra realm resta da configurare nel krb5.conf del server.
In uno stesso GrantForge, test di connessione, ricerche ed esplorazioni dei servizi HDFS vengono eseguiti uno alla volta, mai in parallelo: Hadoop mantiene il tipo di autenticazione, auth_to_local e lo stato di accesso Kerberos per l’intero processo, quindi chiamate simultanee si sovrascriverebbero. Ogni chiamata è limitata da grantforge.plugins.call-timeout (10 secondi per impostazione predefinita), compresa l’attesa del proprio turno; aumentatelo con molti servizi, cluster lenti o un primo accesso Kerberos lento.
La configurazione viene validata al salvataggio: in hadoop.config, fs.defaultFS e fs.default.name sono alias, quindi configurarne uno solo; l’URI del cluster non deve contenere credenziali, percorso, query o frammento; kerberos richiede una password o un keytab; lookup.path deve essere un percorso assoluto senza ..; lookup.max.entries deve essere compreso tra 1 e 100000. Le proprietà aggiuntive sovrascrivono le impostazioni di connessione omonime, e sia la validazione sia l’accesso usano i valori sovrascritti.
Esplorare i percorsi
Seleziona il servizio in Permessi sui dati → Policy e usa Esplora accanto a path.
- Apri le directory, naviga nel percorso o torna alla directory padre e carica le pagine successive quando necessario.
- Consulta gli indicatori file/directory, proprietario, gruppo, permessi, dimensione e data di modifica.
- Seleziona più file o directory, oppure la directory corrente, da aggiungere alla policy; la digitazione dei percorsi continua a proporre suggerimenti.
RPC e gli endpoint WebHDFS con elenchi in batch usano la paginazione nativa. Gli endpoint meno recenti leggono le directory entro il limite di scansione e segnalano un errore oltre tale limite. Gli errori di permessi, autenticazione o connessione mostrano la causa e permettono di riprovare.
L’input può omettere la / iniziale, / e . ripetuti sono consentiti, mentre .. e i percorsi assoluti fuori da lookup.path vengono rifiutati; una directory inesistente non restituisce candidati. L’esplorazione non sostituisce il controllo di accesso di HDFS; collegamenti simbolici e mount ViewFS seguono la configurazione del cluster.
Applicare le policy
L’unico livello di risorsa è path, con accessi read, write ed execute. Le policy dei percorsi supportano ricorsione ed esclusioni.
Il plug-in del server gestisce e consulta le risorse. Per applicare le policy occorre anche l’agente NameNode corrispondente alla versione Hadoop; gli utenti devono soddisfare sia i permessi HDFS nativi sia le policy GrantForge. Gli agenti numerati coprono 2.7, 2.10, 3.2, 3.3, 3.4 e 3.5. La guida dell’agente riporta combinazioni verificate, copertura di autenticazione e HA e limiti del superutente.