vSphere with GPU

先日、vSphere7がリリースされブログなどでもTKGなど新機能の情報が多くなってきました。DockerやKubernetesはこれまでのインフラSEにはちょっと難しいですが、これからのSEには必要な知識だと思います。

さて、本題のvSphereでのGPU利用に次いてです。

最近はAIやDeep Learningということで毎日のように実証実験や導入事例のニュースが発表されています。コロナ関連でもAIを活用といったニュースがありますが、AI / Deep Learningで欠かせないのがGPUです。　

今現在、vSphereでGPUを利用するとなると２つの構成をとることができます。

 １． GPU パススルー

 ２． NVIDIA GRID

1のGPUパススルーはvSpherにGPUを搭載し、仮想サーバへGPUを占有で割り当てて利用する方法です。このメリットは仮想サーバでGPUを占有できることです。その一方でデメリットはvMotionができないことです。vMotionやDRSが利用できないことでメンテナンスタイムやノード障害で仮想サーバが長時間停止する可能性があります。　Deep Learningで学習処理を行っているときにあと数十分で終わるところで障害でも発生したら目も当てられないですね。。。

2つ目のNVIDIA GRIDは、ｖMotionができますが、追加のライセンスが必要なことや、仮想サーバに割り当てられるGPUが4枚まで。また、構成が複雑になるなどのデメリットがあります。

そして私がかなり期待しているのが今後リリースされてくる予定のBitfusionです。

GPU Poolからネットワーク経由で仮想サーバにGPUを提供するのでネットワークがかなり重要になってくると想像できますが、仮想サーバへのGPU割り当て数は特に制限ないし、vMotionも可能と、上記2つのデメリットを補うことができると想像します。

GPUも複数割り当てや、メモリ分割しての割り当てなどかなり柔軟に対応できるようなのと、Dockerなどのコンテナ環境でも利用できそうです。

今後のAIインフラも変わってくるのではないかと思います。

NSX-T 3.0 GA

NSX-Tの3.0がリリースされました。先日リリースされたvSphere7に続いての楽しみな製品のリリースです。

NSX-T 3.0 Release Note

リリースノートには新機能として次のような記載があります。

• Cloud-scale Networking: NSX Federation
• Intrinsic Security: Distributed IDS, Micro-Segmentation for Windows Physical Servers, Time-based Firewall Rules, and a feature preview of URL Analysis
• Modern Apps Networking: NSX-T for vSphere with Kubernetes, container networking and security enhancements
• Next-Gen Telco Cloud: L3 EVPN for VM mobility, accelerated data plane performance, NAT64, IPv6 support for containers, E-W service chaining for NFV

フェデレーション、セキュリティ、コンテナ、Telcoとキーワードだけでもホットなエリアの機能追加に注力されているのがわかります。

Modern Apps NetworkingではvSphere7で提供されたKubernetesと連携するコンテナネットワークを提供できるようになり、IDSでアプリケーションのセキュリティ対策も強化とアプリケーションのためのネットワーク機能強化がされています。

Release NoteのL2ネットワーキング項目でちょっと気になるのはこの部分です。

The N-VDS NSX-T host switch will be deprecated in a future release. 

N-VDSとNSX-Tホストスイッチは将来のリリースで廃止されるようなので、vDSベースでの導入が推奨されるようです。これまでNSX-Tで導入されている環境は将来のアップデートで注意が必要かもしれないです。

まだまだコロナの影響で外出自粛が続きそうなので、これからNSX-T導入して試していきたいと思います。

Kubeflow on Tanzu

vSphere７がリリースされました。注目はなんといってもvSphereでのKubernetesです。

Tanzu PortfolioとしてPKSやPAS(pivotal app service)などなど、昨年のVMworldでTanzuが発表された内容よりもコンポーネントが追加されています。

そんななか色々とTanzu関連の情報を調べていたら、KBにTanzuのロードマップが記載されていて、その中に　Kubeflow　の文字が！

　Tanzu Kubernetes Grid Plus Support Matrix (78173)


Kubeflowは簡単にいうとkubenetes上にMachine Learning環境が簡単にできるようになります。
Kubeflowの詳細は　こちら　です。


ロードマップなので延期も、場合によってはリリースされない可能性もありますが、楽しみです。

vCAP-NV Design

VMware社の試験の体系だったり種類だったりは他の人のブログや、VMware社のサイトで詳しく紹介されているのでここではご紹介しませんが、昨年vCAP-NV Designの試験がリリースされたので、年末にvCAP-NV Designの試験を受けてみました。

私はvCAP5-DCDを持っているので、以前の試験システムからHOLベースに変わったとはいえ、vCAP5時代のイメージで勉強していったところ玉砕しました。。。

vCAP5-DCDでは、画面上にアイコン置いたり、線引いたりと本当にデザイン関連の問題も多々出題されていたのですが、今は全然違うんですね。。。

年末年始はさんでモチベーション下がってたのですが、日本初のVCDX合格者も出たことでまたやる気も出てきました！

ぼちぼち勉強始めます！

Project PacificのPerformance

2019年のVMworldで発表となったProject Pacificには個人的にはとても期待していて、早く製品化されるのを楽しみにしています。

情報も色々と出始めていて、ｖForum東京でも多くのセッションが持たれていました。
USのPerformance TeamもProject Pacificのパフォーマンス検証結果をブログにあげているようです。

How Does Project Pacific Deliver 8% Better Performance Than Bare Metal?

この内容はvForumのセッションでも説明されていましたが、Bare MetalのKubernetsよりもProject Pacificのほうが8%パフォーマンスが良いです。

仮想化よりもBareMetalのほうがパフォーマンスがいいのが通常なので、vForumでこの説明を聞いたときにはちょっとした驚きでした。

Project Pacificのほうがいいのはブログには以下のように記載しています。

＊＊＊＊＊

To get deeper insights, we configure a set of pods to run the same workload at a constant throughput and collect hardware performance counter data for both testbeds to see the proportion of the last level cache (L3) misses that hit in the local DRAM vs remote DRAM. The local DRAM accesses incur much lower memory access latencies in comparison to remote DRAM accesses.

As shown in Figure 4, only half of the L3 cache misses hit in local DRAM, and the rest are served by remote memory in the case of bare-metal Enterprise Linux. In the case of the vSphere Supervisor Cluster, however, 99.2% of the L3 misses hit in local DRAM for an identical pod and workload configuration due to superior CPU scheduling in ESXi. The lower memory access latencies from avoiding remote memory accesses contributes to improved performance on the vSphere Supervisor Cluster.

＊＊＊＊＊

引用( https://blogs.vmware.com/performance/2019/10/how-does-project-pacific-deliver-8-better-performance-than-bare-metal.html )

詳細は上のブログを確認してもらえればと思いますが、簡単に言うとメモリの使い方がvSphereのほうが賢いためにパフォーマンスが優位とのことです。

VMの強制停止(vim-cmd)

久しぶりに検証環境のloginsightをみたら、ディスクがいっぱいのアラートが発生してるじゃん！

ディスクを拡張しろよっ！ってメッセージが出ているのでVM停止しようにも、vsphere clientからもcliからも、シャットダウンも電源offも受け付けない状態に、、、

まぁ、検証環境で気を抜くとよくやってしまうんですよね。

ということで、esxiにログインしてvim-cliで強制停止します。

まずは、loginsightのvmidの確認。

[root@esx06:~] vim-cmd vmsvc/getallvms

Vmid        Name                                         File                                          Guest OS         Version                                                                                                          Annotation                                                                                                       

9      loginsight8      [vsanDatastore] c90ec45d-e494-fac1-cd8b-e4434b765fd4/loginsight8.vmx      other3xLinux64Guest   vmx-11    VMware vRealize Log Insight                                                                                                                                                                                             

該当のvmidは9なのを確認します。

ダメ元で通常のpower offをしてみるも、やっぱりダメでした。

まぁ、vsphere clientでダメでしたしね。

[root@esx06:~] vim-cmd vmsvc/power.off 9

Powering off VM:

Power off failed

[root@esx06:~] vim-cmd vmsvc/power.getstate 9

Retrieved runtime info

Powered on

もういいやってことと、おそらくできないだろうってことでdestroyもしてみましたが、

まぁだめですね。✳︎本番環境ではやらないでください。

[root@esx06:~] vim-cmd vmsvc/destroy 9

Destroy failed

ということで、esxiで該当プロセスを停止します。

まずは、該当プロセスの確認。

[root@esx06:~] esxcli vm prodccess list

loginsight8

   World ID: 2217787

   Process ID: 0

   VMX Cartel ID: 2217786

   UUID: 42 0f 3e 71 4c db c0 a8-f1 51 b2 87 e4 2d 49 86

   Display Name: loginsight8

   Config File: /vmfs/volumes/vsan:523fb3acb1d66ae8-2e6d54369e0422c5/c90ec45d-e494-fac1-cd8b-e4434b765fd4/loginsight8.vmx

World IDを確認して、killコマンドでプロセスをていしします。

[root@esx06:~] esxcli vm process kill --type=soft --world-id=2217787

プロセスが停止したのが確認できました。

[root@esx06:~] esxcli vm process list

仮想マシンも電源OFFになりました。

[root@esx06:~] vim-cmd vmsvc/power.getstate 9

Retrieved runtime info

Powered off

こんかいはkillコマンドのtypeがsoftで停止できましたが、softで停止で着ない場合は、hardやfoceのtypeを指定することもできます。

強さでいうと　soft >hard>forceになるので、順番に試してみてください。

PhotonOS Disk expansion

PhotonOSでいくつかAI系のコンテナを試しているのですが、PhotonOSのディスクはデフォルトで15GBしかないので、必要なパッケージをダウンロードしているとすぐにディスクがいっぱいになってしまいます。。。

なので、PhotonOSのディスク拡張を行いました。


まずは、vSphere ClientでPhotonOSのディスクサイズを大きくします。
PhotonOSに設定されているディスクを15GBから必要なサイズに拡張します。
私の環境ではとりあえず40GBに変更しました。


変更後はPhotonOSにSSHして次の流れで操作します。

1.　再起動なしでDisk変更を認識できるように設定変更
2.　partedコマンドのインストール
3.　partedでディスク拡張
4.　ファイルシステム拡張



まずは、1の再起動無しでディスクの境界(この場合は元々のSectorと拡張したSectorの境界)を認識できるようにします。

＃ echo 1 > /sys/class/block/sda/device/rescan



次に、PhotonOSにはデフォルトではディスク操作のコマンドがインストールされていないので、partedコマンドをインストールします。

# tdnf install parted

Installing:
parted                   x86_64       3.2-7.ph3        photon         1.11M 1159755

Total installed size:   1.11M 1159755
Is this ok [y/N]:y

Downloading:
Testing transaction
Running transaction
Installing/Updating: parted-3.2-7.ph3.x86_64

Complete!


partedのインストールが完了したらディスクの拡張です。

# parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.

(parted) print　　※拡張対象のパーティション番号を確認
print
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  9437kB  8389kB                     bios_grub
 2      9437kB  17.2GB  17.2GB  ext4　　※データ領域の2を拡張します。

(parted) resizepart 2 100%　※パーティション２を100%使う


(parted)print ※拡張されたことを確認
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  9437kB  8389kB                     bios_grub

 2      9437kB  42.9GB  42.9GB  ext4


(parted) quit　※partedを終了



partedでディスク拡張後に、ファイルシステムを拡張します。


# resize2fs /dev/sda2　※ファイルシステムを拡張
resize2fs 1.44.3 (10-July-2018)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 3
The filesystem on /dev/sda2 is now 10483451 (4k) blocks long.


# df -h　　※ファイルシステムが拡張されたことを確認
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        40G  438M   38G   2% /
devtmpfs        998M     0  998M   0% /dev
tmpfs          1000M     0 1000M   0% /dev/shm
tmpfs          1000M  524K  999M   1% /run
tmpfs          1000M     0 1000M   0% /sys/fs/cgroup
tmpfs          1000M     0 1000M   0% /tmp
tmpfs           200M     0  200M   0% /run/user/0



詳細はPhotonOSのマニュアルに記載があるのでそちらを参照してください。