OpenStack Storage(Swift) 調査報告書
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
2011年1月18日
1. 概要
Swift は OpenStack プロジェクトが開発している分散オブジェクトストレージである。OpenStack は、クラウド環境を構築するためのオープンソースプロジェクトであり、仮想マシンの管理を行う Nova と、オブジェクトストレージの Swift がある。Swift の位置づけとしては、Nova の仮想マシン のイメージの保存などが挙げられる。しかしオブジェクトストレージの機能は独立しており、Nova と 関係なく利用することも可能である。現行の仕様では、Nova と連携するようにはなっていないため、 本報告書では Swift のみの利用を中心に述べる。
Swift の元になったのは、Rackspace 社の運用する CloudFiles というサービスであった。現在 はオープンソースソフトウェアとして公開されており、開発言語には Python が使用されている。通 信には CloudFiles と同様のプロトコルを使用しており、CyberDuck などのクライアントソフトウェア から利用が可能である。利用形態としては、Amazon S3 のようにファイルをダウンロードすることや、 クライアントからファイルをアップロードする形になる。Swift は複数のサーバから構成されているた め、障害などで 1 台のサーバが利用不能になっても、他のサーバによってサービスを継続すること ができる。またそのための冗長化の設定及び、増設などによる構成変更に伴う設定も容易である。
2. Swift の機能
2.1. 想定する用途
Swift が想定している用途としては、大容量のファイルの取り扱いが挙げられる。例えば、バック アップデータや、静画や動画等のコンテンツ、仮想マシンのイメージ等である。ファイルサイズの上 限は 5GB となっている。
2.2. オブジェクトとコンテナ
Swift での用語として、オブジェクトとコンテナがある。オブジェクトはいわゆるファイルであり、ア ップロードやダウンロードの対象になる。コンテナはオブジェクトのリストと定義されており、いわゆる ディレクトリのように、ファイルの一覧を提供する。ただしディレクトリと違い、コンテナの中にコンテナ を作ることはできない。コンテナはあくまでオブジェクトのリストを扱うためである。ただしコンテナの 中であれば、ディレクトリもオブジェクトとして作成可能である。
2.3. ユーザ認証
Swift ではクライアントから利用する際、アカウント認証の手順が必要となる。Swift ではアカウン トに関する情報は 3 つあり、アカウント名、ユーザ名、パスワードとなっている。認証が成功すると、 Token と URL が発行される。クライアントは認証後、発行された Token を用いて、URL に対して 通信を行う。
2.4. 冗長化と複製
Swift では、オブジェクト及びコンテナを複数のサーバに保存することで冗長化し、障害等で特 定のサーバが利用できなくなった場合でも、サービスの継続を可能にしている。
オ ブ ジ ェ ク ト な どの デ ー タを 、 複 数 の サー バに 保 存す る こ と で 冗長 化 し て いる 。 後 述 する Replicator によって、サーバの間で定期的にファイルをコピーしている。また、削除に関しても、0 バイトのファイルをコピーすることで、全てのサーバ上からの削除を実現している。
3. アーキテクチャ
Swift の全体構成図を以下に示す。
図 1 全体構成図
Swift を構成するサーバとしては以下のものがある。
・ Auth Server
・ Proxy Server
・ Object Server
・ Container Server
・ Account Server
ま た 図中に は な いが 、 デー タ を 保 存 する サ ーバ に 関 し て は 、 そ の サ ーバ 向け に Auditor 、
Replicator、Updater、Reaper という機構が存在する。
3.1. Auth Server
クライアントが利用する際に、認証を行う。またアカウントの作成に関しても、Auth サ ーバ上で行う。アカウントを作成した際、Account Server にそのアカウントのための URL の情報が保存されるが、ユーザ名・パスワードといった認証に関する情報は Auth Server 上でデータベースとして保存している。
3.2. Proxy Server
リクエストの仲介を行う。クライアントは認証後、Proxy Server を経由してサービスを 受け、クライアントからは Proxy Server とのみ通信を行っているように見える。しかし実 際は Proxy Server が他のサーバと通信を行い、オブジェクト等の提供をしている。また一 般的な HTTP の Proxy とは異なり、ファイルのキャッシュなどは行わない。
3.3. Object Server
Object Server はオブジェクトを扱 うサーバであり、オブジェクトの保 存 ・取 得 ・削 除 といっ た操 作 が行 える。前 述 のとおり、オブジェクトはファイルと考 えて良 いが、ディレクトリもオブジ ェクトの１つとして扱 われる。オブジェクトに付 随するメタデータも保 存 している。
3.4. Container Server
Container Server はオブジェクトのリストを扱い、ディレクトリのように作用する。ディ レクトリとの違いとして、コンテナの中にコンテナを作成することはできない。コンテナ はあくまでオブジェクトのリストであり、コンテナのリストではないためである。前述の とおり、コンテナの中にディレクトリを作成する場合は、オブジェクトとして作成される。
3.5. Account Server
Container Server がオブジェクトのリストを扱うように、Account Server はそのアカウントが保持 しているコンテナのリストを扱う。
3.6. Auditor
Auditor はシステムを監視する。データの異常を検知した場合、他のサーバにあるレプリカを用 いて上書きされる。エラーについてはロギングされる。
3.7. Replicator
Replicator はデータの複製を行う。ハッシュを使用してオブジェクトのデータを比較し、異なって いた場合に複製を行う。複製には rsync を用いている。また削除に関しては、0 バイトのファイルを コピーすることで削除を行っている。削除済みのファイルは.ts の拡張子が付けられる。
3.8. Updater
負荷や障害などで、データの保存に失敗した時のための仕組みが Updater である。失敗すると、 ローカルファイルシステムのキューに入れられる。
3.9. Reaper
Reaper は Account Server にのみ存在する。アカウントが作り直された際に、古いアカウントの データを削除するための仕組みが Reaper である。具体的には、古いアカウントで使用されていた オブジェクトやコンテナを削除する。
3.10. Ring
Proxy Server や Replicator が、他のサーバを参照する際に Ring が使われる。Ring ファイル では、各サーバの情報及び、複製する数や各サーバの優先度などが含まれている。Ring の作成 や編集については swift-ring-builder コマンドを介して行う。Ring の書式や swift-ring-builder コマンドの使い方については 4.5 節で述べる。
4. Cloud Files プロトコル
Swift ではオブジェクト・コンテナに対して取得・保存・削除といった操作が行える。これらの操作 のために、CloudFiles プロトコルという HTTP を元にしたプロトコルを使用している。
4.1. Cloud Files プロトコルのメソッド
CloudFiles プロトコルでは以下の 4 つの HTTP メソッドを使用する。
・ GET
オブジェクト及びコンテナを取得する。オブジェクトに対して GET を行なった場合はオブジェクト を取得する。コンテナに対して GET を行った場合は、コンテナ内のオブジェクトの一覧を取得す る。
・ PUT
オブジェクトのアップロード、及びコンテナの作成を行う。オブジェクトはコンテナの中にしか
PUT できない。またアカウントの作成時にも、PUT が用いられる。
・ HEAD
GET と同様のやりとりを行う。ただし、オブジェクトそのものは取得しない。HTTP では、通信の テストなどの用途に用いられる。Swift ではオブジェクトのアップロードの際に、格納先であるコンテ ナやアカウントが存在するかの確認等に用いている。
・ DELETE
オブジェクト及びコンテナを削除する。オブジェクトが存在しているコンテナは削除できない。
4.2. メッセージの流れ
Cloud Files プロトコルでの、各サーバ間でのメッセージの流れを図示する。操作としてはクライ アントからオブジェクトとコンテナに対して GET・PUT・DELETE を行う。なおクライアントからの HEAD については GET と同様の動作であるため、割愛する。
4.2.1. アカウント作成
アカウントを作成した際には、Auth Server 上にデータベースとして保存される。また、 そのアカウントのための、URL 空間が Account Server に書き込まれる。
図 2 アカウント作成
4.2.1. アカウント認証
クライアントが認証等を行う場合は Auth Server とクライアントが通信を行い、Account Server
や Proxy Server とクライアントの間では通信を行わない。
図 3 アカウント認証
4.2.1. コンテナの PUT
コンテナを作成する場合の動作は図 4 のようになる。クライアントは、認証時に取得した URL に 対し、Token を用いて PUT メッセージを送る。Token は HTTP の拡張ヘッダとして指定する。こ れについては 6.1 節で後述する。
Proxy Server からは、まず Account Server に対して HEAD が実行される。これは PUT 先の コンテナを、格納するアカウントスペースが存在するかの確認のためと考えられるｈ。Account Server への HEAD が実行された後、Container Server へ PUT が行われる。この時には冗長化 のため、複数の Container Server に対して PUT が実行される。
図 4 ディレクトリの PUT
4.2.2. オブジェクトの PUT
オブジェクトを PUT する場合も、クライアントから Proxy Server に対して PUT が実行 される。コンテナの場合と同様に、Account Server、Container Server それぞれに対して HEAD が実行された後、Object Server に対して PUT が実行される。複数の Object Server に対して PUT が実行される点も同様である。
図 5 オブジェクトの PUT
4.2.3. コンテナの GET
コンテナの GET では、まず Account Server に対して HEAD が実行された後、Container Server に対して GET が実行される。PUT の場合とは異なり、GET は単一のサーバに対して実行 される。
図 6 コンテナの GET
4.2.4. オブジェクトの GET
オブジェクトの場合は、Account Server や Container Server との通信は行われず、直接
Object Server に対して GET が実行される。
図 7 オブジェクトの GET
4.2.5. コンテナの DELETE
コンテナを DELETE する場合は、まず Account Server に対して HEAD が実行された後、 Container Server に対して DELETE が実行される。DELETE に関しても、複数の Container Server に対して実行される。
図 8 コンテナの DELETE
4.2.6. オブジェクトの DELETE
オブジェクトの DELETE も、コンテナの DELETE と同様、Account Server と Container Server に対して HEAD を実行した後に行われる。オブジェクトの場合も、複数の Object Server から DELETE が実行される。
図 9 オブジェクトの DELETE
5. Swift のインストール方法
本章では、Swift のインストール手順を説明する。使用する OS は Swift のドキュメントにならい、 Ubuntu Server10.04 を想定する。5.7 節までで、1 台のホスト上で全てのサーバを動作させる場 合の設定方法を説明し、5.9 節では複数台で構成する方法を述べる。
5.1. 想定する構成
4.7 節までは 1 台のホスト上で全てのサーバを動作させる場合の設定方法を説明する。起動させ るプログラムとしては Auth Server、Proxy サーバを 1 プロセスずつ、Object Server、Container Server、Account Server を 4 プロセスずつ動作させる。
5.2. パーティションの作成
Swift ではメタデータを取り扱うことができる。実現方法として、メタデータに対応したファイルシステムを用いている。このため Swift のデータを保存するサーバの要件として、メタデータに対応した
ファイルシステムが必要になる。メタデータに対応しているファイルシステムとしては XFS があり、以
下のコマンドで作成できる。
# mkfs.xfs -i size=1024 /dev/sdb1
# mkdir -p /mnt/sdb1
/dev/sdb1 の箇所は、使用しているストレージや割り当てるパーティション番号によって異なる。作
成後、以下の行を/etc/fstab に追加する。
/dev/sdb1 /mnt/sdb1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 0
追加することで、OS の起動時に自動的にマウントされるようになる。追加後は、以下のコマンドでマ
ウント出来る。
# mount /mnt/sdb1
サーバがデータを保存するためのディレクトリを作成し、/srv からのシンボリックリンクを貼る。これは
デバイスの名前と関係なく、設定ファイルから指定できるようにするためである。下記の例では、1～
4 の 4 つのディレクトリを作成している。また$user:$group はそれぞれ swift を実行するユーザと
グループに置き換える必要がある。
# mkdir /mnt/sdb1/1 /mnt/sdb1/2 /mnt/sdb1/3 /mnt/sdb1/4 /mnt/sdb1/test
# chown $user:$group /mnt/sdb1/*
# mkdir /srv
# for x in {1..4}; do ln -s /mnt/sdb1/$x /srv/$x; done
# mkdir -p /etc/swift/object-server /etc/swift/container-server ¥
/etc/swift/account-server /srv/1/node/sdb1 /srv/2/node/sdb2 /srv/3/node/sdb3 ¥
/srv/4/node/sdb4 /var/run/swift
# chown -R $user:$group /etc/swift /srv/[1-4]/ /var/run/swift
5.3. Swift に必要なソフトウェアとインストール
Swift に必要なソフトウェアパッケージとしては、以下のものがある。
• Python 2.6
• Rsync 3.0 ※Object Server、Container Server、Account Server にのみ必要
• Memcached ※Proxy Server にのみ必要
また、Python のライブラリとして以下のものも必要になる。
• Eventlet 0.9.8
• WebOb 0.9.8
• Setuptools
• Simplejson
• Xattr
• Nose
• Sphinx
これらを apt-get でインストールするためには、以下のコマンドのように実行する。
# apt-get install python-software-properties
# add-apt-repository ppa:swift-core/ppa
# apt-get update
# apt-get install curl gcc bzr memcached python-configobj python-coverage ¥ python-dev python-nose python-setuptools python-simplejson python-xattr ¥ sqlite3 xfsprogs python-webob python-eventlet python-greenlet ¥
python-pastedeploy
上記のコマンドには、Swift の入手に必要な bazaar やテスト用の curl なども含まれている。
なお、現在は bazaar 以外にも公式サイトでの配布もされている。他にも swift そのものを
apt-get でインストールすることが可能になっており、swift-proxy など構成するサーバ単体
のパッケージも存在する。
# apt-get install swift
Object Server、Container Server、Account Server は、rsync を用いて、データを複製し
ている。このための rsyncd の設定として、/etc/rsyncd.conf を以下の内容で作成する。
uid = username gid = username
log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid
[account1]
max connections = 25 path = /srv/1/node/ read only = false
lock file = /var/lock/account1.lock
[container1]
max connections = 25 path = /srv/1/node/ read only = false
lock file = /var/lock/container.1lock
[object1]
max connections = 25 path = /srv/1/node/ read only = false
lock file = /var/lock/object1.lock
uid、gid はそれぞれ swift を実行するユーザのものにする。[account1][container1][object1]
は、それぞれ Account Server、Container Server、Object Server 用の設定である。Path
は同期の対象になるディレクトリで、これらのサーバがデータを保存する場所を指定する
必要がある。複数のサーバプロセスを起動させる場合は、[account2]や[account3]のように、
名前と path を変えて複数定義する。ここでは、それぞれ 4 つずつ起動させるため、lock file
の名前と、path を変えてそれぞれ 4 つずつ定義する必要がある。
また、rsyncd を起動させるために、/etc/defaults/rsync に以下の行を記述する。デフォルト では false で定義されているので true に書き換える。
RSYNC_ENABLE=true
設定後、rsyncd を再起動する。
# service rsyncd restart
また Proxy Server が memcached を使用するため、実行する。memcached に関しては特
に設定をせずに起動できる。
# service memcache restart
5.4. Swift の入手とインストール
Swift の入手は、現在 apt-get や公式サイトからダウンロードすることで行えるが、ここでは bazaar での入手方法を説明する。Swift は LaunchPad で配布されており、bazaar で入手する 場合は LaunchPad のアカウントが必要になる。またアカウントの作成および、LaunchPad への鍵 の登録はしてあるものとして説明する。
まずはソースコードを置くディレクトリを作成する。
# mkdir ~/swift/
続いて bazaar 用の設定を行う。~/bazaar/.bazaar.conf を以下の形式で作成する。Your
Name とについては、それぞれ LaunchPad に登録している情報を入力
する。
[DEFAULT]
email = Your Name
LaunchPad へのログイン、及びソースコードの入手を行う。
# bzr launchpad-login
# bzr init-repo swift
# cd ~/swift
# bzr branch lp:swift trunk
Swift のインストールは以下のコマンドで行う。
# cd ~/swift/trunk
# sudo python setup.py develop
なお、公式サイトからダウンロードした場合は、アーカイブを解凍したディレクトリに移
動して、上記と同様に python のスクリプトを実行してインストールする。
5.5. Ring ファイルの作成
5.5.1. Ring ファイルの場所
各サーバの設定ファイルでは、Ring ファイルの場所は指定してない。ファイル名は固定となってお り、以下の名前で/etc/swift に 保存する必要が ある。それぞれ、Object Server 、Container Server、Account Server の Ring ファイルである。
・ object.ring.gz
・ container.ring.gz
・ account.ring.gz
また後述する rebalance を実行することで、上記のファイルが生成される。実際に作成する必要の あるファイルは以下の名前になる。
・ object.builder
・ container.builder
・ account.builder
5.5.2. swift-ring-builder コマンド
ring ファイルを作成・変更するためには swift-ring-builder コマンドを使う必要がある。Ring フ ァイルの作成は以下のように実行する。
# swift-ring-builder create
の項目で作成するファイル名を指定する。前述のとおり、Ring ファイルは所定の名
前で保存されている必要があるため、ここで上記の名前を指定する。
ではパーティ
ション数を指定する。ここでいうパーティションとは、Ring での概念であり、各サーバに特定のパー
ティションがいくつか割り当てられる。
の値がそのままパーティションの数になるので
はなく、2 の
乗の数が実際のパーティション数になる。では冗長化する
数を指定する。は、パーティションが移動可能になるまでの時間である。これ
はサーバの追加などで、パーティションの割り当てが変わる際に、再割当てを行えるようになるまで
の時間である。
Ring へのデバイスの追加は以下のように実行する。ここでいうデバイスとは、swift のサーバであり、
Object Server、Container Server、Account Server の情報を追加する。
# swift-ring-builder add z-:
/_
は任意の値を設定する。同じ zone のサーバには、データが複製されない。このため、地理
的に近いサーバや、ネットワークトポロジとして近いサーバは同じ zone に所属させる事が考えられ
る。
:
はそれぞれ、サーバの IP アドレスとポート番号を指定する。は、サ
ーバ上のパスを指定する。はデバイスの情報を記述するために、メタデータを付与するこ
とができるが、必須項目ではない。 では重み付けを行う。の大きなデバイス
には、多くのパーティションが割り当てられ、データが優先的に保存されるようになる。
デバイスの追加後は、以下のように rebalance を実行することで、パーティションを各デバイスに割
り当てる。また実行後に object.ring.gz などの、Ring の圧縮ファイルが作成される。
# swift-ring-builder rebalance
ring ファイルの内容は、以下のようにして表示する。
# swift-ring-builder
例えば、Object Server の Ring ファイルである object.builder の中身を表示した場合は、以下
のようになる。
# swift-ring-builder object.builder object.builder, build version 4
262144 partitions, 3 replicas, 4 zones, 4 devices, 0.00 balance
The minimum number of hours before a partition can be reassigned is 1
Devices: id zone ip address port name weight partitions balance meta
0 1 127.0.0.1 6010 sdb1 1.00 196608 0.00
1 2 127.0.0.1 6020 sdb2 1.00 196608 0.00
2 3 127.0.0.1 6030 sdb3 1.00 196608 0.00
3 4 127.0.0.1 6040 sdb4 1.00 196608 0.00
5.6. 各種サーバの設定
各サーバの設定ファイルについて説明する。設定項目の一覧は、Deployment Guide に記載 されているため、ここでは全ての項目は網羅しない。どのサーバでも、省略した場合はデフォルトの 値が適用される。どのサーバにも存在する項目としては以下のものがある。
・ bind_ip 待ち受けに使用する IP アドレスを指定する。省略した場合は 0.0.0.0 となる。
・ bind_port 待ち受けに使用するポート番号を指定する。省略した場合の値は、サーバごとに
異なっている。
・ workers 起動する子プロセスの数を指定する。省略した場合は 1 となる。
・ swift_dir 設定フ ァイ ルや ring が 置かれるディレクトリ を指定する。デ フォ ルトの 値は
/etc/swift である。
・ user サーバプロセスを実行するユーザを指定する。デフォルトの値は swift である。
5.6.1. Auth Server
/etc/swift/auth-server.conf を、以下の内容で作成する。username は、実行させたいユーザ の名前に置き換える必要がある。
[DEFAULT]
user = username bind_ip = 0.0.0.0 bind_port = 11000
cert_file = /etc/swift/cert.crt key_file = /etc/swift/cert.key
[pipeline:main]
pipeline = auth-server
[app:auth-server]
use = egg:swift#auth
default_cluster_url = http://127.0.0.1:8080/v1 super_admin_key = devauth
SSL に対応させることができ、その場合は cert_file と key_file を指定する。SSL に対応さ
せない場合は、この項目を記述しなければよい。default_cluster_url には、Proxy server
の URL を指定する。ただし、クライアントに渡される URL でもあるため、127.0.0.1 など
ではなく、クライアントから利用可能なアドレスである必要がある。super_admin_key に
は管理用のパスワードを指定する、この項目に関しては省略不可である。
5.6.2. Proxy Server
/etc/swift/proxy-server.conf を編集し、以下の内容で作成する。
[DEFAULT] bind_ip = 0.0.0.0 bind_port = 8080 user = username
cert_file = /etc/swift/cert.crt key_file = /etc/swift/cert.key
[proxy-server]
[pipeline:main]
pipeline = healthcheck cache auth proxy-server
[app:proxy-server]
use = egg:swift#proxy allow_account_management = true
[filter:auth]
use = egg:swift#auth ip = 127.0.0.1
port = 11000 ssl = False
[filter:healthcheck]
use = egg:swift#healthcheck
[filter:cache]
use = egg:swift#memcache memcache_servers = 127.0.0.1:11211
[filter:auth]の項目では Auth Server の IP アドレスや Port 番号を指定するが、こちらも省略し
た場合は上記の値が適用される。Auth Server との通信に SSL を使用する場合は、ssl の項目を
True にする。memcache_servers は memcached を指定し、カンマで区切ることで複数台を指定
することができる。
5.6.3. Object Server
/etc/swift/object-server/1.conf を以下の内容で作成する。username に関しては、swift を実 行するユーザのものに書き換える。
[DEFAULT]
devices = /srv/1/node mount_check = false bind_port = 6010 user = username
[pipeline:main]
pipeline = object-server
[app:object-server]
use = egg:swift#object
[object-replicator]
vm_test_mode = yes
[object-updater] [object-auditor]
devices の項目では、サーバがデータを保存するディレクトリを指定する。指定したディレクトリは、
メタデータに対応している必要がある。また 2.conf や 3.conf のように、2 つ目以降のサーバプロセ
スのための設定ファイルも作成可能である。ここでは、パスと Port 番号を変えて 4 プロセスを起動さ
せるため、2.conf、3.conf、4.conf もそれぞれ作成する。
・ /etc/swift/object-server/2.conf
[DEFAULT]
devices = /srv/2/node mount_check = false bind_port = 6020 user = username
[pipeline:main]
pipeline = object-server
[app:object-server]
use = egg:swift#object
[object-replicator]
vm_test_mode = yes
[object-updater] [object-auditor]
・ /etc/swift/object-server/3.conf
[DEFAULT]
devices = /srv/3/node mount_check = false bind_port = 6030 user = username
[pipeline:main]
pipeline = object-server
[app:object-server]
use = egg:swift#object
[object-replicator]
vm_test_mode = yes
[object-updater] [object-auditor]
・ /etc/swift/object-server/4.conf
[DEFAULT]
devices = /srv/4/node mount_check = false bind_port = 6040 user = username
[pipeline:main]
pipeline = object-server
[app:object-server]
use = egg:swift#object
[object-replicator]
vm_test_mode = yes
[object-updater] [object-auditor]
5.6.4. Container Server
/etc/swift/container-server/1.conf を 以 下 の 内 容 で 作 成 す る 。 各 設 定 項 目 に つ い て は 、 Object Server と同様になっている。また、Container Server もプロセスを 4 つ起動させるため、 設定ファイルを 4 つ作成する。
・ /etc/swift/container-server/1.conf
[DEFAULT]
devices = /srv/1/node mount_check = false bind_port = 6011 user = username
[pipeline:main]
pipeline = container-server
[app:container-server]
use = egg:swift#container
[container-replicator]
vm_test_mode = yes
[container-updater] [container-auditor]
・ /etc/swift/container-server/2.conf
[DEFAULT]
devices = /srv/2/node mount_check = false bind_port = 6021 user = username
[pipeline:main]
pipeline = container-server
[app:container-server]
use = egg:swift#container
[container-replicator]
vm_test_mode = yes
[container-updater] [container-auditor]
・ /etc/swift/container-server/3.conf
[DEFAULT]
devices = /srv/3/node mount_check = false bind_port = 6031 user = username
[pipeline:main]
pipeline = container-server
[app:container-server]
use = egg:swift#container
[container-replicator]
vm_test_mode = yes
[container-updater] [container-auditor]
・ /etc/swift/container-server/2.conf
[DEFAULT]
devices = /srv/4/node mount_check = false bind_port = 6041 user = username
[pipeline:main]
pipeline = container-server
[app:container-server]
use = egg:swift#container
[container-replicator]
vm_test_mode = yes
[container-updater] [container-auditor]
5.6.1. Account Server
Account Server の 設 定も 、 Object Server 、 Container Server と 同様 である 。 Account
Server も 4 つ起動させるため、以下の 4 つの設定ファイルを作成する。
・ /etc/swift/account-server/1.conf
[DEFAULT]
devices = /srv/1/node mount_check = false bind_ip = 0.0.0.0 bind_port = 6012 user = username
[pipeline:main]
pipeline = account-server
[app:account-server]
use = egg:swift#account
[account-replicator]
vm_test_mode = yes
[account-auditor] [account-reaper]
・ /etc/swift/account-server/2.conf
[DEFAULT]
devices = /srv/2/node mount_check = false bind_ip = 0.0.0.0 bind_port = 6022 user = username
[pipeline:main]
pipeline = account-server
[app:account-server]
use = egg:swift#account
[account-replicator]
vm_test_mode = yes
[account-auditor] [account-reaper]
・ /etc/swift/account-server/3.conf
[DEFAULT]
devices = /srv/3/node mount_check = false bind_ip = 0.0.0.0 bind_port = 6032 user = username
[pipeline:main]
pipeline = account-server
[app:account-server]
use = egg:swift#account
[account-replicator]
vm_test_mode = yes
[account-auditor] [account-reaper]
・ /etc/swift/account-server/4.conf
[DEFAULT]
devices = /srv/4/node mount_check = false bind_ip = 0.0.0.0 bind_port = 6042 user = username
[pipeline:main]
pipeline = account-server
[app:account-server]
use = egg:swift#account
[account-replicator]
vm_test_mode = yes
[account-auditor] [account-reaper]
5.7. 各サーバの起動
各サーバプログラムの起動方法について説明する。ただし、起動用のコマンドやスクリプトが別
途用意されているため、直接サーバプログラムから起動する機会は少ない。
起動時には、設定ファイルを引数として指定する。設定ファイルは、フルパスで指定する必要が
ある。
# swift-auth-server /etc/swift/auth-server.conf
# swift-proxy-server /etc/swift/proxy-server.conf
# swift-object-server /etc/swift/object-server/1.conf
# swift-container-server /etc/swift/container-server/1.conf
# swift-account-server /etc/swift/account-server/1.conf
起動用に swift-init というコマンドもあり、こちらは設定ファイルを指定せずとも自動的に読み込
んで起動する。
# swift-init auth-server start
# swift-init proxy-server start
# swift-init account-server start
# swift-init container-server start
# swift-init object-server start
start を stop や restart に変更して実行することで、停止や再起動もそれぞれ行える。
swift-init を使用する場合、想定されている設定ファイルは以下のものになる。
サーバ 設定ファイル
Auth Server
/etc/swift/auth-server.conf
Proxy Server
/etc/swift/proxy-server.conf
Account Server
/etc/swift/account-server/*.conf
Container Server
/etc/swift/container-server/*.conf
Object Server
/etc/swift/object-server/*.conf
Object Server、Container Server、Account Server に関しては複数プロセスにも対応してい
る。1.conf や 2.conf のように、上記のディレクトリにある、拡張子が.conf のファイルを読み込んでそ
れぞれ起動させている。
5.7.1. 起動用のスクリプト
Swift のドキュメントでは、操作のために各サーバを起動するためのスクリプトを作成している。1 ホスト上で全てのサーバを動作させるスクリプトであり、複数台に分けた構成の場合は、必要なサー ビスのみを起動するように編集する必要がある。
・ resetswift
resetswift は何かしらのトラブルがあった際に、パーティションの作成からやり直すため のスクリプトである。各サービスの停止、XFS パーティションのマウントし直し、ディレ クトリの作成を行う。使用するデバイスの名前を$dev、ユーザ名とグループ名を$user と
$group としてある。使用する際には、環境に合わせて編集する必要がある。
#!/bin/bash
swift-init all stop sleep 5
sudo umount /mnt/$dev
sudo mkfs.xfs -f -i size=1024 /dev/$dev sudo mount /mnt/$dev
sudo mkdir /mnt/$dev/1 /mnt/$dev/2 /mnt/$dev/3 /mnt/$dev/4 /mnt/$dev/test sudo chown $user:$group /mnt/$dev/*
mkdir -p /srv/1/node/sdb1 /srv/2/node/sdb2 /srv/3/node/sdb3 /srv/4/node/sdb4 sudo rm -f /var/log/debug /var/log/messages /var/log/rsyncd.log /var/log/syslog sudo service rsyslog restart
sudo service memcached restart
・ remakerings
Ring ファイルを一度削除し、再構築する。デバイスは全て localhost 上のサーバで、それぞれ 4
台ずつとしている。
#!/bin/bash cd /etc/swift
rm -f *.builder *.ring.gz backups/*.builder backups/*.ring.gz
swift-ring-builder object.builder create 18 3 1
swift-ring-builder object.builder add z1-127.0.0.1:6010/sdb1 1 swift-ring-builder object.builder add z2-127.0.0.1:6020/sdb2 1 swift-ring-builder object.builder add z3-127.0.0.1:6030/sdb3 1 swift-ring-builder object.builder add z4-127.0.0.1:6040/sdb4 1 swift-ring-builder object.builder rebalance
swift-ring-builder container.builder create 18 3 1
swift-ring-builder container.builder add z1-127.0.0.1:6011/sdb1 1 swift-ring-builder container.builder add z2-127.0.0.1:6021/sdb2 1 swift-ring-builder container.builder add z3-127.0.0.1:6031/sdb3 1 swift-ring-builder container.builder add z4-127.0.0.1:6041/sdb4 1 swift-ring-builder container.builder rebalance
swift-ring-builder account.builder create 18 3 1
swift-ring-builder account.builder add z1-127.0.0.1:6012/sdb1 1 swift-ring-builder account.builder add z2-127.0.0.1:6022/sdb2 1 swift-ring-builder account.builder add z3-127.0.0.1:6032/sdb3 1 swift-ring-builder account.builder add z4-127.0.0.1:6042/sdb4 1 swift-ring-builder account.builder rebalance
・ startmain
Swift の主要なサーバを起動する。
#!/bin/bash
swift-init auth-server start swift-init proxy-server start swift-init account-server start swift-init container-server start swift-init object-server start
・ startrest
Updater、Auditor、Replicator、Reaper をそれぞれ起動する。これらのプログラムの設 定については、Object Server 用の設定ファイルなどに記述する。また Swift のバージョン によっては、OS の言語設定が日本語等だとうまく動作しないので、言語を C に設定してい る。$devauth は、auth サーバの super_admin_key を入力する必要がある。
#!/bin/bash
export LANGUAGE=C
swift-auth-recreate-accounts -K $devauth swift-init object-updater start
swift-init container-updater start swift-init object-replicator start swift-init container-replicator start swift-init account-replicator start swift-init object-auditor start
swift-init container-auditor start
swift-init account-auditor start
5.8. アカウントの作成
クライアントからの利用のためには、アカウントを作成する必要がある。アカウントの
作成は、以下のコマンドを用いる。
# swift-auth-add-user -K -a
には、Auth Server に設定した管理用のパスを指定する。
が、アカウントとしての上方になる。-a オプションは管理者アカウントとして
の作成を意味するが、-a オプションを省いて作成されたアカウントでは、オブジェクトの
取得といった操作を行えない。実行例としては、以下のようになる。
# swift-auth-add-user -K devauth -a test tester testing
5.9. 複数台構成での構築
4.7 節までは、1 ホスト上で全てのサーバを動作させる構成で、設定方法について述べた。 本節では、複数台で構築する場合の設定方法について述べる。
5.9.1. 想定する構成
複数台構成として、以下の構成を前提に説明する。Proxy Server、Object Server、 Container Server、Account Server に関しては、同じ構成の物を複数台用意すれば、同様 の設定で追加が可能である。
・ Auth Server
・ Proxy Server
・ Object Server + Container Server + Account Server
5.9.2. Auth Server の設定
Auth Server のみを動作させる場合は、Auth Server のパッケージと、実行に必要な python ライブラリをインストールすればよい。memcached のインストールや XFS パーテ ィションの作成や、rsync の設定については必要ない。
DNS ラウンドロビンを用いて複数の Proxy Server へ振り分ける場合、Auth Server では 以下のように、URL を IP アドレスではなくホスト名を用いて指定する。
[DEFAULT]
user = username bind_ip = 0.0.0.0 bind_port = 11000
cert_file = /etc/swift/cert.crt key_file = /etc/swift/cert.key
[pipeline:main]
pipeline = auth-server
[app:auth-server]
use = egg:swift#auth
default_cluster_url = http://proxy.example.com:8080/v1 super_admin_key = devauth
5.9.3. Proxy Server の設定
Proxy Server になるホストでは、実行に必要な python ライブラリ以外には memcached が必要になるが、同一ホスト上で動作している必要はない。XFS パーティションの作成や、 rsync の設定については必要ない。
下記は Auth Server の IP アドレスが 192.168.0.1 である場合の設定例である。
[DEFAULT] bind_ip = 0.0.0.0 bind_port = 8080 user = username
cert_file = /etc/swift/cert.crt key_file = /etc/swift/cert.key
[pipeline:main]
pipeline = healthcheck cache auth proxy-server
[app:proxy-server]
use = egg:swift#proxy allow_account_management = true
[filter:auth]
use = egg:swift#auth ip = 192.168.0.1
port = 11000 ssl = False
[filter:healthcheck]
use = egg:swift#healthcheck
[filter:cache]
use = egg:swift#memcache memcache_servers = 192.168.0.2:11211
memcached も複数のサーバを指定できるが、複数の Proxy Server から構成する場合、
全ての Proxy Server で同じ memcached サーバ群を使用する必要がある。また memcached
はデフォルトの設定では、localhost でのみサービスを待ち受けている。他のホストからも
利用可能にするためには、以下のように-l で始まる行を編集する。
# vi /etc/memcached.conf
(省略)
-l 192.168.0.2 (省略)
5.9.4. Object Server + Container Server + Account Server の設定
Object Server、Container Server、Account Server になるホストでは、実行に必要な python ライブラリ以外には rsync が必要になる。またデータを保存するディレクトリは、 メタデータに対応している必要があるため、XFS パーティションの作成と設定も必要にな る。memcached については必要ない。
5.9.5. Ring ファイルの作成
本節の構成の場合、以下のように IP アドレス・Port 番号を変更して Ring ファイルを作 成する。
・ remakerings
#!/bin/bash
cd /etc/swift
rm -f *.builder *.ring.gz backups/*.builder backups/*.ring.gz
swift-ring-builder object.builder create 18 3 1
swift-ring-builder object.builder add z1-192.168.0.3:6010/sdb1 1 swift-ring-builder object.builder add z2-192.168.0.3:6020/sdb2 1 swift-ring-builder object.builder add z3-192.168.0.3:6030/sdb3 1 swift-ring-builder object.builder add z4-192.168.0.3:6040/sdb4 1 swift-ring-builder object.builder rebalance
swift-ring-builder container.builder create 18 3 1
swift-ring-builder container.builder add z1-192.168.0.3:6011/sdb1 1 swift-ring-builder container.builder add z2-192.168.0.3:6021/sdb2 1 swift-ring-builder container.builder add z3-192.168.0.3:6031/sdb3 1 swift-ring-builder container.builder add z4-192.168.0.3:6041/sdb4 1 swift-ring-builder container.builder rebalance
swift-ring-builder account.builder create 18 3 1
swift-ring-builder account.builder add z1-192.168.0.3:6012/sdb1 1 swift-ring-builder account.builder add z2-192.168.0.3:6022/sdb2 1 swift-ring-builder account.builder add z3-192.168.0.3:6032/sdb3 1 swift-ring-builder account.builder add z4-192.168.0.3:6042/sdb4 1 swift-ring-builder account.builder rebalance
5.9.6. サーバの追加
上記の構成で更にサーバを追加する場合は、Ring にデバイスを追加する。ここでは、以下のス クリプトを作成して実行している。
・ addrings
#/bin/bash
cd /etc/swift/
swift-ring-builder object.builder add z1-192.168.0.4:6010 sdb1 1 swift-ring-builder object.builder add z2-192.168.0.4:6020/sdb2 1 swift-ring-builder object.builder add z3-192.168.0.4:6030/sdb3 1 swift-ring-builder object.builder add z4-192.168.0.4:6040/sdb4 1 swift-ring-builder object.builder rebalance
swift-ring-builder container.builder create 18 3 1
swift-ring-builder container.builder add z1-192.168.0.4:6011/sdb1 1 swift-ring-builder container.builder add z2-192.168.0.4:6021/sdb2 1 swift-ring-builder container.builder add z3-192.168.0.4:6031/sdb3 1 swift-ring-builder container.builder add z4-192.168.0.4:6041/sdb4 1 swift-ring-builder container.builder rebalance
swift-ring-builder account.builder create 18 3 1
swift-ring-builder account.builder add z1-192.168.0.4:6012/sdb1 1 swift-ring-builder account.builder add z2-192.168.0.4:6022/sdb2 1 swift-ring-builder account.builder add z3-192.168.0.4:6032/sdb3 1 swift-ring-builder account.builder add z4-192.168.0.4:6042/sdb4 1
swift-ring-builder account.builder rebalance
5.9.7. Proxy Server の複数台構成
[DEFAULT]
user = username bind_ip = 0.0.0.0 bind_port = 11000
cert_file = /etc/swift/cert.crt key_file = /etc/swift/cert.key
[pipeline:main]
pipeline = auth-server
[app:auth-server]
use = egg:swift#auth
default_cluster_url = http://
:8080/v1 super_admin_key = devauth
6. Swift の利用手順
クライアントからの利用手順として、curl および CyberDuck からの利用方法を説明する。
6.1. curl
curl は、シンプルなコマンドラインツールの Web クライアントである。オプションで HTTP ヘッダを指定することができるため、CloudFiles の仕様に合わせた HTTP メッセー ジを扱うことができる。
6.1.1. curl での認証
利用にあたって、まずは認証を行う。4.8 節で作成したアカウントで認証する場合は、下 記のコマンドを実行する。URL については使用する環境に合わせて変更する。
# curl -v -H 'X-Storage-User: test:tester' -H 'X-Storage-Pass: testing'
http://127.0.0.1:11000/v1.0
実行すると、以下のような結果が出力される。
* About to connect() to 127.0.0.1 port 11000 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 11000 (#0)
> GET /v1.0 HTTP/1.1
> User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: 127.0.0.1:11000
> Accept: */*
> X-Storage-User: test:tester
> X-Storage-Pass: testing
>
< HTTP/1.1 204 No Content
< X-Storage-Url: http://127.0.0.1:8080/v1/AUTH_cb4d116793724eacb908b2f509e53c0d
< X-Storage-Token: AUTH_tk310bafc0db024dd39bd73f43fed2f4b0
< X-Auth-Token: AUTH_tk310bafc0db024dd39bd73f43fed2f4b0
< Content-Length: 0
< Date: Sun, 14 Nov 2010 01:56:05 GMT
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
X-Storage-Url と X-Auth-Token を、後の操作で使用するので控えておく。X-Storage-Token
の値は X-Auth-Token と同じになる。
6.1.2. curl での PUT
PUT で コ ン テ ナ を 作 成 す る 場 合 は 以 下 の よ う に 実 行 す る 。 認 証 の 際 に 控 え た X-Auth-Token を-H オプションと X-Auth-Token:で指定する。宛先 URL には同様に取得し た X-Storage-Url の末尾に、作成したいコンテナの名前を加えて指定する。
# curl –v –X PUT -H 'X-Auth-Token: AUTH_tk310bafc0db024dd39bd73f43fed2f4b0'
http://127.0.0.1:8080/v1/AUTH_cb4d116793724eacb908b2f509e53c0d/container
オブジェクトを保存する場合は、-T オプションでアップロードするファイルを指定する。宛先 URL
には、X-Storage-Url にアップロード先のパスを指定する。なお、オブジェクトはコンテナの中にし
かアップロードできない。
# curl –v –T object –X PUT -H 'X-Auth-Token: ¥
AUTH_tk310bafc0db024dd39bd73f43fed2f4b0'
http://127.0.0.1:8080/v1/AUTH_cb4d116793724eacb908b2f509e53c0d/container/object
6.1.3. curl での GET/HEAD
GET の場合も PUT と同じように実行する。X-Storage-Url に、取得したいオブジェクト やコンテナのパスを追加する。また GET の場合は-X オプションは省いても良い。
# curl -v -H 'X-Auth-Token: AUTH_tk310bafc0db024dd39bd73f43fed2f4b0'
http://127.0.0.1:8080/v1/AUTH_cb4d116793724eacb908b2f509e53c0d
HEAD の場合も GET と同様の形式を取り、-X オプションで HEAD を指定する。
# curl –v –X HEAD -H 'X-Auth-Token: AUTH_tk310bafc0db024dd39bd73f43fed2f4b0'
http://127.0.0.1:8080/v1/AUTH_cb4d116793724eacb908b2f509e53c0d
6.1.4. curl での DELETE
DELETE の場合も GET と同じように実行する。X-Storage-Url に、削除したいオブジェ クトやコンテナのパスを加えて指定する。またコンテナは、中にオブジェクトが存在する 場合は削除できない。
# curl –v –X DELETE -H 'X-Auth-Token:
AUTH_tk310bafc0db024dd39bd73f43fed2f4b0'
http://127.0.0.1:8080/v1/AUTH_cb4d116793724eacb908b2f509e53c0d/container/object
6.3. CloudFiles API
前述の curl で行っていた操作を実行するために、CloudFiles は API ライブラリが提供されてい る。現在は PHP、Java、.NET、Ruby、Python 向けの物があり、Github で公開されている。
6.4. CyberDuck
CloudFiles に対応した GUI ソフトウェアとしては CyberDuck がある。Mac 向けのソフ トウェアであるが Java で書かれており、バージョン 3.7 以降からは Windows にも対応し ている。現行の最新版はバージョン 4 系列である。CloudFiles プロトコルを使用するサー ビスとして、Rackspace の Cloud Storage サービスを利用することができる。以前のバー ジョンでは、サーバのアドレスは固定されており、Swift を指定できなかったが、現行の最 新版では、プロトコルのタイプとして Swift を指定し、サーバのアドレスも指定可能である。 本報告書で確認したバージョンは 4.0b7 であり、それ以降のバージョンであれば対応して いるだろう。
6.4.1. CyberDuck の設定
CyberDuck か ら の 利 用 方 法 に つ い て 説 明 す る 。 ク ラ イ ア ン ト の 環 境 と し て は CyberDuck4.0b7、Windows7 で確認している。起動後、新規接続を選択すると接続するサ ーバの設定を行う画面が出るので、プロトコルを FTP から Swift 変更する。選択の画面を 図 10 に示す。
図 10 CyberDuck でのプロトコル選択
選択後は図 11 のように、設定画面が Swift 用のものに変わるので、続けて情報を入力す る。
図 11 CyberDuck でのサーバ設定
ニックネームは、CyberDuck 側で管理するための名前なので好きなものを入力すれば良い。サ ー バ ・ ポ ー ト は そ れ ぞ れ Auth Server の 物 を 指 定 す る 。 ユ ー ザ 名 に は 、 curl の 時 の X-Storage-User と 同 様 、 : の 形 式 で 入 力 す る 。 パ ス ワ ー ド に つ い て は 、 X-Storage-Pass と同様、
を入力する。省略した場合は、接続時に図 12 のような画面 が出て入力を求められるので、API アクセスキーとして入力する。図 11 にあるパスの項目について はパスワードではなく、path の意味である。これは省略しておけばよい。curl と同様のパスとして、
/v1.0 などを追加するとエラーが出るが、省略した場合と同様に使用することができる。また URL が https から始まっているように、SSL 接続を行っている。CyberDuck から利用する場合、Swift は SSL を使用するよう設定しなければならない。
図 12 パスワード入力画面
図 13 接続後の画面と右クリックメニュー
接続後は、図 13 のようになる。右クリックメニューも図 13 に入れている。このメニュ ーから、フォルダの作成やファイルのアップロードを行うことができる。また、一番上の 階層で作成したディレクトリは、コンテナとして扱われ、図 13 で表示されているようなアイ コンになる。コンテナの中で作成したディレクトリは、図 14 のようにディレクトリのアイ コンになる。
図 14 コンテナの中
図 15 ファイルに対する右クリック
メタデータの扱い方としては、図 15 のように対象のファイルを右クリックし、情報を選 択する。選択後、情報の画面が出てくるので、メタデータのアイコンを選択する。選択後、図 16 の画面になり、メタデータを入力できる。
図 16 メタデータの入力画面
7. Swift のログファイルとトラブルシューティング
7.1. Swift のログファイル
ログファイルはすべて/var/log/syslog に保存される。このため、サーバごとに異なるログファイル を用いることは出来ない。しかしロギングのために、stats という仕組みも提供されており、サーバご とに違うファイルを指定することなどが可能になる。
ログは以下のような内容で出力される。表示の都合上、途中で改行しているログについては、先 頭に空白を入れている。太字で表示している部分が、サーバプロセスの名前であり、それ以降の部分がログの内容になる。
Dec 9 18:16:24 swift2 auth-server validate_token('AUTH_tkf53b15e635b64
4b58c575a39778d0cd6', _, _) = (86365.042982816696, 'test', 'tester',
'AUTH_78578ea362324103b5a82e00ffb59362') [0.00]
Dec 9 18:16:24 swift2 auth-server 127.0.0.1 - - [09/Dec/2010:09:16:24 +0000]
"GET /token/AUTH_tkf53b15e635b644b58c575a39778d0cd6 HTTP/1.0" 204 - "-" "-" - - - - - - - - - "-" "127.0.0.1" "-" 0.0016
Dec 9 18:16:24 swift2 account-server 127.0.0.1 - - [09/Dec/2010:09:16:24 +0000] "GET /sdb3/197717/AUTH_78578ea362324103b5a82e00ffb59362" 200 - "tx0c7ffab0-33a2-4098-9f17-197730129540" "-" "curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15" 0.0027 ""
Dec 9 18:16:24 swift2 proxy-server - 127.0.0.1 09/Dec/2010/09/16/24 GET/v1/ AUTH_78578ea362324103b5a82e00ffb59362/ HTTP/1.0 200 - curl/7.19.7%20%28i486-pc-linux-gnu%29%20libcurl/7.19.7%20OpenSSL/0.9.8k%
20zlib/1.2.3.3%20libidn/1.15 test%3Atester%2CAUTH_tkf53b15e635b644b58c575a39778d0cd6 - - -
tx0c7ffab0-33a2-4098-9f17-197730129540 - 0.0059
7.2. トラブルシューティング
起動の際には swift-init コマンドを介して行っているが、このコマンドではエラーの出力がされな い。そのため、設定内容の誤りなどには気づきにくい。直接サーバプログラムを実行した場合は、 エラーメッセージなども出力されるので、トラブルシューティングの際には直接起動するとよいだろ う。
下記は、Auth Server を直接起動させた際、super_admin_key を設定していなかった場合に出力されるエラーメッセージである。
# swift-auth-server /etc/swift/auth-server.conf
Error trying to load config /etc/swift/auth-server.conf: No super_admin_key set in conf file! Exiting.
8. 問題点と課題
8.1. 拡張と Ring の更新
Swift のメリットとして、動的にサーバを追加して冗長化・増設を行える点が挙げられる。 しかしその際に、各サーバにある Ring ファイルを更新しなければならない。規模が大きく なるにつれ、この作業による負担も大きくなる。このため、Ring を更新するためのメカニ ズムとして、同じファイルを複数台にコピーするツールなどが必要になるだろう。そのよ うなツールには、pssh などがある。
8.2. サーバの言語設定による不具合
サーバとなる OS の言語設定によっては、Replicator などが正しく動作しなくなる。Swift の内部では、自身の IP アドレスを取得する関数があり、Replicator などが使用している。 この関数の処理内容は、ifconfig の出力結果を解析して自分自身の IP アドレスを取得する ものである。しかし、例えば OS で設定している言語が日本語の場合、ifconfig の出力に日 本語が含まれ、意図通りの解析がされない。このため、自身の IP アドレスを取得できず、 Replicator などが処理を行えなくなる。
対処法としては、起動用のスクリプト内で言語設定を変えればよい。例えば、startrest の中で、各サーバの起動前に export LANGUAGE=C を加えることで対処できる。なお現 行の最新版では、IP アドレスの取得方法が変わっており、言語設定が日本語などでも動作 する。
8.3. Auth Server の設定
各サーバの設定項目については、Swift のドキュメントに記載されている。しかし、Auth Server についてはドキュメントが現行存在しない。このため隠れた設定が存在している可 能性がある。
8.4. Nova との連携
OpenStack プロジェクトでは、Swift の他にも Nova というソフトウェアを公開している。
Nova はクラウドコントローラであり、クラウド環境を構築するためのソフトウェアである。
Swift との連携として、Nova で使用している仮想マシンのイメージを Swift へ保存するこ
とが考えられる。しかし現在、Swift はあくまでファイルサーバとして動作するため、ファ
イルシステムとしてのサービス提供は行っていない。Nova 側で Swift のプロトコルを使用
するなどの工夫が必要になる。
9. まとめ
本調査書では、分散オブジェクトストレージである Swift についてまとめた。機能や構成 するサーバ群、サーバ/クライアント両者の利用方法について述べた。Swift を構成する各サ ーバは複数台から構成することが可能であり、大規模なサーバへ拡大していくことが可能 である。
Swift はまだ発展途上であり、本報告書の内容から更新される可能性がある。実際、本報 告書の執筆中当初はソースコードが bazaar のみで配布されており、CyberDuck も Swift に未対応であった。しかしどちらも執筆中に状況が変化し、本報告書で述べた状況となっ た。今後も OpenStack Nova でのストレージとして利用可能になるなど、更に開発が進む と予想される。
【主な参考文献】
[1] Swift ドキュメント(公式) http://swift.openstack.org/
[2] CyberDuck http://cyberduck.ch/
[3] Deployment Guide http://swift.openstack.org/deployment_guide.html
[4] LaunchPad https://launchpad.net/
[5] Swift(LaunchPad) https://launchpad.net/swift
[7] 日本 OpenStack ユーザ会 http://openstack.jp/
[8] RackSpace Cloud http://www.rackspacecloud.com/
[9] CloudFiles API http://www.rackspacecloud.com/cloud_hosting_products/files/api/ [10] GitHub https://github.com/
[11] CloudFiles API(GitHub) https://github.com/rackspace/
