【NFS】Network File System

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/23 20:04 / Filesize : 235 KB / Number-of Response : 968
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/03/28(火) 11:42:41 ]: nfsに関する話題を扱うスレ
201 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/24(土) 14:19:25 ]: ちなみに、わざわざ C言語でプログラムしなくても、
シェル上で同じことができる。

umask 777
echo hoge > file

とやれば、fileは読み込みも書き込みも不許可で作成されるが、
echo hogeの内容はちゃんとfileに書き込まれる。
fileがNFS上にあっても当然動作しなければならない。
202 名前：名無しさん＠お腹いっぱい。 [2007/11/24(土) 14:21:35 ]: なるほどumaskはそうやって使うんですね
203 名前：名無しさん＠お腹いっぱい。 [2007/11/24(土) 17:34:17 ]: >>198
RFC1813, 4.4 Permission issues の第3段落に書いてありました
204 名前：名無しさん＠お腹いっぱい。 [2007/11/25(日) 15:06:35 ]: RPC でつかうポートが変化するから、
NATルータ越しのNFSは㍉？
VPN 通すしかない？
205 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/11/25(日) 17:00:41 ]: Intelの82573L で2.4系カーネルでNICのリセット多発した。
結局、NICのROMのアドレス1部変更で直った。
2.6カーネルでは解消された。
206 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/06(木) 13:41:08 ]: >>204
実装によってはポート固定も無理ではないが、
ここで聞かないとわからないレベルならお薦めしない。
あと、WebNFSという選択肢もある。
207 名前：名無しさん＠お腹いっぱい。 [2007/12/19(水) 02:30:55 ]: NFSとiSCSIでよくファイル単位と、ブロック単位という比較を聞くんですが、
NFSサーバに10GBのファイルがあって、それをNFSクライアントで読み込むときに
10GB全部をクライアントでリード・ライトしなきゃいけないとかそういうことなんでしょうか？
208 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/19(水) 09:08:58 ]: >>207
> NFSとiSCSIでよくファイル単位と、ブロック単位という比較を聞くんですが、
どこであるいは誰に聞いた？
209 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/19(水) 09:21:46 ]: >>208
google: NFS iSCSI ファイルブロック

itpro.nikkeibp.co.jp/article/COLUMN/20060407/234778/
＞データ転送の単位は，NASにアクセスするときはファイル単位となる。つまり，NASへのデータ・アクセスでは，ファイル名や共有名などファイルを特定する呼び名で管理している。
＞これに対し，SANの場合はブロック単位の処理になる（通常1つのファイルは1つまたは複数のブロックで構成される）。SANでは，リモートにあるディスク装置内のディスクが，あたかもローカル・ディスク（RAWデバイス＊4）であるかのように振る舞う。
（略）
＞IP-SANには，「FCIP（Fibre Channel over IP）」「iFCP（Internet Fibre Channel Protocol）」「iSCSI（Internet SCSI）」という規格がある。この中で最も期待されているのがiSCSIである。

ってことじゃねーの？
210 名前：名無しさん＠お腹いっぱい。 [2007/12/19(水) 09:58:18 ]: SCSIの復活キター？
211 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/19(水) 11:14:58 ]: って事はiSCSIの方が巨大ファイルでは優位って事なの？
212 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/20(木) 16:46:40 ]: 何を持って優劣の指標としているのか明快に述べよ
213 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/20(木) 16:58:19 ]: 何を持って誤字の書込みをしているのか明解に述べよ
214 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/27(木) 14:42:36 ]: NFSとiSCSIではファイルシステムの層が違う。

ファイル操作システムコール(API)
VFS
個々のファイルシステム(ext3,xfs,reiserfs,fat16,iso9660)
ドライバ
ハードウェア

NFSってのはファイル操作システムコールに相当、ファイル単位でも扱えるし、
バイト単位で読んだりもできる。VFSから下は考えなくてよい。

iSCSIってのはドライバに相当、ファイル単位では考えないで、
ハードウェアとのやりとりの最小単位(ブロック単位)で考えなければならない。
システムとして利用するには、ファイルシステム、VFS、システムコールも備えていなければならない。
215 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/27(木) 14:48:10 ]: >>212-213
以って？
216 名前：名無しさん＠お腹いっぱい。 [2007/12/27(木) 19:59:34 ]: RedHat Linux Enterprise Linux ES 4 2台で NFS サーバと NFS クライアントの設定をしました。
NFS サーバと NFS クライアント側では、それぞれの /etc/passwd にユーザが同じuid、gidで
登録されていて、group hoge に属するユーザだけに書き込ませたいです。

NFSサーバ側：
# mkdir -p /opt/share; ← NFS で共有したいディレクトリを作成
# chgrp hoge share
# chmod g+ws share;

/etc/exports の内容：
/opt/share 192.168.0.0/255.255.255.0(rw,sync)

NFS クライアント側
# mkdir -p /opt/share ← マウントポイントとなるディレクトリを作成
# chgrp hoge share
# chmod g+ws share;

mount -t nfs {nfs_server_name}:/opt/share /opt/share

ここまでは簡単にできたなのですが、nfs クライアント側から、umask が 0022 なユーザが
書き込みをすると、NFS サーバ側では -rw-r--r-- というファイルができます。
ここまではあたりまえですが、これを NFS 側で、強制的に -rw-rw-r として保存するような設定はありますか?

samba だと smb.conf で、公開ディレクトリのブロックの中で
　directory mask = 0664
とできますが、これと同じようなことがしたいです。
217 名前：名無しさん＠お腹いっぱい。 mailto:sage [2007/12/28(金) 05:39:34 ]: /opt/share のファイルシステムのマウントオプションのumaskしだいでは?
NFSサーバの実装によってはそういうのもありえるかもしれないけど、
NFSサーバでumaskを強制させてもあまり意味がないのかも。roかrwくらいだろうし…
218 名前：216 mailto:sage [2008/01/05(土) 07:48:19 ]: >>217
レスどうもありがとうございます。遅くなってすみません。

結局以下の方法で対応しました。

NFS サーバ側で uid hoge / gid hoge という共通ユーザを作成し、
NFS サーバの /etc/exports で以下のようにした。
/opt/share 192.168.0.0/255.255.255.0(rw,sync,all_squash,anonuid=xxx,anongid=xxx)
↑ uid=xxx gid=xxx は、hoge:hoge の uid と gid

こうすることで、NFS クライアント側は gid hoge に属していれば、uid は別のユーザが
作成したファイルを、別のユーザが消すことができるようになりました。
理想は NFS サーバ側で、どの NFS クライアントのユーザがファイルを作成したか知れたほうが
よかったのですが、ここは目をつぶりました。

なお man mount すると、-t で指定するファイルシステムタイプの中で、
一部では -o に mask みたいなオプションが指定できるようですが、-t nfs のときは、
mask と行ったオプションは用意されていませんでした。
219 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/01/06(日) 11:20:48 ]: そもそも論になるけど、NIS使えば?
220 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/01/06(日) 21:59:39 ]: えーマジNISー？ｗ
NISが許されるのは10人未満のLANまでだよねーｗｗｗ
221 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/01/06(日) 23:17:07 ]: >>220
じゃあなんNISればいいんですか？＞＜
222 名前：名無しさん＠お腹いっぱい。 [2008/03/08(土) 17:17:43 ]: 複数台のサーバ環境（自宅サーバ郡）でNFS使って共有するときって、どのディレクトリをシェアするのが効率的なんでしょ
みなさんの運用方法で「これはおすすめ！」っての、教えてもらえないでしょうか。
ちなみにうちはCentOS5の6台構成（Web 3台、Db1台、開発用1台、DB＆NFS＆Samba鯖機1台）
223 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/08(土) 17:39:30 ]: WebサーバでNFSなんて使わないでくださいネ。
224 名前：名無しさん＠お腹いっぱい。 [2008/03/08(土) 17:43:03 ]: >>223
え、そうなの？
/usr/local/libならシェアしてるけども。
225 名前：名無しさん＠お腹いっぱい。 [2008/03/08(土) 23:39:09 ]: NFSっていらんやろ
226 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/08(土) 23:47:11 ]: >>222
/homeのNFS共有は当然として、
OSのバージョンが同じなら /usr以下をすべてNFS共有する。
updatesとか、OSのバージョン管理が一元化できる。
ホストを1台増やす時でも、OSをインストールする必要はない。
もともとインストール済の/usrをNFS共有して、
ホスト毎に必要な/etcや/varなどを個別に用意するだけで済むから。
227 名前：名無しさん＠お腹いっぱい。 [2008/03/09(日) 13:46:30 ]: >>223
ロードバランサーでWebサーバ束ねているような場合、コンテンツの
directoryをNFSで共有って、良くやるパターンだよね？
セキュリティの事を気にして言っているの？
だとしても、その対処法はあるわけで。
228 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/09(日) 21:25:20 ]: たいていのパッケージシステムは、/usrのNFS共有を想定してないんじゃないかな。
少なくとも、ベンダやメンテナによるテストはあまりされていないよね。
そもそも今はパッケージシステム(と安くなったディスク)のおかげで、/usrを共有する必要性って薄くない?

ロードバランサで分散しなきゃならないWebトラフィックって、CGI(CPU bound)なやつで、
その場合はRDBを共有するんじゃないかな。NFSサーバではなく。

NFSに限らず、ネットワークは不確かで、トラブルの発生源の代表格。
厄介なホスト間の依存性も発生するし、ホストローカルで完結するならその方がいいに決まってる。
このシステムにNFSって本当に必要なの? って自問してみるのは、管理コストを減らすのに役立つと思う。

個人的な感覚では、システムのメンテナンスのためにNFSをスポットで利用するのは便利だと思う。
(一般ユーザの/homeや/usr/portsみたいなのを共有するということね)
229 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/09(日) 22:31:09 ]: Solarisでは、/usrはNFS共有することが前提で、
パッケージは SUNW**u が /usr用、SUNW**r が /usr以外用と、
きちんと分けて考えられてるね。
なるべく共有できるバイナリを増やすため、
/binを廃止して /binを /usr/binへのsymlinkにしてるくらいだし。
230 名前：名無しさん＠お腹いっぱい。 [2008/03/09(日) 23:41:52 ]: つ、つまり共有すべきなのは/usr, /homeの二つが鉄板ということでおｋ？
ていうかNFSで共有してる時点でかなりアクセスのパフォーマンスが低下することは避けられないですよね、うーむ。
LAN内で共有してるのであればそんなに気にスンナってか。
231 名前：名無しさん＠お腹いっぱい。 [2008/03/10(月) 10:44:40 ]: いまどきNFSなんて使ってるのか？
232 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 11:13:09 ]: >>230
日本語が読めてないな。

Solarisは/usrを共有することを想定して設計されているから共有できる。
おまえが使うOSはSolarisなのか?
233 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 11:36:11 ]: *BSD方面では、NFSは「無かったこと」にしたいんだろうなｗ
234 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 11:42:27 ]: よく知らんけど、Linux方面のNFS実装ってマシになったの?
235 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 13:58:02 ]: 数年前にzero copyな実装になって今ではNFSv4まで対応してます。
236 名前：名無しさん＠お腹いっぱい。 [2008/03/10(月) 14:41:03 ]: NFSでマウントしたディレクトリってやっぱりアクセス速度が低下するんですか

ってことはデータベース（MySQL)のデータ領域をNFS共有して運用するなんてしちゃだめですね。
でもなんでWebならいいんだ？
237 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 14:53:29 ]: 書き込まないなら良いんじゃない？遅いけど。
238 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 16:02:19 ]: OracleみたいにNFS向けに最適化されているならともかく、
通常のデータベースはNFSファイルシステム上に置いてはいけない。

> でもなんでWebならいいんだ？
Webでもよくはない。NFSで複数のWebサーバがコンテンツを共有するのは、
導入費用も管理コストも高くつくアプローチだ。
239 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 16:05:35 ]: しちゃだめって言うより
意味なくね？
240 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 16:08:35 ]: >>238
> OracleみたいにNFS向けに最適化されている

そうなんか。
Windows 用のだとネットワークストレージ上に DB 作成するのは
やめとけ、みたいな感じだったけど(実際ごにょごにょしないと
作成出来ないし)。
241 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 16:20:33 ]: 一万個の小さいhtmlファイルが1分ごとに更新されるとかの変なwebサイトで無い限り
NFSなんて使わないほうがいい
242 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 16:36:32 ]: >>236
>>227のことと合わせて考えると、Webの場合はCPUがボトルネックになりやすいから、
ロードバランサを導入する意味はある。ただし、変更されるデータの一貫性維持は
どこかで考えておかないといけない。ありがちなのは、そういうデータはDBサーバに
置いて、一貫性維持はアプリケーションとDBの合わせ技でまかなう感じ。

で、Webサーバと同じ理屈で、DBサーバのデータ領域をNFS上に置いて並列運用すると
どうなるかは…
243 名前：名無しさん＠お腹いっぱい。 [2008/03/10(月) 16:40:10 ]: ちょうど今やろうとしてたことが話題にでてきたので教えてください。
サーバが自社内に10台あります、1台目（A）がDBサーバ兼Sambaファイル共有サーバ、もう一台(B)がログ解析＆バックアップ機、
残りの８台をWebサーバにしているのですが、この８台にWebコンテンツが分散しているのが運用上大変（めんどくさい)なため
Aのサーバサーバとして８台のWebをクライアントとしたNFSを構成しようと考えていました。

Webコンテンツは/home以下にHTMLファイルのほかPHPやJavaで書いたスクリプトやプログラムが含まれています。また、オリジナルで
書いたライブラリや、PEARなどの外部ライブラリを習慣として各Web機の/usr/local/libに格納しています。
これらそれぞれのバージョン管理などが非常にめんどくさいので、NFSを導入したいと考えているのですが、
↑のお話だとパフォーマンスが悪いので辞めたほうがよいということですか？
詳しいから、お知恵拝借させてください。
244 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 17:01:22 ]: >>238
WEBサーバの場合、どういう手法が良いんですかね？
rsyncとか？
245 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 17:05:01 ]: >>243
rsync3.0が出て速くなった(らしい)よ
246 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 20:38:04 ]: >>243
ここでそれを質問するということは、NFS環境下で障害を起こすアプリケーション・
ユーザコードの有無を検証できる人があなたの組織にはいないと見るけど、どうかな。

ならばrsyncで各サーバにファイルを配布するスクリプトを書いた方が安全だと思う。
コマンド1発で出来るようにしておけば管理の手間も生じない。
(バージョンに依存したアプリケーションが置かれているとかの理由で)共通化できない
特定のホストを個別に対応することも容易。

一般論として、すでに動いているサーバの構成を変えるのは上策じゃない。
NFSを入れるなら、運用を開始する前にテストするべき。
247 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 21:37:33 ]: NFSはもう古い、って広告、昔あったよね
248 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/10(月) 21:38:39 ]: >>247
どんなん？
249 名前：名無しさん＠お腹いっぱい。 [2008/03/10(月) 22:05:11 ]: >>242
DBにデータを書き込むアプリなら良いけど、ファイルシステム上に
ファイル生成したり、書き換えたりする奴もあるよね。
そうした場合は、NFS置くのが定石。
NetAppみたいの使えば、パフォーマンスもそれほど心配無いだろう。
250 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/11(火) 16:22:22 ]: NetApp買えるなら、その金で1台に集約してNFS不要にする手もあるな。
251 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/11(火) 16:32:41 ]: >>249
アプリケーションがちゃんと並列動作まで考慮してくれてるならいいけど、
通常ファイル使うことからしてあまり期待できないような。

アプリケーションの中身知ってるものならいいけど、自分は定石とまでは言いたくないな。
252 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/11(火) 23:07:04 ]: いずれ結局中身を気にすることにはなる
253 名前：名無しさん＠お腹いっぱい。 [2008/03/12(水) 00:42:22 ]: >>251
ここで言っているアプリは、ロードバランサーで負荷分散できる様な
Webアプリだからね。DBだけじゃなくて、ファイルに書く奴あるじゃん。
そう言うのは、NFSファイルサーバ立てて使うよね？
254 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/12(水) 08:27:40 ]: まあそうだけど、それは「まずい設計をどうにか延命する方法」であって、定石と呼ぶのは抵抗あるなあ。

逆説的だけど、NFS環境を想定したコードが書ける人は、NFSに依存しないで済む方法も用意する。
NFSを使わざるを得ない、というのは、それが本当にNFS上で運用しても問題ないように出来ているのか、一沫の不安を感じるのだ。

NetAppまで導入してしまえば、バックアップ等の運用コストを下げられる余地がでてくるので、
NFSをデスクトップクライアント限定の技術だと考えるのは保守的な考え方かもしれないけどね。
255 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/12(水) 12:59:40 ]: すくなくとも DBのID/PASSはファイル持ちだと思うな。
256 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/12(水) 13:04:17 ]: アクセスをきっかけに変更されないデータならどうだっていいんだけどさー、
>>253はファイルに書くって書いてるじゃん……
257 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/12(水) 13:30:05 ]: >>256
アプリケーションの設計の話だ。
ストレージはファイルシステムだけじゃないだろ?
複数ホスト間で変更の共有が必要な情報を、安易にファイルシステムに格納するアプリケーションは、
トラブルを潜在している徴候だ。
258 名前：256 mailto:sage [2008/03/12(水) 14:56:34 ]: >>257
いやまぁ、だからそういうことを言いたいわけで。
書き込みするのにNFS共有するのは危ないだろうと。
259 名前：名無しさん＠お腹いっぱい。 [2008/03/13(木) 02:27:16 ]: 自宅で5台動かしてるCentOSサーバ（Webサーバ）それぞれにログインするのがめんどい…
/homeを一台でNFS共有して使いまわそうかなと思うのだけど、邪道かな
ついでに/usr/local以下も共有して、自作ライブラリやソースファイルをシェアするってのも検討中。

ガッコで教わったわけじゃないので、どういう風に使うのかが正道なのかわからず、すまんかった…
260 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 10:22:35 ]: /homeは共有してもいいんじゃないか？
261 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 11:25:47 ]: /homeやサイトローカルなディレクトリのNFS共有は真っ当だろう。
てか、自宅なら好きにやればいいと思うが、
システムのブートやデーモンの類はNFSサーバに依存させないのが吉。
ホスト間の依存関係が複雑になると管理がとてもとても面倒になるから。

あと卒直に言えば、ログインが面倒になるほどホスト増やす時点で
かなり間違った道を進んでいる。
262 名前：名無しさん＠お腹いっぱい。 [2008/03/13(木) 12:16:40 ]: >>261
ログイン簡単にするって、どうすればいいの？
うちの会社は100台弱あって大変… /usr/localをシェアするのっていいなあ
263 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 13:23:30 ]: 機械なんだから管理はどんどん自動化しろよ。
なんのためのUNIXだよ。
264 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 13:29:48 ]: シェアはしないけどNFSにする、って方法もあるぞ。
クライアントの /usr/local他のデータを個別に NFS鯖側に持つ。
すると、NFS鯖にログインするだけですべてのクライアントのデータをいじれる。
シェアはしていないので、書き込み競合とかの問題もなし。
265 名前：名無しさん＠お腹いっぱい。 [2008/03/13(木) 15:14:19 ]: >>263
それ、俺もすげー興味ある。
どんな感じで管理してるの？参考にしたい。
266 名前：名無しさん＠お腹いっぱい。 [2008/03/13(木) 16:38:40 ]: NFSにちょっと関係があるかと思い便乗質問で恐縮ですが、
NISも導入した方がいいでしょうか？ひとつのサーバにパスワードやグループなどを
一括管理できるようになるのはメリットかと思うのですが、逆にデメリットって実運用
ではどんなことがあるのかと思い。　よろしくおねがいしまんこ。
267 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 16:40:04 ]: 今更NISか？
LDAPで良いんじゃね？
268 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 18:19:01 ]: >>266 UNIXだけで組んだシステムならNISでも悪くないよ。シンプルだし。
デメリットとしては、古臭いというぐらいだと思うｗある程度の規模になると
LDAP + NSS + nscd の方が安定性も反応性も高い希ガスです。

>>262 100台って少ないね・・・
>>263 激しく同意。人間様のプライドとして単純作業はすべて機械にやらせる。
>>265 cfengine とか Puppet とか？
漏れは自作フレームワークでインスコからメンテから全部楽々運用だな。
人海戦術の手作業で鯖管理してるような DQN を見てると悲しくなる。
269 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 19:14:31 ]: 自作フレームワークをオープンソースでうpしてくれ
270 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 19:17:46 ]: NIS使うとshadow passwdの意味がなくなるんだよな。いや、別にいいんだけど
271 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 19:37:56 ]: うちもNFS+NISだな。
/homeと/usrをNFSで共有。PXE Bootで/もNFS越し。

まあ、数値計算用でほとんど同じ構成だから、あまり凝ったことをしなくても管理は楽。
272 名前：名無しさん＠お腹いっぱい。 [2008/03/13(木) 20:48:20 ]: >>270 C2セキュリティのオプションONにすればok
ypcatで表示しなくなる。
それでも気になる人はNIS+をどうぞ。
273 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 21:16:38 ]: NIS+はサポート終了だって
274 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/13(木) 22:41:03 ]: めでたしめでだし
275 名前：名無しさん＠お腹いっぱい。 [2008/03/15(土) 01:07:04 ]: NFSの転送速度って遅くないですか？
276 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 05:48:30 ]: いやーそれほどでも
277 名前：名無しさん＠お腹いっぱい。 [2008/03/15(土) 09:32:29 ]: うちは50MB/secが限度だった
278 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 15:36:04 ]: うちは75MB/sぐらい。
279 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 16:06:22 ]: > UNIXだけで組んだシステムならNISでも悪くないよ。

悪いこといわんからLDAPにしとけ。
NIS/NIS+はobsolete technologyだ。

特に100台あると(>>262)、NISにはmap転送ストームの問題がある。
280 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 16:56:06 ]: NFS自体
281 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 19:10:52 ]: NIS+はobsolete technologyだが
NISは今も今後も現役。
282 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 19:55:48 ]: 昔はうちでも/usr/localをNFSで共有してたけど、パフォーマンスが悪いので
rsyncで毎晩mirrorする設定にしてるよ。共有してるのは/homeだけ。

/usr/localを更新したらトリガーになるファイルのタイムスタンプを更新して
ＮＦＳ server側で

touch /usr/local/UPDATE

と印付けておく。

で、client側では、

if [ /mnt/local/UPDATE -nt /usr/local/UPDATE ]; then
DORSYNC="1"
fi

とかして実行させる。ここで全てのclientが同時にrsyncかけると負担がかかるので
そのへんはばらけるように工夫する。
283 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 20:12:24 ]: >>281
NISはレプリカが多い時に、
パスワードの同時変更が起きると悲惨。
まさにobsolete。
284 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 20:14:03 ]: NISではレプリカとは言わん。批判するなら正しい用語で。
285 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 20:18:36 ]: じゃあスレーブなw
286 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 20:21:16 ]: ここでhesiodの出番だな
287 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 20:23:38 ]: yppushが起きるだけだが? 何が悲惨?
288 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/15(土) 20:30:30 ]: NISがだめだとおもうならnetinfoを使えばいいのに
289 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/16(日) 01:21:26 ]: おっさんが多いスレなのかしら
290 名前：名無しさん＠お腹いっぱい。 [2008/03/16(日) 14:43:57 ]: エクスポートする、またはマウントするパスで、効率的なやり方を教えてください
291 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/16(日) 15:30:25 ]: /
292 名前：名無しさん＠お腹いっぱい。 [2008/03/22(土) 05:02:33 ]: 高スペック機1台をNFSサーバにして　/export/各サーバ名/home　それぞれを公開Webサーバ台分用意、
そして、各Webサーバ（ひとまず4台）からはそれぞれ/homeをマウントさせて運用したいのですが、変でしょうか？
いちお同バージョンのLinux（centos5.1 x86_64）同士なので/usrも共有しようかなと、これは全機共通で。
こういう使い方ってNFSのパフォーマンス悪いのでしょうか
293 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/22(土) 08:57:35 ]: Linuxのネタをここでやろうとするのは変
294 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/22(土) 12:13:28 ]: 高スペック機1台をNFSサーバにして　/export/各サーバ名/home　それぞれを公開Webサーバ台分用意、
そして、各Webサーバ（ひとまず4台）からはそれぞれ/homeをマウントさせて運用したいのですが、変でしょうか？
いちお同バージョンの FreeBSD 6.3R同士なので/usrも共有しようかなと、これは全機共通で。
こういう使い方ってNFSのパフォーマンス悪いのでしょうか
295 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/22(土) 12:30:31 ]: FreeBSDでNFSはヤツの召還呪文
296 名前：名無しさん＠お腹いっぱい。 [2008/03/22(土) 19:51:32 ]: NFSは激遅
297 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/03/22(土) 20:56:27 ]: >>294
そんなことしないでバックエンド側でファブリック組めばええんちゃう？
298 名前：名無しさん＠お腹いっぱい。 [2008/03/23(日) 03:07:14 ]: >>262
1000台以上あるけど、適当な認証鍵つくって、ループスクリプトでsshでttyつかんで...
ちょいshellscriptを汎用的に書いておけば、一気に全台同じコマンドじっこうできるよん
299 名前：名無しさん＠お腹いっぱい。 [2008/03/23(日) 16:29:41 ]: >>298 どの様に書くのでしょうか。教えていただけますか。ぜひサンプルを。
300 名前：名無しさん＠お腹いっぱい。 [2008/03/24(月) 16:42:59 ]: NISよりも優秀なのってなんだっけ？

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef