Container SIG 2017 Fall にて発表した資料です (pp.31-37 にて画像が一部乱れていますが、ご了承ください)

1. 自作仮想化基盤
「n0stack」の紹介
ぱろっく
hnron
h-otter
kyontan
法政大学
日本工学院八王子専門学校
電気通信大学
電気通信大学

2. - ContainerSIG (Special Interest Group)
- But...
- No
- No
- No Jail
Attention!

3. - ContainerSIG (Special Interest Group)
- But...
- We use
Attention!

4. 自己紹介 (@hnron)
- 日本工学院八王子専門学校
- ITスペシャリスト科 4年
- ICTSC (第3-6回 参加) (第7-9回 運営)
- 自宅ラック勢
- OpenStack
- 自宅にBGPフルルートが来てたり

5. 自己紹介 (@h-otter)
- 電気通信大学 総合情報学科 ３年
セキュリティコース
- ICTSC運営 (第6 ~ 9回)
- アルバイト @
- 自宅ラック勢
- openstack on k8s

6. 自己紹介 (ぱろっく)
- @porisuteru
- 法政大学 理工学部 ４年
知的情報処理研究室
- ICTSC運営委員（第5 - 9回）
- アルバイト @
- インターン @
- 機械学習✖️セキュリティを研究

7. - @sukukyon
- https://monora.me
- 電気通信大学 情報理工学部 3年
- 元 ICTSC 運営委員 (第5 - 8回)
- アルバイト @ &
- 就活中 (?)
自己紹介 (@kyontan)
自宅サーバ群 (FreeBSD, CoreOS, ...)

8. ICTトラブルシューティングコンテスト
- 通称 ICTSC (ICT Trouble Shooting Contest)
- https://icttoracon.net
- 学生によるインフラ技術を中心に出題される
トラブルシューティング大会
- 次回は第9回＠さくらインターネット株式会社 大阪本社

10. 開発の動機
- これまでは CloudStack や OpenStack を用いていた
- CloudStack はネットワークの構造等の自由度が低く、
ICTSC に用いるのが難しかった
- OpenStack は比較的自由度が高かったが、ICTSC で使う際に
毎回特殊な構築の仕方を取る必要があった
- どちらを用いた場合でも、学習コストや不具合が発生した時の
デバッグのコストがとても高かった
- クラウドを理解するためにクラウドを作ってみる

11. We introduce …

12. 全体の構成
- 各コンポーネントやエージェントを分割して開発
- リソースをそれぞれ抽象化するエージェントを作る
- IaaSとしてコンポーネントをまとめる
- Compute, Network, Volume の依存は比較的大きい
- ex. Nova と Neutron と Cinder
→ OpenStackやKubernetesの構造を参考にしながら粒度を調整

13. インターフェイス (OpenStack)
- VMを作るには…
- Neutron でネットワークを作って
- Neutron でサブネット・ポートを作って
- Nova で VM を立てて…
- Cinder でディスクをつくって
- いろいろアタッチして…
- Heat…？ Murano…?

14. インターフェイス (Kubernetes)
- サービスを提供するには…
- PersistentVolumeつくって
- Deploymentを作って
- Service作って
- いろいろ制約を追加して…
- いろいろタグでアタッチして…

15. しんどい

16. インターフェイス (n0core)
- VMを作るには…
- procedure という
1つのリクエストを投げるだけ
- リソースの依存関係を解決
- 効率的なスケジューリング
- resource: vm
name: hello_vm
power_state: started
attachments:
- resource: volume
size: 10G
- resource: port
network:
type: vlan
vlan_id: 10
subnets:
- cidr: 10.0.1.0/24

17. - RESTful API
- 全ては HTTP でやる
- デバッグのしやすさを重視
- 疎結合
- agent 同士の依存を減らす
- マイクロサービスに近い
- agent は比較的密結合である
- 破綻
Architecture (0.1)

18. - MQ を導入
- 到達性を重視
- 容易にリトライが可能
- Scheduler / Conductor
- agent 間の調整 / 管理
- データフローを一方向に
Architecture (0.2)

19. Architecture (0.2)
- API Gateway
- HTTP / MQ の変換
- n0auth, n0image
- HTTP 依存部は外部へ

20. メッセージの流れ
- Scheduler が
必要な agent へ命令
Architecture (0.2)

21. メッセージの流れ
- エラーがあれば
Conductor → Scheduler で
再スケジューリング
Architecture (0.2)

22. Architecture (0.2)
- 依存関係があると……
- Scheduler
→ Agent
→ Conductor
→ Scheduler
→ Agent
→ ...

23. - 依存関係があると……
- Scheduler
→ Agent
→ Conductor
→ Scheduler
→ Agent
→ ...
必要ないのでは?
Architecture (0.2)

24. 全体の構成 (Latest)
依存関係の通知を
Agent から直接 Agent へ
- VM に必要なディスク
... ポート
- ポート ... ネットワーク

25. 全体の構成 (Latest)
依存関係の通知を
Agent から直接 Agent へ
- VM に必要なディスク
... ポート
- ポート ... ネットワーク

26. n0core
- Core Component
全体の構成 (Latest)

27. Messaging
- 全てのメッセージは N0stackMessage である
- Protobuf はそれ自身の型情報を持たない
N0stackMessage
Request Procedure Notification
Simple
Notification
Create
VM
Requests..
Create
Network
Delete
VM

28. Pulsar
- Yahoo! が日米で開発した MQ (メッセージングキュー)
- レイテンシの低さがウリ
- メッセージは ZooKeeper / BookKeeper で伝達/保持
- (acknowledgement を返すまでメッセージを保持できる)
- 今は Apache Incubator の配下で開発続行中
- n0stack の MQ として採用
- MQ の扱いになれておらず色々苦労中

29. Messaging
- Protobuf (Protocol buffer) 3 を全体で採用
- agent 間でのスキーマの統一
- 文字列/数値等の最低限の型は保証できる
- 列挙型もある
- Protobuf 3 では全てのフィールドが optional (なくてもよい)
- シリアライズできたからといってエラーが起きないわけではない

30. - API Gateway
- クライアント (WebUI, CLI) からのリクエストのルーティング
- Authentication, Authorization
- Kong, Traefik などを使いたい (未検証)
- 未着手
n0gateway

31. api
Clients
MQ
api
- HTTP - MQ の橋渡し
YAML, JSON, ...
Protobuf

32. scheduler
- ホストのリソースを元に
VMのスケジューリング
- filter / weight
- APIから送られてくる
procedureの分割
- 各コンポーネントへ
リソースの作成リクエストを送る

33. networker
- 外部ネットワークから
VMへの疎通を確保
- n0stack側から外部の
router/switch を操作
- NAPALM
- BGPで外部のrouterに
VMのIPを/32で広報
- GoBGP

34. porter
- VMのnetworkを抽象化
- ブリッジの作成 &
DHCP による IPアドレスの割当
- 複数のタイプに対応
- flat
- vlan
- ...

35. volumer
- VMイメージ等の管理
- リソースプールの作成
- 作成
- 削除
- ダウンロード
- マイグレーション

36. compute
- VMの管理
- 作成
- 起動
- 停止
- 複製
- デバイス追加
- スペック変更
- マイグレーション

37. compute
- ハイパーバイザにKVMを使用
- libvirtを用いてKVMを管理

38. libvirt
- RedHat が主体となって開発している OSS
- KVM や Xen などのハイパーバイザを管理する抽象化ライブラリ
- C / Python / Java などから API を利用可能

39. libvirt を使う理由
- 将来的に様々なハイパーバイザに対応させやすい
- Linux Containers (LXC) もサポートしている
- コンテナの管理も可能に(?)

40. 進捗
着手し始めた部分
- Scheduler
- Compute
- Volumer
- Porter
- Networker
: Procedure 設計
: ほぼ完成
: Attach 以外ほぼ完成
: MQと結合以外は完成
: gobgp 検証中

41. - 0.1 Release (Soon)
- 色が濃い部分の基本動作
- (0.2, ...)
- 1.0: 全体の完成
- ICTSC9 (2018/3/3, 4)
- 導入判断は 2017/12 😂
- 間に合わせたい
Schedule

42. 様々な形でのサポートを
お願いします!! 🙏

43. Thanks / Check it out!