iNotesのArchive Policyの仕組みを解明したい! -1- | IBM Lotus Notes/Domino (R) をこよなく愛して。。。。
June 30, 2016

iNotesのArchive Policyの仕組みを解明したい! -1-

テーマ:Test Lab.
Archive Policyを使って、膨れ上がるMail DBをArchiveする方法の記事を書いていたのですが、iNotesだけ少し変わった振る舞いをしているようなので、このシリーズでは徹底的にTestしたいと思います。

まず、Testするにあたって、Test Senarioを考えてみます。

1) Policyを適用するGroupを変更した際の動作
  => Group変更で個人にPolicyが適用されるまでに何が行われるか?
2) Policyが適用された時点のProfile文書の状態
  => iNotes Profileなど何が変更されるか?
3) iNotes Preferneceを手動で更新した際の動作
  => 何が更新されて、Archiveが有効/無効となるのか?

これが分かれば、Policyの適用対象のGroupをLotusScriptのAgentから変更した際に、即時にUserに反映する方法が見えてくるのではないかと思います。

まず最初に、

1) Policyを適用するGroupを変更した際の動作

について試してみます。

これまで、Policyを適用するGroupを更新して、実際にPolicy一覧でPolicyのAssignが確認できるまでタイムラグがあることが確認できています。
しかし、このタイムラグは非常に短い時間ですので、試すのが難しいかも知れません。

Dominoはnames.nsfに設定された様々なな情報をCacheするように出来ています。
User情報などはName Lookup Cache(NLCACHE)にCacheされて、Address参照時など、names.nsfを参照することなく、NLCACHEを参照してAddress解決を行ったりしています。
このNLCACHEが影響して、Mailの配信がうまく行かない場合には、Server Consoleから"show nlcache reset"を発行するようにIBM Technical Supportから案内され、実行されたことがある人も多いのではないかと思います。
このCommandにより、Name Lookup Cacheの内容はResetされて、新規にName Lookup Cacheが作成されます。
Groupの情報に関しても、Group Cacheを持っていて、この情報を参照しながら、Groupに関する処理を行っているのですが、残念ながら、Name Lookup Cache(NLCACHE)のようにServer CommandでResetする方法が提供されていません。
IBMによると、Group Cacheの更新は、Groupの更新を1分間隔でMonitorしていて、更新を検知するとGroup Cacheの更新を行うようです。
このMonitorは($ServerAccess) Viewの更新タイミングとなっていて、このViewが更新されると、Group Cacheの更新を行います。
Dominoとしては、Directory Indexer Task(通常のUpdate Taskとは別に動作するDomino Directory専用のUpdate Task)によって処理されていると思いますが、Directory情報の更新が激しい環境では1分という時間が守られていないかも知れません。

(参考)You changed group membership, now when will dynamic policies reflect that?

When you add/remove a member of a group, the Indexer thread will update the internal directory view which is then used to update the group cache. The Indexer thread will run every minute by default or you can specify the server INI variable UPDATE_NAB_SUPPRESSION_TIME with a value in minutes. Once the group cache is updated, dynamic policies will now correctly reflect a users group membership.

Policyを適用するGroupを更新して、Policy一覧を直ぐに書き出して、適用Policyが変更されていない状態で、load updall names.nsf -t "($ServerAccess)"を発行すると、即時にPolicyが適用された状態になることが分かります。

つまり、Groupを使った明示的Policyは、Group Cacheの更新が行われると、直ぐに適用されるということだと思われます。

手作業でやっていたのでは、時間などがかかり、確実なTestにはならないと思いますので、LotusScriptのProgramから行って確認出来るか考えてみます。

実行すべきことは、

1) 明示的Policy適用対象のGroup文書を更新する
2) Server Command(load updall names.nsf -t "($ServerAccess)")を発行する
3) UserへのPolicyの適用状態を確認する

ということです。

1)は通常のLotusScriptで可能ですし、2)もLotusScriptからServer Console Commandを発行することで可能です。
3)はPolicy Synopsisしか無いのでしょうか?
これだとUIからの実施になり、1分以内に確認することができませんので、逆にUPDATE_NAB_SUPPRESSION_TIMEを使って、更新間隔を伸ばして確認した方が良さそうです。
これであれば、手作業での確認も可能です。

まず、Domino Consoleから以下を発行して、Update間隔を5分に伸ばします。

> set config UPDATE_NAB_SUPPRESSION_TIME=5
> show config Update*
[0D04:0009-0B90] UPDATE_NAB_SUPPRESSION_TIME=5

この後、Groupを編集して、Memberを入れ替えます。
入れ替えた後に、Policy一覧でPolicyの状態を確認してから、Server Consoleから
以下のCommandを発行します。

> load updall names.nsf -t "($ServerAccess)"
[05B4:0002-0ACC] 2016/06/11 07:17:56 Index update process started: names.nsf -t ($ServerAccess)
[05B4:0002-0ACC] 2016/06/11 07:17:56 Updating C:\IBM\Domino\data\names.nsf view '($ServerAccess)'
[05B4:0002-0ACC] 2016/06/11 07:17:56 Index update process shutdown

この後に、Policy一覧でPolicyの状態を確認すると、適用状態が変更されていることが分かります。

つまり、(参考)で紹介した英文のFAQにも書かれているように、Groupを使ったDynamic PolicyはGroup Cacheが変更された時点で有効になり、Group Cacheは1分ごとにUpdateされるということです。

今回は、Groupを使ったPolicyがGroupのMemberに適用されるまでの動作を見てみました。

次回は、Policyが適用される前後で、iNotes Profileなどに変化があるのかを見てみます。

<続く>

いわまんさんの読者になろう

ブログの更新情報が受け取れて、アクセスが簡単になります

コメント

[コメントする]

Ameba人気のブログ

Amebaトピックス