序章


データと運用要件をあるサーバーから別のサーバーに移動しなければならないシナリオはたくさんあります。 ソリューションを新しいデータセンターに実装するか、より大きなマシンにアップグレードするか、新しいハードウェアまたは新しいVPSプロバイダーに移行する必要がある場合があります。

理由が何であれ、あるシステムから別のシステムに移行する際には、さまざまな考慮事項を考慮する必要があります。 Chef、Puppet、Ansibleなどの構成管理ソリューションを使用していない場合、機能的に同等の構成を取得するのは難しい場合があります。 データを転送するだけでなく、新しいマシンでも同じように動作するようにサービスを構成する必要があります。

このガイドでは、移行のためにソースシステムとターゲットシステムを準備する方法について説明します。 これには、2台のマシンがSSHキーと通信できるようにすることと、転送する必要のあるコンポーネントについて徹底的に調査することが含まれます。 実際の移行については、次の記事で説明します。

バックアップを作成する


破壊的な可能性のある手順を実行するときに実行する最初の手順は、新しいバックアップを作成することです。 問題がないはずだからといって、思いがけないことが起こらないというわけではありません。 交換が稼働する前に、コマンドが現在の実稼働マシンで何かを壊すような状況に置かれたくないでしょう。

サーバーをバックアップするには、さまざまな方法があります。 選択は、シナリオに適したオプションと最も快適なオプションによって異なります。

物理ハードウェアとバックアップ用のスペース(ディスクドライブ、USBなど)にアクセスできる場合は、利用可能な多くのイメージバックアップソリューションのいずれかを使用してディスクのクローンを作成できます。 VPSマシンを扱う場合の機能的な同等物は、コントロールパネルインターフェイス内からスナップショットまたはイメージを取得することです。

他のオプションは、多くの場合、データと、おそらくサービスに関する情報の一部を保持します。 それはすべて、実装したいバックアップメカニズムによって異なります。 私たちのコミュニティページには、さまざまなバックアップオプションに関する記事があります。 データとシステムに適したものを選択してください。

バックアップが完了すると、続行する準備が整います。 このガイドの残りの部分では、rootとして両方のシステムにログインしていると想定します。

ソースシステムに関する情報を収集する


移行を開始する前に、ソースシステムと一致するようにターゲットシステムをセットアップするための最初の手順を実行する必要があります。

現在のサーバーと移行先のサーバーをできるだけ一致させたいと思います。 移行をスムーズに進めたい場合は、これを最新バージョンにアップグレードしたり、新しいことを試したりする機会としてとらえるべきではありません。 変更を加えると、不安定になり、問題が発生する可能性があります。

新しいマシン用に作成するサーバーシステムを決定するのに役立つ基本情報のほとんどは、単純なunameコマンドで取得できます。

uname -r

3.2.0-24-virtual

これは、現在のシステムが実行しているカーネルのバージョンです。 物事をスムーズに進めるために、ターゲットシステムでそれを一致させることを試みることは常に良い考えです。

uname -m

i686

これがシステムアーキテクチャです。 i686は、これが32ビットシステムであることを示します。 返された文字列がx86_64の場合、これは64ビットシステムであることを意味します。

また、ソースサーバーのディストリビューションとバージョンを一致させるようにしてください。 ソースマシンにインストールしたディストリビューションのバージョンがわからない場合は、次のように入力して確認できます。

cat /etc/issue

Ubuntu 12.04.2 LTS \n \l

可能であれば、これらの同じパラメーターを使用して新しいサーバーを作成する必要があります。 この場合、32ビットのUbuntu12.04システムを作成します。 可能であれば、新しいシステムのカーネルバージョンとの一致も試みます。

ソースサーバーとターゲットサーバー間のSSHキーアクセスを設定する


サーバーがファイルを転送できるように、サーバーが通信できるようにする必要があります。 これを行う最も簡単な方法は、SSHキーを使用することです。 ここでLinuxサーバーでSSHキーを構成する方法を学ぶことができます。

ターゲットサーバーに新しいキーを作成して、ソースサーバーのauthorized_keysファイルに追加できるようにします。 移行が完了したときに、新しいサーバーのauthorized_keysファイルに漂遊キーがないため、これは他の方法よりもクリーンです。

まず、宛先マシンで、次のように入力して、rootユーザーがSSHキーを持っていないことを確認します(rootとしてログインする必要があります)。

ls ~/.ssh

authorized_keys

id_rsa.pubおよびid_rsaというファイルが表示されている場合は、すでにキーがあり、転送するだけで済みます。

これらのファイルが表示されない場合は、次のように入力して新しいキーペアを作成します。

ssh-keygen -t rsa

すべてのプロンプトで「Enter」を押して、デフォルトを受け入れます。

次に、次のように入力して、キーをソースサーバーに転送します。

cat ~/.ssh/id_rsa.pub | ssh other_server_ip "cat >> ~/.ssh/authorized_keys"

これで、次のように入力して、ターゲットシステムからソースサーバーに自由にSSH接続できるようになります。

ssh other_server_ip

これを正しく構成した場合、パスワードの入力を求められることはありません。

要件のリストを作成する


これは実際には、システムと要件の詳細な分析を行う最初の部分です。

操作の過程で、ソフトウェア要件が変更される可能性があります。 古いサーバーには、ある時点で必要だったものの、置き換えられたサービスやソフトウェアが含まれている場合があります。

不要なサービスを無効にし、完全に不要な場合はアンインストールする必要がありますが、これが常に発生するとは限りません。 ソースサーバーで使用されているサービスを検出してから、それらのサービスを新しいサーバーに存在させる必要があるかどうかを判断する必要があります。

サービスとランレベルを検出する方法は、サーバーが採用している「init」システムのタイプに大きく依存します。 initシステムは、ユーザーのコマンドで、または自動的に、サービスを開始および停止する責任があります。

SystemVサーバーでのサービスとランレベルの検出


System Vは、現在も多くのサーバーで使用されている古いinitシステムの1つです。 UbuntuはUpstartinitシステムへの切り替えを試みており、将来的にはSystemdinitシステムに移行する可能性があります。

現在、System Vスタイルのinitファイルと新しいUpstartinitファイルの両方が同じシステム上にあります。つまり、より多くの場所を探すことができます。 他のシステムもSystemVを使用します。 次のように入力すると、サーバーがSystemVを使用しているかどうかを確認できます。

which service

/usr/sbin/service

上記のように、コマンドがシステムパスを返す場合は、システムにSystemVがあります。

次のように入力すると、現在実行されているサービスを確認できます。

service --status-all

 [ ? ]  acpid
 [ ? ]  anacron
 [ + ]  apache2
 [ ? ]  atd
 [ - ]  bootlogd
 [ ? ]  console-setup
 [ ? ]  cron
 [ ? ]  cryptdisks
 . . .

これにより、System-Vinitシステムが認識しているすべてのサービスが一覧表示されます。 「+」はサービスが開始されたことを意味し、「-」はサービスが停止されたことを意味し、「?」はサービスが停止されたことを意味します。 System-Vがサービスの状態を知らないことを意味します。

System-Vがサービスの状態を知らない場合は、代替のinitシステムによって制御されている可能性があります。 Ubuntuシステムでは、これは通常Upstartです。

現在実行されているサービスを把握する以外に、サービスがアクティブになっているランレベルについても知っておくとよい情報があります。 ランレベルは、サーバーがさまざまな状態にあるときにどのサービスを利用可能にするかを指示します。 新しいシステムでソースサーバーの構成を一致させることをお勧めします。

いくつかのツールを使用して、各サービスがアクティブになるランレベルを見つけることができます。 1つの方法は、chkconfigsysv-rc-confなどのツールを使用することです。

UbuntuまたはDebianシステムでは、chkconfigをインストールして使用し、このようなさまざまなランレベルで利用できるSystemVサービスを確認できます。 ほとんどのRHELベースのシステムには、このソフトウェアがすでにインストールされているはずです。

apt-get update
apt-get install chkconfig
chkconfig --list

acpid                     0:off  1:off  2:off  3:off  4:off  5:off  6:off
anacron                   0:off  1:off  2:off  3:off  4:off  5:off  6:off
apache2                   0:off  1:off  2:on   3:on   4:on   5:on   6:off
atd                       0:off  1:off  2:off  3:off  4:off  5:off  6:off
bootlogd                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
console-setup             0:off  1:off  2:off  3:off  4:off  5:off  6:off
cron                      0:off  1:off  2:off  3:off  4:off  5:off  6:off
cryptdisks                0:on   1:off  2:off  3:off  4:off  5:off  6:off
cryptdisks-early          0:on   1:off  2:off  3:off  4:off  5:off  6:off
. . .

もう1つの方法は、sysv-rc-confです。これは、次のようにインストールして実行できます。

apt-get update
apt-get install sysv-rc-conf
sysv-rc-conf --list

acpid       
anacron     
apache2      0:off	1:off	2:on	3:on	4:on	5:on	6:off
atd         
bootlogd    
console-setu
cron        
cryptdisks   0:on	6:on
cryptdisks-e 0:on	6:on
. . .

ツールを使用する代わりに手動でチェックしたい場合は、/etc/rc*.d/の形式をとるいくつかのディレクトリをチェックすることでそれを行うことができます。 アスタリスクは、ランレベルの番号に置き換えられます。

たとえば、ランレベル2でSystem Vによってアクティブ化されているサービスを確認するには、次のファイルを確認します。

cd /etc/rc2.d
ls -l

total 4
-rw-r--r-- 1 root root 677 Jul 26  2012 README
lrwxrwxrwx 1 root root  18 Dec 28  2012 S20php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx 1 root root  15 Apr 26  2012 S50rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root  14 Jun 21  2013 S75sudo -> ../init.d/sudo
lrwxrwxrwx 1 root root  17 Dec 28  2012 S91apache2 -> ../init.d/apache2
. . .

これらは、/etc/init.d/にある構成ファイルへのリンクです。 「S」で始まる各リンクは、サービスを開始するために使用されることを意味します。 「K」で始まるスクリプトは、そのランレベルでサービスを強制終了します。

アップスタートサーバーでのサービスとランレベルの検出


UbuntuとUbuntuベースのサーバーは、デフォルトでUpstartinitシステムを実装するほとんど唯一のサーバーです。 これらは通常、メインのinitシステムとして使用され、SystemVはレガシーサービス用に構成されています。

サーバーにUpstartinitシステムがあるかどうかを確認するには、次のように入力します。

which initctl

/sbin/initctl

上記のように実行可能ファイルへのパスを受け取った場合、サーバーにはUpstart機能があり、Upstartによって制御されているサービスを調査する必要があります。

次のように入力すると、Upstartによって開始されたサービスを確認できます。

initctl list

mountall-net stop/waiting
passwd stop/waiting
rc stop/waiting
rsyslog start/running, process 482
tty4 start/running, process 728
udev start/running, process 354
upstart-udev-bridge start/running, process 350
ureadahead-other stop/waiting
. . .

これにより、すべてのUpstartマネージドサービスの現在の状態がわかります。 現在実行されているサービスを確認し、使用されなくなったレガシーサービスを引き継いだのと同じ機能を提供するサービスがあるかどうかを確認できます。

繰り返しになりますが、各ランレベルで利用できるはずのサービスについて理解しておく必要があります。

これを行うには、initctlコマンドで次のように入力します。

initctl show-config

mountall-net
  start on net-device-up
passwd
  start on filesystem
rc
  emits deconfiguring-networking
  emits unmounted-remote-filesystems
  start on runlevel [0123456]
  stop on runlevel [!$RUNLEVEL]
rsyslog
  start on filesystem
  stop on runlevel [06]
  . . .

これにより、各サービスの多くの構成情報が吐き出されます。 探すべき部分はランレベルの仕様です。

この情報を手動で収集したい場合は、/etc/initディレクトリにあるファイルを確認できます(ここで「init」の後の「.d」が省略されていることに注意してください)。

中には、いくつかの構成ファイルがあります。 これらのファイル内には、次のようなランレベルの仕様があります。

start on runlevel [2345]
stop on runlevel [!2345]

Upstartサービスとランレベルを検出するさまざまな方法についての良いアイデアが必要です。

Systemdサーバーでのサービスとランレベルの検出


ディストリビューションでますます採用されている新しいinitスタイルは、systemdinitシステムです。

Systemdは、他のタイプのinitシステムとはかなり異なりますが、非常に強力です。 次のように入力すると、サービスの実行について知ることができます。

systemctl list-units -t service

UNIT                                           LOAD   ACTIVE SUB     DESCRIPTION
atd.service                                    loaded active running ATD daemon
avahi-daemon.service                           loaded active running Avahi mDNS/DNS-SD Stack
colord.service                                 loaded active running Manage, Install and Generate Color Profiles
cups.service                                   loaded active running CUPS Printing Service
dbus.service                                   loaded active running D-Bus System Message Bus
dcron.service                                  loaded active running Periodic Command Scheduler
dkms.service                                   loaded active exited  Dynamic Kernel Modules System
. . .

Systemdは、他のinitシステムのランレベルの概念を正確に複製していません。 代わりに、「ターゲット」の概念を実装します。 従来のinitシステムを使用するシステムは、一度に1つのランレベルにしか存在できませんが、systemdを使用するサーバーは、同時に複数のターゲットに到達できます。

このため、どのサービスがいつアクティブになるかを把握するのは少し難しくなります。

次のように入力すると、現在アクティブなターゲットを確認できます。

systemctl list-units -t target

UNIT                LOAD   ACTIVE SUB    DESCRIPTION
basic.target        loaded active active Basic System
cryptsetup.target   loaded active active Encrypted Volumes
getty.target        loaded active active Login Prompts
graphical.target    loaded active active Graphical Interface
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target     loaded active active Local File Systems
. . .

次のように入力すると、使用可能なすべてのターゲットを一覧表示できます。

systemctl list-unit-files -t target

UNIT FILE                 STATE   
basic.target              static  
bluetooth.target          static  
cryptsetup.target         static  
ctrl-alt-del.target       disabled
default.target            disabled
emergency.target          static  
final.target              static  
getty.target              static  
graphical.target          disabled
halt.target               disabled
. . .

ここから、どのサービスが各ターゲットに関連付けられているかを確認できます。 ターゲットは依存関係としてサービスまたは他のターゲットを持つことができるため、次のように入力することで、各ターゲットが実装するポリシーを確認できます。

systemctl list-dependencies target_name.target

たとえば、次のように入力します。

systemctl list-dependencies multi-user.target

multi-user.target
├─atd.service
├─avahi-daemon.service
├─cups.path
├─dbus.service
├─dcron.service
├─dkms.service
├─gpm.service
. . .

これにより、そのターゲットの依存関係ツリーが一覧表示され、そのターゲットに到達したときに開始されるサービスおよびその他のターゲットのリストが表示されます。

他の方法によるサービスのダブルチェック


ほとんどのサービスはinitシステムを介して構成されますが、プロセスまたはサービスが亀裂をすり抜けて独立して制御される領域が存在する可能性があります。

これらのサービスの副作用を調べることで、これらの他のサービスやプロセスを見つけることができます。 ほとんどの場合、サービスは相互に、または何らかの方法で外部エンティティと通信します。 サービスが通信できる方法は特定の数だけであり、それらのインターフェースをチェックすることは、他のサービスを見つけるための良い方法です。

プロセスが通信に使用しているネットワークポートとUnixソケットを検出するために使用できるツールの1つは、netstatです。 次のようなコマンドを発行して、一部のサービスの概要を取得できます。

netstat -nlp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      762/mysqld      
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      832/apache2     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      918/sshd        
tcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTEN      799/php-fpm.conf)
tcp6       0      0 :::22                   :::*                    LISTEN      918/sshd        
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name    Path
unix  2      [ ACC ]     STREAM     LISTENING     1526     1/init              @/com/ubuntu/upstart
unix  2      [ ACC ]     SEQPACKET  LISTENING     1598     354/udevd           /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     6982     480/dbus-daemon     /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     8378     762/mysqld          /var/run/mysqld/mysqld.sock
unix  2      [ ACC ]     STREAM     LISTENING     1987     746/acpid           /var/run/acpid.socket

最初のセクションのポート番号は、右端のプログラムに関連付けられています。 同様に、下部はプログラムによって使用されているUnixソケットに焦点を当てています。

ここに、initシステムを通じて情報がないサービスが表示された場合は、その理由と、そのサービスについて収集する必要のある情報の種類を把握する必要があります。

lsofコマンドを使用すると、サービスが利用可能にしているポートに関する同様の情報を取得できます。

lsof -nPi

COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mysqld    762    mysql   10u  IPv4   8377      0t0  TCP 127.0.0.1:3306 (LISTEN)
php5-fpm  799     root    6u  IPv4   8195      0t0  TCP 127.0.0.1:9000 (LISTEN)
php5-fpm  800 www-data    0u  IPv4   8195      0t0  TCP 127.0.0.1:9000 (LISTEN)
php5-fpm  801 www-data    0u  IPv4   8195      0t0  TCP 127.0.0.1:9000 (LISTEN)
php5-fpm  802 www-data    0u  IPv4   8195      0t0  TCP 127.0.0.1:9000 (LISTEN)
php5-fpm  803 www-data    0u  IPv4   8195      0t0  TCP 127.0.0.1:9000 (LISTEN)
apache2   832     root    3u  IPv4   8210      0t0  TCP *:80 (LISTEN)
sshd      918     root    3r  IPv4   7738      0t0  TCP *:22 (LISTEN)
. . .

ssコマンドから、どのプロセスがどのポートとソケットを使用しているかについて、いくつかの優れた情報を得ることができます。

ss -nlpaxtudw

Netid  State      Recv-Q Send-Q   Local Address:Port     Peer Address:Port 
u_str  LISTEN     0      0      @/com/ubuntu/upstart 1526                * 0     users:(("init",1,7))
u_str  ESTAB      0      0      @/com/ubuntu/upstart 1589                * 0     users:(("init",1,10))
u_str  ESTAB      0      0                    * 1694                * 0     users:(("dbus-daemon",480,6))
u_str  ESTAB      0      0                    * 1695                * 0     users:(("dbus-daemon",480,7))
u_str  ESTAB      0      0                    * 1803                * 0

パッケージバージョンの収集


そのすべての調査の後、ターゲットサーバーに実装する必要があるソースマシンで実行されているサービスについての良いアイデアが得られるはずです。

実装する必要があることがわかっているサービスのリストが必要です。 移行をスムーズに進めるためには、可能な限りバージョンを一致させることが重要です。

ソースシステムにインストールされているすべてのパッケージを調べて新しいシステムに複製することはできませんが、ニーズに重要なソフトウェアコンポーネントを確認し、バージョン番号を確認する必要があります。

-vまたは--versionフラグをコマンドに渡すことで、ソフトウェア自体からバージョン番号を取得しようとすることができますが、通常、これはパッケージマネージャーを使用して行う方が簡単です。 Ubuntu / Debianベースのシステムを使用している場合は、次のように入力することで、パッケージマネージャーからインストールされているパッケージのバージョンを確認できます。

dpkg -l | grep package_name

代わりにRHELベースのシステムを使用している場合は、このコマンドを使用して、代わりにインストールされているバージョンを確認できます。

rpm -qa | grep package_name

これにより、インストールしようとしているプログラムのバージョンがわかります。

インストールする重要なコンポーネントのバージョン番号のリストを保管してください。 ターゲットシステムでこれらの取得を試みます。

次のステップ


これで、ソースサーバー上のどのプロセスとサービスを新しいマシンに転送する必要があるかについての良いアイデアが得られたはずです。 また、2つのサーバーインスタンスが相互に通信できるようにするための準備手順を完了する必要があります。

これで、移行の基礎が完成しました。 これで、次の記事で、何をする必要があるかをよく理解して、移行に取り掛かることができるはずです。