Movatterモバイル変換

G P U O N O P E N S TA C K -G P U インターナルクラウドのベストプラクティスP R E S E N T E D B Y M A S A F U M I O H TA @ m a s a f u m i o h t a

A ‘ S TA C K E R ’ L O O K I N GI N T O G P G P U U S E .V O L U N T E E R F O R T H ER A S P B E R RY P IF O U N D AT I O N : )M A S A F U M I O H TA

T H I S P R E S E N TAT I O N I SR E N E W E D F O RO P E N S TA C K D AY S T O K Y O2 0 1 7 .I T I S I N C L U D E D S O M EF E E D B A C K S F R O M T H ES E S S I O N AT # L C 3 C H I N AI N B E I J I N G , 2 0 1 7P R E S E N TAT I O N R E N E W E D

O R G I Z N E D B Y V T J A N DG AT H E RM E , N V I D I A ( A S K ) , D E L L E M C ,N E S I C A N D S O M EC O M PA N I E S W H OI N T E R E S T E D G P U U S E O NO P E N S TA C K E N V I R O N M E N TF O R O U R C U S T O M E R ST H I S P R O J E C T I S …

T E S L A M 6 0 + D E L L E M C P O W E R E D G EC 4 1 3 0 + O P E N S TA C KT O E VA L U AT E G P U O NO P E N S TA C K E N V I R O N M E N TT H A N K S T W O H E L P I N GO U T A N D P R O V I D I N GT H O S E S E R V E R S + C A R D SN O W E VA L U AT I N G . .

なぜ G P U O N O P E N S TA C K なのか ?はじめに

O P E N S TA C K特殊利用の需要OpenStackの特殊な利用の需要が増えてきているHadoop(Sahara),HPC,などなどほとんどのものはまとめたのがなく、ググって調べるしかない…曰く「ドキュメントロスト状態」これらのものはOpenStackのDocsにまとめられるべき

どうやって G P U は O P E N S TA C K 環境で動作するのか？‘GPU ON OPENSTACK’とは何か?

‘ G P U ’ トレンドのおさらい• 多くのGPUコアを利用する• 一部の計算は単一MPUユニットが小さくスピードが遅かろうとも多くのMPUコアを使うことはいくつかの計算処理には有効である• サーバ各々は高パフォーマンスでコンパクトにできる• 低消費電力化はHPCエンドユーザにとって大事なこと• 多くの省電力・ハイパフォーマンスサーバを所有しやすくなる

どうやって G P Uは動くのか？• 現在のところPCIパススルーあるいはNVIDIA(GPU) dockerでの利用となる• ‘PCIパススルー’ は土台となるベアメタル仮想環境に依存する• VSphereとXenは各々VMにGPUコアを任意の単位で分割して割り当てすることが可能• OpenStackの標準的なベアメタル仮想環境として使われるKVMではコア分割ができず、GPUユニットごとをVMに割り当てることとなる• 昨今使われるコンテナ仮想環境でのデプロイとなるNVIDIA(GPU) DockerはDockerコンテナ同士で一つのGPUユニットを共有しているが、明示的な分割はしない• ウインドウズは’docker vm'としては動作しない

G P UO P E N S TA C K とは• インスタントなHPC利用• いくつかの計算をしおえたらVMそのものを壊す。• ちょっとしたお試しでいくつかのVMを使ってHPCグリッド試してみる。終わったらすぐ壊す。• GPUインターナルクラウドとしてのGPU利用• 主に製造業において、いくつかのシステムは情報管理上、パブリッククラウドに外だしができない。

どんな G P U のメカニズムが O P E N S TA C K 環境でうごいているのか？S E T U P : G P U O N O P E N S TA C K

O p e n S t a c k で G P U を動かす方法（現在 )• PCIパススルー• PCIデバイスをダイレクトに接続する• ComputeNodeのハイパーバイザー依存、OpenStack依存ではない• Xen利用でのGPUコア分割、KVMはNVIDIA/AMDともコア分割不可• Intel GVT-g(Xen)/GVT-d(KVM)によるIntel GPUのコア分割• コンテナ• NVIDIA Dockerの利用• 複数のコンテナによってGPUを利用できるが、明示的なGPUコア分割はできない タスク次第でのGPU利用• Kubernetes/Mesos/Docker Swarmなどとの組み合わせ管理

P C I パススルーは V M 上でどう動作するのか？• PCIデバイスをダイレクトにLinuxホストを通じて接続する• 物理ホストよりデバイスを切り離す必要あり• (NVIDIA) Dockerと違いホスト切り離しとなるため、監視管理等は各VMに必要• OpenStack依存のことではなく、Linuxのベアメタル環境に依存• KVM上では一つのGPUデバイスにひとつのVM• Docker/Xen/VSphereと違いGPUは分割もできなければ共有もできない• これはKVMの制限であってOpenStackによるものではない

P C I P a s s t h ro u g h o n O p e n S t a c k• Redhatは公式サポート• ただ、あまり推しでない気が..• Ubuntuはドキュメントすらまともにない…• ググって探すしかない（さすがUbuntu..orz )• 目下小職/NVIDIA JAPAN/DELLEMC/VTJで再度細く検証とOpenStackコミュニティのためにドキュメントをまとめ上げる予定（趣旨に同意いただき参画いただける企業様歓迎いたします)

Linux OS for KVM hypervisorGPU DriverAppVMVMM/KVMIOMMU/Vt-dPCI Express x16Linux/Win OSComputeNodeGPU CardNova ComputeNova SchedulerNova APILinux OSControllerNode図1:OpenStackどうやってGPUパススルーを実現しているのか？(KVMの場合)Nova Conductorpci-stub/vﬁo-pciGPU Driver

S t e p 1 : ホストの G P U の状態をまずは調べる• lspci -nn | grep -i nvidia でGPUの状態をまずはチェックlspci -nn | grep -i nvidia88:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:11b4] (rev a1)88:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio Controller [10de:0e0a] (rev a1)• 全てのGPUユニットがパススルーされている必要がある• GPUだけでなく、ユニットとして認識されるGPUデバイス自体もパススルーする必要あり• でないとVMは動いてくれない..（完全にパススルーにならない)

G P U ポートがパススルーされているかチェック• QuadroなどHDMIはビデオポートだけでなくオーディオポートももっているため注意• lspciでチェックされたものについては全てパススルーさせる必要がある。

S T E P 2 : I O M M U セットアップ• IOMMU(Input/Output Memory Management Unit) は物理デバイスを仮想化システムで使う上で必要なもの• もちろんvt-dはオンにする必要あり (EFI/BIOSののデフォルトはON)• intel_iommuとvfio_iommu_type1.allow_unsafe_interruptsの設定を/etc/default/grubに行う必要ありGRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=onvfio_iommu_type1.allow_unsafe_interrupts=1”

S T E P 3 : p c i - s t u b と V F I O• pci-stubは物理デバイスをLinuxホスト側が利用できないようにする• VFIO(Virtual Function IO) は pci-stubと同様の働きをする。kernel 4.1以降のサポート• 未使用時はデバイスをD3ステート(低消費電力モード)に変更する• It is not used by default デフォルトでは使われないため /etc/module を編集して、これらと関連するコンポーネンツを追記する (kvm,kvm_intel)pci_stubvfiovfio_iommu_type1vfio_pcikvmkvm_intel

S T E P 4 - 1 : ブラックリスト ( 1 )• ramfsでGPUデバイスを認識できないようにする• /etc/initramfs-tools/modules to initramfs (ubuntuの場合)echo ‘pci_stub ids=10de:11b4,10de:0e0a’ >> /etc/initramfs-tools/modulessudo update-initramfs -u && sudo reboot

S T E P 4 - 2 : B l a c k l i s t ( 2 )• ブート時にGPUデバイスを認識できないようにする。• /etc/modprobe.d/blacklist.conf に次を追加:blacklist nvidiablacklist nvidia-uvm• ドライバについてもブラックリストに入れる必要ありblacklist nouveau

S T E P 5 : 物理からのアンバインド• 『物理ホストから切り離しVMへのバインドするため』にpci-stubをチェックする1. pci-stub/new_idにパススルーするドライバのPCI IDをエントリする。2. 関連するPCI識別子を物理ホストから切り離す3. pci-stubにこのPCI識別子をバインドする。echo 11de 11b4 > /sys/bus/pci/drivers/pci-stub/new_idecho 11de 0e0a > /sys/bus/pci/drivers/pci-stub/new_idecho 0000:88:00.0 > /sys/bus/pci/devices/0000:88:00.0/driver/unbindecho 0000:88:00.1 > /sys/bus/pci/devices/0000:88:00.1/driver/unbindecho 0000:88:00.0 > /sys/bus/pci/drivers/pci-stub/bindecho 0000:88:00.1 > /sys/bus/pci/drivers/pci-stub/bind• 物理ホストのdmesgに以下の’claimed’がブートプロセスにあるかどうか確認する。pci-stub 0000:88:00.1: claimed by stub

物理デバイスpci-stub(仮想で使う)GPUユニット(全てのデバイス)‘GPUを物理デバイスよりアンバインドして仮想デバイスにバインドする’echo 11de 11b4 > /sys/bus/pci/drivers/pci-stub/new_idecho 11de 0e0a > /sys/bus/pci/drivers/pci-stub/new_idecho 0000:88:00.0 > /sys/bus/pci/drivers/pci-stub/bindecho 0000:88:00.1 > /sys/bus/pci/drivers/pci-stub/bindecho 0000:88:00.0 > /sys/bus/pci/devices/0000:88:00.0/driver/unbindecho 0000:88:00.1 > /sys/bus/pci/devices/0000:88:00.1/driver/unbind図2:物理にあるGPUを切り離し仮想につなぐ

modprobe/etc/modprobe.d/blacklist.confpci-stub/sys/bus/pci/drivers/pci-stub//sys/bus/pci/devices/$(Identiﬁer)/driver/unbindramfs/etc/initramfs-tools/modulesGRUB/etc/default/grubmodules/etc/modulesUEFI/BIOSVt-d図3:ブート時のGPUブラックリストのプロセス(Ubuntuの場合)IOMMUIOMMUBLACKLISTBLACKLISTIOMMUBLACKLISTBLACKLIST

G P U を追加する ( 1 )• lspci の結果を確認- 2つの関連するPCI識別子が確認できるはず(識別子番号は使用するシステムに依存)lspci -nn | grep -i nvidia88:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:11b4] (rev a1)88:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio Controller [10de:0e0a] (rev a1)84:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:11b4] (rev a1)84:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio Controller [10de:0e0a] (rev a1)• pci-stubにさらにパススルーするGPUの追記をする。echo 0000:84:00.0 > /sys/bus/pci/devices/0000:84:00.0/driver/unbindecho 0000:84:00.1 > /sys/bus/pci/devices/0000:84:00.1/driver/unbindecho 0000:84:00.0 > /sys/bus/pci/drivers/pci-stub/bindecho 0000:84:00.1 > /sys/bus/pci/drivers/pci-stub/bind

G P U を追加する ( 2 )• 追加のGPUがうまく動いたかVMで確認ubuntu@guestos$ lspci -nn | grep -i nvidia00:07.0 VGA compatible controller [0300]: NVIDIA Corporation GK104GL [Quadro K4200] [10de:11b4](rev a1)00:08.0 VGA compatible controller [0300]: NVIDIA Corporation GK104GL [Quadro K4200] [10de:11b4](rev a1)• アプリによっては両方同時に利用する際など、同一のGPUである必要がある可能性がある。/nbody -benchmark -numdevices=2 -num bodies=65536

O p e n s t a c k : n o v a - a p i の設定• ControllerNodeの/etc/nova/nova.confを編集しnova-apiを再起動する• pci_aliasにPCIデバイスの情報、エイリアス名を記述pci_alias={“name”:”K4200”,"vendor_id":"10de","product_id":"11b4"}

O p e n S t a c k : n o v a - c o m p u t e の設定• ComputeNodeにある/etc/nova/nova.confを編集し、nova-computeを再起動する。• pci_passthrough_whitelistにPCIデバイスの情報、エイリアス名を記述pci_passthrough_whitelist={“name”:”K4200","vendor_id":"10de","product_id":"11b4"}*このケースの場合、ベンダーIDとプロダクトIDが適合したデバイスは全てVMにパススルーする。• pci_aliasににPCIデバイスの情報、エイリアス名を同様に追記*Neuton以降pci_alias={“name”:”K4200”,"vendor_id":"10de","product_id":"11b4"}

O p e n S t a c k : n o v a - s c h e d u l e r の設定• ControllerNodeの/etc/nova/nova.confを設定しnova-schedulerを再起動する。• PciPassthroughFilterを利用できるようにするためにPciPassthroughFilterをscheduler_default_filtersに追記する• 同様にPciPassthroughFilterをscheduler_available_filtersに記述するscheduler_available_filters=nova.scheduler.filters.all_filtersscheduler_available_filters=nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilterscheduler_default_filters=DifferentHostFilter,RetryFilter,AvailabilityZoneFilter,RamFilter,CoreFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,AggregateInstanceExtraSpecsFilter,PciPassthroughFilter

Linux OS for KVM hypervisorGPU DAppVMVMM/KVMLinux/WComputeNodeNova ComputeNova SchedulerNova APILinux OSControllerNodeNova Conductorpci_aliaspci_passthrough_whitelistpci_aliasscheduler_default_ﬁltersscheduler_available_ﬁlters図4:NovaがGPU(PCI)パススルーされているComputeNodeで動作するプロセスP C I デバイスを利用可にして P C I 利用のリクエストを送れるようにするp c i p a s s t h ro u g h f i l t e r を利用して G P U パススルーされた C o m p u t e N o d e を選ぶG P U パススルーしたインスタンスを p c i _ a l i a s とp c i _ p a s s t h ro u g h _ w h i t e l i s t によって発生させる

O p e n S t a c k : f l a v o r- k e y の設定• flavor-keyを設定しGPUインスタンスで利用できるようにPCIパススルーの設定をflavorに追記する• pci_passthrough:alias=$(pci_alias_name):$(the number ofGPUs we would like to use)nova flavor-key $flavor_name set “pci_passthrough:alias”=“K4200:$(the number_of_gpus)”

G P U O N O P E N S TA C K を使うにあたって注意すべき問題点既知の問題

C l o u d イメージの問題• CloudイメージはGPUを使う上ではとても小さくqemu-imgでリサイズする必要がある• CUDAドライバはperl-packages(dev packages)がインストール時に必要• それが.debあるいは.rpmパッケージであろうとインストールが必要になる。なぜならCUDAパッケージ自体がバイナリパッケージでなく、ソースコードよりバイナリをビルドしていて、makeをパッケージインストールの際に実行している• NVIDIA曰くCUDAドライバの次期リリースでFIX予定とのこと• CUDA 7.6以降でfixの予定だったのに..まだfixされてない..orz

V D I としての W i n d o w s 利用• CUDA on Windows は思ったより早いけどカクカクしてしまう• 多分DISKのスピード、ネットワークなどなどいろいろなものが予想される。多分エフェメラルモードやその他爆速系のSSD/NVMeの利用やら10g以上のネットワーク環境が必要となるだろう• まだ改善対応をやってみたことはないが、なぜ発生するのかを調べるべく近々検証予定。• VMは基本メモリ/NW転送などコンテキストスイッチでの動作をするため、CUDAの重いワークロードはカクカクする可能性があるかもしれない。• 詳しくはデモビデオにて…• GPU on OpenStack上でのWindowsの動作はもっと調査が必要..時間がほしい…

V D I としての W i n d o w s 利用 ( f e e d b a c k )• Thanks giving some feedbacks to my session at LC3 China!• Should checked and investigate the Windows-related issues below, willupdate later.• Windows 10 on KVM issue• http://bart.vanhauwaert.org/hints/installing-win10-on-KVM.html• Windows 10 deployment is succeeded from my KVM but I still have failed the samedeployment from my OpenStack.I should investigate more what happened in detail.• Nvidia Driver issue (version 337.88 or later)• https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#.22Error_43:_Driver_failed_to_load.22_on_Nvidia_GPUs_passed_to_Windows_VMs• ‘Nvidia drivers on Windows check if an hypervisor is running and fail if it detects one, whichresults in an Error 43 in the Windows device manager. ‘ I haven’t found this issue on myWindows 7 VMs so I should check more in detail• Related links libvirt for adding the driver, should be checked.• https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L2025-L2036• https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4262-L4264

ライブマイグレーションの問題• PCIパススルーを使ったVMはライブマイグレーションができない。マイグレーション前のホストのPCIコネクションが切れないままになってしまう。• ワークアラウンド:古いコネクションを下記にあるようなmysql DBのnova.pci_devicesから削除し古いホストを再起動する。• 再起動は他のホストに影響するため、ありえない。他にmysql DBなど関連プロセスの再起動で乗り切る形もあるが、これも他のホストに影響するためありえないことになる。| 2016-08-11 00:54:45 | 2016-08-19 04:58:01 | NULL | 0 | 45 | 21 | 0000:84:00.0 | 11b4 | 10de | type-PCI | pci_0000_84_00_0 |label_10de_11b4 | available | {} | NULL | NULL | 1 | <<-- old-host| 2016-08-11 00:54:45 | 2016-08-19 04:58:01 | NULL | 0 | 48 | 21 | 0000:88:00.0 | 11b4 | 10de | type-PCI | pci_0000_88_00_0 |label_10de_11b4 | available | {} | NULL | NULL | 1 | <<-- old-host

G P U が O P E N S TA C K 環境でどう動くか  チェック！デモ ( ビデオ )

インスタンスを立ち上げ G P U の動作を確認• RHEL OpenStackを利用• パススルーしてあるインスタンスを立ち上げる• Ubuntuインスタンスを立ち上げlspciとdevicequeryを実行、GPUの動作を確認• Windows上でのGPUの動きをGraphicsベンチで確認、RDSでのリモートサイトにあるものの接続のため、カクカクしてしまうがベンチの結果だけ？良いことを確認する。• デモビデオではSlashtopを利用

関連リンク• Attaching physical PCI devices to guests:https://docs.openstack.org/admin-guide/compute-pci-passthrough.html• Container as a Service on GPU Cloud- Our DecisionAmong K8s, Mesos, Docker Swarm, and OpenStackZun:https://www.slideshare.net/secret/AiUdO4dLxNTkfI• OVMF_による_PCI_パススルー https://goo.gl/icq9mV

S p e c i a l T h a n k s t o :• GPU on OpenStack project membersVirtualTech JapanNVIDIADellEMCNEC Networks & System Integration• @zgock999 at Tokaido-LUG, Nagoya, JapanTeach me some hints how to use GPGPU on VM!• Matthew Treinish of IBM attended my session at LC3 china andfigure out and feedback some point!• Our customers! give the chance to evaluate!

P R E S E N T B Y M A S A F U M I O H TAT W E E T @ m a s a f u m i o h t a m a i l t o : m a s a f u m i @ p i d 0 . o rgT H A N K S V E RY M U C H F O R C O M I N G M Y S E S S I O N !

Movatterモバイル変換

Change Language

GPU on OpenStack - GPUインターナルクラウドのベストプラクティス - OpenStack最新情報セミナー 2017年7月

Embed presentation

Recommended

More Related Content

What's hot

Similar to GPU on OpenStack - GPUインターナルクラウドのベストプラクティス - OpenStack最新情報セミナー 2017年7月

More from VirtualTech Japan Inc.

GPU on OpenStack - GPUインターナルクラウドのベストプラクティス - OpenStack最新情報セミナー 2017年7月