Comments
Description
Transcript
1 - CELF `tree`
HTTP-FUSE CLOOP with
Software RAID and DNSBalance for Embedded Linux
○金井 遵(1), 須崎有康(2), 八木豊志樹(2), 並木美太郎(1)
(1)東京農工大学，(2)産業技術総合研究所
2006/12/08 CELF Jamboree #12
発表の流れ
背景
HTTP-FUSE-KNOPPIXについて
目的
組込みモバイルシンクライアントサーバ
“HTTP-FUSE-KNOPPIX-BOX”
高速化の諸方式
耐故障性と負荷分散の諸方式
評価
組込み機器向け広域仮想ブロックデバイス
“HTTP-FUSE-cloop for Embedded Systems”
組込み向け最適化の内容
評価
まとめ
2006/12/08
CELF Jamboree #12
2
背景
近年，シンクライアントシステムが増加
シンクライアントとは，システムソフトウェアを含めた全て
の情報をネットワークで管理する方式
ソフトウェアやデータを集中管理可能
クライアントマシンにHDDやCDD等の可動部が必要なく信頼性
向上
従来のNFSベースのシンクライアントシステムでは，
サーバが大規模化、モバイル化（WAN対応）が難し
い
どこでもシンクライアントシステムを実現するHTTPFUSE-KNOPPIXが開発
2006/12/08
CELF Jamboree #12
3
HTTP-FUSE-KNOPPIX
CD/DVD起動Linux，KNOPPIXをベースとした
Linuxディストリビューション
ネットワークブロックデバイス“HTTP-FUSE-cloop”
ルートファイルシステムをHTTPを介してインターネット上
から取得
どこでもKNOPPIXが利用できる
HTTPは基本的にセッションレスなプロトコル(⇔NFS)
OS/ソフトウェア管理のコストが小さい
HTTPサーバ上の一次データの更新のみでよい
シンクライアントシステムが実現可能
2006/12/08
CELF Jamboree #12
4
HTTP-FUSE-cloop
効率的なネットワークブロックデバイス
圧縮分割ブロックファイル
オンデマンドでブロックファイル取得
2006/12/08
CELF Jamboree #12
5
従来方式(NFSシンクライアント)との比較
NFSベース
HTTP-FUSE-KNOPPIX
NFS
・UDP
・WAN拡張難
HTTP
・TCP
・基本セッションレス
・サーバの繋ぎ替え容易
*耐故障性に優れる
*柔軟な負荷分散可能
・WANへの拡張容易
・軽量なプロトコル
トラフィック 圧縮は基本的
に無し
ブロック単位圧縮
MD5
通信効率良
・OS起動に必要な
通信量はNFSの2/3！
拡張性
フルコンテンツ
サーバを用意・
大規模化
汎用キャッシュ
サーバを用意・
小規模化可能
サーバ
DHCP/TFTP/
NFS
DHCP/TFTP/HTTP
プロトコル
2006/12/08
CELF Jamboree #12
必要ハードウェア資源
(CPU/メモリ/二次記憶)小
・限定的環境で動作可
・限定的環境で動作可
FireWall越え容易
6
既存の高速化の試み
ブロックファイルのキャッシュ
ブロックファイルをローカルマシン内にキャッシュ
ブロックファイルのダウンロード回数を削減
Ext2Optimizer
ファイルシステムレベルでの最適化
ブロックファイルのダウンロード数を削減
DLAHEAD(DownLoad Ahead)
OS起動に必要なブロックファイルを先読み
2006/12/08
CELF Jamboree #12
7
本研究の目標
HTTP-FUSE-cloopを用いて，
どこでも誰でも安価にシンクライアントシステム
モバイル組込みシンクライアントサーバの開発
高速化・耐故障性・負荷分散機構
処理が軽量なサーバとし，スケーラビリティを実現
システム構築を容易に
モバイル組込みシンクライアントの開発
広域仮想ブロックデバイスHTTP-FUSE-cloopの組込み向け最適化
Linuxベースのユビキタスノードに適用できる
（携帯）情報端末，情報家電，ホームゲートウェイ，センサネットワーク，
学会・会議等での利用，教育利用，家庭内環境etc….
2006/12/08
CELF Jamboree #12
8
問題分析
従来のHTTP-FUSE-KNOPPIXの手法では，
ネットワーク状況（レイテンシ，帯域）が大きく性能を左右
1台のサーバ性能（＝ディスク性能）の限界に対処不可
アクセス集中による，パフォーマンスの低下
耐故障性が考慮されていない
シンクライアントシステムではネットワークファイルシステムの性能が体
感速度に大きく影響
特に組込みハードウェアによるサーバでは，性能に制限
サーバの負荷分散が考慮されていない
モバイル環境では様々なネットワーク環境に対処する必要
クライアント起動中にサーバが故障すると，クライアントも停止
組込み機器のシンクライアント化ではHTTP-FUSE-cloopの性能
などの問題が存在
2006/12/08
CELF Jamboree #12
9
HTTP-FUSE-KNOPPIX-BOX
モバイルシンクライアント
HTTP-FUSE-KNOPPIX
サーバ
各種組込環境で動作可
ARM/SH/PowerPC/x86…
Linux 2.6/2.4系
モバイル化可能
ネットワークブート，
HTTP/Proxy，負荷分散/
耐故障性機能(DNS)など
を持つ
カードケースサイズ，重量
100g程度のものも
ワイヤフリーに近いサー
バ環境も構築可能
無線LAN/PoEなどの技術
2006/12/08
USL-5P（汎用USBサーバ）による
HTTP-FUSE-KNOPPIX-BOX
（SH4-266MHz/64MBMem/CF/
有線LAN/重量150g/文庫本サイズ）
CELF Jamboree #12
10
システムの全体図
HTTP-FUSE-KNOPPIX-BOX
有線・無線LAN・接続なし
（ネットワーク接続有無に
かかわらず起動可能）
・ネットワークブート／ルータ機能
・高速化機能
・負荷分散・耐故障性機構
などを持つ
キャッシュサーバ
・負荷分散が可能
・複数導入可能
クライアントマシン – 多様なアーキテクチャ
(PC/情報端末/情報家電….)
2006/12/08
CELF Jamboree #12
11
2006/12/08
CELF Jamboree #12
12
本研究で用いた手法
高速化の実現
キャッシュサーバによる高速化
RAIDによる高速化
サーバ能力・負荷状況に応じた， DNSによる動的なサーバ切り替えによ
る負荷分散機構
耐故障性の実現
RAIDによる耐故障性
RAIDの冗長性を利用した耐故障性機能
DNSによる耐故障性
ソフトウェアRAIDを利用したリクエスト分散，処理並列化による高速化
DNSによる負荷分散
広域ファイルシステムで問題となるネットワークレイテンシ・帯域を隠蔽
サーバの自動的な異常検出・切り替え機構
管理の自動化
サーバの自動認識（ホットプラグ）機構
2006/12/08
CELF Jamboree #12
13
実装
クライアント側(HTTP-FUSE-cloop for Embedded Systems)
Linux 2.6系(x86/ARM/SH4)
HTTP-FUSE-cloop
ソフトウェアRAIDによる耐故障性・高速化機構を利用するとき
FUSE(Filesystem in UserSpacE) 2.6.0＋独自パッチ
zlib/liblzo/libcurl
md
サーバ側(HTTP-FUSE-KNOPPIX-BOX)
Linux 2.6系/2.4系(x86/ARM/SH4/PowerPC)
DHCP Server, TFTP Server ー ネットワークブート用
HTTP Server(Apache,thttpd…) or Cache/Proxy Server(Squid…)
ー ブロックファイル取得用
DNSによる耐故障性・負荷分散機構を利用するとき
2006/12/08
Ruby 1.8.x (DNS-Balance改造版)
CELF Jamboree #12
14
キャッシュサーバによる高速化
クライアントからネットワーク的に近い場所にキャッシュサー
バを設置、ブロックファイル取得
トラフィックに応じて複数のキャッシュサーバによる負荷分散
が可能
DNSとソフトウェアRAID（後述）
キャッシュサーバの動的な追加・削除が可能
レイテンシ・帯域状況の改善
システム全体をダウンさせる必要なし
汎用HTTPキャッシュサーバが利用可能
Squidを利用
2006/12/08
CELF Jamboree #12
15
評価結果 – 従来方式との比較
HF-KNOPPIX
（w/Cache）
Fast
HF-KNOPPIX
(WO/Cache)
CD起動KNOPPIX
従来のHFKNOPPIX
NFSマウント
0
50
100
150
200
250
起動時間[s]
従来形式と比べ、起動時間の高速化を実現
（クライアント：ThinkPadX30/サーバ：BeSilent – 小型x86マシン）
2006/12/08
CELF Jamboree #12
16
評価結果 – HF-BOX環境間での比較
USL-5P(最適化FS)
Fast
L-BOX(最適化FS)
L-BOX
Be-Silent
typeU
キャッシュあり
0
50
100
150
200
250
キャッシュなし
300
350
400
起動時間[s]
ロースペックノートPCから組込み向け環境まで動作可能
2006/12/08
CELF Jamboree #12
17
RAIDによる高速化と耐故障性
RAIDによる高速化
Linux mdによるソフトRAID
複数のHTTP-FUSE-cloop
をmdにより、RAIDアレイ化
複数サーバからのブロック
ファイル取得・展開の並列化
RAID0/1が利用可
HTTP-FUSEKNOPPIX-BOX
読込みは0/1ともに高速化
RAIDによる耐故障機能
RAID1の冗長性を利用
主にクライアント側の障害に
有効
2006/12/08
HTTP-FUSE自体の障害
クライアント側のネットワーク
障害
HTTP-FUSE毎にネットワー
クインタフェースを変更可能
Client
CELF Jamboree #12
18
RAID0が有利
単一プロセスの場合
RAID0が有利
4
1
10
100
ランダムアクセスサイズ[KB]
1000
10000
RAID1が有利
16
RAID0(8プロセス/4サーバ)
RAID1(8プロセス/4サーバ)
従来方式
14
RAID0ではトラフィックの
偏りが生じる可能性
性能優先時はRAID0
耐故障性優先時はRAID1
2006/12/08
6
0
複数プロセスの場合での
性能差は小さい
8
2
RAID1が有利
先読みアルゴリズム
サーバのディスクキャッ
シュ
複数プロセスの場合
RAID0(1プロセス/4サーバ)
RAID1(1プロセス/4サーバ)
従来方式
10
12
読込性能[MB/s]
12
読込性能[MB/s]
評価 ー
RAID方式による差異
10
差は小さい
8
6
4
2
0
1
CELF Jamboree #12
10
100
1000
10000
ランダムアクセスサイズ[KB]
19
評価 ー サーバ数による差異
従来方式に比べて
サーバ4台で約4.14倍
サーバ1台でも従来方式
に比べ高速化
ダウンロード・展開作業
が並列化
サーバ限界に対応可能
USL-5Pのような組込み
環境で特に有効
2006/12/08
16
1台（RAID1）
2台（RAID1）
4台（RAID1）
1台（従来方式）
14
12
読込性能[MB/s]
10
4.1倍
8
6
4
2
0
1
CELF Jamboree #12
10
1000
10000
同じサーバ1台でも，
ランダムアクセスサイズ[KB]
RAIDあり・なしで性能差
100
20
評価 ー アプリケーション起動時間
メモリ上からの起動
従来のHTTP-FUSE
RAID0（1サーバ）
Eclipse3.2
OpenOffice1.03(Writer)
同時起動
RAID0（4サーバ）
0
5
10
15
20
25
30
起動時間[s]
Eclipse，OpenOfficeともに高速化
同時起動では従来のHTTP-FUSEの1/2以下の起動時間
2006/12/08
ディスクアクセス時間のみでは，3.5倍の高速化
CELF Jamboree #12
21
DNS Balanceによる耐故障機能と負荷分散
HTTP-FUSE-cloopによる
DNSの定期的な名前解決
を利用
クライアントの割当てサーバ
を起動中に動的に変更
ユーザは利用サーバを意識
する必要はない
実装はDNS Balanceを改変
耐故障性
正常なサーバを割当て
主にサーバ側の障害に有効
DNS Request
Knx-Server?
起動!!
Knx-Server = 192.168.0.X
↓
Knx-Server = 192.168.0.Z
負荷の低いサーバを割当て
2006/12/08
Knx-Server List = {
192.168.0.X ,
192.168.0.Y ,
192.168.0.Z (NEW!!) }
Knx-Server =
192.168.0.Z
Client
負荷分散
HTTP-FUSE-KNOPPIX-Server
with DNS-Balance改
障害発生!!
or
負荷増大!!
192.168.0.X 192.168.0.Y 192.168.0.Z
HTTP-FUSE-Knoppix-Servers
Block Files
特定のサーバに負荷を集中
させない
CELF Jamboree #12
22
DNS Balanceによる耐故障機能と負荷分散(2)
最適な（＝負荷が低く，正常な）サーバの動的割当て方法
DNSはハートビートから定期的に
サーバのリストを作成・更新
各サーバの状況（ハートビート）
からDNSがサーバ優先度決定，
クライアント割り当て
サーバの異常検知・回復
サーバの追加・削除を自動認識
管理容易
サーバ切替間隔はTTLなどによる
2006/12/08
サーバ異常発生時，ハート
ビート送出停止
HTTP/Cacheサーバの
動作確認，再起動
ネットワーク異常時にはハート
ビートは到達不可
サーバのホットプラグ
ネットワーク負荷
ネットワーク形態
クライアント割当て台数 etc…
障害発生時の通信停止時間
CELF Jamboree #12
23
RAIDとDNSの組合せによる耐故障/負荷分散
機能
RAIDの各物理ディスクイメージ
を複数のサーバに配置
サーバ状況によって各物理ディ
スクイメージを読み取るサーバを
変更し，
耐故障性
負荷分散
を実現
RAID0/1ともに利用可
192.168.x.1
Cache/HTTP Server
DISK1
Image
DISK2
Image
DISK2
Image
DNS-Balance
knx_server*={
192.168.x.1 ,
192.168.x.2 }
サーバ切替
Blockfiles
RAID0
物理ディスク1
RAID0
物理ディスク2
HTTP-FUSE/DISK1
knx_server1=
192.168.x.1
mdのみではRAID1のみ
耐故障性
必要二次記憶容量はmdを
利用しない場合と同等
DISK1
Image
192.168.x.2
Cache/HTTP Server
knx_server2?
192.168.x.1
HTTP-FUSE/DISK2
knx_server2=
192.168.x.2→192.168.x.1
Linux md
Client
RAID0
論理ディスク
/dev/mdX
MD5によるファイル名
2006/12/08
CELF Jamboree #12
24
負荷分散（スケーラビリティ）の評価
USL-5P×4台
利用
サーバの台数
効果はほぼ線形
さらにクライアント
が増えた場合，
サーバを増やせ
ば対処可能
800
サーバ1台
サーバ2台
サーバ4台
700
起動時間（最悪値）[秒]
600
500
400
300
200
100
0
0
2006/12/08
10
CELF Jamboree #12
20
30
クライアント数[台]
40
50
25
NFSに比べ性能
低下割合が小さい
サーバへの負荷
がNFSに比べ
小さい
組込みサーバに
最適
Fast
起動時間[s]
スケーラビリティ評価 ー 他方式との比較
180
160
140
120
100
80
60
40
20
0
1台
2台
4台
8台
クライアント台数
HF-KNOPPIX/サーバ1台
NFS
2006/12/08
CELF Jamboree #12
HF-KNOPPIX/サーバ2台
26
評価 ー 耐故障性（概要）
サーバ側のネットワーク異常を想定
HF-KNOPPIXサーバとしてUSL-5P 2台を用意
RAID0+DNS
Balanceを利用し，物理ディスク単位でトラ
フィック分散
クライアント側で連続的にHTTP-FUSE-cloopを介し
てデータを読み出す
ネットワークを物理的に切断・接続を繰り返す
各サーバのトラヒックよりサーバ切替えが適切に行
われることを確認
2006/12/08
CELF Jamboree #12
27
通信停止時間=3[s]
評価 ー
耐故障性
正常にサーバ切替え
実行
スループット[Mbps]
サーバ1 サーバ サーバ1
復帰
切断
切替
データアクセス
エラーは発生せず
DNSのTTL
HTTP-FUSEの
timeout
HTTP-Keep-Alive
サーバリスト更新
間隔（Heartbeat）
による
2006/12/08
サーバ2切断/
切替/復帰
45
40
サーバ1
サーバ2
35
30
25
20
15
10
5
0
サーバ復帰時にはト
ラフィックが再度分散
最大通信停止時間は，
サーバ1切断/
切替/復帰
0
10
20
30
40
50
60
70
80
90
100
経過時間[s]
サーバ1切断
サーバ1復帰
サーバ
リスト更新
リスト更新
DNS
DNS問合せ
サーバ切替
DNS問合せ
サーバ切替
クライアント
物理ディスク1
物理ディスク2
Serv1
Serv2
Serv2
Serv2
CELF Jamboree #12
Serv1
Serv2
Serv2
Serv2
Serv1
Serv2
Serv1
Serv1
Serv1
Serv2
28
HTTP-FUSE-cloop for Embedded Systems
組込みシステムにもシンクライアントシステム
広域で利用できる軽量なストレージシステムを提供
様々なアーキテクチャ（x86/ARM/SH/MIPS….）への対応
Linuxベース情報家電等での利用
従来のHTTP-FUSE-cloopでは性能上の問題がある
CPU性能，メモリ性能，ネットワーク性能…
組込み向けのHTTP-FUSE-cloopの最適化が必要
特に，HTTP-FUSE-KNOPPIX-BOXの評価から，
LAN環境ではCPUやメモリ性能がボトルネックになる傾向
CPU：HTTP-FUSE-cloopの展開処理最適化
メモリ性能：メモリ周りの処理の最適化
2006/12/08
CELF Jamboree #12
29
HTTP-FUSE-cloopとHTTP-FUSE-loop(?)
UserApp
FileSystem
FileSystem
Cloop driver
Fuse driver
HTTP-FUSE
-cloop
Fuse driver
Cloop driver
UserApp
FileSystem
FileSystem
Loop driver
Fuse driver
HTTP-FUSE
-cloop
Fuse driver
Loop driver
FileSystem
組込み用 HTTPFUSE-cloop
UserApp
コピー
ダウンロード・展開
Read要求
差し替えを容易に
Kernel
User
Kernel
30
CELF Jamboree #12
2006/12/08
FileSystem
UserApp
従来の HTTPFUSE-cloop
Read要求
展開ルーチンの
ダウンロード
展開
HTTP-FUSE-loopの内部構造(ダウンロード部)
libcurlにより取得
Callback毎にrealloc()
② or ③
Output
展開処理
②
出力バッファ
確保・コピー
download
キャッシュ書込
download
Read Request
from FUSE
①
downloadキャッシュ
●1ファイルのメモリキャッシュ
●二次記憶/Ramdiskキャッシュ
Download
キャッシュ読出
2006/12/08
①、②、③・・・はメモリコピー回数
①
CELF Jamboree #12
31
HTTP-FUSE-loopの改善(ダウンロード部)
libcurlにより取得
あらかじめ固定サイズで確保
されたメモリ領域に書き込み
ReadRequest毎の
出力バッファ確保・コピー廃止
プログラム開始時に確保した
バッファを展開時にも利用
Output
展開処理
download
Read Request
from FUSE
①
Downloadキャッシュ廃止
1ファイルキャッシュは展開後にキャッシュ
→キャッシュヒット時に再展開の必要が
なくなり、高速化
2006/12/08
CELF Jamboree #12
32
HTTP-FUSE-loopの内部構造(展開部)
③ or ④ ④ or ⑤
Output
出力用バッファ
コピー
展開処理
展開用バッファ
確保
download
Read Request
from FUSE
Zlibにより展開
組み込み環境には少々重い
2006/12/08
CELF Jamboree #12
33
HTTP-FUSE-loopの改善(展開部)
キャッシュヒット
展開ルーチンは、
Zlib、LZO、無圧縮
を選択可能に！
① or ③
②
無圧縮イメージの場合は、
Download時に直接、キャッ
シュに出力するため、コ
ピー回数が ① or ② に
2006/12/08
展開処理
（出力バッファ
直接）
ブロック全体の
ReadRequest
CELF Jamboree #12
Output
出力用バッファ
コピー
展開処理
（キャッシュ
バッファ）
download
Read Request
from FUSE
ブロック一部
のReadReq
1ファイル展開後
キャッシュ
②
ブロック全体の
リード要求では
キャッシュしない
34
改良結果
ブロックデータ圧縮ルーチンの変更
Zlibだけでなく，軽量なLZOや，無圧縮方式を利用可能に
メモリ周りの処理の最適化
メモリコピーがボトルネックになっていることが判明
無圧縮イメージではコピー回数を4 or 5回→1 or 2回に
LZO,Zlib利用時にはコピー回数を4 or 5回→1 or 2 or 3回に
メモリ確保(malloc)・再確保(realloc)回数の最適化
1回の読込みリクエストでのメモリ確保回数は3回以上→0回に
キャッシュ方式の変更
展開後のデータをキャッシュ
キャッシュヒット時のCPU負荷・メモリコピー回数低減
ブロック全体の読込み時にはキャッシュしないように
2006/12/08
CELF Jamboree #12
35
圧縮方式・イメージ別の転送量
3種類のイメージ
（各100MB）を用意
ランダムデータ
（圧縮率低/Random）
動画データ
（圧縮率中/Data）
ゼロデータ
（圧縮率高/Zero）
シーケンシャルに30MB
読み出したときの転送
量を測定
zlibとLZOの転送量で
最大1.4倍の差
2006/12/08
Zero
無圧縮
LZO
zlib
Data
Random
0
5
CELF Jamboree #12
10
15
20
総転送量[MB]
25
30
35
36
機器別性能評価
従来方式に比べ
1.8～2.4倍の
性能向上
ARM搭載機器は
メモリ周り最適化
が有効
SH搭載機器では
展開処理軽量化
が有効
メモリ周り最適化
による性能向上
GLANTANK
(Xscale 400MHz)
無圧縮＋最適化
LZO+最適化
zlib＋最適化
従来方式
Armadillo
(ARM9 200MHz)
USL-5P
(SH4 266MHz)
0
2006/12/08
CELF Jamboree #12
展開処理軽量化
2
4
による性能向上
性能[MB/s]
6
8
37
圧縮方式と圧縮率別性能
ダウンロード時間と
展開時間のトレード
オフ
組込み機器では
展開時間がボトル
ネックになる傾向
ネットワーク環境の
改善もあり，組込み
機器ではLZOが
最適か
Zero
Data
LZO
Zlib
無圧縮
Random
0
2
圧縮率中程度の
イメージ（Data)で
LZOの効果顕著
2006/12/08
CELF Jamboree #12
4
6
性能[MB/s]
8
10
12
38
他方式との比較
他方式と比較すると
NFSの1/2倍～同程度
SMBの1.3倍～2.7倍
圧縮率が高くなるデータ
では，圧縮のないNFS
やSMBに比べ有利
FUSE自体のオーバ
ヘッドが比較的大きい
HTTP-FUSEcloop(LZO)
NFS
Zero
Data
Random
SMB
0
2
4
6
8
10
性能[MB/s]
2006/12/08
CELF Jamboree #12
39
まとめ
組込みモバイルシンクライアントサーバ
“HTTP-FUSE-KNOPPIX-BOX”を実装
キャッシュサーバ，RAID，DNSによるトラフィック分散・高速化を実現
RAIDではディスク性能で最大4.14倍の性能を実現
アプリケーション起動で最大1/2以下の起動時間を実現
キャッシュサーバにより従来手法と同等以上の起動時間を実現
スケーラビリティの実現を確認
DNS/RAIDによる耐故障性を実現
組込み機器向けにHTTP-FUSE-cloopを最適化
従来方式に比べ最大2.4倍の高速化
広域にサービス提供可能な，組込みシンクライアント実現の可能性
2006/12/08
CELF Jamboree #12
40