StarBED を用いた大規模ネットワークにおける分散システム検証
原井 洋明 (harai@nict.go.jp)
情報通信研究機構
光ネットワーク研究所 ネットワークアーキテクチャ研究室長
実験実施者：藤川賢治 、戸室知二、田崎創、大西真晶、森岡和行、福島裕介

2015年10月20日
新世代ネットワーク推進フォーラム
第22回テストベッドネットワーク推進WG© National Institute of Information and Communications Technology

StarBEDといえば、、、。
• プロジェクトでは纏まった数のサーバ調達が困難• 1000台を超える実機を用いて検証ができる• 発表者の研究室スタッフの充実に伴ない、使わせて戴くことにした
数学的検証
方式
検討
シミュレーショ
ン検証

大規模検証

ソフトウェアハードウェア
開発

実験室
小規模検証

© National Institute of Information and Communications Technology

テストベッド検証

大規模エミュレーション
検証2利用したStarBEDサーバ
グループ名

PCサーバの型式

設置数 導入年

利用数

Ｆ

NEC Express5800 110Rg-1 168

2006

Ｇ

Proside Amazelast neo920

1502007Ｈ

HP ProLiant DL320 G5p

240

2009

Ｉ

Cisco UCS C200 M2192

2011

Ｊ

Cisco UCS C200 M282*

2011

10Ｋ

Cisco UCS C200 M2144

2011

10Ｌ

Cisco UCS C200 M2120

2011 100 60 100

M

Cisco UCS C200 M214

2011

N

DELL PowerEdge C6220

224

2013

O

SeaMicro SM15000-XE

642013© National Institute of Information and Communications TechnologyHAR

HI

80
60
20

103

講演の内容• 研究の方向性と内容• StarBED3をさまざまな分散システムの検証に• 階層型自動番号割当 HANA
• インターネット規模でサーバ協調によりアドレス空間を配布• 局所情報を用いた分散経路制御• リンク・ノードのjoin/leaveが時々刻々と変動する環境で全域情報の把握に頼らず到達性を求める• ID・ロケータ分離機構 HIMALIS• 故障時の経路切替検証

何度もStarBED を利用させていただき、改めて、この場をお借りして御礼申し上げます© National Institute of Information and Communications Technology

4

将来ネットワーク ITU-T勧告Y.3001• 4つの目的• 12個の設計目標

Rec ITU-T Y.3001, Future Networks: Objectives and Design Goals© National Institute of Information and Communications Technology

5ネットワークアーキテクチャ研究室
研究開発ターゲット
Service Diversity
Functional Flexibility
Energy Consumption

Network Management
Reliability

Data Access
Mobility(局所情報による経路制御)

Data Access
Identification
Mobility
Reliability and Security

2020年の未来社会を支えるネットワークをつくります© National Institute of Information and Communications Technology

6ネットワーク設定が煩わしい．．．
ネットワーク構築がメンドーでしょ？

保全対策

安全対策

冗長化

接続ポート
タグ付け

IP アドレス割当

VLAN割当ネットワーク
更改
ネットワーク増設© National Institute of Information and Communications Technology

大規模ネットワーク構築で設定ミスしたらたいへんですね・・・
確認、確認、指差し確認

収容SW
ポート番号 サーバホスト名
HRKc302pf400100 0/1
HRKc302kssv0100
0/2
HRKc302kssv0200
0/3
HRKc302kssv0300
0/4
HRKc302kssv0400
0/5
HRKc302kssv0500
0/6
HRKc302kssv0600
0/7
HRKc302kssv0700
0/8
HRKc302kssv0800
ホスト名
IP
GW IP
0/9
HRKc302kssv0900
HRKc104krsv0100
10.192.127.20 10.192.1
HRKc302kssv1000
HRKc104krsv01010/10 10.192.127.1
10.192.1
HRKc104krsv01020/11 10.192.127.2
10.192.1
HRKc302kssv1100
HRKc104krsv01030/12 10.192.127.3
10.192.1
HRKc302kssv1200
HRKc104krsv01040/13 10.192.127.4
10.192.1
HRKc302kssv1300
HRKc104krsv01050/14 10.192.127.5
10.192.1
HRKc302kssv1400
HRKc104krsv0106
10.192.127.6
10.192.1
HRKc303pf400100 0/1
HRKc303kssv0100
HRKc104krsv0107
10.192.127.7
10.192.1
0/2
HRKc303kssv0200
HRKc104krsv0108
10.192.127.8
10.192.1
HRKc303kssv0300
HRKc104krsv01090/3 10.192.127.9
10.192.1
消費者向けサービス事業で、総務省に報告さHRKc303kssv0400
HRKc104krsv01ma0/4 10.192.127.17
10.192.1
0/5HRKc303kssv0500
KHNcd02krsv0100
10.194.127.20 10.194.1
れる規模の事故で人為要因は2013年133件
HRKc303kssv0600
KHNcd02krsv01010/6 10.194.127.1
10.194.1（全体の2%）
KHNcd02krsv01020/7 10.194.127.2
10.194.1
HRKc303kssv0700
KHNcd02krsv01030/8 10.194.127.3
10.194.1
HRKc303kssv0800
7
KHNcd02krsv01040/9 10.194.127.4
10.194.1
HRKc303kssv0900

階層型自動番号割当 [HANA]
人手をかけず稼働率の高いネットワークを構築する技術

ロケータ上位部
ロケータ上位部特長• 同時複数経路で耐障害性向上• 自動割当で管理者負担軽減

 ZebOS AX-OS

複数のロケータ上位部と組合せ、ロケータを割当

ロケータ下位部はネット内部で割当

PC千台の網で番号設定負担 1/100

ネットワーク検証実績• アドレス更新も簡単• JGN-Xにネットワーク構築、動作検証• IPv4でも、もちろんIPv6でも• 46,000ネットワークでの動作検証• 小さな経路表で網安定と• SDNとの連携• 耐災害の観点からの検証
省エネ© National Institute of Information and Communications Technology-8-仙台

StarBED3におけるHANA検証 (2011年)
Emulation on StarBED3• 10,000 AS エミュレーション• Debian GNU/Linux 6.0の LXC に実装 Group H 80 nodes (HP ProLiant DL320)

Group L 100 nodes (Cisco UCS C200 M2)

Locator Assign Visualization

Setup Time

Control Overhead（10K AS）

ASごと2.5kbps© National Institute of Information and Communications TechnologyK. Fujikawa, H. Tazaki, H. Harai, SAINT2012

9

HANAを、北陸StarBED技術センターの皆様に宣伝いただきました。御礼申し上げます。
「これが世界最大規模のテストベッドの全貌だ：潜入！ 北陸StarBED技術センター」
IT Media Inc 記事 ＠IT Master of IP Network (2013.3.26)

記事によると「すでに1万ASでの検証は完了し、今は3万6000ASでの大規模検証が行われている」とのこと。。。
発表文献をくださいと聞かれる．．．
やるにはやったんですが、発表はStarBEDのこの会までとっておきました

そうこうしてる間に見えるAS が4万6000に増えてましたが。。。
© National Institute of Information and Communications Technology

10

HANAのインターネット規模性検証（2012～）• 実インターネットAS規模の46,000ノードでHANAを稼動• ノード間でのアドレス空間割当動作を検証• IPv4およびIPv6アドレス体系ともに検証 最下位ASへのアドレス空間割当• 制御量はAS平均10kbps
HANA 実験の構造(CAIDAの実測データベースより作成)

最上位 AS数821

中間 AS数6,234

最下位 AS数39,122

合計 AS 数

46,177

親を沢山もつASの親数

44

子を沢山もつASの子数

4,275

BGPで利用するリンク数

177,397

HANAで利用するリンク数

81,661© National Institute of Information and Communications Technology

機器毎のHANA
制御メッセージ量

平均値：ASごと10kbps
リンクごと6kbps

StarBED3 で利用した10 機の物理サーバの諸元
 CPU Intel Xeon E5 2650 (2.00GHz 8 core ) x 2
 Memory 128 GB (DDR3-1333)

Simulation Example (1) Initial Status
Each administrator of toplevel ASes assigns
address space

AS1: 1/8© National Institute of Information and Communications TechnologyAS2: 2/8

Simulation Example (2) TCP connection

TCP connection
established© National Institute of Information and Communications Technology

Simulation Example (3) Midfix allocation

M:0.1/8-16

M:0.1/8-16© National Institute of Information and Communications Technology

M:0.2/8-16

Simulation Example (4) Prefix distribution

P:2/8
P:1/8
P:2/8

© National Institute of Information and Communications Technology

Simulation Example (5) TCP connection

TCP
connection
TCP connection
establishedestablished© National Institute of Information and Communications Technology

Simulation Example (6) Midfix allocation

M:0.0.2/16-24
M:0.0.1/16-24

M:0.0.1/16-24
M:0.0.2/16-24© National Institute of Information and Communications Technology

Simulation Example (7) Prefix distribution

P:1.1/16
P:2.1/16

P:2.2/16

P:2.2/16
P:1.1/16© National Institute of Information and Communications Technology

Simulation Example (8) Prefix is changed

Administrator
changes prefixfrom 1/8 to 3/8.

© National Institute of Information and Communications Technology

Simulation Example (9) Changed prefix
distribution

P:3/8

P:3.2/16
P:3.1/16© National Institute of Information and Communications Technology

HANAのインターネット規模性検証（可視化）
全体へのドレス空間割当

最下位ASへのアドレス空間割当© National Institute of Information and Communications Technology

StarBED利用者向けネットワークをHANAで構築• 階層的なIPネットワークをStarBEDで簡単に構築できるようになりました
HANAがアドレスを自動設定。
• 実験の自由度が広がりますL2スイッチは物理ノードの個数分(10～200個)のMACアドレスを学習

L2SW

172.16.1.0/24
VM
HANA
RouterVM

TOP HANA
Router

外部接続時にリナンバリングやマルチホーム構成も容易。
(VMの一つにより実装)

172.16.2.0/24
VM
HANA
Router

VM

VM

VM

172.16.10.0/24
VM

HANA
Router

VM

VM

20VMs
物理ノード10台（200台まで拡張可能）。VMは計200台(計4,000台)
従来までのフラットな構成
L2スイッチは、最大4,000個のMACアドレス学習が必要。障害切分けも困難

L2SW

DHCP
Server

DHCPサーバもしくはネットワーク管理者がアドレスを設定

172.16.0.0/16

VM

VM

VM

VM

© National Institute of Information and Communications Technology

VM

VM

VM

VM

VM

局所情報を用いた分散経路制御
ドロネーオーバレイ迂回ルーティングCf) M. Ohnishi, H. Harai, APSITT 2015.

• 災害時等トポロジーが変動する• ネットワークの全体トポロジを把握せずに経路表を構築• 全方位の近隣ノードに対してのみ経路表を作成• 位置座標に基づいてデータを目的地に近い方向へ転送• 近隣だが転送の仕組み上、到達不能の場所がある• 近隣だが物理制約上、到達不能の場所がある• 迂回経路を作る => 局所の情報で作る• JAVA VM を用いた実装の2,500ノード検証
Cisco UCS C200 M2 を最大125機
 CPU Intel Xeon X5670 (2.93GHz 6 core ) x 2
 Memory 48 GB© National Institute of Information and Communications Technology23

ID通信機構 HIMALIS のホスト2000台
規模ネットワーク構築• IPアドレスに依存しない通信、モビリティ、マルチホーム、認証、故障回復• 通信障害検知・回復等のゲートウェイ間連携、レジストリ間連携など分散シ
path failure detection
ステムの検証・評価
link failure injectedTransit Network3rd PT expired (failure detected)
recovery complete
2400
2200

Send (ID layer)

HNR1
RT1

RT2

4-hop 平均
RTT 706 µs

2000

HG1-2 HG2-1

IPv4

1200

HG2-2 HG3-1

Edge Network1
MHAAR2
Edge Network2

HG3-2

AAR3
Edge Network3

18

20

22Time (s)24

3rd PT expired
failure detected
1682

IPv4
LNS2

1000
16IPv6
LNS1

1400

Recv (Dump)

2-hop 平均X RTT283 µs
HG1-1

1600

received datagrams
Send (Dump)

RT4

RT3

1800

Recv (ID layer)

26

location update for CH

1680

LNS3

packet redirection

1678
1676

switch from HG1-2 to HG1X800

28CH

received datagrams

1674
23.15

23.2

23.25

23.3

Time (s)lively path exploration
・・・

100 nodes

モバイルホスト
20VMs/node

ホスト2,000台規模検証環境© National Institute of Information and Communications Technologypath recoveryCf) Y. Fukushima et al., ICUFN 2014.
Cisco UCS C200 M2 (グループ K, L)
 CPU Intel Xeon X5670 (2.93GHz 6 core ) x 2
 Memory 48 GB, 6 GbE NICs

24

Packet ID

DNR

Packet ID

IPv4

AAR1

2nd PT expired

1st PT expired

HIMALISシグナリングストームの検出・改善
Transit Network

ホスト2千台のID・ロケータ情報
登録・検索mh1

1

1.5

2

1.5

locator
host2

allocation2.5

2.5

Time[s](DHCP)

authentication

3

3.5

3

host

3.5

registration

locationupdate

ホスト1台のときのネットワーク接続時間 (秒)

HNR

ホスト認証の負荷増大により、接続シーケンスタイムアウト・再接続多発

100

HG

HG

名前解決
アクセス制御

ノード番号

位置情報
更新

80
60

発表者都合により非公開

40
20

認証サーバ

ネームレゾルバ
ロケータ割振り
ホスト認証

0

10

20

30

locator allocation(DHCP)(DHCP)
ロケータ割振りhost authentication
ホスト認証

40

50
Time [s]

60

70

80

90

100

host registration
ローカルホスト登録
location update
位置情報更新ホスト100台のネットワーク接続 (2014年4月時点)
Edge Network

HIMALISの認証付き制御プレーン© National Institute of Information and Communications Technology

 認証サーバ、ネームレゾルバの負荷増大による接続シーケンスの爆発 (ストーム) を検出=> ソフトウェアの改善策導出 ホスト1,000台の接続を確認 (2015年現在)

25

StarBED3 利用 Tips (2013年12月)•

ノード操作がより簡単に、ディスク読み書込み速度が改善•••

100台使用すると数台は同じ作業を行っても結構な割合で不具合あると感じる••

理由は色々：ディスク障害、メモリ障害、NIC、BIOS設定不備など）。

利用要望書は早め提出、時間が足りない時は延長申請可••

今年度操作スクリプト一新、350GBのディスクコピーが2時間程度
以前は、信用のおける定量データがないので感覚で、割当てマシンスペックに大きく依存と思いますが、2011年ごろのマシンでは終夜ディスクコピーしてた（250GB以上と思います）。

来月の利用申請は毎月15日、2013年度現在の利用要望は300%超

KVMコンソールが応答しない、昨日できたことができないとき•

StarBED側の問題である可能性大、すぐに連絡、あまり頑張らない

一部非公開© National Institute of Information and Communications Technology

26まとめ• 分散システムの大規模検証• 階層型自動番号割当 HANA
• 局所情報経路制御• ID・ロケータ分離 HIMALIS• レイヤ3のネットワークを組む際のアドレッシングが煩わしい方、ご相談ください• 新世代ネットワークの研究開発に大規模なサーバ群を用いた検証は不可欠• 動作実績
• 性能面でのバグ検出• 5G、IoT など数が必要な場面は登場している© National Institute of Information and Communications Technology27

関連文献
••
•

•

•

•

K. Fujikawa, H. Harai, and M. Ohta, “The Basic Procedures of Hierarchical AutomaticLocator Number Allocation Protocol HANA,” Proc. Asia Workshop on Future Internet
Technologies (AWFIT 2011), pp. 124--131, October 2011.
K. Fujikawa, H. Tazaki, H. Harai, “Inter-AS Locator Allocation of HierarchicalAutomatic Number Allocation in a 10,000-AS Network, ”Proc. SAINT 2012, July 2012.
M. Ohnishi, M. Inoue, and H. Harai, “Incremental distributed construction method ofDelaunay overlay network on detour overlay paths,” Journal of Information
Processing (JIP), Vol. 21, No. 2, February 2013.
M. Ohnishi and H. Harai, "Delaunay Overlay Network Construction Method forSuper-Wide Area Disaster Situations," APSITT 2015 (10th Asia-Pacific Symposium onInformation and Telecommunication Technologies), pp. 88—90, August 2015.
V. P. Kafle, R. Li, D. Inoue, H. Harai, "Design and Implementation of Security for
HIMALIS Architecture of Future Networks," IEICE Transactions on Information andSystem 2013, Vol. E96-D, No. 2, pp. 226--237, February 2013.
Y. Fukushima, V. P. Kafle, T. Tomuro, and H. Harai, “Implementation ofCommunication Path Recovery Mechanism in a Multihomed ID/Locator-split
Network,” The Sixth International Conference on Ubiquitous and Future Networks(ICUFN 2014), pp.322—327, July 2014.

© National Institute of Information and Communications Technology28