今年４月にリリースされたubuntu 24.04 LTSを使いHPC Clusterを構築する
この記事は未完成です。完成まで少しお待ちください。
今年４月にリリースされたUbuntu 24.04 LTSを使いHPC Clusterを構築します。この記事を書くに至った理由は次のとおりです。
私のお客様でHPC Clusterをお使いの方は何人かいらっしゃいますが、その中にCentOS 6.3の時代にHPC Clusterを構築させていただいて、毎年ノードを追加しながら25ノードのクラスタまで成長した事例があります。今年度１ノードを追加する際にOSも最新のものにアップグレードすることになりました。現地でスクラッチからHPC Clusterを構築するのは、時間もかかりますし、予期しないトラブルへの対処も難しいことから、私の作業場で小規模なHPC Clusterを構築して動作検証を行い、そのOSクローンを行ったUSBを使い、現地でノード数を拡大するという手順を採用しました。この記事では私の作業場での小規模HPC Cluster構築の手順を実際の体験に基づいて記述していきます。この方法で構築した26台のHPC Clusterがお客様の大学で順調に稼働しており、日夜計算が流されています。HPC Clusterを構築したい読者の役に立つよう、最短手数でのクラスタ構築の解説を行います。
この記事では４台のPCを使ってHPC Clusterを構築します(HPC Cluster構成図参照)。
HPC Clusterではノード（HPC Clusterを構成するコンピュータ）間でファイルの共有、ユーザ情報の共有、ジョブスケジューラ（空いているノードに計算を流すソフトウェア）、プログラムのソースコードを高速に実行できるバイナリコードに変換するコンパイラ、複数ノードを使う並列プログラムを実行可能にするMPIライブラリなどが必要になります。
この記事では、ファイル共有はNFS、ユーザ情報の共有はNIS、ジョブスケジューラはSlurm、コンパイラとMPIライブラリはIntel oneAPIを使用します。
各ノードにUbuntu 24.04をインストールして、各種の設定を行う必要がありますが、個別に行なっていては時間がかかり過ぎていつ終わるか分かりません。この記事ではHead NodeにUbuntu 24.04と必要なソフトウェアパッケージを全てインストールして、それをSystem Clonerを使って、USBメモリにクローンします。Compute Nodeでは、USBメモリから立ち上げて、USBメモリの内容をCompute Nodeのシステムディスクにクローンして、/etc/hostnameとIPアドレスをCompute Node様に書き換えます。これを3台のCompute Nodeで行い、Head Nodeからsshで全てのノードで必要なサービスを立ち上げます。これでHPC Clusterが完成します。この手順をこの後具体的に詳しく解説していきます。
Head Node/Compute Node 01にUbuntu 24.04 Serverをインストールする
ここからUbuntu 24.04 ServerのisoイメージをダウンロードしてUSBメモリなどに書き込んで、そのUSBメモリからブートします。ダウンロードしたisoイメージをUSBメモリに書き込むコマンドは、Linux上では
dd if=ubuntu-24.04-live-server-amd64.iso of=USBメモリのデバイス名（/dev/sdbなど） bs=1M
の様になります。
インストールは特に難しい点はありませんが、LVMを使わない様にすることと、OpenSSH Serverをインストールする点に注意してください。
インストール後の初期設定
インストールが終わりリブートすると、ハードウェアの構成によっては
と表示され90秒待たされる場合があります。リブート時に毎回待たされて時間の無駄ですので、その場合は
sudo systemctl disable systemd-networkd-wait-online.service
sudo systemctl mask systemd-networkd-wait-online.service
を実行すると、待たされることがなくなります。
ログインすると比較的長めのメッセージが毎回表示されますので、これをなくすために、
sudo chmod -x /etc/update-motd.d/*
を実行します。
TimezoneをAsia/Tokyoにする
現在のTimezoneは
hpc@node01:~$ date
Fri Jul 26 11:22:42 PM UTC 2024
hpc@node01:~$
これをAsia/Tokyoにするには
sudo timedatectl set-timezone Asia/Tokyo
を実行します。
hpc@node01:~$ sudo timedatectl set-timezone Asia/Tokyo
[sudo] password for hpc:
hpc@node01:~$ date
Sat Jul 27 08:29:46 AM JST 2024
hpc@node01:~$
時刻をNTPサーバと同期する
systemd-timesyncdを使用してNTPサーバと時刻同期を行います。
sudo timedatectl set-ntp true
/etc/systemd/timesyncd.confの最後に
[Time]
NTP=ntp.nict.jp
FallbackNTP=ntp.ubuntu.com
を付け加えて
sudo systemctl restart systemd-timesyncd
を実行します。
その結果、時刻がNTPサーバと同期しているか確かめるにはtimedatectl statusを実行します。
hpc@node01:~$ timedatectl status
Local time: Sat 2024-07-27 08:48:15 JST
Universal time: Fri 2024-07-26 23:48:15 UTC
RTC time: Fri 2024-07-26 23:48:15
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
hpc@node01:~$
•Local time: 現地時間（JST）。
•Universal time: 協定世界時（UTC）。
•RTC time: リアルタイムクロックの時間。
•Time zone: 設定されているタイムゾーン（Asia/Tokyo）。
•System clock synchronized: システムクロックがNTPサーバと同期されているかどうか（yesと表示されているので同期されています）。
•NTP service: NTPサービスの状態（activeと表示されているのでアクティブです）。
•RTC in local TZ: リアルタイムクロックがローカルタイムゾーンに設定されているかどうか（noと表示されていますが、通常これは問題ありません）。
すべての設定が正しく行われ、NTPサーバと時刻が同期されていることが確認できました。これでシステムの時刻は自動的に正確に保たれます。
公開鍵認証を設定する
Ubuntu 24.04で公開鍵認証を使用することの主なメリットは次の通りです：
1. セキュリティの向上:
•パスワード認証に比べて、公開鍵認証は非常に強力でセキュリティが高いです。パスワードは簡単に推測されたり、ブルートフォース攻撃にさらされたりする可能性がありますが、公開鍵は複雑で推測が困難です。
2. ブルートフォース攻撃の防止:
•パスワード認証を使用すると、ブルートフォース攻撃でパスワードを試行されるリスクがあります。公開鍵認証を使用することで、このリスクを大幅に軽減できます。
3.利便性:
•公開鍵認証を使用すると、一度設定すればパスワードを毎回入力する必要がなくなります。これにより、サーバーへのアクセスが迅速かつ効率的になります。
4. 自動化のサポート:
•スクリプトや自動化ツールを使用してサーバーにアクセスする場合、公開鍵認証は非常に便利です。パスワードを入力する必要がないため、自動化されたプロセスが中断されることなく実行されます。
Ubuntu 24.04において、SSH公開鍵認証を設定することで、これらのメリットを享受し、セキュアで効率的なサーバー管理を実現することができます。
公開鍵認証の設定
ssh-keygen -t rsa
を入力し表示される質問には全てenterを入力します。
hpc@node01:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hpc/.ssh/id_rsa): Created directory '/home/hpc/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/hpc/.ssh/id_rsa
Your public key has been saved in /home/hpc/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:WyrNcTa6RZdPey6Ax+wJX4bDK8jtPxwtvbANUf7Furw hpc@node01
The key's randomart image is:
+---[RSA 3072]----+
| |
| . |
| o . |
| ... o|
| S *=o=.o.|
| o Xoo&o*..|
| ..*o.* /oo.|
| .ooo O *o |
| ...o..Eo.|
+----[SHA256]-----+
hpc@node01:~$
生成された~/.ssh/id_rsa.pubを~/.ssh/authorized_keysにコピーして、authorized_kaysファイルの属性をオーナーのみのrwに変更します。
hpc@node01:~$ cd ~/.ssh
hpc@node01:~/.ssh$ cp id_rsa.pub authorized_keys
hpc@node01:~/.ssh$ chmod og-r authorized_keys
SSH設定ファイルの変更
/etc/ssh/sshd_configファイルで、以下の行を確認（そうなっていない場合は以下の様に変更する）または追加します。
#include/etc/ssh/sshd_config.d/*.conf
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
/etc/ssh/ssh_configファイルで
# StrictHostKeyChecking ask
を
StrictHostKeyChecking no
に変更します。
変更を反映させるために
sudo systemctl restart ssh
を実行します。設定変更を確認するため、ssh localhostを実行します。
hpc@node01:~$ ssh localhost
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Last login: Sat Jul 27 10:07:25 2024 from 192.168.11.4
hpc@node01:~$
パスワードなしでログインできましたので、公開鍵認証の動作確認が取れました。
rootでも公開鍵認証を設定する
HPC（高性能計算）クラスターで、Ubuntu 24.04を使用してrootでの公開鍵認証を必要とする理由は次の通りです：
1. セキュリティの強化: ルートアカウントでのパスワード認証は、ブルートフォース攻撃やパスワード盗難によるリスクが高まります。公開鍵認証を使用することで、パスフレーズがない限り、鍵の紛失や盗難があっても第三者が容易にアクセスすることは困難になります。
2. 自動化: HPCクラスターでは、ジョブのスケジューリングやノードの管理など、多くのタスクが自動化されることが一般的です。公開鍵認証を使用することで、スクリプトや自動化ツールがルート権限を必要とする操作を安全に実行できるようになります。
3. アクセス制御: 公開鍵認証を使用することで、特定のマシンやユーザーに対するアクセス制御がより厳密に行えます。特定の公開鍵を持つユーザーのみがルートアクセスできるように設定することが可能です。
4. 管理の一元化: クラスター全体のルートアクセス管理を中央集権化することで、セキュリティポリシーの一貫性を保ち、管理が簡素化されます。公開鍵認証を使用すると、クラスター全体のルートキーの一元管理が容易になります。
5. ログインの迅速化: パスワードを入力する必要がないため、公開鍵認証によりログインが迅速に行えるようになります。これにより、管理者や自動化スクリプトの作業効率が向上します。
6. セッションのセキュアな確立: 公開鍵認証により、セッションが確立される際にデータが暗号化されるため、セキュアな接続が保証されます。これにより、ネットワーク経由の通信が盗聴されるリスクが減少します。
これらの理由から、HPCクラスターでのrootアカウントの管理には公開鍵認証が推奨されます。これにより、セキュリティを強化し、効率的な管理と自動化を実現することができます。
rootでの公開鍵認証の設定
sudo -iでrootになり、ssh-keygen -t rsaで鍵ファイルを作成します。/root/.ssh/id_rsa.pubを/root/.ssh/authorized_keyにコピーし、属性をオーナーのみのrwに設定します。
sudo -i
ssh-keygen -t rsa
cat /root/.ssh/id_rsa.pub >>/root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys
/etc/ssh/sshd_configファイルを編集します。以下の行を見つけて変更または追加します。
PermitRootLogin yes
PubkeyAuthentication yes
設定を反映させるためにSSHサービスを再起動します。
systemctl restart ssh
rootのままssh localhostを実行してログインできるか確認します。
root@node01:~# ssh localhost
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
root@node01:~#
rootでのsshも公開鍵認証を使ってパスワード無しでログインできることが確認できました。これで他ノードのシステム設定などを容易に行うことができます。
Ethernetデバイス名をeth0, eth1...に変更する
デフォルトでは
hpc@node01:~$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 84:47:09:2d:bd:14 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.3/24 metric 100 brd 192.168.11.255 scope global dynamic enp2s0
valid_lft 151227sec preferred_lft 151227sec
inet6 2400:2410:25c1:400:8647:9ff:fe2d:bd14/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86376sec preferred_lft 14376sec
inet6 fe80::8647:9ff:fe2d:bd14/64 scope link
valid_lft forever preferred_lft forever
3: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 84:47:09:2d:bd:16 brd ff:ff:ff:ff:ff:ff
4: wlp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 90:e8:68:c1:fc:29 brd ff:ff:ff:ff:ff:ff
の様に、enp2s0、enp3s0となっているEthernetデバイス名を、eth0, eth1となる様に変更します。
1. ネットワーク名予測法の無効化：
/etc/default/grubファイル中の、下記の行を見つけ
GRUB_CMDLINE_LINUX=""
を以下の様に変更します。
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
変更を保存して、grubの設定を更新します。
sudo update-grub
2. ネットワーク設定の変更：
元からあった/etc/netplan/50-cloud-init.yamlを名称変更します。
sudo mv /etc/netplan/50-cloud-init.yaml /etc/netplan/50-cloud-init.yaml.bak
次に、ネットワークインターフェースの設定ファイルを更新します。eth0をクラスタ内部通信用の192.168.10.1/24に、eth1をdhcpにするためには、/etc/netplan/01-netcfg.yamlファイルに
network:
version: 2
ethernets:
eth0:
addresses:
- 192.168.10.1/24
dhcp4: no
eth1:
dhcp4: yes
を書き込みます。
3. 設定の適用：
変更を保存して、grubの変更とnetplanの設定を適用するためリブートします。
sudo reboot
これで、eth0は静的IPアドレス192.168.10.1/24を持ち、eth1はDHCPでIPアドレスを取得するように設定されます。
hpc@node01:~$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:5f:67:c1:72:eb brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/24 brd 192.168.10.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 20:7b:d2:25:a9:b5 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.9/24 metric 100 brd 192.168.11.255 scope global dynamic eth1
valid_lft 172782sec preferred_lft 172782sec
4: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ac:82:47:4a:4f:66 brd ff:ff:ff:ff:ff:ff
altname wlp3s0
hpc@node01:~$
インストールされているパッケージを最新にする
基本設定の最後に、現在インストールされているパッケージを最新にしておきます。
sudo apt update
sudo apt upgrade -y
カーネルがアップグレードされるとリブートが必要になりますのでリブートします。
HPC Clusterに必要なパッケージをインストールする
node01の立ち上げ後、必要なパッケージをインストールしていきます。全ノード共通で必要なパッケージは、nfs-kernel-server、nis、autofs、そしてslurm-wlmです。これに加えて、Intel oneAPIのパッケージも必要ですが、これはnode01のみにインストールし、他のノードではNFSを通じて共有します。そのため、ここではIntel oneAPIのインストールは行いません。もちろん、Intel oneAPIを全ノードにインストールすることも可能ですが、将来的なアップデートの際に全ノードで更新作業が必要になり、大容量のため時間と手間がかかることを避けるために、node01にのみインストールし、NFSを利用して共有する方法を選びます。
sudo apt install nfs-kernel-server nis autofs slurm-wlm -y
不要なサービスを停止する
systen_clonerで他のノードにコピーするためのUSBメモリを作成する前に、HPC Clusterで不要なサービスを停止しておきます。現在実行中のサービスのリストはsystemctl list-units --type=service --state=runningで見ることができます。
hpc@node01:~$ systemctl list-units --type=service --state=running
UNIT LOAD ACTIVE SUB DESCRIPTION
autofs.service loaded active running Automounts filesystems on demand
bolt.service loaded active running Thunderbolt system service
cron.service loaded active running Regular background program processing daemon
dbus.service loaded active running D-Bus System Message Bus
fsidd.service loaded active running NFS FSID Daemon
fwupd.service loaded active running Firmware update daemon
getty@tty1.service loaded active running Getty on tty1
ModemManager.service loaded active running Modem Manager
multipathd.service loaded active running Device-Mapper Multipath Device Controller
munge.service loaded active running MUNGE authentication service
nfs-blkmap.service loaded active running pNFS block layout mapping daemon
nfs-idmapd.service loaded active running NFSv4 ID-name mapping service
nfs-mountd.service loaded active running NFS Mount Daemon
nfsdcld.service loaded active running NFSv4 Client Tracking Daemon
nscd.service loaded active running Name Service Cache Daemon
polkit.service loaded active running Authorization Manager
rpc-statd.service loaded active running NFS status monitor for NFSv2/3 locking.
rpcbind.service loaded active running RPC bind portmap service
rsyslog.service loaded active running System Logging Service
ssh.service loaded active running OpenBSD Secure Shell server
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running User Login Management
systemd-networkd.service loaded active running Network Configuration
systemd-resolved.service loaded active running Network Name Resolution
systemd-timesyncd.service loaded active running Network Time Synchronization
systemd-udevd.service loaded active running Rule-based Manager for Device Events and Files
thermald.service loaded active running Thermal Daemon Service
udisks2.service loaded active running Disk Manager
unattended-upgrades.service loaded active running Unattended Upgrades Shutdown
upower.service loaded active running Daemon for power management
user@1000.service loaded active running User Manager for UID 1000
wpa_supplicant.service loaded active running WPA supplicant
Legend: LOAD → Reflects whether the unit definition was properly loaded.
ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
SUB → The low-level unit activation state, values depend on unit type.
32 loaded units listed.
hpc@node01:~$
この中でHPC Clusterに不要なサービスは
1. ModemManager.service
•モデム管理サービス。HPC クラスターには通常不要です。
2. packagekit.service
•パッケージ管理サービス。自動更新を行うためのもので、手動で管理している場合は不要です。
3. polkit.service
•権限管理サービス。HPC クラスターでは、特に必要でない場合は無効にできます。
4. thermald.service
•熱管理デーモン。特定のハードウェアや環境でのみ必要です。
5. udisks2.service
•ディスク管理サービス。HPC クラスターでは手動でディスクを管理することが多いため不要です。
6. upower.service
•電源管理デーモン。デスクトップ環境向けで、HPC クラスターでは通常不要です。
7. wpa_supplicant.service
•無線ネットワークのサポート。HPC クラスターが有線ネットワークのみを使用している場合は不要です。
不要なサービスを停止してリブートしても起動しない様にするには
sudo systemctl stop ModemManager.service
sudo systemctl disable ModemManager.service
sudo systemctl stop packagekit.service
sudo systemctl disable packagekit.service
sudo systemctl stop polkit.service
sudo systemctl disable polkit.service
sudo systemctl stop thermald.service
sudo systemctl disable thermald.service
sudo systemctl stop udisks2.service
sudo systemctl disable udisks2.service
sudo systemctl stop upower.service
sudo systemctl disable upower.service
sudo systemctl stop wpa_supplicant.service
sudo systemctl disable wpa_supplicant.service
を実行します。その結果
hpc@node01:~$ systemctl list-units --type=service --state=running
UNIT LOAD ACTIVE SUB DESCRIPTION
autofs.service loaded active running Automounts filesystems on demand
bolt.service loaded active running Thunderbolt system service
cron.service loaded active running Regular background program processing daemon
dbus.service loaded active running D-Bus System Message Bus
fsidd.service loaded active running NFS FSID Daemon
fwupd.service loaded active running Firmware update daemon
getty@tty1.service loaded active running Getty on tty1
multipathd.service loaded active running Device-Mapper Multipath Device Controller
munge.service loaded active running MUNGE authentication service
nfs-blkmap.service loaded active running pNFS block layout mapping daemon
nfs-idmapd.service loaded active running NFSv4 ID-name mapping service
nfs-mountd.service loaded active running NFS Mount Daemon
nfsdcld.service loaded active running NFSv4 Client Tracking Daemon
nscd.service loaded active running Name Service Cache Daemon
packagekit.service loaded active running PackageKit Daemon
polkit.service loaded active running Authorization Manager
rpc-statd.service loaded active running NFS status monitor for NFSv2/3 locking.
rpcbind.service loaded active running RPC bind portmap service
rsyslog.service loaded active running System Logging Service
ssh.service loaded active running OpenBSD Secure Shell server
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running User Login Management
systemd-networkd.service loaded active running Network Configuration
systemd-resolved.service loaded active running Network Name Resolution
systemd-timesyncd.service loaded active running Network Time Synchronization
systemd-udevd.service loaded active running Rule-based Manager for Device Events and Files
unattended-upgrades.service loaded active running Unattended Upgrades Shutdown
user@1000.service loaded active running User Manager for UID 1000
Legend: LOAD → Reflects whether the unit definition was properly loaded.
ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
SUB → The low-level unit activation state, values depend on unit type.
28 loaded units listed.
hpc@node01:~$
となります。
System Clonerのインストール
System Clonerはこの記事のような各種のCluster構築や、お客様からご注文いただいたHPCサーバやGPUサーバなどにOSと必要なパッケージをインストーする作業を短時間で容易に行うことを目的として、私が約25年前に開発し、OSの進化と多様化に伴い、System Clonerも進化してきました。その特徴は、OSが専有している領域しかコピーしないので、短時間でクローンが終わり、かつシステムディスクより小容量のUSBメモリなどでも（OSが専有している容量より大きければ）クローンが可能です。操作は簡単でクローン先のデバイスを識別できる１文字を入力するだけです。今回の26台のクラスタの全ノードにクローンする作業も、短時間で誤りなく行うことができました。RedHat系OS用とDebian系OS用の2種類があります。今回はUbuntu 24.04ですのでDebian系用のSystem Clonerをインストールします。System Clonerはbinary executable fileです。clone2sdがSATA HDD/SSD (USBメモリもSATA SSDとして認識される）用、clone2nvmeがNVMe SSD (M.２, U.2など）用です。/usr/local/sbinにインストールします。rootでしか実行できません。
hpc@node01:~$ which clone2sd
hpc@node01:~$ sudo which clone2sd
/usr/local/sbin/clone2sd
hpc@node01:~$ which clone2nvme
hpc@node01:~$ sudo which clone2nvme
/usr/local/sbin/clone2nvme
hpc@node01:~$
node02~node04へのnode01のクローンのやり方
System Clonerでnode01のOSをUSBメモリにクローンして、そのUSBメモリでnode02を立ち上げnode02のSSD/HDDにUSBメモリをクローンします。その際、IPアドレスとhostnameをnode02様に変更する必要があります。System Clonerでのクローンが終わってからエディタで修正する方法もありますが、自動的に行う方が便利で間違いを防げます。
change_node_and_ip_after_cloneというラッパーを作り、
change_node_and_ip_after_clone clone2sd a 2
の様に使うことにします。USBメモリから立ち上げてUSBメモリの内容をノードのSSD/HDDである/dev/sdaにクローンした後、hostnameをnode02にIPアドレスを192.168.10.2に変更するコマンドです。その内容は
#!/bin/bash
if [ "$#" -lt 3 ]; then
echo "Usage: $0 <command> <command_params> <new_number>"
exit 1
fi
COMMAND=$1
shift
COMMAND_PARAMS=$1
shift
NEW_NUMBER=$(printf "%02d" $1)
# Execute the provided command with its parameters
$COMMAND $COMMAND_PARAMS
# Update /mnt/etc/hostname
sudo sed -i "s/node[0-9]\+/node${NEW_NUMBER}/" /mnt/etc/hostname
# Update /mnt/etc/netplan/01-netcfg.yaml
sudo sed -i "s/192.168.10.[0-9]\+/192.168.10.${NEW_NUMBER}/" /mnt/etc/netplan/01-netcfg.yaml
# Remove eth1 from /mnt/etc/netplan/01-netcfg.yaml
sudo sed -i '/eth1:/,/dhcp4: yes/d' /mnt/etc/netplan/01-netcfg.yaml
echo "Executed '$COMMAND $COMMAND_PARAMS', updated /mnt/etc/hostname and /mnt/etc/netplan/01-netcfg.yaml with node${NEW_NUMBER}, 192.168.10.${NEW_NUMBER}, and removed eth1"
の様になります。このコマンドも/usr/local/sbinに入れておきます。
node01のOSの内容をUSBメモリにクローンしてBaseUSBを作る
OSがインストールされているのは/dev/nvme0n1になります。
hpc@node01:~$ df -h Filesystem Size Used Avail Use% Mounted on tmpfs 3.2G 2.0M 3.2G 1% /run efivarfs 192K 59K 129K 32% /sys/firmware/efi/efivars /dev/nvme0n1p2 938G 6.8G 884G 1% / tmpfs 16G 0 16G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/nvme0n1p1 300M 6.2M 294M 3% /boot/efi tmpfs 3.2G 12K 3.2G 1% /run/user/1000 hpc@node01:~$
使用している容量は/が6.8G, /boot/efiが6.2Mですので、クローンするUSBメモリの容量は8GB以上あれば十分です。
USBメモリをnode01に差込、デバイス名を確認します。
sudo fdisk -l /dev/sd*
実行してみると
hpc@node01:~$ sudo fdisk -l /dev/sd*
Disk /dev/sda: 115.63 GiB, 124160966656 bytes, 242501888 sectors
Disk model: USB DISK 3.0
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: gpt
Disk identifier: 24A6C1ED-A5CB-4CA7-9C91-E6CF299881DA
Device Start End Sectors Size Type
/dev/sda1 2048 616447 614400 300M EFI System
/dev/sda2 616448 242501854 241885407 115.3G Linux filesystem
Disk /dev/sda1: 300 MiB, 314572800 bytes, 614400 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: 0x00000000
Disk /dev/sda2: 115.34 GiB, 123845328384 bytes, 241885407 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
hpc@node01:~$
となり/dev/sdaがUSBメモリと分かります。
このUSBにOSをクローンするコマンドは
sudo clone2sd a
になります。実際に実行して時間を測ってみると
hpc@node01:~$ sudo time clone2sd a
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Creating new GPT entries in memory.
The operation has completed successfully.
The operation has completed successfully.
mkfs.fat 4.2 (2021-01-31)
mke2fs 1.47.0 (5-Feb-2023)
/dev/sda2 contains a ext4 file system
last mounted on / on Tue Jul 16 10:52:17 2024
Proceed anyway? (y,N) y
Creating filesystem with 30235675 4k blocks and 7561216 inodes
Filesystem UUID: 3978af07-6ed3-441b-900d-43107ca16f3b
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
rsync -a --exclude=/snap/* --exclude=/tmp/* --exclude=/run/* --exclude=/dev/* --exclude=/proc/* --exclude=/sys/* --exclude=/mnt/* / /mnt
117
117
559
559
modprobe: FATAL: Module efivars not found in directory /lib/modules/6.8.0-39-generic
chroot /mnt grub-install /dev/sda
Installing for x86_64-efi platform.
grub-install: warning: EFI variables cannot be set on this system.
grub-install: warning: You will have to complete the GRUB setup manually.
Installation finished. No error reported.
chroot /mnt update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.0-39-generic
chroot /mnt update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-39-generic
Found initrd image: /boot/initrd.img-6.8.0-39-generic
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
6.81user 17.19system 2:11.41elapsed 18%CPU (0avgtext+0avgdata 30080maxresident)k
83061inputs+14417648outputs (1major+693182minor)pagefaults 0swaps
hpc@node01:~$
と2分11秒でクローンが終わりました。出来上がったUSBメモリを以降はBase USBと呼びます。
BaseUSBの取り出し
sudo umount_clone
を実行してから取り出してください。
BaseUSBからnode02のシステムディスクにクローンする
node02にBaseUSBを差し込み、BIOSでUSBメモリからブートする様に設定して、ブートします。ブートしたら、システムディスクのデバイス名をdf -hなどで確認します。
root@node01:~# df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 777M 1.4M 775M 1% /run
efivarfs 128K 95K 29K 77% /sys/firmware/efi/efivars
/dev/sdb2 113G 6.8G 101G 7% /
tmpfs 3.8G 0 3.8G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sdb1 300M 6.2M 294M 3% /boot/efi
tmpfs 777M 12K 777M 1% /run/user/1000
tmpfs 777M 12K 777M 1% /run/user/0
root@node01:~#
上記からシステムディスクは/dev/sdbであることがわかります。/dev/sdbがあれば/dev/sdaもありますので、node02では/dev/sdaが内蔵SSD/HDDになります。そこでBaseUSBを/dev/sdaにクローンして、hostnameをnode02に変更し、IPアドレスを192.168.10.2に変更します。このためのコマンドは"change_node_and_ip_after_clone clone2sd a 2"になります。これを実行して時間を計測してみましょう。
3分50秒でクローンが終わりました。node02~node04はamazonで￥15,0000で購入した非力なPCなのでSSDの速度が遅く時間がかかった様です。
リブートして内蔵SSD/HDDから立ち上げ、node01からsshでログインしてみましょう。node01の/etc/hostsは
127.0.0.1 localhost 192.168.10.1 node01 192.168.10.2 node02 192.168.10.3 node03 192.168.10.4 node04の
の内容です。
hpc@node01:~$ ssh node02 Last login: Sun Jul 28 16:37:43 2024 from 192.168.10.1 hpc@node02:~$ exit logout Connection to node02 closed. hpc@node01:~$ sudo -i root@node01:~# ssh node02 Last login: Sun Jul 28 15:58:21 2024 from 192.168.10.1 root@node02:~#
node01からnode02にユーザ：hpc, root共にログインできることが確認できました。node03, node04でも同様にクローンを繰り返します。
全ノードの動作確認(BaseUSB)
クローンが終了後各ノードをリブートし、以降はnode01でrootで作業をします。各ノードが正しく設定されているか確認しましょう。
root@node01:~# for node in `seq -f "node%02g" 1 4`;do ssh $node 'hostname;ip address|grep inet';done
node01
inet 127.0.0.1/8 scope host lo
inet 192.168.10.1/24 brd 192.168.10.255 scope global eth0
inet 192.168.11.9/24 metric 100 brd 192.168.11.255 scope global dynamic eth1
node02
inet 127.0.0.1/8 scope host lo
inet 192.168.10.2/24 brd 192.168.10.255 scope global eth0
node03
inet 127.0.0.1/8 scope host lo
inet 192.168.10.3/24 brd 192.168.10.255 scope global eth0
node04
inet 127.0.0.1/8 scope host lo
inet 192.168.10.4/24 brd 192.168.10.255 scope global eth0
root@node01:~#
node01~node04のhostnameとIPアドレスが正しく設定されていることが確認できました。
IPマスカレード
HPC（High-Performance Computing）クラスタでのIPマスカレードの必要性は、主にネットワークのセキュリティと管理のために役立ちます。以下に、HPCクラスタでIPマスカレードが必要となる主な理由を説明します。
1. プライベートIPアドレスの保護
HPCクラスタ内のノードは、通常プライベートIPアドレスを使用します。これにより、外部ネットワークからの直接アクセスを防ぎ、セキュリティを高めることができます。IPマスカレードを使用すると、プライベートIPアドレスを持つノードが外部ネットワークと通信するときに、クラスタのゲートウェイのパブリックIPアドレスに変換されるため、内部のアドレスを隠すことができます。
2. ネットワーク管理の簡略化
複数のノードがインターネットにアクセスする必要がある場合、各ノードに対して個別のパブリックIPアドレスを割り当てるのは非効率です。IPマスカレードを使用することで、クラスタ全体が1つのパブリックIPアドレスを共有して外部ネットワークと通信することができ、ネットワーク管理が簡単になります。
3. セキュリティの強化
IPマスカレードにより、外部から内部ネットワークへの直接アクセスを制限することができます。これにより、外部からの攻撃に対する防御が強化されます。クラスタのノードは外部に対して一つのパブリックIPアドレスを使うため、外部の攻撃者が特定のノードを標的にするのが難しくなります。
4. ネットワークアドレスの有効利用
多くのプライベートIPアドレスを使用することで、限られたパブリックIPアドレス空間を効率的に利用できます。IPマスカレードを使用すると、一つのパブリックIPアドレスで多数のプライベートIPアドレスを持つデバイスがインターネットにアクセスできるようになります。
5. トラフィック制御
IPマスカレードを使用することで、クラスタのゲートウェイを通じてすべての外部トラフィックを制御できます。これにより、トラフィックの監視や制限、フィルタリングを行いやすくなります。例えば、特定のノードからのトラフィックを優先したり、特定のプロトコルをブロックすることができます。
まとめ
HPCクラスタでIPマスカレードを使用することは、セキュリティ、管理の簡便性、ネットワーク資源の効率的な利用に大きく貢献します。これにより、クラスタ全体のパフォーマンスとセキュリティが向上し、安定した運用が可能になります。
node01でeth1をインターネット接続用、eth0をクラスタ内部用としてIPマスカレードを設定するには
1. 必要なパッケージのインストール
まず、必要なパッケージをインストールします。
sudo apt update
sudo apt install iptables-persistent
2. IPマスカレードの設定
iptablesを使用してIPマスカレードを設定します。
iptables設定スクリプトの作成
まず、iptablesの設定を行うスクリプトを作成します。/etc/iptables/rules.v4に次の内容を書き込みます。
*nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o eth1 -j MASQUERADE COMMIT *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A FORWARD -i eth0 -o eth1 -j ACCEPT -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT
3. sysctl.confの設定
カーネルのIPフォワーディングを有効にするために、/etc/sysctl.confを編集します。
次の行を見つけてコメントを外します（または存在しない場合は追加します）。
net.ipv4.ip_forward=1
設定を有効にするために、次のコマンドを実行します。
sudo sysctl -p
node02~node04でnode01のIPマスカレードを利用するには
node02~node04でデフォルトゲートウェイをnode01のIPアドレス192.168.10.1に設定します。これだけだと名前解決ができないので、DNSも設定します。大学などのDNSがある組織ではDNSのIPアドレスは組織のものに設定します。自前のDNSがない場合は、8.8.8.8, 8.8.4.4などのgoogleのDNSのIPアドレスを設定すればいいでしょう。ここでは後者の方法を使います。
1. 現在の設定内容の確認
まず、現在の/etc/netplan/01-netcfg.yamlの内容を確認します。
root@node01:~# ssh node02 cat /etc/netplan/01-netcfg.yaml
network:
version: 2
ethernets:
eth0:
addresses:
- 192.168.10.2/24
dhcp4: no
root@node01:~#
2. ファイルを編集してデフォルトゲートウェイとDNSを追加
次に、デフォルトゲートウェイとDNSサーバーを追加するためにファイルを編集します。SSH経由でsedコマンドを使用して編集することもできますが、ここでは直接echoコマンドを使用して内容を一括して置き換える方法を紹介します。
ssh root@node02 "echo 'network:
version: 2
ethernets:
eth0:
addresses:
- 192.168.10.2/24
dhcp4: no
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
routes:
- to: default
via: 192.168.10.1' > /etc/netplan/01-netcfg.yaml"
結果を確認すると
root@node01:~# ssh node02 cat /etc/netplan/01-netcfg.yaml
network:
version: 2
ethernets:
eth0:
addresses:
- 192.168.10.2/24
dhcp4: no
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
routes:
- to: default
via: 192.168.10.1
root@node01:~#
となり無事書き換えが終わりました。
3. 設定の適用
ファイルを編集した後、netplan applyコマンドを実行して設定を適用します。
ssh node02 netplan apply
4. 動作確認
apt updateとtimedatectlで外部サーバーとの接続を確認します。
root@node01:~# ssh node02 apt update
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Get:1 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Hit:2 http://jp.archive.ubuntu.com/ubuntu noble InRelease
Get:3 http://jp.archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Get:4 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages [256 kB]
Hit:5 http://jp.archive.ubuntu.com/ubuntu noble-backports InRelease
Get:6 http://jp.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages [300 kB]
Get:7 http://security.ubuntu.com/ubuntu noble-security/main Translation-en [60.5 kB]
Get:8 http://security.ubuntu.com/ubuntu noble-security/restricted amd64 Packages [208 kB]
Get:9 http://security.ubuntu.com/ubuntu noble-security/restricted Translation-en [40.7 kB]
Get:10 http://jp.archive.ubuntu.com/ubuntu noble-updates/main Translation-en [77.2 kB]
Get:11 http://jp.archive.ubuntu.com/ubuntu noble-updates/restricted amd64 Packages [208 kB]
Get:12 http://jp.archive.ubuntu.com/ubuntu noble-updates/restricted Translation-en [40.7 kB]
Fetched 1,443 kB in 2s (701 kB/s)
Reading package lists...
Building dependency tree...
Reading state information...
All packages are up to date.
root@node01:~# ssh node02 timedatectl
Local time: Tue 2024-07-30 11:09:30 JST
Universal time: Tue 2024-07-30 02:09:30 UTC
RTC time: Tue 2024-07-30 02:09:30
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
root@node01:~#
問題なく接続できていることがわかります。
node02~node04（ノード数可変）にデフォルトゲートウェイとDNSを設定するスクリプト
node02で行った手順をnode03とnode04でも繰り返します。node数が少ないと手動での設定も可能ですが、node数が10を超えると、時間と労力が増え、間違いの可能性も増えます。自動的に行うスクリプトが必須となります。
以下のscriptを/usr/local/sbin/set_gw_and_dnsに書き込みchmod 700 /usr/local/sbin/set_gw_and_dnsを行います。
#!/bin/bash
# ノードのスタートとエンド
START=2
END=4
# ノードプレフィックス
NODE_PREFIX="node"
# 基本のIPアドレス部分（プレフィックス）
IP_PREFIX="192.168.10."
# ノードの設定を変更
for i in `seq $START $END`; do
NODE=$(printf "${NODE_PREFIX}%02d" $i)
IP="${IP_PREFIX}${i}"
echo Processing $NODE
ssh root@$NODE "echo 'network:
version: 2
ethernets:
eth0:
addresses:
- ${IP}/24
dhcp4: no
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
routes:
- to: default
via: 192.168.10.1' > /etc/netplan/01-netcfg.yaml && netplan apply"
done
このスクリプトを使うと
node02~node04までのデフォルトゲートウェイとDNSを自動的に変更し設定を適用します。scriptの最初のSTARTとENDを書き換えれば、何ノードでも一気に変更可能です。
ヘッドノードを除く全ノードでsshでコマンド実行するclsshと、ヘッドノードから他の全ノードにファイルをコピーするclscpを用意する
以降の作業で、ヘッドノードを除く全ノードでsshでコマンド実行することと、ヘッドノードから他の全ノードにファイルをコピーすることが頻発しますので、clsshとclscpコマンドを作っておきます。
/usr/local/sbin/clsshは
#!/bin/bash # 対象ノードの最初と最後を設定 START=2 END=4 # ノードプレフィックスを設定 NODE_PREFIX=node for node in `seq -f "$NODE_PREFIX%02g" $START $END`;do echo ssh $node $* ssh $node $* done
/usr/local/sbin/clscpは
#!/bin/bash
# 対象ノードの最初と最後を設定
START=2
END=4
# ノードプレフィックスを設定
NODE_PREFIX=node
# 変数の初期化
all_params=("$@")
last_param="${all_params[-1]}"
other_params=("${all_params[@]:0:${#all_params[@]}-1}")
param_count=$#
for node in `seq -f "$NODE_PREFIX%02g" $START $END`;do
if [ $param_count -eq 1 ]; then
echo scp $1 $node:$1
scp $1 $node:$1
else
echo scp ${other_params[@]} $node:$last_param
scp ${other_params[@]} $node:$last_param
fi
done
NISの設定
このHPC ClusterではNISを使って全ノードでユーザ情報を共有します。CentOS6.3時代からNISを使ってきましたので、同じやり方でできるものはそのまま使うということで、NISの使用を継続します。
NISのマスターサーバがnode01でスレーブサーバがnode02になります。node03とそれ以降はクライアントになります。
Ubuntu 24.04のHPCクラスターでNIS（Network Information Service）を使用することには、いくつかの利点と欠点があります。
利点
1.集中管理:
•NISを使用すると、ユーザーアカウントやパスワード、ホスト名などの情報を集中管理できます。これにより、管理が簡素化されます。
2.一貫性:
•全てのノードで同じユーザー情報を使用するため、ユーザーがどのノードにログインしても同じ環境が提供されます。
3. スケーラビリティ:
•NISは複数のノードにまたがる大規模なクラスターでも効率的に動作します。
4. 容易なセットアップ:
•NISの設定は比較的簡単であり、既存のネットワーク環境に容易に導入できます。
欠点
1. セキュリティ:
•NISはセキュリティ面での脆弱性があります。パスワード情報が暗号化されていない形でネットワークを流れるため、盗聴されるリスクがあります。しかし、パスワードを使用しないのでこの問題は解消されます。
2.信頼性:
•NISサーバがダウンすると、全てのNISクライアントが影響を受け、ユーザー認証が行えなくなります。このクラスタではスレーブサーバを用意して、サーバダウンのリスクを分散します。
3. スケーラビリティの限界:
•非常に大規模なクラスターや、複雑なネットワーク構成ではNISの性能が問題になることがあります。
4. 新しい技術との互換性:
•NISは古い技術であり、LDAPやKerberosなどのより新しいディレクトリサービスに比べて機能が限定されています。
node01でNISのマスターサーバを設定する
NISのパッケージは全ノードですでにインストール済みですので設定のみを行います。
1. NISドメインネームの設定
/etc/defaultdomainにNISの任意のdomain nameを書き込みます。ここではhpcdiyとします。
sudo echo hpcdiy >/etc/defaultdomain
2. /etc/yp.confと/etc/nsswitch.confを編集
/etc/yp.conf
# # yp.conf Configuration file for the ypbind process. You can define # NIS servers manually here if they can't be found by # broadcasting on the local net (which is the default). # # See the manual page of ypbind for the syntax of this file. # # IMPORTANT: For the "ypserver", use IP addresses, or make sure that # the host is in /etc/hosts. This file is only interpreted # once, and if DNS isn't reachable yet the ypserver cannot # be resolved and ypbind won't ever bind to the server. # ypserver ypserver.network.com ypserver node01 ypserver node02
/etc/nsswitch.conf
# /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: files systemd nis group: files systemd nis shadow: files systemd nis gshadow: files systemd hosts: files dns nis networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis
3. /etc/ypserv.securenetを編集して192.168.10.0/24からのアクセスのみ許可
# # securenets This file defines the access rights to your NIS server # for NIS clients. This file contains netmask/network # pairs. A clients IP address needs to match with at least # one of those. # # One can use the word "host" instead of a netmask of # 255.255.255.255. Only IP addresses are allowed in this # file, not hostnames. # # Always allow access for localhost, IPv4 and IPv6 255.0.0.0 127.0.0.0 host ::1 # This lines gives access to everybody. PLEASE ADJUST! # allow connections from local network 192.168.10.0/24 255.255.255.0 192.168.10.0
4. NIS Master Serverに必要な、ypserv, ypxfrd, yppasswdd, NIS Clientに必要なypbindをenableとrestart
sudo systemctl enable ypserv ypxfrd yppasswdd ypbind
sudo systemctl restart ypserv ypxfrd yppasswdd ypbind
5. ypinit -mを行いNISデータベースを作成
hpc@node01:~$ sudo /usr/lib/yp/ypinit -m [sudo] password for hpc: At this point, we have to construct a list of the hosts which will run NIS servers. node01 is in the list of NIS server hosts. Please continue to add the names for the other hosts, one per line. When you are done with the list, type a . next host to add: node01 next host to add: node02 next host to add: The current list of NIS servers looks like this: node01 node02 Is this correct? [y/n: y] y We need a few minutes to build the databases... Building /var/yp/hpcdiy/ypservers... Running /var/yp/Makefile... gmake[1]: Entering directory '/var/yp/hpcdiy' Updating passwd.byname... Updating passwd.byuid... Updating group.byname... Updating group.bygid... Updating hosts.byname... Updating hosts.byaddr... Updating rpc.byname... Updating rpc.bynumber... Updating services.byname... Updating services.byservicename... Updating netid.byname... Updating protocols.bynumber... Updating protocols.byname... Updating netgroup... Updating netgroup.byhost... Updating netgroup.byuser... Updating shadow.byname... gmake[1]: Leaving directory '/var/yp/hpcdiy' node01 has been set up as a NIS master server. Now you can run ypinit -s node01 on all slave server. hpc@node01:~$
6. 動作確認
ypcat passwdで動作確認
hpc@node01:~$ ypcat passwd hpc:x:1000:1000:hpc:/home/hpc:/bin/bash slurm:x:64030:64030::/nonexistent:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin hpc@node01:~$
と問題なく動作しています。
node02以降をNISのClientにする
1. NIS Clientに必要なファイル/etc/defaultdomain, /etc/yp.conf, /etc/nsswitch.confをclscpで配信する
clscp /etc/defaultdomain /etc/yp.conf /etc/nsswitch.conf /etc
2. NIS Clientに必要なサービスypbindをclsshでenableにしてrestartする
clssh 'systemctl enable ypbind;systemctl restart ypbind'
３. clssh ypcat passwdを実行して動作確認する
root@node01:~# clssh ypcat passwd
ssh node02 ypcat passwd
hpc:x:1000:1000:hpc:/home/hpc:/bin/bash
slurm:x:64030:64030::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
ssh node03 ypcat passwd
hpc:x:1000:1000:hpc:/home/hpc:/bin/bash
slurm:x:64030:64030::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
ssh node04 ypcat passwd
hpc:x:1000:1000:hpc:/home/hpc:/bin/bash
slurm:x:64030:64030::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
root@node01:~#
全ノードでNISが動作している確認ができました。
以下作成中
