Azureでの Linux リモート デスクトップと VDI のオプション

Azure上の Linux 仮想デスクトップ インフラストラクチャ (VDI) は、Azure仮想マシン (VM) からグラフィカル Linux デスクトップを配信するためのアーキテクチャのセットです。 アーキテクチャに応じて、ユーザーは特定の VM に接続したり、GPU アクセラレータアプリケーションを使用したり、共有環境からブローカー セッションを受信したりできます。

Azureでは、Linux セッション ホストを使用するファースト パーティのマネージド VDI サービスは提供されません。 Azure Virtual DesktopとWindows 365は、Windowsデスクトップとアプリケーションを提供します。 Linux デスクトップの場合は、Azure VM にリモート デスクトップ ソフトウェアをデプロイして管理するか、パートナー ソリューションを使用します。

この記事では、Azureの主な Linux リモート デスクトップと VDI のアプローチを比較します。 製品のインストールではなく、アーキテクチャと選択基準に重点を置いています。

Linux デスクトップ アプローチを選択する

次の表は、一般的なシナリオを適切な開始点にマップします。

シナリオ 開始方法 重要な考慮事項
グラフィカル ツールを使用した Linux VM の管理またはトラブルシューティング リモート デスクトップ サーバーを備えた Linux VM 各ユーザーは、特定の VM に接続します。
小規模な開発チームに永続的なデスクトップを提供する リモート デスクトップ ソフトウェアを使用する 1 つ以上の Linux VM VM の割り当て、可用性、スケーリングを管理します。
3D、コンピューター支援設計 (CAD)、または科学的視覚化アプリケーションを実行する グラフィックス対応 GPU VM と高速リモート表示プロトコル デスクトップ セッションでは、GPU 経由でレンダリングをルーティングする必要があります。
一元管理されたセッションを多数のユーザーに提供する パートナーの Linux VDI プラットフォーム ブローカー、負荷分散、ID、クライアントのサポートを評価します。
対話型 Linux デスクトップとスケジュールされた Slurm ジョブを組み合わせる Open OnDemand を使用した Slurm 用 CycleCloud ワークスペース ユーザーには、ワークスペースへのプライベート接続と、ワークロード データへの共有アクセスが必要です。
Windows アプリケーションまたはデスクトップを提供する Azure バーチャル デスクトップ セッション ホストAzure Virtual Desktop Linux ではなくWindows実行されます。

単一 VM のリモート デスクトップ

最も簡単なアーキテクチャは、デスクトップ環境とリモート デスクトップ サーバーを実行する Linux VM です。 ユーザーは、ソフトウェアに応じてネイティブ クライアントまたはブラウザーから接続します。 このアプローチは、グラフィカル管理、トラブルシューティング、概念実証環境、割り当てられた VM を使用できる小規模なチームに適しています。

単一 VM アプローチでは、接続ブローカー、自動ホスト割り当て、または負荷分散は提供されません。 セッションの永続化、デバイスのリダイレクト、ブラウザー アクセスも、リモート デスクトップ製品によって異なります。 ユーザーの数が増えるにつれて、各 VM を個別に管理することは運用上の負担になる可能性があります。

Ubuntu での基本的なリモート デスクトップ プロトコル (RDP) 構成については、「Linux で xrdp を使用する」を参照してください。 xrdp は、初期セットアップと迅速なトラブルシューティングに適した軽量の Ubuntu に重点を置いたオプションですが、完全なマルチユーザー VDI コントロール プレーンやハードウェアアクセラレータによる 3D レンダリングは単独では提供されません。

永続的な単一 VM デスクトップの場合、ThinLinc などのパートナー製品は、セッションの永続化とネイティブ クライアントまたはブラウザーアクセスを提供できます。 詳細については、この記事で後述する マルチユーザーおよびブローカー Linux VDI を参照してください。

GPU で高速化されたリモート視覚化

グラフィックスを集中的に使用するアプリケーションでは、レンダリング パスに GPU が必要です。 例としては、CAD、コンピューター支援エンジニアリング、分子視覚化、地震解釈、医療画像などがあります。 GPU アクセラレーションがないと、これらのアプリケーションは CPU を介してレンダリングされ、インタラクティブな作業には実用的ではないフレーム レートで正しいイメージを提供する可能性があります。

高速 Linux デスクトップには、次の 3 つの主な要件があります。

  • グラフィックス対応の GPU VM サイズ。 NV ファミリは、リモートの視覚化やその他のグラフィックス ワークロード用に設計されています。 コンピューティング指向の NC サイズと ND サイズは、さまざまなワークロード プロファイルを対象とするため、サイズを選択する前にアプリケーションとドライバーの要件を検証します。
  • サポートされているグラフィックス ドライバー。 NVIDIA ベースの NV サイズでは、グラフィックス ワークロードに NVIDIA GRID ドライバーが使用されます。 インストール オプションについては、「 Linux 用 NVIDIA GPU Driver Extension」および「Linuxを実行している N シリーズ VM に NVIDIA GPU ドライバーをインストールする」を参照してください。 AMD ベースのサイズの場合は、選択した VM サイズとオペレーティング システムでサポートされている AMD グラフィックス ドライバーを使用します。
  • GPU を使用するリモート表示パス。 作業用デスクトップ セッションでは、アプリケーションがハードウェア アクセラレーションを使用していることを証明するわけではありません。 リモート デスクトップ製品はグラフィックス スタックと統合する必要があります。または、アプリケーションは VirtualGL などのコンポーネントを使用してレンダリングを GPU にリダイレクトする必要があります。

Important

ユーザーが実行するアプリケーションで高速化を確認します。 OpenGL レンダラーが、 llvmpipeなどのソフトウェア ラスタライザーではなく、予想される GPU を報告することを確認します。

一部のAzure Marketplaceイメージは、高速視覚化のための事前構成済みパスを提供します。 たとえば、既定の ThinLinc Marketplace パスは NVIDIA GPU ワークロードに重点を置きます。 このイメージ フォーカスは、ThinLinc 自体に NVIDIA GPU が必要であることを意味するわけではありません。 ThinLinc では、製品を個別にインストールして構成するときに、CPU のみの Linux デスクトップやその他のデプロイ設計をサポートすることもできます。

スタンドアロンの NVIDIA GPU デプロイについては、「Azureに ThinLinc を使用して GPU アクセラレータを使用した Linux 仮想デスクトップをデプロイする」を参照してください。 高速レンダリング メカニズムの詳細については、Azureでの HPC ワークロードのリモート視覚化に関するページを参照してください。

マルチユーザーおよびブローカー経由の Linux VDI

仲介型 VDI アーキテクチャでは、ユーザー エントリ ポイントと特定の VM アドレスが分離されます。 接続ブローカーは、使用可能なホストにセッションを割り当てますが、管理コンポーネントはプール、負荷分散、セッション再接続、監視、ポリシー制御を提供できます。

パートナーの Linux VDI 製品は、Azure Marketplaceを通じて利用できます。 製品の機能は異なるため、次の要因を独自のアプリケーションやネットワーク条件と比較します。

  • ネイティブ クライアントとブラウザーのサポート。
  • 接続ブローカーとホスト プールの管理。
  • 切断またはネットワーク変更後のセッション永続化。
  • グラフィックス アクセラレーションとサポートされている GPU ベンダー。
  • ID 統合と多要素認証。
  • クリップボード、ローカル ドライブ、プリンター、およびその他のデバイス リダイレクト コントロール。
  • ライセンス、ベンダー サポート、運用所有権。
  • 予想される待機時間とパケット損失の範囲に対するプロトコル のパフォーマンス。

代表的なアプリケーション、データセット、表示解像度、ユーザーの場所を使用して、候補ソリューションをベンチマークします。 合成グラフィックス ベンチマークだけでは、対話型のユーザー エクスペリエンスは予測されません。

ThinLinc は、ネイティブ クライアントまたはブラウザーを介して永続的な Linux セッションを提供できる 1 つのパートナー リモート デスクトップ製品です。 NVIDIA ベースのデプロイに限定されるわけではありません。 ただし、コンパニオン Azureデプロイに関する記事では、スタンドアロンの NVIDIA GPU 設計に焦点を当てています。この構成では、高速視覚化のためのドキュメント化されたパスが提供されるためです。

Slurm ワークロードを使用する Linux デスクトップ

対話型の視覚化がハイ パフォーマンス コンピューティング (HPC) ワークフローの一部である場合、多くの場合、ユーザーはスケジュールされたジョブで使用されるのと同じストレージとネットワークに近いデスクトップが必要になります。 Slurm 用の Azure CycleCloud ワークスペースには、Slurm、自動スケール コンピューティング パーティション、共有ストレージ オプション、Open OnDemand が用意されています。

Open OnDemand は、対話型アプリケーションとジョブ送信用のブラウザー ベースのエントリ ポイントです。 Slurm リリース用の現在の CycleCloud ワークスペースには、グラフィカル デスクトップ セッション用の ThinLinc 統合が含まれています。 このパスは、スタンドアロンの ThinLinc VM とは異なります。Open OnDemand は認証されたユーザー エントリ ポイントを処理し、ワークスペースは対話型セッションをより広い Slurm 環境に接続します。

対話型セッションとコンピューティング ノードが同じホーム ディレクトリとワークロード データにアクセスできるように、共有ストレージを使用します。 OnDemand を開くには、ワークスペース仮想ネットワークへの直接プライベート接続も必要です。 サポートされている構成パスについては、「 CycleCloud で Open OnDemand を構成する」を参照してください。

アクセスとセキュリティに関する考慮事項

グラフィカル デスクトップは、VM とそのデータへの対話型のエントリ ポイントです。 次のコントロールを任意の Linux リモート デスクトップまたは VDI アーキテクチャに適用します。

  • ポイント対サイトまたはサイト間 VPN、または ExpressRoute を介してプライベート接続を使用します。 選択したクライアントとプロトコルがその接続モデルをサポートしている場合にのみ、Azure Bastionトンネリングを使用します。
  • 実稼働セッション ホストのパブリック IP アドレスは使用しないでください。 一時的なパブリック アクセスが必要な場合は、ネットワーク セキュリティ グループの規則を信頼できるソース範囲に制限し、評価後に規則を削除します。
  • 選択した製品に必要なポートのみを公開します。 管理インターフェイスをプライベートのままにします。
  • 自己署名 Web 証明書を、信頼できる証明機関によって発行された証明書に置き換えます。
  • 組織の ID コントロールと統合し、製品でサポートされている場合は多要素認証を必要とします。
  • データ処理の要件に従って、クリップボード、ファイル転送、ドライブ マッピング、印刷、その他のリダイレクト機能を制限します。
  • テスト済みのイメージ ライフサイクルを通じて、オペレーティング システム、デスクトップ ソフトウェア、リモート アクセス コンポーネント、グラフィックス ドライバーにパッチを適用します。

コストと運用上の考慮事項

Linux デスクトップ のコストは、VM の実行時間、各ホストを共有するユーザーの数、ワークロードに GPU が必要かどうかによって異なります。 次のコストと管理要因を考慮してください。

  • アイドル状態の VM の割り当てを解除して、コンピューティング料金の課金を停止します。 停止しているが割り当てられた VM では、引き続きコンピューティング料金が発生します。
  • 使用が予測可能な時間に従う場合は、スケジュールまたは自動スケールを使用します。
  • 使用可能な最大サイズを選択するのではなく、グラフィックス メモリとアプリケーションの要件に従って GPU VM のサイズを変更します。
  • 永続的なユーザーごとの VM と共有ホストを比較します。 共有ホストは使用率を向上させることができますが、仲介、容量計画、ワークロードの分離が必要です。
  • 合計コストには、ソフトウェア ライセンス、サポート、イメージ メンテナンス、監視、ストレージ、ネットワーク エグレスが含まれます。

次のステップ

  • Last updated on