DAOS tier 2 ストレージ

リッチテキストフィールドに添付したファイルは通常、データベース（ .nsf ファイル）内に保存されますが、添付されたファイルの代わりに「チケット」をデータベース内に保存し、ファイルの実体をデータベースの外（レポジトリ）へ移動して .nlo という拡張子の「オブジェクト」として保持する DAOS (Domino Attachment and Object Service)という機能があります。

リッチテキストへの添付が便利すぎるため、ユーザーはサイズの大きいファイルを文書へ添付しがちですが、DAOS （私はダオスと呼称しています）がすばらしいのは、文書にファイル添付してサーバー上のデータベースへ保存するとか、他のDominoへ複製するなどして文書を転送するときに、転送先のレポジトリに添付ファイルと一致する DAOS のオブジェクトがあれば、添付ファイルの実体を転送せず、添付ファイルをチケットに自動で置き換えて nsf へ保存します。レポジトリに無い場合は、実体をレポジトリに移動します。nsf のサイズとサーバーへ転送するサイズを節約してくれます。

転送と書きましたが言い方を変えると、メールデータベースで DAOS を有効にした場合、サイズが 30MB の動画ファイルを添付したメールを同じホームサーバーを使う1000人へ送ったとしても、サーバー上の1001人のメールデータベース内のメール文書にはチケットがあるだけで、添付ファイルの実体はレポジトリに移動した1つのオブジェクトだけです。DAOSが無効の場合と比較すると、サーバー内のストレージは 30MB x 1000 = 約 30GB が節約されることになります。なお DAOS はメール以外のデータベースでも設定することができます。


さて、2019年12月にリリースされる Domino の次期バージョン V11 には、DAOS のストレージを2層にして、レポジトリ（tier 1）にあるオブジェクトのうち、一定期間参照されないものを S3 互換ストレージ（tier 2）へ移動する、という拡張があります。

直近のイベントで目にした、この拡張のイメージ図（「V11新機能と今後のロードマップ」27ページ）では、複数の Domino サーバーのレポジトリ（tier 1）にあるオブジェクトが、S3 互換ストレージ (tier 2) へ移動するのですが、「実体の同じ」オブジェクトがすでに tier 2 に存在すれば、新たに tier 2 へ移動することなしに tier 1 のオブジェクトを削除する、という風に見えます。※そんな説明は資料にはありません

Domino内の複数のDBから参照される同一の添付ファイルが、Domino内の tier 1 で1つのオブジェクトで管理され、さらに複数のサーバーにある同一の添付ファイルが tier 2 で1つのオブジェクトで管理されるようなのです。

ところで、レポジトリにあるオブジェクトは拡張子が nlo のファイルですが、デフォルトでは元サーバーの鍵で暗号化されます。暗号化された nlo は、他のDominoサーバーのレポジトリに作成されたオブジェクトを持ってきても使えないようになっています。

暗号化された nlo をそのまま tier 2 へ移動したのでは、他の Domino からオブジェクトを参照できても内容を読むことができないのではないでしょうか。

tier 1 に作成されるオブジェクトで暗号化を無効にすることは現行バージョンでも可能です。notes.ini に DAOS_ENCRYPT_NLO=0 を追加しておきます。

Domino V11 ベータ2 の What's New には、tier 2 を設定するにあたり暗号化を無効にしなければならないとは書いていません。複数の Domino で tier 2 を共有する場合の設定にも触れていますが、オブジェクトの暗号化については触れていませんでした。
また、暗号化されたオブジェクトを tier 2 へ移動する際、自動で復号化される、といった細かい話にも触れていません。

もし、現状 DAOS を複数の Domino で使っていて暗号化をデフォルトのまま有効にしている場合、同一ファイルから生成された nlo でも tier 2 上では Domino の数の nlo が作成されるかもしれないのです。これでは少々つまらないですよね。

そんなことを考えながら、ノーツコンソーシアム「ザ・ノーツ研究会」11月度の活動の中で検証してみようと取り組んでみましたが、敢え無く時間切れとなってしまいました...うーん、気になる！

このノーツ研究会で検証する前に V11 ベータ2 が公開され、その What's New を読んでいたとき DAOS tier 2 のことが記載されたのを見つけた(ベータ1には記載が無かった)ので、個人で aws のアカウントを作り、無料枠内で S3 を使って DAOS tier 2 を試してみました。

以下に V11 ベータ2 での印象とか、ベータフォーラムで聞いて分かったこと、What's New に書いていないことなどを、つらつらと書き残しておこうと思います。

あ、tier 2 の有効化やその設定方法は小野様のブログが詳しいです。

S3 にはいくつもの「リージョン」があります。ベータ2の What's New に書かれているリージョンは「米国東部（バージニア北部）」のものでしたが、テスト当初は米国内の違うリージョンにバケットを作成したものの Domino からの接続がうまくいかず（サーバー文書で設定する URL などの設定に問題があった可能性はありますが）結局は米国東部のリージョンにバケットを作成して接続できました。そのせいか、私の環境からだとパフォーマンスは恐ろしく悪く、tier 1 にあった約 1GB のオブジェクトをpushできない理由がわからないときに非常に難儀しました。テストするなら小さい添付ファイルから始めることをお勧めします。

DAOS tier2 に関連した統計情報や notes.ini に追加されるいくつかのパラメータには COS という単語が登場します。これは Cloud Object Storage を省略したものかと思います。

ベータでサポートするストレージは aws S3 と MinIO の２つでした。MinIO はオンプレミスに構築できる S3 互換ストレージのようで、Docker で使えるみたいです。
ひょっとすると aws s3 互換 を謳っているサービスなら使えるのかしら...と思ってグーグル先生に「aws s3 互換」と聞くと、MinIO 以外にもたくさんヒットしました。これらが tier 2 として使えるかどうかは不明です。

tier 1 から tier 2 へ push（移動）するにあたり、ファイルが最後に参照されてからの経過日数を基準としています。これはコンソールコマンド tell daosmgr objectinfo all を投入して出力される objectinfo.txt にある AGE の数値と比較しているように思います。

tier 2 の設定を行い、それが有効になると、show tasks コマンド投入で「DAOS Manager   S3Push: Idol」が出力されます。push している最中は Idol が Processing に変わりましたが、ここではオブジェクト（.nloのファイル）の名前はわかりません。
push しているオブジェクト名とサイズを知りたい場合、notes.ini へ DEBUG_COS_PROVIDER=2 をセットしておくと、show tasks ではありませんが、tier 2 への push する時にコンソール上に出力されていました。なお、このデバッグパラメータを追加すると、プログラムディレクトリ内に aws_sdk_yyyy-mm-dd-hh.log といったログが1時間おきに作成されます。

tier 2 への push は午前2時に実行されました。この時刻を変更できるかどうかは不明です。手動で tell daosmgr objectpush 0 をコンソールへ投入すれば、午前2時を待たずにすぐさま tier 2 へ push されます。このコマンドの最後にあるゼロは参照されなくなってからの日数を指しますので、ゼロを指定すると tier 1 にあるすべての nlo が push されます。サーバー文書の DAOS タブで、参照されなくなったオブジェクトを tier 2 へ移動するまでの日数を指定します（デフォルトは1000日）が、午前2時に tier 2 へ push する場合、この値をテストだからと 1 にしても数日待っても移動しませんでした。聞けばこれはバグで7日経過しないと Push されないとのことでした。製品版では修正されていることでしょう。

サイズが大きなオブジェクトの push に時間がかかり、渋滞するのではないかと心配な場合、push スレッドを多重化しておくことができる、と教えてもらいました。notes.ini へ DAOS_S3_PUSH_THREADS=n （nはスレッドの数）を追加します。

tier 2 への push が失敗する場合、notes.ini へ DEBUG_DAOSMGR_TRACE=1 を設定すると、少なくともエラーがわかると教えてもらったのですが、エラーが出なかったこともあり未確認です。

tier 2 へ push されたオブジェクトは、対応する添付を Notes から参照すると tier 1 へ落ちてくるのかと思いきやそうではなく、data ディレクトリ配下に objectStoreTemp という名前のフォルダが作成され TMP1.tmp といったファイルが作成されました。これが tier 2 からダウンロードされたオブジェクトで、クライアントから参照された実体なのだと思います。

最後に、ベータ2 では tier 2 へ push された後、tier 1 には .nlo という拡張子が .nlx に変わっただけのように見えるオブジェクトが存在しました。ベータではフォールバックのために .nlx として残していますが、製品版では削除される、とのことでした。


Domino V11 のリリースはもうすぐです。
Domino 上で動く LEAP やまだ見ぬ軽量クライアントは少々遅れてのリリースとなるようですが、それらを含めて V11 の登場が待ち遠しいです。