バーチャル富岳に触ってみる(AWS上でスパコン)

下記の手順で「プライベート富岳」の環境を構築する
1. AWSのEC2インスタンス作成
2. ParallelClusterのインストール
3. ParallelClusterでクラスタを作成するための定義ファイルの作成
4. クラスタの作成
5. Singularityのインストール
6. アプリの実行

申し訳ありません。先ほどは違う文脈のSingularityについて説明してしまいました。

Singularity CE（Community Edition）は、コンテナ技術を使用したHPC（High Performance Computing）向けのコンテナプラットフォームです。以下が主な特徴です：

1. 主な機能：
- HPCワークロード用に最適化されたコンテナ実行環境
- rootless実行が可能
- 既存のDockerコンテナとの互換性
- セキュアなコンテナ実行環境の提供

2. 利点：
- スーパーコンピュータでの使用に適している
- 再現性の高い実行環境の構築が可能
- 科学計算やHPC環境での移植性が高い
- セキュリティが強化されている

3. 使用例：
```bash
# コンテナイメージのビルド
singularity build mycontainer.sif docker://ubuntu:latest

# コンテナの実行
singularity run mycontainer.sif

# シェルアクセス
singularity shell mycontainer.sif

$ python3 -m pip install --upgrade pip
/usr/bin/python3: No module named pip

python3 -m pip install --upgrade "aws-parallelcluster"

$ pcluster version
{
  "version": "3.11.1"
}

はい、これまでのやり取りを精査して、シングルAZのメリット・デメリットを改めて整理します。

シングルAZの構成：
```yaml
SubnetIds:
  - subnet-123abc  # 単一AZ
ComputeResources:
  Instances:
    - InstanceType: c6gn.16xlarge
```

メリット：
1. ネットワークパフォーマンス：
```plaintext
- 低レイテンシ（〜0.1-0.3ms）
- 高帯域幅（最大100 Gbps）
- ノード間の直接通信が効率的
```

2. コスト効率：
```plaintext
- AZ間データ転送コストが発生しない
- ネットワーク利用料金の最適化
```

3. シンプルな構成：
```plaintext
- ネットワーク設計がシンプル
- 構成管理が容易
- トラブルシューティングが容易
```

デメリット：
1. AZ障害時のリスク：
```plaintext
- システム全体が影響を受ける
- フェイルオーバー先がない
- サービス継続性への影響大
```

2. インフラストラクチャの制約：
```plaintext
- 単一障害点（SPOF）となる
- 障害発生時の代替手段が限定的
```

特に適したワークロード：
```plaintext
1. HPC密結合計算：
   - MPI通信を多用する計算
   - レイテンシ重視の処理
   - ノード間通信が頻繁な処理

2. リアルタイム処理：
   - 低レイテンシが必要な処理
   - 即時性が求められる計算
```

重要な考慮点：
1. 可用性要件：
```plaintext
- 業務クリティカル度
- 許容可能なダウンタイム
- リカバリ要件
```

2. パフォーマンス要件：
```plaintext
- レイテンシ要件
- スループット要件
- ノード間通信パターン
```

結論：
- HPCワークロードの特性に基づいて選択すべき
- 密結合計算では、シングルAZが最適な選択
- 可用性よりもパフォーマンスを重視する場合はシングルAZ
- ミッションクリティカルな要件がある場合は可用性も考慮

これまでの議論を通じて、特にHPC向けのバーチャル富岳のような環境では、パフォーマンスの観点からシングルAZの構成が望ましいことが明確になりました。

Image:
  Os: alinux2
HeadNode:
  InstanceType: t2.micro
  Networking:
    SubnetId: subnet-12345678
  Ssh:
    KeyName: ec2-key-name
Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: queue1
      Networking:
        SubnetIds:
          - subnet-12345678
      ComputeResources:
        - Name: compute-resource1
          InstanceType: c5.2xlarge

pcluster configure --config config-file.yaml

Region: ap-northeast-1
Image:
  Os: alinux2
HeadNode:
  InstanceType: t2.micro
  Networking:
    SubnetId: subnet-xxxxxx
  Ssh:
    KeyName: parallelCluster
Scheduling:
  Scheduler: slurm
  SlurmQueues:
  - Name: queue1
    ComputeResources:
    - Name: c52xlarge
      Instances:
      - InstanceType: c5.2xlarge
      MinCount: 0
      MaxCount: 10
    Networking:
      SubnetIds:
      - subnet-xxxxxx

pcluster create-cluster --cluster-name test-cluster --cluster-configuration cluster-config.yaml

The VPC uses an existing subnet that supports public IP addresses.

pcluster delete-cluster --cluster-name hackathon-parallelcluster

pcluster create-cluster --cluster-configuration ./slurm-gen.yaml --cluster-name hackathon-parallelcluster --region ap-northeast-1

$ pcluster ssh -n hackathon-parallelcluster -i parallelCluster 

sudo yum install -y golang

$ ./mconfig && \
    make -C ./builddir && \
    sudo make -C ./builddir install

$ singularity pull library://riken-rccs/virtual-fugaku/vf-ver1
FATAL:   While pulling library image: error fetching image: image does not exist in the library: riken-rccs/virtual-fugaku/vf-ver1:latest (amd64)

Region: ap-northeast-1
Image:
  Os: alinux2
HeadNode:
  InstanceType: t4g.micro
  Networking:
    SubnetId: subnet-xxxxxxx
  Ssh:
    KeyName: parallelCluster
Scheduling:
  Scheduler: slurm
  SlurmQueues:
  - Name: queue1
    ComputeResources:
    - Name: c72xlarge
      Instances:
      - InstanceType: c7g.2xlarge
      MinCount: 0
      MaxCount: 10
    Networking:
      SubnetIds:
      - subnet-xxxxxx

pcluster create-cluster --cluster-configuration ./slurm-gen.yaml --cluster-name hackathon-parallelcluster --region ap-northeast-1

ntasks ≤ nodes × ntasks-per-node

ntasks-per-node × cpus-per-task ≤ 利用可能なコア数（c7g.2xlargeの場合8）

総使用コア数 = nodes × ntasks-per-node × cpus-per-task

--------------------------------------------------------------------------
mpiexec was unable to find the specified executable file, and therefore
did not launch the job.  This error was first reported for process
rank 0; it may have occurred for other processes as well.
NOTE: A common cause for this error is misspelling a mpiexec command
line parameter option (remember that mpiexec interprets the first
unrecognized command line token as the executable).
Node:       queue1-dy-c72xlarge-1
Executable: singularity
--------------------------------------------------------------------------

  SlurmSettings:
    QueueUpdateStrategy: TERMINATE

Region: ap-northeast-1
Image:
  Os: alinux2
HeadNode:
  InstanceType: t4g.micro
  Networking:
    SubnetId: subnet-xxxxx
  Ssh:
    KeyName: parallelCluster
Scheduling:
  Scheduler: slurm
  SlurmSettings:
    QueueUpdateStrategy: TERMINATE
  SlurmQueues:
  - Name: queue1
    ComputeResources:
    - Name: c72xlarge
      Instances:
      - InstanceType: c7g.2xlarge
      MinCount: 0
      MaxCount: 10
    Networking:
      SubnetIds:
      - subnet-xxxxxxxx
    Image:
      CustomAmi: ami-xxxxxx

➜  ~ aws ec2 describe-images \
    --region ap-northeast-1 \
    --owners amazon \
    --filters "Name=name,Values=*parallelcluster-3.11.1*amzn*arm64*" \
    --query 'Images[].[ImageId,Name,CreationDate]' \
    --output table
----------------------------------------------------------------------------------------------------------------------------------------------
|                                                               DescribeImages                                                               |
+-----------------------+---------------------------------------------------------------------------------------+----------------------------+
|  ami-05198bef7ec3f0b54|  aws-parallelcluster-3.11.1-amzn2023-hvm-arm64-202410180018 2024-10-18T00-21-48.194Z  |  2024-10-18T15:45:49.000Z  |
|  ami-051c728b3aec2cda7|  aws-parallelcluster-3.11.1-amzn2-hvm-arm64-202410180018 2024-10-18T00-21-33.705Z     |  2024-10-18T15:44:11.000Z  |
|  ami-0d11c8188b8a0951f|  aws-parallelcluster-3.11.1-amzn2023-hvm-arm64-202410180018 2024-10-18T00-21-48.194Z  |  2024-10-21T07:48:47.000Z  |
|  ami-0f6505e88226e7dfd|  aws-parallelcluster-3.11.1-amzn2-hvm-arm64-202410180018 2024-10-18T00-21-33.705Z     |  2024-10-21T07:47:02.000Z  |
+-----------------------+---------------------------------------------------------------------------------------+----------------------------+

sudo /usr/local/sbin/ami_cleanup.sh

spdyn: error while loading shared libraries: libhwloc.so.5: cannot open shared object file: No such file or directory

【一般的なコンテナの考え方】
- 完全な独立性
- 環境の完全な封じ込め
- どこでも同じ動作
- ホストとの分離

【HPCでのコンテナの考え方】
- ホストのハードウェアと密接に連携
- MPIやハードウェアライブラリはホスト依存
- 性能最適化のためにホストの情報が必要
- ハイブリッドアプローチが一般的

通常のコンテナ：
Webサーバー → 完全な独立性が重要

HPCコンテナ：
数値計算 → ホストのハードウェア特性の理解が重要

mpiexec --use-hwthread-cpus -n ${SLURM_NTASKS} singularity -v run --bind /usr/lib64/libhwloc.so.5:/usr/lib64/libhwloc.so.5 ${SIFFILE} spdyn p${SLURM_NTASKS}.inp

mpiexec --use-hwthread-cpus -n ${SLURM_NTASKS} singularity -v run \
	--bind /usr/lib64/libhwloc.so.5:/usr/lib64/libhwloc.so.5 \
	--bind /usr/lib64/libevent_core-2.0.so.5:/usr/lib64/libevent_core-2.0.so.5 \
	--bind /usr/lib64/libevent_pthreads-2.0.so.5:/usr/lib64/libevent_pthreads-2.0.so.5 \
	--bind /usr/lib64/libgfortran.so.4:/usr/lib64/libgfortran.so.4 \
	--bind /usr/lib64/libnuma.so.1:/usr/lib64/libnuma.so.1 \
	--bind /usr/lib64/libltdl.so.7:/usr/lib64/libltdl.so.7 \
	${SIFFILE} spdyn p${SLURM_NTASKS}.inp

Region: ap-northeast-1
Image:
  Os: alinux2
HeadNode:
  InstanceType: t4g.micro
  Networking:
    SubnetId: subnet-xxxxxxxx
  LocalStorage:
    RootVolume:
      Size: 64
      Encrypted: true
      VolumeType: gp2
      Iops: 100
      DeleteOnTermination: true
  Ssh:
    KeyName: parallelCluster
  Image:
    CustomAmi: ami-xxxxxxxx
Scheduling:
  Scheduler: slurm
  SlurmSettings:
    QueueUpdateStrategy: TERMINATE
  SlurmQueues:
  - Name: queue1
    ComputeResources:
    - Name: c72xlarge
      Instances:
      - InstanceType: c7g.2xlarge
      MinCount: 0
      MaxCount: 10
    Networking:
      SubnetIds:
      - subnet-xxxxxxxx
    Image:
      CustomAmi: ami-xxxxxxxx