2014-06-24 14 views
5

Sto eseguendo un cluster di test con MRv1 (CDH5) accoppiato con LocalFileSystem e l'unico utente che sono in grado di eseguire processi come è mappato (come mapred è l'utente che avvia i daemon di jobtracker/tasktracker). Quando si inoltrano lavori come qualsiasi altro utente, i lavori non riescono perché il jobtracker/tasktracker non è in grado di trovare job.jar nella directory .staging.I lavori Hadoop falliscono quando vengono inviati da utenti diversi dal filato (MRv2) o mappati (MRv1)

Ho lo stesso identico problema con YARN (MRv2) quando abbinato a LocalFileSystem, ovvero quando si inoltrano lavori da un utente diverso da 'filato', il master dell'applicazione non è in grado di individuare job.jar nella directory .staging.

Dopo aver ispezionato la directory .staging dell'utente che ha inviato il lavoro, ho trovato che job.jar esiste nella directory .staging //, ma le autorizzazioni sulle directory e .staging sono impostate su 700 (drwx ---- -) e quindi l'applicazione master/tasktracker non è in grado di accedere a job.jar e ai file di supporto.

Stiamo eseguendo il cluster di test con LocalFileSystem poiché utilizziamo solo la parte MapReduce del progetto Hadoop abbinata a OCFS nella nostra configurazione di produzione.

Qualsiasi aiuto in questo senso sarebbe immensamente utile.

+0

È possibile avviare il processo PIG o hive nello stesso cluster? –

risposta

1

È necessario impostare una directory di gestione temporanea per ciascun utente nel cluster. Non è così complicato come sembra.

Controllare le seguenti proprietà:

<property> 
<name>hadoop.tmp.dir</name> 
<value>/tmp/hadoop-${user.name}</value> 
<source>core-default.xml</source> 
</property> 

Questo messe a punto fondamentalmente una directory tmp per ogni utente.

Tie questo alla vostra directory di gestione temporanea:

<property> 
<name>mapreduce.jobtracker.staging.root.dir</name> 
<value>${hadoop.tmp.dir}/mapred/staging</value> 
<source>mapred-default.xml</source> 
</property> 

farmi sapere se questo funziona o se è già impostato in questo modo.

Queste proprietà devono essere in filato-site.xml - se non ricordo male.

+0

Ciao, da dove viene $ {user.name}? –

1

Questo ha funzionato per me, ho solo impostare questa proprietà in MR v1:

<property> 
    <name>hadoop.security.authorization</name> 
    <value>simple</value> 
    </property> 

Si prega di passare attraverso questo:

Access Control Lists $ {} HADOOP_CONF_DIR /hadoop-policy.xml definisce un elenco di controllo di accesso per ciascun servizio Hadoop. Ogni elenco di controllo di accesso ha un formato semplice:

L'elenco di utenti e gruppi è costituito da un elenco di nomi separati da virgola. Le due liste sono separate da uno spazio.

Esempio: utente1, utente2 gruppo1, gruppo2.

Aggiungere un vuoto all'inizio della riga se deve essere fornito solo un elenco di gruppi, in modo equivalente un elenco separato da un elenco di utenti seguito da uno spazio o nulla implica solo un insieme di utenti specificati.

Un valore speciale di * implica che tutti gli utenti sono autorizzati ad accedere al servizio.

Configurazione autorizzazione livello servizio aggiornamento La configurazione dell'autorizzazione a livello di servizio per NameNode e JobTracker può essere modificata senza riavviare nessuno dei daemon master Hadoop. L'amministratore del cluster può modificare $ {HADOOP_CONF_DIR} /hadoop-policy.xml sui nodi master e indicare a NameNode e JobTracker di ricaricare le rispettive configurazioni tramite l'opzione -refreshServiceAcl ai comandi dfsadmin e mradmin rispettivamente.

aggiornare la configurazione di autorizzazione a livello di servizio per il NameNode:

$ bin/Hadoop dfsadmin -refreshServiceAcl

aggiornare la configurazione di autorizzazione a livello di servizio per il JobTracker:

$ bin/Hadoop mradmin -refreshServiceAcl

Ovviamente, è possibile utilizzare la proprietà security.refresh.policy.protocol.acl in $ {HADOOP_CONF_DIR} /hadoop-policy.xml per limitare l'accesso alla possibilità di aggiornare la s configurazione dell'autorizzazione a livello di servizio per determinati utenti/gruppi.

Esempi consentire solo agli utenti Alice, Bob e gli utenti nel gruppo MapReduce per inviare i lavori al cluster MapReduce:

<property> 
    <name>security.job.submission.protocol.acl</name> 
    <value>alice,bob mapreduce</value> 
</property> 

Consenti solo DataNodes esecuzione come gli utenti che appartengono ai datanodes gruppo per comunicare con il NameNode:

<property> 
    <name>security.datanode.protocol.acl</name> 
    <value>datanodes</value> 
</property> 
Allow any user to talk to the HDFS cluster as a DFSClient: 

<property> 
    <name>security.client.protocol.acl</name> 
    <value>*</value> 
</property> 
Problemi correlati