Zadanie Hadoop nie powiodło się, gdy zostało przesłane przez użytkowników innych niż przędza (MRv2) lub mapowane (MRv1)

Question

Używam klastra testowego z uruchomioną MRv1 (CDH5) sparowanego z LocalFileSystem i jedynym użytkownikiem, który jestem w stanie uruchomić zadania zgodnie z mapowaniem (as mapred to użytkownik uruchamiający demony jobtracker/tasktracker). Podczas przesyłania zadań jak każdy inny użytkownik zadania nie mogą się powieść, ponieważ jobtracker/tasktracker nie może znaleźć pliku job.jar w katalogu .staging.

Mam dokładnie ten sam problem z YARN (MRv2) po sparowaniu z LocalFileSystem, tj. Przy przesyłaniu zadań przez użytkownika innego niż "przędza", wzorzec aplikacji nie może znaleźć pliku job.jar w katalogu .staging.

Podczas sprawdzania katalogu .staging użytkownika przesyłającego zadanie okazało się, że plik job.jar istnieje w katalogu .staging //, ale uprawnienia do katalogów i .staging są ustawione na 700 (drwx ---- -), a zatem master/tasktracker aplikacji nie może uzyskać dostępu do pliku job.jar i plików pomocniczych.

Używamy klastra testowego z LocalFileSystem, ponieważ używamy tylko części MapReduce projektu Hadoop w połączeniu z OCFS w naszej konfiguracji produkcyjnej.

Każda pomoc w tym zakresie byłaby ogromnie pomocna.

Answer 1

Konieczne jest skonfigurowanie katalogu pomostowego dla każdego użytkownika w klastrze. To nie jest tak skomplikowane, jak się wydaje.

Sprawdź następujące właściwości:

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

Zasadniczo Nastawienia katalog tmp dla każdego użytkownika.

Tie to do katalogu pomostowego:

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

Daj mi znać, czy to działa, czy też już setup ten sposób.

Te właściwości powinny znajdować się w pliku yarn-site.xml - jeśli dobrze pamiętam.

Answer 2

ten pracował dla mnie, po prostu ustawić tę właściwość w MR V1: Listy $ {HADOOP_CONF_DIR} /hadoop-policy.xml definiuje

Access Control:

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

Proszę przejść przez ten lista kontroli dostępu dla każdej usługi Hadoop. Każda lista kontroli dostępu ma prosty format:

Lista użytkowników i grup jest rozdzielaną przecinkami listą nazw. Dwie listy są oddzielone spacją.

Przykład: użytkownik1, użytkownik2 grupa1, grupa2.

Dodaj pustą na początku wiersza, jeśli ma być dostarczona tylko lista grup, równoważnie lista użytkowników rozdzielona przecinkami, po której następuje spacja lub nic nie oznacza tylko zbioru danych użytkowników.

Specjalna wartość * oznacza, że ​​wszyscy użytkownicy mają dostęp do usługi.

Konfiguracja autoryzacji odświeżającego poziomu usługi Konfiguracja autoryzacji na poziomie usługi dla NameNode i JobTracker może zostać zmieniona bez restartowania żadnego z demonów master Hadoop. Administrator klastra może zmienić $ {HADOOP_CONF_DIR} /hadoop-policy.xml na głównych węzłach i polecić NameNode i JobTracker, aby ponownie załadować swoje odpowiednie konfiguracje przez przełącznik -refreshServiceAcl odpowiednio do poleceń dfsadmin i mradmin.

Odśwież konfigurację autoryzacji poziomu usług dla NameNode:

$ bin/Hadoop dfsadmin -refreshServiceAcl

Odśwież konfigurację autoryzacji poziomu usług dla JobTracker:

$ bin/Hadoop mradmin -refreshServiceAcl

Oczywiście, można użyć właściwości security.refresh.policy.protocol.acl w $ {HADOOP_CONF_DIR} /hadoop-policy.xml, aby ograniczyć dostęp do możliwości odświeżania s konfiguracja autoryzacji na poziomie podstawowym dla niektórych użytkowników/grup.

Przykłady Tylko osoby Alice, Bob i użytkowników w grupie mapreduce do złożenia oferty do klastra MapReduce:

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

Zezwalaj tylko DataNodes działa jako użytkowników, którzy należą do datanodes grupowych do komunikowania się z 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>