注意
この記事は、開発版の古い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される予定です。（参考）
