이 블로그 검색

레이블이 ssh인 게시물을 표시합니다. 모든 게시물 표시
레이블이 ssh인 게시물을 표시합니다. 모든 게시물 표시

2019년 4월 17일 수요일

시스템 시작시(부팅시) 자동실행된 docker가 바로 실행되지 않는 문제를 어떻게 해결해야 할까??




내가 있는 다체계물리연구실에서 오랜기간 동안, sun grid engine 구축을 노력해왔다. 수많은 시도가 있었지만 tftp를 이용한 diskless grid는 구축을 하지 못했지만,   결국에 유의미한 결과를 얻었다.


Ubuntu내에서 apt로 또는 fedora(오래된 과거)에서 rpm으로는  설치했을 때, 뭔가, 라이브러리의 버전관리 문제가 걸려서 아무일도 일어나지 않는다.


결국은 docker라는 툴을 이용해서, centos를 기반으로 구축을 완료했다.

문제는 각 서버를 재시작할 시, 자동으로 다시 실행되도록 셋팅을 해놓았으나, 그렇지 않는다는 것이다.


네트워크 작업이 귀찮아서, 내부의 docker가 22번 포트를 쓰도록하고, 디바이스는 다른 포트를 사용하도록 해놓은 탓에, ssh로 로그인을 하고, 다시 작업하기는 매우 귀찮다. 그것도 최근에 안 사실이지만 그 작업도, docker 명령을 실행만 하면 되는 작업이다.

이유를 알 수 없지만, docker명령이 최초 실행되기 전까지, docker daemon은 메모리에만 가상 시스템을 올려놓고, 실행은 되지 않고 있다.


지금은 컴퓨터가 작아서 하나씩 들어가서 docker ps 명령을 실행했다지만, 컴퓨터가 많으면 매우 귀찮은 작업일 것이다.

나만 그런가 싶어, 구글링을 해보니 docker에 가장 적합한 CoreOS에도 있는 Bug라고 한다. CoreOS에도 있다는 소리는 그냥 Docker의 버그로 보이며, 어떤 곳에도 원래 그렇게 작동한다는 이야기는 없다.

그래도 각 사람들이 알아서 해답을 찾았고 그 방법을 적용하였다.

그 방법은 정말 간단하다. 그냥 ... systemctl을 이용해 최후단에 단발로 작용하는 데몬 하나를(언어도단이지만)  띄우는 것이다.



[Unit]
After=default.target

[Service]
Type=oneshot
ExecStart=/usr/bin/docker version
RemainAfterExit=yes

[Install]
WantedBy=default.target


이 간단한 것을 생각지 못한다니, 참...유감이다. 

뭐 그렇지만, 이전까지는 왜 docker가 올라와 있는데도 접속이 안되는지에 대해서 고민을 해왔으니, 제대로 문제를 파악한 기간이 짧았던 것으로 변명하면 되지 않을까...

2017년 9월 19일 화요일

클러스터나 슈퍼컴퓨터에서 계산한 파일을 가져오기와 관련한 데이터 압축이야기



나 같은 경우는 MD simuation을 하는데, 얻는 rawdata 중에는 입자의 d.o.f 만큼의 실수 정보와 자기 인덱스와 관련한 정보 등을 text형식인 것이 있다. 

이런 것들이 입자수를 곱하고, 여러 시간의 스냅샷을 포함하다 보면 이 데이터의 양은 참으로 클 수 밖에 없다. 

내 경우에는 이 데이터의 양이 한번 돌릴 때마다, 12GB나 되는 굉장한 양이 나온다.  그 중에 더미가 있어서 실제로는 8기가 가량 되는 것 같다. 

이 데이터를 그대로 네트웍으로 받는다면 기가비트 환경에서 1분정도, 
100메가비트 환경에서 10분정도를 최저로 잡고 소요되나, 같은 건물이 아닌 이상 저 속도가 나올리가 없다.  나 같은 경우는 대략 20메가비트 정도 나오면 잘되는 듯하는 상황이라, 이대로 받아버리면 안정적으로 계속 다운로드가 될 때, 50분이 걸린다.  1분이나 10분 정도는 충분히 잠시 일보고 오는 식으로 소비할 수 있는 시간이다.   그런데 50분이란 시간도 그럴까? 아닐 것이다. 

(문제는 내가 저 시간을 아껴서 제대로 사용하는 사람이고 싶은 사람이지 그런 사람이 아니라는거...)


그렇다면 방법은 압축을 해서 데이터량을 줄인 후, 방법을 사용해야 할 것이다. 그렇다면 어떤 압축툴을 사용해야 할까?  

  보통 보관용과 전송용으로 차이를 둘 수 있겠다. 압축이란건 투자한 시간만큼 공간을 줄일 수 있다. 보관용은 공간을 줄이는데 관심을 가진다. 적당히 시간을 더 투자하고 공간을 적정선까지 줄이는 것이 목표라면 bzip2으로 시작해서 좀 더 극단적인 부분까지 줄이는게 목표라면 xz(or lzma:7zip의 알고리즘 사용)를 사용하게 된다. 

  우리는 전송용이기 때문에 당연히 gzip을 사용하면 되겠다. 리눅스는 Archiving tool과 Compresion tool을 따로 두는식으로 문화가 형성되어 있어서 Archiving tool로는 tar를 사용하고, gzip을 사용하여 압축을 많이 한다. 이렇게 해도 보통 zip(pkzip)보다는 속도나 압축률면에서 우수하다고 한다. (근거달기는 귀찮다. )

대게 tar cvfz 압축파일이름.tar.gz 내역들 

으로 그냥 사용하지만 문제는 data가 워낙 많아서 시간이 많이 필요하다는 거다. 그런데 기본으로 linux 배포판에 있는 gzip은 병렬로 계산하지 않기 때문에 이것도 한 세월 걸린다는 단점이 있다.  (gzip bzip2 xz 모두 그러함)

하지만 이쪽 사람들은 필요하면 만드는 사람들이기에 찾으면 해당하는 툴이 있다.   나같은 경우는 pigz라는 툴을 사용한다. gzip의 이름을 섞어서 말장난 하는 식의 이름이지만 매우 훌륭하다. 압축알고리즘 자체가 병렬화 되는 것은 아니고, 압축을 할 때, 어차피 파일을 특정 사이즈 마다 쪼개서,  압축을 하니까? 쪼개진 부분을 여러 계산유닛들이 기존 알고리즘으로 압축을 하면 되는 방식이다. 

그렇기 때문에, pigz를 컴파일해서 설치하는데는 root 권한 따위는 필요하지 않고, 필요한 라이브러리는 왠만해서는 서버에 있다. 이 친구들이 쓰는 헤더파일이 없으면, 루트가 제공하는 툴말고는 아무것도 못쓸 정도로 환경이 척박하므로 그냥 기대를 말고, 기존 루틴대로 살면 되겠다. 

tar 명령어에 외부 압축프로그램 바로 지정하는 방식을 사용한다면, 
tar -I pigz   -cvf blah.tar.gz blah blah    압축하기 
tar -I pigz   -xvf blah blah blah     압축풀기
이런 식으로 사용하면 되고 귀찮고 하드공간이 넉넉하면 tar로 먼저 묶고 
pigz로 압축 pigz -d로 풀기를 하면 되겠다. 

압축하는 시간이 기존 싱글쓰레드로 8분가량 걸린다면 16노드인 서버에서는 30초 정도로 끝날테니  굉장히 시간을 절약할 수 있다. 

수치해석 rawdata 전용 압축 툴이나온다면 압축률을 더 높일 수 있을 것 같으나, 그런건 없는 것 같고, 대략 압축을 하면 압축률이 42%정도 나온다. 

파일이 작으면 이건 개 뻘짓이지만. 파일이 커서 굉장이 좋은 방법이 되었다. 
기존 방법으로는 통으로 50분이 걸리던지, 아니면 21+압축시간 걸리던 것이 21+압축시간/nodes  로 시간이 확 줄어드어 쓸만해 진다. 

음 대학교가 연구기관이라면 kist 같은 국가 연구기관들과 100Gb 네트웍으로 연결되고 내부망은 최소 기가비트 건물간은 10기가비트로 연결되어야 정상이 아닐까...?

건국대학교는 이과대학이 내부망이 아직 100메가비트이고, 연구기관들끼리 연결된것은 우회망이 없어서인지 이쪽 대역폭을 어떻게 나눠쓰는지 모르겠는데 너무 느리다. 빨리 좀... 어떻게 해주면 좋겠다. 

아 그리고 이런짓을 할 필요 없이, rsync 나 scp에 압축 옵션이 있다. 
그런데 scp는 이어받기 옵션이 없어서 배제 대상이 되고 rsync에 압축옵션을 넣어서 다운받으면 되겠다. 근데 이건 익숙하지가 않아서 전송용으로만 쓰고 있다. 

  그리고 데스크탑을 리눅스로 쓰는 나같은 리눅서는, 이쪽 철학을 지켜서 각 프로그램들의 기능을 최소화하고 서로 연결해서 사용하는 것이 심적으로 편하다. 그냥 이렇게 쓰도록 하자.  

가장 많이 본 글