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

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のほうが賢いためにパフォーマンスが優位とのことです。