複数のOnTimeサーバーを構成する際の考慮点

実際の手順については→「1台のOnTimeサーバー環境に2台目のOnTimeサーバーを追加する簡易手順書」を参照してください。

A. OnTimeがサポートするフェールオーバーについて

OnTimeがサポートするフェールオーバークラスターは３要素に分かれています。
OnTime環境を構成する重要な各３要素は目的も機能もそれぞれ違います。
目的を明確にすることでそれぞれをご検討及び構成して下さい。

１．OnTimeクライアント及びREST API向けフェールオーバー

HTTPの負荷分散装置等を導入して負荷分散、フェールオーバークラスタを構成して下さい。制御も負荷分散装置で行います。
OnTimeは毎回のREST接続時にDominoのセッション認証ではなく独自のTokenを利用した認証を行っています。なのでランダムにいずれのOnTimeサーバーにREST接続されたとしても問題なくResponseを返します。
負荷分散装置などを設置する場合、ConfigDBのServerSetting文書にあるClientDBのREST接続用URLには負荷分散装置のURLかアドレスを指定して下さい。
フロントに負荷分散装置などを配備しない場合は、URLのホスト名を指定しなおすか、ワークスペースからアクティブなサーバーのOnTimeクライアントDBを開きなおして下さい。
ConfigDB及びOnTimeタスクの構築を併用しない場合はWebOnlyServer(External Server)を構築することも可能です。

２．ConfigDB及びOnTimeタスクのフェールオーバー

OnTimeタスクのフェールオーバーはDominoクラスターとはまったく別のOnTime独自の機能となります。ServerSetting文書のOnTimeクラスターの項目でクラスター名を自由に指定出来ます。タスクの再起動後からOnTimeタスクはOnTimeクラスターメンバー間で独自の死活監視を継続的に行います。
OnTimeタスクだけがダウンした場合でも、OnTimeタスクが稼働するDominoサーバーがダウンした場合でも、同じクラスター内のアクティブメンバーがダウンしたOnTimeタスク分も代理でSync処理を行います。通常この切替えはダウン後約10秒以内に行われます。またダウンしたOnTimeタスクが復旧した場合も自動的に元に戻ります。

３．メールDBのフェールオーバー

OnTimeが利用するメールDBのフェールオーバーの技術はDominoクラスターに依存しています。DominoでメールDBの正常なフェールオーバーが行われてない場合はOnTimeも影響を受けます。OnTimeはConfigDBのUserSetting文書にメールDBのクラスターパスを保持します。何かしらの原因でメールDBにアクセスできなくなった場合、数回のトライアルの後フェールオーバー先に切り替わります。
平常時のOnTimeが行うメールDBからの情報取得及び予定の書き込み先は常にホームサーバーのメールDBとなります。

B. 複数のOnTimeサーバーを利用する際の構成サンプル

複数のOnTimeサーバーを利用する際の構成サンプルを幾つかご紹介します。
複数のOnTimeサーバーと複数のメールサーバーを構成する際のパターンは様々な要因に依存します。
しかしご質問も多く、以下に考え方としてシンプルなパターンを例としてご案内します。
ちなみにOnTimeクライアントからのデータ要求は必ず接続設定されたConfigDBから読み出され、メールDBへの予定書き込みはDominoクラスターの指示に依存しホームサーバーのメールDBとなります。
更にディザスター対策などでサーバー設置拠点が複数に分散する場合などではネットワーク構成も考慮する必要があります。その際はDomino構築パートナー及びOnTimeご購入先のパートナーとご相談下さい。