Compute Engine で密結合な HPC アプリケーションを実行するためのベスト プラクティス

このドキュメントでは Message Passing Interface(MPI)から最適なパフォーマンスを引き出すよう Google Cloud リソースを調整する際のベスト プラクティスについて説明します。密結合なハイ パフォーマンス コンピューティング(HPC)ワークロードでは、プロセスとインスタンス間の通信に MPI がよく使用されます。最適な MPI パフォーマンスを実現するには、基盤となるシステムとネットワーク インフラストラクチャの適切な調整が重要です。Google Cloud で MPI ベースのコードを実行する場合は、これらの方法を使用して最適なパフォーマンスを実現させます。

前提条件と要件

通常、インスタンスの管理には SlurmHTCondor などのワークロード スケジューラが使用されます。このドキュメントの推奨事項とベスト プラクティスは、すべてのスケジューラとワークフロー マネージャーに適用されます。

さまざまなスケジューラやワークフロー ツールを使用した、これらのベスト プラクティスの実装は、このドキュメントでは取り上げません。その他のドキュメントやチュートリアルでは、実装のためのツールと、それらのツールのガイドラインについて説明しています。

このドキュメントのガイドラインは一般的なもので、すべてのアプリケーションに役立つとは限りません。最も効率的または、費用対効果の高い構成を見つけるには、アプリケーションのベンチマークを行うことをおすすめします。

Compute Engine の構成

このセクションでは、アプリケーションの最適なコンピューティング パフォーマンスを実現するためのベストプラクティスについて説明します。システム内で適切なマシンタイプと設定を使用すると、MPI のパフォーマンスに大きな影響を与える可能性があります。

コンパクト プレースメント ポリシーを使用する

プレースメント ポリシーでは、データセンターでの仮想マシン(VM)の配置を制御できます。コンパクト プレースメント ポリシーでは、単一のアベイラビリティ ゾーンに VM を配置するために、低レイテンシのトポロジが用意されています。最新の API を使用すると、物理的に近接する最大 22 個のコンピューティング最適化(C2)VM を作成できます。22 個を超える C2 インスタンス(物理コアが 660 個を超える)が必要な場合は、インスタンスを複数のプレースメント ポリシーに分割します。ワークロードに対応する最小数のプレースメント ポリシーの使用をおすすめします。

プレースメント ポリシーを使用するには、まず、特定のリージョンに必要な数の VM を持つコロケーション プレースメント ポリシーを作成します。

gcloud compute resource-policies create group-placement \
    PLACEMENT_POLICY_NAME --collocation=collocated \
    --vm-count=NUMBER_OF_VMS

次に、必要なゾーンでポリシーを使用してインスタンスを作成します。

gcloud compute instances create instance-1 \
    instance-2...instance-n --zone=us-central1-a \
    --resource-policies=PLACEMENT_POLICY_NAME \
    --maintenance-policy=TERMINATE ...

場合によっては、VM の作成方法を直接制御できない場合があります。たとえば、統合されていないサードパーティ製ツールを使用して VM が作成される場合があります。プレースメント ポリシーを既存の VM に適用するには、VM を停止してから次のコマンドを実行します。

gcloud compute instances add-resource-policies \
    instance-1 instance-2...instance-n --zone=us-central1-a \
    --resource-policies=PLACEMENT_POLICY_NAME

コンピューティング最適化インスタンスを使用する

C2 インスタンスを使用した HPC アプリケーションの実行をおすすめします。これらのインスタンスには、仮想コアから物理コアへの固定されたマッピングがあり、NUMA セル アーキテクチャをゲスト OS に公開します。これらはいずれも密結合な HPC アプリケーションのパフォーマンスにとって重要です。

C2 インスタンスには、最大 60 個の vCPU(30 個の物理コア)と 240 GB の RAM があります。また、最大 3 TB のローカル SSD ストレージを備え、最大 32 Gbps のネットワーク スループットをサポートできます。また C2 インスタンスは、第 2 世代の Intel Xeon Scalable プロセッサ(Cascade Lake)を活用します。これにより、他のインスタンス タイプと比較して、より広いメモリ帯域幅と高いクロック速度(最大 3.8 GHz)が提供されます。C2 インスタンスでは、通常、N1 インスタンス タイプと比較して、パフォーマンスにおいて最大 40% の改善がなされます。

マシン間の通信オーバーヘッドを削減するには、多数の小規模な C2 VM を起動するのではなく、ワークロードを少数の c2-standard-60 VM(同じ合計コア数を持つ)に統合することを推奨します。

ハイパー スレッディングを無効にする

一部の MPI アプリケーションは、ゲスト OS でハイパー スレッディングを無効にすることでパフォーマンスが向上します。ハイパー スレッディングは、ノード上の物理コアごとに 2 つの仮想コア(vCPU)を割り当てます。多くの一般的なコンピューティング タスクや、大量の I/O を必要とするタスクの場合、ハイパー スレッディングによってアプリケーションのスループットを大幅に向上させることができます。両方の仮想コアが計算依存型である、計算依存型ジョブの場合、ハイパー スレッディングはアプリケーションの全体的なパフォーマンスを妨げ、非決定的なバリアンスをジョブに追加する場合があります。ハイパー スレッディングを無効にすると、予測可能性に優れたパフォーマンスが可能になり、ジョブの時間を短縮できます。

オンラインまたは再起動により、C2、N1-Ultramem、N2 インスタンスでハイパー スレッディングを無効にできます。

オンラインでハイパー スレッディングを無効にするには、Manage_Hyperthreading.sh などのスクリプトを使用して、アクティブな CPU をオフラインに設定します。

再起動してハイパー スレッディングを無効にするには、/etc/default/grubGRUB_CMDLINE_LINUX 文字列に次のコマンドを追加します。ここで、NUM_CPU は、インスタンスの vCPU 数を 2 で割った値です。たとえば、c2-standard-60 インスタンスの場合、NUM_CPU は 30 になります。

noht nosmt nr_cpus=NUM_CPU

grub ファイルを変更した後、次のコマンドを実行して GRUB システム構成ファイルを更新してから、システムを再起動します。

sudo grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

システムに従来の BIOS 起動モードがある場合は、代わりに次のコマンドを実行します。

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

再起動後にシステムで SMP(ハイパー スレッディング)が無効になっていることを確認するには、次のコマンドを使用します。

lscpu | grep -e Socket -e Core -e Thread

出力は次のようになります。Thread(s) per core はハイパー スレッディングが無効になっている場合は 1 に、ハイパー スレッディングが有効になっている場合は 2 になります。

Thread(s) per core:    1
Core(s) per socket:    15
Socket(s):             2

ユーザー制限を調整する

Unix システムでは、オープン ファイルや、すべてのユーザーが使用できるプロセスの数などのシステム リソースにデフォルトで制限があります。これらの制限により、1 人のユーザーがシステム リソースを独占して他のユーザーの作業に影響を与えることを防止します。ただし、HPC のコンテキストでは、クラスタ内のコンピューティング ノードはユーザー間で直接共有されないため、通常これらの制限は不要です。

/etc/security/limits.conf ファイルを編集してノードに再度ログインすることで、ユーザー制限を調整できます。自動化の場合、これらの変更を VM イメージにベイクできます。また、Deployment Manager、Terraform、Ansible などのツールを使用して、デプロイ時に制限を調整できます。

ユーザー制限を調整する場合は、次の制限の値を変更します。

  • nproc - プロセスの最大数
  • memlock - 最大ロックイン メモリ アドレス空間(KB)
  • stack - 最大スタックサイズ(KB)
  • nofile - オープン ファイルの最大数
  • cpu - 最大 CPU 時間(分)
  • rtprio - 非特権プロセスに許容されるリアルタイムの最大優先度(Linux 2.6.12 以降)

これらの制限は、Debian、CentOS、Red Hat など、ほとんどの Unix および Linux システムの /etc/security/limits.conf システム構成ファイルで構成されます。

ユーザー制限を変更するには、テキスト エディタを使用して次の値を変更します。

  • /etc/security/limits.conf で次のように変更します。

    *            -     nproc     unlimited
    *            -     memlock   unlimited
    *            -     stack     unlimited
    *            -     nofile    1048576
    *            -     cpu       unlimited
    *            -     rtprio    unlimited
    
  • /etc/security/limits.d/20-nproc.conf で次のように変更します。

    *            -    nproc      unlimited
    

SSH ホストキーを設定する

Intel MPI では、mpirun を実行するノードの ~/.ssh/known_hosts ファイル内にあるすべてのクラスタノードのホストキーが必要です。SSH 認証鍵も authorized_keys に保存する必要があります。

ホストキーを追加するには、次のコマンドを実行します。

ssh-keyscan -H 'cat HOSTFILE' >> ~/.ssh/known_hosts

次のコマンドを実行して、~/.ssh/config ファイルに StrictHostKeyChecking=no を追加する方法もあります。

Host *
StrictHostKeyChecking no

ストレージ

多くの HPC アプリケーションのパフォーマンスは、基盤となるストレージ システムのパフォーマンスに大きく依存します。これは特に、大量のデータを読み書きするアプリケーションや、多数のファイルやオブジェクトを作成またはアクセスするアプリケーションに当てはまります。また、多くのランクが同時にストレージ システムにアクセスする場合も同様です。

NFS ファイル システムまたは並列ファイル システムを選択する

密結合なアプリケーション向けのプライマリ ストレージの種類を以下に示します。それぞれに独自のコスト、パフォーマンス プロファイル、API、整合性セマンティクスがあります。

  • Filestore や NetApp Cloud Volumes などの NFS ベースのソリューションは、共有ストレージ オプションをデプロイするのに最適です。どちらのオプションも Google Cloud でフルマネージドであり、アプリケーションで 1 つのデータセットに対する I/O 要件が厳しくなく、アプリケーションの実行と更新時にコンピューティング ノード間でデータ共有ができない場合に最適です。パフォーマンスの制限については、FilestoreNetApp Cloud Volumes のドキュメントをご覧ください。
  • POSIX ベースの並列ファイル システムは、MPI アプリケーションでより一般的に使用されています。POSIX ベースのオプションには、オープンソースの Lustre と、完全にサポートされた Lustre サービスである DDN Storage EXAScaler Cloud があります。コンピューティング ノードは、データを生成して共有する際に、並列ファイル システムで提供される優れたパフォーマンスを頻繁に利用し、完全な POSIX セマンティクスをサポートします。Lustre などの並列ファイル システムは、大規模なスーパーコンピュータにデータを送信し、何千ものクライアントをサポートできます。また、NetCDFHDF5MPI-IO などのデータ ライブラリや I/O ライブラリをサポートしており、幅広いアプリケーション ドメインの平行 I/O を有効にします。

ストレージ インフラストラクチャを選択する

アプリケーションのパフォーマンス要件は、選択したファイル システムのストレージ インフラストラクチャまたはストレージ階層を示す必要があります。たとえば、1 秒あたりの高い I/O オペレーション(IOPS)が不要なアプリケーション用に SSD をデプロイすると、コストの増加にもかかわらず多くのメリットが得られない可能性があります。

マネージド ストレージ サービスの FilestoreNetApp Cloud Volumes は、容量に基づいてスケーリングする複数のパフォーマンス階層を備えています。

オープンソースの Lustre または DDN Storage EXAScaler Cloud の正しいインフラストラクチャを判断するには、まず、標準永続ディスク、SSD 永続ディスク、またはローカル SSD を使用して必要なパフォーマンスを達成するために必須となる vCPU と容量を把握する必要があります。正しいインフラストラクチャを判断する方法について詳しくは、ブロック ストレージのパフォーマンス情報と、永続ディスクのパフォーマンスの最適化をご覧ください。たとえば Lustre を使用している場合は、メタデータ サーバー(MDS)に SSD 永続ディスク、ストレージ サーバー(OSS)に標準永続ディスクを使用して、低コストで高帯域幅のソリューションをデプロイできます。

ネットワークの設定

多くの HPC アプリケーションでは、MPI ネットワークのパフォーマンスが重要です。この点は特に、異なるノード上の MPI プロセスが頻繁に通信する、またはデータ量の大きい通信を行う密結合なアプリケーションに当てはまります。このセクションでは、MPI パフォーマンスを最適化するためにネットワーク設定を調整する際のベスト プラクティスについて説明します。

tcp_*mem 設定を増やす

C2 マシンは最大 32 Gbps の帯域幅のサポートが可能で、これにはデフォルトの Linux 設定よりも大きい TCP メモリが必要です。ネットワークのパフォーマンスを高めるには、tcp_mem 値を増やします。

TCP メモリ上限を増やすには、/etc/sysctl.conf で次の値を更新します。

net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216

/etc/sysctl.conf に新しい値を読み込むには、sysctl -p を実行します。

ネットワーク レイテンシ プロファイルを使用する

ビジー ポーリングを有効にすることで、一部のアプリケーションのパフォーマンスを向上させることができます。ビジー ポーリングは、ソケットレイヤのコードがネットワーク デバイスの受信キューをポーリングできるようにして、ネットワークの割り込みを無効にすることで、ネットワーク受信パスのレイテンシを短縮します。アプリケーションのレイテンシを評価して、ビジー ポーリングが役立つかどうかを確認します。

ネットワーク レイテンシ プロファイルは再起動後も維持されます。システムに tuned-adm がインストールされている場合は、CentOS で次のコマンドを実行してネットワーク レイテンシ プロファイルを有効にできます。

tuned-adm profile network-latency

システムに tuned-adm がインストールされていない場合は、/etc/sysctl.conf に次のコマンドを追加することで、ビジー ポーリングを有効にできます。

net.core.busy_poll = 50
net.core.busy_read = 50

/etc/sysctl.conf に新しい値を読み込むには、sysctl -p を実行します。

MPI ライブラリとユーザー アプリケーション

MPI ライブラリの設定と HPC アプリケーションの構成は、アプリケーションのパフォーマンスに影響する可能性があります。HPC アプリケーションのパフォーマンスを最大限に引き出すには、それらの設定や構成を詳細に調整することが重要です。このセクションでは、MPI のパフォーマンスを最適化するよう MPI ライブラリとユーザー アプリケーションを調整する際のベスト プラクティスについて説明します。

Intel MPI を使用する

最適なパフォーマンスを得るには、Intel MPI を使用することをおすすめします。

Intel MPI 2018 バージョンの場合、Google Cloud で実行する際に、基盤となる通信ファブリックを指定して共有メモリ専用プロバイダで TCP を使用します。

mpirun -hostfile HOSTFILE -np NUM_PROCESSES \
    -ppn PROCESSES_PER_NODE -genv I_MPI_FABRICS "shm:tcp" APPLICATION

Intel MPI 2019 以降のバージョンでは、パフォーマンス向上のために、基盤となる通信ファブリックを指定して RxM OFI プロバイダで TCP を使用します。

mpirun -hostfile HOSTFILE -np NUM_PROCESSES \
    -ppn PROCESSES_PER_NODE -genv I_MPI_FABRICS "ofi_rxm;tcp" APPLICATION

mpitune を使用して MPI グループの調整を行う

Intel MPI や OpenMPI などの MPI 実装には、通信のパフォーマンスに影響する可能性のある内部構成パラメータが多数あります。これらのパラメータは、MPI グループ通信に特に関連しています。このことによって Google Cloud 環境で大きく異なる動作をする可能性のあるアルゴリズムと構成パラメータの指定が可能です。アプリケーションの特性に基づいて構成パラメータを調整することを強くおすすめします。

MPI グループ通信のアルゴリズムと構成パラメータを手動で指定するには、mpitune の使用をおすすめします。mpitune コマンドを実行するには、ディレクトリへの書き込みアクセス権を持っているか、ルートとしてコマンドを実行する必要があります。

mpitune を使用する場合は、VM 数と VM あたりのプロセス数の組み合わせごとに調整します。たとえば、Intel MPI 2018 バージョンを使用している場合は、次のコマンドを実行して 22 個の VM、VM あたり 30 個のプロセスを調整できます。

mpitune -hf HOSTFILE -fl 'shm:tcp' -pr 30:30 -hr 22:22

上記の mpitune コマンドは、後でアプリケーションの実行に使用できる構成ファイルを Intel MPI ディレクトリに生成します。

アプリケーションの調整構成を使用するには、-tune オプションを mpirun コマンドに追加します。

mpirun -tune -hostfile HOSTFILE -genv I_MPI_FABRICS 'shm:tcp' -np 660 -ppn 30 ./app

調整を有効にするには、I_MPI_FABRICS 環境変数を明示的に指定する必要があります。VM あたりのノード数とノードあたりのプロセス数が、調整中に使用される値と一致する必要があります。

生成された調整ファイルは、intel/mpi/2018.1/etc64 の Intel MPI インストール ディレクトリにあります。

ファイル名は、次のようにデバイス、ノード数、その他の情報をエンコードします。

mpiexec_shm-tcp_nn_22_np_660_ppn_30.conf

対応するディレクトリにファイルをコピーして mpirun コマンドに -tune オプションを追加すると、類似の構成を持つ別の VM のセットでファイルを再利用できます。必要に応じて、構成ファイルを -tune パラメータの後に引数として追加することもできます。

MPI OpenMP ハイブリッド モードを使用する

多くの MPI アプリケーションは、MPI アプリケーションでの OpenMP の有効化に使用できるハイブリッド モードをサポートしています。ハイブリッド モードでは、各 MPI プロセスが固定数のスレッドを使用して特定のループ構造の実行を加速できます。

アプリケーションのパフォーマンスを最適化する場合は、ハイブリッド モード オプションを確認することをおすすめします。ハイブリッド モードを使用すると、各 VM で MPI プロセスを少なくできるため、プロセス間の通信が減少し、全体的な通信時間が短縮されます。

ハイブリッド モードまたは OpenMP を有効にする方法はアプリケーションによって異なります。多くの場合、次の環境変数を設定してハイブリッド モードを有効にできます。

export OMP_NUM_THREADS=NUM_THREADS

このハイブリッド アプローチを使用する場合は、スレッドの合計数が VM の物理コア数を超えないようにすることをおすすめします。c2-standard-60 VM には、15 個のコアの NUMA ソケットが 2 つと、それぞれに 30 個の vCPU があります。複数の NUMA ノードにまたがる OpenMP スレッドを含む MPI プロセスを使用しないことをおすすめします。

ベクトル命令と Math Kernel Library を使用してアプリケーションをコンパイルする

C2 VM は、AVX2、AVX512 のベクトル命令をサポートしています。AVX 命令を使用してコンパイルすることで、多くの HPC アプリケーションのパフォーマンスを向上させることができます。一部のアプリケーションでは、AVX512 の代わりに AVX2 を使用するとパフォーマンスが向上します。ワークロードに対して両方の AVX 命令の試行をおすすめします。科学計算のパフォーマンスを向上させるには、Intel Math Kernel Library(Intel MML)の使用もおすすめします。

適切な CPU 番号を使用する

c2-standard-60 には 2 つの NUMA ソケットがあり、NUMA ノードに関して CPU は次のように番号付けされています。

NUMA node0 CPU(s):     0-14,30-44
NUMA node1 CPU(s):     15-29,45-59

次の図は、c2-standard-60 インスタンスの NUMA ノードにおける各 CPU への CPU 番号の割り当てを示しています。ソケット 0 は CPU 0~14、30~44 を持つ NUMA ノード 0 に対応します。ソケット 1 は、CPU 15~29、45~59 を持つ NUMA ノード 1 に対応します。

c2-standard-60 ノードの仮想コア番号。

VM の単一コアにマッピングされるハイパー スレッドのシブリングスは (0,30)(1,31)..(29,59) です。

Intel MPI では、MPI ジョブのプロセッサの固定に NUMA CPU 番号が使用されます。実行全体で一貫性のある、すべてのノードでコアごとに 1 つのハイパー スレッドを使用する場合は、CPU 番号 0~29 を使用します。

Open MPI は、Portable Hardware Locality(hwloc)によって報告された論理 CPU 番号を使用します。Open MPI を使用する場合、ハイパー スレッドのシブリングスは次のように連続で番号付けされます。

  • ソケット 0: 0(コア 0 HT 0)、1(コア 0 HT 1)、2(コア 1 HT 0)、...、28(コア 14 HT 0)、29(コア 14、HT 1)

  • ソケット 1: 30(コア 0 HT 0)、31(コア 0 HT 1)、2(コア 1 HT 0)、...、58(コア 14 HT 0)、59(コア 14、HT 1)

出力は次のようになります。

lstopo-no-graphics
Machine (240GB total)
  NUMANode L#0 (P#0 120GB) + Package L#0 + L3 L#0 (25MB)
    L2 L#0 (1024KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
      PU L#0 (P#0)
      PU L#1 (P#30)
    L2 L#1 (1024KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
      PU L#2 (P#1)
      PU L#3 (P#31)

Open MPI を使用する場合、CPU 番号 0,2,4,..58 を使用することで、実行全体で一貫性のあるすべてのノード間でコアごとに 1 つのハイパー スレッドを使用できます。MPI でプロセスをコアに固定するには、openMPI の実行時に --bind-to core オプションを使用し、--report-bindings オプションを使用して正しいバインディングを検証します。

セキュリティ設定

組み込みの Linux セキュリティ機能の一部を無効にすると、MPI のパフォーマンスを向上させることができます。これらの各機能を無効にした場合のパフォーマンス上のメリットは異なります。システムが十分に保護されていると確信できれば、次のセキュリティ機能の無効化を検討できます。

Linux ファイアウォールを無効にする

Google Cloud CentOS Linux イメージの場合、ファイアウォールはデフォルトで有効になっています。ファイアウォールを無効にするには、次のコマンドを実行して、firewalld デーモンを停止して無効にします。

sudo systemctl stop firewalld
sudo systemctl disable firewalld
sudo systemctl mask --now firewalld

SELinux を無効にする

CentOS の SELinux はデフォルトで有効になっています。SELinux を無効にするには、/etc/selinux/config ファイルを編集して、SELINUX=enforcing または SELINUX=permissive の行を SELINUX=disabled に置き換えます。

この変更を有効にするには、再起動する必要があります。

Meltdown と Spectre の緩和策を無効にする

Linux システムでは、次のセキュリティ パッチがデフォルトで有効になっています。

  • Variant 1、Spectre: CVE-2017-5753
  • Variant 2、Spectre: CVE-2017-5715
  • Variant 3、Meltdown: CVE-2017-5754
  • Variant 4、Speculative Store Bypass: CVE-2018-3639

これらの CVE に記載されているセキュリティの脆弱性は、Google Cloud にデプロイされたプロセッサを含む、最新のマイクロプロセッサに存在する可能性があります。起動時にカーネル コマンドラインを使用する(再起動しても保持されます)、または実行時に debugfs を使用する(再起動時に保持されません)ことで、これらの複数の緩和策のうち 1 つ以上を無効にできます(関連するセキュリティ リスクを負うことになります)。

上記のセキュリティ対策を完全に無効にするには、次の手順を行います。

  1. ファイル /etc/default/grub を変更します。

    sudo sed -i 's/^GRUB_CMDLINE_LINUX=\"\(.*\)\"/GRUB_CMDLINE_LINUX=\"\1 spectre_v2=off nopti spec_store_bypass_disable=off\"/' /etc/default/grub
    
  2. grub ファイルを変更した後、次のコマンドを実行して GRUB システム構成ファイルを更新してから、システムを再起動します。

    sudo grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
    

    システムに従来の BIOS 起動モードがある場合は、代わりに次のコマンドを実行します。

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg
    
  3. 再起動します。

システムがすでに実行されている場合、次のコマンドを実行すると、上記のセキュリティ対策を無効にできます。これは再起動後は保持されません。

echo 0 > /sys/kernel/debug/x86/pti_enabled
echo 0 > /sys/kernel/debug/x86/retp_enabled
echo 0 > /sys/kernel/debug/x86/ibrs_enabled
echo 0 > /sys/kernel/debug/x86/ssbd_enabled

さまざまな緩和策がシステムに及ぼす影響の可能性と、これらの制御方法については、Red Hat のドキュメントであるマイクロコードとセキュリティ パッチのパフォーマンスへの影響の制御および、投機的ストアバイパスを使用したカーネル サイドチャネル攻撃をご覧ください。

CPU の影響を受ける脆弱性を見つけるには、次のコマンドを実行します。

grep . /sys/devices/system/cpu/vulnerabilities/*

有効になっている緩和策を確認するには、次のコマンドを実行します。

grep . /sys/kernel/debug/x86/*_enabled

チェックリストの概要

次の表に、Compute Engine で MPI を使用するためのベスト プラクティスをまとめます。

領域 タスク
Compute Engine の構成
ストレージ
ネットワークの設定
MPI ライブラリとユーザー アプリケーション
セキュリティ設定

次のステップ