WIDE Technical-Report in 2011

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

PROJECT

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 2011 年度活動報告
岡本 慶大, 島 慶一, 関谷 勇司, 中村 遼, 堀場 勝広
2011-12-31

WIDE クラウド WG 2011 年度活動報告
石田 渉∗

岡本 慶大†島 慶一‡

関谷 勇司∗

中村 遼§

堀場 勝広§

2011 年 12 月 31 日

1

はじめに

しかし、連邦型クラウドの場合には、異なったハー
ドウェアならびにソフトウェア、異なったネットワー

WIDE クラウドワーキンググループは、今後のクラウド技術の研究開発を推進するために 2010 年 1 月にクと運用ポリシによって構築されたプライベートクラ
ウドを連結し、マネージメントすることが必要とされ設立された。複数の WIDE 組織間に渡って運用される。そのため、WIDE クラウドでは、独自にクラウドる広域連邦型クラウドシステムである WIDE クラウ

マネージメントソフトウェアを設計し、実装した。こドシステムの運用と、それを用いた研究開発を行ってれは WCC (WIDE Cloud Controller) と呼ばれておいる。

り、オープンソースソフトウェアとして公開されてい2011 年度の主な活動を以下に列挙する。

る。異なったハードウェア、ソフトウェアを統合して管• WIDE クラウドコントローラ (第 2 章)

理するために、WCC は図 1 に示す構造にて作成され• WIDE クラウドネットワーク (第 3 章)

ル、ネットワーク制御モジュール、ストレージ制御モ

た。リソース管理モジュール、SNMP Polling モジュー• 甲子園中継 (第 4 章)

ジュールは Ruby 言語にて作成され、ユーザインタ• 遠距離狭帯域環境でのマイグレーション (第 5 章)

ソース管理モジュールが全ての情報を集め、VM の作

フェースは Ruby on Rails を使用して作成された。リ• 分散ストレージ技術の検証 (第 6 章)

成場所やリソースの割り当てを判断した後に、libvirt• IPv4-IPv6 トランスレータの評価 (第 7 章)

御モジュールに対して指示を出すことで、VM の作成、ならびにネットワーク制御モジュール、ストレージ制

VM へのネットワーク割り当てならびに VM イメー
ジ用のストレージ割り当てを行う。
また、連邦型クラウドの場合には、組織毎にリソー• LISP を用いたネットワークマイグレーション (第 8章)
• IETF の活動 (第 9 章)

スを提供するポリシが異なる場合があるため、拠点単
位で、他拠点に供出する CPU、メモリ等のリソース以降、それぞれの活動の詳細を各章にて報告する。

2を定義することができ、かつ余剰リソースを組織間にて融通することができるよう設計、実装した。

WIDE クラウドコントローラ

2011 年に行われた WCC のバージョンアップと、バージョンアップに伴って加えられた主な新機能に関WIDE クラウドは各拠点のプライベートクラウド
して以下にまとめる。
を連結して構成した、連邦型クラウドである。プライベートクラウドの場合には、統一の仕様にてクラウド 02/06 : Version 1.8 Release (Strict VM migration) VMを構築することができるため、そのマネージメントもマイグレーションの移動対象先を厳格に制限した
単一のソフトウェアにて可能である。
03/02 : Version 1.9 Release (NEMO Support) NEMO
∗ 東京大学† 奈良先端科学技術大学院大学
モバイルルータを利用したネットワーク移動透過‡ 株式会社 IIJ イノベーションインスティテュート

性を導入した§ 慶應義塾大学

1

ユーザ

Ruby on Rails

SQL
リソース管理モジュール

Database

SNMP Polling
Modulemap646

llibvirt

MGMT
moduleストレージ制御モジュール

ネットワーク制御モジュール

仮想化サーバllibvirtd

StorageiSCSIController

Sheepdog
Controller

MGMT
moduleMGMT
module仮想化サーバ

NFS
Controller

NEPL

MGMT
module仮想化サーバllibvirtd

llibvirtd

Storageネットワーク機器

ネットワーク機器

拠点 A

拠点 B

Storageネットワーク機器

拠点 C

仮想化サーバllibvirtd

Storageネットワーク機器

拠点 D

図 1: WCC アーキテクチャ

03/02 : Version 1.10 Release (Storage location) VM が3

利用するストレージの場所を指定できる機能を追WIDE クラウドネットワーク
IaaS クラウドは、単一のネットワークセグメントを加した

基本に構成される場合が多い。これは、コントローラ

05/01 : Version 1.11 Release (Change VM owner & VM
Hibernation) VM の所有者を変更する機能と VM
ハイバネーションの機能を追加した技術が VM を制御したり、ストレージ機器とサーバが通信を行うにあたっては、それぞれが同一のネット
ワークセグメントに存在する方が制御しやすいからである。また、VM がサービスに使うネットワークは、

05/17 : Version 1.12 Release (VM address info) VM がDHCP にて取得している IPv4 アドレスの情報をVLAN 等の技術を用いてサーバに提供され、サーバ
内部で VLAN を分割してそれぞれの VM に提供され取得できるようにしたる構成が多い。そのため、VM をサーバ間にてマイグ

10/21 : Version 1.13 Release (Storage migration) スト
レージマイグレーション機能を導入した

レーションさせるにあたっては、移動元サーバと移動
先サーバで同様のネットワーク構成が利用できなけれ
ば、VM マイグレーションや VM 耐故障技術を利用

12/17 : Version 1.14 Release (SUMIKAWA) メッセー
ジ表示や VM 所有者によるフィルタリング機能をすることができない。すなわち、サーバ間にてネット
ワーク移動透過性を確保する必要がある。

導入した

一般的な IaaS クラウドでは、サーバ間ならびに拠点間を物理的な回線で直接接続することで、サーバ間に同様の VLAN を設定できるようにしている。もしくは、IP トンネル技術等を用いて、拠点間で VPN

2

マイグレーション

IPv4/IPv6 インターネット
拠点 A

拠点 B
VM

仮想化サーバ
MobileRouter

VM

仮想化サーバ
MobileRouter

VM

VM

NAT66

NAT64

VM

IPv6

VM

仮想ネットワーク

仮想ネットワーク

ネットワークネットワーク

VM

VM

VM

仮想化サーバ

Home
Agent

IPv4

IPv6

VM

VM

VM

VM

仮想化サーバ

VM

仮想化サーバ

仮想化サーバネットワークネットワーク

拠点 A

図 2: NEPL によるネットワークマイグレーション

ネットワーク

拠点 B

ネットワーク

拠点 C

図 3: map646 によるアドレス変換(Virtual Private Network) を構成することで、離れた拠点にあるサーバ同士で同じネットワークを利用する
ことを可能にしている。しかし、拠点間をむすぶ専用

要な場合には、DHCP によってプライベート IPv4 ア
ドレスを取得することが可能となっているが、あくまの回線を利用するためには、拠点が離れているほど高でも補助的な扱いとなっている。VM には、割り当て額のコストが必要となり、また VPN を利用する場合

られる IPv6 アドレスの他に、外から VM にアクセス

でも、利用するネットワークが増減するたびに、VPNするためのサービス用 IPv6 アドレスならびに IPv4

設定を変更する管理コストが必要となる。

アドレスを割り当てることができる。インターネット

そこで WIDE クラウドでは、専用の回線や固定的から VM に割り当てられたサービス用 IPv6 アドレ

な VPN 設定を用いることなく、拠点間にてネット

スに対して通信があった場合には、NAT66 機能によ

ワーク移動透過性を実現する手法を導入した。WIDE

り IPv6 → IPv6 アドレス変換が行われ、VM に接続

Project にて開発されたソフトウェアである、UMIP(USAGI-patched Mobile IPv6 for Linux) ならびに
NEPL (NEMO Platform for Linux) を用いて、拠点される。同様に、サービス用 IPv4 アドレスに対して通信があった場合には、NAT64 機能により、IPv4 -¿IPv6 プロトコル変換が行われ、VM に接続される。この概要を図 [1] に示す。すなわち、VM は IPv6 に対してのみアプリケーションを設定しておくだけで、IPv6間において自由にネットワークを移動させることのできる仕組みを構築し、ユーザに対して提供した。ユー
ザは、自分専用のネットワークをどの拠点にも移動さと IPv4 どちらのクライアントに対してもサービスをせることができるため、専用の回線で接続されていな

提供することができる。さらに、VM を拠点間にてマい拠点にも、VM を移動させることが可能となった。

イグレーションした場合にも、アドレス変換によって

NEPL を用いたネットワーク移動透過性提供の仕組みを、図 2 に示す。

サービス用 IP アドレスを変更せずともサービスを継続することが可能となっている。

ネットワーク移動透過性を利用する VM は、Mobile

また、IPv4 IPv6 プロトコル変換にあたっては、
IPv6 アドレスの下位 64 ビットの中に、IPv4 アドレス

Router (MR) が提供する仮想ネットワークに接続される。VM を拠点間でマイグレーションする際には、を埋め込むことによって、NAT のように状態を管理

MR もあわせてマイグレーションすることにより、移動した先の拠点においても同じネットワークを利用しする必要のない、ステートレスなプロトコル変換を可能とした。IPv4 IPv4 変換を行う NAT の場合には、続けることを可能としている。

アドレスとポート番号の組み合わせを NAT 内部で管また、WIDE クラウドでは、VM には基本的に IPv6

理しておく必要があり、クラウドと外部ネットワーク

アドレスのみが割り当てられる。IPv4 アドレスが必

3

の出入り口を冗長化する場合には、NAT 間でその情

NTSC
input�

報を同期しておく必要がある。一方、map646 によるIPv4 IPv6 プロトコル変換の場合には、マッピング情報が IPv6 アドレスに埋め込まれているため、通信途

JPEG Transfer(UDP)�
sentrydsentrycsentryd01

中でネットワーク出入り口が切り替わったとしても、

write toshared memory�

問題なく通信を継続することが可能となっている。

apachedelivery�mod_sentry
apache module reads
JPEG data�shared memory

現在の WIDE クラウドでは、東京と大阪の 2 地点

sentryc01

に map646 サーバを設置し、WIDE クラウドとイン
ターネットへの接続を冗長化している。それぞれの

図 4: sentry サーバプログラムの動作

map646 サーバでは OSPF ならびに OSPFv3 が動作しており、クラウド内部で VM が利用しているアドレス
を、WIDE インターネット内部に OSPF、OSPFv3 にsentryd と sentryc の動作モデルを図 4 に示す。sentryd は入力された映像をパラパラアニメの要領で 1 秒て広告している。東京と大阪どちらかの map646 サー

毎に JPEG データとして切り出し、sentryc サーバにバやネットワークに障害が発生した場合にも、OSPF

UDP 転送する。JPEG 画像データを受け取った sen-による経路制御によって WIDE クラウドと外部ネッ

tryc は共有メモリへ JPEG データを書き出す。同一サーバ上で動作している apache には mod sentry と呼ばれるモジュールを組み込んであり、特定の URL に

トワークとの通信が自動的に切り替わり、かつステー
トレスな IPv4 IPv6 変換であるために、TCP コネク
ションが切断されることなく、通信を継続することがアクセスするとこの共有メモリの内容が配信される。

可能となっている。

4koshien の配信する Web ページには画像表示用の甲子園インターネット中継

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

全国高等学校野球選手権大会 (以下、甲子園) のような環境下でも、試合進行や球場の雰囲気を伝えることができる。

インターネット中継は、朝日放送、奈良先端科学技術
大学院大学、NTT スマートコネクトの共同プロジェク
トとして 1998 年から行われており、試合経過や過去

4.2の試合のハイライトなどを Web でリアルタイムに提今年度の甲子園システムの概要図を図 5 に示す。昨

供している。 昨年度同様、この Web コンテンツの一

年度は VM を配置する拠点のネットワークを利用し、部を WIDE Cloud を利用して配信した。また今年度

グローバルアドレスを VM に直接設定しため、他の拠は map646 を利用したシステムを構築し、配信運用中

点への VM マイグレーションが不可能であった。今年の VM の広域ライブマイグレーションも可能とした。

4.1

実験トポロジ

度は VM を WIDE クラウドの IPv6 広域 L2 セグメン
ト (VLAN6) に接続し、拠点間での VM マイグレーショ

甲子園システムの概要

ンを可能とした。map646 のサーバは、VLAN6 の内に RA を流しており、VLAN6 に接続している VM の甲子園システムは、3 種類のサーバから構成される。

デフォルトゲートウェイになっている。また、map646

koshien 甲子園の Web コンテンツ全体を配信を利用している VM のグローバル IPv4 アドレスは、
複数の map646 サーバより等コストの OSPF によってsentryc ライブ配信ページのパラパラアニメを配信

経路広告され、広域での負荷分散と高可用性を実現し

sentryd NTSC の映像入力から静止画の切出しと圧縮をている。

行い sentryc へ提供

なお、sentryd から sentryc へのパラパラアニメの転送は、JGN-X 経由で sentryd を VLAN6 へ接続することで実現した。

4

2. Content request

Round.robin

Exis%ng(system((.(Koshien(2009)
Video

sentrycsentrycsentrycsentrydOsaka

Client.
.
.The Internet
Load Balancer
1. Flip-anime loading Tokyo

Osaka
map646

3. Flip-anime distribution

map646

IPv6 L2 Network
JGN-X

Wide.area(live(migra%on

WIDE%Cloud

sentrycsentrycsentrycsentrycsentrycsentrycsentrycsentryc

vmX.naist 

vmX.nezu 

vmX.komatsu

vmX.fujisawa

NAIST (Nara)

U-TOKYOJAIST (Ishikawa) KEIO SFC (Kanagawa)

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

4.3

運用報告

しかし、選手権が進み配信が高負荷となってきた際に、map646 サーバが CPU リソースを使い果たし、画

甲子園システムは開幕の 8 月 6 日より運用を開始し像が配信されないというトラブルが発生した。これら

た。WIDE Cloud 上の VM を配信に投入したのは、大の map646 サーバは、WIDE Cloud 上の他の VM で会 8 日目の 8 月 13 日からである。今回は、根津、奈も利用されているため、Web ページが見れなくなるな

良、北陸に各 1VM の計 3VM を初期配置し、東京とどのトラブルも発生した。図 7 にトラブルが起きた際

大阪の map646 サーバで経路広告および IPv4/IPv6 パの東京と大阪の map646 サーバからのトラフィックをケット変換を行った。

示す。
このトラブルは map646 サーバ上で動作していた

4.3.1

stat 取得プロセスが CPU リソースの大半を使い果た

map646 による広域分散配信してしまったことにより、map646 のプロセスがパケッ

map646 を利用した広域負荷分散は狙い通り動作し、
図 6 に示すとおり、東京と大阪でほぼ同量のトラフィッ
クの吐き出しとなった。また、運用中に大阪の map646

トを変換できなくなったことにより発生したことが分かった。該当する stat 取得プロセスを停止することで正常に配信が行われることを確認した。

サーバがダウンするというトラブルがあったが、東京

またこの時に大阪の map646 へトラフィックが集中の map646 サーバ経由で問題無く配信された。最もトしている様子が図 7 からも読み取れるが、原因は不明

ラフィックが多かった時間で 120Mbps、5000 コネクである。

ションを記録している。

5

図 6: 東京と大阪の map646 サーバによる負荷分散

図 7: トラブルが発生した際の map646 サーバのトラフィック

4.3.2

運用中のライブマイグレーション

今後、map646 サーバのリソース増強や拠点増加、

map646 プロセスの改良や、広域分散環境における VM

配信中の VM の広域マイグレーションに関しても問マイグレーションの詳細な監視、マイグレーションス

題無く動作し、東京から北陸、奈良などへ VM を移動

ループット向上が必要と考えられる。また、サーバ-ク

しても画像は途切れることなく配信された。

ライアント間のルーティング情報を利用した分散配信

しかし、決勝戦の最も負荷の高い時間に VM マイについても検討を行いたい。

グレーションを行ったところ、マイグレーション開始
から 22 分後に突然配信が停止した。調査したところ、Hypervisor から該当する KVM のプロセスが消失していた。KVM プロセスがクラッシュした直接の原因は

5

不明であるが、高負荷時のライブマイグレーションは転送に必要なダーティページが多いためイテレーショ

遠距離狭帯域環境でのマイグレー
ション

仮想計算機を、あるハイパーバイザーから別のハインの回数が多くなってしまう。また、広域環境である

パーバイザーへ移動させる (マイグレーションさせる)

ためネットワークスループットが出ず、転送にかかる技術はすでに確立しており、ほとんどの仮想化環境で時間が想定以上に長くなってしまったことが、要因に提供されている。ただし、マイグレーション可能なのなっていると考えられる。

は CPU の状態とメモリの移動に限られ、ネットワー
ク環境やストレージ環境は十分考慮されていない。マ

4.4

イグレーションの前提として、移動前と後のハイパー考察と課題バイザーが、仮想計算機に対して同一のネットワーク

今年度の甲子園インターネット配信実験では、昨年

環境を提供していることと、同一のストレージ環境に度のクラウドを利用した配信に加え、ネットワーク負アクセスできることが必要条件となっている。ネット

荷分散と高可用性を目的とした広域負荷分散配信と、ワークに関しては、昨年度に報告した NEMO BS[2] 技

VM の広域ライブマイグレーションの実験を行った。
いずれも低負荷時には問題無く動作したが、高負荷時の安定性に難があることが分かった。

術を用いたネットワーク資源の透過性技術に加え、今
年度は LISP[3] などの別の IP モビリティ技術を用いた技術を研究中である。一方ストレージの透過性に関し

6図 8: 高負荷時のライブマイグレーションによる VM クラッシュては、将来的な技術導入を目指した分散ストレージ技
クストレージマイグレーション技術を用いた実証実験

IPv6 のネットワークの透過性に関しては、昨年度導入した NEMO BS 技術を用い、IPv4 のネットワー
ク透過性に関しては、本年度報告書の第 7 章で取り上を実施した。

げる map646 ソフトウェアを用いた IPv4-IPv6 ヘッダ

術の検証をすすめつつ (6 章)、現在利用できるブロッ

トランスレータ技術を利用する。3 つのサーバ (www、

5.1

fu-ring、ns) は、IPv6 アドレス的にはモバイルルータの配下となり、WIDE プロジェクトの NEMO サービ
スセグメントに収容される形となる。モバイルルータ、

ブロックストレージマイグレーション

ブロックストレージマイグレーションはオープンソー

および 3 台のサーバは、実際には WIDE クラウドの仮スの仮想化環境 QEMU で提供されているストレージ

想計算機として構築されており、WIDE クラウドサー

マイグレーション技術である。ブロックストレージマ

ビスネットワークに設置されたハイパーバイザー上でイグレーションは、メモリマイグレーションと同等の動作することになる。

手順をストレージデータに対して実施するものであり、仮想計算機のストレージはハイパーバイザーのロー

移動前のストレージのコンテンツを移動先のストレー

カルストレージから提供される。そのため、仮想計算機

ジにコピーする手法である。ただし、メモリに対してスを、あるハイパーバイザーから別のハイパーバイザー

トレージの容量が大きいため、単純なコピーに加えて、に移動する際にはストレージマイグレーションを実行

コピーオンライト形式 (QEMU の表記では QCOW もしなければならない。前述の通り、今回は QEMU がしくは QCOW2 形式) を用いた差分コピーの機能も提提供するブロックストレージマイグレーションを利用供されている。

5.2

した。
合宿ネットワークは 3 本の対外接続線によってイン実験環境

ターネットと接続された。今回、合宿地が三重県の伊勢志摩ということで、光回線などの広帯域回線を手配

2011 年 3 月に三重で開催した合宿研究会においすることができず、2 本の ADSL 回線と 1 本の衛星回て、合宿地のネットワークおよびサーバ環境の一部を線を利用せざるをえなかった。そのため、結果的に狭帯

WIDE クラウドを用いて構築する試みが実施された。

域でのストレージマイグレーションの実験の場となっ合宿開催前に、あらかじめ合宿地で利用するサーバ群ている。ADSL 回線は 2 本合わせても 1Mbps 程度しを設定しておき、合宿地へのネットワークが開通する

か速度を得られず、帯域的には 1.5Mbps を活用できると同時に、合宿地に設置したハイパーバイザーへ関連

衛星回線の方が太いということになり、仮想計算機、サーバ群を移動する。図 9 に、本マイグレーション実およびストレージマイグレーションは衛星回線を用い験に関わる合宿ネットワークのトポロジを示す。詳細て実行された。

なトポロジ情報は、合宿実験の報告 (「大規模な仮設
ネットワークテストベッドの設計・構築とその運用」)
を参照して欲しい。

7

インターネット

衛星
合宿ネットワーク

ADSL
WIDEコアネットワーク
ADSL

合宿コア
ネットワーク

WIDEクラウド
203.178.138.32/27
2001:200:0:6001::/64

203.178.158.32/27
2001:200:0:ff40::/64

NEMOサービスセグメント.49::20c:29ff:fe25:5835
トランス
レータ
203.178.138.0/28
2001:200:0:1c0a::/64

203.178.142.192/27
2001:200:0:1c01::/64
ホーム

エージェント::20002001:200:d00::/64

モバイル

Hypervisor.9::218:8bff:fe43:d1d0
トランス
レータ

www

モバイル
ルータ

fu-ring

ns

マイグレーション後の物理的位置

2001:200:dff:fff1::/64

ルータ

ハイパーバイザー::1
2001:200:d00:a::/64
::130
www

モバイル
ルータ

::134

::131

fu-ring

ns

サーバー群の論理的位置

www

fu-ring

ns

マイグレーション前の物理的位置

図 9: マイグレーション実験のトポロジ

表 1: 仮想計算機の情報
メモリ容量 ディスク (差分)モバイルルータ

5.3

www

512M
1000M

470M
86M

fu-ring
ns

1024M
1024M

370M
205M

表 2: マイグレーション時間
モバイルルータ
56 分

結果

www

20 分

fu-ring
ns

53 分
28 分

合計

2 時間 37 分 (157 分)

表 2 にマイグレーションにかかった時間を示す。この時間には、ストレージのみでなく、メモリマイグレー

それぞれの仮想計算機の情報を表 1 に示す。前述のションの時間も含まれる。表 1 を見ると、相対的にメ通り、ストレージは全体をマイグレートするのではな

モリ容量の方がディスク容量より大きく見えるが、使く、ベースイメージからの差分のみをマイグレートす用されていないメモリ空間は転送されないため、実際る差分ストレージマイグレーションを用いている。ベー

に転送されるメモリデータは表に示したものよりも少スイメージは、すべてのハイパーバイザーがあらかじないと考えられる。それに対して、ディスクイメージ

め持っていると仮定し、合宿ネットワーク内に設置し差分は、実際に使われている容量に等しいため、表にたハイパーバイザーにも、元のハイパーバイザーで利示す容量がすべて転送されている。

用していたそれぞれの仮想計算機のベースイメージのマイグレーションは、モバイルルータ、fu-ring、ns、

コピーをインストールした。

8

開始
0

56
56

109
53

28

度に引き続き、広域での仮想計算機マイグレーション

完了
157分

137

の技術検討を継続しており、今年度はストレージマイ
グレーションの検証を実施した。現在提供されている

20

モバイルルータ

QEMU のブロックストレージマイグレーション技術

fu-ringは、実際に広域ネットワークでも実行できることが確ns

認できたものの、狭帯域のネットワークではそもそも

www

マイグレーションに時間がかかる、また組み合わせる
ネットワークマイグレーション技術によっては、長くWIDEクラウドに接続

インターネットから切断される時間が発生することも合宿ネットワークに接続確認できた。今後は、第 6 章でとりあげるような分散接続断ストレージ技術、また第 9 章で言及するような、他の種類のネットワーク透過性技術等も考慮しつつ、広域

図 10: ネットワーク接続性

運用可能な技術開発を継続していく。

分散ストレージ技術の検証

6

WIDE クラウドワーキンググループでは、広域ク
ラウド環境で運用可能なストレージ技術の検証を行っている。今年度は、NTT サイバースペース研究所の森田氏が設計した QEMU 用の分散ストレージ技術

sheepdog[4] を検討し、その実用性を検討した。

図 11: マイグレーション中の衛星回線トラフィック

www の順で実行された。すべての仮想計算機は QEMUのライブマイグレーション機能を使って、動作させた

6.1

動機

WIDE クラウドワーキンググループでは、複数の組織に広域に跨がった連邦型クラウドコンピューティン

ままマイグレートされているが、ネットワーク的にモバイルルータが存在しない期間が発生するため、イング環境を目指しており、それを実現するために書かせターネットから切り離された時間が発生している。図

ない技術が広域運用可能な分散ストレージである。現10 に示したように、モバイルルータがマイグレーションを完了した瞬間から、fu-ring、ns、www はそれぞ在、WIDE クラウドワーキンググループが運用する

IaaS 基盤 (WIDE クラウド) は、Linux のディストリ
ビューションのひとつである ubuntu と、それに標準搭載されている KVM 仮想化環境を用いて構築されてれ、53 分、81 分、101 分の間、インターネットへの接続性を失う。
図 11 はマイグレーションが実行されている間の衛おり、その環境と連携して動作するストレージシステ

星回線のトラフィック量を示すグラフである。開始直ムが必要とされている。

後から完了まで、1.5Mbps の衛星回線を完全に埋めて

現在、WIDE クラウドのストレージとして広域 NFS

いる事がわかる。

および iSCSI 技術を用いている。iSCSI サーバは全国

4 カ所 (WIDE プロジェクト根津 NOC、WIDE プロ

5.4

考察

ジェクト大手町 NOC、北陸先端科学技術大学院大学、
奈良先端科学技術大学院大学) に配置されている。各

仮想計算機技術は、すでに商用製品、商用サービス

拠点に NFS サーバが設置されており、iSCSI ディスクが広く普及している成熟した分野であるが、広域ネッをマウントした後に、各ハイパーバイザーに NFS ファ

トワークを前提とした運用技術はまだ確立されていな

イルシステムとしてストレージを提供する形で運用さい。WIDE クラウドワーキンググループでは、昨年

れている。

9

CPU
メモリ
ディスク

NIC

また、別のひとつのノードには iSCSI ターゲット機能

表 3: 実験ノードの仕様
Intel Xeon X5670 (6 コア) x 2を構成し、sheepdog クラスタ外のハイパーバイザーへのストレージ機能提供を試みた。図 12 にクラスタ構

48GB
SATA 500GB x 2Intel Gigabit double、Broadcom

成図を示す。

5709 quad

6.4

機材借用期間に限りがあったため、十分なデータの現状の構成では、iSCSI あるいは NFS サーバをホス取得に至っていないものの、以下に述べる動作の検証

トしている組織への到達性を失うと、該当ストレージを実施できた。

に収容されている仮想計算機が利用できなくなる。そのため、仮想計算機イメージを分散収容できる広域ス• 46 台におよぶ実ノードを用いたクラスタ運用のトレージシステムが必要となっている。

6.2

考察

実証

• 既存のクラスタへの、新たなノードの追加

sheepdog• クラスタ内での仮想ディスクの構成

sheepdog は NTT サイバースペース研究所の森田氏によって設計された、完全対称型の分散ストレージシス
テムである。広く普及している仮想計化環境 QEMU の• クラスタ内での仮想計算機の稼働すべて、そもそも sheepdog が提供するとされる機

ストレージとして利用されることを前提としており、メ能と明言されているものの、実環境に近い構成でそのンテナンスの容易性、規模性を特徴として挙げている。

動作を確認できた意義は大きい。また、実験の過程で、WIDE クラウドワーキンググループでは、sheepdog を
広域環境で利用できるかどうかを検討するため、大規
模エミュレーション環境を実現できる StarBED[5] をソフトウェアの不具合によると思われる現象を発見し、適宜開発者と連絡を取ることによってソフトウェア自体の品質の改善にも貢献できている。

用いて運用可能性を検討する作業に着手した。

逆に、検証できなかった、あるいは動作しない/動作
不安定だった項目として以下のものが挙げられる。

6.3

StarBED での実験構成• クラスタからのノードの切り離し

今回、StarBED から提供 Cisco UCS 200 M247 台• クラスタを構成するメンバシップの一貫性が不安定を利用し、大規模ノード数での運用現実性を検討した。

• iSCSI ターゲット機能

UCS の仕様を表 3 に示す。
時間の都合上、今回の実験ではすべてのストレージ

sheepdog では、クラスタの構成は各ノードが自立

ノードが同一 LAN 上に配置され、その上での運用実的に協調することによって実現されており、ストレー験となった。ストレージノードとして 46 台を利用し、ジノードの参加、離脱は任意のタイミングで実行できそれぞれのストレージノードが内蔵ディスクのひとつることとなっている。しかしながら、検証の過程で、(500GB) を提供する形で sheepdog クラスタが構成さ

ストレージノードの切り離しにおいて動作が不安定にれている。ディスクの合計数が全体のストレージ容量なる場合がみられ、安定した運用ができなかった。現になるが、今回はデータのレプリケーション数を 3 に時点では、ノードを切り離した後、クラスタの状態が設定しているため、実際のストレージ容量はその 3 分

安定するまで待つことで、ある程度運用可能であるこの 1 となり、およそ 7TB となっている。ほとんどのスとが分かっているが、クラスタが安定する状態が外部

トレージノードは、ストレージ機能しか提供しない構から把握しにくいことや、また、事故などによるスト成となっているが、ひとつだけハイパーバイザーとしレージノード切り離しが発生する場合なども考慮するて動作するノードを構成し、仮想計算機を動作させた。

と、運用は難しいと考えられる。

10

VM

VM

VM
iSCSI interface

Hypervisor &iSCSI initiator

iSCSI target &Storage node

Storage
Storage
Storage
Storage
Storage
Storage
Storage
Storage
Storage
Storagenodenodenodenodenodenodenodenodenodenode

VM

Hypervisor &Storage node

Storage
Storage
Storage
Storage
Storage
Storage
Storage
Storage
Storage
Storagenodenodenodenodenodenodenodenodenodenode

Sheepdog cluster (copies=3)
46 storage nodes of 500GB HDD for each, about 20TB (/3) storage in total

図 12: sheepdog クラスタの構成

sheepdog はストレージノードのグループ管理に7.1

生することがあった。この状態では、ストレージデーの計算機の性能向上にだけ頼った方式には限界が見え

スタが正常に動作しない。sheepdog は、今後 corosync

始めている。近年はネットワークで接続された計算機以外にも、zookeeper や accord といったグループ管3を統合して利用する、グリッドあるいはクラウドと呼理機構に対応する予定となっているため、継続して運ばれる技術に注目が集まっており、その利用方法やア用性を検証していく予定である。

プリケーションモデル、資源の効率的な運用方法など

最後の iSCSI ターゲット機能に関しては、iSCSI イの研究が盛んである。また、計算機の資源をより細か

ニシエータとして設定したノードからディスクとしてい粒度で活用するために、ひとつの計算機を仮想的にマウントすることはできたものの、仮想計算機からディ複数の計算機資源に分割して運用する仮想計算機技術

スクを利用している途中に読み出しあるいは書き込みも成熟してきており、今後物理計算機の台数をはるかのエラーが発生することがあり、継続した利用が困難に越える多数の仮想計算機を用いた計算機ネットワー

だった。iSCSI の機能の実装によるものか、sheepdog

クが構築されると考えられている。

クラスタとのインターフェースによるものか、明確な計算機をネットワークに接続する場合、これまでは切り分けができていない。

6.5

はじめに

計算機の速度は年々上昇を続けているものの、単一タの格納先ノードに一貫性が取れなくなるため、クラ2

IPv4-IPv6 トランスレータの評
価

7

corosync ライブラリ1 を利用している。原因は追求できていないが、運用中、一部のストレージノードのグルー
プメンバが、他のストレージノートと異なる状態が発IPv4 が利用されてきた。しかしながら、IPv4 アドレスの枯渇に伴い、IPv6 への移行が現実のものとなってまとめきている。ただし、IPv4 が枯渇した後も、それまでに分配された IPv4 アドレスが利用できなくなるわけで

WIDE クラウドでは、広域で利用できるストレージの仕組みを引き続き検討していく。sheepdog はそのひはなく、今後長期間に渡って IPv4/IPv6 のデュアルス
タック環境が運用されていくものと考えられている。

とつであるが、OpenStack で採用されている SWIFT4 、計算機資源のネットワーク設定を管理する場合、今分散ファイルシステムとして注目されている Glus-

後はデュアルスタックでの運用が必須となる。しかしterFS5 などについても、調査検討を進める予定である。

ながら、IPv4 と IPv6 は、そのアドレス空間の大きさの差を除いてほぼ同じ機能を提供しているにも関わら1 http://corosync.org/doku.php?id=welcome
2 http://zookeeper.apache.org/

ず相互に互換性がないため、運用者は類似したネット

3 http://www.osrg.net/accord/
4 http://openstack.org/projects/storage/

ワークプロトコルを二重に管理する必要がある。

5 http://www.gluster.org/

11

運用管理者としては、サービスに必要なバックエン

ロトコルを完全に把握しているため、三つの方式の中ドネットワークをシングルスタック運用しつつ、外にでは最も細かい制御が可能な仕組みとなる。反面、ア見える部分はデュアルスタックとして公開することで、プリケーションプロトコルが代理サーバーを経由して運用コストを抑えつつ、今後のインターネットの進化にも問題ないように設計されている必要がある。また、備えることができるのが理想である。本論文では、仮想

アプリケーション毎に代理サーバーの開発が必要にな

計算機資源を提供するシステム (IaaS、Infrastructure

るなどの短所がある。アプリケーションによっては残As A Service) を対象とし、そのバックエンドを IPv6

る二つの方式で対応可能な場合も多く、本方式は複雑のみによるシングルスタック運用としつつ、外部に公な中間処理を実現したい場合の特殊対応として利用す

開されるサービス部分を IPv4-IPv6 変換ソフトウェア

る場合が多い。

を用いてデュアルスタック化するシステムを提案する。

トランスポート層での中継では、IPv4 と IPv6 のIPv4-IPv6 変換ソフトウェアは特に新しい技術ではな
く、IPv6 が提案された初期から存在する。しかしなが境界に位置する中継サーバーが、socket レベルで接ら、一般的な変換ソフトウェアはひとつの IPv4 アド

しする。代表的な実装として SOCKS64[6] や Trans-

レスを複数の IPv6 ノードで共有することを前提としport Relay Translator[7] が挙げられる。SOCKS64 でており、アドレスの対応状態の管理、セッションの管は、SOCKS64 ライブラリを利用することによって、理などが複雑であり、また通信状態を保持管理しなけ
ればならないという特性上、スケーラビリティや耐障

DNS の名前解決とデータ送受信機能を差し替え、通信が SOCKS64 中継サーバーを経由するように調整

害性が問題となる。提案システムでは、対象を IaaS にされる。SOCKS64 ライブラリを新たにリンクする必

限定することによって、アドレス変換を一対多から一要があるという点で、クライアントの変更が必要にな

対一に制限している。これにより、現実的な IaaS サー

るという短所はあるものの、アプリケーション的にはビスを提供しつつ、既存の一対多 IPv4-IPv6 変換ソフ

SOCKS64 を意識せず、通常の通信手順を踏むだけで自動的に IPv4/IPv6 変換が行われる。Transport Re-

続を終端、再接続することで両プロトコル間を橋渡

トウェアが抱える問題を解決し、シングルスタックでのバックエンド運用を可能としている。

7.2

lay Translator の方は追加ライブラリを必要としない。
その代わり、IPv6 ノードが IPv4 ノードと通信する場
合には、宛先アドレスとして IPv6 アドレスの一部に関連技術

IPv4 アドレスが埋め込まれた特殊なアドレス空間を用いる。中継サーバーは、前述の特殊な IPv6 アドレ

IPv6 の仕様から IPv4 との後方互換性を省くというス空間宛ての接続を終端し、IPv6 アドレス中に埋め込

決断がなされた時点から、すでに両プロトコル間でのまれた IPv4 アドレスを抜き出す。その上で、抜き出相互接続問題を解決するための技術の検討は始まってされた IPv4 アドレス宛に、同じデータを再送信する。

いた。これらの技術は大きく三つにわけることができ

特殊な IPv6 アドレスは、通常は手動で計算することる。一つ目はアプリケーション層で IPv4 ノードと IPv6はなく、DNS64[8] のような、専用の DNS サーバーをノードの相互接続性を確保する方法、二つ目はトラン

運用することで対応する。

スポート層でデータを中継する方法、最後が IP 層でIP 層でのヘッダ変換は、IPv4 における NAT 技術と同等の技術である。この技術は nat64[9] として標準化

ヘッダ変換を行う方法である。
アプリケーション層での接続性の確保はアプリケー
ション毎に設計された代理サーバーを用いて実現する。

されている。この方式では、中継サーバーが通信を終IPv4 と IPv6 網の境界に代理サーバーを設置し、特定のアプリケーション (たとえばウェブサービスなど) の要求を受け付ける。代理サーバは受信した要求を解釈

ケットは、事前に定められたアドレス変換規則に則っ端する必要がない。中継サーバーに辿り着いた IP パて始点アドレスと終点アドレスが書き換えられる。また同時に IPv4 と IPv6 の間のヘッダ変換も行われる。

し、そこから新たに本来のサーバーへ向けた要求を作中継サーバーの機能がトランスポート層にあるのか、成し、適切な IP プロトコルで再送信する。要求に対IP 層にあるのかが異なるだけで、本質的には二つ目のする応答も、同様の手順で本来の要求元のクライアン

方法と技術的な差は存在しない。

トへ転送される。代理サーバーはアプリケーションプ

12

IPv4 サーバーに接続するときの問題を解決するために提案されたものである。運用的には、ひとつ、あるいIPv4/IPv6
変換ノード群は少数のグローバル IPv4 アドレスが中継サーバーに
前提とする
IaaS
システム

割り当てられており、多くの IPv6 ノードがそのアドレスを共有して IPv4 インターネットへの接続を確保する形態が想定されている。しかしながら、本論文でフロントエンド
ノード群

IPv4/IPv6

IPv4/IPv6
インターネットクに接続している IPv6 ノードがインターネット上の

IPv6-only

これらの技術は、IPv6 でのみ構成されたネットワー

バックエンドノード群

想定しているシステムは、IPv6 で構成されたサーバー
群に、IPv4 ノードがアクセスするものであり、想定された運用形態が異なっている。IPv6 サーバーを IPv4

図 13: 提案システム概要図

ノードに提供するため、グローバル IPv4 アドレスを共有することはできず、IPv6 サーバーアドレスとグ

すべての仮想計算機に IPv4 と IPv6 の両方を割り当て

ローバル IPv4 は一対一で対応づけられることになる。

ても構わないが、先に述べたように二重管理の問題が既存の技術でも、本論文で前提としている仕組みを実発生する。実際、サービスを利用するユーザーから見現することは理論的に可能であるものの、前提とするえるのは、フロントエンドに位置する一部の計算機だ

運用形態が異なるため、実際に運用できる実装は存在けであり、それらの計算機にデュアルスタックでアクしない。

セスできれば、それ以外の計算機がデュアルスタック

本論文では、IPv6 のみによる管理を前提とし、である必然性はない。サービス構築側も、内部のプロ

IPv4/IPv6 変換ソフトウェアを利用したデュアルス
タック IaaS サービスの設計を示し、それを実現する
IPv4/IPv6 変換ソフトウェアの設計および実装、またトコルがひとつであれば、ネットワーク設計が容易になると同時に、その上で動作させるサービスの開発やテスト工数が削減できる。

その性能評価を行う。

また、本提案では IPv4 と IPv6 を一対一で対応させることを前提としている。IPv4 アドレスを複数のシステムおよびソフトウェアの設計と実装

サーバーで共有しないため、その消費量については議本 節 で は 提 案 す る IaaS シ ス テ ム の 全 体 像 と 、を占有する必要があり、これまで通りのサービス内容

7.3

論の余地があると思われる。しかしながら、サーバーとして運用する場合は、いずれにせよ IPv4 アドレス

IPv4/IPv6 変換ソフトウェアの設計を述べる。

を維持するためには避けられない消費と言える。本提案では、アドレスの割り当てをフロントエンド計算機

7.3.1に制限することにより、無駄な消費を抑えることにし

IaaS システムの設計と実装ている。

本提案で対象としているのは、仮想計算機資源を提IaaS 内部ネットワークで利用するプロトコルについては、IPv4、IPv6 のどちらでも構わない。今回の実供する IaaS システムである。これは、複数の物理計算機で構成された資源プールから、仮想的な計算機資源装では将来的な IPv6 への移行を考慮して、IaaS 内部を切り出し、サービス運用の部品として利用する仕組

ネットワークは IPv6 ネットワークのみを使う構成とみである。サービスによって異なるが、ひとつのサーしている。

ビスは一般的には複数の仮想計算機を用いて構築され

図 13 に提案システムの概要を示す。フロンとエンドる。たとえば、ウェブのフロントエンド、ロードバラとなるノードには、実際には IPv4 アドレスは設定さ

ンサー、データベースなどである。あるいは、分散ス

れず、フロントエンドノードの IPv6 アドレスと、そ

トレージのようなサービスの場合は、より多くの仮想れに対応する IPv4 アドレスの情報が IPv4/IPv6 変換計算機がフロントエンドの裏側に配置されることも考ノード群で共有される。アドレス変換は一対一で行わえられる。デュアルスタックサービスを提供する場合、

13

IPv6 サーバーに対応する IPv4 アドレスは変換テーブルに保持されており、クライアントから入力された

IPv4/IPv6

インターネット

IPv4 パケットの終点アドレスに応じて適切な IPv6 終点アドレスへと変換される。IPv6 パケットの始点ア

WIDE
バックボーン
大阪
NOC

OSPF
経路制御

ドレスは、元の IPv4 パケットの始点アドレス情報を東京
NOC

保持する形で、IaaS 内で経路制御されている仮想プレ

IPv4/IPv6
変換ノード群

フィックスの下位 32 ビットに埋め込まれる。IPv4 のアドレス空間は、IaaS システム内ではすべてこの仮想

広域L2網
仮想計算機資源管理システム

プレフィックスに含まれることになる。サーバーから

フロントエンド/バックエンド
ノード群の応答パケットは、上記と逆の手順で変換される。
実装は Linux や BSD で標準的に提供されている tun
仮想ネットワークデバイスを用いた。変換ノードは、

図 14: 提案システムの実構成ネットワーク図IPv6 サーバーに対応付けされている IPv4 アドレスの経路を IPv4 インターネットに広告し、そのアドレスれるので、各変換ノードが通信のセッション情報を保宛のパケットを一旦 tun ネットワークデバイスで受信する。受信されたパケットはユーザー空間でデバイス持する必要がなくなり、パケット単位で変換できる。

を開いている変換プログラムに読み込まれ、図 15 のそのため、変換ノードを複数配置することが容易とな手順に従って変換される。変換の結果生成された IPv6

り、トラフィック増加により変換ノードの負荷が向上

パケットは、再び tun ネットワークデバイスへ書き出した場合でも、変換ノードを追加するだけで対応可能

され、IPv6 サーバーへ配送される。逆方向も同様に、である。また、どこかの変換ノードに障害が発生した

変換ノードが仮想プレフィックスの経路情報を IaaS シ

場合でも、そのノードを切り離す事で他のノード群でステム内に広告し、すべての仮想プレフィックス宛のサービスを継続可能となる。図 14 は、我々が実際にパケットを tun ネットワークデバイスで受信、変換し、構築運用しているネットワーク図である。

元の IPv4 クライアントに再転送される。

最下層に位置する仮想計算機資源管理システムは最後に、本提案で用いる IPv4/IPv6 変換ソフトウェ

WIDE プロジェクトによって開発されている WIDE
Cloud Controller (WCC)[10] を利用している。WCC
は広域 L2 ネットワークを経由して東京と大阪間で接アの制限を述べる。本ソフトウェアは変換ノードでの状態を保持しない設計となっているため、変換のために状態保持が必要となる、フラグメントされた ICMP

続されており、それぞれの拠点に変換ノードを配置しと ICMPv6 間の変換はサポートされない。また、現在ている。変換ノードは OSPF 経路制御プロトコルを用いて、一対一対応された IPv4 アドレスの経路情報をのところ、ペイロード部に IPv4/IPv6 アドレスを含む

WIDE プロジェクトが運用する L3 ネットワークに広報している。これにより、東京あるいは大阪のどちら約であり、理論上は状態を保持しないまま変換可能でパケットの変換もサポートしない。後者は実装上の制ある。

かの変換サーバが消滅しても、適切に生き残ったサー

本 ソ フ ト ウェア は オ ー プ ン ソ ー ス ソ フ ト ウェア

バーにトラフィックが向かうようになっている。

7.3.2

map646 として公開 [1] されており、自由に利用可能である。

変換ソフトウェアの設計と実装

IaaS システム内は IPv6 のみで運用されているため、サーバーにはすべての通信が IPv6 で行われているよ

7.4

性能計測

本節では map646 の性能を評価する。

うに見える。IPv4 クライアントからのパケットは一旦
変換ノードで受信され、IPv6 に変換される。本ソフト
ウェアでの変換手順を図 15 に示す。

14

IPv4インターネット

提案IaaSシステム

IPv4
クライアント

IPv6
サーバー

変換ノード
IPv4パケット

IPv6パケット

始点: クライアントIPv4
終点: サーバーIPv4

始点: 仮想プレフィックス::クライアントIPv4
終点: サーバーIPv6

参照

サーバーIPv4 <=> サーバーIPv6
変換テーブル

図 15: IPv4/IPv6 変換手順

表 4: 性能評価実験環境: 使用計算機
CPU
Core2 Duo 3.16GHz

Memory4GB

OSLinux 2.6.32

Network Interface

Intel 82573L
Realtek RTL-8169

7.4.1

構成1 : map646

IPv4
クライアント

構成2 : v4 only

IPv4
クライアント

構成3 : v6 only

IPv6
クライアントv4
ネットワークv6
ネットワーク
変換ノード

v4
ネットワークv4
ネットワークルータ

v6
ネットワークv6
ネットワーク
ルータ

IPv6
サーバ

IPv4
サーバ

IPv6
サーバ

評価環境
図 16: 実験構成

性能評価実験は次の環境で行った。図 15 に示した、

IPv4 クライアント、変換ノード、IPv6 サーバで構成されるネットワークを実際に構築し、遅延時間の測定のために ping、クライアントサーバ間の帯域幅の測のみを使用した計測を構成 2、IPv6 ネットワークのみを使用した計測を構成 3 と呼ぶ。

ping、iperf の結果をそれぞれ図 17、図 18 に示す。
計測は全て 5 回ずつ行い図にはその平均値を示した。

定のために iperf を用いて変換ノード上の IPv4/IPv6
変換ソフトウェアの性能を計測した。3 台の端末の詳

図 17 の横軸はそれぞれの構成での結果を示し、縦細は表 4 の通りである。Network Interface の Realtek

軸は遅延時間である。構成 1 の遅延時間は 0.172ms、RTL-8169 は変換ノードの IaaS 側のインターフェイスにのみ使用した。それ以外は全て Intel 82573L を使用

構成 2 は 0.139ms、構成 3 は 0.14ms となった。
図 18 の横軸はそれぞれの構成での結果を示し、縦した。

軸は帯域幅である。構成 1 の帯域幅は 572.4Mbps、構

iperf では通信プロトコルとして TCP を使用した。

成 2 は 593.4Mbps、構成 3 は 584.2Mbps となった。

比較対象として変換ソフトウェアを用いず変換ノード
をルータとして扱い、クライアントと変換ノード間のネットワーク、変換ノードとサーバ間のネットワーク

7.4.2

を共に IPv4 ネットワークのみにした場合と IPv6 ネッ類似技術との性能比較

次に類似技術として nat64[9] を用いて、map646 とトワークのみにした場合でも計測を行った。それぞれの性能比較を行った。nat64 は IPv6 ネットワーク内にの実験の構成を図 16 にまとめた。以降この図に従いあるクライアントが変換ノードを通して IPv4 ネット

map646 を使用した計測を構成 1、IPv4 ネットワーク
15

図 17: ping による遅延時間の測定

図 19: nat64 との比較: ping による遅延時間の測定

図 18: iperf による帯域幅の測定

図 20: nat64 との比較: iperf による帯域幅の測定

ワーク内にあるサーバにアクセスするための技術で、行った。ping、iperf の結果をそれぞれ図 19、図 20 にクライアントは IPv6 サービスプレフィックスである示す。

64:ff9b::の下位 32 ビットにアクセスしたい IPv4 アド
レスを埋め込み変換ノードへパケットを渡す。変換ノー

図 19 の横軸は map646 での変換を行った場合、nat64を使用した場合の結果を示し、縦軸は遅延時間である。

ドでの IPv6 パケットから IPv4 パケットへの変換は、

map646 を使用した際の遅延時間は 0.172ms、nat64 をセッション情報の管理とポート変換によって行われる

使用した場合は 0.156ms となった。

ため、変換に必要な IPv4 アドレスは一つだけで済む。

図 20 の横軸は map646 での変換を行った場合、nat64

今回の比較実験では nat64 の実装として Ecdysis[11]を使用した場合の結果を示し、縦軸は帯域幅である。

を使用した。Ecdysis は nat64 のオープンソースの実

map646 を使用した際の帯域幅は 582.4Mbps、nat64を使用した場合は 706.4Mbps となった。

装で、Fedora をベースにパッケージ化された LiveCDが配布されている。Fedora 内で nat64 はカーネルモ
ジュールとして組み込まれている。

nat64 での想定利用環境に合わせ、IaaS システム内
を IPv4 ネットワーク、IaaS システムの外を IPv6 ネッ

7.4.3

実ネットワークでの性能計測

最後に 7.4.1 章で行ったものと同様の計測を WIDE

トワークとして 7.4.1 章で行ったものと同様の計測をプロジェクトが運用する WIDE Cloud 内で行った。比16

図 22: 実ネットワークでの性能計測: iperf による帯域

図 21: 実ネットワークでの性能計測: ping による遅延

幅の測定

時間の測定

ルから変換ハッシュテーブルを作成し、tun インター

表 5: 実ネットワーク環境: 使用計算機
CPU
Xeon 2.33GHz * 2

Memory4GB

OSLinux 2.6.26

Network Interface

Broadcom NetXtreme II

フェイスに到着したパケットの宛先アドレスをキーとして変換ハッシュテーブルから変換先のアドレスを取得するように実装してある。今回コンフィギュレーショ
ンファイルに記述してある変換対は実験環境では実験に用いた 1 組、実ネットワークとして利用した WIDE

Cloud では約 30 組であったためハッシュテーブルの検索には大した時間はかからず、得られた時間コストの較対象として変換ソフトウェアを用いず IPv6 ネット
ワークのみを利用した場合での計測も行った。WIDE

大半は IP ヘッダの変換に費やされていると考えられCloud は実運用されている IaaS であるため、アドレスの付け替えが必要になる IPv4 での検証は行えなかっの時間コストへの影響の調査は今後の課題とする。

る。ハッシュテーブルに格納する変換対が増えたとき
次に 7.4.1 節の実験では map646 を使用した際の帯た。ping と iperf の結果をそれぞれ図 21、図 22 に示域幅の減少は 4%に留まっているが、実ネットワークをす。図 21 の横軸は map646 での変換を行った場合、用いた 7.4.3 節では帯域幅の減少が 34%にまで広がっ

IPv6 ネットワークのみの場合を示し、縦軸は遅延時間てしまっている。7.4.1 節と 7.4.3 節での IPv6 ネット

である。map646 を使用した際の遅延時間は 0.152ms、ワークのみを使用したときの結果を示す図 18 と図 22

IPv6 ネットワークのみを利用した場合は 0.104ms とを比較すると、7.4.3 節では 7.4.1 節の約 1.6 倍の帯域なった。図 22 の横軸は map646 での変換を行った場幅が得られている。この差は各環境で使用した PC の合、IPv6 ネットワークのみの場合を示し、縦軸は帯域幅である。map646 を使用した際の帯域幅は 617Mbps、

NIC の性能差と考えられ、7.4.1 節で map646 を使用

IPv6 ネットワークのみを利用した場合は 927Mbps となった。WIDE Cloud 内で変換ソフトウェアが稼動し帯域幅のボトルネックとなっていたからと考えられる。

した際の帯域幅の減少が小さかったのは NIC の性能が最後に 7.4.2 節の計測により、類似技術である nat64ているサーバのスペックを表 5 に示す。

7.4.4に比べ map646 は帯域幅では 18%、遅延時間では0.016ms パフォーマンスが劣ることがわかった。これは考察

map646 がユーザ空間で動くプロセスとして実装されているのに対し、今回使用した nat64 は Linux のカー
ネルモジュールとして実装されてためと考えられる。

7.4.1 節と 7.4.3 節の遅延時間の計測より、map646を使用する際の時間コストは 0.03-0.05ms とわかった。
変換ソフトウェアではコンフィギュレーションファイ

17

7.5

結論

LISP を用いたネットワークマイ
グレーション8

仮想化技術の進歩により、より多くのサーバーを運用されるようになりつつある。今後 IPv4/IPv6 のデュ

3 で説明した VPN を用いたサーバ間で接続するコスアルスタックインターネットが普及していくことが予想

トを抑制するため、NEPL とは異なるアプローチとしされ、サーバー側も両プロトコルに対応する必要があて LISP(Locator ID Separation Protocol)[3] を用いた

るものの、運用コストを考えると通信プロトコルはひVM のネットワーク移動透過性提供手法を展開した。
LISP を用いることで各 VM への到達性をホストルー

とつに集約できた方が望ましい。本提案では、サービス
バックエンドの構築を IPv6 のみのシングルスタックでトと似た形で 1 対 1 のマッピングをおこない、L2 を拡実現し、利用者に公開するポイントのみを IPv4/IPv6

張する VPN に対する依存性から解放されることを目

変換機構を用いてデュアルスタック化する IaaS シス指す。

テムを提案し、そのために必要な IPv4/IPv6 変換ソフトウェアの設計、実装、評価を行った。IPv4 アドレ
スと IPv6 サーバーの対応を一対一に限定することに

8.1

より、変換ソフトウェアが保持すべき状態をなくし、

LISP(Locator ID Separation Protocol) は現状のグ負荷状況に応じて柔軟に変換ノードを増減でき、またローバルインターネットにおける BGP 経路数抑制

ひとつの変換ノードに障害が発生しても、自動的に他を目的として、IP アドレスが示す 2 つの識別子であの変換ノードがサービスを継続できるスケーラブルかる Routing Location(RLoc) と Endpoint ID(EID) をつ耐障害性の高いシステムが実現できた。変換ソフト

異なる識別子としてとりあつかうプロトコルである。

ウェアの実装は tun 仮想ネットワークデバイスを用い

RLoc と EID は通常の IP アドレスによって表現されてユーザー空間プログラムで実現されている。カーネ

る。LISP は既存のインターネット上に ETR(Egress

ルモジュールとして実装されている変換ソフトウェア

Tunnel Router)、ITR(Ingress Tunnel Router)、Mapと比較した結果、34%の性能低下が認められたため、Server(MS)、Map Resolver(MR) を追加することによって構成されるミドルボックスソリューションである。
LISP では通常 XTR(ETR と ITR の総称) 配下に EID

今後は高速化を目指す改良を進め、ネットワークの本
来の性能を生かしきるような改良を進めていく。

7.6

LISP 概要

Prefix を展開し、IP アドレスとして EID が割り当てられた End Point が設置される。

今後の課題

性能をより向上されるために map646 をカーネルモ
ジュールとして実装していく。またハッシュテーブル

8.1.1に格納する変換対が増えたときのパフォーマンスへのLISP のデータプレーン

ITR が End Point の送信したパケットの宛先 IP ア
ドレスをキーとして MR に対して検索をかけ (Map-

影響を調査していく。また今回は TCP での性能評価
しか行わなかったが、UDP を使用した際の評価、ウェRequest)、MR からの返答である (Map-Reply) によって宛先 EID に対応する RLoc を学習する。ITR は End

ブサーバへのアクセスなど実アプリケーションを使用した際の評価も行っていく。さらに変換ノードを通過

Point から受け取ったパケットを送信元 IP アドレスを
ITR、宛先 IP アドレスを RLoc アドレスとし、LISP
パケットとしてカプセル化して送信する。

するパケットの統計的な情報を得たいという IaaS の管理面からの要求に応えるための機能を map646 上に実装し、さらに運用が容易な IaaS システムの実現を

ETR は受信した LISP パケットのカプセル化を解除
し、通常の IP 経路表上でダイレクトコネクトされてい目指したい。

る収容 EID Prefix のエントリに対してパケットを転送する。なお、一度検索された EID に対応する RLoc には TTL がセットされており、パケットカプセル化とパケット転送の対応表にキャッシュされる。また、ITR 上

18

で Map-Request をおこなった結果 EID に対する RLoc

8.3

が存在しない場合、LISP 以外のネットワーク (通常はグローバルインターネット) との通信と定義し、ITR は

LISP は通信の種別として大きく分けて、1)LISP サ

通常の IP 経路制御によって構築された経路表を参照しイトから LISP サイトへの通信、2) グローバルインターてパケット転送をおこなう。グローバルインターネッ

ネットから LISP サイトへの通信、3)LISP サイトから

トから LISP サイトへの通信は、PXTR(Proxy XTR)

グローバルインターネットへの通信の 3 種類がある。

が通常の IP 経路制御によって EID Prefix を広告する

この中で EID を持つ End Point が移動することで問題ことでトラフィックを引き寄せ、PXTR を ITR としたになるのが、LISP サイトから LISP サイトへの通信で

LISP 通信を EID に対しておこなう。

8.1.2

分散クラウド環境における LISP の問
題点ある。LISP サイトから LISP サイトへ通信をする際、送信元 End Point を収容する ITR は Map-Request に

LISP のコントロールプレーン

よって通信先の LISP サイトの EID を収容する ETRが持つ RLoc を検索し、検索結果を Map Cache として

XTR は収容している EID Prefix と ETR 自身が持つ
RLoc を Map 情報として MS に対して登録する (Map-

保持しパケット転送テーブルにキャッシュする。そのため、通信相手である End Point が移動した場合、Map

Regist)。MS は BGP によって Map-Regist された EIDと RLoc のマッピング情報を他の MS と MR に対して広告する。ITR は End Point から受信したパケットの情報に対する TTL がタイムアウトするまでキャッシュ
不整合がおこる問題がある。現在 IETF で議論されている LISP の Internet Draft では EID と RLoc の Map

宛先 IP アドレスに基づいて MR に Map-Request を

情報の TTL は分単位で規定されているため、キャッ

おこない、MR は BGP により通知された EID を持シュ不整合によって VM の拠点移動によって長時間のつ MS に対して Map-Request を転送する。この BGP

通信断が発生する。

によって構築されたネットワークを ALT(Alternative

LISP Topology) と呼ぶ。Map-Request を受信した MSは、Map-Request を該当する ETR に対して転送し、8.4

ETR は検索をおこなった ITR に対して Map 情報を
Map-Reply として返答することで、ITR は EID に対する RLoc を学習する。

LISP を用いた分散クラウドアーキテ
クチャの提案

本研究では分散クラウド環境において、VM のライ
ブマイグレーションによる Map 情報のキャッシュ不整8.2

合を解決するアーキテクチャを提案する。この問題を分散クラウド環境における LISP の位置づけ解決するため、本研究では CP(Content Provider) が管理するネットワークにおいて、LISP ネットワーク

本研究で提案する分散クラウド環境における要素をとグローバルインターネットからのトラフィック着信

LISP に対応させた場合、VM は EID を IP アドレスとして割り当てられる End Point である。また、VM のLISP ネットワーク内に限定した VM の EID と RLocに対するアンカーとして代表 ETR を定義し、CP の

デフォルトルータは XTR となり、IaaS 事業者の Localを管理する Map Server を定義した。

Network から XTR に割り当てられた IP アドレスがRLoc となる。本研究で提案する分散クラウド環境でクアーキテクチャと VM マイグレーション時のプロシー

図 23 に代表 ETR(図中 D-ETR) を用いたネットワー
ジャを示す。代表 ETR は LISP ネットワークとグロー

は、VM がライブマイグレーションによって異なる拠

バルインターネットに対し CP が委譲するネットワー

点へ移動する。また、VM 単体にネットワークの移動

ク Prefix を集約して広告し、LISP サイトとインター透過性を確保する技術を要求しないため、全体のアーネットからのトラフィックを代表 ETR に引き寄せる。

キテクチャとしてネットワークによる移動支援型のレ

そのため、LISP ネットワークからは CP に割り当て

イヤ 3 モビリティ技術であると言える。

られた EID Prefix は集約経路のみが存在する。これにより他の LISP サイトの XTR が CP の持つ EID に対

19

する RLoc を解決した場合、必ず代表 ETR の IP アド

CP&AS&


レスを通知されるため、実際に VM が収容されている

Local&MS&

XTR の RLoc を解決する必要が無く、キャッシュの不整合を回避する。

CN&

ISP&

D+ETR&

Transit+1&      
       
  

VM のマイグレーションは Local MS に対して CloudController から通知され、代表 ETR は各 VM のホス
ト単位で記述された EID と RLoc の Map 情報を持つ

LISP&Network&
Internet&

XTR&



Transit+2&

Local MS と BGP peer を確立し、VM の移動に追従した最新の Map 情報を BGP Update によってプッシュ

MS&

Transit+3&
Cloud&XTR&

Cloud&XTR&

CSP+EID&
Preﬁx&

型通知される。その手順は以下の通りである。

Cloud&Controller

VM

1. VM のライブマイグレーションは IaaS 事業者がVM を管理・運用する Cloud Controller が VMM

Hypervisor
Cloud&Provider+base+A

に対してシグナリングによって開始される。

& END&
Point&&
LISP&Site&

CSP+EID&
Preﬁx&

VM
Hypervisor
Cloud&Provider+base+B

図 23: LISP を用いた分散クラウド環境のアーキテクチャ

2. VM は拠点 A から拠点 B へライブマイグレーショ
ンされる。

イグレーションに伴う EID-RLoc Mapping 情報の変3. Cloud Controller は VM のライブマイグレーションと連動して MS に Map-Regist によって通知を更と BGP によるプッシュ型通知を利用した実験をおこなっている。

おこない、MS に対して常に VM の EID と RLoc

また、本研究グループでは Linux 上における XTR とMS の実装がほぼ完了させた。そのため今後の課題との最新 Map 情報を提供する。

4. MS は代表 ETR に対して BGP peer を確立し、Cloud Controller から受け取った Map-Regist 情
報を BGP Update によってプッシュ型通知をおしてはこれらの実装を WIDE クラウド上の各ハイパー
バイザー上に展開し、WCC との連携インターフェー
スを持つことで、WIDE クラウドの全利用者に対してこなう。

適用可能な環境を整えていく予定である。

これらの手順を経て、LISP ネットワークもしくはグローバルインターネットより代表 ETR に配送されたト9

ラフィックは、代表 ETR 上にある最新の Map 情報を

WIDE クラウドワーキンググループでは、広域連邦

基に EID に対応する RLoc に対してパケットを LISP

型クラウド運用におけるネットワーク資源の透過的なパケットとしてカプセル化して適切な XTR へと転送利用を実現するための要求事項とその実装例を検討し

される。

8.5

IETF の活動ている。検討した内容はインターネットドラフトとしてまとめられ [13]、IETF に提出されている。

現在の利用状況と今後の課題[13] では、ネットワーク資源の透過的な運用に必要な要求事項として以下の点に注目した。

現 在 WIDE プ ロ ジェク ト で は LISP

Beta
Network[12] と 呼 ば れ る LISP の 普 及 を 目 的 と し• 異なるデータセンタであっても、同一のユーザにたプロジェクトに参加し、LISP Beta Network の仮想には同一のネットワーク資源を提供すること

AS(AS3943) が提供するアドレスブロックより IPv4

• ネットワーク資源が、あるデータセンタから別のデータセンタへ移動する際には統一した移動ポリと IPv6 の Prefix 委譲を受け、WIDE クラウド上の

LISP 実験網に展開している。現在 WIDE クラウドではこれらの Prefix から切り出された IP アドレスを利シが適用できること用して一部の VM が稼働している。また、VM のマ

20• ユーザに提供されるネットワーク資源は、サービス中断を避けるため、高可用性を有すること

広域での仮想計算機マイグレーション技術として、ストレージのマイグレーション技術の実証、分散型ストレージ技術の検証を実施した。広域マイグレーション

また、ネットワーク資源のデータセンタ間移動を実では、ストレージに加えてネットワークの透過性も必現する手法として、以下のふたつの移動モデルを提案要であり、こちらに関しては LISP 等の IP モビリティ

した。

を利用した透過的なネットワーク資源提供方法の研究、• ホストベース移動モデル

IPv4-IPv6 ヘッダトランスレータを用いたアドレス変換によるネットワーク透過性の提供技術の実証をおこ• ネットワークベース移動モデルなった。近年は IETF でも仮想計算機の管理に関するホストベースの移動モデルでは、ユーザが利用している話題が注目されており、WIDE クラウドワーキンググ

仮想計算機自身がネットワーク移動のための機能を持

ループでも、実験環境での運用経験を踏まえた要求事

ち、ネットワークベースの移動モデルではデータセンタ

項を提案している段階である。今後も、規模性にすぐ

ネットワークがその機能を提供する。後者の場合、ユーれた広域分散環境でのクラウド運用を可能とする技術

ザの仮想計算機はネットワーク資源の移動に関与するの研究開発を継続していく。

必要がない。前者を実現する例としては、IP 層の経路制御を用いた方法、Mobile IP[14, 15] などの移動通信

参考文献

プロトコルを仮想計算機が有する方法などが挙げられる。後者を実現する方法は、広域 VLAN、vxlan[16] な[1] Keiichi

どを用いたデータリンク層での解決方法、NEMO[2]、

Shima

and

WataruIshida.

map646:Mapping between IPv6 andIPv4 and vice versa,
August 2011.

LISP[3] などを用いた IP 層での移動通信技術などが挙げられる。

https://github.com/keiichishima/map646/.

データセンタにおける資源透過性の話題は、近年のIETF でも盛んに議論されている。IETF ワーキンググ[2] Vijay Devarapalli, Ryuji Wakikawa, Alexandru
Petrescu, and Pascal Thubert. Network Mobil-

ループとしては、Layer 2 Virtual Private Networks、

Layer 3 Virtual Private Networks、Operations andManagement Area Working Group などに跨がる話題

ity (NEMO) Basic Support Protocol. IETF, January 2005. RFC3963.

となっており、また台湾の IETF82 以後、データセン[3] Dino Farinacci, Vince Fuller, Dave Meyer, andDarrel Lewis. Locator/ID Separation Protocol(LISP). IETF, December 2011. draft-ietf-lisp-

タ技術に関係する話題を取り扱う dc@ietf.org メー
リングリストも設置された。

WIDE クラウドワーキンググループでも、引き続き連邦型クラウド技術における資源透過性の議論を継続

17.

していく。

[4] Kazutaka Morita. Sheepdog, December 2011.
http://www.osrg.net/sheepdog/.

10

まとめ

[5] National Information of Information andCommunications Technology. Hokuriku Re-

WIDE クラウドワーキンググループでは、広域に広がる組織を前提とした、連邦型クラウドサービスのsearch Center (StarBED), December 2012.
http://www.starbed.org/.

運用技術を研究開発している。2010 年度に引き続き、[6] Hiroshi Kitamura. SOCKS-based IPv6/IPv4
Gateway Mechanism.
IETF, April 2001.
RFC3089.

WIDE クラウド管理ソフトウェアの開発、WIDE ク
ラウドネットワークの拡張を継続している。WIDE ク
ラウドサービスの応用として、夏の甲子園中継の映像
配信サービスのサービスホストとして、仮想計算機を用いた動的な負荷適応の実証実験を実施した。また、21

[7] Jun ichiro itojun Hagino and Kazu Yamamoto.
An IPv6-to-IPv4 Transport Relay Translator.
IETF, June 2001. RFC3142.
[8] Marcelo Bagnulo,

Andrew Sullivan,

PhilipMatthews, and Iljitsch van Beijnum. DNS64:
DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. IETF,
April 2011. RFC6147.
[9] Marcelo Bagnulo, Philip Matthews, and Iljitsch
van Beijnum. Stateful NAT64: Network Address
and Protocol Translation from IPv6 Clients to
IPv4 Servers. IETF, April 2011. RFC6146.
[10] WIDE project. WIDE Cloud Controller, August
2011. http://wcc.wide.ad.jp/.
[11] Viagénie.
Ecdysis: open-source implementation of a NAT64 gateway, August 2011.
http://ecdysis.viagenie.ca/.
[12] LISP Beta Network Project. LISP Beta Network
Project. http://www.lisp4.net/beta-network.
[13] Keiichi Shima, Yuji Sekiya, and Katsuhiro
Horiba. Network Portability Requirements andModels for Cloud Environment. IETF, October 2011. draft-shima-clouds-net-portabilityreqs-and-models-01.
[14] Basavaraj Patil, Phil Roberts, and Charles E.
Perkins. IP Mobility Support for IPv4. IETF,
August 2002. RFC3344.
[15] David B. Johnson, Charles E. Perkins, and Jari
Arkko. Mobility Support in IPv6. IETF, June
2004. RFC3775 (Obsoleted by RFC6275).
[16] Mallik Mahalingam, Dinesh G. Dutt, Kenneth Duda, Puneet Agarwal, Lawrence Kreeger,
T. Sridhar, Mike Bursell, and Chris Wright.
VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks.
IETF, August 2011. draft-mahalingam-duttdcops-vxlan-00.

22