[Q] transition of file server
Hiroki Kashiwazaki
今現在使っているファイルサーバの老朽化に伴い，新しいファイルサーバへの
移行を考えています．ファイルサーバをネットワークから切り放す時間を最小
限に留めて移行作業を行いたいのですが，以下のような手順を考えました．
代替機マシン名：ALT
現行ファイルサーバ名：FS
1. FSの/etc/passwd, /etc/group, /etc/shadow などを移行する．
2. ALTでFSの/homeディレクトリを/mnt/nfs/FS/homeなどにNFSマウントして，
ALTの/homeに対してrsyncする．
3. ALTとFSを外部ネットワークから切り放し，ALTとFSだけのネットワークに
する．ALTをSSHでroot Login可能にし，FSから/etcと/homeを，ALTの/etc
と/homeにrsyncする．
4. FSは捨て捨て．ALTを外部ネットワークに接続して再起動．
この手法で「ここが穴じゃん」とか「ここは無駄」とか「こうした方がもっと
cool」とかいうアドバイスありましたら (沢山ありそうですが…) お寄せ下さ
い．
ではでは．
--
柏崎 礼生 (Hiroki Kashiwazaki)@HUIIC
Ph.D candidate in the Division of Electronics & Information
Engineering, Hokkaido University
mailto:r...@cc.hokudai.ac.jp
Tel:+81-11-706-2998
Kawaguti Ginga
<864qz6...@genki00.cc.hokudai.ac.jp>の記事において
r...@cc.hokudai.ac.jpさんは書きました。
> 今現在使っているファイルサーバの老朽化に伴い，新しいファイルサーバへの
> 移行を考えています．ファイルサーバをネットワークから切り放す時間を最小
> 限に留めて移行作業を行いたいのですが，以下のような手順を考えました．
どの程度の規模/責任問題/ユーザー・管理者間の交流があるのか，
によって話が変わる気がします．
> 代替機マシン名：ALT
> 現行ファイルサーバ名：FS
>
> 1. FSの/etc/passwd, /etc/group, /etc/shadow などを移行する．
ここまでは概ね良いとして(この前に user に password 等の
変更の一時的禁止を announce する必要がありますね)，
> 2. ALTでFSの/homeディレクトリを/mnt/nfs/FS/homeなどにNFSマウントして，
> ALTの/homeに対してrsyncする．
(ssh dump| restore でも良い?)
> 3. ALTとFSを外部ネットワークから切り放し，ALTとFSだけのネットワークに
> する．ALTをSSHでroot Login可能にし，FSから/etcと/homeを，ALTの/etc
> と/homeにrsyncする．
これ，文面からしますと 2. はネットワーク接続時に行われていますが，
ユーザーがファイルをいじったりすると話がややこしいですよね．
特に巨大ファイルとか DB みたいなのが絡むと無駄・危険が大きくなります．
また，mail spool が ~/Maildir/ なんかだったりすると，
本人にはどうしようもないところで随時変更が入ります．
だから，あとで rsync しなおし，ということなんだと思いますが，
結局は以下の rsync をどこまで信用するのか，にかかりますね．
rsync の問題(一部?):
* file system の上で動作するので atime は全部リセットされます
(mail spool で問題になったりします)
* ufs についているフラグは保存されない
(FreeBSD で chflags で設定して ls -ol で見えるヤツ)
* (私は未確認なだけ:) hardlink は -H で保存されるはずだが，
本当に大規模に動くかは良く分からない
一応，この辺の問題点が user との間で合意がとれていれば問題ないとは
思います．
# 意外と，FS,ALTが同OSなら HDD つなぎ直して local 接続で
# dump/restore してしまうほうが速かったり，はしないか...
--
∧∧
Zzz.. (- - )⌒⌒⊇～ 川口 銀河
############## ginga-fj-s...@ginganet.org
Hiroki Kashiwazaki
お返事どうもありがとうございますです．
At 22 Sep 2003 00:13:43 GMT,
Kawaguti Ginga wrote:
> どの程度の規模/責任問題/ユーザー・管理者間の交流があるのか，
> によって話が変わる気がします．
ごもっともです．大学の少人数な研究室レベル (学生数10人前後) で，
管理者がユーザ一人一人の実体を把握しているような状況です．更に
うれしい事に (忌むべき事に ?) ユーザはあんまりこのファイルサー
バを活用してくれていません．メールサーバやウェブサーバが，この
ファイルサーバに格納された情報を常時利用しているぐらいです．
容量は全体で 100GB程度．現在ハードディスク容量に対する利用率が
90% 程度まで高まって来ているため，250GB のRAID1 へと移行しよう
としています．ALTも FSもLinux です．本当は X Serveとかだったら
うれしかったのに，しくしく．
> ここまでは概ね良いとして(この前に user に password 等の
> 変更の一時的禁止を announce する必要がありますね)，
後でネットワークから隔絶した時に，/etcもrsyncする事を考えると，
passwordの変更をしても問題が生じないような気もします．
# なんでネットワークから隔絶した後，2.と同様にNFS越しにrsync
# しないで，rsync -e ssh をするのかというと，ただ単に
# /etc/exportsの書き換えをしなければならない分，手順が増える
# じゃない，という下らない理由だったりします．
> > 3. ALTとFSを外部ネットワークから切り放し，ALTとFSだけのネットワークに
> > する．ALTをSSHでroot Login可能にし，FSから/etcと/homeを，ALTの/etc
> > と/homeにrsyncする．
>
> これ，文面からしますと 2. はネットワーク接続時に行われていますが，
> ユーザーがファイルをいじったりすると話がややこしいですよね．
2.は3.でのrsyncに要する時間を極力小さくするために行うこと，と
考えています．100GBまるまる rsyncすると 6時間程度かかりました．
(理想的には2時間程度で終わるはずなんだが) ．差分転送なら数分
で終了させる事ができます．
あと実際に試していないために懸念している事として，ssh サーバの
鍵は移動するだけで良いのかどうか，という点があります．移行後に
ssh でログインすると「のっとられてます」の Warningが出るのでは
ないかと…．
SASAKI Shigeo
8月に、研究室のメールサーバ兼 /home のファイルサーバのディスクが
障害を起こして、急遽、ディスクのコピーをすることになったのですが…
Hiroki Kashiwazaki <r...@cc.hokudai.ac.jp> writes:
> 2.は3.でのrsyncに要する時間を極力小さくするために行うこと，と
> 考えています．100GBまるまる rsyncすると 6時間程度かかりました．
> (理想的には2時間程度で終わるはずなんだが) ．差分転送なら数分
> で終了させる事ができます．
このときは
2. dump コマンドでフルダンプ | ssh で転送して restore
3. dump コマンドで差分ダンプ | ssh で転送して restore
しました。
rsync に比べて処理時間が短かく済んだと思います。
Hideo Sir MaNMOS Morishita
In article <lyisnl9...@maple.is.akita-u.ac.jp>,
そのあいだ、パーティション全体にロックをかけておく必要はあります。
結構痛し痒し。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
Kawaguti Ginga
dump の差分を活用すれば，っていうのは抜けてたなぁ > じぶん
<86llsh...@genki00.cc.hokudai.ac.jp>の記事において
r...@cc.hokudai.ac.jpさんは書きました。
> あと実際に試していないために懸念している事として，ssh サーバの
> 鍵は移動するだけで良いのかどうか，という点があります．移行後に
> ssh でログインすると「のっとられてます」の Warningが出るのでは
> ないかと…．
/etc/ssh/* を移せば OK です.
SAITOH akinori
Hideo Sir MaNMOS Morishita wrote:
>>2. dump コマンドでフルダンプ | ssh で転送して restore
>>3. dump コマンドで差分ダンプ | ssh で転送して restore
>>rsync に比べて処理時間が短かく済んだと思います。
rsyncはファイルの内容まで比較するので、タイムスタンプが
信用できる場合とか、転送先が空パーティションの場合は無駄ですね。
> そのあいだ、パーティション全体にロックをかけておく必要はあります。
> 結構痛し痒し。
パーティション全体にロックをかける（readonlyにしておくか、
アンマウント）必要があるのはrsyncも同じでしょう。
必要があるというか、正しいコピーがとれなくなるだけで
すが。
安全と時間のバランスを取るなら、
dump 0fu - | rsh XXX restore rf -
ロック
dump 1fu - | rsh XXX restore rf -
アンロック
とか
dump 0fu - | rsh XXX restore rf -
サーバ停止
dump 1fu - | rsh XXX restore rf -
新サーバに差し替え
かな？
同セグメント内で盗聴が怖くない時を除いてrshはつかわないほう
がいいんでしょうね。