- - PR -
2台からほぼ同時にファイル共有(RedHat GFS、クラスタ？)
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-08-18 10:55
こんにちは、皆さんの投稿いつも拝見＆参考にさせてもらっています。
現在２台のPCからFiberChannelで接続されたRAIDに片側のPCからファイルをライトした直後にう片側からリードするという作業を繰り返すことを考えています。（できる限り高速 に） あたりまえなのかもしれませんが、同時にマウントして上の作業をやってみるとリード側からファイルが見えなかったり、ファイルが壊れてしまったりと問題が発生しました。 そこでRedHat GFSなどデータを共有するようなクラスタ関連の情報を集めていました。 とりあえずGFSを導入してみるかということでマニュアル参考にやってみようとしたのですが、 http://www.redhat.com/docs/manuals/csgfs/admin-guide/s1-sf-cluster.html に Because of quorum requirements, the number of lock servers allowed in a GFS cluster can be 1, 3, 4, or 5. Any other number of lock servers — that is, 0, 2, or more than 5 — is not supported とあり２台ではできないのでしょうか？ フェンシングデバイスがなければいけないようなことも書いてあったり・・・ そもそもGFS以外にもこのような環境を構築する方法があるのかもしれません。 皆さんがお持ちの経験や知識をご教授いただければと思い、初めてスレッドを投稿いたしました。よろしくお願いします。 | ||||||||
|
投稿日時: 2005-08-18 21:28
GFSとか全然知らないんですが、フォローが無いようですので...
ファイルを書いたプロセスのほうは「書き終わったつもり」であっても OSのバッファに入っているだけでディスクには書き込まれていなかったり しますから、「書いたはずのファイルがない」ということは起こります。 また、マシンAのOSが知らないうちにマシンBのほうがファイルを書き換えて いた、というような場合、ファイル管理情報の変更の内容によっては 「ファイルが壊れているようにみえる」ということも起こると思います。 あともちろん、同時に書き込むと致命的です。 ローカルのマシンの上で動く複数のプロセスが同時にひとつのファイルに アクセスしても「ファイルがない」みたいな問題が発生しないのは、 書き込みに使うバッファと読み出す際のファイルキャッシュとが統合されて いるためです。 GFSがどういうやり方をしているのか知りませんが、「ファイルを読む際に ローカルのメモリ上のキャッシュを調べるよりも先に、ストレージ上の ファイルが更新されているかどうか調べるようにするためカーネルを変更 する」ということと、「同時書き込みを防ぐ」「まずいタイミングで読み 出さないようにする」ためのロック機構が必要になるかと思います。 が、それでもストレージの側で遅延書き込み（write cache）と先読み （read ahead cache）を使っていると、不整合が発生し得るような気も しないでもありません。write cache を off にするか、write through cache みたいな機能を提供する製品を使えば問題ないと思いますが。 ・・・うーん、どうなんだろ？
上に書いたようなロック機構を提供する、ロックサーバの話ではないでしょーか。 ロックサーバを冗長化した場合、どういう方法でプライマリのロックサーバを 決定するようにしているか、ということで2台ではダメな理由があるんじゃあ ないかと思いまふ。 [ メッセージ編集済み 編集者: ぽんす 編集日時 2005-08-18 21:30 ] | ||||||||
|
投稿日時: 2005-08-18 21:32
こんばんわ．
自分も興味があるだけですが．．． iSCSI とか使っても lock する必要あるのでしょうか？ というか，GFS って「一時に複数から書き込める」のでは？ | ||||||||
|
投稿日時: 2005-08-18 22:54
iSCSIも使ったことありませんが... iSCSIが提供するのは生のストレージを 共有する機能であって、その上でファイルシステムを使いたいということで あれば不整合が生じないよう配慮した仕組みが別途必要と思います。
おっと、説明が足りませんでした。 これには「どの層において同時か」ということがあって... 上で「同時書き込み」と書いたのは、デバイス上というか OS - デバイス間のことです。ここで、お互いに他が何をやっているか 知らないところから同じファイルに対する書き込みがばらばらに独立に ごちゃまぜにやってくると、ファイルとファイルシステムが壊れます。 # それでも壊れないファイルシステムというのも理屈の上では # あり得そうですが、たぶん実用上意味が無さそう。 ですが、OS にファイルの読み書きを依頼しているプロセスからは 競合相手を気にすることなく書き込めるはずです。 そこでみれば、同時書き込みOKということになります。 | ||||||||
|
投稿日時: 2005-08-19 10:01
ぽんすさん、kazさん返答ありがとうございます。
同時書き込みは今回しないのですが、同時アクセスになるのでどちらにせよロック機構が必要そうですね。。イメージ的には１台（Ａ）にロックサーバを立ち上げます。そして（Ａ）はローカルもう１台（Ｂ）はリモート（Ａ）のロックサーバを見に行くようなことができれば・・・と考えていましたが、２台とは別の（Ｃ）でロックサーバをあげないとだめなんでしょうかね。。。３台の設定例はGFSのマニュアルにもあるようなのですが。。。３台目用意するのも考えてはいますができれば２台でやりたいですな。。。 | ||||||||
|
投稿日時: 2005-08-19 13:54
日本語では
http://www.sc-i.co.jp/products/sistinafaq.htm#ninshiki http://japan.cnet.com/news/ent/story/0,2000047623,20069498,00.htm ------------------------ 検索語 HPC File system cluster -------------- ここから、先の話は 分散ロックマネージャ の方になってゆくようです。 =====＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ Because of quorum requirements, the number of lock servers allowed in a GFS cluster can be 1, 3, 4, or 5. Any other number of lock servers — that is, 0, 2, or more than 5 — is not supported とあり２台ではできないのでしょうか？ の答えは Single Lock Manager (SLM) — A simple centralized lock manager that can be configured to run either on a file system node or on a separate dedicated lock manager node. だから、ファイル・ノードと共用可、Redundant Lock Manager (RLM) はダメらしい。 GFS とは(読めてないが) 仮想ディスクを作る、(プールボリューム定義して RAIDやパーティションを束ねて) 次に、仮想ディスク内にgfs_mkfs する(ここに分散ロックマネージャのパラメータが必要)、 次に、仮想ディスクをマウントする。 ちゃんと、GFSのマウントポイントで使うと分散ロックされるのでは ローカルデバイスのままでは、分散ロックしなさそう。 [ メッセージ編集済み 編集者: MMX 編集日時 2005-08-23 15:20 ] | ||||||||
|
投稿日時: 2005-08-19 21:45
こんばんわ．
そのようですね． MMX 様よりいただいた情報を参照する限り， > このファイルシステムはロック機構が組み込まれ、 > ファイル共有が出来る以外は、 > Linuxネィティブのファイルシステム > （ｅｘｔ３、JFS、XFS）と全く同じように使えます。 と，ここをご指摘ですね -> ぽんす様 でも，これを見る限り「バラバラで書き込みに来ても大丈夫」なように思えます． | ||||||||
|
投稿日時: 2005-08-20 01:25
素朴に考えれば、AとBのどちらか一方にロックサーバとしての役目を 兼ねさせるのはアリと思いますが、実際どうなってるかは分かりません。 マニュアルを読むなり、それでも分からなければ試しに設定してみれば よいのでわ。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。