Closed kmu-leeky closed 7 years ago
네 알겠습니다.
그냥 작업만 하지말고, 중간에 발견되는 문제점 이나 동작 시퀀스 등을 정리해주는게 좋을것 같아.
#!/bin/bash
STOP_FRONT="sudo docker stop yarn-slave"
RM_FRONT="sudo docker rm yarn-slave"
for i in {1..25}
do
STOP_COMMAND="$STOP_FRONT$i"
$STOP_COMMAND
RM_COMMAND="$RM_FRONT$i"
$RM_COMMAND
done
sudo docker network create --driver overlay --subnet 10.10.0.0/24 --attachable spark-yarn-network
network 구성 상태를 보고 싶으면
sudo docker netwrok inspect spark-yarn-network (네트워크 이름)
명령어를 사용하면 된다.
#! /bin/bash
NETWORK=$2
MASTER_COMMAND="sudo docker run -it --name yarn-master --network $1 --ip 10.10.0.2 --add-host=master:10.10.0.2 -p 8088:8088 --cpu-shares 1024 --memory 12g"
SLAVE_FRONT="sudo docker run -it --name"
SLAVE_COMMAND=""
COMMAND_LAST="kmubigdata/ubuntu-hadoop /bin/bash"
SLAVE="slave"
ADDHOST='--add-host='
IP="10.10.0."
numOfContainers=1
numOfAddHosts=1
numOfCores=1
coreNumber=1
if [[ -z "$5" ]]; then
echo "format is wrong"
echo "./run_hadoop network-name want-master slave-from slave-to number-of-hosts"
echo "ex) ./run_hadoop my-net 1 1 5 10"
echo "network is my-net, need master container, slave from 1, slave to 5, number of hosts=10"
exit 0
fi
if [ $2 == 1 ]; then
while [ $numOfAddHosts != $(($5+1)) ];
do
MASTER_COMMAND="$MASTER_COMMAND $ADDHOST$SLAVE$numOfAddHosts:$IP$(($numOfAddHosts+2))"
numOfAddHosts=$(($numOfAddHosts+1))
done
MASTER_COMMAND="$MASTER_COMMAND $COMMAND_LAST"
$MASTER_COMMAND
fi
numOfContainers=$3
while [ $numOfContainers != $(($4+1)) ];
do
SLAVE_COMMAND="$SLAVE_FRONT yarn-slave$numOfContainers --network $1 --ip $IP$(($numOfContainers+2)) --memory 4g --cpu-shares 1024 --storage-opt size=300G --add-host=master:10.10.0.2"
numOfAddHosts=1
while [ $numOfAddHosts != $(($5+1)) ];
do
SLAVE_COMMAND="$SLAVE_COMMAND $ADDHOST$SLAVE$numOfAddHosts:$IP$(($numOfAddHosts+2))"
numOfAddHosts=$(($numOfAddHosts+1))
done
numOfCores=1
$SLAVE_COMMAND $COMMAND_LAST
SLAVE_COMMAND=''
numOfContainers=$(($numOfContainers+1))
coreNumber=$(($coreNumber+1))
done
bd-1 ./run_hadoop spark-yarn-network 1 1 25 75
bd-2 ./run_hadoop spark-yarn-network 0 26 50 75
bd-3 ./run_hadoop spark-yarn-network 0 51 75 75
쉘 스크립트 실행중에 컨테이너가 하나씩 켜질때 마다 ctrl+d로 종료해주면 된다.
컨테이너 생성이 모두 끝나면 다음 명령어로 컨테이너들을 한번에 실행.
sudo docker ps -a | awk '{print $1}' | xargs sudo docker start
다시 sudo docker netwrok inspect spark-yarn-network (네트워크 이름)
명령어를 이용해 오버레이 네트워크 상태를 보면 다음과 같이 새로 생성된 컨테이너들이 추가된 것을 볼 수 있다.
sudo docker exec -it yarn-master /bin/bash
마스터 컨테이너 접속
hadoop namenode -format
명령어로 namenode 초기화 후
cd $HADOOP_PREFIX/sbin
여기서 start-all.sh 실행
jps
명령어로 마스터 노드 jvm process 상태 확인.
slave 노드에서도 확인 (에러 발생)
여기서 보시면 slave 노드에서 데이터노드가 실행이 안되어 있는데 원인이 뭘까 생각하다가 현재 슬레이브 컨테이너가 메모리를 각각 4g씩 할당받게 되어있는데 yarn.nodemanager.resource.memory-mb 값이 4096mb여서 메모리가 부족해서 실행이 안되는걸로 추측해서 값을 2048로 바꾸어 보았습니다. 근데 검색을 좀 더 해보니 이게 문제가 아닌거 같아서 아직 원인을 잘 모르겠습니다..
그리고 마스터에서 start-all.sh 를 실행시켜도 203.246.113.16:8088 포트에 접속이 되지 않고 있고,
bd-2에서 sudo docker run -dit --name spark-client --network spark-yarn-network -p 22006:22 --add-host=master:10.10.0.2 --cpu-shares 1024 --memory 12g kmubigdata/ubuntu-spark /bin/bash
로 spark-client 컨테이너 생성후 spark-shell 실행시 다음과 같은 오류가 발생하고 있습니다.
하둡 Web UI 접근 불가 문제는 run_hadoop 쉘 스크립트의 MASTER_COMMAND 부분에 포트포워딩 해주는 부분을 다음과 같이 추가해서 해결했습니다.
MASTER_COMMAND="sudo docker run -it --name yarn-master --network $1 --ip 10.10.0.2 --add-host=master:10.10.0.2 -p 8088:8088 --cpu-shares 1024 --memory 12g"
docker hub에서 ubuntu-hadoop을 빌드해주었는데 ubuntu-spark 에서 빌드 도중에 계속 오류가 발생합니다.
음 남현아 우선 이슈에 코드를 업데이트 하지 말고, 코드는 코드로 파일을 만들어서 따로 커밋을 하고, 이슈에는 코드 링크만 두는게 나중에 확인하기도 좋을것 같아. 이렇게는 보기가 어려워.
"쉘 스크립트 실행중에 컨테이너가 하나씩 켜질때 마다 ctrl+d로 종료해주면 된다." run_hadoop 의 경우에도 https://github.com/kmu-bigdata/ubuntu-hadoop/blob/master/run_hadoop#L6 위의 코드를 보면 interactive shell 을 사용하지 않게 하는걸 해뒀어. 최신코드를 확인해봐.
"컨테이너 생성이 모두 끝나면 다음 명령어로 컨테이너들을 한번에 실행. sudo docker ps -a | awk '{print $1}' | xargs sudo docker start" 왜 필요하지?
슬레이브 노드에서 시작하지 않을 이유는 딱히 없을듯 한데.. ssh 등에 문제가 있을수 있으니, master 노드에서 start-all.sh 했을때 에러 메시지가 있는지 확인해봐.
마지막에 docker build 는 어떻게 시작한거야? 보통은 로컬 (bd-1,2,3 에서 docker build .) 에서 정상 동작 확인 후에 깃허브로 코드를 푸쉬한 후에 자동으로 빌드 되는데.
아 제가 run_hadoop 코드를 잘못썼습니다.. 다시 수정하도록 하겠습니다. 그리고 슬레이브 노드에서 시작하지 않는 문제는 해결했습니다. 마지막에 docker build 같은 경우에는 아까 yarn.nodemanager.resource.memory-mb 수정한 부분을 다시 원래값으로 하려고 github 페이지에서 직접 yarn-site 파일만 변경한 후에 pull request보내서 머지한 후 도커허브에서 자동으로 빌드 되도록 했습니다.
지금 깃허브에있는 kmubigdata/ubuntu-spark repository를 그대로 가져와서 build해보려고 했는데 https://people.apache.org/~pwendell/spark-nightly/spark-master-bin/latest/spark-2.3.0-SNAPSHOT-bin-without-hadoop.tgz 이 링크가 없어진것 같습니다.
오케이.
다운로드 같은 경우 2.3 이 아직 테스트 버전이라 링크가 왔다갔다 하나보다. 2.2 가 공식으로 발표되었으니 2.2 를 사용해도 되겠다. https://d3kbcqa49mib13.cloudfront.net/spark-2.2.0-bin-without-hadoop.tgz
sudo docker stop 컨테이너 이름
sudo docker rm 컨테이너 이름
명령어로 기존에 설치되어 있는 yarn-slave, yarn-master, spark-client 컨테이너를 지워준다. 귀찮으면 스크립트를 작성해 사용하면 된다.
sudo docker network create --driver overlay --subnet 10.10.0.0/24 --attachable spark-yarn-network
*특정 network 구성 상태를 보고 싶으면
sudo docker netwrok inspect spark-yarn-network (네트워크 이름)
명령어를 사용하면 된다.
현재 사용되고 있는 도커 이미지는
sudo docker pull kmubigdata/ubuntu-hadoop
sudo docker pull kmubigdata/ubuntu-spark
명령어로 가져오면 된다.
( * yarn-slave 생성시에 사용할 kmubigdata/ubuntu-hadoop 도커 이미지 버젼이 bd-1,2,3에 모두 같은지 확인해야 한다. 버젼이 다르면 bd-1,2,3 에 있는 컨테이너들 간의 ssh 접속 권한 문제가 발생할 수 있다.)
bd-1 ./run_hadoop spark-yarn-network 1 1 25 75
bd-2 ./run_hadoop spark-yarn-network 0 26 50 75
bd-3 ./run_hadoop spark-yarn-network 0 51 75 75
다시 sudo docker netwrok inspect spark-yarn-network (네트워크 이름)
명령어를 이용해 오버레이 네트워크 상태를 보면 다음과 같이 새로 생성된 컨테이너들이 추가된 것을 볼 수 있다.
sudo docker exec -it yarn-master /bin/bash
마스터 컨테이너 접속 후
(cat /etc/hosts 에서 모든 슬레이브 주소가 존재하는지 확인, $HADOOP_CONF_DIR/slaves 에도 slave1~75까지 있어야 한다.)
start-dfs.sh start-yarn.sh
실행
jps
명령어로 마스터 노드 jvm process 상태 확인.
yarn-master가 설치되어 있는 서버의 8088 포트로 접속 하면 하둡 Web UI를 확인할 수 있다.
sudo docker run -dit --name spark-client --network spark-yarn-network -p 22006:22 --add-host=master:10.10.0.2 --cpu-shares 1024 --memory 12g kmubigdata/ubuntu-spark /bin/bash
hdfs dfs -put $SPARK_HOME/jars /spark
hdfs dfs -mkdlir /spark/shared-logs
마지막으로
spark-shell --master yarn --num-executors 30
명령어로 스파크를 실행 시키면 다음과 같이 스파크가 정상 작동하는것을 확인할 수 있다.
교수님 지금 스파크 사용중에 이런 이슈가 발생하는데 얀 설정 문제인거 같아서 좀 더 확인해 보겠습니다.
start-master.sh start-slave.sh spark://spark-client:7077 이 두 쉘 스크립트를 실행 시키면 된다.
이건 왜 해준거야? 필요없을것 같은데.
Spark stand-alone cluster 와 YARN 모드의 차이점을 공부해봐.
아 제가 yarn deploy cluster mode와 client mode 개념과 헷갈린거 같습니다. 그 부분 수정하겠습니다.
교수님 스파크 yarn-site.xml에 yarn.nodemanager.resource.memory-mb 값을 3072로 yarn.scheduler.maximum-allocation-mb값을 1536 으로 수정해서 셋팅완료 하였습니다. 설치 메뉴얼은 위에 이슈에 있는 내용을 수정했고, 도커파일 변경된 부분은 kmu-bigdata 깃헙에 올려두도록 하겠습니다.
메모리 설정값이 문제였다는 거지? 그렇다면 다행이고.
spark-history 서버는 돌렸어? https://spark.apache.org/docs/latest/monitoring.html
첫부분 보고 작업해봐. 기본적인 config 파일은 만들어져 있으니, ubuntu-spark 이미지로 새로운 컨데이너 이미지 만들어서 18080 포트만 포워딩 해주면 될거야.
history 서버 작업하는 것 까지 설치법에 같이 작성해주고.
그리고 설명서 파일 이랑 코드 올린곳은 어디야?
spark-history 서버도 돌렸고 잘 작동하는데 메모리 설정값이 문제가 아닐수도 있을것 같습니다. 어제와 같은 spark-client 에서 같은 matrix multiplication 코드를 돌려보았는데 저번과 같은 에러가 다시 발생해서 원인 파악중입니다.. 현재 스파크 2.2.0 버전을 사용중인데 스파크 버전 문제인가해서 구글에 스파크 2.3.0 버전을 검색해봤는데 이미지를 못찾겠습니다.
설명서 파일은 아래 링크에 작성해 두었고 코드는 문제 해결되면 랩실 깃헙 레포지토리에 반영하도록 하겠습니다. https://docs.google.com/document/d/1_G3uRW4LGI8vFpcpO8858F13thgPTqjamlCE7eiv4Po/edit?usp=sharing
2.3 은 nightly build 의 spark-master-bin 에 있어 https://spark.apache.org/developer-tools.html#nightly-builds
문서 정리는 잘 해뒀고. 문서는 읽기 전용보다는 커멘트는 남기게 해줘. 그래야 보완할 부분에 대해서 얘기해주지
수정 가능하도록 바꾸었습니다. 교수님이 보내주신 링크 이미지파일 사용해 봤었는데 jars 폴더가 없어서 hdfs에 넣어주질 못했었는데 사용 가능한건가요?? https://people.apache.org/~pwendell/spark-nightly/spark-master-bin/spark-2.3.0-SNAPSHOT-2017_08_24_01_03-43cbfad-bin/spark-2.3.0-SNAPSHOT.tgz
빌드된 이미지가 안보이네.. 현재 ubuntu-spark 이미지 에 있는 걸 카피해서 사용해볼수 있을까?
빌드된 이미지가 안보이네.. 현재 ubuntu-spark 이미지 에 있는 걸 카피해서 사용해볼래?
On Thu, Aug 24, 2017 at 7:14 PM, NamHyunE notifications@github.com wrote:
수정 가능하도록 바꾸었습니다. 교수님이 보내주신 링크 이미지파일 사용해 봤었는데 jars 폴더가 없어서 hdfs에 넣어주질 못했었는데 사용 가능한건가요?? https://people.apache.org/~pwendell/spark-nightly/spark- master-bin/spark-2.3.0-SNAPSHOT-2017_08_24_01_03-43cbfad-bin/spark-2.3.0- SNAPSHOT.tgz
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kmu-bigdata/distributed-matrix-completion/issues/13#issuecomment-324594493, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ4TIK5t6m-wyNhEODU_KCfcM9bavjt6ks5sbU0XgaJpZM4O5rJx .
-- Kyungyong Lee (이경용) Assistant Professor Department of Computer Science Kookmin University. Seoul. South Korea.
e-mail: leeky@kookmin.ac.kr homepage: http://leeky.me office: 02) 910-4420 cell: 010-6539-0619
현재 ubuntu-spark는 밑에 있는 ubuntu-hadoop의 변경 사항이 반영되지 않았는데 그냥 사용해도 괜찮을까요??
현재 ubuntu-spark 를 동작시키면 /usr/local/spark 가 있으니 그걸 압축해서, 구글 드라이브 같은 곳에 올려둔 뒤에 스파크 dockerfile 을 수정해서 직접 올려둔 이미지를 사용하라는 이야기.
아.. 그렇게 해보도록 하겠습니다.
교수님 스파크 셋팅을 2.3.0 버전으로 시도했을때는 계속 아래와 같은 에러를 해결하지 못해서 못돌려 보았습니다.
그래서 일단 스파크 2.2.0 버전으로 다시 셋팅해서 spark-shell --master yarn --num-executors 30 으로 스파크 실행시켜 테스트 하던 도중에는 저번과 같은 에러가 발생 했습니다.
그런데 같은 코드를 같은 스파크 버젼에서 spark-shell --master yarn 으로 실행시켰을 때는 에러가 발생하지 않았습니다 (--num-executors 디폴트 값은 2입니다). 결국 --num-executors를 잘못 설정 해줬던 것이 에러의 원인인것 같습니다..
같은 BlockMatrix 2 x 8, 8 x 2에서 block size를 2048로 증가시켜서 더 테스트 해보았는데 spark-shell --master yarn --num-executors 2,4,8,16 으로 실행 시켰을 때는 잘 작동했고 spark-shell --master yarn --num-executors 32로 실행 시켰을 때는 에러가 발생했습니다.
히스토리 서버에서 event timeline를 살펴 보았는데 num-executors값을 증가 시킬수록 scheduler delay시간이 상당히 증가했습니다. 그리고 에러가 발생한 컨테이너 로그를 확인해 보았는데 num-executors값을 증가시킬수록 scheduler delay가 커져 heartbeat interval을 초과해 다른 executor에 문제가 있다고 여기어 exception을 계속 발생 시키는것 같습니다.
다시 BlockMatrix를 4 x 32, 32 x 4크기에 BlockSize를 512로 변경해 num-executors 값을 증가시키면서 테스트 해보았는데 같은 결과였습니다.
결론은 yarn mode에서는 executor 수를 많이 줄수록 scheduler delay가 커져 효율적이지 않은것 같습니다. 그래서 저희 bd-1,2,3 구성을 executor수를 줄이고 executor당 할당되는 리소스를 증가시켜 주는게 좋을것 같은데, 교수님 생각은 어떠신지 알고싶습니다.
음.. 그러지 않을것 같은데.. 지금껏 30개 넘게해서 잘 동작한건 어떻게 설명할 수 있을까? scheduler delay 가 얼마나 크길래 그게 heart beat interval 을 넘어간다고 생각해? 그 둘이 서로를 간섭 한다고 생각이 들지 않고..
Scheduler delay 가 얼마나 길어지는지 확인해봐. 기껏해봐야 수십 msec 이지 않을까 하는데. 만약 정말로 scheduler delay 가 문제라면 그 값이 높아지는 이유를 해결해야 할것 같아. 30대의 executor 도 manage 못한다면 마스터 컨테이너 나 드라이버 에 자원을 더 할당해야 할수도 있고.
아직 그부분 까지는 생각해보지 못했는데 더 알아보도록 하겠습니다..
제가 스케쥴러 딜레이가 문제라고 생각했던 이유는 BlockMatrix를 4 x 32, 32 x 4크기에 BlockSize를 512로 설정해 multiply를 해주었을때 가장 시간이 많이 소요되는 stage8에서 다음과 같이 결과가 나왔기 때문입니다. 1) --num-executors 16인 경우
2) --num-executors 4인 경우
교수님이 말해주신 부분에 대해서도 더 알아보도록 하겠습니다.
지금 보니 scheduler delay 가 수초나 걸리네. 그럼 그것 자체가 잘못된 값으로 보이네. (num-executors 가 4인 경우에도) 정상적인 경우라면 수 msec 이면 충분해야 하거든. 어딘가에서 설정이 잘못된것 같다는 생각이 드네.
만약 해볼 수 있다면, 이전에 잘 동작했던 설정을 그대로 해서 확인해봐. 각 호스트당 다커 인스턴스 갯수를 20개로 하고 node manager 설정도 이전처럼 해서. 그래도 안되면 더이상 디버깅 하기는 어려울것 같으니, 내가 한번 살펴볼께.
넵 그렇게 해보도록 하겠습니다!
교수님 bd-1,2,3 에 예전과 같은 설정으로 셋업했는데도 같은 결과가 발생합니다.. 스파크는 2.2.0버전을 사용하였습니다. --num-executors 2인 경우
--num-executors 4인 경우
--num-executors 8인 경우
--num-executors 16인 경우
응 그러네. 우선 니가 본 문제는 초기에 설정할때 특정 하둡 버전이랑 스파크 버전에서 발생했던 문제인데 또 발생하네..
지금 보니 스파크는 최근에 빌드가 안되서 latest 가 이전에 동작하던 버전인데, 하둡의 경우는 최근에 업데이트된 이미지를 사용하고 있네 (Docker file 에 변경한 코드는 없어도 하둡 2.8 코드가 그 사이에 바뀌어서 다른 점이 있을수도 있을듯).
bd-1,2,3 에 이전에 동작했던 hadoop 을 worked 라는 태그로 해뒀으니 지금 하둡을 중지하고, kmubigdata/ubuntu-hadoop:worked 로 다시한번 만들어서 확인해봐 줄래?
교수님. 아까와 같은 셋팅으로 똑같은 코드를 빌드스크립트 작성해서 클러스트 모드로 실행했더니 정상적인 결과가 나오는 것 같습니다.
spark-submit --master yarn --deploy-mode cluster --num-executors 16 --class SparkMultiplication target/scala-2.11/outer-product-example_2.11-1.0.jar
남현아. 몇번 더 돌려보고 내일 오후에 얘기해볼까? 내 기억에는 가끔 잘되다가 안되기도 했던것 같아서.. 서너번만 더 돌려보자. num-executors 도 30으로 한번 해보고.
네 알겠습니다! 어제도 32로 실행시켜 보았고, 오늘도 num-executors 16,32,64로 주어봤는데 cluster 모드에서는 잘 작동합니다.
good effort!
하둡과 스파크 컨테이너 활용하여 재 설치 필요.
@NamHyunE 이번 이슈에 각 단계를 정리해보자.