リモートビジュアライゼーションは、永続的なスタンドアロン仮想マシン(VM)を使用することも、HPCクラスターとの対話セッションの統合も、よりシンプルなアクセスパターンに置き換えることも可能です。 ユーザーの作業方法、データの所在、セッションにスケジューラ管理の計算リソースが必要かどうかに基づいてモデルを選択します。
各モデルに共通するコンポーネントや設計原則については、「Azure上の高性能コンピューティングのためのリモートビジュアライゼーション」を参照してください。
展開モデルの比較
| 要件 | スタンドアロンの可視化 | スケジュールされたクラスタ可視化 | 代替アクセスパターン |
|---|---|---|---|
| 一般的なワークフロー | 永続的ワークステーションまたはアプリケーションセッション | スケジュールされたHPCジョブに関連するインタラクティブ作業 | ノートブック、ウェブアプリケーション、ローカル可視化、または非インタラクティブレンダリング |
| コンピュート割り当て | セッション ホスト VM に固定されています | HPCスケジューラから要求された | アプリケーションやバッチワークフローによります |
| スケールパターン | ホストのサイズ変更や独立管理ホストの追加 | クラスタスケーリングによるインタラクティブリソースの追加または削除 | ウェブサービス、ノートブックプラットフォーム、バッチジョブのスケールを広げる |
| ユーザー エントリ ポイント | ネイティブのリモートディスプレイクライアントまたはウェブアクセス | クラスターと統合されたHPCポータルまたはリモートディスプレイエントリーポイント | ブラウザ、コマンドライン、またはローカルアプリケーション |
| データアクセス | マネージド ディスクまたはマウントされた共有ストレージ | クラスターホームディレクトリと共有プロジェクトストレージ | アプリケーション固有のストレージアクセス |
| コストパターン | セッションホストは実行中に計算負荷を蓄積します | インタラクティブノードは割り当てられている間に計算料金を発生させます。共有クラスタサービスやストレージはそのまま残ることができます | 選択されたサービスやワークフローによります |
| Operations | VMイメージ、セッション、容量、ライセンス | ポータル、スケジューラ統合、クラスタイメージ、セッション、ライセンス | アプリケーションまたはサービス操作 |
| 最適 | 個人、小規模チーム、そして持続的な環境 | 共有HPC環境とインタラクティブジョブ | フルリモートLinuxデスクトップを必要としないワークロード |
スタンドアロンのビジュアライゼーションを選択してください
以下の場合にスタンドアロンのビジュアライゼーションを活用してください:
- ユーザーはスケジューラに縛られない永続的なLinuxワークステーションを必要としています。
- アプリケーションは1台のVM上で完全に動作します。
- 少数のユーザーは予測可能な専用容量を必要とします。
- 管理者は各ホストまたはホストプールごとにVMイメージ、ユーザーアクセス、ストレージマウント、ソフトウェアライセンスを管理できます。
スタンドアロン設計は、1つのセッションホストから始まり、複数のホストに拡張することができます。 各ユーザーが専用のVMを受け取るか、同時ユーザーがより大きなVMを共有するかを決定してください。 CPU、メモリ、グラフィックメモリ、ストレージの要件はアプリケーションごとに大きく異なるため、実際のワークロードとセッション密度を検証してください。
スタンドアロンの可視化は、HPCクラスターとは運用的に分離されています。 ユーザーは共有プロジェクトストレージにアクセスしたり、ジョブをクラスタに提出したりできますが、管理者はそれらの接続を設計・維持しなければなりません。
スタンドアロンのLinux VDI実装については、Azure上でThinLincでGPU加速されたLinux仮想デスクトップをデプロイする方法をご覧ください。
単独の計画の考慮事項
- ユーザーと並行性: 単一のVMはパイロット用または数名の専用ユーザーに適しています。 大規模な展開では、ホスト割り当て、セッションブローカリング、またはホストプール設計が必要です。 製品のライセンスや測定されたアプリケーション需要によって、一般的なユーザー数の範囲ではなく、サポートされるセッション数が決定されます。
- 可用性: 単一のVMは、別のホストを追加し、ユーザーを再接続または再割り当てする方法を除き、単一の障害点となります。
- コスト:ゲストOS内でVMを停止しても、そのAzureのコンピュート割り当ては解放されません。 セッションやアプリケーションのライフサイクルが許すなら、ホストが不要な場合はデロロケーションしましょう。 ディスクやその他の保持されたリソースは引き続き料金が発生しています。
- データ場所: ワークステーションがクラスタデータを使用する必要がある場合、共有プロジェクトストレージをマウントします。 アイデンティティマッピング、権限、ファイルシステムのパフォーマンスを確認しましょう。
- スキル: 運用チームはLinux VM、イメージ、GPUドライバー、ネットワーク、ストレージ、リモートディスプレイ、アプリケーションライセンスの専門知識を必要とします。
スケジュールされたクラスタ可視化を選択します
スケジュールされたクラスタ可視化は以下の時に使用します:
- インタラクティブな作業は、より大きな予定されたHPCワークフローの一部です。
- セッションはバッチジョブと同じアイデンティティ、ホームディレクトリ、プロジェクトストレージを必要とします。
- ユーザーは各セッションごとに異なるコンピュートリソースやGPUリソースを要求する必要があります。
- 管理者は、インタラクティブな容量とリソース使用を制御するためのスケジューラポリシーを求めています。
このモデルでは、アクセスポータルやサービスがスケジューラにインタラクティブジョブを要求します。 スケジューラはセッションを適切なコンピュートリソースに配置し、ユーザーは設定済みのリモートディスプレイパスを通じて接続します。 設計はセッション開始時間、アイドルセッションポリシー、ジョブ制限、リソースクリーンアップ、再接続動作を考慮しなければなりません。
Azure CycleCloud Workspace for Slurmには、Web エントリーポイントとしてOpen OnDemandが含まれています。 ThinLincは、Slurmを通じてスケジュールされたLinux VDIセッションのアプリケーションオプションの一つです。 Microsoftはパッケージ統合に対して限定的なサポートを提供していますが、CendioはThinLinc製品とそのライセンスをサポートしています。 展開および検証手順については、 CycleCloud Workspace for Slurmの「Open OnDemandでThinLincの設定」をご覧ください。
スケジュールされたクラスターの計画に関する考慮事項
- ユーザーと並行性: スケジューラポリシー、利用可能な容量、アプリケーションプロファイル、ポータルの制限が並行性を決定します。 このモデルは共有ユーザーコミュニティにサービスを提供しますが、すべてのクラスタに固定されたユーザー数が適用されるわけではありません。
- 起動時間: セッションは既存のノードを待つか、新しいノードのプロビジョニングを待つことができます。 キュー時間とプロビジョニング時間の目安を設定します。
- コスト: 動的にプロビジョニングされたインタラクティブノードはジョブ完了後にデロケーションでき、アイドル計算負荷を削減します。 アクセスノード、スケジューラーノード、ストレージ、ネットワーク、その他の保持リソースは引き続き料金が発生する可能性があります。 スケジュールされた設計がすべての怠け時間を自由にするわけではありません。
- データロケーション: セッションは通常、クラスタのアイデンティティおよび共有ファイルシステムを使用し、重複データパスを減らします。 すべてのインタラクティブパーティションから権限とパフォーマンスを検証します。
- スキル: オペレーションチームはまた、Slurm、オートスケーリング、Open OnDemandまたは選択したポータル、クラスタイメージ、インタラクティブアプリ統合の専門知識も必要です。
データの位置を決定要因として使うこと
権威あるデータへの最も単純なサポート済み経路を提供するモデルを選択してください:
- クラスタコンテキストを必要とせずに管理ディスクやサポートされた共有マウントを使用できる場合は、スタンドアロンの可視化を選択してください。
- セッションがバッチジョブと同じアイデンティティ、ホームディレクトリ、ソフトウェア環境、プロジェクトストレージを使用する必要がある場合は、スケジュールクラスタ可視化を選択してください。
- アプリケーションがブラウザを通じて結果を縮小表示できる場合や、ローカル利用のために管理された小規模なデータセットを転送できる場合は、代替パターンを選択してください。
クラスタ間と別々の可視化ホスト間で完全なデータセットをコピーするのを日常的なワークフローとして避けてください。 繰り返しコピーを行うことで、ストレージ、転送、同期、データガバナンスの作業が増加します。
代替アクセスパターンを選択してください
フルリモートデスクトップはソフトウェア、セキュリティ、容量、ライセンスの責任を増やします。 運用の複雑さが少なく、ユーザーのニーズに合った別のパターンを選ぶ。
考えてみてください。
- ブラウザ上で既に動作するワークフローのためのアプリケーション固有のウェブインターフェースです。
- JupyterHubや他のノートブック環境で、インタラクティブな分析と可視化が可能です。
- 画像、アニメーション、またはデータセットを共有ストレージに変換する非インタラクティブレンダリングジョブ。
- データサイズやガバナンス要件が転送可能な場合に減少した結果のローカル可視化。
- ユーザーがグラフィカルな操作を必要としないときに使うSSHやコマンドラインツール。
決断を下してください
これらの質問は順番に使います。
- 作業量はインタラクティブなグラフィカルセッションを必要としますか? もしそうでなければ、コマンドライン、ウェブネイティブ、ノートブック、またはバッチレンダリングのパターンを使いましょう。
- セッションはスケジューラ割り当てされたクラスタリソースが必要ですか? もしそうなら、スケジュールされたクラスターの可視化を評価する。
- ユーザーは固定容量の永続的な環境を必要としているのでしょうか? もしそうなら、単独のビジュアライゼーションを評価してください。
- 選択した製品は必要なオペレーティングシステム、GPU、アプリケーション、アイデンティティ設定に対応していますか? もしそうでなければ、別の製品や展開モデルを選択してください。
- ネットワークは各ユーザー拠点から適切なやり取りを提供できるのでしょうか? もしなければ、リージョン、アクセスパス、表示設定、ワークフローを変更してください。
- チームは予想される並行処理で設計を安全に運用できるのでしょうか? 決定には画像の保守、監視、復旧、ライセンス、ユーザーサポートを含めてください。
まずはパイロットから始め、成長計画を立てましょう
パイロットを使ってアプリケーションの互換性、セッションリソースの使用、ユーザー体験を確立し、その後に本格的なスケールモデルを選択してください。
典型的な成長経路は以下の通りです:
- 1つの代表的なアプリケーションとデータセットを1台のVMでテストします。
- CPU、システムメモリ、GPUメモリ、ストレージ、ネットワークレイテンシ、再接続の動作を測定します。
- 代表的な同時利用者を追加し、最初に限界に達するリソースを特定しましょう。
- ユーザーが永続的な専用環境を必要とする場合は、スタンドアロンのイメージおよびホスト割り当てプロセスを標準化してください。
- ユーザーが共有スケジューラリソースを必要とする場合は、ポータルとインタラクティブパーティションを通じてワークフローを再現してください。
- 画像の更新、監視、サポート所有権、容量制限、復旧を本番展開前に定義してください。
成功したスタンドアロンのパイロットを、スケジュールされたノードにもそのまま適用できると思い込まないでください。 スケジューラ統合はセッションの開始、クリーンアップ、識別、ストレージ、再接続の動作を変えます。
本番環境に導入する前に検証する
選ばれたモデルに対して限定的な概念実証を構築します。 代表的なアプリケーションや予想されるユーザー位置からのデータをテストします。 VMのサイズ、ドライバー、オペレーティングシステム、リモートディスプレイソフトウェアのバージョン、ネットワークレイテンシ、セッション同時実行、テスト結果を記録し、本番設定を再現できるようにします。
ベンダー固有の展開手順を公開または標準化するのは、完全なパスを再現し、そのサポート所有者を特定するまでは避けてください。