Recommended
More Related Content
What's hot
What's hot (20)
Similar to Ikarashi Bachelor Thesis
Similar to Ikarashi Bachelor Thesis (20)
More from pflab
More from pflab (18)
Ikarashi Bachelor Thesis
- 1. Fast Inter-Unikernel-as-Process Communication by Sharing Memory メモリ共有による高速なUnikernelプロセス間通信 情報科学科４年 加藤研究室 05-171005 五十嵐将
- 3. コンテナの課題 OS Kernel システムコール 隔離されたリソース app app コンテナ間の資源アイソレーションはOS Kernelの安全性に依存 スコープ外の 資源アクセスは Kernelがブロック
- 4. コンテナの課題 OS Kernel システムコール 隔離されたリソース app app コンテナ間の資源アイソレーションはOS Kernelの安全性に依存 Kernelは膨大で不具合あり
- 6. OS Kernel Unikernels as Processes*のアイソレーションモデル 従来のコンテナ Unikernels as Processes OS Kernel スコープ外の資源アクセスが システムコール呼出レベルで 不可能 必要最小限（300超中7つ）以外 のシステムコール呼出を禁止 システムコール システムコール *Williams, et al. SoCC 2018 syscall filter app app 隔離されたリソース
- 7. OS Kernel Unikernels as Processesの制限 従来のコンテナ Unikernels as Processes OS Kernel open open read syscall filter open mmap open mmap 同じファイルを open openは不許可 共有領域 app appappapp 動的なプロセス間通信が不可能 隔離されたリソース
- 8. 提案： Inter-Unikernel-as-Process Communication (IUPC) Unikernel as Process間のメモリ共有を実現 • openを使用しない強固なアイソレーション • メモリ共有による高速なプロセス間通信 clock_gettime ppoll read write pread64 pwrite64 exit_group recvmsg close mmap munmap 従来のUnikernel as Processで 許可されているシステムコール ＋ openは許可しない 新規に許可する システムコール app A app B openopen syscall filter
- 14. IUPCにおける共有メモリの作成方法 OS Kernel syscall filter app A app B 仲介 プロセス 4.チケット受渡し ネットワーク 通信 ticket 隔離されたリソース
- 17. 評価 評価環境 • Intel Core i7-4610M 3.00 GHz CPU (2 cores / 4 threads) • DDR3 SDRAM 16 GB • Linux 4.15 評価方法 • seccompを用いてUnikernel as Processを模倣したテストプログラム • パケット型通信と共有メモリ上のリングバッファを通した通信を比較 • リングバッファサイズを変えて計測 • 1KB Ring • 4KB Ring • 16KB Ring • 64KB Ring 共有メモリ上のリングバッファ 送信側 app 受信側 app read write IUPCによる共有メモリを用いた通信
- 19. 結論 • IUPC（Inter-Unikernel-as-Process Communication）を提案 • 共有メモリを使った高速な通信 • openを使わない強固なアイソレーション • IUPCによってスループットを最大7倍改善 • メッセージサイズに関わらず効果的 • メッセージサイズに対して十分なリングバッファサイズが必要
Editor's Notes
- この研究の背景として、クラウドにおける資源管理がございます クラウド事業者にとって、その所有するハードウェア資源を効率的に利用するためには、1つのハードウェアあたりのユーザ数を増やすことが重要になっています その際には、ユーザに提供する環境を仮想的に用意することになりまして、各ユーザは全く関係のない人物であると仮定されるため、各ユーザの環境間でアイソレーションが必要になってまいります ユーザに提供される既存の環境の抽象化方法としては、たとえば仮想マシン、コンテナなどというものがありまして、それぞれで独自のアイソレーションを実装しております。 このうち、コンテナでは、OSの資源の抽象化が利用可能となっております
- しかしながら、既存コンテナの実装には課題がございます というのは、コンテナ間の資源のアイソレーションは、OS Kernelの安全性に依存しているという点です。 既存の実装では、コンテナの中のプロセスからのリソースアクセスは、OS Kernelの機能によってアイソレーションされていますが、一方でOS Kernelは膨大であり、不具合も多くKernelの中に含まれていると考えられ、その不具合によってコンテナ間のアイソレーションが破綻する可能性にさらされていると考えられます このような既存のコンテナの実装のアイソレーションの問題を、Unikernels as Processesという先行研究では、次のように解決しました 矢印の説明 OS Kernel 20行に1個バグがある 火じゃない
- しかしながら、既存コンテナの実装には課題がございます というのは、コンテナ間の資源のアイソレーションは、OS Kernelの安全性に依存しているという点です。 既存の実装では、コンテナの中のプロセスからのリソースアクセスは、OS Kernelの機能によってアイソレーションされていますが、一方でOS Kernelは膨大であり、不具合も多くKernelの中に含まれていると考えられ、その不具合によってコンテナ間のアイソレーションが破綻する可能性にさらされていると考えられます このような既存のコンテナの実装のアイソレーションの問題を、Unikernels as Processesという先行研究では、次のように解決しました 矢印の説明 OS Kernel 20行に1個バグがある 火じゃない
- しかしながら、既存コンテナの実装には課題がございます というのは、コンテナ間の資源のアイソレーションは、OS Kernelの安全性に依存しているという点です。 既存の実装では、コンテナの中のプロセスからのリソースアクセスは、OS Kernelの機能によってアイソレーションされていますが、一方でOS Kernelは膨大であり、不具合も多くKernelの中に含まれていると考えられ、その不具合によってコンテナ間のアイソレーションが破綻する可能性にさらされていると考えられます このような既存のコンテナの実装のアイソレーションの問題を、Unikernels as Processesという先行研究では、次のように解決しました 矢印の説明 OS Kernel 20行に1個バグがある 火じゃない
- Unikernels as Processesでは、動作をするために許可されているシステムコールが、Linuxの300を超えるシステムコールのうち7つと必要最小限にしぼられており、それ以外のシステムコール呼出がすべて禁止されております。 そのおかげで、Unikernels as Processesでは、スコープ外の資源へのアクセスを特定のシステムコール呼出を禁止するという方法でアイソレーションを実現しております。 Unikernels as Processesというプロセスのアイソレーション手法 7つのLinuxシステムコールで動き、それ以外のシステムコールはブロックできる システムコールの種類レベルの制御による高い信頼性
- プロセス間通信 IPCはつかわない
- openが禁止されているため、 可能な操作は極めて限定的
- 左は
- 「スループット計測」を書く
- 黄色はみづらい レジェンドを変える→従来のパケット型通信 Mbps→Gbps