ドミノクラスタのさらなる活用を目指して、Domino V10 の新機能だったシンメトリッククラスタについて概要を調べました。これはその情報収集した結果をまとめたレポートでです。検証に基づくレポートではありませんので、予めご了承ください。
機能概要
シンメトリッククラスタの機能概要は以下の通りでした。
1. 同じ状態に維持とは？
Administrator ヘルプによるとシンメトリッククラスタは『データベースがクラスタ内のサーバー全体で同じ状態に維持されるようになります』とあります。
この同じ状態にする機能とは次の２つでした。
- データベースの欠落状態の修正
- 破損状態の修復
シンメトリッククラスタは、上記２点を修復することを目的にした機能です。
2. データベースの欠落状態の修正
では、データベースの欠落とはどのような状態でしょうか？
言葉通り、クラスタメンバーの片方にデータベースが存在し、他のメンバーサーバには存在しないことを言います。ポイントは、データベース単位での判断であることです。例えば、何らかの理由で、文書や設計などデータベース内のデータに欠落があったとしても、シンメトリッククラスタでは検知しません。
欠落を発見した場合、シンメトリッククラスタが他のクラスタメンバーのサーバから自動でデータベースを複製してくれます。
このような機能ですので、アプリやメール DB の作成し忘れをなくすことに活用できそうです。また、ユーザが誤って自身のメール DB を削除した場合にも自動復旧が可能ですね。
3. 破損状態の修復
シンメトリッククラスタが破損しているデータベースを見つけると、まず Fixup を実行します。Fixup が失敗し修復できない場合、そのデータベースをリネームし、他のクラスタメンバーのサーバから自動でデータベースを複製しなおしてくれます。
Fixup で普及できない状態がどれほどの頻度で発生するか知りませんが、万一起こった時に焦らなくてすみそうです。
4. 動作条件の注意
シンメトリッククラスタは ODS が 52 以上が条件となります。
また、データベースの欠落状態の確認では、フォルダ名とファイル名で行われます。UNIX 系の OS の場合大文字小文字も判別されますので、注意してください。
通常のドミノクラスタや複製はレプリカ ID を基準としますが、シンメトリッククラスタは違うということに注意してください。
5. 復旧の動作と権限
シンメトリッククラスタが他のクラスタメンバーのサーバから自動でデータベースを複製する動作なのですが、通常の複製とは少し違うようです。
聞いた話では、読者フィールドは無視されて複製されるらしく、例えサーバが参照できない文書であっても、複製されるそうです。ただ、ACL が ”なし” のような場合にはエラーとなるそうです。
状況からして、フルアクセスアドミニストレータ権限とも少し違うようなので、要検証の項目ですね。
ただ、そもそも、このような状況に陥ること自体、良くない状態ですので制限というほどのことではないかもしれません。
既存タスクとの関係
機能概要にまとめた通り、シンメトリッククラスタは、データベースの存在の整合性維持を担当する機能です。よって、既存の機能とは次の通りすみわけされていることがわかります。
| タスク | タスクの担当範囲 |
| シンメトリック クラスタ |
データベースの存在の整合性維持。 不足や破損などを検知し、データベースをファイル単位でそろえる。 |
| クラスタ | 文書の作成などのイベントをもとに、更新を他のメンバーサーバに即時反映。 このクラスタ複製では、イベントだけが複製の対象となる。 |
| 複製 | サーバ停止中の更新など、何らかの理由でクラスタ複製されなかった文書などを複製。 よって、定期的な複製を推奨。 |
このように、シンメトリッククラスタを導入したからと言って、別のタスクを止められるわけではありません。新たな範囲を担当する ”新機能” ということになります。
サーバ管理者の作業を軽減するタスクといえますね。
機能的な制限？
今回の調査において、次のような情報を入手しました。
SERVER_AVAILABILITY_THRESHOLDが使用された場合の自動改修（対称クラスター）の動作について
簡単に言うと、ドミノクラスタの構成をホットスタンバイに設定している状態で発生する問題で、修復に失敗してしまうとのことです。
ホットスタンバイの設定は、サーバを稼働系と待機系に分け、稼働系が停止したときのみ待機系に接続させる設定で、ドミノサーバでは、notes.ini の SERVER_AVAILABILITY_THRESHOLD を 0:100 （稼働系:待機系）に指定します。
解決策は、待機系の SERVER_AVAILABILITY_THRESHOLD を 90 に変更するとありますが、これではホットスタンバイの設定ではなくなります。
ドミノクラスタの環境において、アプリサーバでは競合文書抑止の観点で、通常ホットスタンバイに設定します。
よって、現時点でシンメトリッククラスタが利用できる環境は、メールサーバだけとなりそうです（メールDBは競合が起こりにくいので、負荷分散を目的にしたクラスタリングで運用できます）。
ちなみに、この問題の改善要望が、HCL Domino Ideas Portal に投稿されています。この制限がなくなったシンメトリッククラスタを使いたいという方は、VOTE してください。
Auto repair of Symmetric Cluster when SERVER_AVAILABILITY_THRESHOLD = 100
※ 2023/9/29 更新
上記改善要望ですが、ステータスが ”Shipped” に変更されました。
やっぱりほしいフルアクセスな複製
読者フィールドや ACL の設定ミスで、サーバが参照できない状況って、いくら注意しても発生する可能性は残ります。コーディングルールで縛ったところで、間違いが起こらない保証はありませんし、開発者のすそ野が広ければ確率は上がります。ACL の設定も同様です。
単独のサーバで運用している場合は大きな問題にはなりませんが、クラスタ環境においては運用上の問題になりえます。サーバが切り替わったら、『下書き文書がなくなった！？』なんて問い合わせにつながります。
その対応として、常々、フルアクセスアドミニストレータモードで複製する機能を追加してほしいと思っています。Domino Administrator クライアントで可能なんだからサーバ間の複製でも可能と思うんですけどね...
この要望については、2018 年に改善要望を HCL Domino Ideas Portal に投稿しました。
New replication option for Domino cluster
タイトルがキャッチーじゃないのか、英語力が問題なのかは知りませんが、見事に人気がありません...
賛同いただける方は、ぜひ VOTE をお願いします。
0 件のコメント:
コメントを投稿