1.5.5 仮想サーバーから物理サーバーへ移行するには？

（2016年時点での内容をアーカイブとして掲載しているため、一部の掲載内容が最新情報とは異なる場合がありますので、ご了承ください。最新のIBM Cloudのアップデート情報はこちらを参照してください。）

概要
<注意> フレックス・イメージのサービスは、2017年8月7日にサービス提供終了となりました。

仮想サーバーは、1時間から安価に使える大変便利なものです。 この仮想サーバーを利用したビジネスが成長して利用者が増えることで、処理性能が必要になると物理サーバーへ移行した方が、サーバー基盤運営に関わるコストを抑えることができることがあります。 ここでは仮想サーバーから物理サーバーへ簡単に移行する方法についてご紹介します。

仮想サーバーと物理サーバー比較
次のグラフは、同一ハードウェアで、仮想環境のない状態とXenの仮想サーバーで、同一CPUコア数でベンチマーク・プログラム UnixBenchを実行、比較した結果です。 判りやすくするために、物理サーバーの性能値を1となるように相対値にしたものです。

倍精度浮動小数点型計算 (Double-Precision Whetshtone)と整数型計算(Dhrysone 2 using register variables)の二つのベンチマークでは、CPUのレジスタを中心に実行するため、差がでません。 しかし、OSのシステムコール、プロセス間通信、ファイルコピー、プロセス生成などに関する処理速度は、4割に満たない性能値となっています。 この結果は、一つの検証結果であり、仮想サーバーと物理サーバーの傾向全体を代表するもではありませんが、仮想化のオーバーヘッドにより、特にOSのシステム・コールや、ディスクへの入出力が多いものは、性能劣化が著しいことが理解できます。 これらの結果から、物理サーバーを利用すれば、CPUコア数やサーバー数を減らし、さらに高い性能を得ることができる見込みをたてることができます。

一方で、サーバー統合というテーマがあります。 稼働から4〜5年が経過して、古くなった物理サーバーを、新しい性能の高いハードウェア上の仮想サーバーに移行することで、増えすぎた物理サーバーを減らし、運用コストを削減するというものです。 この場合は、ハードウェアの性能が年々向上し、活かしきれないハードウェアの高い性能に、仮想化環境を載せて、ハードウェアを有効に利用するものです。 この場合でも、当然仮想化のオーバーヘッドは存在していますが、それ以上にハードウェア性能が向上しているため、あまりクローズアップされてきませんでした。

仮想サーバーの条件
仮想サーバーから物理サーバーへの移行方法は、仮想サーバーのシステム・バックアップをフレックス・イメージとして取得して、物理サーバーへリストアするものです。 したがって、フレックス・イメージが取得できるOSでなければなりません。 そして、フレックス・イメージは、RHEL、CentOS、Windows Server系OSに対応しています。 仮想サーバーは、これらのOSである必要があります。

一方で、フレックス・イメージが使えないOSであっても、サーバー設定ツールのChefやPuppetを使って構築された環境であれば、容易に仮想サーバーから物理サーバーへ移行が可能です。

物理サーバーのディスク条件
次のグラフは、仮想サーバーのSANディスクは、物理サーバーのシングル・ドライブのSATA,SASよりも性能が高いことを表しています。 もし仮想サーバーのディスクのI/Oウェイト時間が多く、このボトルネックの解消を狙って物理サーバーへの移行を考えたとします。 もし物理サーバーのSATAディスクを使った構成に変更したら、性能が低くなり、逆効果となることを、このグラフは暗示しています。 このグラフによれば、物理サーバーのSATAディスクのランダムリードの性能は、仮想サーバーのSANディスクの約15分の1程度であるからです。 そこで、物理サーバーの性能を生かしていく上で、SSDの選択が有効であることも、このグラフから読み取ることができます。

仮想サーバーからフレックス・イメージを取得
<注意> フレックス・イメージのサービスは、2017年8月7日にサービス提供終了となりました。
仮想サーバーから物理サーバーへ移行するには、メニューを次の順で進み「Create Flex Image」を表示します。
「Devices」 -> 「Device List」 -> 「Device Name」-> 「Actions」 -> 「Create Flex Image」

次の画面のように、「Image Name」をインプットして、フレックス・イメージを取得します。

ここで、もしも、セキュリティ対策として、SSHのパスワード認証が禁止されていると以下のようなエラーが発生します。

対策として、sshdの設定ファイル /etc/ssh/sshd_configの中で、PasswordAuthentication を yesにします。

To disable tunneled clear text passwords, change to no here!

PermitEmptyPasswords no

PasswordAuthentication yes

フレックス・イメージから既存の物理サーバへリストアする方法
フレックス・イメージを既存の物理サーバーへリストアする場合、次の順で進み「Load From Image」を表示します。
「Devices」 -> 「Device List」 -> 「Device Name」-> 「Actions」 -> 「Load from Flex Image」

目的のフレックス・イメージファイルを選択して、「Load Selected Image」をクリックします。

次のレビュー画面が表示されます。リストア対象のディスクが上書きされても良ければ「Next」をクリックします。

さらに、もう一度、確認画面が表示されます。「Device Name」、「Device Type」を確認して間違えなければ、「Confirm OS Reload」をクリックして、リストアを開始します。

これで物理サーバーに対してリストアが開始されます。

物理サーバーを注文してリストアする方法
新規の物理サーバーにリストアする場合は、以下の順で進み、物理サーバーを注文します。
「Devices」->「Manage」->「Images」-> 利用したいフレックス・イメージ行の「Action」-> 「Order Bare Metal Server」
これより先は、1.3 物理サーバーを起動するには？と同じですので、省略します。

注意事項
IPアドレスは、既存の物理サーバーへフレックス・イメージをリストアした場合、フレックス・イメージ取得元の仮想サーバーのIPアドレスが引き継がれず、既存の物理サーバーのIPアドレスに置き換えられます。このため、SSHでログインする際に、以下のエラーメッセージが表示されることがあります。 この場合、メッセージに示されるknown_hostsファイルの該当行を削除するなどの対応が必要になります。

imac:~ maho$ ssh 10.52.21.69 -i key/identity -l root
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
d5:e6:9faa:b7:24ab:75:46:2a:0e:b297.
Please contact your system administrator.
Add correct host key in /Users/maho/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/maho/.ssh/known_hosts:13
RSA host key for 10.52.21.69 has changed and you have requested strict checking.
Host key verification failed.

新規に物理サーバーを注文してリストアした場合でも、同様に元の仮想サーバーのIPアドレスが引き継がれません。 このため、移行対象サーバーを参照する側のIPアドレスを変更するか、SoftLayerのDNSサービスを参照するようにして手間を省くなどの対応が必要です。

仮想サーバーのCPUコア数を追加する場合と物理サーバーへ移行した場合の性能差
MySQLのOLTP性能を例にして、仮想サーバーのコア数を増やしていった場合と、物理サーバーへ移行した場合の比較結果が次のグラフになります。 この検証結果では、一切チューニングなしの同じ条件で、環境だけを変更してOLTP性能を比較しました。 仮想サーバーでは、CPUコア数を4コア以上に増やしても性能向上が見られないのに対して、物理サーバーへ移行した場合は、約3.7倍に性能が向上しました。 このグラフでは、仮想サーバーでは得られない性能値に一息に到達したことを表しています。 これらの結果から、仮想サーバー上でのチューニングなどの作業を省いて、物理サーバーへ移行することの価値を理解頂けるものと思います。

これに用いたOTLP測定のベンチマーク・プログラムは、sysbenchで、比較に利用したコマンドのオプションは次になります。

sysbench
--test=oltp
--oltp-read-only=off
--db-driver=mysql
--mysql-user=root
--mysql-socket=/var/lib/mysql/mysql.sock
--oltp-table-size=1000000
--num-threads=4
--max-requests=0
--max-time=60
run

仮想サーバーから物理サーバーへ移行のご紹介は以上です。