JupyterHubを活用した、いまどきの情報科学の教育環境簡単クラウド構築 (後編)

前編のあらまし

情報科学の演習環境をJupyterHubを用いて構築する方法を、2本の記事でご紹介します。

前編の記事では、情報教育の演習環境の構築を想定して、必要なスペックの算出、さくらのクラウド上にJupyterHubをインストールしたサーバの構築、JupyterHubへのログイン方法やユーザの登録管理方法を説明しました。

この記事は、それに続く後編です。演習環境の運用において必要となる作業として、サーバの停止・起動方法や、サーバのスペックを変更する方法を解説します。

サーバの停止と起動

実行中のサーバのシャットダウンと起動は、ともにさくらのクラウドのコントロールパネルから操作する事ができます。今回設定したTLJHのシステムはSystemd Unitsに関する設定もすでに備えており、システム起動時にはすべての必要なプロセスが起動できるようになっています。したがって、コンロールパネルから起動した後はWebの画面を使って演習をスタートする事ができるため、手動で関連プロセスを実行する必要はありません。つまり起動したらすぐに使える状態になります。

授業やハンズオンでは、事前に決められた時間や期間中はサーバを起動し続ける必要がありますが、起動中は課金が発生しますので、それを織り込んだ運用が必要になります。また、忘れがちですが、サーバをシャットダウンした場合でも、ディスクに対する課金は、そのディスクを削除するまで発生するので注意が必要です。このあたりは、さくらのクラウドのマニュアル「ご利用料金の計算方法」を確認する事をお勧めします。コントロールパネル上段の”?”をクリックするとマニュアルが表示されます。

画面18 電源操作画面

シャットダウンの操作をクラウドのコントロールパネルから行うには、電源操作メニューにあるシャットダウンコマンドを選択します。このコマンドは、チェックボックスで指定したサーバに対して、コマンドを送る事ができる仕組みになっています。

画面19 シャットダウン指定

電源操作メニューのシャットダウンボタンを押すと、対象のサーバを再度表示し、シャットダウンの操作を行うかの確認状態になります。ここでもう一度、右上のシャットダウンボタンを押すことでシャットダウンのプロセスに入る事ができます。

ユーザがJuypterHubを利用している状態でシャットダウンする事は可能な限り避けたいので、事前にJupterHubの管理者画面にて、各ユーザが実行しているサーバサービスをすべて停止する処置を行った後に、サーバ自体のシャットダウンを行うのが運用上無難です。

画面20 シャットダウン状態の表示

シャットダウンが完了すると、一覧にあるサーバのステイタス表示の色が濃いグレーになり、サーバが停止状態にある事が確認できます。

サーバのプラン変更

演習のリハーサルを行い、実際に必要な計算資源のサイズが明らかになったら、すべての資源やディスクをいったん削除して、新しくTLJHのシステムを作り直すのが一番簡単です。ここまで説明してきた事をすべてやり直しても、慣れると10分もあれば、新しいCPUサイズとメモリ、ディスクサイズでシステムを作り直す事ができます。しかしながら、演習がスタートして、参加するユーザがログイン情報を登録し、それぞれのホーム領域に課題データを書き込む作業を行っているのであれば、最初から作り直す事はもはやできません。そんなときは、サーバのプラン変更で対応することができます。

対象のサーバをシャットダウンした後に、プラン変更したいサーバのチェックボックスを付けると、詳細の文字が有効化されます。その詳細ボタンを押すと次の画面が現れます。

CPUとメモリの変更

画面21 サーバの詳細情報の表示方法

新しく現れた画面に「プラン変更」というリンクが現れますので、そのリンクをクリックするとプラン変更画面が現れます。少しメニューが深いですが、情報は簡潔に並んでいるので、容易に目的の変更画面にたどりつけます。

画面22 サーバのプラン変更ボタンの表示

プラン変更は、サーバの設定をした時と同じで、変更したいサーバのプランを選ぶだけで完了します。変更後のサーバを起動すれば、新しいCPUとメモリのサイズで起動出来ます。

画面23 プラン変更の項目(CPU・メモリ)

ディスクのサイズ変更

現在接続されているディスクのサイズアップの手順としては、下記の3つの操作を行います。

  1. 現在サーバに付いているディスクを複製元として、新しい大きなサイズのディスクへ複製を作成する。
  2. サーバに接続されているディスクを、新しいディスクに置き換える。
  3. サーバを起動して、コマンドラインでパーティションを拡張する操作を行い、新しいディスクサイズに適合させる。

以上の3つの操作後に、すべての動作に問題ない事を確認してから、元のディスクを削除する操作をすることで、サーバのディスクのサイズアップが完了します。さくらのクラウドのマニュアルでは、2と3が別の順番で扱われている例もありますが、Ubuntuに関してはコントロールパネル上でのパーティションの拡張をサポートしていないため、ここでは順番が入れ替わり、コマンドラインからの操作を行う必要がでてきます。

一度、複製の処理が始まると、キャンセルをしても複製が完了するまで終わりませんので注意が必要です。特にサイズが大きいディスクの複製には数時間必要になります。

画面24 利用ディスクの一覧表示

コントロールパネルの左にあるストレージ項目の中にディスク一覧を表示する項目があり、現在使われているディスクのリストが表示されます。JupyterHub用に作成したサーバに接続されているシステム用の20GBのサイズのディスクを確認できます。

このディスクを元に、よりサイズの大きな100GBのディスクを作成し、元の20GBに格納されている情報を複製して、新しいサイズの大きな100GBのシステム用のディスクを作成します。新しいディスクは追加ボタンを押すことで作成に必要な項目を入力できます。

画面25 ディスク追加の設定(システム用ディスクからの複製)

20GBのディスクから100GBのディスクの複製を行うのに、約3分程度の時間が必要になります。複製の進行中は、状態が待機中となり利用する事ができませんが、複製が完了すると2個目の新しい100GBのディスクが利用可能と表示されます。

画面26 ディスクを一覧に追加された100GBのディスクが作られた事を確認

20GBディスクがサーバに接続されていて、100GBのディスクは、まだサーバに接続されていない事もリストから判別できます。

画面27 サーバからのディスクの取り外し方法
画面28 取り外しボタンが表示された状態
画面29 サーバからディスクが取り外された状態

今回作成しているサーバの詳細画面にあるディスクのタブを選択すると、サーバに接続しているディスクのリストを表示する事ができます。このリストの右端の三角のマークをクリックするとディスクを取り外す事ができますので、この操作をする事で取り外します。これですべてのディスクが外れた状態になります。

次に接続ボタンを押すことで、このサーバに対して、新たにディスクの接続を指定できるようになります。

画面30 サーバへのディスク接続

接続ボタンを押すと、「既存ディスクを接続」のリストに、さきほど作成した100GBのディスクが現れますので、これを選択し、更新ボタンを押すことで、ディスクの接続が完了します。

この状態になるとサーバを起動する事ができますので、サーバを起動して、入れ換えたディスクのパーティションの拡張操作を行います。

sshを使ってサーバにログインをして、以下の①から⑦項目までを確認しながら設定していきます。

① vdaのサイズが100GBになっている事を確認、vda1が19.9Gとなっている事も確認

ubuntu@sv:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0 55.5M  1 loop /snap/core18/2074
loop1     7:1    0 70.3M  1 loop /snap/lxd/21029
loop2     7:2    0 32.3M  1 loop /snap/snapd/12398
loop3     7:3    0 55.5M  1 loop /snap/core18/2344
loop4     7:4    0 44.7M  1 loop /snap/snapd/15534
loop5     7:5    0 61.9M  1 loop /snap/core20/1405
loop6     7:6    0 67.8M  1 loop /snap/lxd/22753
sr0      11:0    1 1024M  0 rom  
vda     252:0    0  100G  0 disk    <--- ココに注目
├─vda1  252:1    0 19.9G  0 part / <--- ココに注目
├─vda14 252:14   0    4M  0 part 
└─vda15 252:15   0  106M  0 part /boot/efi

② 現在の利用可能容量が16Gと、"/"以下の利用可能な領域が増えていない事を確認

ubuntu@sv:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  968K  3.2G   1% /run
/dev/vda1        20G  3.4G   16G  18% /    <--- ココに注目
tmpfs            16G     0   16G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/loop0       56M   56M     0 100% /snap/core18/2074
/dev/loop1       71M   71M     0 100% /snap/lxd/21029
/dev/vda15      105M  7.9M   97M   8% /boot/efi
tmpfs           3.2G     0  3.2G   0% /run/user/1000
/dev/loop3       56M   56M     0 100% /snap/core18/2344
/dev/loop4       45M   45M     0 100% /snap/snapd/15534
/dev/loop5       62M   62M     0 100% /snap/core20/1405
/dev/loop6       68M   68M     0 100% /snap/lxd/22753

③ /vdaのパーティション1に対して、容量の拡張を行う

ubuntu@sv:~$ sudo growpart /dev/vda 1
CHANGED: partition=1 start=227328 old: size=41715679 end=41943007 new: size=209487839 end=209715167

④ 現在のブロックデバイスvda1が99.9Gと増えた事を確認

ubuntu@sv:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0 55.5M  1 loop /snap/core18/2074
loop1     7:1    0 70.3M  1 loop /snap/lxd/21029
loop3     7:3    0 55.5M  1 loop /snap/core18/2344
loop4     7:4    0 44.7M  1 loop /snap/snapd/15534
loop5     7:5    0 61.9M  1 loop /snap/core20/1405
loop6     7:6    0 67.8M  1 loop /snap/lxd/22753
sr0      11:0    1 1024M  0 rom  
vda     252:0    0  100G  0 disk     <--- ココに注目
├─vda1  252:1    0 99.9G  0 part /  <--- ココに注目
├─vda14 252:14   0    4M  0 part 
└─vda15 252:15   0  106M  0 part /boot/efi

⑤ vda1のファイルシステムの種類を確認(ext4)

NAME    FSTYPE   LABEL           UUID                                 FSAVAIL FSUSE% MOUNTPOINT
loop0   squashfs                                                            0   100% /snap/core18/2074
loop1   squashfs                                                            0   100% /snap/lxd/21029
loop3   squashfs                                                            0   100% /snap/core18/2344
loop4   squashfs                                                            0   100% /snap/snapd/15534
loop5   squashfs                                                            0   100% /snap/core20/1405
loop6   squashfs                                                            0   100% /snap/lxd/22753
sr0                                                                                  
vda      V--- ココに注目                                                                           
├─vda1  ext4     cloudimg-rootfs 73XXXXbb-1045-46fc-99df-XXXXXXXXXXXX   15.5G    19% /
├─vda14                                                                              
└─vda15 vfat     UEFI            BD61-C33D                              96.5M     7% /boot/efi

⑥ ext4用のファイルシステムのサイズ変更コマンドをvda1に対して実行

ubuntu@sv:~$ sudo resize2fs /dev/vda1
resize2fs 1.45.5 (07-Jan-2020)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 3, new_desc_blocks = 13
The filesystem on /dev/vda1 is now 26185979 (4k) blocks long.

⑦ vda1の利用可能領域が93Gと拡張された事を確認

ubuntu@sv:~$ df -Thl
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs   16G     0   16G   0% /dev
tmpfs          tmpfs     3.2G 1000K  3.2G   1% /run
/dev/vda1      ext4       97G  3.9G   93G   4% /        <--- ココに注目
tmpfs          tmpfs      16G     0   16G   0% /dev/shm
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs      16G     0   16G   0% /sys/fs/cgroup
/dev/loop0     squashfs   56M   56M     0 100% /snap/core18/2074
/dev/loop1     squashfs   71M   71M     0 100% /snap/lxd/21029
/dev/vda15     vfat      105M  7.9M   97M   8% /boot/efi
tmpfs          tmpfs     3.2G     0  3.2G   0% /run/user/1000
/dev/loop3     squashfs   56M   56M     0 100% /snap/core18/2344
/dev/loop4     squashfs   45M   45M     0 100% /snap/snapd/15534
/dev/loop5     squashfs   62M   62M     0 100% /snap/core20/1405
/dev/loop6     squashfs   68M   68M     0 100% /snap/lxd/22753

ここまでできたら完了です。JupyterHubの動作確認を行った後に、古い20GBのディスクは削除する事ができます。もしくは、何かのバックアップのために持っておくのも良い考えです。しばらく、20GB程度のサイズであればアーカイブ化しておくのもコストパフォーマンスは良いです。

ここまでは、既存のシステムディスクを初期の20GBから100GBへ拡張させる場合について説明してきました。初期の設計項目について再度提示します。

1クラス20名程度の利用を想定した計算機の設計内容

  1. CPU 10vCPU
  2. メモリ 32GB
  3. ディスク システム用(/) 20GB (1台) ユーザホーム領域用 (/home) 100GB(1台)共有データ領域用(/data) 100GB(1台)
  4. OSはUbuntu Server 20.04.2 LTS 64bit (cloudimg)

現在、システム用のディスクは100GBに拡張されています。元のディスクに再度付け替えれば、上記の設計内容に戻せますので、必要があれば行ってください。今回の例では、このまま100GBのシステムディスクが付いた状態で説明を続けます。

2個目のディスクをサーバに追加する

サーバのディスク領域のサイズアップとしては、先に紹介したサイズの大きなディスクへ複製を行う事で拡張する方法の他に、別の追加のディスクを作成し、複数のディスクで管理する方法もあります。通常、容量が足りなくなるのは、ユーザのhomeなど特定の場所になるので、その場所を新しく追加したディスク領域へ切り出す方法です。このような構成変更は、できるだけユーザの利用が少ない最初の段階で作業を行う方がよいので、今回紹介する例では、実際の演習を開始する前に設定する事をお勧めしています。

画面31 追加Home領域のブランクディスクの作成

先のディスク拡張の時と同じように、追加のディスク作成をコントロールパネル上で行います。その際に、今回はディスクソースとして、「ブランク」を選択し、ディスクサイズを100GBとしてください。

次に、新しく作成するディスクを、クラウドバックエンドで物理的に収納されている機器とは別のストレージに収容するオプションを選択します。このオプションにより、システムディスクが置かれている実体と物理的に異なる機器に収容されるため、耐障害性が上がります。これはクラウドならではのサービスなので、是非ご利用ください。次に名前は「Home領域ディスク」として、わかりやすくしています。以上のオプションの指定を行った後に作成ボタンを押すことで、新しいディスクが作られます。

画面32 新しく作成されたHome領域ディスク

ディスク一覧には、これまで作成した3つのディスクが表示されています。その中に「Home領域ディスク」があり、まだサーバに接続されていない事がわかります。収納ストレージ名が3つとも異なっている事から、物理的に異なる装置に3つのディスクが収容されており、障害に対するリスク分散がされてます。

画面33 JupyterHubサーバに新しいディスクを接続する

対象のサーバの詳細メニューにあるディスク項目には、現在システム用のディスクとして1台が接続されています。この状態で「接続」ボタンを押すことで、新しいディスクを追加で接続できます。

画面34 作成済みディスクの接続画面

既存ディスクにさきほど作成した「Home領域用ディスク」を選択し、更新する事で、新しいディスクをサーバに接続できるようになります。

画面35 JupyterHubサーバに接続されたディスク項目のリスト

以上のように、JupyterHubサーバに新しいディスクが接続されている事が確認できました。ただし、現時点ではブランクのディスクが接続できただけですので、Ubuntuからディスクを使えるように、パーティション設定とファイルシステムのフォーマット作業等を行う必要があります。この段階でサーバを起動して、追加の設定を行っていきます。

画面 36 停止していたサーバの起動

サーバ一覧に表示されている停止サーバをチェックし、電源操作にある「起動」を選ぶ事で、サーバを起動できます。

前回と同様にsshを使い、起動したサーバにログインして、以下のコマンドを実行していきます。

Linuxのviコマンドを使う箇所がこの後にでてきます。viの使い方を知らない場合には、事前に調べて慣れておくか、ubuntu環境でファイルの編集ができるコマンドに慣れる準備をしておくのが良いと思います。

① vdbのディスクが新たに付いた事を確認
ubuntu@sv:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0 55.5M  1 loop /snap/core18/2074
loop1     7:1    0 55.5M  1 loop /snap/core18/2344
loop2     7:2    0 61.9M  1 loop /snap/core20/1405
loop3     7:3    0 70.3M  1 loop /snap/lxd/21029
loop4     7:4    0 44.7M  1 loop /snap/snapd/15534
loop5     7:5    0 67.8M  1 loop /snap/lxd/22753
sr0      11:0    1 1024M  0 rom  
vda     252:0    0  100G  0 disk 
├─vda1  252:1    0 99.9G  0 part /
├─vda14 252:14   0    4M  0 part 
└─vda15 252:15   0  106M  0 part /boot/efi
vdb     252:16   0  100G  0 disk     <---  ココに注目

② vdbのディスクのパーティションの設定をする
ubuntu@sv-113400728073:~$ sudo fdisk /dev/vdb

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x7bd87dff.

Command (m for help): n     <---  新規のパーティション
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p):        <----  pのオプションを選択
                       ここから先はディフォルト値でOK
Using default response p.
Partition number (1-4, default 1): 
First sector (2048-209715199, default 2048): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-209715199, default 209715199): 

Created a new partition 1 of type 'Linux' and of size 100 GiB.

Command (m for help): p    <---   パーティションを確認
Disk /dev/vdb: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x7bd87dff

Device     Boot Start       End   Sectors  Size Id Type
/dev/vdb1        2048 209715199 209713152  100G 83 Linux

Command (m for help): w   <--- パーティション情報の書き込み(重要)
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

③ vdb1のパーティションができているか確認
ubuntu@sv:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0 55.5M  1 loop /snap/core18/2074
loop1     7:1    0 55.5M  1 loop /snap/core18/2344
loop2     7:2    0 61.9M  1 loop /snap/core20/1405
loop3     7:3    0 70.3M  1 loop /snap/lxd/21029
loop4     7:4    0 44.7M  1 loop /snap/snapd/15534
loop5     7:5    0 67.8M  1 loop /snap/lxd/22753
sr0      11:0    1 1024M  0 rom  
vda     252:0    0  100G  0 disk 
├─vda1  252:1    0 99.9G  0 part /
├─vda14 252:14   0    4M  0 part 
└─vda15 252:15   0  106M  0 part /boot/efi
vdb     252:16   0  100G  0 disk 
└─vdb1  252:17   0  100G  0 part   <---  100Gのスペースができた

④ vdb1をext4のファイルシステムでフォーマットする
ubuntu@sv:~$ sudo mkfs -t ext4 /dev/vdb1
mke2fs 1.45.5 (07-Jan-2020)
Creating filesystem with 26214144 4k blocks and 6553600 inodes
Filesystem UUID: bd1345c0-b277-4bba-a52a-9b1ee9e9xxxx
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: done

⑤ vdb1をマウントして利用できる状態にする
ubuntu@sv:~$ sudo mount /dev/vdb1 /mnt/

⑥ 既存の/home以下の内容と同じものを新規のディスク領域(vdb1)に複製する
ubuntu@sv:~$ sudo cp -av /home/* /mnt/
'/home/jupyter-admin123' -> '/mnt/jupyter-admin123'
'/home/jupyter-admin123/.jupyter' -> '/mnt/jupyter-admin123/.jupyter'
'/home/jupyter-admin123/.jupyter/lab' -> '/mnt/jupyter-admin123/.jupyter/lab'
'/home/jupyter-admin123/.jupyter/lab/workspaces' -> '/mnt/jupyter-admin123/.jupyter/lab/workspaces'
'/home/jupyter-admin123/.jupyter/lab/workspaces/default-37a8.jupyterlab-workspace' -> '/mnt/jupyter-admin123/.jupyter/lab/workspaces/default-37a8.jupyterlab-workspace'
'/home/jupyter-admin123/.bash_logout' -> '/mnt/jupyter-admin123/.bash_logout'
'/home/jupyter-admin123/.profile' -> '/mnt/jupyter-admin123/.profile'
'/home/jupyter-admin123/.bashrc' -> '/mnt/jupyter-admin123/.bashrc'
'/home/jupyter-admin123/.local' -> '/mnt/jupyter-admin123/.local'
'/home/jupyter-admin123/.local/share' -> '/mnt/jupyter-admin123/.local/share'
'/home/jupyter-admin123/.local/share/jupyter' -> '/mnt/jupyter-admin123/.local/share/jupyter'
'/home/jupyter-admin123/.local/share/jupyter/runtime' -> '/mnt/jupyter-admin123/.local/share/jupyter/runtime'
'/home/jupyter-admin123/.ipython' -> '/mnt/jupyter-admin123/.ipython'
'/home/ubuntu' -> '/mnt/ubuntu'
'/home/ubuntu/.bash_logout' -> '/mnt/ubuntu/.bash_logout'
'/home/ubuntu/.profile' -> '/mnt/ubuntu/.profile'
'/home/ubuntu/.bashrc' -> '/mnt/ubuntu/.bashrc'
'/home/ubuntu/.ssh' -> '/mnt/ubuntu/.ssh'
'/home/ubuntu/.ssh/authorized_keys' -> '/mnt/ubuntu/.ssh/authorized_keys'
'/home/ubuntu/.cache' -> '/mnt/ubuntu/.cache'
'/home/ubuntu/.cache/motd.legal-displayed' -> '/mnt/ubuntu/.cache/motd.legal-displayed'
'/home/ubuntu/.sudo_as_admin_successful' -> '/mnt/ubuntu/.sudo_as_admin_successful'

⑦ vdb1のディスクをアンマウントする
ubuntu@sv:~$ sudo umount /mnt/

⑧ vdb1の固有ID(UUID)を確認(注意! UUIDはディスク固有のIDなので、以下のIDは各自の環境で一致する事はありません)
ubuntu@sv:~$ sudo blkid /dev/vdb1
/dev/vdb1: UUID="bd1345c0-b277-4bba-a52a-9b1ee9exxxx" TYPE="ext4" PARTUUID="7bd87dff-01"

⑨ fstabにvdb1のUUIDを使ってマウントする情報を書き込む(viの使い方を調べてから行ってください)
ubuntu@sv:~$ sudo vi /etc/fstab 
LABEL=cloudimg-rootfs    /    ext4   defaults    0 1
LABEL=UEFI    /boot/efi   vfat    umask=0077  0 1
/dev/disk/by-uuid/bd1345c0-b277-4bba-a52a-9b1ee9exxxx /home ext4 defaults 0 0

⑩fstabにあるパーティションボリュームをマウントする
ubuntu@sv:~$ sudo mount -a

⑪Home領域がマウントされ、利用可能容量が増えている事を確認
ubuntu@sv:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  996K  3.2G   1% /run
/dev/vda1        97G  3.7G   94G   4% /
tmpfs            16G     0   16G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/vdb1        98G   61M   93G   1% /home     <--- ここに注目
/dev/loop0       56M   56M     0 100% /snap/core18/2074
/dev/loop2       62M   62M     0 100% /snap/core20/1405
/dev/loop1       56M   56M     0 100% /snap/core18/2344
/dev/vda15      105M  7.9M   97M   8% /boot/efi
/dev/loop4       45M   45M     0 100% /snap/snapd/15534
/dev/loop3       71M   71M     0 100% /snap/lxd/21029
/dev/loop5       68M   68M     0 100% /snap/lxd/22753
tmpfs           3.2G     0  3.2G   0% /run/user/1000

今回の例は元のシステムディスクにある/homeを削除していません。通常この手の作業の際には、複製後は削除するのが定説なのですが、私の場合は考えがあり残しています。例えば、Home領域のディスクを外した状態で起動したい場合は、/etc/fstabの/homeの行をコメントアウトして再起動すれば、元の/homeにアクセスする事ができるようになり、/home/ubuntu/.sshにある公開鍵も、そのまま利用する事が可能となります。これが時には便利なので、/homeは削除せずに残しています。

Ubuntuユーザのパスワードは、クラウドコントロールパネルにあるコンソールからログインする事を想定すると、設定しておくのをお勧めしておきます。sudo passwd ubuntu でいつでも設定可能です。

3つ目のディスクをサーバに追加する

情報科学の演習を行う場合に、学生が演習で利用するデータを提供しなければならないケースがあります。例えば、コンピュータビジョンなどの機械学習演習では、学習用の画像ファイルを多数用意しなければならないケースもありますし、バイオインフォマティクスでは公共データベースなども必要になります。そのような少し大きめのファイルを共有するには、別のディスクにして、サーバに簡単に着脱できるように管理しておくとアセットとして管理できるので、入れ換えや使い回しに便利です。

そのようなニーズから、Home領域の追加と同様にブランクディスクを作成して、現在のサーバに接続し、共有データ領域として構築します。ディスクの追加はサーバが停止した状態で行うため、現在起動しているサーバは必ず停止してから次の作業に移ってください。

画面37 新しい共有データ領域用ディスクの追加

ディスク一覧には、これまで作成してきたディスクが一覧されていると思います。Home領域ディスクを作成した時と同じように、追加ボタンを押すことで、新しいディスクの追加画面を表示させる事ができます。

画面38 共有データ領域ディスクの追加

先のHome領域と同じ要領で、ディスクプランやディスクソースやサイズに関する項目を設定していきます。今回、接続先サーバを、作成段階で指定する方法をとります。ドロップダウンメニューに表示される、これまで作成してきたJupyterHubのサーバを選択します。これにより、ディスク作成時にサーバに接続された状態で追加できます。

画面39 ディスク一覧

ディスク一覧には、これまで作成した4つのディスクが表示されているはずです。サーバ項目から、3つのディスクが接続されているのが確認出来ます。この状態で、JupyterHubサーバを起動させる事ができます。

① 3つ目のディスクのvdcが見えている事を確認します。
ubuntu@sv-113400728073:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0 55.5M  1 loop /snap/core18/2074
loop1     7:1    0 55.5M  1 loop /snap/core18/2344
loop2     7:2    0 61.9M  1 loop /snap/core20/1405
loop3     7:3    0 70.3M  1 loop /snap/lxd/21029
loop4     7:4    0 67.8M  1 loop /snap/lxd/22753
loop5     7:5    0 44.7M  1 loop /snap/snapd/15534
sr0      11:0    1 1024M  0 rom  
vda     252:0    0  100G  0 disk 
├─vda1  252:1    0 99.9G  0 part /
├─vda14 252:14   0    4M  0 part 
└─vda15 252:15   0  106M  0 part /boot/efi
vdb     252:16   0  100G  0 disk 
└─vdb1  252:17   0  100G  0 part 
vdc     252:32   0  100G  0 disk     <---  ココに注目

② vdcにパーティションを新規作成する
ubuntu@sv-113400728073:~$ sudo fdisk /dev/vdc

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x82d0c30a.

Command (m for help): n      <-- 新規パーティション作成
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):   <--- 1番
First sector (2048-209715199, default 2048):  <---  デフォルト値でOK
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-209715199, default 209715199): 

Created a new partition 1 of type 'Linux' and of size 100 GiB.

Command (m for help): p      <-- パーティションを確認
Disk /dev/vdc: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x82d0c30a

Device     Boot Start       End   Sectors  Size Id Type
/dev/vdc1        2048 209715199 209713152  100G 83 Linux

Command (m for help): w      <--  パーティション情報を書き込み(重要)
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

③ vdc1のパーティションが作成されている事を確認
ubuntu@sv-113400728073:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0 55.5M  1 loop /snap/core18/2074
loop1     7:1    0 55.5M  1 loop /snap/core18/2344
loop2     7:2    0 61.9M  1 loop /snap/core20/1405
loop3     7:3    0 70.3M  1 loop /snap/lxd/21029
loop4     7:4    0 67.8M  1 loop /snap/lxd/22753
loop5     7:5    0 44.7M  1 loop /snap/snapd/15534
sr0      11:0    1 1024M  0 rom  
vda     252:0    0  100G  0 disk 
├─vda1  252:1    0 99.9G  0 part /
├─vda14 252:14   0    4M  0 part 
└─vda15 252:15   0  106M  0 part /boot/efi
vdb     252:16   0  100G  0 disk 
└─vdb1  252:17   0  100G  0 part 
vdc     252:32   0  100G  0 disk 
└─vdc1  252:33   0  100G  0 part    <--- ココに注目

④ vdc1をext4のファイルシステムでフォーマットする
ubuntu@sv-113400728073:~$ sudo mkfs -t ext4 /dev/vdc1 
mke2fs 1.45.5 (07-Jan-2020)
Creating filesystem with 26214144 4k blocks and 6553600 inodes
Filesystem UUID: 77310dab-a755-41e9-b5a1-196f2220xxxx
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: done

⑤ vdc1のUUIDを表示
ubuntu@sv-113400728073:~$ sudo blkid /dev/vdc1
/dev/vdc1: UUID="77310dab-a755-41e9-b5a1-196f2220xxxx" TYPE="ext4" PARTUUID="82d0c30a-01"

⑥ vdc1のマウント先となるディレクトリ(/data)を作成
ubuntu@sv-113400728073:~$ sudo mkdir /data

⑦ fstabにvdc1のUUIDを使ってマウントする情報を書き込む
ubuntu@sv-113400728073:~$ sudo vi /etc/fstab
LABEL=cloudimg-rootfs    /    ext4   defaults    0 1
LABEL=UEFI    /boot/efi   vfat    umask=0077  0 1
/dev/disk/by-uuid/bd1345c0-b277-4bba-a52a-9b1ee9e9xxxx /home ext4 defaults 0 0
/dev/disk/by-uuid/77310dab-a755-41e9-b5a1-196f2220xxxx /data ext4 defaults 0 0

⑧ fstabに書かれているボリュームをマウント
ubuntu@sv-113400728073:~$ sudo mount -a

⑨ マウントしたパーティションボリュームを確認
ubuntu@sv-113400728073:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G 1004K  3.2G   1% /run
/dev/vda1        97G  3.7G   94G   4% /
tmpfs            16G     0   16G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/loop0       56M   56M     0 100% /snap/core18/2074
/dev/loop2       62M   62M     0 100% /snap/core20/1405
/dev/loop1       56M   56M     0 100% /snap/core18/2344
/dev/loop4       68M   68M     0 100% /snap/lxd/22753
/dev/loop3       71M   71M     0 100% /snap/lxd/21029
/dev/loop5       45M   45M     0 100% /snap/snapd/15534
/dev/vda15      105M  7.9M   97M   8% /boot/efi
tmpfs           3.2G     0  3.2G   0% /run/user/1000
/dev/vdb1        98G   61M   93G   1% /home   <--- ココに注目
/dev/vdc1        98G   61M   93G   1% /data   <--- ココに注目

以上で目標のサーバの構築が完了しました。作成したのは、以下の設計内容のJuypterHubサーバとなります。

1クラス20名程度の利用を想定した計算機の設計内容

  1. CPU 10vCPU
  2. メモリ 32GB
  3. ディスク システム用(/) 20GB (1台) ユーザホーム領域用 (/home) 100GB(1台)共有データ領域用(/data) 100GB(1台)
  4. OSはUbuntu Server 20.04.2 LTS 64bit (cloudimg)

このあとは、機械学習だったり、バイオインフォマティクスの関連モジュールを、pipを使ってインストールすればよいだけです。TLJHでは、すべての演習者の環境は共通のsite-packagesで管理されているので、adminユーザが必要なモジュールをインストールする事で、すべてのユーザで共有されます。

今回はJupyterHubを使った演習環境のバニラ版といえる環境を作成してみました。基礎的なLinuxの知識があれば構築する事ができると思いますので、是非演習環境を構築する際に試してみてください。

最後に

Jupyterhubを使ったいまどきの情報科学教育環境をクラウドを使って作成する例を紹介しました。これまでの大学や大学院の教育現場でのニーズを踏まえて、できるだけ実践的な構成を意識して構築してみました。今回は演習を目的として構築しましたが、選択するCPUやメモリをハイスペックな構成にして、研究分野で利用する事も十分可能かと思いますので、いろいろと試してみてください。

なお、今回作るシステムの利用に関しては、OSSである事を十分理解した上で、自己責任のリスクになる事をご理解ください。