WIDE Technical-Report in 2011

WIDE クラウド WG 2010 年度活動報告
wide-tr-cloud-report-2010-00.pdf

WIDE Project : http://www.wide.ad.jp/

If you have any comments on WIDE documents, please contact toboard@wide.ad.jp

Title:Author(s):Date:

WIDE クラウド WG 2010 年度活動報告
石橋 尚武, 岡本 慶大, 島 慶一, 関谷 勇司
2011-1-4

WIDE クラウド WG 2010 年度活動報告
石橋 尚武∗

岡本 慶大†島 慶一‡

関谷 勇司§

2011 年 1 月 4 日

はじめに

1

キテクチャを技術的にとらえることで、従来のサービ
スと何が異なり、何が技術的な問題点となるのかを探WIDE クラウドワーキンググループは、今後のクラウド技術の研究開発を推進するために 2010 年 1 月にり、クラウドに関する理解を深めるために開催された。

WIDE プロジェクトが主催するため、クラウドという言葉が意味する社会的な側面ではなく、技術的な観設立された。活動内容としては、複数の WIDE 組織間に渡って運用される広域連邦型クラウドシステムであ点から、その利点と欠点、ならびに運用上の問題点とる WIDE Cloud システムの運用と、それを用いた研改善すべき課題に関して、発表者から提言をしてもら究開発である。

い、それを議論する形式にて行われた。

今年度の主な活動を以下に列挙する。

技術課題の解決に関しては、WIDE プロジェクトが• クラウドアーキテクチャシンポジウム開催 (2 章)

今後果たすべき役割、ならびに標準化等の貢献に関し• 甲子園インターネット中継 (3 章)

まとめられた。

て、どのように進めていくべきかの議論を中心として
本シンポジウムは、WIDE プロジェクトのスポン• ライブマイグレーション性能評価 (4 章)

サー企業ならびに WIDE メンバーに対して参加の案• ネットワーク可搬性 (5、6 章)

内が送付され、当初予定通りの 50 名以上が参加する
盛況なシンポジウムとなった。

• NAT64 の実装と運用 (7 章)以降、それぞれの活動の詳細を各章にて報告する。

2.2

本シンポジウムのプログラムを、以下に示す。

クラウドアーキテクチャシンポジ

2

ウム開催

• WIDE プロジェクト代表挨拶 (代表 江崎浩 (東京大学))2010 年 7 月 2 日に、慶應義塾大学三田キャンパスにて WIDE プロジェクト主催のクラウドアーキテクチャ
シンポジウムを開催した。本節では、その開催報告を• 第一部 : クラウドコンピューティングのアーキテ
クチャ (13:00 – 14:45)

行う。

2.1

プログラム

– クラウドコンピューティングのアーキテクチャ(村井純 (慶應義塾大学))

開催目的– クラウドのセキュリティアーキテクチャ (門林雄基 (奈良先端科学技術大学院大学))

本クラウドワークショップは、「クラウド」という– IaaS アーキテクチャの現状 (関谷勇司 (東京キーワードが氾濫する昨今の状況において、そのアー

大学))∗ 東京大学† 奈良先端科学技術大学院大学‡ 株式会社 IIJ イノベーションインスティテュート

• 第二部 : テクニカル・アップデート (15:00 – 16:45)§ 東京大学1

– セキュリティとインタークラウド (門林雄基(奈良先端科学技術大学院大学))に関する報告が行われた。次に、WIDE プロジェクト– WIDE クラウドワーキンググループの活動(関谷勇司 (東京大学))

する発表が行われた。最後に、NICT が構築、運用しで構築、運用している WIDE Cloud の技術詳細に関ている StarBED をクラウドとして利用するための実験や検証に関する報告が行われた。

– StarBED とクラウドコンピューティング (三輪信介 (独立行政法人情報通信研究機構))

発表後の議論においては、より積極的な広域分散と耐障害性を追求した技術開発が必要であるという点と、• 第三部 : クラウド技術開発をガイドする (17:00 –19:00)

オープンな技術でかつセキュリティを確保したインター– パネル : 技術とベストプラクティス (座長:行われ、現状の技術では信頼性を担保するための監視

クラウドを実現するための手法が課題であるとの指摘があった。また、クラウドの管理技術に関する議論も

江崎浩 (東京大学))

技術や管理技術が確立されていないことも議論された。
第三部においては、パネルセッションにて議論が行– パネル : ポリシと標準化 (座長:村井純 (慶應

われた。このパネルセッションでは、クラウドアーキテ

義塾大学))

2.3

クチャはより上位層のアプリケーション、サービスを含めたものに発展していく傾向にあり、その組み立て

シンポジウムにおける議論方によっては、「砂上の楼閣」となってしまうという懸念が指摘された。これは、基盤の技術を固めずに既存

第一部は、クラウドコンピューティングのアーキテの技術を継ぎ接ぎして構築されているクラウドアーキ

クチャに関しての発表と議論が行われた。一口に「クテクチャを比喩するものである。これに関して、オーラウド」と言っても、その運用形態は様々であり、そプンアーキテクチャの技術を提唱し、きちんと標準化の形態に応じてアーキテクチャも異なることが報告さを行っていくことが重要である、という指摘が出され、れた。また、クラウドコンピューティングを利用した

WIDE プロジェクトは技術開発と標準化を通して世界に貢献することが必要であるとの認識が共有された。

サービスと、既存のサービスとの違いについて発表があり、その違いから発生するセキュリティ上の問題点
に関する発表も行われた。
発表後の議論は、アーキテクチャの開放性、透明性、

2.4

イノベーションに関するものから始まり、いまのクラシンポジウムのまとめ

本シンポジウムは三部構成で行われ、第一部、第二ウドはクローズドアーキテクチャの抱え込みサービス

部では「クラウド」の現状把握とその技術詳細、問題になっている点が懸念である、という点が指摘された。

点の把握が行われた。これを受けて第三部では、クラ

また、クラウドの利点を生かして運用されている商用

ウドの健全な発展とそのために WIDE プロジェクト

クラウドというものが少なく、既存技術の組み合わせが今後なすべき課題に関する議論が行われた。WIDEで構築されたアーキテクチャの上で、既存のサービス

プロジェクトはその技術開発と標準化、運用技術の蓄の低コスト版を展開しているのみにすぎない、という積において、クラウドのガラパゴス化を防ぎ、オープ

意見が出された。

ンアーキテクチャとしての健全なる発展に貢献するこ

今後は、SLA(Service Level Agreement)、ならびにとが必要である、との結論が導かれた。

信頼性、冗長性の確保が技術的な課題となり、オープ

この議論をうけ、WIDE クラウド WG では、信頼

ンアーキテクチャを基にしたクラウドアーキテクチャ

性、冗長性の確保、ならびに安定運用のための技術開の設計が望まれるという議論がなされた。

発や標準化に積極的に取り組む所存である。

第二部では、より技術的な観点からの現状報告とその問題点に関する議論が行われた。まず、インターク
ラウドを構築するにあたってのセキュリティ課題に関する発表が行われ、クラウドのセキュリティというものが認識されておらず、今後問題となるであろう課題2

3

甲子園インターネット中継

3.1

プロジェクト概要

koshien の配信する Web ページには画像表示用の
JavaScript が配置してあり、この JavaScript が一定間隔で sentryc から画像を取得することで、パラパラア
ニメのように動作し、ストリーミングが閲覧出来ない

全国高等学校野球選手権大会 (以下、甲子園) のといった環境下でも、試合進行や球場の雰囲気を伝え

インターネット中継は、朝日放送、奈良先端科学技術ることができる。

大学院大学、NTT スマートコネクトの共同プロジェ

sentryd から sentryc へのデータ転送は、プライベークトとして 1998 年から行われており、試合経過や過トネットワークを利用しており、sentryd はインター

去の試合のハイライトなどを Web でリアルタイムに

ネットへの接続点は持っていない。

提供している。 今年度は、Web コンテンツの一部をWIDE Cloud を利用して配信を行うことで、期間限定の大規模配信におけるクラウドコンピューティング活用について検証した。

3.2

3.3

昨年度までの課題とクラウドによる解決

昨年度までの構成では、アクセス集中時に sentryc 系

甲子園システムの概要のサーバ能力不足や対外線の逼迫により、一部のユー
ザへ画像が配信されないような場合があった。sentryd

甲子園システムは、3 種類のサーバから構成される。

側で JPEG 画像の圧縮率を上げる、パラパラアニメのkoshien 甲子園の Web コンテンツ全体を配信

更新間隔を伸ばすなどの対策を行ったが、その分ユー

sentryc ライブ配信ページのパラパラアニメを配信

ザへの配信クオリティが落ちてしまうという問題もあっsentryd NTSC の入力から静止画の切出しと圧縮を行い上の VM とすることで、外部の計算機リソースやネッ

た。そこで、sentryc 系サーバの一部を WIDE Cloud

sentryc へ提供

トワーク帯域を利用するという運用を行った。
+,(-'.%/#+,(-'.%/0+,(-'.%/1

!"#$%&'<%=$"/$9/!71%"'/8"89%&'">=?"%&

1:1*7"

53(01)*./(/01.23.4%
#:;<(

+,(-'.%/M
映像

89';!"#$%&

(.%)23=

1:1*7"/89'C>"/%"1'!/+,-./'1$1

(.%)234/#
(.%)234/0
(.%)234/1

$$$!"#$%&'()

!"#$%&*$$$+,-./0%1#!2"%/
345,6

@0AB/=#:C$

6-.*@%).2%.)

566
789
40$=,O'"&#:;<(
()*+,-./(/01.23.4%

(.%)234/N!"#$%&'(

!71%"'/8"89%&/?@AB*4C,D=*
E57@F6G*H>6IJKIL(.%)234>%&2&#(.%)234>%&2&0

-0$%&2&$$$!"#$%&*()

!"#$%&'()*

図 1: sentry サーバプログラムの動作(.%)234>%.PD#
(.%)234>%.PD0

QR$%.PD$$$!"#$%.PD*

sentryd と sentryc の動作モデルを図 1 に示す。sen-

図 2: 2010 年度甲子園システムネットワーク概要図

tryd は入力された映像をパラパラ漫画の要領で 1 秒
毎に JPEG データとして切り出し、sentryc サーバに
UDP 転送する。JPEG 画像データを受け取った sen-

今年度の甲子園システムのネットワーク構成を図 2に示す。WIDE Cloud 上の VM は、奈良 (NAIST) とtryc は共有メモリへ JPEG データを書き出す。同一サーバ上で動作している apache には mod sentry と呼

根津 (東大) に配置し、1VM 毎に 1 グローバル IPv4/v6
アドレスを割り当てた。

ばれるモジュールを組み込んであり、特定の URL に

従来プライベートネットワークで運用していた sen-

アクセスするとこの共有メモリの内容が配信されるよ

tryd は、cisco2.dojima との間を JGN2plus 経由で接うになっている。

3

続することで、インターネット経由で WIDE Cloud 上

いのは、準仮想化によるエミュレーションのオーバーの sentryc へも画像転送を可能とした。

ヘッド削減の効果によるものである。

実 計 算 機 で あ る sentryc.asahi.co.jp と 、WIDE

Cloud の振り分けは、koshien が配信する JavaScriptLinux カーネルのバージョンが古いにもかかわらず
CentOS (Linux 2.6.18) が Ubuntu (Linux 2.6.32) よの参照先サーバを書き換えることで実現した。koshien

り速い理由は、タイマ割り込み間隔などのカーネルのシリーズは本年度は 9 台で運用したので全体の 1/9 ず

設定に起因すると考えられる。

つのトラフィックを振り分けられる。さらに、koshien
シリーズの負荷に余裕がある場合は前段のロードバラ

3.5

ンサのウェイトを変更することで細かいトラフィック

甲子園システムの運用は、開幕の 8 月 7 日から行わ調整が可能である。

3.4

運用報告

れた。WIDE Cloud では、奈良と根津にそれぞれ 4 台ずつの VM を準備した。決勝戦でのトラフィックは甲ベンチマーク

子園システム全体で 650Mbps を記録した。また、最大トラフィックは準決勝で 800Mbps を記録している。

実 際 の 運 用 前 に 、WIDE Cloud 上 の VM で のApache ベンチマークを行った。Hypervisor は CPU による変化を調査するため、Intel Xeon と AMD Opteron

3.5.1のサーバを利用した。Hypervisor の構成を表 1 に示す。

実戦投入

WIDE Cloud 上の VM の実戦投入は甲子園 2 日目第また、VM の GuestOS として これまでの甲子園で3 試合から開始され、koshien のうち 1 台の JavaScriptの参照先を奈良の VM へ変更することでトラフィックの運用実績のある CentOS 5.5 と、Hypervisor と同じ

OS である Ubuntu 10.04 をインストールし、OS の違いによる性能差を比較した。また、仮想 NIC についが分散されることを確認した。VM の TCP セッショ
ン数の変化を図 3 に示す。14:30 付近からセッションて、準仮想化ドライバを利用する virtio と、Intel Pro

数が増加しているのがわかる。

1000 のエミュレーションである e1000 の比較も行った。VCPU は 1、割り当てたメモリは 4GB、利用した
Apache のバージョンは 2.2.16 で、MPM は event を利用し、mod sentry を組み込んである。
ベンチマークは httperf を利用し、mod sentry によって画像が提供される URL を対象とした。sentryd の提供するコンテンツサイズは 25KB とした。
表 2: Apache ベンチマーク結果
構成
レスポンスレート (s)Intel+CentOS+virtio

2153

AMD+CentOS+virtio

1107Intel+CentOS+e1000

1188

Intel+Ubuntu+virtio

1886

図 3: sentryc 切替時の TCP セッション数の変化
随時、VM の追加、削除を行ったが特に問題は無く、大会 8 日目は準備した 8VM を全て投入した。この日の奈良の Hypervisor におけるネットワークトラフィ
ックを図 4 に示す。4VM の合計となっており、最大

80Mbps、根津と合わせて約 150Mbps、約 8000TCP
セッションとなった。

表 2 にベンチマーク結果を示す。最も性能が高かったのは、Intel Xeon のサーバ上で CentOS と virtio を3.5.2利用した組み合わせであった。AMD のパフォーマン
スが伸びないのは、kvm amd カーネルモジュールの実

リバースプロキシ導入

koshien と sentryc の紐付けにおけるさらに細かい装の問題である可能性が高い。virtio が e1000 より速

ウェイト調整や、AMD の Hypervisor の利用、グロー

4表 1: Hypervisor の構成
vm1.naist

vm2.naist

CPU

Xeon L5520 (2.26GHz) x2

Opteron 2387 (2.8GHz) x2

Memory36GB DDR3

64GB DDR2

OS

Ubuntu 10.04 amd64

Hypervisor

KVM 84

3.5.3

トラブル

全 VM 投入後、大会 11 日目のピーク時間帯に VM
や Hypervisor の応答が著しく悪化する問題が発生した。問題発生時の Hypervisor の CPU 使用率のグラフを図 fig:cloud:koshien-sentryc-trouble に示す。30 分程の間、監視マシンから snmp データが取得できていな
い様子がわかる。CPU 使用率やメモリ使用量、ネット

図 4: 4VM 合計ネットワークトラフィック

ワークトラフィックはまだ頭打ちになっていないので、
各 VM から発行されるネットワーク割り込みの処理に

バル IPv6 アドレスのみを持つ VM の追加などを目的

よって Hypervisor の処理が逼迫し、パケットに応答でに、リバースプロキシを導入した。リバースプロキシ

きなくなった可能性が考えられる。

がボトルネックにならないよう、実計算機を利用した。
表 3 にリバースプロキシのサーバ構成を示す。
表 3: リバースプロキシのサーバ構成
CPU
Xeon X5570 (2.8GHz) x2

Memory24GB DDR3

Network

10 Gigabit

OS

CentOS 5.5

Rev.Proxy

Apache 2.2.16 (event MPM)
mod proxy balancer

図 6: VM 応答悪化時の Hypervisor の CPU 使用率
さらにリバースプロキシ導入後にも応答悪化、画像が途中で切れるなどの問題が発生した。こちらは、奈

mod proxy balancer のセッティングを図 5 に示す。

良に設置したリバースプロキシのバックエンドに根津

ここに示しているのは、guest1 および guest2 を Intelの VM を配置したのが原因で、バックエンドを奈良のXeon の Hypervisor 上、guest3 および guest4 を AMD

VM のみにしたところ解消した。
また、Ubuntu 10.04 の net-snmp に問題があり、80Mbps 以上のトラフィックを snmp で取得できないとOpteron の Hypervisor 上に配置した状態で、負荷を均等にかけたい場合の設定である。
大会 14 日目第 1 試合において、トラブルに見舞わいう問題や、Internet Explorer において sentryc の切れたものの、リバースプロキシのみで 166Mbps、甲子替がうまくいかない問題などがあることも分かった。

園システム全体で約 800Mbps を記録した。

5

図 5: mod proxy balancer の構成ファイル (例)<Proxy balancer://cluster>
BalancerMember http://guest1.naist.wide.ad.jp/sentry-handler loadfactor=10
BalancerMember http://guest2.naist.wide.ad.jp/sentry-handler loadfactor=10
BalancerMember http://guest3.naist.wide.ad.jp/sentry-handler loadfactor=2
BalancerMember http://guest4.naist.wide.ad.jp/sentry-handler loadfactor=2</Proxy>

3.6

考察と課題

4.2

今回の実験は、期間限定の大規模配信基盤としてク

予備実験

ラウドを利用するという試みであり、おおむね良好な

Xen においてメモリの汚れ方によってライブマイグ
レーションの挙動がどのように変わるのかを実験するに結果を得ることができたと考えている。特に、昨年度当たって予備実験を行った。２台の ThinkPad X61 には複数回行う必要があったパラパラアニメの更新間隔

Fedora 14 と Xen4.0.1 をインストールし Gigabit Eth-の調整が今年度は 1 度だけで済んだため、クラウドを

ernet スイッチに接続し、memtest+86 の CD イメージをブートディスクとする仮想マシンを作成し 128MB のメモリを割り当てた。メモリにシーケンシャルに書き利用することでクライアントへの配信クオリティを向上できたと結論づけられる。
運用面では、検証不足な点がいくつか散見された。

込みを行う Test 0 とランダムに書き込みを行う Test4

ベンチマークほど実戦では性能が出ない点、同一ワーをそれぞれ実行しながらライブマイグレーションを行

クロード多重化による性能劣化、リバースプロキシのった。

構成法などである。
今後、これらのトラブルの原因究明や、実戦によりTest0、Test4 におけるメモリ転送の各イテレーショ
ンにおける転送されたページと汚れたページとスキッ

近いベンチマーク手法、VM のチューニングについてプされたページの数をそれぞれ図 4.2(a)(b) に示す。

検討を行う必要がある。

Test0 では早い段階で転送ページ数と汚れたページ数

また、クライアントのソースアドレスや AS によっの差が収束し 13 回目でイテレーションを終了していて配信元の VM を変更する、つまりクラウドを CDNるのに対し、Test4 ではページの転送がページの汚れの一種として利用する方法についても検討を行いたい。

方に追いついていないため収束せず、30 回目で強制的に終了されている。それぞれのメモリの転送速度と汚4

ライブマイグレーション性能評価

4.1

背景

れ速度を図 4.2(c)(d) に示す。ランダム書き込みを行う

Test4 ではシーケンシャルな Test0 に比べて平均約３倍の速度でページが汚れているのがわかる。シーケン
シャルな書き込みであれば同じページに何度も書き込みが行われるのでページの汚れ方は緩やかになる。一Xen や KVM などの仮想化技術のひとつにゲスト
OS を停止させずにハイパーバイザ間を移動させる技術であるライブマイグレーションがある。ライブマイ方でランダムで書き込む場合はページの一箇所でも書き込みが行われればページは汚れたと判断されるためページの汚れ方は激しくなるからである。

グレーションは LAN 内で行われることを想定し設計さXen ではメモリの転送速度は 500Mbps に制限されてれている技術である。本計測では、ライブマイグレー

いるなど、Xen のメモリ転送のイテレーションに関係ションを長距離広帯域下で行った際の挙動を計測し評する各種の値はソースコードにハードコードされ、経価を行う。

験的な値に基づいていると考えられるため、環境に応じて最適な値を見つけることによってマイグレーションを高速化する余地がある。

6

192.168.10.0/24
.30
.100
Xen A

(a)

.20

(b)

VLAN A 10.37.9.0/24.2

情報基盤センター
L3sw
.100
.2

Xen B

.3
JGN 福岡L3sw.3

VLAN B 10.37.1.0/24.10
NFS Server
(c)

(d)

図 8: Xen におけるライブマイグレーション実験時のネットワーク構成

図 7: ライブマイグレーション予備実験の結果

4.3

現在は JGN2plus の回線を用い数回計測を行い、本性能評価計測にむけたチューニングを行っている。予備計測で実際の性能評価を行うにあたって、JGN2plus の回は TCP のウィンドウサイズがボトルネックとなり帯線を利用し性能評価を行っている。機器の構成は Dell

域を十分に使用出来ていなかったため、本計測ではデPowerEdge R410 を 3 台用いた。Xeon 2.27GHz を持
つマシン 2 台に Debian lenny と Xen3.2.1 をインス

フォルトのウィンドウサイズを最大値に設定する。
メモリを汚す際のプログラムに関しても、現在は128MB のファイルを用意し、UNIX システムコール

トールし、Xenon 1.87GHz のマシンに Ubuntu10.04
をインストールし，NFS サーバとして構築した。ネッである mmap() を用いてそれをメモリ上に allocate しトワークの構成を図 4.3 に示す。ネットワークは NFS

た上でランダムな位置にランダムな値を書き込むプロ

でストレージを共有している LAN はすべて 1G を使

グラムを使っている。ただし、sleep() やランダム値生

用し、JGN2plus の回線では帯域は 10G の回線、Xen

成時のオーバヘッドが原因で単位時間あたりのメモリのサーバでは 1G の NIC を使用している。福岡での折の汚れ具合が正確ではないことがわかったため、rdtsc

り返しでは RTT が 40ms、基盤センターでの折り返しを用いたプログラムに変更行っている。以上のチュー

では RTT が 0.2ms である。

ニングをもとに今後、本計測を行う。

実験の手順は下記を予定している。

• Xen A, Xen B 間でライブマイグレーションを5行う。

• ライブマイグレーションにかかった時間、イテレー

トサービスを、いわゆるクラウド環境において提供する。

OS

ク可搬性の要求事項

近年の仮想化技術の向上により、様々なインターネッ

ションの回数を計測し、送信パケットを dump す• １ 、２ の 手 順 を ゲ ス ト

クラウド運用におけるネットワー

ることが可能になってきた。仮想化技術のひとつに、のメモリ

仮想計算機をハイパーバイザー間で移動させる、マイ（128MB,256MB,512MB,1GB,2GB,4GB,8GB）、

グレーション機能があるが、この技術は同一リンクに折り返し地点（基盤センター、JGN 福岡）、メモ接続されたハイパーバイザー間での移動に限定されて

リの汚し具合（汚していない状態、自作メモリ汚おり、インターネット上の任意の場所にあるハイパー

しプログラム起動時、memtest86+）をすべてのバイザーへの移動は考えられていない。本章では、イ組み合わせで繰り返し行う。

ンターネットを経由した異なるリンクへの移動の必要

7

性と、それを実現する運用技術案に言及することで、の技術であり、データセンター間を直結できる回

クラウド運用におけるネットワーク可搬性を考える。

線を持っている必要がある。VPN は VLAN より

なお、本アイデアはインターネットドラフトとしてまも柔軟な構成が可能だが、クラウドサービスの管とめてあり [1]、IETF Clouds BoF にて議論されたも理主体が異なる場合、容易には相互接続できない。

のである。

5.1

• ユーザーサービスネットワークの高可用性: VLANや VPN を用いる場合、それがインターネットへの単一障害点にならないようにする必要がある。

背景

データセンター間、クラウドサービス間でのネッ

本章ではデータセンター間およびクラウドサービス

トワーク可搬性を考えるとき、ユーザーサービス

間でのネットワーク可搬性に関する要求と手法をまとネットワークの高可用性を提供できなければならめる。仮想化技術の発展は、インターネットサービスない。

に変化をもたらした。PaaS (Platform as a Service) とよばれる技術は、仮想化された計算機によって構成された基盤の上にインターネットサービスを構築する。

5.3

現状の PaaS は単一データセンターで単一運営主体

ネットワーク可搬性モデル

ここでは 2 種類のネッワーク可搬性モデルを考える。

によって構築されているが、これを分散し、さらにはひとつはホストベースのモデル、もうひとつはネット

複数の事業者間で連携させたいという要求は拡大しつワークベースのモデルである。

つある。こうすることによって、PaaS を構成する一部の機器あるいはデータセンターに障害が発生した場
合でも、他のデータセンターへ仮想計算機を移動させ5.3.1

る等することにより、サービスの継続可能性が向上す

このモデルでは、各ホスト (ゲスト計算機) がネットるためである。

ワーク可搬性の機能を持つ。各々のホストは、なんらサービスを停止あるいは影響を与えること無く、仮かのホスト移動通信プロトコルを備えていなければな

想計算機をデータセンター間、クラウドサービス間でらない。仮想計算機が、あるハイパーバイザーから、移動させるためにも、ネットワーク可搬性技術が必要

異なるネットワークに属するハイパーバイザーにマイ

となる。

5.2

ホストベース可搬性モデル

グレートした場合、仮想計算機自身が移動通信プロト
コルを発動し、現在接続されているネットワーク環境

ネットワーク可搬性要求に応じて適切に自身のネットワーク環境を整えなければならない。

以下に、仮想計算機をデータセンター間やクラウド
サービス間で移動させるためのネットワーク可搬性に関する要求事項を挙げる。

5.3.2

ネットワークベース可搬性モデル

このモデルでは仮想計算機が利用しているネットワー• データセンターやクラウドサービスをまたがる

ユーザーサービスネットワーク: 各々のユーザー

ク環境が、移動の前後で変化しないことが保証される。

には、他のユーザーと干渉しない固有のサービス

仮想計算機は、ネットワーク環境の変化に気がつかな

ネットワークが提供されなければならない。これ

いため、移動の前後でなにかアクションを起こす必要はない。同じネットワーク環境を提供するため、クラはクラウドサービス間をまたがる場合でも守られウドサービス基盤側は、異なる場所に同じネットワー

なければならない。通常、こういったネットワー

クを提供する機能を持たなければならない。

クは VLAN や VPN サービスを用いて実現されるが、特に異なるサービス事業者によって運営されるデータセンター間やクラウドサービス間の連携を考えると現実的ではない。VLAN はレイヤー 2

8

5.4

実装手法

化を Mobile IP 機能によって検知し、適切に移動処理を行わなければならない。

本節ではネットワーク可搬性を実装する手法をいく

Mobile IP と同様、本方式を採用する場合はホーム
エージェントが単一障害点となる。ホームエージェン

つか提案する。5.4.1 節では広域 VLAN を用いた場合の可搬性の実装例を、5.4.2 節ではホストベースの可搬トの多重化などによる高可用性の運用は、本文書の範性技術として、Mobile IPv6[2] を用いる例を、5.4.3 節

囲を越えるのでここでは言及しない。

ではネットワークベースの可搬性技術として、NEMO

BS[3] を用いる例を紹介する。
5.4.3
5.4.1

NEMO ベースネットワーク可搬性

NEMO ベ ー ス の ネット ワ ー ク 可 搬 性 技 術 で は 、RFC3963[3] を用いたルータの移動通信プロトコルを活用する。クラウド運用者は、RFC3963 に準拠した

広域 VLAN によるネットワーク可搬性

ネットワーク可搬性を実現するひとつの方法として、
レイヤー 2 で透過的なリンクをすべてのクラウドサー

移動ルータを複数運用し、それぞれの移動ルータに固ビスに提供する手法が考えられる。近年の高速広域での定プレフィックス (Mobile Network Prefix, MNP) を

ネットワークの性能を考えると、広域にレイヤー 2 ネッ

割り当てておく。移動ルータは、クラウドサービスのトワークを展開することも現実的となってきている。

ユーザーからは原則隠されており、ユーザーは透過的

この場合、ハイパーバイザーの構成は単純になる。

に固定プレフィックスを利用する。

すべてのハイパーバイザーは、広域に展開された同一移動ルータ自身も仮想計算機として実現し、マイグ

レイヤー 2 ネットワークに接続されることとなり、単レートの際には、移動ルータとその固定プレフィック

一データセンターにおけるハイパーバイザー運用と変スに接続しているユーザーの仮想計算機が同時に同じ

わりがない。仮想計算機は、ハイパーバイザーのブリッ

ハイパーバイザーへ移動する。移動した後、移動ルージ機能によって、広域レイヤー 2 ネットワークに接続

タが接続するハイパーバイザーのネットワークは、以することになる。

前のネットワークとは異なるが、NEMO BS の手順を

仮想計算機のマイグレーションに関して特に注意す踏むことにより、新しいネットワーク環境に対応可能

る必要もない。すべてのハイパーバイザーが同一のリとなる。一方、固定プレフィックスに接続しているユーンクに接続しているので、既存のマイグレーション技

ザーの仮想計算機は、移動が発生した事実を知る必要

術を用いることができる。

はなく、移動前と同じ環境で継続して運用可能である。
ひとつの固定プレフィックスには、ユーザーの仮想

5.4.2

計算機を必要なだけ接続することができる。ただし、Mobile IP ベースネットワーク可搬性

仮想計算機のマイグレーションは移動ルータ単位とな

ホストベース実装では、すべての仮想計算機が Mo-るため、同じ固定プレフィックスに接続された仮想計算

bile IP 機能を備えている必要がある。加えて、Mobile
IP の運用に必要なホームエージェントもクラウドシス

機は、マイグレーションの際には必ず同時に同じ宛先
ハイパーバイザーに移動しなければならない。仮想計

テムの一部として運用されなければならない。

算機の移動に細かい粒度を持たせたい場合は、ひとつ各々の仮想計算機はハイパーバイザーが提供するローの移動ルータに収容する仮想計算機の数を減らす必要

カルネットワークに接続し、Mobile IP の手順に従っがある。逆に、通常統一セグメントで運用されるようて自身の気付けアドレスをホームエージェントに登録なサービス、たとえば、ウェブフロントエンドとデーする。Mobile IP の具体的な動作については、ここでタベースなどは意図的に同じ移動ルータに収容して効は言及しないので、詳しくは RFC3775[2] を参照して率を上げることができる。

ほしい。

固定プレフィックスを保持しているネットワークは、

仮想計算機がマイグレートされると、接続先のネット

実際にはハイパーバイザー内部に仮想的に作り出されワーク環境がマイグレートした先のハイパーバイザー

たネットワークとなる。移動元と移動先のハイパーバ

によって変化する。仮想計算機は、ネットワークの変イザーでは、移動する仮想計算機 (移動ルータやユー

9ザーの仮想計算機) から透過的にアクセスできる名称

直し、移動ルータが収容している仮想計算機には影響

で仮想ネットワークが提供されている必要がある。

が出ない運用となっている。

Mobile IP の場合と同様、高可用性を実現するためには、ホームエージェントの問題を解決する必要がある。

WIDE Cloud は IPv6 での運用を前提として設計してある。特に、6 章で紹介したネットワーク可搬性はWIDE Cloud におけるネット
ワークベース可搬性技術の運用

6

NEMO BS を基にしているため、IPv6 しかサポートされない。しかしながら、現状を考えると、IPv6 のみでの運用だけでは不十分である事は明らかであり、WIDE Cloud では、運用開始初期から広域 VLAN
ベースのネットワーク可搬性を提供してきた。5 章で分類したとおり、VLAN ベースの可搬性では、異なる

IPv4 への接続性を提供するのは必須である。そこで、ネットワークの運用は IPv6 のみとして運用コストを管理ドメイン間でのネットワーク可搬性を実現しにく

下げつつ、IPv4 への後方互換性を提供する手段としていという欠点がある。そこで現在、NEMO を用いた

IPv4 と IPv6 のヘッダ変換サービス (NAT64) を提供している。

ネットワークベースの可搬性技術を試験運用中である。
本章では、その運用の概要を解説する。

6.1

NAT64 の実装と運用

7

7.1

トポロジ

設計と実装

ここで提供する NAT64 サービスは、WIDE Cloud

図 6.1 に NEMO ベースのネットワーク可搬性を実での運用に特化した割り切った設計となっている。最現した WIDE Cloud のネットワークトポロジを示す。

大の関心はスケーラビリティである。WIDE Cloud 内

図に示してあるのは、ネットワーク可搬性に関係するには、将来的には対外的なサービスを担うノードを仮部分のみであり、完全な WIDE Cloud のトポロジと想計算機として運用する予定にしている。そのため、は異なることに注意して欲しい。

NAT64 変換部分がボトルネックとならないように、負ホームエージェントは WIDE の根津 NOC に設置

荷に応じて変換サーバを増減させることができる必要してあり、2001:200:0:1c01::/64 に接続している。移動がある。これを実現するため、IPv4 と IPv6 の対応は

ルータは現時点では 10 台が運用されており、NEMO

1 対 1 とし、一般的な NAT64 に見られるような、複数のホームネットワークとして 2001:200:d00::/64 を用の IPv6 クライアントがひとつの IPv4 アドレスを共有いている。各移動ルータには 2001:200:d00:1::/64 かする機能は省いてある。こうすることにより、NAT64

ら 2001:200:d00:a::/64 までのプレフィックスを固定プ

サーバは IPv6 ノードと IPv4 ノードの対応関係を静的

レフィックスとして割り当てている。移動ルータを受に知るだけで済むようになり、変換の状態を保持する

け入れることができるハイパーバイザーは、現在根必要がなくなる。すべてのヘッダ変換はパケット単位

津 NOC に 3 台、小松 NOC に 2 台が稼働中であり、で実行されるため、たとえ一連のデータストリームがそれぞれのプレフィックスは 2001:200:0:1c0a::/64 と複数の NAT64 サーバに分散したとしても、変換結果

2001:200:0:1400::/64 となっている。
移動ルータはいずれかのハイパーバイザーの中で仮に不備が生じる事が無い。これにより、負荷に応じてNAT64 サーバを任意の位置に配置して入力トラフィッ
クあるいは出力トラフィックを分散することができる。

想計算機として動作しており、ハイパーバイザーが提供するブリッジネットワーク経由でインターネットに本サービスのために開発した NAT64 プログラムは、接続している。根津から小松、あるいはその逆に移動

オープンソースソフトウェアとして公開済み [4] である。

した場合、ハイパーバイザーの提供するネットワーク
環境に変化が生じるが、移動ルータの NEMO 機能により、適切にホームエージェントとのトンネルを張り

10

WIDE komatsu: 2001:200:0:1400

Hyper
Hyper
visor
visor

2001:200:0:1c01
WIDE
Core

Home
Agent
Home: 2001:200:d00::/64

WIDE nezu: 2001:200:0:1c0a:
MR-1
MR-2
MR-3
MR-4
MR-5
MR-6
MR-7
MR-8
MR-9
R-10

Hyper
Hyper
Hyper
visor
visor
visor

from 2001:200:d00:1::/64 to 2001:200:d00:a::/64

図 9: NEMO ベースのネットワーク可搬性を実現した WIDE Cloud のトポロジ

7.2

トポロジ

図 7.2 に WIDE Cloud における NAT64 サービスのトポロジを示す。現在のところ、2 台の NAT64 サー
バが稼働しており、どちらかに障害が発生しても他方Internet

がサービスを引き継ぐ形をとることで、冗長性を確保している。

WIDE Cloud 内の IPv6 ノードからは、すべてのIPv4 ノードのアドレスが 2001:200:d00:100::/64 の空間にマップされ、あたかも IPv6 ノードと通信してい

WIDE
Core
2001:200:0:1c0a::/64
203.178.138.0/28

るように見える。

WIDE Cloud の外へは、限られた IPv4 アドレスがmap646

公開され、それらは 1 対 1 で WIDE Cloud 内の IPv6

map646

サービスホストに対応づけられる。WIDE Cloud 外のIPv4 ノードは、WIDE Cloud の公開 IPv4 アドレスにアクセスすることで、内部の IPv6 サービスホストの2001:200:d00:100::/64
203.178.138.221/29
203.178.141.194/32

サービスを享受する。

2001:200:d00:100::/64
203.178.138.221/29
203.178.141.194/32

7.3
図 10: WIDE Cloud における NAT64 サービスのトポ

運用サーバ

現時点で、WIDE Cloud の NAT64 サービスを利用ロジして運用されている公開サーバは以下の通りである。

• www.kame.net
KAME プロジェクトのホームページ。

11

幹となる項目の研究開発に引き続き注力していく予定• www.internetconference.org
インターネットコンファレンスのウェブサーバ。

である。

インターネットコンファレンス 2010 開催を機に、物理計算機から WIDE Cloud 環境に移行された。

参考文献

その他、2010 年 10 月 23 日に開催された、厚生労働[1] Keiichi Shima and Yuji Sekiya. Network Portability Requirements and Models for Cloud Envi-

科学研究成果発表シンポジウムでは、イベント用の一時ウェブサーバとして、4 台の WIDE Cloud サーバがronment. IETF, September 2010. draft-shimaclouds-net-portability-reqs-and-models-00.

NAT64 サービスと共に用いられ、運用された。

8[2] David B. Johnson, Charles E. Perkins, and Jari

まとめ

Arkko. Mobility Support in IPv6. IETF, June
2004. RFC3775.

今年度は WIDE Cloud システムの本格運用が開始され、システム自体の開発はもちろん、それを活用し[3] Vijay Devarapalli, Ryuji Wakikawa, Alexandru
Petrescu, and Pascal Thubert. Network Mobility(NEMO) Basic Support Protocol. IETF, January

た研究開発や、仮想計算機を貸し出してのイベントサ
ポートなどが行われた。また、研究開発の方向性を議論する場として、WIDE プロジェクトとしてクラウド

2005. RFC3963.

シンポジウムを開催し、クラウド技術に対する取り組みを紹介するとともに、実際にクラウドサービスに関[4] Keiichi Shima.

わっている人たち、また関わってほしいと思っている

map646:Mapping between

IPv6 and IPv4 and vice versa, December 2010.
https://github.com/keiichishima/map646/.

人たちを巻き込む場を設けた。
イベントとしては、3 章で報告した甲子園中継をはじめ、厚生労働省の厚生労働科学研究成果発表シンポ
ジウム、インターネットコンファレンス 2010 のウェ
ブサーバーホスティング、KAME プロジェクトのウェ
ブサーバーホスティングなどを実施した。
研究活動としては、広域での安定運用を実現するために必要となるライブマイグレーションの性能を評価する活動を実施し、よりよい広域マイグレーションに向けての技術検証を継続している。また、広域マイグ
レーションに必要な、資源マイグレーションのひとつとして、ネットワーク資源のマイグレーションに関する要求項目をまとめた。
運用面では、WIDE Cloud の操作をウェブベースで実現する WIDE Cloud Controller (WCC) の運用開始、5 章で議論したネットワーク可搬性の実証実験、
また完全 IPv6 運用に向けた NAT64 プログラムを開発し、運用を開始した。
来年度は、クラウドシンポジウムなどを通じての研究の方向性の確立、ネットワーク可搬性の実運用、効率的なライブマイグレーションに関する研究、広域ス
トレージに関する研究など、今後のクラウド技術の根12