読者です 読者をやめる 読者になる 読者になる

めもめも

このブログに記載の内容は個人の見解であり、必ずしも所属組織の立場、戦略、意見を代表するものではありません。

Gluster3.3.0qa34のSwift API利用手順

注意

この記事は、開発版の古いGlusterFSに基づいています。GlusterFS3.3のGA版が公開されていますので、GA版での利用については、こちらの手順を参照してください。

何の話かというと

この記事の内容をコミュニティ版のGlusterFSで試してみる手順です。詳細説明は先の記事にあるので、手順のみを記載します。

構成は次の通りです。

hostname ip 役割
swift01 192.168.122.30/24 Swift APIサーバ
gluster01 192.168.122.31/24 GlusterFSサーバ
gluster02 192.168.122.32/24 GlusterFSサーバ

ここでは、この3台をpeerとするGlusterFSクラスタを構成して、実際のボリュームはgluser01/gluster02のディスクのみを使用して作成します。

事前準備

上記の3台に共通の作業です。

まずは、RHEL6.2を「基本サーバ」構成で導入します。/etc/hostsで名前解決できるようにしておきます。

/etc/hosts

192.168.122.30	swift01
192.168.122.31	gluster01
192.168.122.32	gluster02

GlusterFS3.3.0qa34をインストールして、デーモンを起動します。

# yum localinstall http://bits.gluster.com/gluster/glusterfs/3.3.0qa34/x86_64/glusterfs-3.3.0qa34-1.x86_64.rpm \
 http://bits.gluster.com/gluster/glusterfs/3.3.0qa34/x86_64/glusterfs-server-3.3.0qa34-1.x86_64.rpm \
 http://bits.gluster.com/gluster/glusterfs/3.3.0qa34/x86_64/glusterfs-fuse-3.3.0qa34-1.x86_64.rpm 
# chkconfig glusterd on
# service glusterd start

なお、gluster01/gluster02では、/data以下をボリュームのブリックとして使用しますので、ブリック用のファイルシステムを/dataにマウントしておきます。この時、マウントオプションに「user_xattr」の指定が必要です。/etc/fstabに次のようにuser_xattrを付けておきます。

/etc/fstab

/dev/vda4               /data                   ext4    defaults,user_xattr     0 0

ボリュームの作成

これは、gluster01で作業します。ボリューム「vol01」を作成します。

# gluster peer probe gluster02
# gluster peer probe swift01
# gluster peer status
Number of Peers: 2

Hostname: gluster02
Uuid: b934a8d9-f7fc-4516-8495-c41aeaab3172
State: Peer in Cluster (Connected)

Hostname: swift01
Uuid: 8fcb32d6-f7c3-4ce1-8788-d34f9bd09491
State: Peer in Cluster (Connected)

# gluster volume create vol01 gluster01:/data/brick01 gluster02:/data/brick01
# gluster volume start vol01
# gluster volume info vol01
 
Volume Name: vol01
Type: Distribute
Volume ID: b3f0f714-49a2-4a1d-8da8-da5dedb66e68
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: gluster01:/data/brick01
Brick2: gluster02:/data/brick01

Swift APIサーバの構成

これは、swift01で作業します。

まずは、localhsost指定でボリューム「vol01」がマウントできることを確認しておきます。

# mount -t glusterfs localhost:/vol01 /mnt
# df
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/vda2              5039616   1760300   3023316  37% /
tmpfs                   510344         0    510344   0% /dev/shm
/dev/vda1               198337     27710    160387  15% /boot
localhost:/vol01       4996480    138624   4604032   3% /mnt
# umount /mnt

次の手順で、必要なパッケージを導入します。coverageの導入時にextentionモジュールが入らない警告がでますが、これは無視しておきます。

# yum install memcached openssl python-setuptools python-paste python-paste-deploy python-configobj python-simplejson python-configobj
# easy_install-2.6 coverage
# yum localinstall http://yum.griddynamics.net/yum/diablo/python-greenlet-0.3.1-4.x86_64.rpm \
 http://yum.griddynamics.net/yum/diablo/python-eventlet-0.9.16-gd1.el6.noarch.rpm \
 http://yum.griddynamics.net/yum/diablo/python-webob-1.0.8-0.noarch.rpm \
 http://kojipkgs.fedoraproject.org/packages/python-netifaces/0.5/1.el6/x86_64/python-netifaces-0.5-1.el6.x86_64.rpm \
 http://kojipkgs.fedoraproject.org/packages/pyxattr/0.5.0/1.el6/x86_64/pyxattr-0.5.0-1.el6.x86_64.rpm
# chkconfig memcached on
# service memcached start
# yum install http://download.gluster.com/pub/gluster/glusterfs/3.2/UFO/swift-1.4.5-1.noarch.rpm \
 http://download.gluster.com/pub/gluster/glusterfs/3.2/UFO/swift-plugin-1.0.-1.el6.noarch.rpm
# pushd /etc/swift
# openssl req -new -x509 -nodes -out cert.crt -keyout cert.key -days 36500 -subj "/C=JP/ST=Tokyo/CN=Swift API"
# popd

/etc/swift/proxy-server.confを下記のように編集します。

/etc/swift/proxy-server.conf

[DEFAULT]
bind_port = 8080
user = root
log_facility = LOG_LOCAL1
bind_port = 443
cert_file = /etc/swift/cert.crt
key_file = /etc/swift/cert.key

[pipeline:main]
pipeline = healthcheck cache tempauth proxy-server

[app:proxy-server]
use = egg:swift#proxy
allow_account_management = true
account_autocreate = true

[filter:tempauth]
use = egg:swift#tempauth
#user_<account>_<user name> = <password> [.admin]
user_vol01_admin = pas4vol01admin .admin
user_vol01_user01 = pas4vol01user01

[filter:healthcheck]
use = egg:swift#healthcheck

[filter:cache]
use = egg:swift#memcache
memcache_servers = localhost:11211

最後にSwift APIを起動します。

# swift-init main start
Starting proxy-server...(/etc/swift/proxy-server.conf)
Starting container-server...(/etc/swift/container-server/1.conf)
Starting account-server...(/etc/swift/account-server/1.conf)
Starting object-server...(/etc/swift/object-server/1.conf)

動作確認

まずは、REST APIを直接HTTPで叩いてみます。

認証トークンの取得

[root@swift01 ~]# curl -v -H 'X-Storage-User: vol01:admin' -H 'X-Storage-Pass:pas4vol01admin' -k https://swift01:443/auth/v1.0
* About to connect() to swift01 port 443 (#0)
*   Trying 192.168.122.30... connected
* Connected to swift01 (192.168.122.30) port 443 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* skipping SSL peer certificate verification
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
* 	subject: CN=Swift API,ST=Tokyo,C=JP
* 	start date:  4月 14 01:19:55 2012 GMT
* 	expire date:  3月 21 01:19:55 2112 GMT
* 	common name: Swift API
* 	issuer: CN=Swift API,ST=Tokyo,C=JP
> GET /auth/v1.0 HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
> Host: swift01
> Accept: */*
> X-Storage-User: vol01:admin
> X-Storage-Pass:pas4vol01admin
> 
< HTTP/1.1 200 OK
< X-Storage-Url: https://127.0.0.1:443/v1/AUTH_vol01
< X-Storage-Token: AUTH_tkf1b11da55f4847df9a8944c50329628b
< X-Auth-Token: AUTH_tkf1b11da55f4847df9a8944c50329628b
< Content-Length: 0
< Date: Sat, 14 Apr 2012 01:28:03 GMT
< 
* Connection #0 to host swift01 left intact
* Closing connection #0

コンテナ「container01」の作成

# curl -v -X PUT -H 'X-Auth-Token: AUTH_tkf1b11da55f4847df9a8944c50329628b' https://swift01:443/v1/AUTH_vol01/container01 -k
* About to connect() to swift01 port 443 (#0)
*   Trying 192.168.122.30... connected
* Connected to swift01 (192.168.122.30) port 443 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* skipping SSL peer certificate verification
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
* 	subject: CN=Swift API,ST=Tokyo,C=JP
* 	start date:  4月 14 01:19:55 2012 GMT
* 	expire date:  3月 21 01:19:55 2112 GMT
* 	common name: Swift API
* 	issuer: CN=Swift API,ST=Tokyo,C=JP
> PUT /v1/AUTH_vol01/container01 HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
> Host: swift01
> Accept: */*
> X-Auth-Token: AUTH_tkf1b11da55f4847df9a8944c50329628b
> 
< HTTP/1.1 201 Created
< Content-Length: 18
< Content-Type: text/html; charset=UTF-8
< Date: Sat, 14 Apr 2012 01:28:32 GMT
< 
201 Created

* Connection #0 to host swift01 left intact
* Closing connection #0

この時、swift01上で、vol01がマウントされていることが分かります。

# df
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/vda2              5039616   1780324   3003292  38% /
tmpfs                   510344         0    510344   0% /dev/shm
/dev/vda1               198337     27710    160387  15% /boot
localhost:vol01        4996480    138624   4604032   3% /mnt/gluster-object/AUTH_vol01

swiftコマンドで、ファイルのアップロードを行います。

# date > file01.txt
# swift -A https://swift01/auth/v1.0 -U vol01:admin -K pas4vol01admin upload container01 file01.txt
file01.txt
# swift -A https://swift01/auth/v1.0 -U vol01:admin -K pas4vol01admin list container01
file01.txt

おまけ

複数のSwift APIサーバを立てて負荷分散することも可能です。この場合は、ユーザ認証を外部のKeystoneに委ねる必要があるのですが、Keystoneの設定方法がまだよく分かっていません。。。orz

どなたか、ぜひ、Swift API - Keystone連携に挑戦してください。

「中の人」に問い合わせた所、TempAuth以外のユーザ認証については、現在計画中とのことでした。もともとSwiftの代替のためだけに本機能を開発しているわけではないので、単純にKeystoneと連係させるというわけではなく、GlusterFS環境全体に適用できる統合認証機能の実装を計画しているとのことです。

この記事の手順で構成した場合、コンテナ/オブジェクトに対応するディレクトリ/ファイルのパーミッションが「World Accessible」になるというセキュリティ上の問題があります。これについては、近々、Big Fixされる予定です。(参考