システムの複製（クローニング）について

[法]

毎々お世話になります。

Igniteを使用したシステムの複製を計画しています。

ただし全サーバにDATがあるわけでは無いためテープからの展開は出来ないと思って

います。

他サーバのDAT装置からmake_tape_recoveryのデータは読めるのでしょうか。

現在のところ、make_net_recoberyの使用が第１候補となっています。

make_net_recoveryを使用してシステムの複製を実施された方がいればコツ・注意点や

アドバイスをお願いします。

現在の計画概要は下記の通りです。

　新規サーバ：A、B　　　　Ignite-UXサーバ：C

　１．Aを構築し、Cよりネットバックアップ取得。

　２．Bをユーザ介入モード(10sec)で起動し、Cへアクセス。

マニュアルですとクライアントデータをコピーしなければならないとの記載があり

ましたが、２の時点でディレクトリ指定でアクセスできないのでしょうか。

質問要望が散漫しており申し訳ありませんが、宜しくお願い致します。

[rawsq]

> Igniteを使用したシステムの複製を計画しています。

> ただし全サーバにDATがあるわけでは無いためテープからの展開は出来ないと思って

> います。

> 他サーバのDAT装置からmake_tape_recoveryのデータは読めるのでしょうか。

他のサーバで作ったmake_tape_recoveryのデータを展開することはできると思いますが、

他のサーバのDAT装置を使ってブートすることは難しいかと。

(繋ぎかえるとかではなくて、ですよね。)

> 現在の計画概要は下記の通りです。

> 　新規サーバ：A、B　　　　Ignite-UXサーバ：C

> 　１．Aを構築し、Cよりネットバックアップ取得。

> 　２．Bをユーザ介入モード(10sec)で起動し、Cへアクセス。

>

> マニュアルですとクライアントデータをコピーしなければならないとの記載があり

> ましたが、２の時点でディレクトリ指定でアクセスできないのでしょうか。

1.実行後、手動でファイルを変更する必要があります。

2.の際ディレクトリ指定等はありません。CINDEXに事前に書き込まれた情報から選択する

形となります。

以下、覚えているレベルで。

1.が完了(デフォルトの場合)するとサーバCには主に以下のようなディレクトリ/ファイルが展開されます。

a) /var/opt/ignite/client/{MACアドレス}

b) /var/opt/ignite/client/{ホスト名}

c) /var/opt/ignite/recovery/archives/{ホスト名}

a)にはその対象サーバに関する情報が含まれます。

b)はリンクで、リンク先は対応する上記a)となっています。

c)には実際のアーカイブファイル(tar)が保存されています。

編集する必要があるファイル群はa)以下に存在します。

a)配下の主な内容は以下。

CINDEX...make_net_recoveryでリカバリする際選択できるアーカイブセット(どの設定で復元するか。つまりどのe)フォルダ以下の設定を利用するかということ。)

d) recovery...アーカイブの設定を格納。詳細は以下。

e) recovery/YYYY-MM-DD,hh:mm...各アーカイブ毎の設定を格納するフォルダ。日付は

アーカイブを採取したとき。

f) recovery/YYYY-MM-DD,hh:mm/archive_cfg...アーカイブファイル(tar)の場所を指定

g) recovery/YYYY-MM-DD,hh:mm/system_cfg...H/Wインスタンスやネットワークの設定

あとサーバBはmake_net_recoveryによるインストール中サーバCのc)をNFSマウントします。

よってサーバCの/etc/exportsの編集が必要かと。

[法]

rawsqさん、ご意見ありがとうございます。

>他のサーバのDAT装置を使ってブートすることは難しいかと。

>(繋ぎかえるとかではなくて、ですよね。)

そうです、繋ぎ変えもしません。（SCSIも無いので）

調べてみたのですが、参考資料が見つかりません。

やはり無理のようですね。

make_net_backupからの戻しは経験があるので、下記手順で実施しようと考えて

いました。

○サーバをブートする

1. 10sec〜で起動、「bo lan」のIP指定でIgnite-UXサーバを指定。

○自ノードのネットワーク設定画面へ遷移する

2. ネットワーク設定画面で、バックアップを取得したIPアドレス・ホスト名を

　 仮指定する。

○インストール画面へ遷移する

3. インストール画面でIPアドレス・ホスト名を正規の設定にする。

手順的に間違いがないか、検証できる環境が無いため確証が取れません。

ご存知でしたら添削・助言をお願いします。

以上、宜しくお願いします。

[rawsq]

> ○サーバをブートする

サーバBですよね。

> 1. 10sec〜で起動、「bo lan」のIP指定でIgnite-UXサーバを指定。

> ○自ノードのネットワーク設定画面へ遷移する

> 2. ネットワーク設定画面で、バックアップを取得したIPアドレス・ホスト名を

> 仮指定する。

ここでバックアップを取得したIPアドレス・ホスト名にすることでバックアップデータ

にアクセスしよう。ということでしょうか。

確かにココで設定したアドレス/ホスト名はサーバB＝Igniteサーバ間が通信する際に

利用しますが、先に述べたとおり設定ファイルはMACアドレスベースのフォルダに格納

されているためバックアップを取得したサーバAの情報へはアクセスできないと考えます。

> ○インストール画面へ遷移する

> 3. インストール画面でIPアドレス・ホスト名を正規の設定にする。

よって、サーバAのバックアップ情報へはアクセスできないかと。

参考程度に手順を。(検証されておりません。)

○サーバAにてバックアップ採取

○サーバBをブートする

1. 10sec〜で起動、「bo lan」のIP指定でIgnite-UXサーバを指定。

○自ノードのネットワーク設定画面へ遷移する

2. ネットワーク設定画面ではサーバBのホスト名/IPアドレスを利用。

○インストール画面へ遷移する

この時点でサーバCの/var/opt/ignite/client/{MACアドレス}が出来上がっていればOK。

作成されていなければもう少し進んでみる。(Advance modeの画面まで行ってみる。

2-a. サーバAの情報をコピー

# cd /var/opt/ignite/client

# cp -p {サーバAのホスト名}/CINDEX {サーバBのホスト名}/

# cp -rp {サーバAのホスト名}/recovery/YYYY-MM-DD,hh:mm {サーバBのホスト名}/recovery/

2-b. サーバBの情報の修正(必要最低限のものだけ書きます。)

/var/opt/ignite/client/{サーバBのホスト名}/recovery/YYYY-MM-DD,hh:mm/archive_cfg

→15行目あたりのnfs_sourceがサーバAのイメージファイルを示しているか確認。

(たぶん修正の必要なし)

/var/opt/ignite/client/{サーバBのホスト名}/recovery/YYYY-MM-DD,hh:mm/system_cfg

→最終行付近のサーバ固有の情報を修正

2-c. サーバCのNFS設定変更

2-bで指摘したnfs_sourceがサーバBにもマウントできるように/etc/exportsを編集

デフォルトであれば/etc/exportsには以下のエントリがあるはず

/var/opt/ignite/recovery/archives/{サーバAのホスト名} -anon=2,access={サーバAのホスト名}

accessオプションにサーバBを追加/export

# exportfs -av

3. Ignite-UX configuration toolを再起動。

Advanced modeであれば「Basic」タブの「Configurations」にサーバAのアーカイブセット表示されるはずです。

私はこれで展開しています。

[rawsq]

追記:

ココが参考になるかと。

http://docs.hp.com/ja/B2355-90773/ch11s12.html

[法]

rawsqさん、ご意見ありがとうございます。

お教え頂いた手順と私の考えていた手順の両方を作業時に確認したいと

思います。

手順・結果は追って報告させてもらいます。

[法]

おはようございます。

ひとつ確認させてください。

以前DATからのクローニングを実施したところ、instl_adm -dの結果が

バックアップを取得したサーバの情報になっていました。

おそらくクローニングを実施する際にネットワーク情報を変更せず、

後から変更したのではないか、と推測しています。

net_recoveryのデータからクローニングした場合はこのような事象は

ありませんでしょうか？

以上です。

[rawsq]

instl_adm -dはIgnite-UXサーバの場所を示すファイルだと認識しています。

クローニングには直接関係無いのでは?と思うのですが...

以下のケースについての質問でしょうか?

サーバAをバックアップ。

サーバBへクローニング。

サーバBをIgnite-UXサーバとして運用したい。

このときinstl_adm -dの結果はサーバAなのかどうか。

(サーバAの情報が残っていればサーバBをIgnite-UXサーバとして利用するには支障が

でるから。)

結果としてはinstl_adm -dの結果はサーバAのものだと思います。

(クローニングしてますので。)

つまりクローニング後サーバBをIgnite-UXサーバとして運用するにはinstl_admコマンド

によってサーバBの情報に書き換える必要があると思います。

書き換えないとサーバBからbootpにてブートはできたものの、ブートカーネルとあわせて

送られてきたIgnite-UXサーバの場所がサーバAとなっているためInstallのUI起動に

サーバAを参照しようとするでしょう。

(サーバAとも通信できればブートはできますが、意図したものではないですよね。)

以上のような回答でよろしいでしょうか。

[法]

rawsqさん、ご意見ありがとうございます。

なるほど、勘違いしていました。

ご指摘ありがとうございました。

[法]

結果報告です。

rawsqさんから教えて頂いた手順で大体が出来ました。

ただ、nfsの設定部分でサーバ指定を指定すると読み込めず、

/etc/exportsのaccess部分は削除することでインストール

出来ました。

また、時刻についてですが、一度日本を指定しなおさないと

時刻だけグリニッジになるようです。

（地域は日本が表示されましたが、時刻のみグリニッジでした）

以上です。

ありがとうございました。