複数の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ご購入先のパートナーとご相談下さい。
１．OnTimeをメールと同じサーバーに共存させる場合の指針
複数台のOnTimeサーバーを構築する理由が必要最低限の冗長性ならば下図の様な構成が適切でしょう。
コンパクトなパッケージングとネットワークトラフィックの軽減を主目標として下さい。
ローカルのメールDBは同じサーバーで動作するOnTimeタスクがSync処理するよう構成して下さい。
２．OnTimeをメールと独立したサーバーで運用させる場合の指針その１
複数台のOnTimeサーバーを構築する理由が平常時の負荷分散も考慮するなら下図が適切でしょう。
それぞれのOnTimeサーバーが出来るだけ独立して動作する事を主目標として下さい。
Dominoクラスターを組むメールサーバー群はそれぞれ同じOnTimeサーバーがSync処理するように構成して下さい。
３．OnTimeをメールと独立したサーバーで運用させる場合の指針その２
複数のOnTimeサーバーを構築する理由が有事の際のフォールトトレラント等なら下図が適切でしょう。
通常は主系のOnTimeサーバーだけで効率よく動作することを主目標として下さい。
全てのメールサーバーを主系のOnTimeサーバーに接続するように構成して下さい。
