ようこそ、Notes/Domino ファン & ブロガーのみなさん !


【ご注意】 このブログはビジネスに活用いただくためのものですので、以下の点を守ってご利用願います。


1. 他社あるいは他人への誹謗中傷のコメントはご遠慮ください。

2. コメントはビジネスとして問題のない言葉、表現を使ってください。

3. Webで一般公開されていない、具体的な個人や法人を特定するコメントはご遠慮ください。

4. 個人情報の記載は行わないでください。


上記を守られないコメントは、こちらの判断で削除させていただきますのでご了承願います。


尚、このサイトの掲載内容は私自身の見解であり、IBMとは全く関係はありません。

また、IBMのビジネスに利害を及ぼすために記載している訳ではありません。


ここに記載されている内容は、私自身の経験からの記載であり、内容が正確でない場合もあることをご理解の上、ご利用願います。


ご利用に際しては、左側のフレームに記載しております【注】をご一読の上、利用条件を守ってご利用ください。

1 | 2 | 3 | 4 | 5 |最初 次ページ >>
June 24, 2016

DAOS環境でのBackupからのMail復元時の注意点

テーマ:Technique
皆さんの環境でも、添付ファイルの容量削減効果があるからと、DAOS(Domino Attachment Object Store)を利用されている場合もあるのではないかと思います。

昔あったSCOS(Single Copy Object Storeでしたっけ?)も同じような仕組みです。

ファイル容量の削減に貢献し、Diskの節約が出来るのは良いことなのですが、これにより逆に運用が複雑になります。

DAOSに至っては、SCOS時代に比べTransaction Loggingを有効にしなければならないことは皆さんご存知の通りです。

DAOSやSCOSを使わない環境であれば、Backup ToolでBackupされたDBを単純にClientやTest ServerなどにRestoreして、内容を確認することができますが、DAOSやSCOSを使った環境ではそうはいきません。

運用上、良くあるのが、Mail文書を消してしまったので、Backupから元に戻して欲しいというUserの我儘です。
Soft Deletionが有効になっている環境であれば、Defaultで48時間以内であればUserでも元に戻すことが出来るのですが、そういうUserに限って何も考えずにゴミ箱を空にしてしまったりしています。
Mail DBがQuotaに達して、Mailが送信できなくなり、必死でMail DBの整理をしていたのだろうというのは良くわかりますが、作業は落ち着いてやって欲しいものです。
中には、昨日Mailの整理をしていたが、間違えてその日に来た新着Mailを消してしまったから戻して欲しいという要求もありますが、運用で取得しているBackupは夜間に1回なので、当日に当日のMailを削除したのを戻してくれと言われても無理な訳です。

少し話がそれましたが、こういうBackupからMailを戻して欲しいというUserの要望があった場合、通常の環境ならいとも簡単なのですが、DAOS/SCOS環境はそうではないのです。

SCOSは今は使われていないので、DAOS環境に絞ってお話ししましょう。

DAOS環境の場合、Mail DBとDAOSの添付ファイルのフォルダー(File System)は別で、別々にBackupされています。
Mail DBの文書内の添付ファイルは、DAOSに保管されたFileへのPointer情報を持っているだけですので、Mail DBだけをNotes Clientや別のServerにRestoreしても、Mail文書を開く際にDAOSに格納された添付ファイルが参照できないため、文書が開けない状態になるのです。
DAOSに格納されたAttachment Objectが削除されていない前提であれば、元DBのあったServerにRestoreすれば正常に文書が開けます。
DAOSからAttachment Object自体が無くなっていた場合は、もっと面倒なことになります。

では、ここではDAOSにAttachment Objectが残っていた場合(比較的簡単な場合)を考えてみましょう。

BackupからMail DBを元のDBに配置しないと、DAOSに格納されたObjectが参照できない訳ですから、本番のDBとBackupから戻したDBが同一Server上に同居することになります。

賢明な皆さんなら、直ぐに気が付くと思いますが、DominoはDBをReplica IDで同一の物と判断している関係上、同一Server上に同一Replica IDのDBが存在すると何が起こるか分からないのです。
他のServerとReplicaやCluster Replicaを行っている環境では、同じReplica IDのDBがServer上に存在すると、どちらのDBとReplicaするか分からない状態になります。
実際にやってみると分かりますが、OS CopyでServerに戻した後、DominoがそのDBを握り、Replicaを行ったことがReplication Historyから確認できるでしょう。

では、このような場合、どうすれば良いのでしょうか?

先ずは、BackupからDomino配下以外のWork領域にRestoreしたDBをNotes ClientのData領域にOS Copyして、Replication Settingを変更し、一時的にReplicaを禁止する設定を行うことです。
これで、Replicationは行えなくなります。
次に、Notes Clientも環境によってはReplicationをしている場合がありますので、この時点でDesktopのDB ICONやReplica Entryがあれば消してしまい、DB自体をNotes ClientのData Folder以外に退避することです。
そのあとで、このMail DBが元あったServerの本番のMail DBが入ったFolderとは別のFolderにOS Copyで配置します。
この時点で、load fixupでOS Copyで戻したMail DBをFixupしておくのが良いでしょう。
これでやっとServerに戻すことができ、Notes ClientからAccessして必要なMail文書をCopyして本番のMail DBにCopyした後にBackupから戻したMail DBを削除すれば作業が完了する訳です。

DAOSが有効になっていない場合と比べると、かなり煩雑な操作になることがお分かり頂けるでしょう。

更に、これはDAOSが有効な環境に限ったことではありませんが、Soft Deletionが有効になった環境で、Userさんから、数日前に文書を削除したのだが、今日ゴミ箱を空にしてしまったが、必要なMail文書があったので、戻したいという要望があった場合です。
Mail文書を削除した日が分かっていれば、Defaultではその日時から48時間はゴミ箱に残っているハズなので、Mail文書した日の夜間に取得されたBackup FileをRestoreすれば良いわけです。
ところが、文書を削除してからSoft Deletion有効期限(Defaultで48時間)以上経ったMail DBをServerに戻すと、確認するまでにゴミ箱の文書が削除されてしまう可能性が高いです。
これも困る訳ですが、もう1日前を戻せば良いという意見もあるかもしれませんが、削除したMailが削除した日に届いていた場合、ゴミ箱から復活させるしか方法はないのです。
この場合は、BackupをNotes ClientにOS Copyしてから、DB PropertyのSoft Deletionの有効期限を目いっぱい伸ばした後で処理する必要があります。
DAOSが有効な環境では、Backupを戻す先が元のServerに限られるため、DAOSが無効な環境よりも面倒なことになることは確かです。

こうやって考えていくと、Diskを節約しようとかという考えを捨てた方が賢明かも知れない訳です。
今時、Diskはかなり安価になっている訳で、運用を複雑にしてミスを招きかねない運用をすると、運用コストが上がり、人件費が一番高いという状態にもなりかねないのです。

単に目先のことだけを考えず、総合的に考えて機能を導入するかどうかを判断すべきだと思います。
 
いいね!した人  |  コメント(0)  |  リブログ(0)
June 23, 2016

膨大な容量に膨れあがるMail DBへの対処方法? -8-

テーマ:Technique
<話題の履歴>

膨大な容量に膨れあがるMail DBへの対処方法? -1-
膨大な容量に膨れあがるMail DBへの対処方法? -2-
膨大な容量に膨れあがるMail DBへの対処方法? -3-
膨大な容量に膨れあがるMail DBへの対処方法? -4-
膨大な容量に膨れあがるMail DBへの対処方法? -5-
膨大な容量に膨れあがるMail DBへの対処方法? -6-
膨大な容量に膨れあがるMail DBへの対処方法? -7-


前回は、Archive Policyの設定を行いました。

今回は、Archive Policy用に作成したGroupにMemberを設定して、Archive Policyを適用してみます。


それでは早速Archive Policyを適用するUserをArchive用のGroupに入れてみます。
Group文書を編集保存して、Policyの一覧で確認すると、Groupを変更してから1分前後でPolicyが適用されます。

Server_Side_Archive_36

Notes ClientはMail DBを開きなおすことで、即時にArchive Menuが出てきます。
iNotesは、今回は、HTTP Restartすることなく、BrowserでF5で更新すると、Archive Menuが出てきました。
Archiveを禁止した組織的Policyを配布してから、Browserで更新を行っていなかったので、HTTP Cacheではなく、読み直しを行った為と思われます。

Server_Side_Archive_37 Server_Side_Archive_38

しかし、まだArchive DBは作成されていないため、MenuからAccessしようとしても、Fileが無いErrorとなってしまいます。

それでは、Server SideでArchiveを実施します。
以前の記事で書きましたが、Compactを実施することでArchive DBが作成されます。

今回は、Archiveだけを実施するため、

 Load Compact -A mail\

を実行します。

実行結果は以下のようになり、全てのUserのArchiveをしようとしていますが、Archiveが禁止されたUserはSkipして、対象のUserだけをArchiveしていることが分かります。

> load compact -A mail\
[0A34:0004-010C] 2016/06/05 06:04:19 Archiving documents from mail\administ.nsf (Administrator)
[0A34:0004-010C] 2016/06/05 06:04:19 Archiving documents from mail\siwama.nsf(Shinya Iwama)
[0A34:0004-010C] 2016/06/05 06:04:20 Pushing mail\siwama.nsf to archive\a_siwama.nsf
[0A34:0004-010C] 2016/06/05 06:04:20 レプリケータは 1 文書を archive\a_siwama.nsf へ mail\siwama.nsf から追加しました
[0A34:0004-010C] 2016/06/05 06:04:20 Pushing mail\siwama.nsf to archive\a_siwama.nsf
[0A34:0004-010C] 2016/06/05 06:04:20 Archived mail\siwama.nsf, 1 documents were archived and 1 were deleted
[0A34:0002-0B34] 2016/06/05 06:04:21 Database compactor process shutdown

Notes Clientから確認すると、以下のように対象の文書のみArchiveされています。

Server_Side_Archive_39

iNotesから見ても、以下のようになっています。

Server_Side_Archive_40

これで、Archiveが正常に行われたことが確認できました。

次に、Groupを変更することでArchive対象のUserを変更してみます。
今回は、既にArchive対象となっていたUserをGroupから外し、新しいUserをGroupに指定します。
同様にPolicy一覧からPolicyが適用されたことを確認した上で、Clientから状態を見てみます。

Notes ClientはMail DBを開きなおすことで、Archive MenuからArchive条件が消え去ります。
iNotesは、Archive MenuにArchive条件が表示されたままの状態ですが、Archive FileにAccess出来ない状態になります。
Preferenceを再保存しても、Menuには残ったままで、HTTPをRestartしても、Preferenceを再保存しても、Menuは残った状態になっています。

Load Compact -A mail\

を発行すると、Menuから消えました。

これは不思議な現象なので、再度実験をしてみました。

【Archiveの有効化】

 1) Groupを更新してArchive無効となっているUserを有効にする
 2) Archive Policyが適用されたことをPolicy一覧で確認する
 3) iNotes BrowserでF5で更新する
   => Archive Menuは現れず
 4) iNotes Preferenceを開き、保存する
   => Archive Menuが現れる

この実験から考えると、iNotesはArchive Policyが適用されても、Preferenceを保存してPreferenceの変更を認識させないと、HTTP Cacheの内容を読むのではないかと思われます。

【Archiveの無効化】

 1) Groupを更新してArchive有効となっているUserを無効にする
 2) Archive Policyが適用されたことをPolicy一覧で確認する
 3) iNotes BrowserでF5で更新する
   => Archive Menuは残ったまま
 4) iNotes Preferenceを開き、保存する
   => Archive Menuは残ったまま
 5) Domino Server Restart
 6) iNotes BrowserでF5で更新する
   => Archive Menuは残ったまま
 7) iNotes Preferenceを開き、保存する
   => Archive Menuは残ったままの場合と消える場合がある
 8) 残ったままの場合、Server ConsoleからLoad Compact -Aを発行
   => F5でArchive Menuが消える

この実験からすると、iNotesはArchive Policyが解除されても、Preferenceを保存してPreferenceの変更を認識させないと、HTTP Cacheの内容を読むのではないかと思われますし、それ以外にも時間とかの要素がMenuが消えない場合に影響しているのかも知れません。

一般の利用では、夜中にArchiveを実行したり、夜中にArchive Policyを適用/除外するためにGroup文書を更新する処理を行うでしょうから、こういった問題は起こらないと思われますが、24時間利用されているような環境では考慮が必要かも知れません。

このiNotesでの振る舞いは別途調査したいと思いますが、Archive Policyの動きとしてはある程度利用に耐えられるのではないかと思います。


今回は、Archive Plicyの適用/除外を行い動作の検証を行いました。

次回は、もう少し、Archive PolicyのArchive条件の動きを検証してみます。

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

膨大な容量に膨れあがるMail DBへの対処方法? -7-

テーマ:Technique
<話題の履歴>

膨大な容量に膨れあがるMail DBへの対処方法? -1-
膨大な容量に膨れあがるMail DBへの対処方法? -2-
膨大な容量に膨れあがるMail DBへの対処方法? -3-
膨大な容量に膨れあがるMail DBへの対処方法? -4-
膨大な容量に膨れあがるMail DBへの対処方法? -5-
膨大な容量に膨れあがるMail DBへの対処方法? -6-


前回は、組織的Policyを使って全てのUserのArchiveを禁止しました。

今回は、一部のUserだけArchiveが出来るように設定します。


一部のUserというのは、以前の記事で書きましたが、強制的にCopy Mailを受け取るような管理職を想定しています。
例えば、e-MailのCopy MailをSystemから受け取る場合も考えられます。そういったMailの場合、System的に送っている訳ですから、Subjectなどに特徴があり、Mailを特定できる訳です。
そういう意味から、以前の記事で記述したように、Mail Tempalteを変更して、Subjectの文字判断からArchive対象として認識されるようなAgentを作成し、その文書だけを表示するViewを用意した訳です。

では、早速、設定を行っていきます。

まず、対象となるUserを定義するGroupを作成します。
Group文書はMemberに定義できるUser数が限られていますが、入れ子のGroupにすることで回避できます。
今回は評価目的なので、Group生成のLogicを考えることはしませんが、Archiveが可能なGroupを定義します。

Server_Side_Archive_24

メンバーはこの時点では与えないようにします。

次に、Archive Settings文書を作成します。
PrivateなArchiveは禁止し、Server SideでのArchiveのみ可能とします。

Server_Side_Archive_25

評価環境の単一Server環境で設定していますので、この設定では、Mail ServerにArchiveが作成されてしまいますが、複数Server環境でArchive専用の安価な構成のServerを設けることが出来れば、そのServerにArchiveを作成することも可能です。

Server_Side_Archive_26

勿論、iNotesから利用する場合は、複数ServerのSSOの設定を行っておく必要はありますが、参照する機会が少ないDBをCPUやDiskの能力の低いServerに配置することでCostを下げることが可能だと思われます。

次に、Archive条件文書を作成します。
条件式Tabを開き、「新規条件」Buttonを押して作成することができます。

Server_Side_Archive_27

条件の設定は、以下のように行います。

Server_Side_Archive_28

削除対象の文書を期間ではなく、作成したViewを対象とするように設定し、更にジャンクメールも対象にするようにしておきます。
単に条件に合致したMailだけでなく、UserがMail RuleでJunkに分類したMailもArchive対象とするためで、これにより、Userに案内すれば更に効率的にArchiveが行えると考えたからです。

この設定を保存します。
しかし、保存しただけでは、Archive条件として有効になる訳ではありません。
保存した後に戻った画面で、「条件の追加」Buttonで設定する必要があります。

Server_Side_Archive_29

作成したArchive条件を選択する画面が現れますので、必要なものを選択します。
これから分かるように、複数の条件を選択できます。

Server_Side_Archive_30

これで、以下のように条件が設定されます。

Server_Side_Archive_31

それ以外は、Archive Logなどの設定ですが、無効にしておきます。

Server_Side_Archive_32

これで、以下のようにArchive設定が完了しました。

Server_Side_Archive_33

次に、このArchive設定を適用するためのPolicyを作成します。

Server_Side_Archive_34

Policyは明示的Policyで適用するGroupを指定します。

Server_Side_Archive_35


これで準備が整いました。

今回は、Archive Policyの設定を行いました。

次回は、このPolicyを適用して評価してみます。


<続く>
いいね!した人  |  コメント(0)  |  リブログ(0)
1 | 2 | 3 | 4 | 5 |最初 次ページ >>

AD

Ameba人気のブログ

Amebaトピックス

      ランキング

      • 総合
      • 新登場
      • 急上昇
      • トレンド

      ブログをはじめる

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

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

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

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

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