2015-09-22 8 views
6

Do tej pory uruchamiałem Spark tylko na maszynach Linux i maszynach wirtualnych (bridged networking), ale teraz jestem interesujący w wykorzystywaniu większej ilości komputerów jako niewolników. Przydałaby się dystrybucja kontenera Docker Spark Slave na komputerach i automatyczne połączenie ich z zakodowanym Iskrem głównym IP. To już działa, ale mam problem z skonfigurowaniem odpowiedniego SPARK_LOCAL_IP (lub parametru -host dla start-slave.sh) na kontenerach slave.Spark SPARK_PUBLIC_DNS i SPARK_LOCAL_IP w autonomicznym klastrze z kontenerami dokowania

Wydaje mi się, że poprawnie skonfigurowałem zmienną env SPARK_PUBLIC_DNS tak, aby odpowiadała IP sieci dostępnej dla hosta (z przestrzeni adresowej 10.0.x.x), co najmniej jest pokazywana w interfejsie WWW urządzenia Spark master i jest dostępna dla wszystkich komputerów.

Ustawiłem również SPARK_WORKER_OPTS i port Docker do przodu zgodnie z instrukcją na http://sometechshit.blogspot.ru/2015/04/running-spark-standalone-cluster-in.html, ale w moim przypadku Master Sparka działa na innej maszynie, a nie w Dockerze. Uruchamiam zadania Sparka z innej maszyny w sieci, być może także z samym niewolnikiem.

Rzeczy, które próbowałem:

  1. należy konfigurować SPARK_LOCAL_IP w ogóle, niewolnik wiąże się z dochodzeniem kontenera (np 172.17.0.45), nie może być połączony z master lub sterownika, obliczenia nadal działa większość czas, ale nie zawsze
  2. Powiąż z 0.0.0.0, slave rozmawiają z masterem i nawiązują połączenie, ale umiera, inny niewolnik pojawia się i znika, kontynuuje pętlę w ten sposób
  3. Powiąż z hostem ip, start nie działa jako ten adres IP nie jest widoczny w kontenerze, ale byłby dostępny dla innych, ponieważ przekazywanie portów jest skonfigurowane jako

Zastanawiam się, dlaczego skonfigurowany SPARK_PUBLIC_DNS nie jest używany podczas łączenia się z urządzeniami podrzędnymi? Myślałem, że SPARK_LOCAL_IP wpłynie tylko na lokalne powiązanie, ale nie zostanie ujawnione na komputerach zewnętrznych.

Pod numerem https://databricks.gitbooks.io/databricks-spark-knowledge-base/content/troubleshooting/connectivity_issues.html poinstruowano, aby "ustawić SPARK_LOCAL_IP na adresowalną nazwę hosta dla procesów sterownika, procesora głównego i procesów roboczych", czy jest to jedyna opcja? Uniknąłbym dodatkowej konfiguracji DNS i po prostu użyłbym ips do skonfigurowania ruchu między komputerami. Czy istnieje prosty sposób, aby to osiągnąć?

Edit: Podsumowując obecną Ustawianie:

  • Master działa na Linux (VM w VirtualBox Windows z mostku sieci)
  • Kierowca twierdzi pracy z innego komputera z systemem Windows, działa świetnie
  • Obraz dokowania do uruchamiania niewolników jest rozprowadzany jako "zapisany" plik .tar.gz, ładowany (zwinięty xyz | gunzip | ładunek dokowanego) i uruchamiany na innych maszynach w sieci, ma to probem z prywatnym/publicznym konfiguracja ip
+0

Jak dokładnie próbujesz używać kontenerów? czy były to pojemniki tylko do "piaskownicy" lub "eksperymentowania?" Mam na myśli to, czy próbujesz uruchomić wiele kontenerów równolegle z mistrzem na jednym kontenerze i po prostu niewolnikami w innych? czy instalujesz razem iskrę poza kontenerami? – TravisJ

+0

Tylko niewolnicy będą w Dockerze, master i sterownik działają "natywnie" w systemie operacyjnym (ale prawdopodobnie w maszynie wirtualnej). Mój obraz dokowanego niewolnika wygląda mniej więcej tak (nie całkiem aktualny): https://github.com/nikonyrh/docker-scripts/blob/master/spark_py34/Dockerfile Zasadniczo instaluje Python 3.4, numpy, scipy itp. Będziemy potrzebować do równoległego szkolenia naszych modeli. Musimy skalować na wielu niewolnikach, aby uzyskać wyniki szybciej i myślałem, że obraz Docker będzie łatwy do wdrożenia, a nawet na AWS. – NikoNyrh

+0

FYI Wysłałem również pytanie na https://github.com/apache/spark/pull/3645#issuecomment-142319031, również związane z https://github.com/apache/spark/pull/3893 – NikoNyrh

Odpowiedz

5

Chyba znalazłem rozwiązanie dla mojego użytku literami (jeden pojemnik Spark/hosta OS):

  1. Zastosowanie --net host z eth0 docker run => gospodarza jest widoczny w pojemniku
  2. Ustaw SPARK_PUBLIC_DNS i SPARK_LOCAL_IP na adres IP hosta, zignoruj ​​172.xx docker0x adres

Iskrzą może połączyć się z komputerem ip i inne urządzenia komunikują się z nim, przekazywanie portów zajmuje się resztą. DNS lub jakiekolwiek skomplikowane konfiguracje nie były potrzebne, nie testowałem tego dokładnie, ale do tej pory tak dobrze.

Edycja: Należy pamiętać, że te instrukcje dotyczą Spark 1.x, w Spark 2.x wymagane jest tylko SPARK_PUBLIC_DNS, uważam, że SPARK_LOCAL_IP jest przestarzałe.

6

Używam 3 różnych typów kontenerów doków na moim komputerze z zamiarem wdrożenia ich w chmurze, gdy wszystkie potrzebne oprogramowanie zostanie do nich dodane: Master, Worker i notatnik Jupyter (ze Scala, R i Python jądra).

Oto moje obserwacje tej pory:

Master:

  • nie mogłem zrobić to wiązać się z Docker Host IP. Zamiast tego przekazuję do niego nazwę domeny: -h "dockerhost-master" -e SPARK_MASTER_IP="dockerhost-master". Nie mogłem znaleźć sposobu na powiązanie Akki z adresem IP kontenera, ale akceptuję komunikaty pod adresem IP hosta. Wiem, że to możliwe z Akka 2.4, ale może nie z Spark.
  • Przechodzę pod numer -e SPARK_LOCAL_IP="${HOST_IP}", który powoduje, że interfejs internetowy wiąże się z tym adresem zamiast z adresem IP kontenera, ale interfejs WWW działa poprawnie.

Pracownik:

  • dałem pojemnik pracownik innego hosta i przekazać go jako --host do Spark org.apache.spark.deploy.master.Worker klasie. To nie może być taka sama jak magistra lub klastra Akka nie zadziała: -h "dockerhost-worker"
  • Używam Docker na add-host więc pojemnik jest w stanie rozwiązać nazwę hosta do pana IP: --add-host dockerhost-master:${HOST_IP}
  • Mistrza adres URL musi być przekazywana jest spark://dockerhost-master:7077

Jupyter:

  • to trzeba URL master i add-host, aby móc go rozwiązać
  • żyje w notatniku i tam zaczyna się internetowy interfejs aplikacji Spark, a nie master. Domyślnie wiąże się z wewnętrznym adresem IP kontenera Docker. Aby zmienić to, co musiałem przekazać: -e SPARK_PUBLIC_DNS="${VM_IP}" -p 4040:4040. Kolejne aplikacje z notebooka będą miały numer 4041, 4042 itd.

Dzięki tym ustawieniom trzy komponenty mogą się ze sobą komunikować. Używam niestandardowych skryptów startowych z spark-class, aby uruchomić klasy na pierwszym planie i w tej chwili nie zezwalać na zamykanie kontenerów Docker.

Istnieje kilka innych portów, które mogą zostać ujawnione, takie jak serwer historii, który nie został jeszcze napotkany. Używanie --net host wydaje się znacznie prostsze.

+0

klasa do uruchomienia pracownik jest niepoprawny. powinien to być org.apache.spark.deploy.worker.Worker, zamiast org.apache.spark.deploy.master.Worker. –

4

Używam również iskry w kontenerach na różnych hostach w docku. Począwszy pojemnik roboczy z tych argumentów nie pracował dla mnie:

docker run \ 
-e SPARK_WORKER_PORT=6066 \ 
-p 6066:6066 \ 
-p 8081:8081 \ 
--hostname $PUBLIC_HOSTNAME \ 
-e SPARK_LOCAL_HOSTNAME=$PUBLIC_HOSTNAME \ 
-e SPARK_IDENT_STRING=$PUBLIC_HOSTNAME \ 
-e SPARK_PUBLIC_DNS=$PUBLIC_IP \ 
spark ... 

gdzie $PUBLIC_HOSTNAME hosta jest osiągalny z pana.

Brakujący element to SPARK_LOCAL_HOSTNAME, nieudokumentowana opcja AFAICT.

https://github.com/apache/spark/blob/v2.1.0/core/src/main/scala/org/apache/spark/util/Utils.scala#L904

+0

'SPARK_LOCAL_HOSTNAME' jest dokładną konfiguracją, której szukałem. Dziękuję Ci! –

Powiązane problemy