Alibaba Cloud Linux:コンテナーの起動後にAlibaba Cloud Linux 3にデプロイされたGPU高速化コンテナーでGPUを使用できない場合はどうすればよいですか。

問題の内容

コンテナーは、systemdバージョンがsystemd-239-68.0.2.al8.1より前のAlibaba Cloud Linux 3オペレーティングシステムにデプロイされます。 systemctl daemon-reloadコマンドを実行すると、コンテナーはGPUへのアクセスに失敗します。

• コンテナでnvidia-smiコマンドを実行すると、コマンド出力にGPU情報は含まれません。

• devices.listファイルの内容を照会すると、ファイルの内容が変更されます。 たとえば、GPU 0の権限は195:* mに変更されます。

次の図では、左側はコンテナーがGPUにアクセスできることを示し、右側はコンテナーがGPUにアクセスできないことを示します。

原因

/dev/char/ ディレクトリ内のデバイスノードをNVIDA GPUデバイスノードにリンクするシンボリックリンクは存在しません。 /dev/char /ディレクトリ内のデバイスノードの名前は、/dev/char/<major number:minor number> の形式です。 この例では、/dev/char /ディレクトリ内の /dev/char/195:255という名前のデバイスノードと、/dev/nvidiactlという名前のNVIDIA GPUデバイスノードが使用されます。 runcは、/dev/char /ディレクトリ内のデバイスノードをNVIDIA GPUデバイスノードに自動的に関連付けます。 コンテナが起動すると、runcは関連付けに基づいてコンテナとGPUのデバイス制御グループ (cgroup) を設定します。 次に、runcはsystemdのcgroup設定を提供します。 ただし、cgroup構成は存在しません。

systemctl daemon-reloadコマンドを実行してsystemd構成をリロードした後、systemdはsystemdによって管理されるすべてのサービス状態をシリアル化し、ディスク上の構成ファイルを読み取り、新しい状態をサービスに再適用します。 上記のプロセス中に、systemdは記録された状態に基づいてすべてのcgroup設定を再適用します。 ただし、シンボリックリンクが存在しないため、systemdは /dev/char/ ディレクトリで /dev/char/195:255という名前のデバイスノードを見つけたり設定したりできません。 その結果、systemdは /dev/char/195:255デバイスノードのデバイスcgroupを設定できず、コンテナーがGPUにアクセスできなくなります。

解決策

Alibaba Cloudは、systemd-239-78.0.4でFullDelegationDeviceCCroupオプションを提供しています。 FullDelegationDeviceCCroupオプションは自動的に有効になります。これにより、サービスに対してDelegateがyesに設定されている場合でも、systemdはデバイスcgroup設定を再適用できなくなります。 GPUアクセス障害の問題を解決するには、systemdを最新バージョンにアップグレードします。 以下の手順を実行します。

1. Elastic Compute Service (ECS) インスタンスのsystemdを最新バージョンにアップグレードします。

   sudo yum upgrade systemd

   yを入力してアップグレードを確認します。

2. 設定を有効にするには、ECSインスタンスを再起動します。

   警告

   再起動操作により、インスタンスが短時間停止し、インスタンスで実行されているサービスが中断される可能性があります。 これにより、データが失われる可能性があります。 インスタンスを再起動する前に、重要なインスタンスデータをバックアップすることを推奨します。 また、オフピーク時にインスタンスを再起動することを推奨します。

   sudo reboot

3. systemdのバージョンがsystemd-239-78.0.4以降であるかどうかを確認します。

   rpm -qa systemd

4. コンテナーでnvidia-smiコマンドを実行し、GPU情報を表示します。

   nvidia-smi

   次の図に示すコマンド出力は、GPUに期待どおりにアクセスできることを示しています。