Swift実証実験
Daisuke Matsui
ライブドアの松井です。
Swift飲み会やtwitterで
Swiftの実証実験の話が上がっているので
議論を進めませんか？
目的としては「大規模なSwift環境の運用ノウハウを得る」ことですね。
徐々に数を増やしていった際に、出てきそうな問題だけでも
・Ringファイルのメンテナンス
・レプリケーションの偏り
・ProxyServerの負荷
等々あります。
有志でサーバを出し合って、環境を構築して
運用してノウハウを得るというやり方を想定しています。
クラウドストレージ研究会で
Swiftネタを発表するので
そこで参加者募集するつもりです。
---
Daisuke Matsui
@nanodayo
Yasuhiro Arai
検証項目いいですね！ 昨夜、自分も本MLに投稿したので、
そちらと一緒に議論していただけると助かります～
2011年11月14日10:48 Daisuke Matsui <sinorev...@gmail.com>:
Ise Koichi
皆様
Motonobu Ichimura
はじめまして!?
市村 (@famao) です。
今年の6月位からSwiftを触りはじめました。
まだ、すべて読み切れているわけではありませんが、よろしくお願いします。
機材面だとあまり協力できないかもしれませんが、知恵はだすべく、
松井さんの話に少しのっからせてもらいます
今思いつくままに書いていますので、あとからこれもこれも！といいだしたり、
どこか間違ってたりするかもしれませんが、それは後日訂正します;-)
・Ringファイルのメンテナンス
Swiftがringファイルを実質すべてのコンポーネント(proxy,account,container,object)で同一である必要が
ある事から、サーバの増減をしたい時にどうやってringファイルをメンテナンスするか、という話です。
今のところ、構成ファイル自体をｓwift内部にストアしておく手法を考えていますが、ベターな解があればいいなぁ...
・レプリケーションの偏り
たとえばアカウントを単一にして皆で共有できるようにしよう！となった際には、アカウントが単一になるため、
アカウントのレプリケーションとして選定されたサーバにアクセスが集中してしまいます。
そのようなデータの隔たりがある際でも、サーバにアクセスが集中しても余裕でさばけるから平気、とか
適切にデータをばらさないとまずくてその場合、zoneの切り方等も含めてどういう設定だとうまくばらけるね、
といったところが気になります。
また、隔たりとは少し話がそれるかもしれませんが、Swiftは
・PUT、POSTの場合
1. 「レプリケーション全てに同時に書き込みを行って完了するまで待つ」
2. そのあと、各書き込みのステータスをチェックし、「結果の過半数で応答するステータスを決める」
・GETの場合
1. レプリケーションのどれか一つを選定する
2. 選定したサーバからオブジェクト等を取り出す
という動きをします。
リクエスト処理はPUT、POSTの場合「常に選定されたサーバ群の中で一番遅いサーバにひきづられ」て、GETの場合
「1/replication数」でどのサーバにリクエストを飛ばすかがきまります。
このため、速いサーバと遅いサーバが混在している環境や、DR用途等を意識してサーバ配置を分散させよう
といった事を意識するととたんに遅いマシンに引きづられて性能がでなくなる可能性が高まります。
用途として、そこそこのマシンを用いて単一のデータセンタにおくべし！というのも方針としてはありなんですが、
ロケーションを分散させたり、あまったマシンを連ねた場合にもそこそこの性能を目指せるか、という話には
興味があります。
# てか、PUT,POST時には結果は多数決できめるんだから、リクエストも完了時点で成功が過半数だったら(もしくはわりきって2個成功したら)
# そこで処理中断しても問題ないんじゃないかと想定してどうやって改造すべきか妄想中です。
# で、GET時にはリクエスト処理が速そうな順にリクエストを出す、と。
・ProxyServerの負荷
すべての通り道はProxyServerですよねー。今のところ、ProxyServer単体でもそこそこ性能はだせるイメージは
ありますが(プログラムネックというより、ネットワークにひきづられるイメージ)実際どうなんだろう、的な話ですよね。
それに加えて...
・運用面の話
特に各アカウントの統計情報とか、ディスクの利用状況とかをうまく集めてくる手法はないかなぁ
(単体コンポーネントならreconなりあるんですが、全体としてみる仕組み)
・認証面の話
認証が今後keystoneに移行していくとした場合、swauthでは、swift内部で適宜処理してくれていた認証部分が
外に切りだされてしまうので、現在のところ、keystone自体がSPOFになりえる状態なんですが、これをうまく扱える
良い手法がないかなぁ、等々たくさんあります。これはおいおい...
・object-serverの配置のコツやらswift-object-auditorの設定値はなにがいいか
swift-object-auditorは、定期的にオブジェクトを全部なめて、MD5が正しいかどうかチェックします。
単位時間あたりに読み込めるバイト数や、どのくらいの間隔をおいてファイルの整合性をチェックするか
の設定値がありますが、これがデフォルト値だと、ある程度ストアするオブジェクトが増えてきたときに
全部読み込むために、I/Oに相当負荷がかかります。
当初は、network性能が一番Swiftに影響を与えると思っていたのですが、データ量が増えた時に
知らないI/O負荷がでまくりでこれにごく最近気付きました。
これ、多分ディスクのI/Oから計算する事になるのとは思うのですが、実はプログラムとしてではなくて、cronで
定期的に行った方が運用的に楽なんじゃないかと思ったりしています。
同様に、みすごしがちですが、swift-object-replicatorの設定値も見ておいた方がよいかなぁと
考えています。
運用とは直接関係ありませんが、こまいところだと
・本当にxfsが一番効率いいの？
・RAID5使うな、といわれていますが、実際のところRAID5にするとパフォーマンス相当おちるの？
あたりは気になっています。
皆様
Motonobu Ichimura
市村です。
言い残した事があったので、またでてきました
・ACLの扱い
認証まわりとも関連するのですが、keystoneになるとACLがまったく実装されていない状態になります。
swauthだとコンテナ毎にACLがかけられるのですが、swauthでも、ACL設定はアカウントを跨げない
という制限があります。
ex) accountA:userA さんに対してaccountB:userBさんが読み取り許可を与える、といった事ができない
keystoneを利用する場合、現時点ではどうせACLを自分で実装するはめになるでしょうから、
どうせならACLはこうあると運用面でもサービス面でもいいよね、という指針があるといいなぁと思っています。
powered.by.solaris
お世話になります。中島でございます。
私も市村さんの指摘されている、
object-auditorの挙動に最近気づきました。
1サーバに大量のSATAディスクを搭載して使う場合は
遅いSATAディスクへ細かなI/Oが大量に走ってしまうので
間隔の調整やcron化＆GET時のチェックのような形式のほうがいいのかもしれません。
認証周りはOpenStackとしてはKeyStoneと連携せざるを得ないと思いますが、
Swift単体での利用を考えると別途何か仕組みがあると嬉しいですね。
時間があれば認証のLDAP連携や、Hadoopへのデータロードツールなんかを作ってみたいですが、
本業が年度末に向けて活気づいているのでなかなか手がつかない状況です。。。
HWの準備に関しては今週末のOSC2011と、
11/30のOpenStack+CloudStack勉強会でSwiftの発表するので、
そこで実証実験の内容を話して有志を募ってみたいと思います。
HWのゴールはどのくらいで設定するのがよいでしょうかね？
（設置する場所の問題もありますし）
↓これまでの内容をまとめておきます。
-----------------------------------------------------
HW準備
■現状
・中島の検証センターはマシンはそこそこあるがSATAディスクがほとんどない。
・借りるのに時間かかる＆期間制限有り
■やってること
・松井さんがクラストで募集
・中島がOSC2011、勉強会で募集
■決めること
・検証用に何台くらい準備するか？
・設置場所
・期間（いつからどのくらい）
検証・検討項目
■Ring
・徐々に台数が増える場合のメンテナンス方法
・構成ファイル自体をｓwift内部にストアしておく手法
■Proxy
・徐々に台数が増える場合の負荷
・単一アカウント時に負荷集中、Zoneの切り方
・GET、PUT/POST ロケーションを分散させたりする場合に問題あり
■Account
・SWAuth無き後の細かいところをどうするか
・keystone自体がSPOFになりえる状態
・ACLの扱い
■Container
・コンテナ同期とか
■Object
・swift-object-auditor、swift-object-replicator の負荷
■運用面
・各アカウントの統計情報とか、ディスクの利用状況とかをうまく集めてくる手法
■その他
・本当にxfsが一番効率いいの？
・RAID5にするとパフォーマンス相当おちるの？
-----------------------------------------------------
以上。よろしくお願いいたします。
2011年11月14日23:25 Motonobu Ichimura <moto...@gmail.com>: