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などに変化があるのかを見てみます。

<続く>
いいね!した人  |  コメント(0)  |  リブログ(0)

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

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

最近の画像つき記事
 もっと見る >>

コメント

[コメントをする]

コメント投稿

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。