OVS - ODL Setup.

|

(*본 포스트는 https://wiki.opendaylight.org/view/Installing_OpenDaylighthttps://www.youtube.com/watch?v=rYW7kQRyUvA 를 참고하여 작성하였음.)

1. ODL(Open Day Light)

ODL이 자바기반인 만큼,서버 시스템에 jre가 설치되어 있어야 한다.

apt-get install openjdk-8-jre

위키에는 7버전이 설치되었지만 필자는 8버전에서 실행하였다.

이후 vi ~/.bashrc 를 통해 하단에 export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64 이렇게 자바 path를 설정해 준다.


자바 설정이 끝났다면 실제로 ODL을 구동하기 위한 환경인 OSGI기반의 컨테이너인 karaf를 설치해야 한다. 다행히도, https://www.opendaylight.org/downloads 여기서 karaf와 ODL을 pre-built해놓은 파일을 구할 수 있다. wget 명령어를 통해 받은 후, unzip으로 압축을 풀고 karaf를 실행하면 된다.
필자는 carbon 0.6.0 버전을 사용하였다. 만일 구버전의 링크가 깨져있거나, 후술할 feature부분의 링크가 깨져 있다면 https://nexus.opendaylight.org/ 이곳에서 검색이 가능하다.

정상적으로 실행이 된다면 터미널에서 다음과 같은 화면을 볼 수 있다.



 

karaf console을 통해 여러가지 feature를 설치하면 OVS와의 연동이나, web기반 ODL interface인 dlux를 사용할 수 있다.
일단 feature:install odl-l2switch-switch-all odl-dlux-all odl-restconf odl-aaa-authn odl-mdsal-apidocs 커맨드로 필요한 feature를 설정한다.


2. OVS(Open Virtual Switch)

이제 가상 스위치인 OVS를 설치해보자. 설치는 간단히 apt-get install openvswitch-switch로 가능하다.
이제 ovs-vsctl add-br mybridge(임의로 정한 스위치 이름)로 가상 스위치를 생성하고, ifconfig mybridge up을 통해 인터페이스를 활성화시킨다. 그렇다면 시스템의 토폴로지는

이렇게 구성된다.

아직 사용자(IP Stack)은 ovs를 통해 바깥 네트워크와 이어져 있지 않은 상태다.여기서 eth0와(리눅스 버전에 따라 ens33일 수도 있다.) ovs를 이어주기 위해서

ovs-vsctl add-port mybridge ens33 을 실행한다.
그리고 ifconfig ens33 0 , dhclient mybridge 를 실행하면 IP Stack이 바깥 네트워크로 나갈 때

이런 경로를 거치게 된다.


3.OVS와 ODL 연동

 

ovs상에서 ovs-vsctl set-manager tcp:"서버ip":"포트" (0.6.0 기준 포트는 6653이다)
ovs-vsctl set-controller tcp:"서버ip":"포트"
를 실행해 컨트롤러와 ovs를 이어준다.

잘 수행됐다면, ovs-vsctl show를 통해 다음 정보를 볼 수 있어야 한다.

is_connected 필드가 true값이 되어야 하고,

 

status에 state가 ACTIVE값이어야 한다.


여기까지 모든 과정이 정상적으로 이뤄졌다면, 이제 웹 인터페이스인 dlux가 동작해야 한다.

서버아이피:8181/index.html (이전에는 /dlux/index.html이었지만 ODL 버전이 올라가면서 URL이 바뀌었다.) 로 접속하면

 

다음과 같이 연동한 OVS가 보이면 연동 성공이다.

 

 

신고

'ComputerEngineering > Network' 카테고리의 다른 글

TSPEC  (0) 2017.08.10
[추가중] OVS command  (0) 2017.02.13
OVS - ODL Setup.  (5) 2017.02.13
BitTorrent  (0) 2016.12.16
TCP  (0) 2014.05.09
Transport Layer  (0) 2014.04.27
trackback 0 And Comment 5

VMware에서 창크기 조절로 해상도가 자동조절(autofit)이 되지 않을 때.

|

 

 

버추얼박스면 자동으로 되지만, VMware를 사용하면 VMware Tools를 설치해주어야 한다.vmware Workstation을 사용하면 view에서 바로 조절할 수 있지만, Player버전이라면 설치해야한다.

Update Vmware Tools를 누르고, VMware하단에 install하라는 안내가 뜨면 install을 누르고, dvd에 삽입된 이미지에서 tar.gz 압축을 푼 후 vmware-install.pl을 실행해 설치를 해준 후 재부팅하면 끝.

 

 

신고
trackback 0 And comment 0

BitTorrent

|

BitTorrent(이하 토렌트)는 P2P 방식의 파일 교환 프로토콜이다. 이 프로토콜의 가장 큰 특징은 파일을 다운받는 유저들(leecher)이 다운로드의 주체이자 곧 업로드의 주체라는 점이다. 한줄로 토렌트의 기능을 요약하자면, "BitTorrent는 파일을 piece단위로 나누고, peer끼리 서로 이를 교환해 마침내는 모든 piece를 전송받아 파일을 완성한다."라고 말할 수 있다.개념도를 통해 설명해보자면,


 한 파일을 piece라는 segment 단위로 조각내고, 모든 조각을 소유한 유저(seeder)와 그렇지 못한 유저(leecher)끼리 piece를 주고받으며(이렇게 한 파일을 주고받는 유저(peer)들의 파일 공유 집단을 swarm이라고 한다.) 결국에는 leecher가 모든 piece를 모아 파일을 완성시킨다.유저와 서버가 1:1 관계가 아닌 유저와 유저들이 N:N 관계를 맺으므로 Multisource downloading이라 할 수 있다.서버와 클라이언트가 1:1로 파일을 주고 받는 것과 다르게, 토렌트에서 서버라고 할 수 있는 트래커는 단지 swarm안에서 peer list를 통해 seeder와 leecher를 중개해 주기만 할 뿐,파일을 갖고 있거나 전송해주지는 않는다.(최근에는 distributed hash tables,DHT를 통해 trackerless system을 지원하는 클라이언트도 있다.) 따라서 서버에 큰 부담을 주지 않고,낮은 대역폭의 네트워크 환경에서 효과적으로 작동할 수 있다.단, 이러한 방법은 고전적인(HTTP나 FTP 요청같은) 방식에 비해  빠른 속도,즉 충분한 peer를 확보하는데 시간이 걸릴 수도 있다.



(그림 출처 : http://davidhales.name/posters/patarin-hales-delis-poster6.pdf)

파일 배포의 시작은 torrent(확장자 명 - 이하 seed 파일) 라는 메타 데이터 파일을 생성하는 것부터 시작하는데, 이 파일은 파일을 몇 piece로 나눌지,(보통 piece의 크리는 256KB다. piece 크기가 작아지면 다른 peer에게 받을 수 있는 piece의 양이  늘어 swarm 내의 piece교환양이 많아져 성능이 증가하지만, piece의 증가에 따라 hash값도 같이 증가하므로 torrent 파일의 크기도 증가한다.)그리고 그 piece에 대한 해쉬 정보(SHA1), 파일의 이름, 트래커의 URL 등의 정보를 담고 있다. torrent파일은 B-Encode 방식으로 인코딩 되어 있다.

이 파일을 파일의 원 소유자(최초의 seeder)가 Internet에 파일을 올리면, 다른 유저들은 해당 파일을 다운로드받아 BitTorrent 클라이언트에서 다운로드를 시작할 수 있다.(연결은 TCP로 이루어진다.)조각들은 비순차적으로 다운로드되고, bitTorrent 클라이언트에서 다시 순서대로 정렬된다.다른 peer에서 piece를 수신하면 해당 piece의 해시를 seed의 해시 값과 비교해 오류 검증을 한다.
여기서 트래커는 peer에게 다른 peer들의 ip와 포트를 리턴해주고, peer들이 전송해주는 정보로 업로드와 다운로드를 모니터링, 존재하지 않는 peer들은 list에서제거하기도 한다.




파일을 piece로 쪼갠 후, 어떤 조각을 다른 peer에게 요청하는가, 즉 piece selection에 관해서는 4가지 정책이 있다.(swarm의 piece다양성이 증가하면 perfomance가 증가하므로, 이는 꽤 중요한 문제다.)

1.Strict Prioirity : 일단 piece에 대한 부분(BitTorrent 에서는 piece를 다시 sub-piece로 쪼갠다)이 요청되면,해당 piece의 나머지는 다른 어떤 piece보다 우선적으로 요청된다. 이 정책은 가능한 빠르게 완전한 조각을 확보하는데 도움이 된다.

2.Random First Piece : 다운로드가 막 시작되었을때, 해당 peer는 갖고 있는 piece가 없기 때문에 다른 peer와 교환할 piece가 없고,이는 곧 tit-for-tat 전략(밑에서 설명)에 의해 다운로드 속도 저하를 초래한다. 따라서 가능한 빠르게 완전한 조각을 확보해야 한다.

3.Rarest First : 일단 처음 piece를 확보하면, peer는 다른 peer들이 가진 piece중 가장 적은 peer가 갖고 있는 piece를 요청한다.이는 피어가 다른 피어들이 원하는 조각을 갖고 있게 해주고,다른 피어들로부터 꾸준하게 관심을 받을 가능성을 높혀준다.또한 piece의 다양성을 높여 peer들이 서로 교환하는 것이 아니라 seeder에게만 piece를 받는 현상(즉 seeder의 전송 부하)를 줄여준다. 추가로, Rarest First 전략은 seeder가 떠날 때 특정한 조각이 부족해서 완전한 파일이 swarm안에 존재하지 않는 상황을 어느정도 방지해준다.

4.Endgame Mode : 종종 어떤 piece가 매우 느리게 전송될 수 있다.이는 파일의 다운로드 완료를 delay시키기 때문에, 이를 방지하기 위해 어떤 sub-pieces가 모자랄 경우,  모든 peer에게 해당 sub-pieces에 대한 request를 보낸다. 대역폭 낭비를 막기 위해 해당 sub-piece의 다운로드가 완료되면, cancel 메세지를 보내 완료한 조각에 대해 전송 요청을 취소한다.실제로는 이 구간이 짧고 신속하게 넘어가므로 그렇게 큰 대역폭의 낭비는 이루어지지 않는다.


토렌트에서는 다운로드/업로드가 유저들끼리 이루어지기 때문에,이른바 hit-and-run, 즉 업로드는 하지 않으면서 다운로드만 받는 유저들(free-rider)이 문제가 될 수 있다.이를 해결하기 위해 나온 전략이 바로 tit-for-tat(우리말로 하자면 눈에는 눈) 전략이다.이를 설명하기 위해 파레토 효율(쉽게 말하면 서로 win-win하는 전략)이나 죄수의 딜레마같은 경제학 용어가 등장하지만 생략하고 요점만 말하자면, 상대가 나에게 업로드를 해주면(즉 나에게는 다운로드) 나도 상대에게 업로드를 해주고(상대의 다운로드),그렇지 않다면 나도 업로드를 해주지 않는 것이다. 모든 peer가 이 정책을 지킨다면, 업로드를 하지 않는 peer는 결국 아무에게서도 다운로드를 할 수 없는 고립상태에 빠지게 될 것이다.이 정책은 free-rider들의 발생을 방지하면서 peer들끼리 협력하는 분위기를 유도할 수 있다.

이제 문제는 어떤 peer에게 업로드를 제한/지속할 것이냐-로 넘어간다. 어떤 peer에게 업로드를 중단하는 것을 choke, 다시 재개하는 것을
unchoke라고 한다.토렌트에서는 기본적으로 4개의 피어를 unchoke해놓는다.
(설정에서 바꿀 수도 있다. 이 개수를올리면 swarm쪽에서는 peer간의 업로드 수와 양이 늘어나 전체적으로 보면 업로드 속도가 늘어나게 된다.단, 모든 피어들이 동일한 개수의 unchoke peer를 가지는 것이 아닌 경우, 적은 쪽의 peer가 더 빠른 다운로드 속도를 보인다. 그 이유는 업로드 대역폭을 더 작은 수의 peer에게 할당함으로써 다른 peer에게 선택될 확률이 높기 때문이다.)
peer는 자신에게 업로드하고 있는 peer 중 가장 업로드 기여가 큰 4 peer를 골라 unchoke하게 되고,비 협조적인 peer들은 choke한다.이 결정은 평균적으로 20초동안 현재 다운로드 rate를 보고 이루어진다.choke를 한다고 해서 다운로드가 바로 끊어지는 것은 아니며, 단지 업로드만 중지될 뿐이다. 따라서 재연결을 위해 자원이 쓰일 필요는 없다.
물론, 현재 unchoke된 peer들이 현재 연결된 peer들보다 더 나은 업로드 rate를 보여줄 수도 있기 때문에, 토렌트에서는 다른 peer가 얼마나 업로드를 해주는 지와는 관계없이 unchoke를 해준다.이를 optimistic unchoking이라고 한다. 이는 매 30초마다 무작위의 peer에게 이뤄진다.
만일 해당 peer가 더 좋은 업로드 rate를 보여준다면,해당 peer가 새로운 4개의 peer로 합류하게 될 것이다.

모든 peer들에게 choke당하는 상황이 올 수도 있다. 만약 이렇게 되면 해당 peer는 저조한 다운로드 rate가 지속될 것이다.이런 상황에서 더 나은 peer들을 찾기 위해서, 일단 60초동안 어떤 sub-piece도 받지 못한다면 해당 peer에게 "snubbed"되었다고 간주하고 optimistic unchoke를 제외하고는 choke를 풀지 않는다.그리고 optimistic unchoke의 개수를 하나에서 여러개로 늘린다.

다운로드가 완료되고 나면(seeder),더이상 높은 다운로드 rate를 요구하지않게 된다. 따라서 swarm에 긍정적인 영향을 주기 위해서, 다른 peer들에게(자신을 포함한)업로드 rate가 높은 peer를 택해 해당 peer에게 업로드를 해준다.(업로드를 성실히 하는 peer들이 빨리 파일을 완성할수록 swarm의 전체 업로드 속도는 증가하므로)



신고

'ComputerEngineering > Network' 카테고리의 다른 글

[추가중] OVS command  (0) 2017.02.13
OVS - ODL Setup.  (5) 2017.02.13
BitTorrent  (0) 2016.12.16
TCP  (0) 2014.05.09
Transport Layer  (0) 2014.04.27
개요  (0) 2014.04.26
trackback 0 And comment 0
prev | 1 | 2 | 3 | 4 | 5 | ··· | 43 | next