ページビューの合計

ラベル クラスター の投稿を表示しています。 すべての投稿を表示
ラベル クラスター の投稿を表示しています。 すべての投稿を表示

2025年6月24日火曜日

#Domino #REST #API ( #DRAPI ) ・・・での凡ミス💦~私の備忘録として~

Hello everyone.

Thank you very much for your support last week at #DominoHub 2025 Tokyo.

We would like to thank you again for your participation and watching our event, despite the fact that we were a group of amateurs in organizing the event.

I would like to take this opportunity to write about a trivial mistake I made, as a reminder not to repeat it in the future.


みなさま、こんにちは。
先週は #DominoHub 2025 東京にてたいへんお世話になり、ありがとうございました。
イベント開催については素人の集団での開催にもかかわらず、たくさんの皆様にご参加・ご視聴頂けましたこと、重ねてお礼申し上げます。

また19日のオンラインセッション時にはイベントポータルがダウンしてしまい、たいへんなご迷惑をお掛けしてしまいましたことを深くお詫び申し上げます。

当日の様子は浜さんのブログにも公開されておりますが、今後も出てくるかと思いますので、もうしばらくお待ちください。


さて今回はDomino REST API (DRAPI)について、超凡ミスでまたまたサポートの方に無駄なお仕事をお願いしてしまいました。
二度と同じことを起こさないため、自分への備忘録も兼ねて記事として残しておきます。


早速ですが、まずは発端です。
既存本番環境で使用しているアプリを DRAPI に追加して、外部連携をさせたいとの目的から、そのアプリを DRAPI に追加するという作業の中で発生しました。

具体的には、DRAPIにログインし、Configurationを開きます。


開きましたら、続いてDatabase Management -REST API を開きます。


開きましたら、右上の[+ Add Schema]をクリックしてスキーマの作成を進めます。
※DRAPIの概要についてはここでは触れません。
HCL様サイトで3回に分けて公開されておりますので、そちらをご参照ください。


今回は新規でスキーマを作りますので、[Create Schema]をクリックします。


以下の画面が表示されますので、一覧から対象のアプリを選択します。


しかしながら今回追加したいアプリがリストされておりません。
手入力で指定してもアプリが存在しないと怒られてしまいます。

確かにこの時点が何か簡単なミスをしているような気はしました。
もちろんHCL様サポートポータルで検索してみたのですが、それらしき記事が見つかりませんでした。

ということで、今回もサポートの方を頼ったのです。


はじめはブラウザのキャッシュクリアの指定を頂きました。
確かにそれまで実施していませんでしたので、早速実行

・・・変化なし

念のためDominoサーバーをマシンごと再起動

・・・変化なし

致し方なくサポートの方へ状況報告しました。

夕方遅い時間にも関わらず、すぐに次のステップの案内が届きました。
記載されている内容には以下の記載がございました。

[Add Schema] ボタンを押して [Create Schema] を選択して、[Database] のリストには、通常は Data ディレクトリの全てのデータベースがリストされています。
念のため load catalog コマンドを実行して、データベースカタログの更新を行ってみてください。

この内容を読んで、「はっ」としました。


結論を書く前にまずは弊社の環境について少し触れておきます。
現時点で社員数は130名ほどになりますので、従来から全く問題なく1サーバーですべてを賄っておりました。
しかしながら年々Dominoの重要性が増してきていることから、先般クラスター環境を作って頂きました。
あまり複雑なことが発生することは避けたかったため、基本は本番サーバー1台で運用し、障害発生時のみクラスターサーバーに切り替わる、いわゆる Active/Standby の構成になります。

そこにDRAPIを追加したのですが、本番DominoではLeapなども動いており、念のため負荷の少ないクラスターサーバーへインストールを実施しました。

以下のような構成になります。


さてここまで書きましたら、既に気付かれた方もいらっしゃるのではないでしょうか。

ということで原因・・・凡ミス・・・です。

はい。
DRAPIに追加したいアプリは本番Dominoにのみ存在し、クラスターには存在しておりませんでした。

つまりDRAPIが参照するはずのクラスターDominoサーバーのカタログにはリストされておらず、もちろんそのためにDRAPIのリストにも表示されないというオチでした💦

対象のアプリを本番Dominoからクラスターへ複製し、再度ブラウザのキャッシュをクリアしたところ・・・無事表示され、DRAPIのスキーマ追加が完了しました。

サポートの皆様、毎回ほんとうに申し訳ございません。
特に最近はVoltMX GoとDRAPIで私の勘違いなども含めてお手を煩わせてしまっており、申し訳ない限りです。
が・・・何卒引き続きよろしくお願い致します。


ということで目的のアプリはDRAPIに追加できましたので、これより細かな設定(連携するビューやフォーム、フィールド)を進めて参ります。

このあたりはまたどこかの機会に発表させて頂ければと考えております。


ということで、今回は私自身の反省の意味を込めた記事にて失礼致します。




2023年9月27日水曜日

Dominoサーバーを #クラスター 化する場合の注意事項

 I would like to explain a new addition we have made to our company about problems related to cluster servers and how to deal with them.

I consider it quite important, so please read it.


みなさま、こんにちは。
・・・少し時間が空いてしまいましたね。
とは言いつつ、今回もまずは告知からです。

僭越ながらも、弊社にて検証しました事例もご紹介させて頂きます。
終了後にはお楽しみ満載のパーティータイムもご準備頂けているようですので、ぜひ現地でお会いしましょう!!


さて今回は、以前からサブスクはサーバー立て放題だから、「やるやる!」と言っていたクラスター化を実装致しました。
その中で、弊社で発生したトラブルについて報告致します。

まずクラスターサーバーの作成について、ここでは触れませんので、ご了承ください。


【エラー発生までの流れ】

クラスターサーバーへ全メールデータベース(退職者含め130ほど)の複製を作成しました。
※弊社のメールボックス制限はひとり10GBです。

翌日、一部ユーザーから受信ボックスが空っぽとの報告がありました。
調べると、メールそのものは受信しているのですが、受信ボックスに配信されない(すべての文書には入る)状況となっていました。

なおすべての文書ビューでは、[フォルダ]が表示されているのですが、本来「受信ボックス」となるべき文書がブランクになっていることを確認しました。

なおこの現象は発生している者としていない者がいることも確認されました。

以上から、こちらでの解決は困難と判断し、サポートへ問い合わせしました。


【発生した現象】
いつもながら即日回答がありました。
結論としては、既にケースとしてリリースされている内容に該当していました。

Domino Administrator の「レプリカの作成」機能を使用した場合に発生する可能性のある問題

要はレプリカスタブが実際の複製処理を実施している間に、サーバーメンテナンスのひとつである「designタスク」が実行されてしまうと、設計反映の処理が重複してしまい、トラブルの原因となるそうです。

確かに発生しているユーザーとしていないユーザーがいる点からも、納得です。


【本来実施すべき準備】

まずは今回の復旧作業でなく、このような状態に陥らないための下準備について記載致します。
手順としては、複製の初期化が終了するまでは一時的に Design の定期実行を停止するということになります。
具体的には、

notes.ini のパラメータ ServerTasksAT1= で Design タスクが指定されているため、一時的にこの記述を削除する

となります。
もし今後、クラスターサーバーを追加されるような場合は、ご注意ください。


【復旧作業①】

それでは実際に弊社のような状況に陥った場合の対処方法です。

①念のため、対象のメールボックス(nsf)をバックアップする

②そのメールボックスをDesignerで開き、[フォルダ]内[$Inbox]を削除する


③Dominoコンソールで、対象メールボックスにconvertコマンドを実行する。
 ※テンプレートのファイル名は実際に利用しているものを指定します。

load convert mail\ABC.nsf * djxmail12.ntf

ケース文書では、以上で復旧するようです。(例外として、以下記述はあります)
※この対応で復旧できるのは、convert を実施した日から 90 日前までに受信したメッセージのみであることに注意してください。90 日よりも過去に受信したメッセージを受信ボックスに表示させる手段は存在しないため、バックアップからリストアするか、すべての文書ビューから必要なメッセージを受信ボックスにコピーする必要があります。

しかしながら、弊社の現象では、複製作成前のメールはこの時点で受信ボックスには表示されませんでした。


【復旧作業②】

再度サポートに問い合わせたところ、

データベースのトラブルシューティングと問題解決のための管理ツール(Admin Tool)
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0080492

というものを紹介して頂けました。
ツールの機能はいろいろとあるようですので、先のリンクをご確認ください。
ちなみに画面は以下のようなものになります。


こちらを使って、メールデータベースの復旧を試してみます。

作業は至って簡単で、

①[Darabase Health]-[Rebuild Mail Database Inbox]を選択


②以下のような画面が表示されますので、[Select]をクリックして、対象のメールデータベースを選択します。


③[Rebuild]をクリックして、あとは待つのみになります。


完了したら、メッセージが表示されますので、OKします。
ちなみにRebuildの時間は対象のメールデータベースの容量に比例するようで、個人的なイメージとしては、結構かかったと感じました。

結果として、本ツールを利用することで、障害は解消することができました。
※本ツールはもっと精査しても面白そうですね。


以上で今回のレポートと致します。

以下参考情報として、作業中でひっかかった内容のケースを追記しておきますので、こちらもご参照ください!!



【参考資料】

※1 システム管理要求「レプリカ作成の実行」による高速レプリカが実行される条件

https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0037843

※2 「再始動可能な圧縮には、db 及び ODS が 55 以上のトランザクションログが必要です。」のメッセージが出力される
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0105755

→「情報のメッセージになりますので、該当のメッセージが出力されていても、特に問題はありません。」・・・だそうすです。