이번 편에서는 Bacula가 어떠한 방법으로 백업을 하는지, 그 방법에 대한 개념을 잡아보도록 한다.  Bacula는 다소 특이한 방식으로 작동하는데, 처음 보면 뭐가뭔지 이해가 잘 안가고, 언뜻 보면 상당히 복잡해보이기 때문이다.  bacula.org에는 이해를 돕기위한 그림이 몇 개 있지만 사실 이게 본인 입장에서는 더 해깔린다.  별것도 아닌건데 어렵게 설명하는 느낌이랄까.

Bacula는 3개의 서비스 데몬과 카탈로그라고 하는 하나의 DB로 구성된다.  결국 총 4개의 서비스 데몬이 필요한 셈인데, 이 4개의 서비스 데몬은 얼마든지 확장이 가능하다.  그렇다면, DB를 제외한 나머지 3개의 서비스 데몬에 대해서 보자.

1.  Director Daemon - 클라이언트들과 통신을 한다.  백업 및 복원명령을 직접 제어하며, 공식적으로 하나의 디렉터 데몬은 총 1천여대 정도의 클라이언트를 제어할 수 있다.  포트번호는 9101을 사용한다.
2.  File Daemon - Director Daemon으로부터 백업 명령이 들어왔을시, 어떤 파일들을 백업해야하는지 대상 목록을 뽑아낸뒤 해당 파일들을 전송한다.  포트번호는 9102을 사용한다.
3.  Storage Daemon - Director Daemon으로부터 백업 명령이 들어왔을시, 파일데몬과 직접 접속하여 파일들이 저장되어야할 백업 장치를 제공하고, 파일을 실제로 저장하는 역할을 수행한다.  포트번호는 9103을 사용한다.

조금 이해가 되실거다.  디렉터 데몬은 하나만 있으면 되지만 규모가 많거나, 혹은 특정한 목적에 의해 서버별로 백업을 나눠서 해야하는 경우라면 디렉터 데몬은 여러 개를 두면 된다.  결국 명령은 디렉터가 내리는 것이므로, 두개의 디렉터에서 하나의 클라이언트에 백업명령을 두번 세번 내리는 것도 가능하다는 얘기다.  물론 그렇게 쓸 일은 없겠지만.

파일데몬의 경우, 대부분의 머신에 설치되는 클라이언트인데, 설정 자체는 아예 손댈 일이 없을 정도로 간단하게 돌아간다.  메모리에 상주해있기만하면 디렉터 데몬에 의해서 알아서 동작하기 때문에 신경쓸 일은 전혀 없다고 봐도 무방하다.  실제로 대부분의 에러는 디렉터 데몬이 돌아가는 서버에서 발생하지, 파일데몬이 설치되어있는 클라이언트에서는 거의 생기지 않는다.

스토리지 데몬은, 머신에 어떤 저장장치가 연결되어있는지를 정의해놓으면 작업별로 특정 장치를 지정할 수 있다.  예를 들어서, 사용자의 FTP 디렉토리는 LTO-5로 백업하고, /etc 디렉토리는 하드디스크에 저장하는 형태도 가능하다.  따라서, 스토리지만 정의해놓으면 디렉터 데몬이 설정대로 파일을 백업해준다.  서버의 규모가 작은 곳이라면, 하나의 머신에 모든 저장장치를 전부 연결하고 디렉터와 스토리지 데몬을 한 서버에서 돌리는 식으로 하면 되겠다.  글쓴이가 일하는 곳에서는 디렉터 데몬은 오픈스택의 한 가상머신에서, 스토리지 데몬은 LTO-5 장치를 연결한 서버에서 운영한다.  그외 모든 물리적인 서버와 오픈스택 가상머신들에 파일데몬을 설치하여 백업 중에 있다.  Bacula가 사용하는 CPU 점유율은 무척 낮기 때문에 가상머신에서 돌려도 거의 문제가 없다.

그러면 이제 bacula.org에서 제공하는 그림을 보자.

 

이제 위의 그림이 쉽게 이해 가실거다.  다만 Admin Workstation이 2대가 보이는 부분은, 관리자의 개인 컴퓨터에서 디렉터 데몬을 통한 모니터링이 가능하다는 것을 보여주는 그림인데, 실제로 3줄짜리 설정파일만 있으면 모니터링이 가능하다.  따라서, 관리자가 여러 명인 상황에서도 각각 자기들의 컴퓨터를 통해서 모니터링이 가능한 것이다.

그러면, 왜 데이터베이스가 필요한지 설명을 할 차례가 왔다.  Bacula에는 "카탈로그"라고 하는 일종의 백엔드 서비스가 있는데, 백업되는 파일들의 인덱싱을 한다고 보면 이해가 쉬우실 거다.  즉, 파일 관리의 수월함과 빠른 복원을 위해 백업시마다 파일들에 대한 목록을 DB에 넣어서 관리를 하게되며, 공식적으로 MySQL, PostgreSQL, 그리고 SQLite를 지원한다.  물론, DB가 손상됐을 때를 대비해서 수동으로 복원할 수 있는 방법 역시 제공되는 CLI 툴을 통해 가능하다.  공식적으로는 PostgreSQL을 권장하며, 실제 기업업무용으로 SQLite는 권장하지 않는다.

여기서 어떤 분들은 아마 "어차피 백업된 경로 들어가서 ls 치면 파일목록 다 나올텐데 뭐하러 DB를 쓰는가" 라고 의문점이 생기실텐데, Bacula는 파일의 목록을 DB에 넣고, 실제 파일들은 압축하거나 아니면 그냥 하나의 파일로 묶어서 보관한다.  쉽게 생각해서 tar 명령어처럼 하나의 파일을 만들어서 여기에 몽땅 넣어버리는데, 물론 여기에도 다양한 옵션이 있다.  용어가 해깔릴 수 있으므로, 백업되는 파일들을 몰아넣는 파일을 "볼륨"이라고 부르도록 하자.

1.  볼륨의 용량을 제한할 수 있다.  예를 들어 볼륨 하나당 10기가로 지정해두고 백업을 진행하다 10기가가 넘어가게 되면 또 다른 볼륨을 생성한다.
2.  생성되는 볼륨의 갯수를 제한할 수 있다.
3.  특정 백업분을 삭제할 경우, 사용자는 몇개의 볼륨이 존재하는지, 어떤 파일이 어떤 볼륨에 있는지 상관하지 않아도 된다.  따라서, 목적별로 스토리지를 운영ㅇ할 수 있다.
4.  특정 볼륨에서 특정 백업분만 삭제할 수 있다.
5.  볼륨에 auto-prune을 지원한다. 
6.  백업되는 파일들의 유지기간 (Retention) 지정이 가능하며, 기일이 지난 백업분은 Bacula가 알아서 삭제해준다.
7.  특정 백업분을 특정 볼륨에 지정하는 것이 가능하다.  예를 들어, Incremental은 볼륨 AAA, Differential은 볼륨 BBB, Full은 CCC 이런 식으로.
8.  따라서, 백업에 쓸 수 있는 스토리지의 용량이 한정되어있어서 이것을 매번 신경써줘야하는 관리자라면, 이 문제에서 해방될 수 있다. 

Bacula의 공식문서에 의하면, 데이터를 저장하는 방식인 Pool이니 Volume이니 하는 것들은 사실상 테이프 백업 장치의 개념을 하드디스크 백업에 적용시키는 거라고 한다.  또한, 하나의 파일로 묶어서 보관한다는게 뭐하러 그렇게 하는건지 다소 이해가 가지않을 수도 있지만, 서버의 보안이 뚫렸거나 관리자가 아닌 유저가 접속해서 백업데이터에 접근하더라도 데이터 자체가 하나 혹은 몇개의 파일에 전부 모아져있기 때문에 내용을 볼 수 없다는 장점이 있다.  따라서, 하나의 파일로 묶는건 보안상 그렇다고 이해하면 되겠다.

스토리지 서버가 다른 곳에 있기 때문에, 재해복구나 Bare Metal Recovery도 가능하다.  평소 서버들을 백업할 때 시스템 전체 (/)를 백업해뒀다면, 나중에 우분투 라이브 씨디 등으로 부팅한뒤 네트워크를 설정해주고 파일데몬을 설치해서 CLI 툴로 복원해주면 되는 것이다.

 

이것으로 Bacula의 백업 프로세스에 대해서 알아봤다.  복잡해보이지만, 알고보면 무쟈게 간단하다.  정리를 해보자.

1.  Bacula는 3가지 서비스 데몬과 데이터베이스로 구성된다.
2.  디렉터 데몬은 일종의 관제탑으로서, 백업/복원/모니터 등등의 모든 작업에 대한 통솔을 한다.
3.  파일 데몬은 어떤 파일이 백업되어야하는지를 목록을 뽑아낸다.
4.  스토리지 데몬은 디렉터 데몬의 백업 및 복원 명령에 의해 저장장치를 제공하고, 데이터를 읽고쓴다.
5.  디렉터 데몬은 백업되는 파일들의 목록과 모든 상황을 데이터베이스에 기록한다.
6.  백업되는 파일들은 볼륨이라는 몇개의 거대한 파일이나 테이프에 기록된다.

다음 편에는 Bacula의 서비스 데몬들을 설치해보도록 한다.

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

또 다른 매뉴얼 작성을 시작한다.  Bacula 라고하는 엔터프라이즈급 오픈소스 네트워크 백업 솔루션이다.  엔터프라이즈 라는 단어에서 오는 의미를 봐서, 개인용은 아니라는 것이 짐작되실 거다.  물론 개인용으로 써도 된다.  전혀 문제없다.

이걸 처음 써보고서는 오픈소스에 이 정도 성능의 솔루션이 한국에서 널리 알려지지 않은 것이 안타까워서, 본인 스스로가 이걸 좀 알려야겠다고 마음을 먹게되었다.  또한, 나는 Bacula Systems에서 주관하는 공인 교육인 Bacula Systems Administrator I과 II 교육을 모두 수료하여 Certified Backup Admin 인증서를 받았다.

한 가지 덧붙이자면, 본 매뉴얼은 Bacula Systems의 경영진 및 직원들에게 작성을 통보했었고, 사실 그들도 어느정도 관심있게 지켜보고 있다.  언어적인 문제일 수도 있겠지만, Bacula가 독일을 비롯한 유럽과 서양에서는 상당히 인기있는 반면 아시아에서는 언급은 커녕 이런게 있는지도 모르는 경우가 태반이기 때문이다.  이 매뉴얼을 시작으로 한국의 IT 시장에도 Bacula가 어느 정도 알려지길 바라는 기대가 어느정도 있어보인다.

본 매뉴얼을 시작하게 된 계기는, 이렇게 훌륭한, 그것도 오픈소스 솔루션을 모르는 분들이 생각보다 너무 많아서였다.  Bacula는 한 번도 들어본 적이 없었지만 처음 접하고나서는 완전히 반해버렸다.  너무나도 훌륭하고 이걸 집이건 어디건 내가 관리하는 컴퓨터라면 전부 이걸로 갈아엎고 싶을 정도다.  내가 일하는 곳이 미국이라서 오픈소스를 접하기가 쉽긴 하지만, 주립대학이 주정부기관의 한 부서이다보니 아무래도 비용을 최대한 줄일 수 있는 오픈소스만 고집하는 것이 진짜 오픈소스 솔루션을 쉽게 접할 수 있는 이유가 아닐까 싶다.

Big Blue Button이라고 하는 너무나도 훌륭한 영상/음성지원 실시간 프레젠테이션 솔루션에 대해서도 잠깐 언급을 해드린다.  정말 이것이 과연 오픈소스인가 할 정도로 좋고, 게다가 상당수의 교직원들이 우분투 리눅스를 사용하는 본인의 직장환경에서도 모든 기능이 100% 작동되었다.  윈도우, 리눅스, 그리고 맥까지 모두 작동되는 이런 훌륭한 오픈소스 프로그램들이 많은데, 이런 것들을 알지 못해서 못쓰는 상황이 많이 안타깝다.

이 매뉴얼에서 곧 다룰 Bacula라고 하는 백업 솔루션도 마찬가지로, 오픈소스이며 너무나도 잘 만들어져있고, 쉽고, 간편하다.  해외에서는 이미 커뮤니티 버전에 대한 유저들의 참여가 활발하며, Bacula를 만든 Bacula Systems의 CTO인 Kern Sibbald가 직접 메일링 리스트의 답변을 주기도 한다.  공식적으로 리눅스, 윈도우, 맥, 그리고 여러 유닉스를 지원하며, 그외 잘 쓰이지 않는 유닉스 유저의 경우는 소스가 오픈되어있기 때문에 소스를 가져다 설치하면 된다.  공식적으로 지원되는 클라이언트용 플랫폼으로는 리눅스, 솔라리스, Free/Net/OpenBSD, 윈도우, 맥, HP-UX, Tru64, Irix가 되겠다.  특히나 백업이라는 행위가, 모든 장소에 똑같은 방식이 적용하는 것이 불가능한 아주 다양한 상황에 대한 요구가 필요한 것인데 Bacula는 이런 요구를 모두 처리할 수 있는 기능을 갖추고 있다.

또한 Bacula는, "오픈소스로 돈을 버는" 한국에서는 다소 성공하기 어려운 형태의 비지니스 모델을 이뤄냈는데,
1. 오픈소스 솔루션을 개발해서 배포한다.
2. 유료로만 지원되는 플러그인 및 모듈, 기술지원, 그리고 전문교육
을 판매하는 형태로, Bacula Systems라고하는 회사가 별도로 존재한다.  따라서, bacula.org는 오픈소스의 커뮤니티 버전을, baculasystems.com 이라고 하는 엔터프라이즈 레벨의 상품을 판매하는 것이다.  Bacula는 2000년 1월에 처음 개발이 시작되어, 2002년 4월에서야 소스포지에 첫 버전이 올라왔고, 유료버전은 짝수이며 현재 버전 6까지 나와있다.

Bacula의 특징으로는 다음과 같다.

1.  쉬운 설치 및 쉬운 설정
2.  다양한 백업 장치 지원 (하드디스크, LTO 1-5 테이프 장치 등등)
3.  다양한 모니터링툴 지원
4.  증분, 차등, 차등 증분, 변경분, 가상백업, 백업 주기, 압축, 프로토콜 등 다양한 백업방식 지원
5.  원하는 경로 설정 및 백업 전후 실시할 명령어 지정 가능 
6.  네트워크로 백업되는 데이터의 암호화를 위한 다양한 옵션 (MD5, SHA, TLS, CRAM-MD5 등등)
7.  압축 

글쓴이가 근무하는 서버실 서버 중 대략 60대를 Bacula로 백업하고있는데, 사실 옵션이 아무리 많아도 쓰는건 한정되어있기 마련이다.  따라서, 본인의 상사께서 정해준 규정과 옵션으로만 운영하는 현재, 매일 하루에 한 번씩 이메일로 날라오는 백업 리포트를 읽는 것 외에는 백업에는 아예 신경을 안쓰고 근무할 정도로 편하고 쓰기쉬운 백업 솔루션이라고 말할 수 있다.  또한, 글쓴이의 서버실 규모가 작아서 그렇지, 교육에서 만났던 브라질에서 온 참가자의 경우는 1천대 가량 규모의 백업을 Bacula로 하고있다고 했다.  다른 참석자 중에서는 NASA에서 근무하는 System Admin도 있었다.

본 매뉴얼을 따라하기 위한 조건으로, 아래의 환경처럼 구성하고자 한다.  반드시 맞춰야할 필요는 없지만, "네트워크 백업 솔루션"인만큼 최소 2대의 컴퓨터가 있어야겠다.  다만, 반드시 필수적인 조건으로는, 본 매뉴얼을 따라하고자하는 분께서는 반드시 리눅스 터미널과 명령어 사용에 익숙해야하고, 네트워크에 대한 최소한의 개념은 이해하고 있어야한다는 점이다.  본인의 실습 조건이다.

1.  노트북
2.  가상화 프로그램 (Parallels 혹은 VMware)
3.  4대의 가상 컴퓨터
4.  글쓴이는 우분투 한국 로코팀 컨택터이므로, 가상 컴퓨터 4대의 운영체제는 모두 우분투 리눅스로 실시하며, 특별히 한 대는 데스크탑으로 한다.
5.  맥용 클라이언트 설치는 설명에서 제외한다.  일단, MacPorts에서 설치가 가능하고, 설정은 리눅스랑 100% 똑같다.
6.  윈도우용 클라이언트는 부득이하게 제외하기로 한다.  맥용 클라이언트와 마찬가지로, 설정은 리눅스랑 100% 같다.  참고로, 현재 윈도우용은 2012년 6월 28일자 버전인 5.2.10을 끝으로 무료버전은 개발이 중단됐다.  참고로, 최대 9대까지 쓸 수 있는 윈도우용 라이센스는 불과 1년에 $25 밖에 안한다.  1,000대 이상도 그래봐야 $600 밖에 안한다.기업용으로 이 정도 가격은 정말로 껌값이다.  무료 버전의 클라이언트는 현재 개발이 중단됐다는 점을 기억하자.
7.  백업 명령/복원 등의 실습은 CLI로 먼저 시작하고, CLI가 어느정도 익숙해지면 GUI를 진행한다.  사실 GUI를 사용하는 진짜 이유는, Bacula에서 화면에 출력되는 데이터가 횡으로 너무 길어서 CLI로 보면 상당히 불편하다.
8.  다양한 환경과 상황에서의 실습은 차후에 보여드릴 예정이다.  백업이라는 게 상황마다 조건마다 다들 판이하게 다르기 때문에 그것들을 일일히 다 실습해볼 수도 없거니와, 여러가지 상황에 대비한 옵션과 각각의 옵션에서 파생될 수 있는 결과 역시 수없이 많이 달라질 수 있기 때문에 개념을 설명하는 부분에서는 설명을 제외한다. 

이제 설치에 들어가보자.  가상 컴퓨터가 아닌 진짜 컴퓨터로 해도 상관은 없겠지만, 리눅스 설치에 시간이 좀 걸릴테니 미리 준비하실 분들은 우분투 설치부터 시작하시면 되겠다. 

다음 편으로...

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

9월 10일부터 12일까지 총 3일간 진행됐던 Bacula Systems 사의 오픈소스 네트워크 백업 솔루션 공인 자격교육이 끝났다.

이로써 아마도 국내 첫 Bacula 공인 백업 어드민이 된듯 싶다.


 


 

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

sudo add-apt-repository ppa:webupd8team/sublime-text-2

sudo apt-get update

sudo apt-get -y install sublime-text 


Sublime Text 2 실행한 뒤, 사이드 바에 고정시키면 끝.

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

1주일에 걸친 매뉴얼 작성이 모두 끝났다…  이번 매뉴얼 작성을 위해 실시한 설치까지 합치면 총 6번의 Ceph 클러스터 설치를 해보게 됐는데, 이제는 정말 울집에 쓰는 홈서버에도 하드 몇 개 더 달아서 오브젝트 스토리지 구성한다고 할지도 모르겠다.

이 매뉴얼 작성의 시작은 페이스북에 있는 오픈스택 코리아 그룹이라는 오픈스택 유저모임에 글쓴이가 질문 몇개를 올린 것에서 시작이 됐었다.  원래 매뉴얼을 작성할 마음은 전혀 없었고, 글쓴이가 근무하는 곳에서는 이 Ceph를 오픈스택 클라우드와는 별개로 개발자나 Faculty members, 혹은 그외 업무용으로 자료저장이 필요한 사람들에게 공간을 제공하기 위해서 구축하게된 시스템이다.  따라서, 설치를 하고 이것이 어떤 물건이면 어떻게 사용하는 것이고 어떤 목적에 맞게 어떻게 쓸 수 있는지를 알아보던 중 질문을 올리게 됐고, 어느 한 분께서 Ceph 쪽으로는 한국어로 나와있는게 전혀 없어서 힘든데 나중에 매뉴얼 올려주시냐는 글 한줄을 보고서 이걸 작성해야겠다는 마음을 먹게됐다.  나중에 알고보니, 나 말고도 Ceph 설치과정을 아주 간단하게 적은 한국 블로그를 보긴 했는데, 자세히 보니까 그냥 Ceph 홈페이지에 있는 공식문서를 그대로 적어놓기만했고 번역이나 설명이 전혀 되어있지 않은 상태었다.  어찌됐든, 나름 한국 온라인 상에서는 최초의 Ceph 설치 매뉴얼이라는 자부심을 갖고 매뉴얼을 작성했다.

사실 제일 힘들었던 점은 역시나 API였는데, CephFS의 경우 그냥 마운트하는 것으로 하드디스크 쓰듯 쉽게 사용할 수 있었지만, API의 경우 아무런 이유없이 안되는데다 어쩔 때는 됐다가 또 어쩔 때는 안되기도 하니, 이게 가상머신이라 안되는 건지, 내가 뭔가를 잘못해서 안되는 건지 대체 알 수가 없었다.  그러한 이유 때문에 아직 Ceph를 쓰는 곳이 많지않구나~ 하는 생각도 하곤 했었다.  나중에 알고보니 아주 굵직한 회사들이 Ceph를 도입했거나 할 예정이라더라.

글쓴이의 학교에 세팅되어있는 환경은, OSD용 서버가 총 3대가 있고, 한대당 2테라바이트짜리 서버급 하드디스크가 16개 장착되어있다.  Ceph 클러스터 전체를 통틀어서 대략 80테라바이트의 저장공간이 있다.  여기에 Ceph와 OSD 서버 3대에 기가비트 랜카드를 2장씩 더 꼽아서 Bonding을 구성하고, OSD의 다른 이더넷은 케이블을 뽑아서 외부와의 연결을 차단시켰다.  따라서 Ceph 클러스터 내부에서는 그들만의 고립된 세계에서 기가비트 본딩시켜놓은 속도로 통신하고, 사용자는 Ceph 서버하고만 통신하는 것이다.  꽤 괜찮은 구성 같은데 오브젝트 스토리지 구성 계획 중이신 분들은 참고하시라.  사실 이글 읽으실 분들이라면 굳이 얘기안해도 글쓴이보다 더 잘아실 거다.

퇴근하고서 저녁식사를 하고난 후에 시간을 내서 작성했던터라 그래서 1주일쯤 걸리긴 했는데, 시간이 많이 걸리더라도 내심 기대하고 있는 것은 내가 시작한 이 매뉴얼을 시작으로 많은 분들이 Ceph를 사용하고 테스트를 해보면서 노하우를 공유해주시고, 또 이 매뉴얼에 추가를 해주신다면 이러한 것도 오픈소스 활동에 기여하는 것이 아닐까 한다.

 

감사합니다.

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

드디어 대망의 마지막 편이다.  이번 편에서는 지난 번 설치한 RADOS Gateway를 이용해서 Swift와 Amazon S3 API를 이용하는 방법을 알려드린다.  여기서는 글쓴이의 경험상 안되는 부분들이 좀 많았고, 구글에서 아무리 자료를 검색해도 도움이 될만한 자료는 없었다.  이에 관련한 이야기는 후기편에 올려드린다.

S3든 Swift든 가장 중요한 것은 user를 생성하는 것이다.  User 생성, Bucket 관리 등은 radosgw-admin이라는 명령어를 통해서 이루어지는데, 이 명령어가 갖고있는 옵션은 그다지 다양하지 못하다.  따라서, 제공되는 기능은 현재로서는 아주 단순하다고 볼 수 있겠다.

먼저 유저를 만들자.  글쓴이의 이름과 이메일 주소를 넣어서 할테니 이 글을 보시는 분들은 각자 알아서 하시면 되겠다.
sudo radosgw-admin user create --uid=seowon --display-name="Seowon Jung" --email=seowon@hawaii.edu

특별한 설명이 따로 필요없을 정도로 간단하다.  실행이 정상적으로 완료되면 아래와 같은 JSON 형태의 결과가 출력된다.

{ "user_id": "seowon",
  "display_name": "Seowon Jung",
  "email": "seowon@hawaii.edu",
  "suspended": 0,
  "max_buckets": 1000,
  "subusers": [],
  "keys": [
        { "user": "seowon",
          "access_key": "JRGPACZEG4FPS2HGKLP5",
          "secret_key": "pFFIRX2i1augYDlno3Muhz\/jFS5ixlubbBbf0lGs"}],
          "swift_keys": [],
          "caps": []}

이 명령어 실행으로 Amazon S3 사용을 위한 계정을 만들었다.  간단하다.  Access key와 Secret Key로 인증이 이루어진다.  접속은 아래의 화면처럼 하면 되겠다.  

만약 리눅스 사용자가 DragonDisk를 사용한다면 반드시 Connect using SSL/HTTPS에 체크를 해줘야한다.

이제 방금 생성한 유저에 Swift API 사용권한도 줘보자.  아래의 명령어를 실행해본다.
sudo radosgw-admin subuser create --uid=seowon --subuser=seowon:swift --access=full

그러면 아까 위에서 봤던 JSON 형태의 메시지가 출력되는데, 전부 다 같고 subusers라는 항목이 더 추가되서 나온다.

{ "user_id": "seowon",
  "display_name": "Seowon Jung",
  "email": "seowon@hawaii.edu",
  "suspended": 0,
  "max_buckets": 1000,
  "subusers": [
        { "id": "seowon:swift",
          "permissions": "full-control"}],
  "keys": [
        { "user": "seowon",
          "access_key": "JRGPACZEG4FPS2HGKLP5",
          "secret_key": "pFFIRX2i1augYDlno3Muhz\/jFS5ixlubbBbf0lGs"}],
          "swift_keys": [],
          "caps": []}

그런데 유심히 보면 swift_keys가 공란으로 되어있다.  이 부분이 바로 Swift에 인증이 이루어지는 "패스워드" 항목이다.  따라서 패스워드를 생성해줘야한다.  이 패스워드는 맘대로 정할 수 없고 위에서 봤던 S3처럼 Base64 문자열이 자동으로 생성된다.  아래의 명령어를 실행한다.
sudo radosgw-admin key create --subuser=seowon:swift --key-type=swift

그러면 위의 화면과 똑같은데 swift_keys 항목에 패스워드가 생성된 화면을 볼 수 있다.

{ "user_id": "seowon",
  "display_name": "Seowon Jung",
  "email": "seowon@hawaii.edu",
  "suspended": 0,
  "max_buckets": 1000,
  "subusers": [
        { "id": "seowon:swift",
          "permissions": "full-control"}],
  "keys": [
        { "user": "seowon",
          "access_key": "JRGPACZEG4FPS2HGKLP5",
          "secret_key": "pFFIRX2i1augYDlno3Muhz\/jFS5ixlubbBbf0lGs"}],
  "swift_keys": [
        { "user": "seowon:swift",
          "secret_key": "rHZLD2ONRsGR2BreFxCmKAULhlk6PXq6D9cNGjc1"}],
  "caps": []}

다 됐다.  확인해보자.  전편에서 언급했지만, Swift API는 내 경험상 리눅스 터미널의 명령어로만 작동이 가능했다.  그것도 HTTPS는 안되고 HTTP만 됐는데, 이것 역시도 왜 안되는지 원인을 알 수 없었다.  현재 Ceph에는 Swift의 1.0 버전이 내장되어있으며 2.0은 당연히 지원되지 않는다.  명령어의 형식은 아래와 같다.

swift -V 1.0 -A http://IP_Address -U username:swift -K Secret_key command option

실제 예제로 확인해보자.  먼저 버켓을 생성한다.  버켓은 post라는 명령어로 생성이 가능하다.  테스트를 위해 Test_Seowon이라는 버켓을 만들어본다.  아무런 메시지가 나오지 않는다면 정상적으로 실행된 거다.
swift -V 1.0 -A http://10.211.55.24/auth -U seowon:swift \
  -K rHZLD2ONRsGR2BreFxCmKAULhlk6PXq6D9cNGjc1 post Test_Seowon

파일을 업로드해보자. upload 라는 명령어다.
swift -V 1.0 -A http://10.211.55.24/auth -U seowon:swift \
-K rHZLD2ONRsGR2BreFxCmKAULhlk6PXq6D9cNGjc1 upload Test_Seowon ./Motor\ Vehicle\ Registration.pdf  

Motor Vehicle Registration.pdf 라는 업로드된 파일명만 출력된다.  파일이 정상적으로 존재하는지 확인해보자.
swift -V 1.0 -A http://10.211.55.24/auth -U seowon:swift \
-K rHZLD2ONRsGR2BreFxCmKAULhlk6PXq6D9cNGjc1 list Test_Seowon

Motor Vehicle Registration.pdf 라는 파일명이 출력된다.  만약 업로드를 여러개 했다면 모두 출력된다.  참고로 위의 list 명령어 뒤에 나오는 버켓명을 빼고 실행하면, 버켓 리스트가 출력된다.

한가지 특이했었던 점을 얘기해보자면, 사무실에서 글쓴이가 쓰고있는 워크스테이션 (우분투 12.04 64비트 + 버츄얼박스)에 본 매뉴얼과 똑같은 상황을 만들어놓고 몇 가지 테스트를 하기위해 700메가짜리 파일 10개 정도를 Cyberduck의 Amazon S3 API를 통해 업로드하였다.  그리고서 OSD 노드 중 아무거나 하나를 골라 /var/lib/ceph/osd/ceph-?/current/ 디렉토리에 있는 수백개의 디렉토리 중 대략 50여개를 삭제한뒤 다시 Cyberduck으로 접속해서 업로드했었던 파일들의 다운로드를 시도하였다.

결과는 당연히 실패.  물어보나마나다.  실패를 해야 당연한 거다.  그런데 위에 언급했었던 "특이"했었다는 사항이, 위의 테스트 후 대략 이틀 뒤에 Ceph 클러스터의 성공적인 설치를 글쓴이의 사수에게 보고했었고, 사수는 나름 테스트를 하기위해서 글쓴이가 올린 ISO를 다운받으면서 "속도는 그런대로 괜찮네" 그러는 것이었다.  설마 그럴리가 없어서 "다운로드 실패할텐데?"라고 했더니 잘된다는 것이었다.  그래서 상황을 얘기했더니 글쓴이의 사수 왈 "아마도 자가치유능력이 있는게 아닐까" 라고 얘길해줬고, 분명 수십개의 디렉토리를 삭제하고나서 파일 다운로드가 안되는걸 글쓴이의 눈으로 확인을 했던터라 정말 보고도 믿을 수 없었다.  스토리지의 자가치유능력이라는게 과연 가능한건가...

 

이로써 실행해보기로 했었던 모든 테스트를 완료했다.

후기편으로...

 

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

이번 편에서는 RADOS Gateway를 이용한 Amazon S3 및 OpenStack Swift API 사용법이 되겠다.

Ceph에 스토리지 접근을 위한 몇 가지 API를 내장하고 있는데 현재 많이 쓰이는 Amazon S3와 오픈스택의 Swift API를 내장하고 있다.  다만 Swift API의 경우 현재로서는 버전 1.0만 지원하고 있으며, 글쓴이의 경험으로는 Swift는 아무리 애를 써도 SSL로는 작동을 못시키겠더라.  또한, Swift를 지원하는 FTP 클라이언트, 예를 들어 Cyberduck 같은 유명 FTP 클라이언트를 이용한 Swift 접속 역시 아무리 애를 써도 제대로 작동되지 않는다.  그렇다면 대체 어떤 식으로 작동을 했느냐 하면…  Swift client가 설치된 리눅스 컴퓨터에서 터미널 열고 명령어를 치는 것으로 동작을 확인할 수 있었다.  동작은 제대로 잘 됐지만 리눅스 터미널에서의 swift 명령어 사용을 제외한 나머지는 하나도 되는 게 없었다.

Amazon S3의 경우는 위에서 언급한 맥/윈도우용으로 절대적이라고 할 수 있을만큼 유명한 Cyberduck에서 테스트를 실시해봤으며, 리눅스에서는 DragonDisk라는 멀티플랫폼 FTP Client를 사용해서 테스트를 실시했다.  모두 이상없이 잘 진행됐었다.

Ceph에서는 RADOS (글쓴이가 사는 곳에서는 "레이도스" 라고 읽는다)라는 Ceph 클러스터의 기초가 되는 개념의 오브젝트 스토어 모델이 Ceph의 핵심을 이루고 있으며 게이트웨이, 다시말하자면 결국 RESTful API를 통해서 스토리지에 접근할 수 있는 몇가지 방법을 제시하고 있다.  API의 종류로는, 위에 언급한 Amazon S3, Swift v1.0, Block device, CephFS, Object Store, 그리고 Admin용 API가 제공되고 있다.

설치를 시작해보자.  API의 제공형태는 REST이므로 당연하게도 웹서버가 필요하다.  여기에 FastCGI 모듈이 필요하다.  Apache2-HTTPS 관련 설명은 제외토록 한다.  이 매뉴얼 보면서 따라하시는 분들이라면 다들 기본 장착하셨을거라고 생각한다.

sudo apt-get install apache2 libapache2-mod-fastcgi

설치가 끝나면 ReWrite 모듈과 FastCGI 모듈을 켜준다.

sudo a2enmod rewrite
sudo a2enmod fastcgi
sudo a2enmod ssl 

공식문서에는 아파치 서버를 툭하면 재시작해주는데, 우리는 한 번에 설정해서 끝내도록 해보자.   어느정도 기본적인 설정이 됐으면 RADOS Gateway와, 필요한 분에 한해서 SSL 인증서를 생성/설치한다.

sudo apt-get install radosgw
sudo mkdir /etc/apache2/ssl
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2049 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

 

이번에는 ceph.conf 파일에도 몇가지 설정의 추가가 필요하다.  일단, 아래와 같이 입력한다.

[client.radosgw.gateway]
host = ceph
keyring = /etc/ceph/keyring.radosgw.gateway
rgw socket path = /tmp/radosgw.sock
log file = /var/log/ceph/radosgw.log
rgw dns name = ceph

참고로, host 네임은 FQDN이 아니라 반드시 머신의 hostname을 적어줘야한다.  그외 공식문서에 의하면 자기네들이 수정해서 배포하는 FastCGI를 사용하지 않을거라면 반드시 다음의 라인을 추가하라고 한다.

rgw print continue = false

설정이 다된 ceph.conf 파일을 OSD 노드들에도 똑같이 전송해준다.  

데이터용 디렉토리를 생성한다.
sudo mkdir -p /var/lib/ceph/radosgw/ceph-radosgw.gateway

 

이제는 아파치의 버츄얼 호스트를 수정할 시간이 왔다.  여기서 본 매뉴얼을 보시는 분들에 따라 다양한 형태의 세팅이 나오기 때문에 자세한 설명은 생략하겠다.  본 매뉴얼은 80번 포트에서 Swift, 443번 포트에서 Amazon S3의 API를 제공하는 경우로 설정을 한다.

FastCGI 설정을 해야하는데, 당연히 http/https 모두 돌아가야한다.  /etc/apache2/ports.conf 파일을 열어서 다음 라인 2줄을 삭제하거나 주석처리한다.

NameVirtualHost *:80
Listen 80 

그런 다음 아래의 라인을 삽입한다.

FastCgiExternalServer /var/www/s3gw.fcgi -socket /tmp/radosgw.sock

/var/www/s3gw.fcgi 작성은 밑에서 따로 설명한다.  이제 버츄얼 호스트 파일을 작성해야하는데, 기존의 설정파일은 그냥 보존하는 의미에서 새로운 파일들을 작성한다.

sudo touch /etc/apache2/sites-available/{rgw,rgw-ssl}

rgw부터 작성해보자.  파일이름에서 유추할 수 있듯, http에서 작동될 Swift v1.0 API다.  일단 꼭 들어가야하는 라인을 붙여드리고, 그 밑에 글쓴이의 실제 서버에서 작동 중인 파일을 첨부해드린다.

파일 맨 상단에 아래의 두 줄을 넣어준다.  위에 ports.conf에서 삭제했으니, 다시 넣어주는 것일 뿐이다.
NameVirtualHost *:80
Listen 80 

<VirtualHost *:80> 아래에 들어가야할 부분은 다음과 같다.
RewriteEngine On
RewriteRule ^/([a-zA-Z0-9-_.]*)([/]?.*) /s3gw.fcgi?page=$1&params=$2&%{QUERY_STRING} E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L] 

<IfModule mod_fastcgi.c>

    <Directory /var/www/>
        Options +ExecCGI
        AllowOverride All
        Order allow,deny
        allow from all
        AuthBasicAuthoritative Off
    </Directory>
</IfModule>

아래의 두 줄을 </VirtualHost > 끝나기 전 아무데나 삽입해준다.
AllowEncodedSlashes On
ServerSignature Off 

rgw-ssl 파일은 사실 위의 파일과 크게 다를 건 없다.  단지 첫 줄에 <IfModule mod_ssl.c><VirtualHost _default_:443> 내지는 <VirtualHost *:443>이 들어가있는지, 그리고 SSL 인증서 관련 부분만 확인하면 된다.
첨부파일: rgw

이제 CGI 파일을 작성하자.  /var/www/s3gw.fcgi 파일을 생성해서 다음의 두 줄을 넣고 저장한다.
#!/bin/sh
exec /usr/bin/radosgw -c /etc/ceph/ceph.conf -n client.radosgw.gateway

위 파일에 쓰기 권한을 준다.
sudo chmod +x /var/www/s3gw.fcgi 

기본으로 설정되어있는 버츄얼 호스트를 내리고, 새로 작성한 위의 두 파일을 올리자.
sudo a2dissite default
sudo a2ensite rgw
sudo a2ensite rgw-ssl 

 

Ceph키를 생성해줘야하는데 그냥 아래의 다섯 줄을 그냥 치면 된다.
sudo ceph-authtool --create-keyring /etc/ceph/keyring.radosgw.gateway
sudo chmod +r /etc/ceph/keyring.radosgw.gateway
sudo ceph-authtool /etc/ceph/keyring.radosgw.gateway -n client.radosgw.gateway --gen-key
sudo ceph-authtool -n client.radosgw.gateway --cap osd 'allow rwx' --cap mon 'allow r' /etc/ceph/keyring.radosgw.gateway
sudo ceph -k /etc/ceph/ceph.keyring auth add client.radosgw.gateway -i /etc/ceph/keyring.radosgw.gateway

설치 및 설정이 모두 끝났다.  아파치와 Ceph를 재시작해주고 새로운 서비스 데몬인 radosgw를 시작해주면 된다.
sudo service ceph restart
sudo service apache2 restart
sudo /etc/init.d/radosgw start

참고로, 위의 Ceph 재시작 명령어에서 -a가 붙지않은 이유는 모든 서비스를 재시작할 필요가 없기 때문이고, 따라서 빠르게 재시작이 가능하다.
이로서 설치는 끝났다.  CGI 스크립트가 제대로 작동되는지를 보려면, 웹브라우저를 열고 접속해보면 된다.

 

다음 편에서는 API를 이용하는 방법을 알아본다.

다음 편에서...

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

이번 편에서는 지금까지 구축해놓은 2-3대의 Ceph 클러스터를 어떻게 활용할 수 있는지에 대해서 알아보도록 한다.  구축을 하기는 했는데, 과연 어떻게 자료를 저장을 할 수 있는지, 다른 서버에 어떻게 붙이고, 접속은 어떻게 하는지에 대해서 몇가지 소개를 하도록 한다.  역시 마찬가지지만 글쓴이가 해본 것들에 대해서만 소개를 해드리며, Hadoop과 오픈스택 노바 볼륨으로 붙이는 건 환경상 제외한다.  오픈스택에 통합시키는건 꼭 보여드리고 싶었는데, 매뉴얼을 작성하기 위해 devstack을 구축하고 예제를 위한 인스턴스를 생성하고…  상상만 해도 이건 온라인 매뉴얼이 아니라 책이 되어가는 느낌이다.  참고로 말씀드리면, 오픈스택에 노바 볼륨으로 통합시키는건 아주 쉽다.  인터넷에 비록 영어이긴 하지만 잘 정리해놓은 블로그들이 많다.  꼭 필요하신 분들은 그것을 참고하시고 성공적으로 잘 되면 글쓴이처럼 한 편의 매뉴얼 작성을 부탁드린다.  본 매뉴얼에 붙여나가다보면 정말 한 권의 책이 되지않을까 싶다.

앞으로 소개를 해드릴 내용은,

1.  Mount 명령어를 이용한 Ceph FS 연결
2.  RADOS Gateway를 이용한 Amazon S3 및 OpenStack Swift API 사용법

정도가 되겠다.  1번은 간단하지만 2번은 아주 간단하지만은 않다.  개인적으로 아직 풀리지 않는 의문도 좀 있다.

 

1.  Mount 명령어를 이용한 Ceph 파일시스템 연결

Mount 명령어를 이용한 Ceph 파일시스템을 연결하는 방법이 가장 단순하고 간편하다.  Ceph의 common 패키지가 필요하므로, 앞서 2번째 편에서 설명했던 패키지 소스를 추가하여 ceph 패키지를 설치한다.  mount 명령어 사용법은 다음과 같다.

mount -t ceph Ceph_모니터노드_주소:6789:/ 마운트할_경로 -vv -o name=admin,secret=키링_패스워드

Ceph 모니터 노드의 주소란, /etc/ceph/ceph.conf에 [mon.a] 섹션에 지정된 노드의 주소를 의미한다.  본 매뉴얼에서는 Ceph 노드에서 모니터와 메타데이터 서버를 모두 담당하기로 했으니, ceph 노드의 IP 주소를 적으면 되겠다.  만약 모니터 노드가 2개 이상이시면 쉼표를 붙여서 추가시키면 된다.

얘) 10.211.55.24:6789,10.211.55.25:6789,10.211.55.26:6789:/

마운트할 경로는 알아서 정하시면 되겠다.  여기서는  /mnt로 한다.

키링 패스워드란, /etc/ceph/ceph.keyring에 적힌 패스워드를 의미한다.  따라서, 글쓴이의 명령어를 적으면 다음과 같이 된다.

$ mount -t ceph 10.211.55.24:6789:/ /mnt -vv -o name=admin,secret=AQCDHopRoE74CRAAtOcubIrEM9/6r+4n09cT1g==


성공적으로 연결됐을시 다음과 같은 메시지가 나오게 된다.
parsing options: rw,name=admin,secret=AQCDHopRoE74CRAAtOcubIrEM9\/6r+4n09cT1g==

mount 명령어와 df 명령어로 확인해보자.

$ mount
10.211.55.24:6789:/ on /mnt type ceph (name=admin,key=client.admin)

$ df -m
10.211.55.24:6789:/    185453 16488    168965   9% /mnt

30 기가바이트짜리 하드디스크가 2개 달린 OSD노드가 총 3개이므로 30x6 = 180기가바이트.  맞게 표시된다.  테스트 머신을 하나 더 구성할 수 있거나 주변에 사용 가능한 리눅스 컴퓨터가 있다면 ceph-common 패키지를 설치하고 마운트를 또 해보자.  복수의 컴퓨터에서 마운트가 가능하다.  오브젝트 스토리지이므로 분명 파일의 입출력 속도는 빠를 것이다.  글쓴이도 아직 제대로된 테스트를 해보지 못해서 확실히는 모르겠다.

 

다음 편에서...

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

이번 편에서는 OSD를 추가로 설치해야할 상황에서 수동으로 추가하는 방법을 알려드린다.  기존의 OSD에 하드디스크 하나를 더 추가하는 것과 절차는 동일하다.  단지, 같은 host명을 사용하느냐 아니냐일 뿐만 다르다.  지금껏 잘 따라오신 분은 이미 눈치 채셨겠지만, 저장된 자료가 지워지는 부분에 대해서 상관만 없다면 osd 디렉토리를 전부 삭제하고 설치단계에서 진행했었던 mkcephfs 명령어를 통해 한 번에 수십 수백대의 OSD를 다시 설정할 수도 있다.

우분투를 설치하고 Ceph 패키지를 설치하는 하는 것까지는 똑같다.  물론, ceph.conf 파일을 넣어주고 /etc/hosts에 osd-2를 등록해주는 것, 새로운 osd의 root 패스워드를 설정하고, ceph로부터 root의 ssh-copy-id 명령어를 이용한 키 복사 역시 동일하게 설정하면 되겠다.  사실상, 이전편에서 mkcephfs 명령어 이전까지는 동일한 진행을 하면 된다.

새로 붙일 OSD의 이름은 osd-2로 정하고, 1편에서 정한대로 10기가의 OS 설치용 하드디스크 하나, 그리고 osd용 30기가짜리 하드디스크 2개를 생성해서 우분투 12.04 64비트를 설치하고 apt-get dist-upgrade와 Ceph 패키지 설치를 완료했다.  파티션을 생성해서 ext4로 포맷을 하고 /var/lib/ceph/osd/ceph-4와 /var/lib/ceph/osd/ceph-5라는 디렉토리를 생성해서 user_xattr 옵션과 함께 마운트를 시킨 상태이다.  꼭 기억해야할 사항이, /etc/hosts에 osd-2를 추가시킨뒤 root 사용자로 변경해서 ssh-copy-id osd-2를 잊지말자.

이제 추가를 해보자.  Ceph 노드로 옮겨서 편의상 root로 사용자를 변경하고 아래의 명령어를 실행해보자.

# ceph osd create

그러면 아주 간단하게 딱 4 라는 글자만 찍힐 것이다.  방금 새로 설치한 OSD-2 노드는 하드디스크가 2개이므로, 위의 명령어를 한 번 더 실행한다.  역시 예상대로 5라는 숫자가 찍힐 거다.  이제 /etc/ceph/ceph.conf 파일을 열어서 새로운 osd를 추가해주자.

[osd.4]
host = osd-2

[osd.5]
host = osd-2

만약, 새로운 OSD 노드를 설치하지 않고 기존의 OSD 노드, 예를 들어 OSD-1 노드에 하드디스크 2개를 더 추가한 것이라면 host 주소만 바꿔주면 된다.  설정 자체는 아주 간단하고 쉽다고 볼 수 있겠다.  편집이 끝났으면, /etc/ceph/ceph.conf 파일을 예상대로 osd-0, osd-1, 그리고 새로 만든 osd-2 노드의 /etc/ceph/ 디렉토리에 전송하자.  osd-2의 경우는 /etc/ceph/ 디렉토리에 아무것도 없을테니, /etc/ceph/ceph.keyring 파일도 같이 전송해야한다.

전송이 끝났으면, osd-2 노드에 root로 접속해서 아래의 명령어를 실행한다.

ceph-osd -i 4 --mkfs --mkkey
ceph-osd -i 5 --mkfs --mkkey 

실행하면 글자와 숫자들이 주르륵 올라가면서 error라는 글자나, failed, No such file or directory 등의 메시지가 눈에 띄일텐데 신경쓰지 않아도 된다.  2편에서 mkcephfs를 실행했을 때처럼 새로운 하드디스크에 아무 것도 없기 때문에 나오는 메시지라고 보면 되겠다.

마지막으로 아래의 명령어를 실행한다.

ceph auth add osd.4 osd 'allow *' mon 'allow rwx' -i /var/lib/ceph/osd/ceph-4/keyring
ceph auth add osd.5 osd 'allow *' mon 'allow rwx' -i /var/lib/ceph/osd/ceph-5/keyring 

화면에 added key for osd.4, added key for osd.5 라는 메시지가 뜰 것이다.  접속을 끊고 Ceph노드로 돌아가자.  이제 OSD 노드에서 할 일은 없다.

osd-4와 5가 제대로 붙었는지 확인을 해보자.

# ceph osd tree 
# id    weight  type name       up/down reweight

-1      4       root default
-3      4               rack unknownrack
-2      2                       host osd-0
0       1                               osd.0   up      1
1       1                               osd.1   up      1
-4      2                       host osd-1
2       1                               osd.2   up      1
3       1                               osd.3   up      1
4       0       osd.4   down    0
5       0       osd.5   down    0

새로 등록한 4와 5가 보이고, 현재는 비활성화 되어있는 것을 알 수 있다.  이 2개의 osd를 같은 pool에다 올리자.

# ceph osd crush set 4 osd.4 1.0 pool=default rack=unknownrack host=osd-2 
updated item id 4 name 'osd.4' weight 1 at location {host=osd-2,pool=default,rack=unknownrack} to crush map

# ceph osd crush set 5 osd.5 1.0 pool=default rack=unknownrack host=osd-2
updated item id 5 name 'osd.5' weight 1 at location {host=osd-2,pool=default,rack=unknownrack} to crush map

이제 다시 트리를 확인해보자. 

# ceph osd tree
# id    weight  type name       up/down reweight

-1      4       root default
-3      4               rack unknownrack
-2      2                       host osd-0
0       1                               osd.0   up      1
1       1                               osd.1   up      1
-4      2                       host osd-1
2       1                               osd.2   up      1
3       1                               osd.3   up      1
-5      0                       host osd-2
4       0                               osd.4   down    0
5       0                               osd.5   down    0

ceph osd crush set 4 osd.4 pool=default rack=unknownrack host=osd-2
ceph osd crush set 5 osd.5 pool=default rack=unknownrack host=osd-2

다 좋은데 osd가 다운되어있는 것이 보인다.  이것을 활성화시키려면 osd를 그냥 재시작해주기만 하면 된다.  간단하다.

# service ceph -a start osd.4
=== osd.4 ===
Starting Ceph osd.4 on osd-2...
starting osd.4 at :/0 osd_data /var/lib/ceph/osd/ceph-4 /var/lib/ceph/osd/ceph-4/journal

# service ceph -a start osd.5
=== osd.5 ===
Starting Ceph osd.5 on osd-2...
starting osd.5 at :/0 osd_data /var/lib/ceph/osd/ceph-5 /var/lib/ceph/osd/ceph-5/journal

끝이다.  이제 다시 트리를 확인해보자.

 

# ceph osd tree 
# id    weight  type name       up/down reweight

 

-1      4       root default
-3      4               rack unknownrack
-2      2                       host osd-0
0       1                               osd.0   up      1
1       1                               osd.1   up      1
-4      2                       host osd-1
2       1                               osd.2   up      1
3       1                               osd.3   up      1
-5      2                       host osd-1
4       1                               osd.4   up      1
5       1                               osd.5   up      1

스토리지의 상태를 확인해보자.

~# ceph -s
   health HEALTH_OK
   monmap e1: 1 mons at {a=10.211.55.24:6789/0}, election epoch 1, quorum 0 a
   osdmap e23: 6 osds: 6 up, 6 in
    pgmap v150: 960 pgs: 960 active+clean; 8699 bytes data, 7064 MB used, 165 GB / 181 GB avail
   mdsmap e11: 1/1/1 up {0=a=up:replay} 

HEALTH_OK라고 나오고, 6 osds: 6 up이라고 나오면 osd 6개 모두 올라와있고 상태는 OK라는 뜻이니, 모두 이상이 없다.  이로서 OSD 추가설치는 끝났다.  다음 편에서는 이렇게 구축해놓은 스토리지 클러스터를 어떻게 사용할 수 있는지에 대해서 알아본다.

다음 편에서...

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

이제는 실제 Ceph와 OSD의 구성파일들이 저장되는 위치와 관련 파일들을 세팅해주는 단계이다.  역시, 간단하고 쉽고 크게 어려운 것은 없다.  이번 편부터는 터미널을 3개 띄우던지 tmux나 screen등 편하신대로 취향에 맞춰, ceph, osd-0 그리고 osd-1의 터미널을 모두 열어서 작업하는 것을 추천한다.

일단 본 매뉴얼에서는 이전 편에서 언급했듯, ceph는 MDS와 모니터만, osd-0과 osd-1에서는 osd를 사용한다고 했다.  따라서, 먼저 ceph에 모니터와 메타데이터 디렉토리를 생성해준다.

sudo mkdir -p /var/lib/ceph/mon/ceph-a
sudo mkdir -p /var/lib/ceph/mds/ceph-a 

앞서 몇번 얘기했지만 네이밍 센스가 참 어처구니 없다.  설정파일에서는 mon.a라고 해놓구서 디렉토리는 ceph-a로 작성하는건 또 뭔지.  이번에는 osd-0으로 이동해서 osd용 디렉토리를 생성해줘야하는데,  osd-0과 1에 있는 2개의 osd용 하드디스크는 아직 포맷을 하지 않은 상태이다.  1편에서 일단 포맷을 하지말고 넘어가라고 설명했던 이유는 여기서 어떠한 파일시스템으로 포맷을 할건지 결정하기 위한 설명을 드리기 위함이다.

먼저 Ceph의 공식문서에 의하면, Ceph는 B-Tree FS (btrfs)나 XFS를 사용할 것을 추천한다.  그런데, btrfs는 아직 정식으로 사용하기에는 아직 불안한 감이 많기때문에 본 매뉴얼에서는 btrfs은 선택하지 않는다고 가정한다.  따라서, xfs로 포맷을 해볼 수도 있겠다.  물론 우리의 친구 ext4로 포맷해도 상관없다.  글쓴이는 둘 다 해봤다.  여기서, 둘 중 뭘로 포맷을 하느냐에 따라 해줘야할 작업이 한 가지씩 나뉜다.  일단은 먼저 osd 디렉토리부터 만들자.  아래의 디렉토리가 곧 마운팅 포인트가 된다.

osd-0에서
sudo mkdir -p /var/lib/ceph/osd/ceph-0
sudo mkdir -p /var/lib/ceph/osd/ceph-1

osd-1에서
sudo mkdir -p /var/lib/ceph/osd/ceph-2
sudo mkdir -p /var/lib/ceph/osd/ceph-3

 

현재 파티션 테이블이 존재하지 않을테니 파티션을 생성해주고 포맷을 한다.  osd-0과 osd-1의 2개 하드디스크 모두 실시한다.
예)  sudo fdisk /dev/sdb -> n -> p -> 엔터 -> 엔터 -> 엔터 ->wq
sudo mkfs.ext4 /dev/sdb1 

 

1. XFS로 포맷할 경우

/etc/ceph/ceph.conf 파일을 열어서 filestore xattr use omap = true 라인을 삭제한다.  그렇다.  해당 라인은 ext4를 위한 옵션이다.  그리고 위에 생성해준 마운팅 포인트로 마운트를 한다.  다음번 부팅시 Ceph클러스터가 제대로 작동되려면 /etc/fstab에도 당연히 추가를 시켜줘야하겠다.

osd-0에서
sudo mount /dev/sdb1 /var/lib/ceph/osd/ceph-0
sudo mount /dev/sdc1 /var/lib/ceph/osd/ceph-1 

osd-1에서
sudo mount /dev/sdb1 /var/lib/ceph/osd/ceph-2
sudo mount /dev/sdc1 /var/lib/ceph/osd/ceph-3

 

2. EXT4로 포맷할 경우
마운트 옵션에 반드시 user_xattr이 들어가야한다.  /etc/fstab를 열어서 마운팅에 user_xattr을 넣어준다.  현재 시점에서는 마운트만 하면 되므로 옵션을 줘서 마운트를 한다.

osd-0에서
sudo mount -o user_xattr /dev/sdb1 /var/lib/ceph/osd/ceph-0
sudo mount -o user_xattr /dev/sdc1 /var/lib/ceph/osd/ceph-1 

osd-1에서
sudo mount -o user_xattr /dev/sdb1 /var/lib/ceph/osd/ceph-2
sudo mount -o user_xattr /dev/sdc1 /var/lib/ceph/osd/ceph-3

fstab 예: 
UUID=e2af1baa-4ca2-434b-8bce-807a9e2e61f3 /var/lib/ceph/osd/ceph-0  ext4  user_xattr  1 2
UUID=5b055bb2-2875-4dcb-bda9-c963e966c7b9 /var/lib/ceph/osd/ceph-1  ext4  user_xattr  1 2 

다만 여기서 문제가, Ceph의 공식문서에는 Dump와 Pass값에 대한 언급이 없다는 점이다.  글쓴이는 1 2로 했다.  아무래도 1 2가 맞는 것 같다.

mount 명령어를 쳤을 때 user_xattr이 나와야 제대로 된 거다.

/dev/sdb1 on /var/lib/ceph/osd/ceph-0 type ext4 (rw,user_xattr)

 

다 됐으면 마지막 준비작업으로 /etc/ceph/ceph.conf 파일을 OSD 노드들에게도 똑같이 보내줘야한다.  모든 Ceph 클러스터 노드들은 반드시 같은 내용의 ceph.conf 파일을 갖고있어야한다.

sudo scp /etc/ceph/ceph.conf osd-0:/etc/ceph/
sudo scp /etc/ceph/ceph.conf osd-1:/etc/ceph/

 

이제서야 드디어 클러스터를 구성하라는 명령어를 내리는 단계에 왔다.  명령어는 달랑 한 줄이다.  ceph 노드에서 실시한다.  앞으로는 특별한 일이 없으면 osd-0과 osd-1은 건드리지 않는다.
sudo mkcephfs -a -c /etc/ceph/ceph.conf -k /etc/ceph/ceph.keyring

명령어를 실행하고나면 뭔가 글씨가 주르륵 올라가는데 메시지가 길기 때문에 스크롤상 생략한다.  일단 여기서 나오는  No such file or directory 메시지는 무시해도 된다.  파일이 없는건 당연하기 때문이다.  하지만 빨간 글씨로 뭔가가 나왔다거나 failed라는 메시지가 보인다면 제대로 되지않았다는 얘기다.  마운트 포인트를 확인하고 각각의 하드디스크가 각자의 마운팅 포인트에 마운트가 제대로 됐는지 확인을 하고, 모두 이상이 없으면 /var/lib/ceph/osd/ceph-?/, /var/lib/ceph/mon/ceph-a/, /var/lib/ceph/mds/ceph-a/ 디렉토리에 밑에 있는 파일과 디렉토리들은 모두 수동으로 삭제를 해줘야 위의 명령어를 다시 실행할 수 있다.  또한, OSD 노드들의 /var/lib/ceph/osd/ 디렉토리에 가서 ls 명령어를 쳐보면 알 수 없는 파일들이 조금 있는데, osd 디스크 하나당 대략 1기가바이트 정도의 용량을 차지하는 것을 볼 수 있다.

위의 명령어를 실행하고나면, OSD 2대에 각각 2대의 하드디스크 즉, 총 4개의 OSD 스토리지를 세팅하게되는데, 시간은 불과 몇초 안걸린다.  명령어를 실행하고나면 /etc/ceph 디렉토리에 ceph.keyring이라는 파일이 보일 것이며, 이것의 권한을 644로 변경해준다.

이제 Ceph의 서비스 데몬을 실행해주자.
sudo service ceph -a start

대략 아래와 같은 화면이 나온다.

=== mon.a ===
Starting Ceph mon.a on ceph...
starting mon.a rank 0 at 10.211.55.24:6789/0 mon_data /var/lib/ceph/mon/ceph-a fsid 1d703392-a1b4-4588-880e-a699207f8c8d
=== mds.a ===
Starting Ceph mds.a on ceph...
starting mds.a at :/0
=== osd.0 ===
Starting Ceph osd.0 on osd-0...
starting osd.0 at :/0 osd_data /var/lib/ceph/osd/ceph-0 /var/lib/ceph/osd/ceph-0/journal
=== osd.1 ===
Starting Ceph osd.1 on osd-0...
starting osd.1 at :/0 osd_data /var/lib/ceph/osd/ceph-1 /var/lib/ceph/osd/ceph-1/journal
=== osd.2 ===
Starting Ceph osd.2 on osd-1...
starting osd.2 at :/0 osd_data /var/lib/ceph/osd/ceph-2 /var/lib/ceph/osd/ceph-2/journal
=== osd.3 ===
Starting Ceph osd.3 on osd-1...
starting osd.3 at :/0 osd_data /var/lib/ceph/osd/ceph-3 /var/lib/ceph/osd/ceph-3/journal

상태를 체크해보자. sudo ceph health 라는 명령어를 치면 HEALTH_OK 라고 떠야한다.  만약 Warning이 뜨면 몇분정도 기다렸다가 다시 명령어를 내려보거나, 그래도 안되면 서비스 데몬을 재시작 해본다.

이제 마지막으로, 생성된 keyring을 OSD 노드에 보내주면 설치는 모두 끝이다.  위에서 keyring의 권한을 644로 변경해줬는지 꼭 확인하자.

sudo scp /etc/ceph/ceph.keyring osd-0:/etc/ceph/
sudo scp /etc/ceph/ceph.keyring osd-1:/etc/ceph/ 

 

다음 편은 OSD를 추가해야할 경우에 대해서 설명드리도록 한다.

다음 편에서...

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,