TKG Demo Appliance試してみる：Part1 OVA入手

インストールして触りだけ試したりしていたけど、そろそろがっつりやってみないととずっと思いつつ、生粋のインフラエンジニアにはなんとなくハードルが高くて手がつかなかったKubernetes。

自宅で試すにはリソース足りないからなぁ。。。自分に言い訳しつつ後回しにしてたけど、試してみたいソフトがTKGで動くらしい。しかもTKGもDemoアプリ(仮想アプライアンス)が提供されているので、在宅勤務で自宅環境も触りやすいので試してみようと思います。

VMware Flings

FlingsにはESXi Arm EditionやHCI Benchなど無料で使える便利ツールが多数公開(2021年1月時点で157種類）されています。位置づけとしては製品への機能組み込み前のテストのようなのものなんでしょうかね。

このFlingsでTKGのデモ環境を構築できるDemo Appliance for Tanzu Kubernetes Gridが公開されています。Workshopガイドも併せて公開されているので導入＆基本操作までであれば簡単に試すことができます。

ということで、自宅のPCに導入してみたいと思います。

OVAのダウンロード

では、さっそくTKG Demo Applianceをデプロイしていきます。

サポートする環境としてはVMC on AWS、VMC on DellEMC、オンプレのvSphereの3種類なのですが、今回は自宅のNUCにインストールしてみます。

Demo ApplianceとPhotonOSのダウンロードを行います。

URLから直接ダウンロードしてもいいのですが、コンテンツライブライを利用してダウロードします。

vCenterのメニューからコンテンツライブラリを選択します。

新規作成を選択します。

名称を入力します。

サブスクライブ済みコンテンツライブラリを選択し、URLを入力します。

URLはマニュアルに記載があるこちら( https://download3.vmware.com/software/vmw-tools/tkg-demo-appliance/cl4/lib.json )こちらを入力します。

コンテンツライブラリで利用するデータストアを選択します。

設定が完了すると自動でOVAテンプレートがダウンロードされます。

2021年1月26日時点ではこちらのバージョンがダウンロードされました。

今回はここまでで次回はDeployに入りたいとおもいます。

Bitfusion2.5 Release!

 11月5日にBitfusion2.5がリリースされました！

Bitfusion2.5.0 Release Note

2.5での新機能は次の8項目です。

vSphere Bitfusion 2.5.0 の新機能

• ベアメタル クライアントのサポート
• 健全性チェックの拡張と操作性の向上
• バージョン 2.0.0 以降の vSphere Bitfusion クライアントのサポート
• NVIDIA ドライバ 450
• NVIDIA CUDA 11
• TensorFlow 2.3 のサポート
• PyTorch 1.5 のサポート
• TensorRT 7.1.3 のサポート

この中で注目はベアメタルクライアントのサポートです！

これまでのBitfusionクライアントはvSphere上の仮想マシンだけでしたが、ベアメタルのサーバもサポートされるようになりました。これは、データセンター内の物理LinuxマシンからもGPUをネットワーク経由で利用できるということなので、もっとGPUが活用される環境が整ってきました。

その他にもCUDAの11やTensorflowの2.3もサポートなど、開発側でも動作確認を進めているんでしょうね。　今後のアップデートが楽しみです！

Bitfusion Update

 7月にリリースされたBitfusionですが、毎月のようにUpdateがリリースされています。

vSphere Bitfusion 2.0.2　Updated on: 08 SEP 2020

• Support for applications that register segmentation fault (SIGSEGV) handlers. This fixes an issue observed when using Caffee, a framework for deep learning.
   
• Fixes health check issues when using Paravirtual RDMA (PVRDMA).
   
• Fixes a potential freeze, or hang, when using the vSphere Bitfusion client.
   
• Fixes a race condition that can occur when updating vSphere Bitfusion cluster statistics.

vSphere Bitfusion 2.0.1　Updated on: 04 AUG 2020

• Fix for detecting license correctly for vSphere >= 7.0b


• Updated NVIDIA driver to version 440.95.01


• Support for multiple datacenters within a vCenter Server instance. (This does not mean that a Bitfusion Server can be supported by multiple vCenter Server instances.)

vSphere Bitfusion 2.0.0　Updated on: 09 JUL 2020

• Dynamic, remote sharing. AI/ML applications do not need to be modified or recompiled. They run on client machines as-is, but their API calls to access GPUs are intercepted and sent for execution on Bitfusion server machines that house the physical GPUs. GPUs are allocated as needed and returned to the pool when a session or application completes.
   
• Partial sharing. GPU memory can be partitioned into slices of arbitrary, different sizes, then allocated to different clients for concurrent use.
   
• vCenter Server now hosts the vSphere Bitfusion management and analytic capabilities.

まだ、新しい製品なのでFixesがほとんどで新機能追加というわけではありませんが、

安定して動くようになるのはありがたいですね。

ドキュメントもわかりやすいですが、まだまだ情報量が少ない印象なので、そのあたりも追加されることを期待しています。

Bitfusion Server Resource & Client Resource

Bitfusionの導入について投稿しようかと思っていたのですが、こんなもんかと言うくらい簡単なのと、公式のインストールマニュアルが分かりやすいので、今回はBitfusion ServerとClientのリソースについて書いていきます。

<Bitfusion Server>

Bitfusion ServerはOVAファイルで提供されているため、展開はウィザードにしたがうだけなのですが、メモリサイズやvCPUのサイズは環境に合わせる必要があります。

ここでいう環境とは具体的にはGPUの種類と枚数になります。

公式のドキュメントには次のような記載があります。

1. The minimum size is the aggregate total of GPU memory on all GPU cards passed through, multiplied by a factor of 1.5.
2. Server compute – minimum cores is the number of GPU cards multiplied by 4

まず、1つ目のメモリサイズについて、Bitfusionサーバのメモリサイズは、搭載しているGPUメモリの1.5倍を割り当てる必要があります。

RecommendのGPUはNVIDIAの V100かT4と記載があるので、それらのGPUを搭載した場合のBitfusion サーバのメモリは次のようになります。

V100

GPUメモリは16 or 32GBなのですが、Bitfusionサーバで32GBメモリ版のV100＊2枚を利用する場合は次の計算になります。

 

32GB*2枚*1.5=96GB

T4

T4はメモリサイズが16GBなので、同様に1台のBitfusionサーバで2枚のT4を利用する場合はこちらの計算式です。

16GB*2枚*1.5=48GB

 

2.のvCPUについてはBitfusionサーバに割り当てるGPU数＊4を割り当てればOKです。

Bitfusion Clientに割り当てるメモリサイズはアプリケーションに依存してくるので個々の環境に合われる必要がありますが、アプリケーションが一度に利用するGPUメモリサイズの1.5倍ほどが目安となります。

Bitfusion requirements

前回はBitfusionのコンポーネントや基本構成について調べた内容を紹介いたしました。
今回は導入手順のまえに、Requirementを見ていきます。

<vSphere>
まずベースとなるvSphereですが、Bitfusionサーバが稼働するESXi(GPUプール)はvSphere7が必要になります。　噂ではU1からという噂もありましたが、Install GuideにはU1の文字はないので後日確認してみたいと思います。

GPUリソースを利用するBitfusionクライアントはvSphere6.7か7であればいいようなので、既存のvSphere環境が6.7であってもESXiのアップデートを行わずにBitfusionが利用できるようです。


<Client OS>
Bitfusionクライアントをインストールする仮想OSは、現時点ではUbuntuとCentOS、Redhatの3種類になります。　※ベアメタルは現時点では未サポートです。
　Ubuntu16.04, 18.04
　CentOS７
　RHEL7.4以降
HorizonとかのWindowsでも利用できればCAD VDI環境などにも利用することができるのですが、BitfusionはAIやMLでの利用を想定しているので、このあたりはしょうがないですね。。。
あとはDockerコンテナにもインストールが可能です。



<GPU>
GPUはTeslaのV100かT4がサポートされるようです。ここもやはりAI/MLを想定しているからこのGPUなんだと思います。


<Network>
前回の記事にも書きましたが、Bitfusionはネットワーク経由でGPUリソースを利用するので最低でも10Gbpsで、できればそれ以上のネットワークが必要になります。
　・10G Ethernet
　・RoCE

Bitfusionを試した感じだと1msecだとかなり影響がでるなぁ。。。と思っていましたが、
予想以上に低遅延なネットワークが必要で、ノード間で50マイクロ秒もしくはそれ以下だそうです。

クライアントからBitfusionサーバに対して次の通信ポートを開ける必要があります。
通信ポート：56001, 55001-55100, 45201-46225



要件をまとめてみると一番のポイントは高速なネットワークですね。

Bitfusion リリース！

Bitfusionがリリースされました！！　

AIやディープラーニングが引き続き盛り上がっているので、Bitfusionに興味がある人も多いのでないでしょうか。　私もリリースされるのをずっと待ってました！


リリースされたばかりでまだまだ情報も少ないですが、Bitfusionの調べた内容を紹介していきたいと思います。


＜特徴＞
なんといってもBitfusionの1番の特徴は、ネットワーク経由でGPUリソースを柔軟に割り当てられることです。これまでGPUの仮想化といえば、GPUを搭載したESXiホスト上の仮想マシンにたいして、パススルーやNVIDIAのvGPUなど同一ホスト内のGPU仮想化に限られていたので、ネットワーク経由で自由に割り当てられるのはとても大きなメリットだと思います。
　✳︎VMwareに買収される前のFlexdirectの時はFPGAなどのアクセラレータも利用できたっぽい(ロードマップ？)のですが、現時点ではGPUのみサポートされています。


<システム構成>
GPUプールのESXi上にBitfusionサーバ(アプライアンス)を展開し、ネットワーク経由でBitfusion ClientにGPUリソースを提供します。

Bitfusion Server
左側のESXiがGPUプールで、Virtual ApplianceがBitfusionサーバです。BitfusionサーバはVMwareから提供される仮想アプライアンスで、vSphere7 U1以上にデプロイします。
デプロイしたBitfusionサーバにはGPUをパススルーで設定します。

Bitfusion Client
右側のESXi上のVMはBitfusionを介してGPUリソースを利用する仮想マシンで、CentOSとUbuntuがサポートされています。このLinux仮想マシンにBitfusion Clientをインストールして、ネットワーク経由でGPUリソースを利用します。サポートされるLinuxの詳細のバージョンはドキュメントを確認してください。

Network
ネットワークは Ethernet(10Gbps)、RDMA、Infinibandをサポートしています。
GPUリソースをネットワーク経由で利用するので、広帯域、低遅延のネットワークが必要です。

Bitfusionライセンス
当初BitfusionはvSphere Enterprise Plusに内包される予定でしたが、vSphereのAdd-on として提供されることになったようです。ちょっと残念ですがBitfusionの利用状況を確認するのが目的のようなのでしょうがないですね。


今回はBitfusionの基本構成とコンポーネントを紹介しました。
次回以降は、利用方法だったり、導入手順などを投稿していきたいと思います。

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インフラも変わってくるのではないかと思います。