Project Euler Problem #1


1000보다 작은 자연수 중에서 3 또는 5의 배수를 모두 더하면?


10보다 작은 자연수 중에서 3 또는 5의 배수는 3, 5, 6, 9 이고, 이것을 모두 더하면 23입니다.

1000보다 작은 자연수 중에서 3 또는 5의 배수를 모두 더하면 얼마일까요?



Source Code (Github)



본 문항은 Project Euler 사이트에 영문으로 수록된 것을 한글로 변역한  Project Euler @ kr의 문항입니다. 

PyCharm을 활용한 파이썬 개발환경 구축

1. Python 다운로드 및 설치

- PyCharm IDE 설치에 앞서 파이썬을 먼저 설치해준다. Python 공식 다운로드 페이지에서 각자 머신에 맞는 릴리즈 및 버전으로 다운받아 설치한다.


2. PyCharm IDE 다운로드 및 설치

- 위에서 Python을 정상적으로 설치한 후에 JetBrain 홈페이지에서 PyCharm을 다운로드 받고 설치해주자. Community 버전이 무료로 제공되는 버전이다.


3. PyCharm 다운 및 설치

- PyCharm 설치가 완료 후, 실행해보자. 그러면 몇 가지 설정을 위한 선택사항이 나오는데 기본값으로 OK 또는 Accept을 눌러서 실행하자. 모든 설정을 마친 후 나오는 화면은 아래와 같다.

4. 프로젝트 생성 및 실행

- Python과 PyCharm이 설치되었다면, 간단한 프로젝트를 생성하고 실행함으로써 정상적으로 동작하는 지 확인하자. 아래는 간단한 'Hello World!'를 작성하고 실행시킨 결과화면이다.


IETF 미러포럼 기술 워크샵

IETF 기반 가상화 네트워크 및 응용기술



 08월 24일 수요일에 강남역에서 진행된 IETF 미러포럼 기술 워크샵이 시작되었다. 워크샵이 IETF 미러인만큼 최근 동향 및 제안되고 있는 블루프린트 및 새롭게 런칭되는 프로젝트에 대한 얘기가 주를 이뤘다. 특히, OPNFV와 관련하여 진행되는 프로젝트 및 주요 사항들에 대해서 조사 및 연구한 내용을 국내에 전파해주는 방식의 워크샵이었다. 1일차에는 숭실대, 고려대 교수 및 학생들이 발표를 진행했으며, 2일차에는 광주과학기술원 학생 역시 발표를 진행할 예정이다.


 첫 째날에 진행된 발표 내용 중에서 완벽히 이해되는 부분은 상당히 적었다. 커다란 컨셉들은 들어본 적은 있었지만 세부적으로 어떻게 디자인되고 있는지 모르는 내용이 대다수였기 때문에 이해하기 어려웠다. 해당 워크샵의 발표를 이해하기 위해서는 네트워크 동향 및 기술 변화에 대한 상당한 수준의 배경지식이 요구되었다. 그럼에도 불구하고 워크샵 참석에 의미가 있었던 부분은 새롭게 런칭하는 프로젝트가 무슨 일을 하는 것인지 일목요연하게 정리된 자료들을 볼 수 있었으며, 그간 무슨 그룹인지 몰랐던 OPNFV에 대해서 보다 자세하게 알 수 있었다는 점이다.


 OPNFV는 그간 NFV 사용 및 운용에 있어서 필요한 부분(Gap)을 확인하고, 해당 부분을 충족할 수 있는 방법에 대해서 프로포절 및 구현을 한 뒤 지속적으로 적용가능한 지 테스트 해주는 데에 비중이 크다. 아직 승인되지 않았지만 프로포절된 프로젝트까지 포함해서 약 50여개의 프로젝트가 운용될 예정이며, 모든 프로젝트가 어떻게 진행되는 지 쫒는 것은 불가능하다는 설명이다. 해당 워크샵에서도 많은 프로젝트 중에서 숭실대 연구실에서 주안점을 두고 보고 있는 다섯 개 정도의 프로젝트에 대해서 소개하는 자리를 가졌다.


 워크샵 발표 중 교수가 진행하는 내용은 상당히 트렌디하여 디테일하기보다는 전반적인 큰 그림을 설명하는 경우가 잦은 편이다. 따라서 상당한 배경지식이 있어야만 그 내용을 온전히 내 것으로 만들 수 있을 것 같다. 그러나 고려대 백상헌 교수님께서 진행하신 SFC에 대한 부분에서는 상당히 디테일한 디자인을 설명하고 있는 덕분에 듬성듬성일지라도 이해할 수 있었다. 그럼에도 크고, 작은 프로젝트에 대해서 디테일하게 설명하는 학생들의 발표 자료 및 내용이 쉽게 이해되는 편이다.


 전반적으로 온전하게 발표 내용을 내 지식으로 만드는 것에는 한계가 있었지만, 미려하게나마 네트워크 기술 트렌트의 냄새라도 쫒아가 본 경험을 할 수 있었다. 2일 차에서는 내가 앞으로 연구해야하는 OpenStack에 대한 발표를 연구실 선배들이 진행한다. 내일 오전이라도 집중해서 내 지식의 경계가 한 층 넓어지는 계기가 되길 희망한다.









Summer Workshop on Computer Communications

하계 컴퓨터통신 워크샵 2016



 올해 7월 초, 제주에서 진행한 KCC(Korea Computer Congress) 2016에 오픈소스 프로젝트인 I/O Visor를 토대로 논문을 작성해서 참석한 기록이 있다. 당시 제출했던 논문의 내용을 확장하고, 하나의 서비스로써 구축했던 내용에 대해서 논문으로 정리했고, 그 내용을 토대로 8월 말에 SWCC 2016 워크샵에 참석하게 되었다.

 당시 제출했던 논문의 제목은 리눅스 커널 네트워킹과 연계된 가상 스위치 플로우 모니터링의 실증 및 가시화로써 오픈소스 소프트웨어인 I/O Visor, InfluxDB 그리고 Grafana를 통해 네트워크 패킷을 캡쳐하고, 데이터베이스에 넣고, 사용자에게 유용하도록 시각화해주는 서비스를 정리한 내용이다. 개인적으로는 이번 논문에서 다루고 있는 애플리케이션은 혼자서 다양한 오픈소스 소프트웨어들의 핵심 기능을 엮어서 하나의 서비스를 구현했다는 점에서 의의가 있다고 생각한다. 논문에 대한 얘기는 여기까지 하고, SWCC 2016 참석한 후기를 남겨본다.

 워크샵 참석은 연구실에서 나와 교수님만 참석했다. 혼자서 학회를 간다는 것은 상당히 고려해야할 점이 많다는 것을 이번 기회에 새삼느끼게 되었다. 특히 장소가 강원도 홍천에 있는 오션월드였는데, 준성수기인 덕분에 숙박 가격이 너무 비싸서 차마 이용할 수 없었다. 학교측에서 지불해주는 숙박비에 두 배를 넘는 가격에서 맘 편히 잠들 기분은 아니었다. 혼자가 아니었더라면, 다같이 한 방에서 자고, 숙박비를 나눴더라면 이용해볼만 했겠으나 그럴 사람이 없다는 게 조금 섭섭하더라. 그리고 장소가 오션월드인만큼 주변을 돌아보면 워터파크에 놀러온 연인과 가족들로 바글바글했다. 이런 곳에 노트북과 발표자료를 들고 두리번 거리고 있는데 군중 속에 고독이 따로 없었다.

 장소에 대한 불만에 이어서 한 가지 더 불평, 불만을 늘어 놓자면 KCC 2016에 비해서 너무 학생 논문의 퀄리티나 발표자의 수준이 떨어진 것을 체감할 수 있었다. 발표에 대해서 준비를 안한 것도 확연히 보였고, 이들 사이에서 발표를 열심히 준비해야겠다는 생각을 유지하는 것은 쉬운 일이 아니었다. 전체 워크샵에 37편의 학생논문이 게재되었는데 너무나 대충 대충 넘어가는 발표 탓에 듣는 시간 조차 아까울 정도였다. 주최측의 진행조차도 매끄럽지 않았다. 애초에 공지로 내려왔던 17~20분의 발표시간은 당일 행사 지연으로 인해 10분 발표로 축소되었다. 준비조차 안하는 학생들과 이런 학생들을 배려(?)하는 듯한 발표 시간 축소는 너무나 실망스러운 조합이었다. 

 그래도 좋았던 점은 특별 세션의 내용이 상당히 유익했다는 점이다. 비록 수학에 약한 탓에 수식이 난무하는 슬라이드는 이해하기 어려웠지만, 그래도 맥락을 이해할 수 있었다. 상당히 언변이 좋은 교수님들이 많았고, 전달력이 좋았던 덕분에 모바일 클라우드, 머신러닝 등 익숙하지 않은 분야에 대한 정보를 얻을 수 있는 기회였다. 특히 첫 번째 발표였던 UNIST 김효일 교수님의 '모바일 클라우드 환경에서의 QoE 기반 Computation Offloading 기법' 발표와 둘 째 날 진행되었던 노영균 교수님과 이재성 교수님의 머신러닝/딥러닝에 대한 기초내용이 흥미로웠다.

 워크샵의 큰 파이를 차지하는 학생논문 및 발표에 대해서는 전반적으로 실망스러운 행사였지만, 특별 세션에서는 배울 점이 많은 유익한 시간이었다. 내년에는 이런 부분을 보완하여 보다 탄탄한 행사가 되기를 희망한다.





SWCC 2016 3단 리플렛.pdf


 이전에는 gcc 컴파일 시 발생하는 경고에 대해서는 무시했었다. 에러가 아닌이상 돌아가는 경우가 많았으니까. 그러나 이제는 그 원인 하나하나에 해결해서 깔끔하게 아무런 경고 메세지가 출력되지 않는 것을 추구하고 있다. 이런 이유에서 자주 무시하고, 해결 방법을 알아보지 않았던 경고 메세지 하나를 소개하고, 해결 방법을 적어본다.


unsigned int의 출력을 위한 포맷: %zu


 


 위 경고 메세지가 발생한 원인은 sizeof 함수에 있다. 소스코드를 굳이 포함시킬 필요가 없어서 배제했으나, 그 코드 내에서는 구조체를 선언하고, 그 구조체의 크기를 출력하기 위해 sizeof 함수를 사용했다. 사이즈를 %d 포맷으로 출력을 시도하는데, 이 때 경고 메세지가 발생한다. 이를 해결하기 위해서는 sizeof 연산의 출력을 위한 포맷으로 %zu를 사용하면 된다. 아래의 코드를 참조하자.


printf("size: %zu\n", sizeof(pos1));


 간혹 리눅스 터미널 환경에서 C언어로 코드를 작성하다보면, 뜻밖의 상황에서 에러를 맞이하게 된다. 비록 치명적이지 않고 간단한 에러임에도 불구하고, 매번 발생 원인을 잊고서 구글에 검색하는 경우가 잦은데, 이런 상황을 모면하고자 생기는 문제점을 기록하려한다. 간단한 문제인 만큼 추후에 기억하기 쉽고, 내 블로그를 참조할 누군가를 위해 간단하고 간략하게 작성할 참이다.



gcc 컴파일 시 <math.h> 헤더 파일 링크가 안 될 경우


 


 코드상에 별다른 문제가 없음에도 헤더파일 인식이 안되서, 위와 같은 에러가 발생하는 경우가 있다. 필자의 경우 <math.h>를 포함시켰는데도 불구하고 sqrt 함수가 정의되지 않았다고 나온다. 이는 <math.h> 헤더 파일에만 해당하는 경우는 아니므로, 정상적으로 코드 내 헤더 파일을 include 시켰음에도 특정 라이브러리 호출이 안된다면, 아래와 같은 명령어로 해결하자.


gcc -o "filename" "filename.c" -lm


 동일한 gcc 컴파일 명령어 뒤에 -lm을 추가함으로써 해결할 수 있다. gcc 컴파일러는 디폴트로 mathematical 라이브러리를 링크할 당시 포함시키지 않는다고 한다. 따라서 -lm 명령어를 통해 추가해줘야 한다.

 이번 포스팅은 C언어에서 자주 사용되는 문자열 관련 함수에 대해서 정리를 하려고 한다. Java 함수와는 다르게 유독 C언어 함수에 대해서는 자주 쓰는 것들도 암기가 잘 안되고, IDE를 통해 개발하기 보단 vim을 통해 작성하다보니 자꾸만 인터넷 검색을 하게된다. 물론 모르는 내용을 구글링을 통해 알아가는 것은 당연하지만, 반복적으로 같은 정보를 기억하지 않고 검색에만 의존하다보니 시간도 많이 잡아먹는 것 같아, 이 기회에 한 번 정리하고자 마음먹었다.



1. putchar, fputc, getchar, fgetc


 위 함수들 모두 문자열이 아닌 '문자'를 입력하고 출력하는 함수들이다. putchar와 fputc는 출력 스트림을 표준 출력으로 할 지, 아니면 사용자가 지정할 것인지의 차이를 보인다. 이 점과 마찬가지로 getchar와 fgetc의 차이 역시, 입력 스트림을 표준 입력으로 할 지, 사용자가 지정할 것인지의 차이가 있다. 특이점은 리턴 타입이 int이므로 이점을 기억하여 사용해야 한다. 그리고 getchar의 경우 버퍼에 남아있는 개행 문자를 처리할 때도 사용한다는 점을 기억하자. 


 해당 함수를 이용할 때 알아두어야 할 내용 중에 하나는 EOF에 관한 것이다. End of File의 약자로, 파일의 끝까지 와서 더이상 읽어들일 내용이 없다는 뜻이다. 키보드 입력의 경우 Ctrl+D, Ctrl+Z 입력이 EOF를 의미하게 된다. 실제로 위 두 함수에서 반환하는 EOF는 -1로 정의된 상수임을 잊지 말자.



2. puts, fputs, gets, fgets


 위 함수 중 문자열 입력 함수인 gets, fgets가 scanf 함수와 보이는 가장 큰 차이점은 공백이 있는 문자열을 입력받을 수 있다는 점이다. 더불어, puts, fputs의 차이 및 gets, fgets의 차이점은 위에서 언급한 입/출력 스트림을 지정할 것인가, 아니면 표준 입/출력 스트림을 사용할 것인가의 차이다. 추가적으로 puts 함수는 자동으로 개행을 진행하지만, fputs 함수는 자동 개행을 하지 않는다. gets 함수를 사용함에 있어서 미리 마련된 배열의 길이를 넘어서는 문자열이 입력되면, 할당되지 않은 메모리 영역을 침범할 수 있는 우려가 있다. 따라서 가급적이면 fgets 함수를 사용하는 것이 유익하다. 그러나 fgets 함수에도 주의해야 할 점이 있다. fgets 함수를 사용하면 특정 사이즈만큼 입력받을 수 있는데, 문제는 맨 마지막에 Null 문자를 포함하기 때문에 지정한 크기보다 하나 작은 길이만큼 읽어들인다. 또, fgets 함수는 개행 문자를 만날 때까지 문자열을 읽어들이는데, 개행문자까지 문자열에 포함시킨다.



3. fflush


 출력 버퍼를 비우는 함수. 출력 버퍼를 비운다는 것은 출력 버퍼에 저장된 데이터가 목적지로 전달되는 것을 의미한다. 그러나 입력 버퍼를 비운다는 것은 전혀 다른 내용이다. 입력 버퍼의 비움은 곧 데이터의 소멸을 의미한다. 특히 입/출력 동작중에 유독 엔터-키로 인해서 개행문자가 삽입되는 바람에 출력이 원하는 형태로 되지 않는 경우가 있는데, 위에 1번에서 언급했던 것과 같이 getchar 함수를 활용하면 이런 문제를 해결할 수 있다. 아래의 함수를 참조하자.


void EmptyOutputBuffer(void) {

while(getchar != '\n');

}



4. strlen


 문자열의 길이를 출력해주는 함수다. 반환형이 unsigned int를 대변하는 size_t 타입이라서 출력할 때 경고 메시지가 뜨는 경우가 다분하다. %d가 아닌, %zu 형식을 사용하면 해결된다. 뒤에 따라오는 개행문자를 제거하고, 순수하게 유효한 문자열만 입력받는데 사용되기도 한다. 아래의 함수를 참조하자.  strlen 함수를 이용하여, 문자열의 길이를 파악한 후 맨 마지막 문자열을 개행문자에서 Null로써 대체하고 있다.


void PureString(char str[]) {

int len = strlen(str);

str[len-1] = 0;

}



5. strcpy, strncpy


 문자열 복사에 사용되는 함수다. strncpy는 특정 길이를 명세하여, 명세된 길이까지 복사한다. 그러나 이 함수를 사용하기 위해서는 주의해야할 점이 있다. strncpy 함수는 딱 정해진 크기만큼 복사하는데, 그 안에 Null 문자를 포함하지 않을 수 있다. 따라서 출력 해보면 이상한 메모리 위치에 접근하여, 원하는 출력이 안될 수 있다. 따라서 해당 함수를 사용할 때는 아래 코드처럼 우회해서 사용하는 편이 안전하다. 아래처럼 문자열의 마지막 위치에 강제적으로 Null을 삽입될 수 있도록, 하나 작은 값까지 복사를 진행하자.


strncpy(str2, str1, sizeof(str2)-1);

str2[sizeof(str2)-1] = 0;



6. strcat, strncat


 문자열을 이어붙여주는 함수다. 기억할만한 점은 앞 문자열의 Null 문자 위치부터 덧붙여진다는 점이다. 따라서 사용자는 한 문자열에 두 개의 Null 문자가 생길 수 있는 가능성을 무시하고 사용할 수 있다. strncat의 경우, 덧붙일 문자열의 크기를 지정할 수 있는데, 해당 크기에는 Null 문자가 포함되어 있지 않다. 만약 10을 인수로 전달했다면, 10개의 문자열과 Null 문자열이 덧붙여져서 총 11개의 문자가 추가된다.



7. strcmp, strncmp


 두 문자열이 동일한 지, 아닌지를 판별할 때 사용한다. 같으면 0을 반환하고, 0이 아니면 다른 문자열이라고만 기억해도 충분할 것 같다. strncmp를 사용할 일은 거의 없을 것 같다. 



8. atoi, atof, atol


 문자열을 int, double, long으로 변환해주는 함수. 앞서 소개한 함수들은 <string.h>에 선언된 함수지만, 이 함수들은 <stdlib.h>에 선언되어 있다.



9. 마치며...


 위 함수들은 개발함에 있어서 정말 자주 사용되는 함수들이다. 반환형이나 인수 타입을 암기해서, 검색하는데 소모되는 시간을 절약하도록 하자. 특히 각 함수들이 가지고 있는 기본 기능외에 기억해야할 점이 있다. 대부분 개행문자와 관련된 점 또는 Null 문자와 관련된 점인데, 이런 부분을 정확하게 숙지해야만 문자열 입/출력을 다루는 데 문제 없이 능숙하게 처리할 수 있을 것 같다.



10. 참고


 열혈 C 프로그래밍 [윤성우 저]










 종강하면서 연구실에서 다루고 있는 연구 주제로 오픈소스 가상 스위치인 Open vSwitch의 내부 프로젝트인 OVN(Open vSwitch Virtual Network)에 대해 공부하게 되었다. OVN의 가장 대표적인 기능은 피지컬 머신들의 토폴로지의 상관없이 통신할 수 있도록 각 호스트간의 Overlay된 연결을 제공하는 것이다. 이런 기능을 제공하기 때문에, 기능 테스트를 위해서는 다수의 피지컬 머신을 갖춰야만 했고, 이 부분이 테스트하는데 귀찮고, 까다로운 부분이었다. 물론 연구실에 남는 데스크탑을 토대로 구축하면 됐을 일이지만, 연구실에서 보유 중인 데스크탑을 사용해봤으나 상태가 썩 좋지 않았다. 자연스레 VM 쪽으로 눈을 돌리게 됐다. VM을 사용한 테스트 환경 구축은 데스크탑을 일일히 가져와서 선을 꼽고, 준비하는 것에 비하면 너무 간편했다. 그러나 하이퍼바이저를 활용하여 로지컬한 머신을 생성하고, 생성한 머신에 OS를 설치하고, 다시 테스트에 필요한 소프트웨어를 설치하는 과정을 반복적으로 수행해야 한다는 점이 여전히 불편함으로 남았다. 그래서 이번에는 더욱 편하게 VM을 Provisioning 할 수 있는 방법에 대해서 알아보게 되었고, Vagrant를 알게되었다.


 아래는 Windows10 64bit 버전의 OS 환경에서 하이퍼바이저(VirtualBox)를 활용하여 Ubuntu-14.04.3 64bit 서버 VM 환경을 구축하는 내용을 다루고 있다.




1. Vagrant?


 Vagrant는 가상화 기술을 사용자로 하여금 쓰기 쉽고, 편하게 하여 개발 환경을 손쉽게 구축해주는 도구다. Vagrant를 활용하면 다양한 테스트 및 개발에 필요한 환경을 빠르게 구축할 수 있다는 점이 가장 큰 장점이다. 따라서 다양한 개발환경에서 기능 테스트를 수행하거나, 이전에 제작했던 시스템의 환경과 동일한 환경을 재현하는 데 사용될 수 있다. Opencloudengine의 Wiki에서는 다음과 같이 Vigrant의 이점을 설명하고 있으나, '빠르고, 간편한 VM Provisioning'으로 요약할 수 있겠다.

    • 과거 구축했던 개발 및 운영 환경을 즉시 재현할 수 있다.
    • 개발자가 만든 VM 이미지를 다른 개발자들과 공유할 수 있다.
    • VM 구성 및 배포를 커맨드 몇 번만으로 빠르게 진행할 수 있다.
    • 개발자가 구성한 VM을 서버에서도 그대로 사용할 수 있다.
    • VM 공유 기능을 제공한다.
    • 설치가 매우 쉽다.
    • 소프트웨어 구성 비용이 없다.
    • 유지보수 비용을 최소화할 수 있다.

 그러나 Vigrant는 오픈스택과 같은 Cloud IaaS를 구성하지 않는다. Network, Storage, Compute 가상화를 포함하는 가상화 기술을 제공하지는 않는다. 또한 그럴싸한 Web UI 제공이 안되며, VMware를 기반으로 사용하기 위해서는 유료 플러그-인을 구매해야하는 점이 있다.


2. Vagrant 사용과 Box에 대한 이해


 Vagrant 사용에 앞서 선행되어야 할 부분이 일부 있다. 먼저 하이퍼바이저 VirtualBox를 다운받아서 설치하도록 하자. 그 다음 마찬가지로 Vagrant 공식 페이지에서 제공하는 파일을 OS에 맞게 다운받아 설치하도록 한다. (필자는 Windows10 환경에서 진행했다.) 이렇게 두 개의 설치만 진행되면 사용을 위한 준비는 끝났다.


 이제 명령프롬프트를 켜서 아래의 두 명령어를 치면 VM이 자동적으로 설치된다. Vagrant 공식 페이지에서 제공하는 문서에서는 Root 디렉토리에 새로운 폴더를 만들어, 그 안에서 아래의 명령어를 수행하는 것을 권장하고 있다. 아래의 화면처럼 나온다면 설치가 정상적으로 진행된 것이다. 아마 대부분 눈치챌 수 있듯이, init 명령어 뒤에 들어가는 인수에 따라 어떤 버전의 OS로 설치할 지 결정한다. 각각의 OS를 담고 있는 이미지를 BOX라고 칭하는 데, 본 포스팅에서는 Ubuntu-12.04 64bit 버전인 precise64로 VM을 생성하고 있다.


vagrant init hashicorp/precise64

vagrant up




 앞서 말한 것과 마찬가지로 vagrant init 명령어는 뒤에 작성된 URL로부터 VM 세팅을 위한 템플릿을 가져온다. https://atlas.hashicorp.com/boxes/search에 접속해보면, vagrant에서 제공하고 있는 OS별, 구성요소별로 Box 설정을 위한 파일이 제공되고 있다. 이들 중 VM 환경으로 사용을 원하는 Box를 선택하고, init 명령어를 통해 해당 정보를 가져옴으로써 원하는 시스템 환경을 구축할 수 있다. 그리고 vagrant up 명령어를 통해 가져온 설정 정보를 토대로 VM을 생성해준다.


 아래의 화면을 보면 Virtual Box를 설치한 직후 아무것도 없는 상태에서 아래와 같이 하나의 로지컬 머신이 생성된 것을 확인할 수 있다.




 vagrant init 명령어를 치면, 해당 디렉토리에 'Vagrantfile' 파일이 생성된다. 이전에 Box가 VM 생성을 위한 템플릿이었다면, vagrantfile은 생성될 VM에 대한 세부 설정을 정의한다고 볼 수 있다. VM을 생성할 때, 어떤 box 파일을 사용할 것인지, VM에 할당할 CPU, Memory, Network 등의 configuration을 vagrantfile에서 정의 및 수정할 수 있다.



 'vagrant up' 명령어를 실행할 때 위와 같은 오류가 발생한다면 이는 Virtual Box 버전에 따른 오류다. 필자도 아래와 같은 오류를 해결하는데 시간을 꽤 많이 할애 했는데, 설정을 잘못 했다거나(사실 설정이라 할 것도 없지만..), 설치 과정에서 문제가 있었던 것은 아니었다. 단지 갱신된 Virtual Box 버전에 따라 동작하지 않았던 것이다. Vagrant 동작을 확인한 버전은 Virtualbox 5.0.24이므로 해당 버전으로 설치할 것을 권고하는 바이다.



3. VM Provisioning


 Vagrant를 사용하여 VM을 생성한다고 해도, 완벽한 Provisioning이 진행됐다고 보긴 어렵다. 각 VM에서 개발환경에 필요한 소프트웨어 설치가 수동으로 필요하다면, 이는 절반뿐인 Provisioning이다. 따라서 웹 서버, 미들웨어, DB등을 설치하고, Configuration 하기위한 방법이 필요하다. 물론 VM 생성을 위한 이미지 자체에 이들을 포함시켜서 배포하는 경우도 있지만, 이 경우 한 종류의 개발 환경만 배포되므로 유연한 사용은 어렵다.





 Vagrant는 이런 불편함을 해소할 수 있는 Provisioning 기능을 제공한다. VM 생성 후, vagrantfile에 기술된 provisioning script를 수행함으로써 필요한 소프트웨어를 자동으로 설치하고, configuration해준다. 위 사진처럼 Vagrantfile 작성 시, VM 시스템 환경을 구축하자마자 bootstrap.sh에 작성된 스크립트 언어에 맞춰 필요한 소프트웨어를 설치하고 설정해준다. 한 가지 주의할 점은 vagrantfile의 provisioning 부분에 기술된 명령어는 vagrant up, reload, provision 세 개의 멸령어가 실행될 때마다 매번 실행된다. 따라서 스크립트 내에 해당 소프트웨어가 설치되었는지 확인 후에, 설치가 안된 소프트웨어에 대해서만 설치를 진행하다록 스크립트를 작성하는 것이 좋다.



4. Vagrant를 활용한 다양한 개발환경 구축


 위에서 설명한 것과 마찬가지로 Vagrant를 활용하면 다양한 개발환경 구축이 간편하고 빠르게 가능하다. Vagrant 활용의 이해를 돕기 위해 아주 기본적인 환경 모델을 나열해봤다.

    • Ubuntu + Apache
    • Ubuntu + MySQL
    • Ubuntu + Tomcat
    • CentOS + Apache
    • CentOS + MySQL
    • CentOS + Tomcat

나열된 목록과 같이 box 및 vagrant provisioning 기능을 활용하여 서로 다른 형태의 VM을 빠르게 구축할 수 있다는 점이 바로 vagrant의 큰 매력과 장점이다.


5. 마치며...


 대학원에 진학 한 뒤로 반복적인 테스트는 일상이다. 반복속에서 특정 요인만 변경하면서 계속 실험결과를 추적해야하는 상황이 많다. 특히 우리 연구실의 경우에는 VM을 활용한 테스트 환경을 구축해야 하는 일이 잦은 편이다. 따라서 이번 기회에 배운 Vagrant를 활용하면, 앞으로 남은 대학원 생활 동안에 효율적으로 일을 할 수 있을 것 같다. 아직은 기본적인 사용에만 익숙하고, 나만을 위한 완벽한 Provisioning까지는 어려운 상황이다. Vagrant가 제공하는 Provisioning 기능을 활용하여 보다 디테일하고 타이트하게 구성되는 나만의 테스트환경 구축을 위해 조금 더 들여다봐야 할 것 같다.



6. 참고


https://www.virtualbox.org/wiki/Downloads

https://www.vagrantup.com/downloads.html

https://www.vagrantup.com/docs/getting-started/

http://wiki.opencloudengine.org/pages/viewpage.action?pageId=2852295

http://bcho.tistory.com/806



개강과 동시에 이전까지 실습해보던 ONOS, Mininet에서 OvS라고 불리는 Open vSwitch로 방향이 변경되었다. 물론, 다른 블로거나 사람들이 써놓은 글귀를 읽는 것 역시 도움이 되겠지만, 처음 학습하는 만큼 OvS 공식 페이지, OvS GitHub에서 제공하는 문서들을 먼저 보고 있다. 아직까지는 OvS가 정확하게 무슨 역할과 기능을 담당하고, 어떻게 응용될 수 있는지 정확히는 모르겠다. (조금 더 OvS에 대해서 구체적으로 이해한 뒤, OvS란 무엇인가에 대해서 포스팅을 할 예정이다.) 그러나 SDN과 OvS의 관계에 대해서 검색을 해보니 상당히 밀접하게 연관되어 있으며, SDN 구현을 위해 핵심적인 역할을 담당하는 것은 확인할 수 있었다.



OvS에 대한 이론적인 이해에 앞서, 실습을 통해 OvS가 어떤식으로 활용되는지 파악해 볼 요량이다. 공식 페이지에서 제공하는 튜토리얼을 따라해보며, 새로이 알게된 부분에 대해서 정리를 하려한다. 튜토리얼 진행을 시작하자마자 부딪힌 문제는 튜토리얼 진행을 위한 준비물이었다. 사실 공식 페이지에 게재된 튜토리얼 자료를 보면, 다수의 호스트가 필요한 것이 대부분이며, 심한 것은 각각의 호스트에 다수의 NIC 카드가 설치된 환경을 요구하고 있다. 필자는 이들 중에서 조건이 덜 까다로운 것을 꼽아, 실제로 수행 해 본 과정을 기술하려 한다.



Monitoring VM Traffic Using sFlow



이것이 오늘의 튜토리얼 제목이다. 제목을 누르면 공식 페이지에서 제공하는 해당 글을 읽을 수 있도록 링크했으니 참고하기 바란다. 우선 이번 튜토리얼의 목적은 'sFlow Collector'라는 것을 활용하여 두 개의 VM에서 전송되는 트래픽을 모니터링 하는 것이다.



1. 환경설정


위의 그림은 공식 페이지에서 제공하고 있는 그림이다. 오늘 실습을 위해서는 위와 같은 세팅이 필요한데, 일단 두 개의 호스트, 두 개의 피지컬 네트워크가 요구된다. 각각 조건에 대해서 자세히 알아보자.


- Host 1: 실제로 OvS와 KVM을 이용한 버추얼머신들이 올라가는 호스트다. 그림상으로는 두 개의 NIC 카드(eth0, eth1)를 요구하지만, 필자는 해당 조건을 만족하는 디바이스가 없어서, Data Network와 Management Network를 통합하여 하나의 Network만 사용했다. Host 1 세팅을 위해 사용한 머신은 그냥 굴러다니는 Dell PC 하나에 Ubuntu Server 14.04 버전을 사용했다.


- Host 2(Monitoring Host): 모니터링만을 위한 Host 2에는 마찬가지로 굴러다니는 Dell PC 하나에 Ubuntu Desktop 14.04 버전을 사용했다. 이 Host 2에는 sFlowTrend라는 소프트웨어만 설치해서 구동하기 때문에 GUI가 제공되는 Desktop 버전으로 설치했다.


- Data Network: 실제로 두 VM으로 부터 데이터 트래픽을 전송하는 네트워크지만, 가지고 있는 Host 1의 NIC가 하나인 관계로 Management Network와 따로 구분하여 이용하지 않았다. 공식 페이지의 내용에서도 해당 네트워크는 반드시 필요한 것은 아니라고 아래와 같이 명시하고 있다.

For experimentation, this physical network is optional. You can instead connect all VMs to a bridge that is not connected to a physical interface.


- Management Network: 실제로는 Data Network로 나가는 트래픽을 확인을 위한 네트워크였지만, 위와 같은 이유로 Data Network와 구분하여 사용하지 않았다.


Host 2에서 사용하는 sFlowTrend 프로그램은 무료로 제공되는 프로그램인데, Java 환경에서 sFlow를 수집해주는 역할이다. sFlow는 기본적인 5 tuple 정보(Protocol, src/dst IP, src/dst Port)와 L2 정보(MAC, Interface, vLan)까지 바로바로 서버에 정보를 보내주는 방식으로 동작한다.



2. Host 1 Setting


위 그림과는 미묘하게 다른데, 내가 가진 호스트는 OS 설치 당시 eth1을 디폴트로 설정했기 때문에 eth0이 없고, eth1만 있음을 미리 밝힌다. 세팅을 위해서는 상당히 많은 과정이 필요한데, 너무 자세히 다루지 않고 각각의 명령어마다 간략하게 설명을 진행하려한다.


[1]

가장 먼저 Host 1에 업데이트 및 OvS를 설치하도록 하자.

$sudo apt-get update

$sudo apt-get install openvswitch-switch


[2]

다음은 /etc/network/interface 파일을 변경해주도록 한다. 이는 기존의 eth1에 할당된 네트워크 정보를 새로이 만들 브릿지 br0에 물려주기 위함이다. 해당 파일(/etc/network/interface)을 vi 텍스트 편집기로 열어서 eth1에 해당하는 부분을 br0로 변경해주자.

$sudo vi /etc/network/interface


auto eth1

iface eth1 inet static

address    xxx.xxx.xxx.xxx

netmask    xxx.xxx.xxx.xxx

...


$sudo vi /etc/network/interface


auto br0

iface br0 inet static

address    xxx.xxx.xxx.xxx

netmask    xxx.xxx.xxx.xxx

...


[3]

새로운 브릿지 br0를 생성하고, br0에 eth1 포트를 추가해주자.

$sudo ovs-vsctl add-br br0 

$sudo ovs-vsctl add-port br0 eth1

추가한 결과를 확인하기 위해서는 아래의 명령어를 이용한다.

$sudo ovs-vsctl show


명령어를 통해 출력되는 것을 보면, 브릿지 br0에 eth1 포트가 정상적으로 추가된 것을 확인할 수 있다. 필자의 스크린 캡쳐는 튜토리얼이 모두 완료된 상태에서 촬영한 것이므로 다르지만, 브릿지 br0에 포트 eth1이 추가된 것만 확인하도록 하자.





[4]

변경했던 /etc/network/interface 파일이 적용되도록 interface를 내리고, 다시 올린다. eth1의 ip는 0으로 설정한다. 이미 해당 포트를 브릿지 br0에 추가했고, /etc/network/interface 설정에서 br0에 IP를 기존 eth1의 IP로 할당했으므로 네트워크 연결에는 문제가 없다.

$sudo ifconfig eth1 0

$sudo ifconfig br0 0

$sudo ifup br0

$sudo ifconfig br0 up

$sudo ifconfig eth1 up


[5]

VM 생성을 위해 필요한 KVM을 설치하고, VM에 설치할 OS 파일을 다운받도록 하자. 필자는 호스트와 마찬가지로 VM에 우분투 서버를 올렸다. 우분투에서 제공하는 URL이 정상적으로 동작하지 않을 때가 있다. 웹에 검색을 통해 다른 곳에서 제공되는 URL을 통해 다운 받을 것을 권장한다.

$sudo apt-get install qemu-kvm libvirt-bin

$wget https://releases.ubuntu.com/14.04.3/ubuntu-14.04.3-server-amd64.iso


[6]

위 그림에서 확인해보면 각 VM 아래에는 tap들이 달려있는데, 이것이 VM의 NIC 역할을 해주는 것처럼 보인다. 각 VM에서 이용할 tap을 생성하자. 위 그림과는 다르게 VM1에서 사용할 탭의 이름을 tap1, VM2에서 사용할 탭의 이름을 tap2로 생성했다.

$sudo ip tuntap add mode tap tap1

$sudo ifconfig tap1 up


$sudo ip tuntap add mode tap tap2

$sudo ifconfig tap2 up 

ifconfig 명령어를 통해 해당 탭들이 정상적으로 올라왔는지 확인하자. 위의 스크린 캡쳐와 마찬가지로 필자의 상태는 튜토리얼이 모두 완료된 상태이므로 다르게 나타날 수 있다. 필자가 튜토리얼을 진행할 때에는 tap의 이름을 각각 vm1, vm2로 했기 때문에 아래 화면에서 vm1이 곧 tap1이고, vm2가 tap2 다. 모두 완료된 상태에서 글을 작성하기 때문에 네이밍이 다른 점을 양해바란다.





[7]

VM을 생성하고, VM에 다운로드 받았던 OS 이미지 파일을 통해 운영체제를 설치하도록 하자. VM을 총 두 개를 생성하는데, 아무래도 OS 설치과정이 포함되어 있기 때문에 하나 완료하고 나머지 하나를 진행하면 너무 오래걸린다. 두 VM을 병행하여 제작토록하자. 필자가 설치한 운영체제의 이미지 파일명은 ubuntu-14.04.3-server-amd64.iso다.

$sudo qemu-img create vm1.img -f qcow2 10G

$sudo qemu-img create vm2.img -f qcow2 10G


$sudo kvm -m 512 -name vm1 -smp cpus=1,maxcpus=1 -device virtio-net-pci,netdev=net0,mac='EE:EE:EE:EE:EE:55' -netdev tap,id=net0,ifname=tap1,script=no -boot d vm1.img -cdrom ubuntu-14.04.3-server-amd64.iso -vnc :5 -daemonize

$sudo kvm -m 512 -name vm2 -smp cpus=1,maxcpus=1 -device virtio-net-pci,netdev=net0,mac='EE:EE:EE:EE:EE:66' -netdev tap,id=net0,ifname=tap2,script=no -boot d vm2.img -cdrom ubuntu-14.04.3-server-amd64.iso -vnc :6 -daemonize


[8]

VM에 보다 손쉽게 접근하기 위해서 Host 1에는 xvnc4viewer를 설치하고, 윈도우 PC(Host 1, Host 2 외에 컨트롤을 위한 Host)에는 VNC Viewer를 설치하자. 구글링을 통하면 손쉽게 구할 수 있을 것이다.

$sudo apt-get install xvnc4viewer

윈도우에서 VNC Viewer를 실행하면 아래와 같은 화면이 나오는데, Host 1의 IP:5(VM1) 또는 IP:6(VM2)을 입력해주자. 5와 6의 숫자는 위에서 VM을 생성할 때 뒤 쪽에 입력했던 번호다. 즉 [Host 1의 IP:5]를 입력하면 VM1을 원격으로 다룰 수 있으며 [Host 1의 IP:6]을 입력하면 VM2를 원격으로 컨트롤 할 수 있다.





해당 VM에 접속하면 OS 설치하는 화면이 출력되는데, 아마도 네트워크 세팅을 수동으로 해줘야 할 것이다. 각 VM의 IP address는 192.168.0.5, 192.168.0.6으로 할당하여 VNC 번호와 동일하게 하자. 큰 의미는 없고 [MAC 주소의 마지막 숫자, VNC 포트 번호, IP 마지막 번호]를 통일해서 기억하기 쉽게하자는 뜻이다.

IP address: 192.168.0.5  //  192.168.0.6

Netmask: 255.255.255.0  //  255.255.255.0

Gateway: 192.168.0.1  // 192.168.0.1

Name server addresses: 8.8.8.8  //  8.8.8.8            


[9]

설치가 완료되면 각 VM을 일단 종료하자.

$sudo shutdown -P now


[10]

브릿지 br0에 NAT 설정을 위해 MASQUERADE 해주자. VM 내부적으로는 192.168.0.X 대의 Private 망을 사용하는데 VM에서도 Public 망을 이용할 수 있게 끔 NAT 설정을 해주자.

$sudo iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE


[11]

게이트웨이 역할을 위한 브릿지 br_private을 하나 더 생성하고, 각 VM의 tap을 br_private에 연결하자. 그리고 VM이 연결된 br_private를 br0에 연결한다.

//br_private 생성

$sudo ovs-vsctl add-br br_private


//br_private에 VM의 tap을 연결

$sudo ovs-vsctl add-port br_private tap1

$sudo ovs-vsctl add-port br_private tap2


//br0와 br_private을 연결하기 위한 포트를 각각의 브릿지에 생성

$sudo ovs-vsctl add-port br_private po_tobr0

$sudo ovs-vsctl add-port br0 po_toprivate


//br0와 br_private을 연결

$sudo ovs-vsctl set interface po_tobr0 type=patch

$sudo ovs-vsctl set interface po_toprivate type=patch

$sudo ovs-vsctl set interface po_toprivate options:peer=po_tobr0

$sudo ovs-vsctl set interface po_tobr0 options:peer=po_toprivate


[12]

마지막으로 /etc/network/interface 파일에 브릿지 br_private에 대한 정보를 추가하고, 인터페이스를 올리면 마무리된다.

$sudo vi /etc/network/interface


auto br_private

iface br_private inet static

address 192.168.0.1

netmask 255.255.255.0



$sudo ifup br_private

$sudo ifconfig br_private


[13]

다시 VM을 구동시키고, VNC Viewer를 통해 원격으로 접속해보자. 또한 각 VM에서 핑 테스트를 통해 정상적으로 VM이 Public 망에 접속됐는지 확인하자.

// Host 1

$sudo kvm -m 512 -name vm1 -smp cpus=1,maxcpus=1 -device virtio-net-pci,netdev=net0,mac='EE:EE:EE:EE:EE:55' -netdev tap,id=net0,ifname=tap1,script=no -boot d vm1.img -vnc :5 -daemonize

$sudo kvm -m 512 -name vm2 -smp cpus=1,maxcpus=1 -device virtio-net-pci,netdev=net0,mac='EE:EE:EE:EE:EE:66' -netdev tap,id=net0,ifname=tap2,script=no -boot d vm2.img -vnc :6 -daemonize


// VM1 or VM2

$ping www.google.com

핑 테스트가 정상적으로 동작한다면 Host 1의 세팅의 90% 이상이 성공적으로 완료된 것이다.


[14]

sFlowTrend 사용을 위한 설정이 필요하다. Host 1에서 아래의 스크립트를 입력하고, 각 스크립트가 의미하는 바는 공식 페이지의 설명을 참조하길 바란다.

$ COLLECTOR_IP=[Host 2의 IP]

$ COLLECTOR_PORT=6343 (6343: sFlowTrend의 default port #)

$ AGENT_IP=eth1

$ HEADER_BYTES=128

$ SAMPLING_N=64

$ POLLING_SECS=10


$sudo ovs-vsctl -- --id=@sflow create sflow agent=${AGENT_IP} target=\"${COLLECTOR_IP}:${COLLECTOR_PORT}\" header=${HEADER_BYTES} sampling=${SAMPLING_N} polling=${POLLING_SECS} -- set bridge br0 sflow=@sflow



3. Host 2(Monitoring Host) Setting


[1]

sFlowTrend 설치 이전에 Java 설치 및 PATH 설정이 선행되어야 한다. vi 텍스트 편집기로 /etc/bash.bashrc 파일을 열어서 아래의 한 줄을 추가해주자. 

$sudo apt-get install openjdk-7-jdk

$sudo vi /etc/bash.bashrc


//추가할 부분

export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64


$sudo -s

#source /etc/bash.bashrc


[2]

자바 설치 및 PATH 설정이 완료되면, sFlowTrend 다운로드 페이지로 이동하여 Linux Installer를 다운 받고 설치하자. 해당 파일은 쉘 스크립트 파일로 작성되어있는데, 실행이 안된다면 chmod 명령어를 이용하여 권한을 변경한 뒤 실행해보자. 정상적으로 실행되면 Starting Installer... 라고 출력되면서 설치화면이 나올 것이다. 참고로 Host 2는 GUI를 제공하는 Ubuntu Desktop 환경이다. 설치 화면이 안내하는 대로 따라하면서 설치를 완료하자. 그리고 프로그램을 실행시켜보면, 아래와 같은 화면이 나올 것이다.





[3]

화면 우측 아래에 초록색으로 불빛이 깜빡이는데, 이 불빛이 바로 Host 1으로 부터 sFlow 데이터를 수신하고 있음을 의미한다. 프로그램을 실행하면 가장 먼저 나오는 것이 Dashboard지만 각 탭으로 들어가서 확인해보면 다양한 형태로 시각화되는 것을 확인할 수 있다. 또한 지금은 시각적으로 크게 변하는 것을 확인할 수 없지만, 각 VM에서 큰 용량의 파일을 보내거나, 다운 받으면 그래프의 형태가 급진적으로 변하는 것을 알 수 있다.







4. 마치며...


사실 해당 튜토리얼보다 어려웠던 것이 Host 1을 세팅하는 부분인데, 내가 이전에 선배들이 제작한 관련실습자료를 따라해 본 경험이 있어서 큰 문제 없이 진행할 수 있었다. 튜토리얼 실습을 통해서 OvS를 사용법은 어느정도 숙지할 수 있었지만, 실제로 OvS를 어떤식으로 이용할 수 있을 지는 여전히 궁금하다. 공식 페이지에서 제공하는 다양한 OvS 관련 튜토리얼을 수행해보고, 관련된 논문이나 글귀를 참조하여 OvS를 능숙하게 다루고, 이용할 수 있도록 성장해야겠다. 또한 sFlowTrend는 비록 모니터링을 위해서 사용했던 소프트웨어지만, 데이터를 다양한 포맷으로 시각화하여 제공하므로 제법 유용하게 사용할 수 있을 것 같다. 아직은 시각화 된 자료를 이해하고 분석하는 역량이 부족하여, 제공되는 자료를 충분히 활용하지 못하는 것 같다. 다시 한 번 꼼꼼하게 시각화된 그래프와 자료들을 살펴봐야 겠다.



5. 참고


http://openvswitch.org/support/config-cookbooks





 개강을 앞두고 연구실 생활을 하면서 OvS나 Kafka, Flume, Docker, Mesos, Spark, Zeppelin 등 이전까지는 접해보지 못했던 다양한 것들을 얕게나마 경험하고 있다. 그 중 오늘 포스팅할 소재는 ONOS라는 것으로, 필자도 오픈소스 프로젝트의 일환이자 SDN 및 NFV와 밀접한 연관이 있다는 것을 알고있을 뿐 정확하게는 프로젝트의 의미를 이해하고 있지 않다. 학습을 진행하면서 부족한 부분을 진행하기로 하고, 오늘은 이 ONOS 설치에 대한 이슈를 정리하고자 한다. 사실 어제 몇 시간동안 설치를 시도했으나 성공하지 못했다. 그런데 이전까지 진행됐던 과정을 모두 제거하고, 새로이 설치를 진행해보니 무난하게 잘 되어 진행 과정을 정리해본다. 글에 앞서 설치에 정말 큰 도움을 준 블로그가 있어서 감사의 말씀을 전한다.


먼저, 필자는 Ubuntu Desktop 14.04 LTS 64bit를 이용해 설치를 진행했음을 알린다.


1. GIT


 ONOS 설치를 위해서는 사전에 몇 가지 과정이 선행되어야 하는데, 따라해보면 그리 어렵지 않다. 대부분의 오픈소스들이 그러하 듯 ONOS 역시 Git Repository를 통해 소스를 배포하므로 GIT 설치를 진행해보자.

$ sudo apt-get install git


2. JAVA 1.8


 다음은 ONOS가 동작하기 위해 필요한 자바 1.8 버전을 설치가 필요하다.

$ sudo apt-get install software-properties-common

$ sudo apt-apt-repository ppa:webupd8team/java

$ sudo apt-get update

$ sudo apt-get install oracle-java8-installer


 설치된 자바의 환경설정을 위해서 아래의 명령어를 이용하고, 정상적으로 설정이 되었는지 확인해보자.

$ export JAVA_HOME=/usr/lib/jvm/java-8-oracle

$ env | grep JAVA_HOME


3. Maven, Karaf


 ONOS는 Maven과 Karaf를 이용하여 실행과 컴파일이 진행된다. 아직 Maven, Karaf에 대해서는 아는 내용이 없는데, 추후 학습이 진행되면서 추가해 볼 생각이다. ONOS에서 제안하는 Maven 및 Karaf 버전은 Apache Maven 3.3.1, Apache Karaf 3.0.3이므로 해당 버전을 다운받고, 적당한 폴더에 압축을 해제하자.

$ cd ~ 

$ mkdir Applications

$ cd Downloads

$ wget http://download.nextag.com/apache/karaf/3.0.3/apache-karaf-3.0.3.tar.gz

$ wget http://archive.apache.org/dist/maven/maven-3/3.3.1/binaries/apache-maven-3.3.1-bin.tar.gz

$ tar -zxvf apache-karaf-3.0.3.tar.gz -C ../Applications

$ tar -zxvf apache-maven-3.3.1-bin.tar.gz -C ../Applications


4. ONOS Source Download


 이전에 설치했던 GIT을 이용하여, 이제 ONOS 소스를 다운 받자. 다양한 버전을 받을 수 있는데 필자가 사용한 버전은 onos-1.4 버전이다.

$ cd ~

$ git clone https://gerrit.onosproject.org/onos

$ cd onos

$ git checkout onos-1.4

$ git pull --rebase origin master


5. 환경설정


 정상적으로 동작하기 위해서 ONOS 환경설정이 필요하다. 아래의 내용은 부팅할 때마다 해줘야한다. 이 과정이 귀찮다면, 쉘 스크립트로 작성해서 저장해도 무방하다.

$ export ONOS_ROOT=~/onos

$ source $ONOS_ROOT/tools/dev/bash_profile


 위의 설정을 해도 정상적으로 동작하지 않는 경우가 발생했는데, 지인으로부터 해결책을 받을 수 있었다. 위 코드와 더불어 아래의 내용을 /etc/profile에 추가해주자.

$ sudo vi /etc/profile


JRE_HOME=/usr/lib/jvm/java-8-oracle/jre

MAVEN_HOME=~/Applications/apache-maven-3.3.1

PATH=$PATH:$JAVA_HOME/bin:$JRE_HOME/bin:$M2_HOME/bin

export JRE_HOME

export MAVEN_HOME

export PATH



6. ONOS 설치


 환경 설정까지 끝마쳤다면, Maven을 사용하여 ONOS를 빌드해보자.

$ cd ~/onos

$ mvn clean install


 정상적으로 이전 과정들이 진행되고, 환경설정이 완료되었다면 문제없이 빌드가 완료될 것이다. 해당 코드에는 빌드 후 테스트 과정이 포함되어있기 때문에 시간이 꽤나 소요되므로 인내를 가지고 기다려보자. 성공적으로 빌드가 완료되었다면 BUILD SUCCESS라는 메시지를 확인할 수 있을 것이다.


7. ONOS 실행


 실행에 앞서 ONOS가 실행되는 IP를 세팅해줘야 한다. SDN 컨트롤러의 IP를 설정해주자.

$ export ONOS_IP=<ONOS IP Address>


 이제 모든 준비가 완료되었다. ONOS를 실행시켜보자.

$ ok clean


 아래와 같은 화면이 출력된다면 정상적으로 ONOS가 동작중인 것이다.




8. 마치며...


 막상 설치를 하고보니 크게 어려운 과정은 아니었지만, 설치과정에서 반복되는 오류가 어디에서 발생한 것인지 알아내는 것이 어려웠다. 되짚어보면 환경 설정하는 부분에서 정상적으로 설정되지 않아서 발생한 문제 같은데, 모든 내용을 지우고 반복해보니 이상없이 설치되는 것을 확인할 수 있었다. 이에 앞서, 버추얼박스를 이용하여 ONOS Tutorial을 수행해봤는데, 너무 무겁게 돌아가는 탓에 아예 반응을 하지 않을 정도로 심한 렉이 생겨서 VM을 이용한 ONOS 구동은 포기했다. 아직 정확히 ONOS가 무엇인지, 무슨 기능을 제공할 지 아는 것이 없지만 시작이 반이라는 말처럼, 앞으로 ONOS에 대한 학습을 진행해보려 한다.


9. 참고


http://sola99.tistory.com/

http://uni2u.tistory.com/41