目的
Webブラウザからクラスタの計算資源を利用できるオープンソースソフトウェアOpen OnDemandは、日本国内でも普及しつつあります。2025年9月現在、インターネットで調べた範囲において、Open OnDemandを採用している日本の研究機関や大学のスパコンセンターは下図の通りです（インターネットには出ていないものの、著者が直接見聞きした導入事例もいくつかありますが、それらは下図には含まれていません）。
これまでのクラスタの利用はPuTTYなどによるSSH接続が一般的でしたが、コマンドラインの利用からWebブラウザを介したGUIの利用へと移行しつつあります。そして、その標準的なインタフェースとしてOpen OnDemandが定着していく可能性が高いと考えられます。
Open OnDemandを安定的に運用するためには、複数台のサーバを用いた冗長化が不可欠となります。そこで、本記事では、著者が所属する組織で実際に行ったOpen OnDemandの冗長化構成と設定方法について紹介します。
概要
本記事では、以下のFQDNを例として説明します。
- ロードバランサ:
ood.example.net - Open OnDemandサーバ:
ood1.example.net,ood2.example.net
ユーザがWebブラウザを使ってood.example.netにアクセスすると、ロードバランサによって ood1.example.netまたはood2.example.netへ振り分けられます。また、メンテナンス目的などで任意のOpen OnDemandサーバに直接アクセスできるように、例えばood1.example.netをWebブラウザのURL欄に指定すればロードバランサを経由せずにサーバへ接続可能としています。
ネットワークの構成
最初に考えたネットワーク構成は下図の通りでした（図では省略していますがロードバランサ自体も冗長化されています）。認証サーバであるIdP（Identity Provider）にはKeycloakを使っています。
Open OnDemandサーバは100G Ethernetと10G EthernetのNICを搭載しています。一方、利用しているロードバランサ（F5 Networks社のBIG-IP）は10G Ethernetポートのみの搭載です。この構成の問題点は、ロードバランサを経由しないとOpen OnDemandサーバは外部と通信できないため、サーバの100G Ethernet NICが活用できない点でした。
そのため、次のように100G Ethernetを外部ネットワークに接続する構成へと変更しました。
Open OnDemandサーバのroute設定において、ロードバランサへの通信は10G Ethernet NICを経由して、それ以外への通信は100G Ethernet NICを用いるように設定しました。具体的には、初回アクセスのみ10G経路でセッションを確立し、その後の通信は100G経路を利用するようにしました。
設定
ロードバランサ（F5 Networks社のBIG-IP）
- Virtual Server：
ood.example.netのグローバルIPアドレスを割り当て - Load Balancing Method：Least Connections（セッション数が少ないサーバを選択）を設定
- クライアントとサーバ間のセッション継続中は同一サーバへ誘導するため、スティッキーセッションを有効化
- Health Monitor：各Open OnDemandサーバに対して30秒おきに443/tcpへの応答確認
IdP（Keycloak）
ロードバランサおよび各Open OnDemandサーバからのアクセスを許可する設定を行いました。
SSL/TLS証明書
証明書管理を集約するため、ロードバランサと各Open OnDemandサーバで同一の証明書を利用できるマルチドメイン証明書（ood.example.net、ood1.example.net、ood2.example.net）を作成しました。
Open OnDemand
本記事で用いたOpen OnDemandのバージョンは4.0.7、OSはRedHat Linux 8.10です。
OpenID Connect認証設定ファイル/etc/httpd/conf.d/auth_openidc.confを以下のように設定します。
OIDCRedirectURI /oidc
Open OnDemandの設定ファイル/etc/ood/config/ood_portal.ymlを以下のように編集します（下図はood1.example.netの例）。servernameにはロードバランサのFQDN、server_aliasesには自身のFQDNを記載します。
servername: 'ood.example.net'
server_aliases:
- 'ood1.example.net'
設定反映は以下のコマンドで行います。
$ sudo /opt/ood/ood-portal-generator/sbin/update_ood_portal
なお、Open OnDemand 4.1以降では/etc/ood/config/ood_portal.ymlにoidc_redirect_uriの設定項目が追加されるため、/etc/httpd/conf.d/auth_openidc.confを直接編集する必要はなくなる予定です1。
さらに、ood.example.netにアクセスした際に、実際にどのOpen OnDemandサーバへ接続されているのかを確認できるようにするため、Open OnDemandのダッシュボードのフッターにホスト名を表示する設定を追加しました。具体的には、設定ファイル/var/www/ood/apps/sys/dashboard/app/views/layouts/_footer.html.erbを以下のように編集しました。
# 変更前
<span>OnDemand version: <%= Configuration.ood_version %></span>
# 変更後
<span>OnDemand version: <%= Configuration.ood_version %> (<%= `hostname`.strip %>)</span>
実際の運用について
各Open OnDemandサーバのスペックは下記の通りです。
| ood1.example.net | ood2.example.net | |
|---|---|---|
| CPU | Intel Xeon Gold 6338 (32 cores) | Intel Xeon Gold 6526Y (16 cores) |
| Memory | DDR4-3200 256 GB | DDR5-5200 256 GB |
冗長化以前はロードバランサを用いずにood1.example.netのみで運用していました。同時利用ユーザ数は通常20程度、講習会時で60〜100程度ですが、100人規模であっても単一サーバで十分処理可能でした。
そこで、負荷分散構成を準備しつつ、当面はロードバランサでood1.example.netのみを利用し、ood2.example.netはホットスタンバイとして運用する方針としています。ood1.example.net障害時やメンテナンス時に切り替え、さらに将来ユーザ数が増加し性能低下が見られた際には負荷分散を有効化する計画です。その場合、各サーバのスペックが少し異なるので、ロードバランサのLoad Balancing Methodを変更する必要があるかもしれません。