view slide/slide.md @ 52:d0b469710cb2

update fig
author Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
date Sat, 13 Feb 2021 15:41:52 +0900
parents 71e1425687f3
children b6e530c55007
line wrap: on
line source

---
marp: false
title: コンテナ技術を用いた教育情報システムの構築
paginate: true

theme: default
size: 16:9
style: |
  section {
    background-color: #FFFFFF;
    font-size: 28px;
    color: #4b4b4b;
    font-family: "Arial", "Hiragino Maru Gothic ProN";
  }

  section.title {
    font-size: 40px;
    padding: 40px;
  }
  section.title h1 {
    text-align: center;
  }

  section.slide h1 {
    position: absolute;
    left: 50px; top: 35px;
  }

---
<!-- class: title -->
# <!--fit--> コンテナ技術を用いた教育情報システムの構築

- 宮平 賢
    - 琉球大学工学部工学科知能情報コース
- 河野 真治
    - 琉球大学工学部

---
<!-- class: slide -->
# 学生が自由に利用できる教育情報システムの構築

- 情報通信技術の普及に伴い学ぶことが増えている
- その学習環境として、Virtual MachineやContainerがある
    - 実行には高性能なPCが必要な場合がある
    - クラウドサービスもあるが、無料だと制限がある
- 学生の学習環境として、コストを支払う必要のない環境を提供したい
- 今年度はシステム更新があり、新しくSSDとGPUが搭載される
    - リソースを最大限利用できる教育情報システムが必要となる

---
<!-- class: slide -->
# これまでの学生向け学習環境

- VM貸出サービス
    - Akatsuki
        - 申請を行い、Webコントロールパネルから作成
    - ie-virsh
        - 手元のPCで作成したVMイメージのデプロイ

- VM貸出サービスのデフォルトスペック
    - CPU 1コア
    - メモリ 1GB
    - ディスク容量 10GB

---
# これまでの学習環境の問題点

- VM貸出サービスの一部学生は申請の方法が分からなかったり、貸出サービスがあることが周知されていなかったため、旧システムのリソースが余っていた

</br>

- VMのスペックの変更にはシステム管理チームへの申請が必要であり、利用者と管理者とのやり取りなどの手間があった

</br>

- 旧システムにはGPUが搭載されていないため、貸出サービスではなく研究室ごとの機器、クラウドサービスが多く利用された

</br>

- ファイルシステムに使用していたGFS2はロックマネージャの影響が大きく、サーバ1台がクラスタに参加できないとGFS2上にアクセスできなくなった

---
<!-- class: title -->
# 教育情報システムの構築

---
<!-- class: slide -->
# VMベースからコンテナベースへ移行

- 旧システムはVMベースでシステムが構築されていた
- サービスごとにVMがあり、管理に手間が掛かる
- VMベースでは搭載されるGPUを有効活用できない
    - 1つのVMに1台のGPUが必要
- VM貸出サービスをやめるわけではない
- サーバのリソースを効率よく利用できるコンテナへ移行

---
# コンテナ環境の導入

- マルチユーザで利用できるPodman、Singularityを導入する
- Podman
    - rootlessで利用できる
    - nvidia-dockerの設定を行えばGPUを利用できる
- Singularity
    - rootlessで利用できる
    - GPUの利用が容易
        - GPUドライバーのインストールのみ

---
# コンテナエンジンの補い

- Podman
    - イメージの作成やコンテナの作成が遅い
    - rootlessでは実行できない機能がある
        - IPアドレスの割り当て
- Singularity
    - イメージの作成に時間がかかる
        - ビルド中にエラーが発生すると、一から再開する必要がある

- そこでPodmanのwrapperであるie-podmanを作成した

---
# ie-podmanの作成

- ユーザのUID、GIDを取得し管理を行う
    - 他のユーザのリソースを操作できない
- SSD上にイメージ等を保存し、高速を図る

---
# ie-podmanの機能 1/2

- Podmanのすべての機能をwrappするのではなく、一部機能のみを提供する

| コマンド | 機能 |
| --- | --- |
| build| Containerfileの指示に従いイメージを作成する | 
| cp | コンテナにファイルを送信する |
| exec | 起動中のコンテナでプロセスを実行する |
| images | コンテナイメージの一覧を表示する |
| info | コンテナの情報を表示する |
| logs | コンテナのlogを表示する |
| ps | 起動中のコンテナの一覧を表示する |

---
# ie-podmanの機能 2/2

- registryやsifなど独自機能を提供する

| コマンド | 機能 |
| --- | --- |
| registry |  学科のレジストリの操作を行う |
| rm | コンテナを削除する |
| run | コンテナを作成する |
| sif | イメージをsifファイルに変換する |
| start | コンテナを起動する |
| stop | コンテナを停止する |

---
# ジョブスケジューラの導入

- 多くのリソースを必要とするプログラムは管理が必要である
- 4台のサーバのリソースを利用できるようにする必要がある
- そこで、ジョブスケジューラのSlurmを採用する
    - フォールトトレラントで拡張性が高い

---
# ジョブスケジューラの構築

利用方針 **「計算リソースの利用効率を上げる」**
- Jobの優先順位
    - 要求するリソースの少ないJobの優先度を高くする
    - 実行時間が短いJobの優先度を高くする
    - これまでのJobの実行履歴で優先度は変化しない

これでは多くのリソースを要求するJobが実行されない可能性がある。
- Jobの実行時間
    - Jobの実行時間の記載がない場合は**1日で強制終了**させる
    - 管理者からJobの優先度を上げる

また、Jobのスケジュールにはバックフィルを採用する。

---
# ファイルシステムの導入

- Cephを採用
    - 自己修復、自己管理機能を搭載するため信頼性が高い
    - 柔軟なアクセス方法の提供
        - Object Gateway
        - ブロックデバイス
        - POSIX互換のファイルシステム

---
# 教育情報システムの構成

- 汎用サーバ全てにKVM、Podman、Singularityをインストール
- Slurm
    - 汎用サーバ1台をコントローラ/計算ノード
    - 残りを計算ノード
- Ceph
    - ディスクサーバをOSD
    - 汎用サーバ3台をMON, MDS, MGR

---

![bg 80%](images/system.png)

---
<!-- class: title -->
# 教育情報システムの利用と管理

---
<!-- class: slide -->
# ie-podmanの使用方法

- PodmanはDockerと同じCLIを提供している
- IPアドレス、GPUをコンテナへ割り当てられる
    - `ie-podman run --ip --gpu [IMAGE_NAME]`
- 作成したイメージをsifファイルへの変換に対応
    - `ie-podman sif [IMAGE_NAME]`

---
# GPUの利用方法

- Singularityでは容易にGPUを利用できる
    - `singularity run --nv [SIF_NAME]`
- ホームディレクトリ、/tmpなどがコンテナにマウントされる
    - プログラムの実行に便利
- SlurmによるJob管理
    - 必要なリソースを記述し投下する
    - CPU数、GPU数

---
# batchファイルの例

- Jobに必要とするリソース
    - CPU 8コア、GPU 1つ
- Jobの実行時間
    - 1分

```bash
#!/bin/bash
#SBATCH --job-name sample
#SBATCH --output logs/%x-%j.log
#SBATCH --error logs/%x-%j.err
#SBATCH --nodes 1
#SBATCH --cpus-per-task 8
#SBATCH --gpus tesla:1
#SBATCH --time 01:00

singularity exec --nv [SIF_NAME] [COMMANDS]
```

---
<!-- class: title -->
# 教育情報システムの評価

---
<!-- class: slide -->
# ファイルシステムの評価 1/2

- 実験概要
    - `dd`コマンドを使用し書き込み速度を比較する

- 書き込み速度の比較
    - GFS2
    - NFS
    - CephFS
    - CephRBD

---
# ファイルシステムの評価 2/2

![bg 70%](images/fswrite.png)

---
# ie-podmanの評価 1/3

- 実験環境
    - 新システムの汎用サーバで実施

- 実験概要
    - イメージのBuild速度を比較する

```Dockerfile
FROM ubuntu:20.04
RUN apt-get update && \
    apt-get upgrade -y
```

- Build速度の比較
    - Docker
    - Podman (rootless)
    - ie-podman (Podman rootfull wrapper)

---
# ie-podmanの評価 2/3

![bg 70%](images/container2.png)

---
# ie-podmanの評価 3/3

- Rootlessは`syscall`が複数呼ばれている
    - そのため、イメージの作成が遅いのではないか
- 左がrootless、右がrootfull

![height:325](images/syscall.png)

---
<!-- class: title -->
# まとめ

---
<!-- class: slide -->
# 今後の課題

- 教育情報システムの周知
    - Jobの投下やリソースの要求方法
    - ie-virsh、ie-podmanの使用方法
    - 定期的な周知が必要
- ie-podmanのネットワーク構成の見直し
    - プレフィックス長が24のため、最大254個のIPアドレス
    - コンテナを停止で使用されない場合は削除する必要がある
- 基幹サービスすべてのコンテナ移行
    - まだVMで動いている基幹サービスがある
    - コンテナ運用の経験を積んでいきたい