WebRelease サーバの移行手順

STEP 1. 新サーバの構築

まず、新サーバを準備します。新サーバに OS (この例では Cent OS 6.4) をインストールし、必要な設定を行ってください。

• OS を最新版にアップデートしてください。(yum update)
• DNS
• Router
• Firewall (iptables)
• その他

このドキュメント中では、説明のために、新サーバのホスト名は newserver.example.com としておきます。

STEP 2. 新サーバへの WebRelease のインストール

新サーバに WebRelease をインストールしてください。

インストールにあたっては、最新版のインストールメディアをご購入いただき、それを使ってインストールしていただくのがよいでしょう。インストールメディアの購入方法につきましては下記リンクを参照してください。

もちろん、新規にメディアをお求めいただく事なく、お手元にお持ちのインストールメディアを使って WebRelease をインストールしていただいても構いません。その場合、インストール後に WebRelease を最新版にアップグレードしてください。なお、古いバージョンのインストールメディアでは、最新の OS へのインストールができない場合がありますのでご注意ください。

WebRelease のインストールはインストールマニュアルに沿って行ってください。

インストールが完了したら、WebRelease が新サーバ上で正常に動作しているかどうか確認しておきましょう。OS 再起動後に WebRelease が正常に自動起動することなどもチェックしておくと安心です。

STEP 3. メモリ割り当て量の設定

新サーバ上の WebRelease のメモリ割り当て量を設定します。設定は WebRelease の管理画面から行ないます。この値には、基本的に、旧サーバで指定していた値以上の値を指定してください。

メモリ割り当て量の設定方法はインストールマニュアルに記載されていますので、それを参考に作業してください。

STEP 4. 新サーバ上の WebRelease をいったん止める

旧サーバから新サーバへのデータの移行作業は WebRelease を止めた状態で行なう必要があります。データの移行を行うにあたり、新サーバ上の WebRelease をいったん止めます。

WebRelease は下記のコマンドで停止することができます。コマンドは root (権限) で実行してください。

# cd /etc/init.d
# ./webrelease2 stop

上記の停止コマンドを実行したら、一応、ブラウザから新サーバ上の WebRelease にアクセスし WebRelease が止まっていることを確認しておいてください。

STEP 5. 旧サーバのストレージデータを新サーバにコピーする

次は、旧サーバ上にある WebRelease のストレージデータを新サーバにコピーします。作業手順は下記のとおりです。各コマンドは root （権限）で実行してください。

# cd /etc/init.d
# ./webrelease2 stop

# cd ~wr2
# tar cvzf - ./WebRelease2.storage > WebRelease2.storage.tgz

# cd ~wr2
# du -s -m ./WebRelease2.storage

# cd ~wr2
# sftp someone@newserver.example.com
someone@newserver.example.com's password: (パスワードを与えます)
sftp> put WebRelease2.storage.tgz

STEP 6. 新サーバ上にコピーされたストレージデータを解凍する

新サーバ上にコピーされた WebRelease2.storage.tgz を WebRelease が使えるように解凍します。

# cd /etc/init.d
# ./webrelease2 stop

# su - wr2
wr2% 

wr2% cd
wr2% /bin/rm -fr ./WebRelease2.storage

wr2% cd
wr2% tar xvpzf ~someone/WebRelease2.storage.tgz

wr2% ls -l
合計 53400
drwxr-xr-x  6 wr2  wr2      4096  2月 10 11:03 ThirdPartyProducts
drwxr-xr-x  3 wr2  wr2      4096  2月 10 11:03 WebRelease2
-rw-r--r--  1 wr2  wr2       630  2月 10 12:10 WebRelease2.log
drwxr-xr-x 27 wr2  wr2      4096  2月 10 11:39 WebRelease2.storage

STEP 7. 新サーバ上の WebRelease を起動する

下記コマンドで、新サーバ上で WebRelease を起動します。

# cd /etc/init.d
# ./webrelease2 start

これで、新サーバ上で WebRelease が稼働開始しました。ブラウザで新サーバ上の WebRelease にアクセスし、稼働しているかどうか確認してください。

正しく移行できているかどうか、下記の点について確認しておくとよいでしょう。

• 全サイトが移行されていること。
• 移行前後で、各サイトのページ数が一致していること。
• 移行前後で、ユーザ登録情報が一致していること。

今回の手順では WebRelease2.storage をそのまま移行しているので、登録ユーザ情報もすべて旧サーバのものが移行されています。admin のパスワードも旧サーバから移行されたものとなっています。

STEP 8. 後片付け

移行作業が順調に終わり、新サーバでの稼働が軌道に乗ったならば、下記の作業ファイルを削除してしまいましょう。

• 新サーバ上の ~someone/WebRelease2.storage.tgz
• 旧サーバ上の ~wr2/WebRelease2.storage.tgz

なお、移行時点のデータをしばらく保全しておきたいということであれば、上記のいずれか一方（または両方）を、当面消さずに保存するか、または、他のサーバにコピーするなどして保存してください。

その他

下記の点にご注意ください。

• 作業開始に先立って、旧サーバ上の WebRelease2.storage のバックアップを確保しておいてください。移行作業中の停電やオペレーションミスなど、思わぬ事故でデータを破壊してしまう危険があります。必ずバックアップを別サーバまたはオフラインメディアに確保してから作業してください。

• Solaris の場合には tar コマンドではなく gtar (GNU tar) を使う必要があるかもしれません。Solaris 上にインストールされている tar コマンドが長いパス名を扱えるものでない場合には、tar cvzf が期待どおりの tar ファイルを生成してくれません。gtar を使う以外にも tar コマンドの -E などのオプションで問題を回避できる場合もあるようです。詳しくは Solaris のマニュアルを参照してください。

• 新サーバの設置されるネットワーク環境が旧サーバと異なる場合、新サーバ稼働後に、新サーバ側の WebRelease に対していくつかの設定変更が必要になる場合があります。

  • 新サーバのネットワーク環境では、公開サーバにコンテンツを配信するための ftp / sftp サーバが異なる場合、それらの設定情報を変更する必要があります。
  • 新サーバのネットワーク環境では、旧サーバとは異なる SMTP サーバを使う必要がある場合、WebRelease の「メールサーバ」の設定変更が必要です。
  • 新サーバのネットワーク環境では、旧サーバとは異なる proxy サーバを使う必要がある場合、WebRelease の「Proxy サーバ」の設定変更が必要です。

• 秘密鍵を移行する必要があるかもしれません。WebRelease から公開サーバへのコンテンツのアップロードに sftp を使用していて、かつ、認証に公開鍵認証を使用している場合、旧サーバの ~wr2/.ssh 以下の ssh 鍵ファイル類を新サーバに移行するか、または、新サーバ上で新たな鍵ペアを生成しなおして、sftp サーバ上の公開鍵を新しいものに交換しておく必要があるでしょう。

• データの移行完了後、新サーバ上で WebRelease が稼働し始めると、各種通知メール類はすぐに発送され得る状態になります。例えば、承認遅延警告メールは、その条件が成立すると、新サーバから発送されます。何らかの理由で、旧サーバと新サーバを並行稼働させている場合には、同じ内容のメールが両方のサーバから発送される事態にいたる可能性がありますのでご注意ください。そのような事態を回避したい場合には、移行前 (上記のステップ 5 の (1) 実行前) に、旧サーバ上で WebRelease の「メールサーバ」の設定をクリアし、メールが発送されない状態にしておくとよいでしょう。「メールサーバ」の設定がクリアされている状態のデータを移行し、新サーバ側で一定の動作確認が終わった時点で、新サーバ側で「メールサーバ」設定をあらためて行えば混乱を避けられるでしょう。