2016年12月8日木曜日

HIL: Designing an Exokernel for the Data Center

遅刻しました.ごめんなさい.
本稿はシステム系論文紹介 Advent Calener 2016,2 日目の記事になります(大遅刻).
今回はHIL: Designing an Exokernel for the Data Center を紹介します.

原論文

J. Hennessey, S. Tikale, A. Turk, E. U. Kaynar, C. Hill, P. Desnoyers and O. Krieger, “HIL: Designing an Exokernel for the Data Center″, in 7th ACM Symposium on Cloud Computing, ser SoCC '16, Santa Clara, CA, USA: ACM, Oct. 2016, pp. 155―168, ISBN: 978-1-4503-4525-5. DOI: 10.1145/2987550.2987588. [Online]. Avaliable: http://doi.acm.org/10.1145/2987550.2987588.

前提

1. Exokernel
まず始めに,表題にもある,Exokernel について説明しなければなりません.Exokernel とは,1995 年に生まれた技術です[1]. 図1を見てください. これは,マイクロカーネルよりさらに一歩進めて,security bindings 以外を全てカーネルから追い出してしまい,従来のカーネルのサブシステムは,全てアプリケーションとリンクするライブラリとしてしまうアーキテクチャです.この,従来の OS の機能を持つライブラリを,libraryOS と言います.リソース管理などの機構をアプリケーション毎に特化させる事を容易にし,また,複数のアプリケーションの,デバイスや計算資源へのアクセスの分離(isolation)とその管理(management)をそれぞれ Exokernel と libraryOS で全く分けてしまえる事が特徴のアーキテクチャでした.

TL;DR

さて,今回紹介する論文は,この Exokernel のような抽象層を,ベアメタルクラウドのデータセンタに導入する試みです.
  • 双方向に信頼されないベアメタルのデプロイメントサービス(OpenStack Ironic, MaaS, xCAT ..)
  • これらサービスでデータセンタの計算資源を効率的に共有
  • 効率化のみならず新しい経済モデル,新しいアプリケーション,新しいセキュリティ特化型の利用,を可能にする(と論文の筆者は信じている)

背景と問題点

現在様々な物理サーバー向けのデプロイ/プロビジョニングのツールがありますが,これらは全て,低レイヤを覆い隠し, また,イメージデプロイツールを通して抽象化することでアプリケーションやサービスを物理システムの上に展開する事を簡単にするという共通の目的があります.
しかし,OpenStack Ironic は勿論 OpenStack ユーザ向けですし,xCAT は HPC 分野でのデプロイのためのツールで,用途によって様々です. 抽象化の実現の仕方も様々ですので,すると例えばクラスタの管理者はソフトウェアのデプロイに Ironic を使うのか MaaS を使うのか決断する必要がありますし,データセンタの管理者達は,それぞれのツールをユーザが使えるように,サーバ群を静的にパーティションして備えるといったことが起こります.
ユーザが新しいツールを使いたかったとしても,さらにサーバ群をいくつか新しいツールのために使えるよう準備しておかなければならないため,結果としてデータセンタ管理者はそれを避けようとします.つまり,新しいツールが出ても中々使えない状況が起こります.
そこでこの論文では,Hardware Isolation Layer(HIL)というレイヤを導入することで,複数のベアメタルデプロイツール間で計算資源の共有を可能とし,データセンタの効率化を果たすというのが目的になります.

概要

2. HIL の概要図
HIL の役割は主に,物理サーバやネットワークの確保と,これら確保したものを複数のデプロイサービス間で分離することです.しかも,その構成について,手動の管理なく再構成が可能になります.具体的には,1) 物理サーバの確保 2) ネットワークの確保 3) サーバとネットワークの接続,が HIL が提供する基本的な機能です.また,追加的な機能としては,1) HIL のマネージドネットワークへの VPN 接続 2) パワーサイクルやブートデバイス選択のようなものを安全に行なうノード管理機能 3) 確保されたリソースの追跡,などがあります.また,サーバープールごとに 1 つの HIL インスタンスを置き,管理することで,巨大なデータセンタを複数の会社や研究グループが管理する状況にも対応します.

構造

3. HIL のデプロイのコンポーネント
HIL の構造について,図3. を見て下さい.HIL のコンポーネントは, 3 つに分類され,コアコンポーネント,システムドライバ,オプショナルサービスとなります.本稿ではオプショナルコンポーネントについては割愛します.原論文を参照ください.

HIL API

HIL の資源は,ユーザの集合に管理される project が基本になっており,この projectnodesnetworks という要素を持っており,nodes,つまりサーバは networks へ接続される NICs を持ちます.REST API を通じて操作され,ユーザは次の操作が可能です.
  • プロジェクト作成・空のプロジェクト削除
  • ネットワーク作成・削除,パブリックネットワークのプロジェクトへの取り込み
  • プロジェクトへのノード確保・プロジェクトからノードの解放
  • ネットワークへの NICs 接続・ネットワークからの NICs 切断
  • パワーサイクルやシリアルコンソールへのアクセスのようなノードの管理
  • 空いてるノードの一覧表示,プロジェクトへのノードとネットワーク割り付け,ノードやネットワークの詳細取得,などのクエリ

コアコンポーネントとドライバ

HIL Server
HIL のロジックの実装の大半と HIL の REST API,データベースのインターフェース,操作エンジン,アウトオブバンド管理1 のドライバを持ちます.
OBM and Auth drivers
HIL は,OBM(=アウト・オブ・バンド管理)ドライバを通してベアメタルのノードを制御します(パワーサイクルや,ネットワークブート,シリアルコンソールのログへのアクセス).OBM ドライバは,IPMI を使って実装され,プログラムインターフェースを提供します.また,認証と認可の決定は,auth driver へ転送されます.リクエストの説明,受け取った決定(認可の可否),オプションで認可トークンをドライバに渡すことで,認可が実行されます.
Operation Engine
ネットワーク構成の変更のような,調整操作のシーケンスへ責任を持つエンジンです.API サーバからキューを通してリクエストを受け取り,リクエスト順に処理を実行し,最終的に完了したらデータベースを更新します.
Switch drivers
operation engine がネットワーク接続の操作を行なう際に実際にその操作を受け持つ実装になります.VLAN などを用いて,他のプロジェクトや外部システムから,プロジェクトへのアクセスを拒否し保護するといった事を実現します.

評価

1. 13 ヶ月間のクラスタで実行された操作の統計
2. 秒当たりの中央値と標準偏差
プロトタイプ実装は 3000 行以下(ただし PoC).48 の Cisco UCS C220 M32 ノードで日々基本的な production に使用されています.表1. は,このクラスタで,HIL を 13 ヶ月間稼動させ取った操作の数の統計で,表2. はこれらのコアの操作について,かかった時間の中央値と標準偏差を取ったものです.これは各操作を 250 回繰り返した場合の統計値です.スイッチと対話しない,データベースの操作のみで完結する操作の場合,数十ミリ秒で操作が終了しており,ネットワークの接続を要する操作も数秒で終わっています.
4. 同期的な API の並列性
5. 非同期的な API の並列性
4. は同期的な API の実行を,クライアント数を増加させた場合の処理にかかる時間を見たものです.基本的に,クライアント数が増えても実行時間は増えておらず,alloc_net と free_net は多少実行時間が増えていますが,スケーリングしていると言えます.ノードの解放だけ異様に実行時間が長いのは,ノードの解放の前に ipmitool を実行してコンソールを接続する必要があるため, 他の操作に比較して 5 倍という実行時間になっているようです.図5. は非同期な API の実行における並列性です.この操作は,ネットワークスイッチへの対話が必要であり,この計測では全てのリクエストが同一のスイッチに向けられていることがボトルネックになってします.スイッチがスケールするより巨大な環境で,HIL に最適化されているのであれば,並列性はさらに向上するのではないかと原論文の著者は推測しています.
6. HIL で区画された環境へ,Hadoop 環境をベアメタルと仮想環境(OpenStack)それぞれ用いてデプロイした時のパフォーマンス
次に,HIL をベアメタルサービスで用いた場合のデモンストレーションについてです(図6.).1) HIL で 8 ノード確保し,2) Foreman を用いて Red Hat Enterprise Linux をプロビジョニングし,3) Apache BigTop でビッグデータ処理環境をベアメタルにデプロイし,4) CloudRank-D ベンチマークを用いた結果となります.比較対象となる仮想化環境は,MOC(Massachusetts Open Cloud)の OpenStack (Kilo リリース版)を同一のクラスタの idle のノードで実行し,同一テストを走らせたものです.仮想の Hadoop 環境は 1 ノード 1 VM で動作され,各 VM はホストの 90 % の資源が与えられています(残りの 10 % はハイパーバイザに予約されている).仮想化によるオーバーヘッドの分,ベアメタルのほうが性能が勝っています.
ところで,HIL そのものは,例えばリクエストに対しどのノードを確保するべきか選択する,といったようなスケジューリングはしません.そこで,HPC クラスタで広く使われている SLURM スケジューラを導入し,HIL リクエストに特別の名前空間を設けることで,HIL と SLURM を共存させることにも成功しています.

経済効果

7. 1 週間での リアルタイムワークロードと HPC ワークロードが必要とした c4.xlarge インスタンスの数
8. 1 週間でのシステムの利益(5000 の Linux がホスト可能な,US-East-1a にある c4.xlarge の EC2 インスタンス)
実際のデータセンタで HIL が使われると仮定します.たとえば,Amazon EC2.現在オンデマンドにインスタンスが借りれますが,HIL によってオンデマンドにクラスタ単位での貸し出しが可能となり,これは大規模ゲームサーバや HPC のようなリアルタイムアプリケーションで有利になります.MMO ゲームは,それぞれ使い方が異なる,極度に特化したソフトウェアを分散サーバファームを通して配信しますし,多くの HPC ライブラリやアプリケーションも同様にとてもハードウェアに寄りの動作をする設計になっているので,OS のドライバやハードウェアのサポートを必須としています.HIL ならば,仮想化されているサービスとそうでないサービスの間で,物理ノードの数を動的に調整できます.つまり,HPC に使われていたノードを,クラウドサービスで使うノードに転用する,ということを,オーバーヘッドをかなり少なく(一時間以内で)行なえるのです(サーバの再起動と再プロビジョニングの分の時間はかかっていますが).
7. はログデータによる,HPC ワークロード(SunGrid Engine)とリアルタイムワークロード(ゲーム,MineCraft)の必要とする c4.xlarge インスタンス数の一週間でのプロットです.
8. は,5000 の Linux を c4.xlarge EC2 インスタンスで貸し出せると仮定した架空の AWS のようなベンダの,一週間での利益を図示したものです(ただし,オンデマンドで貸し出せず,スポット市場3を通して貸し出すものとする).このインスタンスは 5000 を超える物理ノードで提供されると仮定します.さて,図8. の緑の線は,スポット市場で全部のノードが貸し出された場合の利益です.しかし,もし図7. の HPC ワークロードに全て貸し出し,残ったノードを仮想化してスポット市場に貸し出すのなら,赤の線がその利益となり,単純にスポット市場に全部貸し出すよりも 30 % も高い利益が得られます.同様にリアルタイムワークロードで考えると,青い線,50 % の利益向上が見込めるそうです4

まとめ

本稿で紹介した論文では,HIL をデータセンタの基本的な抽象層として導入しました.HIL は異なるハードウェアと仮想プロビジョニングシステムの下のレイヤとなるため設計され,サービス間の強力な isolation を提供することで,新しいデプロイサービスの導入をラクにし,また,異なるデプロイサービス間での資源の移動を効率的に可能にしました.また,HIL によって Hadoop 環境のベアメタルなデプロイサービスとしても動作可能であること,SLURM スケジューラを MaaS や Ironic,Emulab といったベアメタルプロビジョニングツール同様に導入可能であることを実証・議論しました.さらに,異なるサービス間で,サービスのキャパシティを移動させる事についての経済効果も明かにされました.現在(論文の提出された 2016 年 10 月現在)MOC で HIL が 2016 年 1 月より使われ,100 以上のユーザが日常的に使用しているようです.

本稿のまとめ

本稿では,HIL: Designing an Exokernel for the Data Center について紹介しました.実のところ Exokernel に関連する論文だと思ってとりあえず読みながら記事を書いていたのですが,途中でこれは Exokernel から着想を得ただけで分野違ったなーと若干後悔しています.しかしながら,同じシステム系でも OS アーキテクチャとデータセンタでのプロビジョニングは結構違う分野ですが,こうやって着想を得て活用されるというのはなかなか面白いですね.
Web でたまにマイクロサービスとかの話を聞きますが,システムでも機能単位やコンテナ単位で細分化して取り扱おうという試みが増えている気がします.データセンタでもこうやってクラスタを細分化して配分できるようにし,様々な構成で効率的に活用できる,というのは当然の流れかもしれません.個人的には libraryOS はそういった流れを実現するものとして注目しているので,今後も色々論文読んでいきたいと思います.

脚注:
†1:アウト・オブ・バンド管理:電源オフ,スリープ,休止状態や,何かの理由で OS が応答できない状況などの時,管理者が管理コントローラへ接続できるように何らかの措置を取る.
†2:10 GbE NIC を備え,デュアル 6 コア CPU(+ハイパースレッディング有効),128 GB RAM,ディスクは 1 つないし 2 つという構成.
†3:現物を取引する市場のこと.対義語は先物市場で,これは株や為替のような,将来のある時期に物を受け渡しする契約を結ぶ取引をする市場を指す(契約時点で物が手元になくても良い).
†4:c4.xlarge インスタンスの価格は Amazon EC2 の 2015 年 7 月 13―20 日に準じている.HPC のコストは AWS HPC のオンデマンドのコスト,リアルタイムワークロードのコストは 3.4 GHz Xeon E3-1270,8GB RAM のサーバを IBM SoftLayer で借りる場合のコストをそれぞれ仮定している

参考文献

^1 D. R. Engler, M. F. Kaashoek, and J. O’Toole Jr, “Exokernel: An Operating System Architecture for Application-Level Resource Management,” in 15th ACM SIGOPS Symposium on Operating Systems Principles, ser. SOSP ’95, vol. 1, Copper Mountain, CO, USA: ACM, Dec. 1995, pp. 251―266, ISBN: 0897917154. DOI: 10.1145/224056.224076. [Online]. Available: https://pdos.csail.mit.edu/6.828/2008/ readings/engler95exokernel.pdf.

2016年11月28日月曜日

Ansible 2.2.0 でホストごとに実行するタスクを切り替える

ansibleで実行対象を切り替える方法 http://tdoc.info/blog/2014/05/30/ansible_target_switching.html

このサイトを参考にしようと思ったのですが古くて現在に似わなかったのでメモ.

when: "'foo' in group_names"
inventory_host でグループ分けするところまでは同じ.
when で条件分けをするにあたって,
group_names はタスクを実行しているホストが所属するグループの配列になってるので,目的のグループに所属しているかどうかを in 演算子で確認する感じです.

2016年11月22日火曜日

フォントが埋め込まれていない PDF にフォントを埋め込む

表題通りです.

古い日本語論文を読むと,90 年代終わりから 00 年代初頭ぐらいのもので,
PostScript プリンタのフォントダウンロードを期待して Adobe 基本 35 書体と
Ryumin-Ligtht と GothicBBB-Medium を指定するが埋め込んでいない,
という PDF を見かけることがある.

ふつうは代替フォントが表示されて終わるのでなんでも良いけれども,
Mendeley の内蔵ビューワーであったり,ブラウザ内蔵ビューワーであったり,
そういう環境では埋め込まれていない和文フォントはそのまま表示できずに空白になる.

次のコマンドで GhostScript を使ってこれを解決.

$ gs -o font_embedded.pdf -sDEVICE=pdfwrite -dEmbedAllFonts=true -sFONTPATH="/usr/share/fonts/Type1:/path/to/your/font/dir" font_not_embedded.pdf
-o の後には出力ファイル名,最後の引数にしているのはフォントが埋め込まれていない,今回操作を行ないたいファイルへのパス.
言うまでもないけれども,-sFONTPATH="" には : 区切りでフォントへのパスを書く.

2016年10月31日月曜日

標準エラー出力を pipe で受け取る

たまに標準出力エラーについて加工したくなることがある.
しかし,単純に|を使っても出力は受け取られないので,加工に使うコマンドの標準入力は空のままである.
次のようにすれば良い.
$ mage? 2>&1 >/dev/null | magemge!
これは,一度標準エラー出力をリダイレクトして,標準出力に投げなおしているだけである.つまり以下でも同じことができる.
$ mage? 2> /dev/stdout 1> /dev/null | magemage! 

2016年9月14日水曜日

PS VIta をハックしよう

インロダクション

ずっとまえにこんな記事を書いた私がこのネタを逃すはずがなかった.
そもそも低レイヤに興味をもつ切っ掛けのひとつが PSP のハックシーンだったので,
そのハックシーンの人達がおおきく影響している PS Vita に興味がないわけがなかった.

その PS Vita だが,今年 2016 年の 7 月終わりになりにわかに動きを見せはじめている.

背景と経緯

以前は,PS Vita に内蔵されている PSP エミュレータについて,PSP のファームウェアのバグをつつく形で PSP の Homebrew を起動させることが主流だった.Homebrew はビールの自家醸造を指す単語だが,転じてハックシーンでは自作アプリケーションをコンソールゲーム機で動作させることをいう.PS Vita は PSP の反省からなのかゲームメディアもセーブデータなどを格納するメモリーカードも独自規格かつ暗号化されており,バッテリーを自分で取り外すことも不可能になっていた.
OS には *BSD ベースのものが採用されており(未確認.一部のソフトウェアスタックだけという話も.FreeBSD と NetBSD のふたつについてライセンスされている),ASLR も有効化されてるという.

だが,実はこの PS Vita に搭載されているブラウザのレンダリングエンジン,WebKit の改造版に exploit が存在しており,PS Vita でネイティヴに Homebrew が動作させられるらしい.

そんなこんなで去年登場したのが,Rejuvenate,若返りを意味するハックである.
Yifan Lu 氏によるハックで,PlayStation®Mobile 向けに作った Homebrew が未署名でも動作する.しかし,この PlayStation®Mobile のサービスは去年終了してしまい,Yifan Lu 氏もこの Rejuvenate の開発を停止した.なにより,導入が煩雑であった.

今回の手法

今回登場したのは,またもや Yifan Lu 氏による WebKit exploit で,その名前も
HENkaku(変革)である.
これはとても簡単で,ファームウェアバージョン 3.60 の PS Vita のブラウザで,
上記サイトにアクセスし install ボタンをタップすれば良い.
すると,PS Vita のホーム画面に,molecularShell というバブルが追加され,
VitaShell という PSPFiler を彷彿とさせるファイラーアプリが起動できる.
このファイラーアプリは FTP サーバを兼ねており,FTP を通して自作アプリを送りつければ何でもあそべる.
ちなみに,HEN (Homebrew ENabler) は PSP のハックシーンから使われている用語である.

実装

このハックの詳細は実は開発者が自らブログで詳解しており,PoC も載ってる.
JSArray というコレクションのソートをするメソッド内で toString() が使われており,
これにバグがあって任意コードを配置することが可能だったため,
任意コード実行脆弱性が発生したらしい.
しかも,どうやらカーネル exploit らしいという噂もある.

ちなみにこの穴はファームウェア 3.61 で即座に塞がれた.

バックアップゲーム

また,関連して,案の定というかゲームのバックアップとそれの起動手段が出現した.
これについてはゲームの海賊版を推進し,なおかつ PS Vita のハックシーンをあやうくし,
PSP のときのいたちごっこの再現になるので微妙なところである.
バックアップツールは Vitamin,Vitamin でバックアップしたゲームで使える,PSP のときのようなプラグインのサンプルが Amphetamine,ゲームをバックアップするときに Vitamin がアプリデータベースに注入するデータのコードネームが Morphine とまあ,
ネーミングセンスはあるけどクロい.
試してみた.
我が故郷島根を舞台にした角川ミステリーゲームのゲーム,「√Letter ルートレター」である.というかゲームこれしかまだもってない.
ちなみに,結果は起動に失敗.何かのモジュールが足りないようだ.libc.suprx など差し替えたりしてみると動くかもしれないらしいけどすくなくとも手元では失敗している.

なお,このツールは eboot.bin を復号する処理があるっぽいので少なくとも日本では限りなくクロである.試したものが動かなくてよかった.きっともう使わない気がする,使わないほうが良さそうだ.

開発ツール

Rejuvenate は PlayStation®Mobile を利用するため,Unity とか用意したりちょっと面倒だったらしい(試してない)べつに VitaShell なども動作してた模様. いまは開発停止してるが,https://github.com/psp2sdk といった SDK が当時からあったようだ.
が,今回については PSPSDK のときみたく VITASDK が出てきた.
https://github.com/vitasdk
GNU Toolchain でサクサクっと使えるようだ.
https://vitadev.github.io/
こちらの成果をつかえば,上記 SDK がビルド済みバイナリで簡単に入るみたい.
追加情報:

関連項目

PSP のハックシーンでは有名で,氏のサイトは重要な情報の集積地と議論の場になっている,wololo 氏によって PS Vita の Homebrew コンテストが今日から開催される模様.
コンテスト名,GekiHEN(激変).合計 $800 の賞金が準備されているそうです.
http://wololo.net/2016/09/13/announcing-gekihen-homebrew-contest-ps-vita/
コンテストのレギュレーションや詳細はこちら

本記事執筆時点では早速最初のエントリーがあらわれていた.名前は luaIrc で,
PS Vita が IRC クライアントになるものだ.Lua Player により実装されている.
PSP の Homebrew の初期も Lua Player でいろいろ実装がされていた.

まとめ

色々手を尽くしセキュリティを強化したコンソールゲーム機であっても,バグは無くならないので思いもよらないところから突破される.これはなかなか教訓的だなあと感じるとともに,しかしこういった盛り上がりに興奮を隠せない悪い自分がいるのも見つけてしまうのでした.いやしかし,またなんでもありな感じになってきてしまいましたね……
既に ゲームボーイアドバンスやニンテンドー DS のエミュレータ,DOOM などが移植されています.

VAIO Z(フリップモデル)に Arch Linux をいれる

自分のメインマシンである VAIO Pro 13 | mk2 が不慮の事故で一部破損したので,
実用上一切問題ない箇所だったが修理送りにした.

そこで,今研究室で貸与されている VAIO Z(フリップモデル)にVAIO Pro 13 | mk2 の環境を全部転送することにした.
ちなみに,もちろんデュアルブートにしてる.Windows 消すの勿体なく感じるんですよねぇ.びんぼーしょー.

以下,覚書


  • initramfs には nvme モジュールを含める.
  • btrfs の subvolume にしていた /home は,read-only で snapshot を作成して,btrfs-send で全部送ってやることで /home をそのまま新環境にそっくり移した.
  • その際に,mbuffer を使って転送した
  • 受け側は mbuffer の stdout を btrfs-receive が受ける
また,VAIO Z(フリップフロップモデル)は N-Trig の筆圧感知のタッチスクリーンとペンが付いている.しかし,Linux の X や Wayland はデフォルトではこれを使えない.
次のようにする.
これを /etc/X11/xorg.conf.d に配置しておくことで,ペンを認識するようになる.

最後に,自動回転についてだが,現状これに対応していない.
iio-sensor-proxy というツールを使えば自動回転に対応できるのだが,
そのためのセンサーのドライバがそもそも存在していないためである.
これは Intel Integrated Sensor Hub (Intel ISH) というデバイスのドライバが必要である.
このドライバは先頃 LKML にパッチが投稿,議論されており,ついには
https://lkml.org/lkml/2016/9/7/98
のとおりに hid/for-next のツリーにマージされた.
おそらく Linux 4.9 から使えるようになるだろう.

2016年8月18日木曜日

ビルドしたx86_64なPC向けの「lk」カーネルをQEMUで動かす

前回の記事の続き.

ビルドしたものはscripts/do-qemux86-6を付けると動かせる.
が,このスクリプトを走らせるとmakeでlkのビルドをしなおそうとする.

正直単にQEMUを起動するだけなので,次のコマンドをlkのプロジェクトディレクトリのルートで行なえば良い.
$ qemu-system-x86_64 -m 512 -smp 1 -machine q35 -kernel build-pc-x86-64-test/lk.elf -nographic
-enable-kvm -cpu hostを付けるとか-nographic外して-serial stdio付けるとか,-m-smpの後ろの数字変えてメモリ割り当てやVCPU数変えるとか,
scripts/do-qemux86で指定できるオプションでの引数の変更とかは勝手にすれば良いと思う.