プロフィール

大山恵弘

  • Author:大山恵弘
  • 公式なサイトはこちら

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブロとも申請フォーム

ブログ内検索

RSSフィード

リンク

FC2カウンター

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

【耐故障】 Handling Cascading Failures: The Case for Topology-Aware Fault Tolerance 【分散システム】

In HotDep 2005.
http://www.stanford.edu/~candea/hotdep/

大規模分散アプリケーションは複数のコンポーネントが複雑に絡み合ってできている。これは、「連鎖的な障害」をもたらす。

本研究では、連鎖的な障害が広がるのを防ぐために、システムのトポロジについての情報を用いることを提案している。トポロジを意識して障害検出、リカバリを行うことを提案。

研究はまだ初期段階であり、この論文は問題提起が主という感じ。トポロジアウェアな耐故障技術を構築するには、どんなことを考えなければならないかを列挙してる。

あと、連鎖的な障害を5つのクラスに分けたり、コンポーネントの依存関係を3つに分けたりといった分析の話もあり。

この論文も、複数のコンポーネントからなるセキュリティシステムの障害検出・リカバリを扱っている。セキュリティシステムをサンドボックスの中で実行する。サンドボックスは、ユーザに与えられたセキュリティポリシーに従い、コンポーネント間の依存関係を意識して再起動や停止などのリカバリ処理を実行する。
スポンサーサイト

【リカバリ】 Building a Reactive Immune System for Software Services 【エミュレータ】

In USENIX Annual 2005.
http://www.usenix.org/events/usenix05/tech/general/sidiroglou.html

プログラム(主にサーバ)の障害を自動的に修復するためのシステム。

セグメンテーション違反やゼロ除算などの例外が発生したら、引き続く実行では、例外を発生させた命令を取り囲むコード部分をエミュレータ上で実行する。

エミュレータ実行に移る前に、プログラムの状態のスナップショットを取る。エミュレータ実行から戻る際に、エミュレータ上で動いているプログラムを生で実機上で動くように復元する。

エミュレータ上では、障害を起こす可能性のある命令の実行を検査しながら実行する(たとえばゼロ除算が発生したなら、div命令を監視しながら実行する)。エミュレータ上実行で、次に実行される命令で例外が発生することが判明したら次の処理を行う。(1) 例外が発生した関数内で行われたメモリの更新を全部ロールバック、(2) その関数をリターンさせる。返り値は、エラーコードっぽいものにする。たとえばint型の関数なら-1を返すとか。

エラーを返させてもやはり障害が発生する場合には、エミュレータ実行の範囲を広げる。その関数を取り囲む関数もエミュレータ実行するとか。

想定外のエラーを想定内のエラーに変換して、プログラム内にあるハンドラにあくまで例外処理をさせるという手法。彼らいわく、Error Virtualization。

x86エミュレータSTEMを実装して実験した。エミュレータはCライブラリの形をしており、守りたいプログラムにリンクして使う。エミュレータ実行開始、エミュレータ実行終了みたいなAPIが準備されている。

Apache, sshd, Bindで実験。leaf関数を人為的に書き換えて適当にアボートさせても、どのサーバもかなりの確率(9割くらい)で、稼動し続けることを確認した。また、実際の攻撃コードを用いて攻撃したところ、いずれのサーバも稼動し続けることを確認した。他に、性能への影響も計測しています。

あやしげなところもあるが、おもしろいアイデアがちりばめられていて、いい感じの論文。

部分的にエミュレータ実行するという点につい注意をひかれてしまうが、エミュレータ実行は一手段であって、それに目を奪われすぎると、本質を見失う。

エミュレータ実行してロールバックみたいな話は多くの人が考えているはずだし、実際論文もたくさん出てる。この論文の貢献は、むしろ、例外を発生させる(た)関数を、強制的に適当な値でリターンさせるというアイデアの提案ではないかという気がします。Failure Oblivious Computingの大掛かり版みたいな。

横山くんのチェックポイントシステムの研究あたりが、まさにこのあたりの応用にドンピシャリで効いてきそうな気がしています。

【仮想化】 Self-migration of Operating Systems 【マイグレーション】

In SIGOPS European Workshop 2004.
http://www.diku.dk/~jacobg/

OS全部をマイグレーションするシステムを実装した。
一つはL4ベース。もう一つはXenベース。
たぶんポイントは2つ。

  • メモリイメージを二段階転送してdowntimeを削減するという提案
  • ゲストOSの中にマイグレーション機構を実装するという提案

2004年後半の論文ではあるが、VMotionには触れられていないようだ。多段階転送はいまや珍しくない。VMotion以外では、最近Xenグループがそういう論文発表したし、Quasarも多段階転送をする。

マイグレーションのための実装をなるべくゲストOSに押し込もうって話のほうが、今となってはおもしろい。ゲストOSに押し込むと、ホストOSっていうかhypervisorの機能が小さくなるので、TCBを小さくすることが容易になる。異なるhypervisor間でのマイグレーションもしやすくなる。

本研究ではXenのゲストOSのXenoLinuxを改造してマイグレーション機能を実装している。L4版はホストOSによるマイグレーションの実装。

ゲストOS内でスナップショットを取るとなると、自分自身のスナップショット取得は永遠に完了しない(不動点があればいいが)みたいな話がついてきて、それはそれで楽しいかもしれない。

基本的には、ゲストOSとホストOSが協調して何かやるって方向は結構好きです。

Virtual Multiprocessorだと、スナップショットとかマイグレーションってどうなるんだろうなって、ふと考えたり。

CPUにVM機能が入ったりCPUがマルチコア化するという動きを見ていると、セキュアなhypervisorの研究は今後極めて重要になる気がしています。XenoServerとかVMware ESX Serverが、今後どう進化するのか。

【侵入検知】 Behavioral Distance for Intrusion Detection 【多様性】

In RAID 2005.
http://www.ece.cmu.edu/~dawnsong/

タイトル見て、「あ!うまい!やられた!」って思った。Behavioral Distanceというキャッチーなキーワードの導入。思いつきそうでなかなか思いつかなかった。くやしいのう。

システムコール列侵入検知手法の一つ。

侵入検知したいプログラムがあったら、そのプログラムのレプリカ(群)を同時に走らせる。元のプログラムとレプリカには、同じ入力が与えられる。よってそれらは同じような動きをする。

ただし、元のプログラムとレプリカの動きを、意図的に変える。元のプログラムとレプリカをちがうプラットフォームで実行するとか、N-versionみたいなことして、レプリカの実装を元のプログラムと変えるとか。

その結果、元のプログラムとレプリカから出てくるシステムコールは、若干異なる。でも、正常実行であるかぎり、それらは似通っている(behavioral distanceが小さい)。

攻撃された場合、元のプログラムとレプリカのシステムコールは、かなり食いちがう(behavioral distanceが大きくなる)。

これを利用して、侵入検知を行う。

既存の侵入検知手法に比べて、mimicry attackが難しいのが利点。

Shadow Guardingにちょっと似てるような気がしたのだが、論文ではふれられていないようだ(たしかに、研究の前提や手法などで異なる点は多いのだけれども)。

Songさんとか、Chewさんとか、だいぶ前から、多様性の導入で安全性を実現しようってことやってる。2002年にすごくおもしろいテクニカルレポート書いてる。それがまださらに発展して、計算機免疫系とくっついて、こういう楽しい研究が出てくるのか~と、なんだか大ショック。発想のおもしろさに打ちのめされました。

うちの周りを見渡すと、島本くんが、「Windowsのシステムコール列で侵入検知」ってテーマをやってます。これとかこれとか。

【仮想機械】 Are Virtual Machine Monitors Microkernels Done Right? 【マイクロカーネル】

In HotOS X.

http://www.usenix.org/events/hotos05/prog_public.html

bib抜くと3ページのポジションペーパみたいなもの。

マイクロカーネルとVMMの共通点とちがう点を述べている。VMMについては主にXenを引き合いに出している。

比較を通じ、マイクロカーネルが失敗しつつあり、VMMが隆盛する理由は何なのかを明らかにする(ちょっと大げさに言えば)。

基本的にはマイクロカーネルは理想主義でVMMは現実主義。

1、信頼性

ユーザーレベルにページャーを押し出すとカーネルが困るとか。

XenではVM間でメモリを厳しく分離してるとか。

2、IPC

マイクロカーネルではIPC性能が重要。

XenではVM間の通信はあまり重要ではない。

3、コンポーネント化の粒度

マイクロカーネルではOSの機能を別々の部分に分離することに注力。その結果現在のOSのサポートをするために多大な労力。

VMMではそもそも現在のOSのサポートが先にありき。その結果ユーザも多くなった。

Para-virtualizationの是非についての議論もほしいように思いました。

なお、Virtual Multiprocessorでも、既存のLinuxをゲストOSとして、ほぼそのまま使えます。

【仮想機械】 Increasing Application Performance In Virtual Environments Through Run-time Inference and Adaptation 【仮想ネットワーク】

In HPDC 2005.
http://www.caip.rutgers.edu/hpdc2005/program.html

Virtuosoプロジェクトの最新の研究。

VMの集合の上で動いているアプリケーションの通信挙動を推測する。その情報をもとに、アプリケーションを環境に適応させて、アプリケーションのスループットを向上させる。使用する適応行動は、(1) VMのマイグレーション、(2) オーバレイトポロジの修正、(3) オーバレイフォワーディング、の3つ。トポロジとルーティングは完全に別。ヒューリスティクスを利用し、適切なノードにVMを配置。使ったVMMはVMware。OSにもアプリケーションにも修正は必要ない。

Quasarにも関係してるかも。

| ホーム |


 BLOG TOP 


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。