OCP Serverを用いた OpenStack Containerの検証
•Télécharger en tant que PPTX, PDF•
6 j'aime•4,666 vues
2015年1月28にCTCソリューションセンタで開催された、PoC/HVDC WG Engineering Workshop での発表資料になります。 お題目としては、OCPサーバを用いてPrivate CloudやPublic Cloudを構築するために使えるBare Metal Provisioning Toolとして MAAS のご説明と、OCPサーバを用いたOpenStack + Docker 環境で benchmark を行ない性能・消費電力の観点でどのようにメリットを引き出せるのかを考察した結果についてご紹介しました。
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à OCP Serverを用いた OpenStack Containerの検証
Similaire à OCP Serverを用いた OpenStack Containerの検証 (20)
Plus de Takashi Sogabe
OCP Serverを用いた OpenStack Containerの検証
- 1. OCP Serverを用いた OpenStack Containerの検証 2015-01-28 曽我部 崇 (Takashi Sogabe) Internet Initiative Japan, Inc MAAS + nova-docker OCPサーバを用いたベンチマーク
- 2. ハイブリッドクラウドの課題 • 容易に購入できる? • 容易に運用できる? • 性能は出る? • コストメリットはある?
- 3. OpenStack + Docker • Dockerによるコンテナ仮想化を、OpenStackの APIを用いて利用 – Docker + Heat – Docker driver
- 4. 検証内容(1) • OCP環境で BareMetal Deployment環境の構 築方法を確立し、情報を共有する – MAAS • Bare Metalサーバを直接使う
- 5. 検証内容(2) • OCP環境で OpenStack + Docker の構築手順 を確立し、情報を共有する – Docker Driver (nova-docker) • Icehouse にて コードが削除された
- 6. 検証内容(3) • OpenStack + Docker構成を性能及び省電力 の観点で比較・評価を行なう – 比較対象 • OpenStack with KVM • BareMetal (MAAS) – 測定方法 • BMCの消費電力情報を計測しながらベンチマークソフ トにより負荷を掛ける
- 7. Hardware構成(1) • Server – Wiwynn Winterfell (Windmill) – CPU: Xeon E5-2660 2.20GHz x2 • 16-core, 32-thread – Memory: 32GB – Disk: Intel SSDSC2BB24, 240GB – NIC: Intel 82599ES (10GbE)
- 8. Hardware構成(2) nova-controller nova-compute • nova-compute – OpenStack + KVM KVM OS App
- 9. Hardware構成(3) nova-controller nova-compute • nova-docker – OpenStack + docker driver docker App
- 10. Hardware構成(4) Ubuntu • Bare Metal – MAASによるdeploy App
- 11. Software構成 • Management Server – MAAS • OS – Ubuntu14.04LTS • OpenStack – 2015年1月の master – devstack – Network構成 • Nova-network (FLAT DHCP)
- 12. 測定方法(CPU) • sysbench – cpu-max-prime=100000 – Num-threads={1,2,4,8,16,32}
- 13. 測定方法(Disk I/O) • fio – direct write, direct read – bs=16k – size={10GB x1, 5GB x2, 2.5GB x4, 1.25GB x8, 0.625GB x16, 0.312GB x32} – numjobs={1, 2, 4, 8, 16, 32} ※ nova-docker は device mapper に対応していないため、dockerのfio 測定については bare metal server(Ubuntu14.04LTS + docker 1.4.1 を 用いる
- 14. 測定方法(iperf) • iperf – length 128k – parallel {1, 2, 4, 8, 16, 32} – time 30sec
- 15. 測定結果 (CPU, 計算時間) 0 50 100 150 200 250 300 350 0 4 8 12 16 20 24 28 32 bare-metal nova-docker nova-kvm TotalTime(sec) Number of Threads
- 16. 測定結果 (CPU, 消費電力) 0 50 100 150 200 250 300 350 0 4 8 12 16 20 24 28 32 bare-metal nova-docker nova-kvm PowerUsage(Watt) Number of Threads
- 17. 測定結果 (Disk I/O, randwrite) 0 50 100 150 200 250 300 350 0 4 8 12 16 20 24 28 32 bare-metal docker-dev-mapper nova-kvm Number of Threads Throughput(MB/s)
- 18. 測定結果 (Disk I/O, randread) 0 50 100 150 200 250 300 350 400 450 500 0 4 8 12 16 20 24 28 32 bare-metal docker-dev-mapper nova-kvm Number of Threads Throughput(MB/s)
- 19. 測定結果 (net, outbound) 7 7.5 8 8.5 9 9.5 10 0 4 8 12 16 20 24 28 32 bare-metal nova-docker nova-kvm Number of Threads Throughput(Gbps)
- 20. 考察(CPU) • nova-docker スレッド数が1, 2の際に性能が低 い – スレッド数が4以上になると性能低下は見られな い • 消費電力はCPUの負荷に応じて大きく変わる
- 21. 考察(Disk I/O) • docker (device mapper)のI/O性能は、bare metal と比べて少し低い程度 – docker(aufs)はおそらくさらに性能が低くなる • aufs を使うと direct i/o の測定が出来なかったので、グ ラフでは docker(device mapper) のみを掲載 • kvmの randwrite性能が低い • 一時データ、キャッシュの用途でローカルディスクを 使う場合、kvmはボトルネックが大きくなってしまう
- 22. 考察(net) • nova-dockerの場合、プロセス数が1,2,4の際 に性能低下が見られる – プロセス数が少ないときにCPU性能が十分に出て いないのが原因かもしれない – プロセス数が8以上になると、10Gbpsを使い切れ る
- 23. 考察(全体) • 計算処理だけが必要な場合は、KVMでも オーバーヘッドはそれほど大きくない • Disk I/Oを多用するアプリであれば、dockerを 使うことでスループットを大幅に改善できそう • Networkについては、スループットが沢山必 要であればdocker を使うことで性能向上が期 待できそう
- 24. nova-dockerの仕組みは? • nova-docker – OpenStack (IaaS)のAPIでアプリをdeploy – KVMに比べてインスタンスの起動時間が早い – Docker(hub)のイメージがそのまま動く – 分散処理など、orchestrationをするための仕掛け は基本的に無い Novaはmachineを抽象化しているのに対し、 Dockerはprocessを抽象化している
- 25. クラウド時代のアプリケーション • 今まで – 1つの大きなサーバに手動でアプリを詰め込む • クラウド時代 – 沢山の小さなサーバに自動でアプリを詰め込む Server Hypervisor App1 App2 App3 Server Kubernetes, Mesos, etc. App Server Server
- 26. Heat + Docker • Heat – 複数のアプリを一括してdeployできるツール • novaで生成されたインスタンスに対して Docker API を操作する – Scheduler は無いので、deploy先は手動で割り当 てる – Disk I/O性能を上げるのが目的であれば、Ironic 等のbare metal deploymentが別途必要
- 27. OpenStack API + Docker API DockerOpenStack Nova Docker or Ironic Nova Docker Docker in Docker の環境で様々なOrchestratorを動かす
- 28. 様々なOrchestratorとの連携 Docker Magnum Mesos Heat Solum CloudFoundary KubernetesOpenShift PaaS Patform Orchestrator for Distributed System OpenStack Components
- 29. Magnum • OpenStackのContainer向けSchedulerサービス – Docker, Kubernetesに対応 – APIは新たに設計 • Bay – Work がscheduleされたNodeの集合。AWS ECSのclusterみたいなもの? – Bay model(テンプレートみたいなもの)を指定して Bay を生成する • Node – Workが実際に動作するHost(BareMetal or Virtual) • Pod – 同一Host上で動作するContainerの集合 • Service – Podsとアクセスpolicyが定義された抽象レイヤ • Replication Controller – 設定数のPodsが動作していることを保証するための、Podsグループの抽象レイヤ • Container – Docker container
- 30. Documents / Tools • https://github.com/iij/ocpj-poc-openstack – MAASを用いてOCPサーバをインストールする方 法 – nova-docker インストール方法 – Benchmark手順
Notes de l'éditeur
- Hybrid cloud を用いることで、例えば定常的なワークロードはプライベート側、ピークワークロードをパブリック側に寄せることでコストを最適化したり、既に持っているサーバを有効活用することが出来ます。 しかしながら、パブリッククラウドが持っているようなスケールメリットをプライベートクラウドで実現するためにはOCPサーバやOpenStackの導入など、いくつか従来のLegacy ITとは違ったアーキテクチャや考え方を導入する必要があります。 本発表では、主に性能とコストの観点でOCPサーバの利点を検証した結果について発表します。
- まず、想定するコンピューティング環境について説明します。 プライベートクラウド上で動かすのが良さそうなワークロードは定常的に計算やIOが発生するようなものが想定されます。何故かと言うと、突発的な負荷であればパブリッククラウド上に逃がしてもたいしてコストは掛からないと考えられます。 そのため、アプリの実行環境としてはBare Metal とコンテナ仮想化技術を組み合わせたようなものが最適ではないかと考えます。 今回のPoCでは、OCPサーバ上に構築した OpenStackとDockerの環境上でベンチマークを取得しました。ベンチマークに用いた構成は二種類あり、一つ目はDockerとHeatを組み合わせたものになります。Heatは、OpenStackで複数のインスタンスをテンプレートベースで一括deployするためのツールです。昨年5月にリリースされたIcehouseでHeatのDocker対応が入りました。二つ目は、OpenStack NovaのバックエンドをDockerにするドライバ nova-docker になります。
- 次に、検証内容の概要について説明します。 一つ目は、OCP環境を用いてBare Metal Deployment環境を構築しました。Bare Metal Deploymentを実現するためのツールとしてはMAASを用いました。MAASは、Ubuntuの開発元のCanonical社が開発しているMetal As A Serviceと呼ばれるソフトウェアで、Bare Metal Server上にOperating Systemの初期構築をするためのあらゆる仕組みが提供されます。通常、DesktopのOSであれば人間が手作業でインストールすることも多いですが、台数が多いクラウドのインフラなどでは手作業は現実的ではないため、このようなDeploy Toolを用いることで徹底的に自動化をするのが一般的です。
- 二つ目の検証内容としては、OpenStackのcompute環境をDockerにする場合の構築手順をまとめました。2015年1月現在は novaのdocker driverはOpenStackのupstreamに取り込まれておらず、OpenStackとしてはIncubationステージの状態です。そのため、構築手順や検証結果の情報はあまり世の中に存在していません。今回PoCで検証した内容はgithub上でも一般公開するので、沢山の人に情報を共有することができるようになります。
- 3つ目の検証内容としては、Dockerを使った場合のメリットを性能及び消費電力の観点で比較、検討を行ないました。 比較対象は2つあり、一つ目はOpenStackとKVMの組み合わせです。二つ目は、Bare Metal としてdeployしたサーバを使います。 測定方法としては、OCPサーバのIPMI/DCMIとして取得できる消費電力情報を定期的に計測しながらベンチマークソフトを走らせることで、負荷に対する消費電力の情報を取得します。
- ハードウェアの構成は、台湾のODMメーカ Wiwynn社のOCPサーバを用います。
- 次に、OpenStackとKVMの構成についてご説明します。こちらの図は、今回比較対象として用いる OpenStackとKVMを組み合わせた場合のハードウェア構成になります。 OpenStackのコントローラ部については図左のnova-controller側にインストールされています。Computeノードは図右側のnova-computeになります。仮想化技術にはKVMを使うため、KVMの上にOSが載り、さらにその上でアプリケーションソフトが動作するイメージになります。
- 次に、OpenStackとdockerの組み合わせについて解説します。 図の左側はOpenStack+KVMの構成と同じくOpenStackのコントローラが動いています。Computing nodeについては、Dockerを用いるためOSのエミュレーションが無く、Dockerの上でアプリケーションソフトが動いているイメージになります。アプリ自体はcompute nodeからは一プロセスとして見えます。
- 次に、比較のため環境として用意したBare Metal構成についてご説明します。 こちらの図は、MAASによりDeployされたUbuntuサーバの上で動作するアプリケーションプロセスを意味しています。とくに何の変哲もない、通常のサーバ上で動作する一アプリということになります。
- ソフトウェア構成について解説します。 サーバのdeploymentにはMAASサーバを用います。そのため、ベンチマークに用いるサーバとは別にManagement ServerとしてのMAASサーバが別途用意されています。 OSにはUbuntu14.04LTSを用いました。OpenStackのdeployについては、devstackを用いました。使用したOpenStackのバージョンとしては、2015年1月の最新版を用いています。 ネットワーク構成はnova-networkをflat dhcpモードで動かしました。最もシンプルなネットワーク構成なので、ベンチマークには最適です。
- 次に、ベンチマークの方法について説明します。 CPUのベンチマークにはsysbenchというフリーのツールを用いました。Sysbenchでは、素数を見つけるアルゴリズムを動かすことでCPUに負荷を掛けます。今回sysbenchに設定したパラメタは、cpu-max-primeが10万、スレッド数は1,2,4,8,…, 32と可変で値を変えていきます。
- Disk IOのベンチマークには、fioという名前のベンチマークソフトを用いました。 設定パラメタとしては、direct write及びdirect readについてそれぞれ測定し、block sizeは16kBに設定しました。並列度を意味する numjobsについては、1,2,4,8,16,32と可変に変えていき、sizeについても並列度に合わせて10GB, 5GBx2,,, のように合計で10GBになるように設定しています。 尚、nova-dockerはdevice mapperに対応していないため、benchmarkについてはbare metal server上での測定で代用しました。Dockerはdefault supportのブロックデバイスがAUFSなのですが、AUFSだとIO性能があまり高くないことと direct ioに対応していないため今回の測定から外しました。
- 次に、ネットワークの測定方法について説明します。 ネットワークのbenchmarkには iperfを用いました。設定パラメタとしては、length 128kB、並列度は 1,2,4,8,16,32と可変で測定し、測定時間は30秒に設定しました。
- CPUのベンチマーク結果についてご説明します。 グラフの横軸はスレッド数になります。1から始まり、2,4,8,16,32の順で測定しています。グラフの縦軸は実行時間を秒数でプロットしています。スレッド数が増えるに従い、計算時間が短くなっていきます。 赤のグラフがnova-dockerになり、bare-metalとほぼ同じ値になっています。Nova-kvmは緑色のグラフになります。
- こちらのグラフは、先ほどのbenchmarkの際の消費電力をプロットしたものになります。 消費電力自体は、bare-metal, nova-docker,nova-kvm共にあまり大きな差はありませんでした。
- こちらのグラフは、Disk IOのランダムライトに関するベンチマーク結果になります。 横軸はスレッド数、縦軸はスループットで単位はMB/sになります。 ベンチマーク結果としては、bare-metalとdockerの間にはあまり性能差は見られませんでした。Dockerとnova-kvmで比べると、kvmの方が大幅に性能が下がることが読み取れます。
- こちらのグラフは、DiskIOのランダムリードに関するベンチマーク結果になります。 ランダムリードに関しても、nova-kvmはdockerに比べて大きく性能が落ちることが読み取れます。但し、その差はランダムライトに比べると小さいです。
- こちらのグラフは、ネットワークのベンチマーク結果になります。 Dockerはベアメタルに比べるとスレッド数が少ない時のスループットが若干低めの模様ですが、スレッド数が大きくなるに従い10Gbpsの帯域を使い切れるところにまで到達しました。 Nova-kvmについては、一貫して9Gbpsあたりの帯域を超えることはありませんでした。いわゆる、10Gbpsワイヤーレートまで使い切るのは難しい模様です。
- 次に、ベンチマークの結果から読み取れたことをまとめます。 CPUに関しては、nova-dockerはスレッド数が1,2の際には性能が低いものの、スレッド数が増えるに従い性能低下はほとんど見られなくなりました。 消費電力に関しては、CPUの負荷に応じて大きく変わりました。
- Disk IOについては、今回はファイルシステムとしては device mapperを使いました。Device mapperであれば、IO性能は bare metalと比べて遜色ないくらいになります。 但し、dockerには他にも複数のストレージが選べるため、モノによってはあまり性能の出ないものがあるので要注意です。 Kvmのrandom write性能については、かなり低い値となりました。 但し、今回のベンチマークはローカルディスクについて行った結果なので、コンテナのインスタンスが永続データを扱う場合はリモートストレージやSQLのPaaS等、ネットワーク越しのI/Oになるので今回のベンチマーク結果とは違う特性になる可能性があります。
- ネットワークのベンチマークの結果としては、nova-dockerの場合、プロセス数が1,2,4の場合は性能の低下が見られました。 これは、CPUベンチマークでも同様の傾向があったので、network driver周りの問題というよりは、CPU周りの問題かもしれません。
- 全体のまとめとしましては、大きく分けて3つの結果を得ることができました。 一つ目は、CPU処理がメインの場合はKVM等の完全仮想化環境を用いてもオーバーヘッドはあまり大きくありませんでした。 二つ目は、Disk IO処理が大きい処理がメインの場合は、dockerを使うことで処理性能を大幅に引き上げる可能性がありそうでした。 三つ目は、ネットワークに関しては10Gbpsを目いっぱい回すようなアプリになる場合はdockerを使うことで性能向上が期待できそうでした。