自作仮想化基盤

「n0stack」の紹介

ぱろっく

hnron

h-otter

kyontan

法政大学

日本工学院八王子専門学校

電気通信大学

電気通信大学

- ContainerSIG (Special Interest Group)

- But...

- No

- No

- No Jail

Attention!

- ContainerSIG (Special Interest Group)

- But...

- We use

Attention!

自己紹介 (@hnron)

- 日本工学院八王子専門学校

- ITスペシャリスト科 4年

- ICTSC (第3-6回参加) (第7-9回運営)

- 自宅ラック勢

- OpenStack

- 自宅にBGPフルルートが来てたり

自己紹介 (@h-otter)

- 電気通信大学総合情報学科３年

セキュリティコース

- ICTSC運営 (第6 ~ 9回)

- アルバイト@

- 自宅ラック勢

- openstack on k8s

自己紹介 (ぱろっく)

- @porisuteru

- 法政大学理工学部４年知的情報処理研究室

- ICTSC運営委員（第5 - 9回）

- アルバイト@

- インターン@

- 機械学習✖️セキュリティを研究

- @sukukyon

- https://monora.me

- 電気通信大学情報理工学部 3年

- 元 ICTSC 運営委員 (第5 - 8回)

- アルバイト@ &

- 就活中 (?)

自己紹介 (@kyontan)

自宅サーバ群 (FreeBSD, CoreOS, ...)

ICTトラブルシューティングコンテスト

- 通称 ICTSC (ICT Trouble Shooting Contest)

- https://icttoracon.net

- 学生によるインフラ技術を中心に出題される

トラブルシューティング大会

- 次回は第9回＠さくらインターネット株式会社大阪本社

開発の動機- これまでは CloudStackや OpenStackを用いていた

- CloudStackはネットワークの構造等の自由度が低く、

ICTSC に用いるのが難しかった

- OpenStackは比較的自由度が高かったが、ICTSC で使う際に

毎回特殊な構築の仕方を取る必要があった

- どちらを用いた場合でも、学習コストや不具合が発生した時の

デバッグのコストがとても高かった

- クラウドを理解するためにクラウドを作ってみる

We introduce …

全体の構成

- 各コンポーネントやエージェントを分割して開発

- リソースをそれぞれ抽象化するエージェントを作る

- IaaSとしてコンポーネントをまとめる

- Compute, Network, Volume の依存は比較的大きい

- ex. Nova と Neutron と Cinder

→ OpenStackやKubernetesの構造を参考にしながら粒度を調整

インターフェイス (OpenStack)

- VMを作るには…

- Neutron でネットワークを作って

- Neutron でサブネット・ポートを作って

- Nova で VM を立てて…

- Cinder でディスクをつくって

- いろいろアタッチして…

- Heat…？ Murano…?

インターフェイス (Kubernetes)

- サービスを提供するには…

- PersistentVolumeつくって

- Deploymentを作って

- Service作って

- いろいろ制約を追加して…

- いろいろタグでアタッチして…

しんどい

インターフェイス (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

- RESTful API

- 全ては HTTP でやる

- デバッグのしやすさを重視

- 疎結合

- agent 同士の依存を減らす

- マイクロサービスに近い

- agent は比較的密結合である

- 破綻

Architecture (0.1)

- MQ を導入

- 到達性を重視

- 容易にリトライが可能

- Scheduler / Conductor

- agent 間の調整 / 管理

- データフローを一方向に

Architecture (0.2)

Architecture (0.2)

- API Gateway

- HTTP / MQ の変換

- n0auth, n0image

- HTTP 依存部は外部へ

メッセージの流れ

- Scheduler が

必要な agent へ命令

Architecture (0.2)

メッセージの流れ

- エラーがあれば

Conductor → Scheduler で

再スケジューリング

Architecture (0.2)

Architecture (0.2)

- 依存関係があると……

- Scheduler

→ Agent

→ Conductor

→ Scheduler

→ Agent

→ ...

- 依存関係があると……

- Scheduler

→ Agent

→ Conductor

→ Scheduler

→ Agent

→ ...

必要ないのでは?

Architecture (0.2)

全体の構成 (Latest)

依存関係の通知を

Agent から直接 Agent へ

- VM に必要なディスク

... ポート

- ポート ... ネットワーク

全体の構成 (Latest)

依存関係の通知を

Agent から直接 Agent へ

- VM に必要なディスク

... ポート

- ポート ... ネットワーク

n0core

- Core Component

全体の構成 (Latest)

Messaging

- 全てのメッセージは N0stackMessage である

- Protobuf はそれ自身の型情報を持たない

N0stackMessage

Request Procedure Notification

Simple

Notification

Create

VMRequests..

Create

Network

Delete

VM

Pulsar

- Yahoo! が日米で開発した MQ (メッセージングキュー)

- レイテンシの低さがウリ

- メッセージは ZooKeeper / BookKeeper で伝達/保持

- (acknowledgement を返すまでメッセージを保持できる)

- 今は Apache Incubator の配下で開発続行中

- n0stack の MQ として採用

- MQ の扱いになれておらず色々苦労中

Messaging

- Protobuf (Protocol buffer) 3 を全体で採用

- agent 間でのスキーマの統一

- 文字列/数値等の最低限の型は保証できる

- 列挙型もある

- Protobuf 3 では全てのフィールドが optional (なくてもよい)

- シリアライズできたからといってエラーが起きないわけではない

- API Gateway

- クライアント (WebUI, CLI) からのリクエストのルーティング

- Authentication, Authorization

- Kong, Traefik などを使いたい (未検証)

- 未着手

n0gateway

api

Clients

MQ

api

- HTTP - MQ の橋渡し

YAML, JSON, ...

Protobuf

scheduler

- ホストのリソースを元にVMのスケジューリング

- filter / weight

- APIから送られてくるprocedureの分割

- 各コンポーネントへリソースの作成リクエストを送る

networker

- 外部ネットワークから

VMへの疎通を確保

- n0stack側から外部の

router/switch を操作

- NAPALM

- BGPで外部のrouterに

VMのIPを/32で広報

- GoBGP

porter

- VMのnetworkを抽象化

- ブリッジの作成 &

DHCPによる IPアドレスの割当

- 複数のタイプに対応

- flat

- vlan

- ...

volumer

- VMイメージ等の管理

- リソースプールの作成

- 作成

- 削除

- ダウンロード

- マイグレーション

compute

- VMの管理

- 作成

- 起動

- 停止

- 複製

- デバイス追加

- スペック変更

- マイグレーション

compute

- ハイパーバイザにKVMを使用

- libvirtを用いてKVMを管理

libvirt

- RedHat が主体となって開発している OSS

- KVM や Xen などのハイパーバイザを管理する抽象化ライブラリ

- C / Python / Java などから API を利用可能

libvirtを使う理由

- 将来的に様々なハイパーバイザに対応させやすい

- Linux Containers (LXC) もサポートしている

- コンテナの管理も可能に(?)

進捗

着手し始めた部分

- Scheduler

- Compute

- Volumer

- Porter

- Networker

: Procedure 設計

: ほぼ完成

: Attach 以外ほぼ完成

: MQと結合以外は完成

: gobgp 検証中

- 0.1 Release (Soon)

- 色が濃い部分の基本動作

- (0.2, ...)

- 1.0: 全体の完成

- ICTSC9 (2018/3/3, 4)

- 導入判断は 2017/12 😂

- 間に合わせたい

Schedule

様々な形でのサポートを

お願いします!! 🙏

Thanks / Check it out!