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의 잡동사니 보관소

,