タイトル長いな…
OpenStack 触ってたときに感じた vSphere リソース抽象化 の話。
OpenStack とは
今となっては言わずもがな、オープンソースで開発されているクラウド基盤。
ja.wikipedia.org
コンピュートリソースやネットワーク、ストレージなどのハードウェアを抽象化して管理し、リソース操作 API を提供する。またユーザやテナント管理を提供し、サービス利用者は API を通じて On-Demand でのリソース利用を可能としている。
リソースの実体はバックエンドに存在している KVM や vSphere などの仮想化機構や物理ハードウェアから払い出される。 仮想化機構や物理ハードは OpenStack のコンポーネントからコミュニティや各ベンダで開発されている Driver や Plugin を通して操作され、リソース提供が行われており、OpenStack 自体が仮想化や Networking の機能を持ち、リソース提供しているわけではない。
OpenStack 自体が仮想化機能を持っているわけではない。(ここ重要)
vSphere vs OpenStack ?
上記の通り、OpenStack は仮想化機能を持っておらず、機能として競合するわけではないので、vSphere (ESXi) と競合するものではない。
というか、 VMware 社が VMware Integrated OpenStack (VIO)として提供、サポートするディストリビューションがあるぐらいの共存するべき存在のもの。
www.vmware.com
強いて言えば vCloud Director が競合しているんですかね？
vCloud Director は実物見たことないのでほとんど分からないんですけど…
VM リソースの払い出し
OpenStack での VM リソース払い出しは nova というコンポーネントが担当している。
ネットワークやストレージは他のコンポーネントになっているので今回は割愛。
KVM
バックエンドが KVM の場合、構成としては以下。
nova-api, nova-conductor, nova-scheduler というプロセスが全体の Controller として管理を行い、nova-compute プロセスが各 HV 上に存在し libvertd 経由で各 VM を操作している。
大事なのは各 HV 毎に nova-compute プロセスが必要。
vSphere
一方で vSphere の場合の構成。
nova-api, nova-conductor, nova-scheduler は特に変わらないが、nova-compute は各 HV 上に存在するわけではなく、Controller の一部として存在し、ここから VMware 用の Driver 経由で vSphere API を叩く。
(ESXi 上にホイホイデプロイできないしね…)
KVM の場合だと HV 毎に必要だった nova-compute プロセスですが、
この構成の場合、nova-compute は vSphere のクラスタ毎に必要となる。
vSphere クラスタ = 巨大 HV
OpenStack での VM 起動は nova-scheduler が管理下の HV の残リソースや構成などから決定し、該当 HV 上の nova-compute に対し VM プロセスの作成を指示する。
vSphere の場合、nova-scheduler はどの vSphere クラスタ上に作成するかまでを決定し、どの HV 上に立てるかは vCenter の DRS 側でスケジューリングを行なっている。
※ なので OpenStack - vSphere 構成の場合、DRS (完全自動化) が要件になっている。
参考：OpenStack Docs: VMware vSphere
また、OpenStack 側で各 HV の残リソース情報を確認した際、nova-compute 経由で情報を取ってきているので、vSphere 構成だと表示される情報はクラスタリソースの合計値になっている。
つまり、OpenStack から見た場合、vSphere クラスタ = 巨大 HV とみなし、それにより KVM 構成と同じ nova プロセス構成で実現できている。
その根底にあるものは
OpenStack から話を展開してきましたが、別に vSphere クラスタ = 巨大 HV は OpenStack に限らず、vSphere が元々持っている抽象化の思想だと思います。
各 HV リソースを抽象化してリソースプールとし、必要に応じてリソースを払い出すというまさに仮想化、抽象化の神髄だが、このレベルでそれを実現できている製品は知っている限り他だと見当たらないような…
vSphere はそこに多くの実績があり、個人的にはアドバンテージの 1 つになっています。
そして、これを実現できているのは vMotion と DRS がかなり大きい。
vMotion は Live Migration として KVM もできたりするが、各 HV のリソース状況を取得して評価し、偏りが発生した場合は自動的に vMotion で均一化する DRS 相当の機能を実現しているものはあまり聞いたことなく…あるのかな？
まぁ、vMotion 自体も信頼と実績が違いすぎる気も。
実際 KVM 構成の OpenStack だと結局 HV 単位のプロビジョニングベースでのリソース管理となっており、ノイジー問題を引くことも多々あった。
vSphere 構成の OpenStack だとクラスタ単位でのリソース管理となり DRS が効いているおかげでノイジー問題を引くことも少なかった印象。
(諸事情によりオーバーコミットはあまり攻めなかったが、おそらく KVM より攻めても全然大丈夫そう)
結局のところ
何か発散しそうなので無理矢理締めると
- vSphere のリソース抽象化はすばらしい
- vSphere クラスタ = 巨大 HV
- その根底には vMotion と DRS
クラウド的に On-Demand で VM が作られる環境での vSphere は積極的に DRS を入れておくのがおすすめ。
これにリソースプールとかアフィニティルールがあったりでかなり緻密に管理できたりするのですが、On-Demand だとオーバースペックかも…
(リソースプールはともかく、アフィニティは都度 VM に適用なので)
