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

3.その他 - 2.その他

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

OnTimeがサポートするフェールオーバークラスターは３層で分かれています。

それぞれOnTime環境を構成する重要なパート毎に構築手法がかわります。

以下の各3要素はそれぞれ目的も機能も違ってきます。

目的を明確にすることでそれぞれをご検討及び構成して下さい。

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

HTTPの負荷分散装置等を導入して負荷分散、フェールオーバークラスタを構成して下さい。

その際、ServerSetting文書のREST用のClientDBのURLには負荷分散装置のURLかアドレスを指定して下さい。

制御も負荷分散装置で行います。

OnTimeはDominoのセッション認証ではなく独自のTokenを利用した認証を毎回のREST接続時に行っています。

なのでいずれのOnTimeサーバーにRESTで接続しても問題なくResponseを返します。

フロントに負荷分散装置などを配備しない場合は、URLのホスト名を指定しなおすか、ワークスペースからアクティブなサーバーのOnTimeクライアントDBを開きなおして下さい。

後述するOnTimeタスクの構築を併用しない場合はWebOnlyServerを構築することも可能です。

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

OnTimeタスクのフェールオーバーはOnTime独自の機能となります。OnTimeタスクはServerSetting文書で指定したOnTimeクラスタメンバー間で独自の死活監視をしています。

OnTimeタスクだけがダウンしたがDominoサーバーは正常な場合でもOnTimeタスクが稼働しているDominoサーバーが機能不全の場合でも、アクティブなクラスターメンバーが代理でダウンしたOnTimeタスク分もSync処理を司ります。通常この処理は10秒以内に行われます。また機能不全のサーバーが復活した場合も自動的に元に戻ります。

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

OnTimeはUser文書にメールDBのクラスターパスを保持しています。何かしらの原因でメールDBにアクセスできなくなった場合、数回のトライアルの後フェールオーバー先に切り替わります。

OnTimeがメールDBからの情報取得及び予定の書き込みなどはアクティブなホームサーバーのメールDBとなります。よってOnTimeが利用するメールDBのフェールオーバーの技術はDominoクラスターに依存しています。

DominoでメールDBの正常なフェールオーバーが行われてない場合はOnTimeも影響を受けます。ご注意下さい。

複数のOnTimeサーバーを利用する際の構成サンプルを幾つかご紹介します。

複数のOnTimeサーバーと複数のメールサーバーを構成する際のパターンは様々な要因に依存します。

しかしご質問も多く、以下に考え方としてシンプルなパターンを例としてご案内します。

ちなみにユーザーからの接続はいずれのサーバーへの場合でも読み出しはそれぞれローカルのOnTimeデータを使用しますし、メールDBへの書き込みはDominoクラスターの指示に依存します。

更にサーバー設置拠点が複数に分散する場合など更にネットワーク構成も考慮する必要があります。その際は Domino構築パートナー及びOnTimeご購入先のパートナーとご相談下さい。

１．メールサーバーとOnTimeを同じサーバーに共存させる場合の指針

複数台のOnTimeサーバーを構築する理由が最低限の冗長性ならば下図の様な構成が適切でしょう。

コンパクトなパッケージングとネットワークトラフィックの軽減を主目標として下さい。

その場合ローカルのメールDBは自身で動作するOnTimeタスクが面倒を見るよう構成して下さい。

２．メールサーバーとOnTimeが独立したサーバーで運用させる場合の指針その１

複数台のOnTimeサーバーを構築する理由が平常時の負荷分散も考慮するなら下図が適切でしょう。

それぞれが出来るだけ独立して運用出来る事を負荷分散のための主目標として下さい。

クラスターを組むメールサーバー群はそれぞれ同じOnTimeサーバーに接続するように構成して下さい。

３．メールサーバーとOnTimeが独立したサーバーで運用させる場合の指針その２

複数のOnTimeサーバーを構築する理由が有事の際のフォールトトレラントなら下図が適切でしょう。

主系のOnTimeだけで通常機能が効率よく動作することを主目標として下さい。

全てのメールサーバーを主系のOnTimeサーバーに接続するように構成して下さい。

ドキュメント内無題 (ページ 49-52)