Bitfusionの話しは聞かなくなってきたけど、自宅で使うにはBitfusionってすごい便利なんで私はまだまだBitfusion使っています。
今回はWindow11のDocker Desktopでコンテナ動かして、Bitfusionを使ってみました。
vCenterで管理されているホストではないのでvCenterでTokenを作る必要がありますが、動かすことができました。
とりあえず認識だけですが、bitfusion smiも、Bitfusion list_gpusも問題なく動いています。 しかも自宅のWifi環境経由で。
Bitfusion4.5.2のRelease Noteに記載されていたこちらの文言。
vSphere Bitfusion クライアントは、vSphere Bitfusion コマンドライン インターフェイスで現在の GPU の割り当てと使用率を表示できます。
じゃぁ、どんなコマンドなんだ！ってことで調べて試してみたところ、bitfusion usageというコマンドが追加されていました。
自宅のBitfusion環境でgpu_burnでGPUに負荷をかけつつコマンド実行してみました。
負荷をかけた状態でvCenterで確認すると、Allocation-1、Core Utilization-1、MemoryUtilization -0.85でしっかりGPUに負荷がかかっていることがわかります。
負荷をかけた状態でnvidia usageコマンドを実行してみました。
どのBitfusion Serverを利用して、どの程度のメモリが割り当てられているか確認することができます。
4.5.1のバージョンまではvCenterでしか利用状況がわからなかったので、CLIで確認できるのでGPUが利用中でジョブがキューにはいったのか、トラブルなのかの切り分けにも使えそうです。
VMware Exploreもおわり、vSphere8やvSAN8の発表がありました。
個人的に期待していたAI / ML系のアップデートは仮想マシンへのGPU割当数が拡張されたというくらいで、Project Radium関連の発表はありませんでした。
Bitfusionは特にないだろうし、セッションもないだろうなぁ。。。と思っていましたが、思ったとおりやはりありませんでした。
ですが、YoutubeにProject Radiumのデモ動画がアップされました！
NVIDIAとAMDのGPUでTensorflow動かしていますね。リリースされるのが楽しみです！
自宅Bitfusionを利用して色々と試し中。
公式ドキュメントでは、Yolov3での利用サンプルが記載されています。
このYolov3でも全く問題なく動作したのですが、Yoloxでも動作を試してみました。
特に変わった設定もせずに実行することができました。
ただ、vCenterのBitfusionタブを見ていて気づいたのが、GPUがOverCommit(でいいのかな?)できてる！
最近若干アップデートの間隔が長くなってきた気がしますが、着実に進化していますね。
Project Radiumのリリースも楽しみです。
run または request コマンドを実行するときにラベルを付けることができます。これにより、vSphere Bitfusion ユーザー インターフェイスでクライアントを効率的に識別できます。
今回はvsphere with tanzuのworkerノードへのディスク追加方法についてご紹介します。
コンテナは軽量という印象をお持ちの人も多いと思いますが、コンテナイメージによっては数GBのサイズがあったりで意外とサイズの大きいものもあります。
私はAI系のコンテナイメージを利用することが多いのですが、これがイメージサイズが大きくてpull imageで時間がかることがあります。時間がかかるだけであればいいのですが、ディスクサイズに収まらないということも発生します。
通常のKubernetesやDockerであればホストOSのディスクサイズは仮想マシンでも数十GBから数百GB程度取ることがあるのであまり問題はないのですが、TanzuでTKCを作成してWoker Nodeを展開すると私の環境の場合はディスクサイズが16GBで、Workerノードのディスク容量が足りずにコンテナイメージを展開できないことがありました。
状況としてはkubetctl get pod でStatusがEvictedになります。
kubectl describe podで詳細を確認すると、The node was low on resource: ephemeral-storage.のメッセージが、、、
色々ためしたのですがWorkerノードのディスクを拡張するしかなく、tkcを作成するyamlファイルに以下を追加することで回避できました。
volumes:
- name: containerd
mountPath: /var/lib/containerd
capacity:
storage: 64GiB
ネット探してもこのあたりに困っている人は少なそうだったんですが、Workerノードのディスクサイズに困っている人は少ないのか、周知の事実なのか、、、
とりあえず、やっとコンテナ使えるようになりました。