GraduationThesis Archive

前回の続き。
LVSにおけるセッション維持を調べているうちにGFSのパーミッションについて気になった。

結論としては、アクセスの可否はNFSと同様にuidやgidなどの値が同じかどうかを見ているだけぽい。
例えば、あるサーバのapacheの実行ユーザapache(uid=48)が共有ファイルシステム上にファイルを作る。
このファイルのパーミッションがapacheユーザ(uid=48)がアクセスできるものである場合、
別のサーバのuid=48のユーザもそれにアクセスできる。たぶん。

ファイルシステム上にセッションファイルを置く場合、
apacheの実行ユーザがセッションファイルを参照できるようにする必要があると思うのだけど、
これって上手くやれば他人のセッションファイルを覗いたりできないのかなぁ。
ちょっとこの辺も調べたい。

まあでもセッション情報の保存にファイルシステムを利用するってのは向いてないっぽい。
ファイルシステムにもよるけど、ファイル数が増えると著しく検索性能が低下してしまうらしいし。
普通はデータベース使うわなぁ。

ちょい前に調査したことを復習がてらまとめ。
内容に間違いがあるかもしれないので、あまり信頼しすぎないように。
もし間違いがあればツッコミいただけると助かります。


LVSを利用する際、セッション維持をどうするか。

その前にちょっとセッションについて。
セッションについては、こちらがとてもわかりやすく解説してくれていました。
コレ見ればこのエントリの大部分は見ないでも良いです(ぉ

基本的にHTTPは"状態"というものを持たない。
だから、認証ページとかで認証して次のページに遷移した後、
認証したという事実は保持されない。
それゆえ、再び認証が必要なページに訪れると再度認証する必要がある。
これを防ぐために、クライアントが既に認証したという事実を何らかの方法でわかるようにし、
一度認証した後に認証が必要なページにアクセスした際、
その情報を参照し認証を省けるようにする。
上記のように、HTTPにおいて状態を保持するためのしくみがセッション。

基本的にはセッション維持には次のような方式がある。ほとんどこちらに書いてある。

1. ソースIPアドレスを利用したもの
2. SSL sessionIDを利用したもの
3. クッキーを利用したもの
4. URLによるセッションID渡し

基本的にセッション維持のためには、何らかの情報をサーバサイドが保持する。
ソースIPアドレス方式ならクライアントのIPアドレス、
SSL sessionID方式ならSSL sessionID、クッキー方式とURL方式ならセッションIDなど。

ちょっと1は毛色が違うかな。
ロードバランサの場合は情報を保持するのがロードバランサになるし。
ちなみに、ソースIPアドレス方式は、プロキシに対応できないという問題があります。
SSL sessionID方式もブラウザによってはセッション中にセッションの再手続きをして、
SSL sessionIDが変わってしまうためセッションが維持できないことがあるという問題があったり。
メジャーなのは3かな？ただ3はクライアントがクッキーを有効にしているという前提なので、
クッキーが無効だとダメ。4はクッキー無効でも一応セッション維持できるが、
気をつけないと脆弱性がある。が、それを言うとクッキーも脆弱性がある。
というかセッション自体が気をつけないと脆弱性がある。
まあ今回は実験的なものなので、その辺は路線から外れるから無視。

ロードバランサを導入したシステムにおいて、
サーバサイドにセッションに関する情報を残す場合、
ロードバランサが情報を保持するようなセッションならば問題ないのだが、
Webサーバが情報を保持するようなセッションはマズい。
あるリクエストをあるクラスタノードが処理し、認証などを行いセッションを生成する。
次にクライアントがリクエストを送信した時、
最初にリクエストを処理したクラスタノードと別のクラスタノードにリクエストが割り振られてしまうと、
今回リクエストが割り振られたクラスタノードは認証したという事実がわからない。

上記のような理由から、
ロードバランサを導入したシステム上では、
Webサーバにセッション情報を保持するようなセッションを利用する際に、
何らかの対策をとる必要がある。
ちなみに、ロードバランサによるセッション維持は、LVSではソースIPアドレスによるものだけぽい。
UltraMonkey-L7プロジェクトみたいに、
LVSを拡張してレイヤ7セッション維持に対応したものもあるみたいですが、
こちらは詳細を見てないのでわかりません。
機器としてのロードバランサは高いだけあって、
セッション維持に関してはLVSよりも選択肢が用意されているハズ。

LVSでセッションを維持するためには、
何らかの手法を用いてセッション情報をクラスタノード間で共有する必要がある。
それはデータベースであったり、共有ファイルシステムであったり。
そこで、僕の卒論はLVS+GFSな環境、GFSは共有ファイルシステムなので、
セッション維持が簡単にできるのではないか？ということで調査してた。
本筋とはちょっとずれてるんだけど。

とりあえず現状見た感じではできる。
phpのセッションは、
セッションを生成した際にセッションIDをサーバに保存するのだが、
この保存先のパスは指定できる。
だから、GFSの共有領域にそのセッションIDを保存するようにする。
ちなみに、GFS上のセッションIDの保存先のパーミッションは、
apacheがアクセスできるようにしないといけない。
セッションIDを参照する時には、全てのクラスタノードが同じ領域を参照するため、
どのクラスタノードがセッションIDを生成しても、全てのクラスタノードがそれを参照できる。
このメソッドなら、どのクラスタノードにリクエストが割り振られても、問題なくセッションを維持できた。
突き詰めていくと穴があるかもしれないけど。

(書いてて思ったけど、GFSのパーミッション管理ってどうなっているのだろう？
LDAPなどで統合したユーザ情報を参照しているならわかるけど、そうじゃない場合。
実験ではセッションIDへ問題なくアクセスできたけど、
他のサーバが問題なくアクセスできるってことは、
パーミッション的にセキュリティがやばい気がする。
そういったユーザ情報を統合したものがない場合、
セキュリティ的にもこのメソッドはちょっとマズい気がしてきた。
ちょっとパーミッション周りもいい機会だし調べてみようかな？)

ちなみになんとなく調査をしているうちに、
データベースとファイルシステムの向き・不向きが気になってきた。
気が向いたらまた調べたい。

GFSに力を入れる前に。
そもそも卒論のシステムで使うファイルシステムはGFSでいいのかというところから。
クラスタファイルシステムについて調べてみる。

クラスタで使用されるファイルシステムには、大別して二種類あると考えて良いみたい。
一つが分散ファイルシステム。もう一つがクラスタファイルシステム。

前者は複数のノードで少しずつデータを保持して、ストライピングを行うファイルシステム。
サーバでRAID0を構成するイメージに近いもの。Google File SystemやLustreなど。

後者はブロックデバイスを複数のノードで同時にマウントし読み書きするファイルシステム。
Global File SystemやOracle Cluster File Systemなど。

GFSやOCFSはRAID0を構成しない場合、HDDの速度がボトルネックになりそう？
共有できても最終的にアクセスできるデバイスが一つじゃ順番待ちになるからね。
分散ファイルシステムは拡張性や信頼性にやや欠けるものの、
ストライピングするだけあって速度が速いかな。
分散ファイルシステム+RAID0とかやるともっと速くなるんだろうか？

もうちょっと調べて使用するものを決定する予定。
思ったよりもファイルシステムの数が多い。
そんで違いを理解するのがしんどい。
最終的には触れた経験があるせいで好奇心が一番強いGFSに落ち着きそうな気はする。

↓次読もうかなと思っている論文。
A 64-bit, shared disk file system for Linux

Red Hatのページに書いてあるように、GFSのバージョン3.0について説明されている論文。
論文自体は発見していたけど、ここで言われているGFSが
Red Hat GFSに関係しているのかがよくわかっていなかった。
少し調べてみたところ、Red Hat GFSと関係したものであることがわかった。
元々GFSはSistina Softwareが販売とサポートを行っていたのだが、
2003年にRed HatがSistina Softwareを買収したのでRed Hat GFSとなったらしい。

卒論でGFSを使おうと思っているので、これを読んでGFSについて学びたいと思う。

しかし英語＆2カラム＆20ページ。
きっつい(^ω^；；)
まあ、慣れればなんとかなるだろ・・・。

読んだのは
Designing an Enhanced PC Cluster System forScalable Network Servicesという論文。
内容は僕が卒論で考えているものに近め、というかほぼそのまんま。
違いは使用するソフトウェアとかファイルシステムあたりかな。
だから評価方法など参考になる部分がそこそこありました。
(少し怪しい部分もあったけど)

英語の文章を読むのは昔マニュアルを見てうんうん唸ったことがあるから
耐性はできているがやはり時間がかかる。
今回もある程度理解しながら一回読むのに6時間ほどかかったし・・・。
他にもざっとpptを形作るのに5時間ほど。
内容の研磨に1時間ほど。言う内容考えるのに1時間ほど。
レジュメ作るのに1時間半ほど。
あと深く理解するための拾い読みを何度も。
時間きっついなぁ。
論文内容紹介の形式から調べてたから余計に時間がかかる。
まあ、慣れてスピードアップしていければいいかな。
時間はかかったけど頑張った分、そこそこしっかりした発表ができたのではないかと。

さっぱり論文は読んだことがなかったが、
自分のやろうとしている分野に近い論文を読むのは結構面白かった。
あと、ファイルシステムなどの比較は今の自分で調べていくよりも
他人の論文を参照していく方が効率が良いことに気がついた。
もちろん深く理解するためには自分で調べていく必要があるんだけど、
軽い理解をする段階では論文で比較されているのを参照するのが楽。
必ずしもその情報が正しいとは限らないけど、
まあ、論文なら信頼性はそれなりにはあるんでないかな。

次はGFSについての論文を読んでみたいな。