遅刻しました．ごめんなさい．
本稿はシステム系論文紹介 Advent Calener 2016，2 日目の記事になります（大遅刻）．
今回はHIL: Designing an Exokernel for the Data Center を紹介します．
まず始めに，表題にもある，
しかし，OpenStack Ironic は勿論 OpenStack ユーザ向けですし，xCAT は HPC 分野でのデプロイのためのツールで，用途によって様々です． 抽象化の実現の仕方も様々ですので，すると例えばクラスタの管理者はソフトウェアのデプロイに Ironic を使うのか MaaS を使うのか決断する必要がありますし，データセンタの管理者達は，それぞれのツールをユーザが使えるように，サーバ群を静的にパーティションして備えるといったことが起こります．
ユーザが新しいツールを使いたかったとしても，さらにサーバ群をいくつか新しいツールのために使えるよう準備しておかなければならないため，結果としてデータセンタ管理者はそれを避けようとします．つまり，新しいツールが出ても中々使えない状況が起こります．
そこでこの論文では，
HIL の役割は主に，物理サーバやネットワークの確保と，これら確保したものを複数のデプロイサービス間で分離することです．しかも，その構成について，手動の管理なく再構成が可能になります．具体的には，1) 物理サーバの確保 2) ネットワークの確保 3) サーバとネットワークの接続，が HIL が提供する基本的な機能です．また，追加的な機能としては，1) HIL のマネージドネットワークへの VPN 接続 2) パワーサイクルやブートデバイス選択のようなものを安全に行なうノード管理機能 3) 確保されたリソースの追跡，などがあります．また，サーバープールごとに 1 つの HIL インスタンスを置き，管理することで，巨大なデータセンタを複数の会社や研究グループが管理する状況にも対応します．
HIL の構造について，図3. を見て下さい．HIL のコンポーネントは， 3 つに分類され，コアコンポーネント，システムドライバ，オプショナルサービスとなります．本稿ではオプショナルコンポーネントについては割愛します．原論文を参照ください．
HIL のロジックの実装の大半と HIL の REST API，データベースのインターフェース，操作エンジン，アウトオブバンド管理1 のドライバを持ちます．
OBM and Auth drivers
HIL は，OBM（＝アウト・オブ・バンド管理）ドライバを通してベアメタルのノードを制御します（パワーサイクルや，ネットワークブート，シリアルコンソールのログへのアクセス）．OBM ドライバは，IPMI を使って実装され，プログラムインターフェースを提供します．また，認証と認可の決定は，auth driver へ転送されます．リクエストの説明，受け取った決定（認可の可否），オプションで認可トークンをドライバに渡すことで，認可が実行されます．
Operation Engine
ネットワーク構成の変更のような，調整操作のシーケンスへ責任を持つエンジンです．API サーバからキューを通してリクエストを受け取り，リクエスト順に処理を実行し，最終的に完了したらデータベースを更新します．
Switch drivers
operation engine がネットワーク接続の操作を行なう際に実際にその操作を受け持つ実装になります．VLAN などを用いて，他のプロジェクトや外部システムから，プロジェクトへのアクセスを拒否し保護するといった事を実現します．
プロトタイプ実装は 3000 行以下（ただし PoC）．48 の Cisco UCS C220 M32 ノードで日々基本的な production に使用されています．表1. は，このクラスタで，HIL を 13 ヶ月間稼動させ取った操作の数の統計で，表2. はこれらのコアの操作について，かかった時間の中央値と標準偏差を取ったものです．これは各操作を 250 回繰り返した場合の統計値です．スイッチと対話しない，データベースの操作のみで完結する操作の場合，数十ミリ秒で操作が終了しており，ネットワークの接続を要する操作も数秒で終わっています．
図4. は同期的な API の実行を，クライアント数を増加させた場合の処理にかかる時間を見たものです．基本的に，クライアント数が増えても実行時間は増えておらず，alloc_net と free_net は多少実行時間が増えていますが，スケーリングしていると言えます．ノードの解放だけ異様に実行時間が長いのは，ノードの解放の前に
次に，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 を共存させることにも成功しています．
実際のデータセンタで 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．
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 で借りる場合のコストをそれぞれ仮定している
本稿はシステム系論文紹介 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 の概要図 |
構造
 |
| 図3. HIL のデプロイのコンポーネント |
HIL API
HIL の資源は，ユーザの集合に管理される project が基本になっており，この project は nodes と networks という要素を持っており，nodes，つまりサーバは networks へ接続される NICs を持ちます．REST API を通じて操作され，ユーザは次の操作が可能です．- プロジェクト作成・空のプロジェクト削除
- ネットワーク作成・削除，パブリックネットワークのプロジェクトへの取り込み
- プロジェクトへのノード確保・プロジェクトからノードの解放
- ネットワークへの NICs 接続・ネットワークからの NICs 切断
- パワーサイクルやシリアルコンソールへのアクセスのようなノードの管理
- 空いてるノードの一覧表示，プロジェクトへのノードとネットワーク割り付け，ノードやネットワークの詳細取得，などのクエリ
コアコンポーネントとドライバ
HIL ServerHIL のロジックの実装の大半と 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. 秒当たりの中央値と標準偏差 |
 |
| 図4. 同期的な API の並列性 |
 |
| 図5. 非同期的な API の並列性 |
ipmitool を実行してコンソールを接続する必要があるため， 他の操作に比較して 5 倍という実行時間になっているようです．図5. は非同期な API の実行における並列性です．この操作は，ネットワークスイッチへの対話が必要であり，この計測では全てのリクエストが同一のスイッチに向けられていることがボトルネックになってします．スイッチがスケールするより巨大な環境で，HIL に最適化されているのであれば，並列性はさらに向上するのではないかと原論文の著者は推測しています．
 |
| 図6. HIL で区画された環境へ，Hadoop 環境をベアメタルと仮想環境（OpenStack）それぞれ用いてデプロイした時のパフォーマンス |
ところで，HIL そのものは，例えばリクエストに対しどのノードを確保するべきか選択する，といったようなスケジューリングはしません．そこで，HPC クラスタで広く使われている SLURM スケジューラを導入し，HIL リクエストに特別の名前空間を設けることで，HIL と SLURM を共存させることにも成功しています．
経済効果
 |
| 図7. 1 週間での リアルタイムワークロードと HPC ワークロードが必要とした c4.xlarge インスタンスの数 |
 |
| 図8. 1 週間でのシステムの利益（5000 の Linux がホスト可能な，US-East-1a にある c4.xlarge の EC2 インスタンス） |
図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 で借りる場合のコストをそれぞれ仮定している