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

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

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

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

a0056607_14285241.jpg

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

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


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

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


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


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


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


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

 yast > System > Partitioner を起動します。
a0056607_14572559.jpg


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

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


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

 /dev/sdf を選び Add します。
a0056607_1513140.jpg

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

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


 最後に確認のダイアログ
a0056607_154508.jpg


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


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

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


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


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

-仮想マシンを共有-

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


 マウントします。
a0056607_16352167.jpg


 マウントされています。
a0056607_16373259.jpg



リポジトリの修正

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

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

a0056607_16554188.jpg


VMファイルの書き換え

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

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

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


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

-まずは手動で-

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

うまく行ったようです。

-Live Migration-

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

# telnet target 8002

を実行すると
a0056607_9353232.jpg

結果論ですが、こんな感じでポートが開いていればOKです。なお 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

a0056607_9304312.jpg


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

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

-終わりに-

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

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

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

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

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

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

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

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

お問い合わせは
islandcenter.jp

-Key Word-
SUSE XEN iSCSI Live Migration

[PR]
トラックバックURL : https://islandcnt.exblog.jp/tb/19941486
トラックバックする(会員専用) [ヘルプ]
※このブログはトラックバック承認制を適用しています。 ブログの持ち主が承認するまでトラックバックは表示されません。
by islandcenter | 2014-06-30 07:09 | SUSE | Trackback | Comments(0)