はじめに

昨年の vmworld で発表になった Photon Controller は、同じく昨年の DockerCon EU で OSS 化が実現され、現在 Github 上でソースコードが公開されています。また、VMware Fusion/Workstation で試すことが出来る仮想アプライアンスも提供されているので、直ぐにでも試すことが出来ます。すでに記事もいくつか見つけることが出来ます。

• Photon-ControllerでDockerを動かしてみる
• VMware Photon Controllerの使い方

しかし、このお試し仮想アプライアンスは Github 上に公開される前のコミットだったり、DockerCon EU 以降ですでに Photon Controller 自体のコードも変わりつつあるので、詳しく確認したい場合には余り役に立たなくなりつつあります。

このエントリに始まるシリーズで、Devbox をビルドして ESXi を管理できるようにするところまでを追いかけたいと思います。

この記事は PROMOTED-3809 を元に執筆しています。

Photon Controller とは

ほんとに触りだけであれば、こちらの記事を…

VMware Photon Controller Deep Dive
VMware Photon Controller をオープンソース化

Photon Controller は、超大規模仮想環境向けのコントロール プレーンであり、コンテナクラスタ デプロイ エンジンになります。

もともとは、10,000 ESXi 以上、1,000,000 VM 以上を単一のコントロール プレーンで管理したいという要望を実現するためのコントロール プレーンとして開発が進められていました。vCenter Server のバージョンにも依るのですが、単一の vCenter Server で 3,000 VM クラスを管理しようとすると、ちょいちょい vCenter Server が根を上げることがあります。具体的には

• パフォーマンスデータのロールアップが正常に行われない
• Web Client での表示が異様にモッサリして使い物にならない
• API/Web Client での操作の一つ一つに異様に時間が掛かる

などです。DB の IOPS が足りないなどの問題もありますが、チューニング/ダイエット (特に統計情報レベル/イベント) なしの vCenter Server を使われているケースでは 大体この辺りからサチります。

All Flash Storage ならばもう少し頑張れるやも…

しかし、世の中には 3,000 VM どころか 100,000 VM 以上稼働させているユーザーもいたりするため、そのため出来てしまう vCenter Server の山をどうにか出来ないかという話があります。そこで、

• vMotion なし
• vSphere HA なし
• DRS なし
• そのほか無い無い尽くし

ではあるものの

• x,000,000 VM 対応 (目標)
• x0,000 ESXi 対応 (目標)
• マルチテナント
• RESTful API によるフルアクセス
• 可用性はアプリケーションで実装することを前提

といった今風なコントロール プレーンとして Photon Controller は実装されています。発表時にはコンテナ クラスタ (Kubernetes, Mesos, Swarm) をデプロイするエンジンとして、紹介されていますが、本質的には超大規模仮想環境向けのコントロール プレーンになります。コンテナ クラスタはその超大規模仮想環境を消費するための一要素でしかありません。

Photon Controller の構成

概要の絵は こちら にありますが、いくつか現状のソースコードとまだ一致しないところもあるので補足しながら紹介します。

API Front End

RESTful API のフロントエンドとなり、Photon Controller への全ての API コールを捌きます。単純に API のだけではなく、内部タスクの生成、VM 作成などの軽い処理は API Front End で実装されています。

Root Scheduler

VM の配置を司ります。ESXi 上で動作する Agent、Leaf Scheduler、Intermediate Scheduler と遡る木構造を構成し、その頂点の Scheduler が Root Scheduler になります。この辺は OpenStack Nova の Cells v2 に似ていると思われます。

Housekeeper

EAGER イメージのクローニングや不要になったイメージの削除などを担当します。EAGER とは、ある VM ディスク イメージを全てのデータストアに予めコピーする設定で、高速なクローンを実現します。

400 VM のクローンなども想定しているので、発想自体が通常の斜め上になります。

Chairman (Health Manager?)

Scheduler の木構造の管理を行います。ESXi が登録された際に Scheduler の木構造のどこに追加されるのか？Leaf Scheduler が死んだ場合に、どのように木構造の組み替えを行うか？といったことを制御しています。

公式の絵では Health Manager とありますが、おそらくソースコード上は Chairman のこと。

Deployer/Cluster Manager

Deployer は、Photon Controller のコントロール プレーンをデプロイします。何を言っているんだ？という感じではありますが、最初にデプロイされる VM はコントロールプレーン デプロイ用 VM になります。プロダクションで使われるコントロール プレーンはこのデプロイ用 VM から、可用性やスケーラビリティに合わせた構成でデプロイされます。VMware Integrated OpenStack が Insterller VM から、コントロール プレーンを構成する VM を 17 個デプロイするのと同じ方式をとります。

また、Cluster Manager が別コンポーネントとして描かれていますが、現時点では Deployer の Java プロセスに同居しているサービスになります。この Cluster Manager は Kubernetes、Mesos、Swarm クラスタを構成する VM 群のデプロイや初期設定を流し込む役割を担います。

CloudStore

見慣れない CloudStore ですが、これが Photon Controller における永続データの保管場所となります。RDB ではなく、同じ時期に OSS 化が発表された Project Xenon をベースに作成さています。最終的には Apache Lucene に保存されるので ElasticSearch に近いかも知れません。Photon Controller には vSphere HA はないので、Project Xenon のレイヤーでデータの冗長性を確保します。

Project Xenon は優れもので Strong Consistency にも Eventually Consistency にも対応したデータストアも持っています。初期のコードを見ると Hibernate で PostgreSQL を使った形跡を確認出来ますが、vSphere HA なしの可用性の確保を考えた場合の面倒くささもあって、Project Xenon にしたのかもしれません。

Zookeeper

全てのコンポーネントは Zookeeper にて分散環境での状態管理を行っています。

API Front End から Zookeeper までが管理 VM 群で動作するコンポーネントになります。

Leaf/Intermediate Scheduler

個人的にはこのコンポーネントが Photon Controller において最も驚いたところです。

Leaf Scheduler および Intermediate Scheduler は、なんと ESXi 上で動く Python のスクリプトで実装されています。仮想アプライアンスで実装しても vSphere HA でフェイルオーバーできないのだから、vmkernel で動かしてもいいじゃない、と言わんばかりです。Scheduler の処理自体は単純で、下位の ESXi Agent あるいは Scheduler のスコアを収集しているだけなので、それほど負荷はありません。

Agent

Agent は ESXi 上で動く Python のスクリプトで実装されています。Agent は ESXi の Hostd と通信し、ESXi に対する操作を実現します。ESXi は以下のいずれかの役割を担います。

• 純粋なリソースとしての ESXi / Agent のみ
• Leaf Scheduler 兼 リソースとしての ESXi / Leaf Scheduler と Agent
• Intermediate Scheduler 兼 リソースとしての ESXi / Intermediate Scheduler と Agent

各コンポーネントの通信方法

ESXi のコンポーネントは Python ですが、それ以外は Java で実装されているため、何らかのシリアライゼーションが必要になります。Photon Controller では、この言語を超えた通信を Apache Thrift によって実現されています。しかし、最近追加された CloudStore や Cluster Manager は Project Xenon で実装されており JSON+RESTful API なので、将来的にどうなるかは注意しておくと良いと思われます。

余談

tenant、project、disk などなど登場しますが、まぁ世の中の時流に乗ったと言うことで…。

対外的に端的に紹介して！といわれるときは、「OpenStack Nova+Magnum でっせ」と前置きして説明することも しばしば。

さらに余談

気軽に使われる Deep Dive という言葉に抵抗が出てきたため Insight としてたり…本家の Link も Introduction であって Deep でも何でもないのよね…