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

,

여기서부터 시작되는 설치매뉴얼은 특별한 언급이 없는한 Ceph, OSD-0 그리고 OSD-1 노드 모두 똑같이 실시하는 것으로 한다.  Ceph 노드에서 먼저 실시하고, 이후 OSD-0과 OSD-1 노드에 적용하는 것을 추천한다.

1.  먼저 Ceph로 사용할 컴퓨터 혹은 가상머신 (이하 Ceph라고 함)과 스토리지 용으로 사용할 가상머신 (이하 OSD라고 함)에 우분투 12.04 LTS를 설치한다.  설치 과정 중에 나오는 몇몇 설정은 반드시 아래의 조건을 따른다.

Ceph 노드의 호스트네임은 반드시 ceph로 한다.
첫번째 OSD 노드의 호스트네임은 반드시 osd-0,
그리고 두번째 OSD 노드의 호스트네임은 반드시 osd-1,
마찬가지로 세번째 OSD 노드의 호스트네임은 반드시 osd-2로 한다.

위의 사항이 꼭 "반드시" 지켜야하는 건 아니지만, 본 매뉴얼을 그대로 따라하기 위한 규칙 정도로 생각해주시면 되겠다.  꼭 알고있어야할 점은, Ceph는 hostname을 기준으로 작동한다는 점이다.  계정명은 크게 상관없으니 편한대로 정한다. 

OSD의 경우 우분투가 설치될 첫번째 하드디스크만 포맷하고, 나머지 2개는 추후 설명을 위해 일단 놔둔다. 

2.  sudo -i를 이용해 root로 변경 후 패스워드를 설정한다.
  a. Ceph 노드에서 root의 ssh 키를 만들어줘야한다.  ssh-keygen -t rsa
  b. Ceph 노드에서 ssh-copy-id ceph, ssh-copy-id osd-0 그리고 ssh-copy-id osd-1 명령어로 비밀번호 입력없는 접속을 위한 키를 전송해준다.  Ceph가 OSD 노드간 통신을 위해 SSH를 이용한다.
  c. 또한, 반드시 root의 ssh 접속을 허용해야한다.  /etc/ssh/sshd_config에서 root의 접속이 활성화되어있는지 확인한다.

3.  /etc/hosts 파일을 열어서 ceph, osd-0, 그리고 osd-1 서버 각각의 IP 주소와 호스트명을 똑같이 입력해준다.

4.  sudo apt-get update && sudo apt-get dist-upgrade를 실시하고 재부팅 한다.

5.  이제 Ceph의 저장소를 추가할 차례다.  Ceph가 이미 리눅스 커널에 포함되어있고 우분투/데비안 저장소에도 있긴 하지만, 버전이 워낙 낮은 관계로 (0.41), Ceph의 공식 매뉴얼대로 따라하면 제대로 되지않는다는 문제가 있다.  따라서,  Ceph의 저장소에서 직접 받아서 설치한다.
wget -q -O- 'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc' | sudo apt-key add -
echo deb http://ceph.com/debian-bobtail/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list
sudo apt-get update && sudo apt-get install ceph

6.  Ceph 패키지의 용량이 대략 36메가 가량 되는데, 우리는 이것을 OSD 서버들에도 똑같이 해야하기 때문에 apt-get clean을 하지말고 ceph에서 받아놓은 패키지를 osd-0/1의 /var/cache/apt/archives에 보낸다.

7.  Ceph의 버전을 확인해본다.  Ceph의 패키지 저장소가 제대로 추가되지 않았으면 0.41이 나올 것이고, 제대로 추가됐었다면 2013년 5월 8일 기준, 0.56.6이 표시될 것이다.
$ ceph -v
ceph version 0.56.6 (95a0bda7f007a33b0dc7adf4b330778fa1e5d70c)

8.  Ceph는 불친절하게도 설치시에 설정파일을 제공해주지 않는다.  직접 작성해야하는데, 그나마 다행스럽게 Ceph 문서에서 그대로 갖다붙이면 된다.  크게 어려운 부분은 없다.  일단 전체를 붙이고, 개별적으로 설명한다.  파일의 위치와 이름은 /etc/ceph/ceph.conf 이며, 권한은 644로 설정한다.

[global]
auth cluster required = cephx
auth service required = cephx
auth client required = cephx

[osd]
osd journal size = 1000
filestore xattr use omap = true

[mon.a]
host = {hostname}
mon addr = {ip-address}:6789

[osd.0]
host = {hostname}

[osd.1]
host = {hostname}
#devs = {path-to-device}

[mds.a]
host = {hostname}

[global] 섹션은 따로 건드려줄 건 없다.  ceph와 osd간의 인증방식에 대한 부분인데 어차피 cephx 말고는 다른 옵션이 none 밖에 없기도 하거니와, 이 부분은 none은 절대로 권장하지 않는다고 한다.

[osd] 섹션은 osd 스토리지의 저널 사이즈를 지정하거나 위치 등을 지정할 수 있는데, 사실 공식문서에도 전혀 설명이 없다.  따라서 공식문서에서 제공하는 옵션을 그대로 사용하기로 한다.  다만, filestore xattr use omap = true 라인은 다음편에서 설명할 osd 하드디스크를 위해 눈여겨보는 정도만 한다.

[mon.a] 섹션은 Ceph의 스토리지 클러스터를 모니터링하는 호스트를 지정하는 부분이다.  host = {hostname}에서 중괄호친 부분을 ceph라고 바꾼다.  host = ceph  만약 ceph 노드의 호스트네임을 ceph로 설정하지 않았다면 이 부분에서 따로 지정한 호스트네임을 넣는다.  하지만, Ceph의 작동은 호스트네임이 지대한 영향을 미치기 때문에 본 매뉴얼에서는 되도록 ceph로 지정할 것을 권하는 바이다.  참고로, Ceph에서는 공식적으로 3대 이상의 모니터용 호스트를 둘 것을 권고한다.  두번째 모니터라면 [mon.b]가 되며, 세번째 모니터는 [mon.c]가 된다.  네이밍 센스가 참 어처구니 없다.

[osd.0] 섹션과 [osd.1] 섹션은 예상하시는대로 osd가 될 노드의 저장장치를 지정하는 부분이다.  본 매뉴얼의 예제에서는 osd-0과 osd-1에 각각 2대의 OSD용 하드디스크가 있으니, 결국 우리가 쓸 총 osd의 갯수는 4개가 되겠다.  따라서, 아래와 같이 적으면 되겠다.

[osd.0]
host = osd-0

[osd.1] 
host = osd-0

[osd.2]
host = osd-1

[osd.3]
host = osd-1 

위에서 얘기했지만, 네이밍 센스 참 구리다.  당연한 말이지만 host 뒷부분에 나오는건 OSD 노드 각각의 호스트네임이다.

[mds.a] 섹션은 메타데이터 서버를 지정하는 곳이다.  역시 마찬가지로 본 매뉴얼의 예제에서는 ceph로 한다.


따라서 본 매뉴얼에서는, 모니터와 메타데이터로 ceph 서버에 전부 몰아넣어서 사용하기로 하고, 데이터 저장용도로는 osd-0과 osd-1에 장착된 2개의 추가 하드디스크를 사용하게 되는 것이다.

대충 그림

Ceph 공식매뉴얼에 의하면, #devs = {path-to-device} 부분에서 osd로 쓸 디바이스의 장치명을 입력해도 되게끔 주석처리를 해놨지만, 해도 되고 안해도 된다.  안해도 제대로 작동한다.  넣고싶으신 분은 /dev/sdb1 등의 형태로 넣으시면 된다.


다 됐으면, 방금 작성한 우리의 첫 설정파일을 나머지 OSD 노드들에도 똑같이 복사해줘야한다.  위치와 권한은 당연히 똑같다.  Ceph 노드에서 루트 권한으로 scp를 이용해서 보내자.  위치는 /etc/ceph/ceph.conf에, scp로 보내면 권한은 기본값으로 644를 주게된다.

 

다음 편으로...

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

미루고 미룬 Ceph 오브젝트/블럭 스토리지의 설치 매뉴얼 작성을 시작한다...

글쓴이의 소개글에 써있지만 다른 얘기를 추가하자면,
현재 글쓴이가 근무하는 하와이 대학교 사범대학에는 캐노니컬 본사에서 파견나온 오픈스택 기술팀의 지원으로 구축되어진 오픈스택 클라우드 시스템이 운영되는 중이다.  다만, High Availability가 빠진채로 구축되어진 그들의 실력에 너무나도 큰 실망을 하게된 글쓴이의 사수가 이걸 갈아엎고자 오픈스택의 나름 초전문가 집단이라는 Mirantis와 기술지원 협약을 맺고 HA에 Ceph 스토리지를 붙여서 오픈스택 클라우드 시스템 전체를 제대로 구축하려는 계획을 갖고있다.  Ceph를 개발한 사람이 세운 회사인 InkTank와도 글쓴이의 사수가 몇번의 전화통화를 했었는데, 그쪽 입장에서는 아무래도 정부쪽 도입 차원에서의 또다른 케이스 스터디도 될겸 (주립대학은 미국 주정부에서 하나의 부서이다), 어느정도의 기술지원을 해줄 것으로 보인다 (규모가 작긴 해도 주립대학에서 도입하는 것이다보니 나름 이름값은 하나보다).  미란티스 기술지원팀이 6월 중순에 하와이 들어와서 3주간 머무를 예정이며 7월이면 아마 Swift와 Quantum이 제외된 오픈스택 클라우드 시스템을 가질 것으로 예상 중이다.

이에 대비하기 위해, 글쓴이의 사수께서는 Ceph 스토리지 클러스터링 구축에 대한 노하우를 미리 쌓기위해 글쓴이에게 그 임무를 맡겼으며, 대략 3대로 이루어진 클러스터를 가상머신과 실제 서버에 약 5회 정도 설치하고 약간의 테스트를 실시하였다.  시간관계상, 인력관계상, 그리고 여건상 자세한 테스트는 할 수 없었다 (단 두명으로 사범대학 전체 서버를 관리한다).  미국 최대의 컴퓨터 소매점인 Bestbuy에서 최근 Ceph로 스토리지를 갈아탔다고 했는데, OSD용으로 900대를 세팅했다고 한다.  이외 몇군데 케이스가 더 있긴한데 자료가 공개된 게 없어서 자세한 건 알 수 없지만, Ceph가 이젠 더 이상 프로젝트 단계는 아닌 것만은 분명한 것 같다.  따라서, 자세한 테스트는 글쓴이의 사수도 그냥 믿고 건너뛰는 것 같았다.

 

본 매뉴얼은 Ceph 오브젝트/블럭 스토리지 클러스터를 우분투 리눅스 서버에 설치하는 방법을 기술한 매뉴얼이다.  매뉴얼이라고 얘기했지만 사용법에 대한 매뉴얼이 아니라 "설치법"에 대한 매뉴얼이다.  설치한 환경은 맥북과 패러럴즈를 이용하여 매뉴얼을 작성했지만, 실제 글쓴이는 맥북+패러럴즈 뿐만 아니라 리눅스+버츄얼박스와 실제 서버까지 합쳐 대략 5번 이상 설치를 해봤다고 위에 이미 언급했으므로, 분명히 "된다" 라고 말씀드린다.  따라서, 설치환경은 크게 문제가 되지않으므로 그냥 넘어가고 준비물에 대해 설명한다.

1.  본 매뉴얼을 따라할 수 있는 컴퓨터 최소 3대 이상 혹은 버츄얼박스/VMware/패러럴즈 등의 가상머신 프로그램
2.  만약 가상머신으로 실습해보실 분이라면, 3대 이상의 가상머신을 굴릴 수 있는 CPU와 램, 그리고 하드디스크 용량
3.  리눅스와 네트워크, 그리고 터미널 사용에 대한 충분한 상식

설치에 앞서 본 매뉴얼을 따라하는데 필요한 환경을 설정하고 그외 몇가지 사항에 대해 설명한다.

1.  필요한 서버: Ceph 1대, OSD 3대
2.  Ceph 노드에는 하나의 운영체제용 하드디스크만 있으며, 자료 저장 용도(osd)로는 사용하지 않는다.
3.  OSD 노드에는 3대의 하드디스크가 있으며 하나는 리눅스 OS 설치 및 운영용이며 나머지 2대는 Ceph 스토리지 클러스터용(osd)이다.
4.  각각의 OSD 노드에는 2기가의 램, OS 설치용으로는 10기가 하드디스크, 그리고 OSD용으로 30기가 하드디스크 2개씩을 생성한다. 
5.  OSD용으로 할당하는 2개의 하드디스크는 절대로 LVM으로 묶지 않도록 한다.  다만, 하드웨어 RAID 카드에 의한 RAID-0은 괜찮다.
5.  세번째 OSD 노드는 OSD 추가설치에 대해 설명할 예정이므로 기본적인 설치는 생략한다.
6.  글쓴이는 우분투 한국 로코팀의 공식 컨택터이므로, 운영체제는 모두 우분투 12.04 LTS 64비트판으로만 설명한다 (32비트로는 해보질 않았지만, 32비트로 스토리지 서버 운영하는 곳은 없을 거라고 본다).
7.  Ceph에 대한 개념이나 기타 용어 설명 등은 여기나 혹은 구글을 참고하시고, 본 매뉴얼은 전적으로 Ceph의 공식 문서를 보고 작성했다.  참고로, Ceph 공식문서는 제대로 완성되지 않은게 많고, 최신 버전이 반영되어있지 않으며, 게다가 군데군데 대충 건너뛴 부분도 많다.
8.  Ceph나 오픈스택 공식 문서에 의하면, 오픈스택에 Ceph 스토리지를 붙여서 사용하는 방법이나 Keystone 통합인증방법 등에 대한 설명이 있긴하지만, 오픈스택에 관련된 부분에서는 글쓴이의 개인 컴퓨터에 오픈스택을 구축해서 시연하는 것을 보여주는 것이 쉽지않기 때문에 이 부분은 생략한다.
9.  DevStack은 완전한 오픈스택 시스템이라고 하기에는 좀 뭔가 부족한데다, 여러가지 설정과 경로가 조금 다르기 때문에 역시 제외한다 (글쓴이가 수도없이 많이 해봤는데, 이게 가상머신이라 안되는건지 devstack이라 안되는건지 알 수가 없어서 포기했다).  개인적인 의견으로는, devstack은 "오픈스택이란 대충 이런거다" 라고 맛만 보여주는 정도의 데모 버전이라고 생각한다.
10.  글쓴이가 근무하는 곳의 오픈스택 클라우드 시스템은 이미 여러가지 서비스가 운영되고 있기 때문에 절대 건드릴 수가 없다.  따라서, 어쨌든 오픈스택에 관한 부분은 Swift API에 대한 부분을 제외하고는 모두 생략한다.
11.  5월 7일자로 새로운 안정버전인 CuttleFish가 나왔고, 그러면서 매뉴얼대로 작동되지 않는 부분이 좀 있어서 심하게 많이 당황했었다.  게다가 아직 공식문서에도 제대로 반영이 된게 없어서, 결국 새로운 버전으로 매뉴얼을 제작하는건 에러메시지도 막 건너뛰고 그러는 것이 별로 보기좋지 않아서 이전 안정버전인 Bobtail로 설명하기로 한다.  참고로 CuttleFish는 CentOS에 대한 지원이 강화되었다.  다시 말하자면, 이전 버전까지는 우분투/데비안에서만 공식적으로 돌아갔었다.
12.  파일을 복사해서 각각의 스토리지들이 어떻게 복사가 되고 하는 등의 "테스트"는 진행하지 않는다.  테스트까지 진행할시 너무나도 양이 많아지기 때문에 본 매뉴얼은 전적으로 "설치"와 설치에 대한 확인작업만 설명하며, 테스트는 이 글을 읽는 분들께 부탁드린다.
13.  분명히 틀린 부분도 있을 것이고 잘못 설명한 것도 있을 것이며, 글쓴이가 제대로 이해하지 못한 부분도 있을 것이다.  이 매뉴얼을 작성하기 위해 많은 시간을 투자한 글쓴이를 위해, 이 글을 읽는 분들께 너그러움을 부탁드린다.

 

다음 편으로...

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,