드디어 대망의 마지막 편이다. 이번 편에서는 지난 번 설치한 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의 잡동사니 보관소