iSCSI 上に仮想イメージを導入し、ついでに Live Migration してみる。

　iSCSI は FC より遅いので、仮想化には不向きともいわれます。そうは言っても 1Gbps のネットワークであれば、ほぼ SAS-RAID 程度までならパフォーマンスは十分です。そもそもディスクのＩＯが付いてこれません。ネットワークの帯域よりも iSCSI のデバイスそのものの方がパフォーマンスには影響してしまうのです。

　ついでに、iSCSI でハイパーバイザーから共有して、ライブマイグレーションに挑戦してみます。

　今回使うのは qnap の TS110, もう５年前の機種にも関わらず、ファームウェアのアップデートがありました。その都度Ｉ／Ｆが変わったり、機能が変わったりしています。進化を止めない qnap , 今のところお勧めです。かなり古い装置なので、速度はマッタリです。


　Ｑｎａｐ　に iSCSI の機能を組み込みます。今回はパスワードは設定しませんが、誤接続を防ぐためにも IP-SAN 内部にパスワードを設定しておくと良いでしょう。

　今回は仮想化ハイパーバイザーはSUSE 標準の XENです。 Domain0 が動作する SLES11sp3 上から yast でiSCSI Initialtor を作成します。
yast > NetWork Service > iSCSI initiator


　もし、iSCSI がインストールされていない場合、SUSE では自動的にリポジトリからインストールされます。

　デフォルトは ”manual” です。そのままでも構いませんが、実運用するには "When Booting"　などに変更しておくと良いでしょう。


　iSCSI ターゲットのアドレスor DNS 名をセットします。


　iSCSI ターゲットに接続するとターゲットの中で iSCSI デバイスとして作成済みの仮想ストレージが出てきます。まだ接続しただけなので　False と表示されていますが、 Login ボタンで True になります。


　SUSE の場合、これで iSCSI の設定が終わりです。実にあっけない。


　次に接続したiSCSI デバイスをフォーマットしてします。最初に Mount Point として　/iscsi ディレクトリをを作りました。
　別に /var/lib/xen 全体をマウントしても構わないのですが、それでは仮想サーバー全部が iSCSI に作られてしまいます。本格的な運用であれば、それで構いませんが、今回はテストです。

　yast > System > Partitioner を起動します。


　「エキスパート専用ツールだよ、操作には十分注意してね」

　というダイアログはYes。パーティション全体の状態が表示されます。


　/dev/sdf に iSCSI デバイスが認識されています。

　/dev/sdf を選び Add します。

　実はこのパーティションは一度 ext3 で使った後なので、実際には Edit から操作しました。

　このパーティションをフォーマットするので Format にチェック、形式は ext3, マウントポイントは /iscsi とします。


　最後に確認のダイアログ


　これでSUSE では iSCSI のフォーマットしてマウントが完了します。fstab にも自動的に書き込まれます。
試してみましょう。


　それでは、この iSCSI のデバイスに仮想サーバーイメージを作成してみます。

　yast > Virt-Manager を使い、サーバーをインストールします。ここでは XEN ですが、 KVM でも同じ手順です。仮想イメージを置く場所は "New" で /iscsi/images/my-vm とし、myvm.disk0.raw を仮想サーバーのディスクファイル名として指定します。


　インストール中の状態を zabbix で監視すると、ローカル ISO イメージから読み込んだインストールファイルをiSCSI-ＮＡＳが一生懸命読んでいるのがわかります。６０～７０Mbps なので 100Mbps の通信回線でもそれほど遅いとは思わないかもしれません。勿論 Gbit HUB + SSD-NAS などならもう少し帯域を使うと思います。


　感覚的には、ローカルＨＤＤに導入するのと同じ程度、と言ったところです。

-仮想マシンを共有-

　同様に異なるハイパーバイザーで iscsi の設定を行います。
　
　iSCSI の設定が終わったら、iSCSI パーティションをマウントします。 yast > System > Partition Manager より、iSCSI デバイスがデバイスとして認識されていることを確認し


　マウントします。


　マウントされています。



リポジトリの修正

　インストールはＤＶＤイメージから実施したので、仮想マシン上のＩＳＯのリポジトリは削除します。

　yast > Software > Software Repositories より、 ISO ファイルのリポジトリを選んで "Delete"します。アクティベーションした後のリポジトリは残しておきましょう。また、ISO ファイルの代わりに内部ネットワークのソフトウェア配布用のサーバーを Add しておきます。



ＶＭファイルの書き換え

　XEN の場合、インストールに使ったイメージ ISO ファイルの記述を削除しておく必要があります。

これが残っていると DomU を起動するときに「そんな仮想ディスクはない」と怒られます。

　iSCSI 上に作られたイメージファイルのパスは同じパスが推奨です。


　この仮想マシンの設定ファイルを共有する相手側の Domain-0 の /etc/xen/vm に scp などでコピーします。

-まずは手動で-

　まず、今動いている仮想マシンをシャットダウンして、共有する相手の Domain-0 で dom-u を起動して正しく動作するか確認しました。

うまく行ったようです。

-Live Migration-

Live Migration はポート 8002 を利用します。Telnet で

# telnet target 8002

を実行すると

結果論ですが、こんな感じでポートが開いていればＯＫです。なお Telnet は標準パッケージには入っていませんし、最近の Windows にも付属していないようです。SUSE では Yast > Software Management から telnet を Serach してインストールしましす。

さて、デフォルトでは 8002 ポートは開いていません。Live Migration を有効にするには幾つかの設定が必要です。次のドキュメントを参考にします。

SUSE Linux Enterprise Server 11 SP3 Virtualization with Xen

に /etc/xen/xend-config.sxp を書き換える必要があるようなので

5.6.1. Configuring Xend for Migrations¶

To prepare a VM Host Server system for migrating, edit the configuration file /etc/xen/xend-config.sxp. Search for the following lines:
#(xend-relocation-server no)
#(xend-relocation-port 8002)
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')


Change the lines to match the following strings:
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$ \
^')


These changes must be done on all VM Host Server systems that should participate in migrating guests.

という記述がありましたが、これではうまく行かず、フォーラムを探したところ

Unable to migrate a domain

(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address ")
(xend-relocation-hosts-allow ")

　と変更するのが正解なようです。この状態で xend をリスタートさせます。ちなみに xend をリスタートさせても、稼働中の dom-u には影響はありませんでした。

　さていよいよ Live Migration をやってみます。
　
　# xm migrate --live MyVM MoveToHV-IPaddress



　無事 Live Migration に成功しました。

　メモリのサイズにもよりますが、稼働中の仮想マシンメモリの一部を相手に送るため、一瞬ネットワークに負荷がかかります。２～３秒後にはライブマイグレーションが完了します。

-終わりに-

　iSCSI でハイパーバイザー自体を SAN ブート、あるいはＵＳＢブートできれば、ＣＰＵ自体はディスクレスとなるので、熱処理、排熱、電源負荷などでのメリットは大きいでしょう。その上で仮想ＣＰＵ自体のディスクイメージも iSCSI-SAN の上に置くことになります。ネットワークのトラフィックは十分検討する必要があります。
　しかし、中小規模のネットワークであれば「これでもいいのかな」という程度ですので、それほど負荷には気を遣わなくても構わないでしょう。大手ＳＩ事業者ではちょっとした仮想化でも FC-SAN が必要だ、とやたら高額な見積もりを出してくる場合があるので注意が必要です。

　ただし、構内ネットワークとＳＡＮ環境は別に構築するのが無難です。

しかし、ディスクドライブを単一の iSCSI-NAS に集約すると、ディザスタリカバリも併せて検討する必要があります。例えば、仮想イメージを別なＮＡＳに定期的にバックアップするとかです。

　また、アクセスの大きなファイルサーバーのようなシステムイメージを iSCSI 上に構築する場合、システムイメージと、データボリュームのデバイスは分けた方が良さそうです。

　そうなると、いよいよ問題となるのは HUB の選択ですね。ＨＵＢは ip-SAN 側にポート多め、あるいは NetGear で出している 10Gbit HUB などが選択できます。ただ、あまり 10GbT のＨＵＢが中々普及していないので困ります。

　Live Migration は本来、オペレータが状況を認識した上で実施するもので、自動的に切り替わるなどの器用な機能はありません。もっとも中小規模向けのシステムでも、仮想マシンを好きに他のハイパーバイザーＣＰＵ装置に移行できるのは大きなメリットがあります。

　ただ、それだけの事のために Live Migration って必要か、という疑問もあるし、実際、シンプルな構成であれば、あまり障害も起こりにくくなるので、あまり提案したいと思える機能ではありません。

　個人的な意見になりますが、iSCSI は仮想システムにつなげる外部ディスクとして考えるのが一番シンプルだと思います。何しろ SCSI HBA がいらないわけですから、手軽です。

お問い合わせは
islandcenter.jp

-Key Word-
SUSE XEN iSCSI Live Migration