swift

2012年03月09日

WireSharkでSwiftの処理の流れとかを追っているのですが
いかんせんPortを複数使っていて
見分けるのが面倒なんですよね。

オマケにservice名解決を有効にしてたりすると
6000~が全部x11になってしまって
account(6002)、container(6001)、object(6000)の区別がつきませんし!

後、中身の書式がHTTPなのに
単なるTCPとして読まれるとかも・・・/(^o^)\

そんな訳で本来便利なはずのWireSharkの機能ですが
Swiftでは見事に裏目に出ていたり、適用されてない感があるので
なんとか便利に使えないかカスタマイズしてみました。

■serviceとして定義する
Windows版での話ですが
/etc/servicesに相当するファイルが
WireSharkのフォルダにあったので書き換えてみました。

書式とか細かいことは省きますが
とりあえず以下の番号と名前が登録されるように修正します。
うちはdiffファイルを貼るような親切なブログじゃないぜ!
# 元ファイルをバックアップしてなかっただけともいう
keystone 5000/tcp
swift-object 6000/tcp
swift-container 6001/tcp
swift-account 6002/tcp
swift-proxy 8080/tcp
keystone-adm 35357/tcp

X11とかhttp-altとして既に定義されていたりするので要修正。
コメントアウトしておきましょう。

長いけどPort番号順に並んでいるので
自分が定義したPort番号の設定箇所を探しやすいです。
# 範囲指定なパターンがあるのでエディタでの検索がしにくい

■HTTPの設定にSwiftのPort番号を入れる
WireSharkのEdit→Preference→Protocols→HTTP
で、TCP Portsの定義でSwift関連のPort番号を追加します。
設定画面はこんな感じ。

tcp_port


WireSharkの画面はこんな感じ。捗るぞ。
after



Swift解析時以外は役に立たないのは言うまでもない。

nanodayo at 19:33コメント(3)トラックバック(0) 

2012年03月08日

TechTargetの記事やらOpenStackインストール手順のようなものを参考に作ってみました。

OpenStackインストール手順のようなものと同様
diablo-stableを対象にしています。

登録内容としてはswiftのドキュメントに乗ってるサンプルの
tempauth用のアカウントと同じものを登録します。
挙動が違ったり互換性がなかったりするけどなー(゚∀゚)
#!/bin/bash
BIN_DIR=${BIN_DIR:-.}
BIN_DIR=/usr/bin

# IP 変えないとlocal以外で使えないぜHAHAHA
SWIFT=127.0.0.1
KEYSTONE=127.0.0.1

# Tenants
$BIN_DIR/keystone-manage $* tenant add admin
$BIN_DIR/keystone-manage $* tenant add test
$BIN_DIR/keystone-manage $* tenant add test2

# Users
$BIN_DIR/keystone-manage $* user add admin secret admin
$BIN_DIR/keystone-manage $* user add test:tester testing test
$BIN_DIR/keystone-manage $* user add test2:tester2 testing2 test2
$BIN_DIR/keystone-manage $* user add test:tester3 testing3 test

# Roles
$BIN_DIR/keystone-manage $* role add Admin
$BIN_DIR/keystone-manage $* role add Member
$BIN_DIR/keystone-manage $* role add ServiceAdmin
$BIN_DIR/keystone-manage $* role grant Admin admin
$BIN_DIR/keystone-manage $* role grant ServiceAdmin test:tester
$BIN_DIR/keystone-manage $* role grant ServiceAdmin test2:tester2

# services
keystone-manage service add swift object-store "Swift Object Storage"
keystone-manage service add identity identity "Keystone Identity Service"

#endpointTemplates
$BIN_DIR/keystone-manage $* endpointTemplates add RegionOne swift https://${SWIFT}:8080/v1/AUTH_%tenant_id% https://${SWIFT}:8080/ https://${SWIFT}:8080/v1/AUTH_%tenant_id% 1 1
$BIN_DIR/keystone-manage $* endpointTemplates add RegionOne identity http://${KEYSTONE}:5000/v2.0 http://${KEYSTONE}:35357/v2.0 http://${KEYSTONE}:5000/v2.0 1 1

# Tokens
$BIN_DIR/keystone-manage $* token add 999888777666 admin admin 2015-02-05T00:00

#Tenant endpoints
$BIN_DIR/keystone-manage $* endpoint add admin 1
$BIN_DIR/keystone-manage $* endpoint add admin 2

$BIN_DIR/keystone-manage $* endpoint add test 1
$BIN_DIR/keystone-manage $* endpoint add test 2

$BIN_DIR/keystone-manage $* endpoint add test2 1
$BIN_DIR/keystone-manage $* endpoint add test2 2

$BIN_DIR/keystone-manage $* credentials add admin EC2 'admin:admin' admin admin || echo "no support for adding credentials"
tempauthで作ったアカウントとの互換性はありません(キリッ
tempauthとkeystoneとでaccountのパス生成ルールが異なるためです。
(トップ階層のディレクトリパスが違うみたいな話)

tenantがaccountに相当するみたいです。
test:testerでも
test:tester3でも同じコンテナが見れるのはSwiftとしては正しい挙動っぽい・・・?

nanodayo at 10:48コメント(2)トラックバック(0) 

2012年03月01日

SwiftクライアントといえばCyberDuckですね。
Swift以外にもFTPとかSCPとか
結構な数のファイル転送プロトコルに対応しています('-'*)
他にも動作環境がMacとWindows両方対応していたりと。

・・・でもなんか、最近のSwiftには対応してるんだっけ(
Bexar時点では対応していたのですが
認証時のURLが変わっているとか
ヘッダの名前が変わっているとかで最新版には追いついていなかった ような。

後、そもそもCUI環境でのクライアントが欲しいってパターンもありまして・・・

REST APIなシステムなので
こちらのスクリプトみたいに、
curlにオプションを指定してやれば使えちゃいます。

なんですが、最新版だとヘッダの名前が変わっていたり
そもそもtest:testerみたいな形式とは限らなかったりで
こちらも実情に即していないです。
swift_authをこんな感じにすればそのまま現行版に対応できます。
#!/bin/bash

mkdir ~/.swift/
curl -k -v -H "X-Auth-User: $1" -H "X-Auth-Key: $2" "$3/v1.0" > ~/.swift/auth.out 2>&1
grep X-Auth-Token ~/.swift/auth.out | awk -F ": " '{print $2}' > ~/.swift/token
grep X-Storage-Url ~/.swift/auth.out | awk -F ": " '{print $2}' > ~/.swift/url
使う時はこんな感じ。
swift_auth user key http://address:port
http://から入れないといけない仕様にしたのは、httpsを使う場合を視野に入れて。

swift_authさえこちらに書き換えればswift_getとかはそのまま使える・・・はず。












ちなみにswiftという
もっとイケてる付属のクライアントコマンドがあるので
特に上記のスクリプト使う必要は無いです(キリッ

nanodayo at 12:16コメント(3)トラックバック(0) 

2012年02月29日

困ったときこそブログに書こうという今日この頃です。

Swift+Keystone自体は
TechTargetの記事などにもあって
今更需要もないかなという感じだったのですが
(手を付けてなかっただけとも言う)

掲載されているRPMが配布終了していまして・・・/(^o^)\どうすっぺ

http://yum.griddynamics.net/yum/ までは残っていて、違うディレクトリで
diabloのrpmは配っているようです。
ただserviceコマンドとかでkeystoneは動かない模様/(^o^)\

とりあえずこのあたりを参考に動かしてみてます。
http://2done.org/openstack/install/keystone.html

一応、動くっぽ・・・?

上記2つのページを参考にしつつ
keystoneにデータを入れて動かしてみました。
swiftコマンドも成功するよ。

・・・成功するにはするんですが。TechTargetの記事では
Account: AUTH_admin
Containers: 0
Objects: 0
Bytes: 0
みたいになるはずなんですが
Account: AUTH_1
Containers: 0
Objects: 0
Bytes: 0
みたいになってまして。

endpointとして指定しているtenant_idが数値で展開されるか
文字て展開されるかの違いでしょうけど・・・はてさて。

・・・でもよく考えたら別に数値で展開されても問題にならないような気がしてきました(

nanodayo at 18:34コメント(0)トラックバック(0) 

2011年04月02日

Swiftでは基本的にProxy Serverがクライアントと通信して
実際にデータを持っているサーバが変わってもいいようになっています。
じゃあProxy Serverはどうやって
データを持っているサーバを選んでいるかというと
Ringというファイルを元に決めています。

そんなわけで今回はSwiftのRingファイルについてです。
基本的には、データ置き場のサーバのリストですが
含まれている情報としては以下のものがあります。
  • IPアドレス
  • Port番号
  • サーバ上のパス
  • 優先度
  • パーティション数
  • メタデータ
  • 複製する数
  • ゾーン

順に説明していきます。
  • IPアドレス
  • Port番号
  • サーバ上のパス

これは解らないと通信できませんからね。
サーバ上のパスも指定できます。
  • 優先度
  • パーティション数

ここでいうパーティションとはSwift上の概念です。
1パーティションに1ファイルが置かれるもので
各サーバに対してパーティションが
いくつか割り当てられるという認識でいいようです。

優先度の高いサーバほどよくデータが置かれますが
優先度の高いサーバほど多くのパーティションが割り当てられる ってことかなぁ。
  • メタデータ

メタデータってなんなんだー

Swiftではメタデータを扱うことができます。
メタデータというのは、ファイルに追加できる拡張情報です。
例えば音楽であれば、アーティスト名やアルバムの名前ですね。

・・・なんですが、ここでのメタデータはファイルに付けるものとは全く関係ないです。
(ファイルのメタデータ自体は扱える)
ただ同じような概念で、サーバに対して自分で情報を追加できます。
といってもそんな大それたものではなく、単なるメモを追加するための項目です。
  • 複製する数

個別のサーバの情報ではなく、Ring全体のための情報です。
後で変えたくなったときはどうするんだろう・・・?

どのサーバにするかは一方向ハッシュを用いて決定しているようです。
  • ゾーン

複製のポリシーに関わってくるフィールドです。
同じゾーンのサーバに対してはデータをコピーしません。

nanodayo at 12:17コメント(2)トラックバック(0)