InterSystemsデータベースミラーリング。 ミラーの作成とテスト。 パート2

前のパートでは、ミラーチューニングについて検討しました。これは、InterSystems Database Mirroring DBMSCachéの高可用性テクノロジです。

この記事では、中断（失敗）のシナリオと、それらに対するミラーの反応について検討します。



休憩は計画的でも計画外でもかまいません。

スケジュールされたものは、オペレーティングシステム、DBMSバージョン、アプリケーションシステムバージョンを更新するためにサーバーを停止する必要があり、プロセスを制御する場合です。



スケジュールされた休憩の例：

• たとえば、アップデートをインストールするためにOSを再起動します。
• DBMSの再起動
• ハードウェアサーバーの更新。

予定外-サーバーが情報システムのクライアントと、私たちの知識なしで動作することができなくなる何かが起こるとき。 この理由は次のとおりです。

• DBMSフリーズ
• OSフリーズ
• 緊急（リセット、電源オフ）;
• サーバーのハードウェア障害。
• ネットワーク機器の故障。
• 戦争、流行、吹雪、宇宙ブラックホール。

フェイルオーバー

Cachéミラーの自動フェイルオーバーは、プライマリサーバーで障害/中断が発生した場合にのみ発生します。この記事では、このような場合のみを検討します。 もちろん、バックアップサーバーで問題が発生するシナリオもありますが、この場合、IPは引き続き機能し、管理者が手動でバックアップサーバーを復元するまで物理的なミラーリングはありません。 両方のサーバーがすぐに障害を起こした場合、別のシナリオが可能です。ただし、この場合、IPの動作の中断は避けられず、その決済は「手動」で実行されます。



自動克服障害の基本的なシナリオ：

1. プライマリサーバーは、ミラー化されたデータベースの1つと連携するISクライアントに対応し、バックアップサーバーは「スタンバイ」状態になります。
2. プライマリサーバーで障害が発生しました。
3. バックアップサーバーは、プライマリサーバーが「ダウン」状態にあることを確認し、自動的にプライマリサーバーになり、情報システムのクライアントにサービスを提供し続けます。
4. 以前のプライマリサーバーは（管理者などによって）復元され、新しいバックアップサーバーになり、新しいプライマリサーバーの「スタンバイ」モードに入ります。

何がおかしいのでしょうか？

プライマリサーバーでネットワークインターフェイスに障害が発生したが、長くは続かない状況を想像してください。ただし、バックアップサーバーがプライマリサーバーになることを「決定」するだけで十分です。 結果は、スプリットブレインの状況です。

スプリットブレイン

スプリットブレイン -両方のサーバーが動作していて、それぞれが現在プライマリであると考えている場合、 脳 がんはクラスターサーバーの完全な非同期状態です。

このような状況は、たとえば、バックアップサーバーがプライマリサーバーが「ダウン」していると「誤って」判断した場合に、クラスター内に同時に2つのプライマリサーバーが表示され、ユーザーリクエストを同時に処理しようとする-クラスターの崩壊。

IPユーザーの場合、この状況は作業の無期限の中断で表され、管理者が手動で復元します。

この状況から回復する最も速い方法は、バックアップまたは非同期の「ミラー」からデータを復元することにより、クラスターを再作成することです。

AgentContactRequiredForFailover

障害/中断時のCachéミラーの動作の決定的な要因は、AgentContactRequiredForFailover = yes / noパラメーターの値です。

AgentContactRequiredForFailover = yes

AgentContactRequiredForFailover（ACRF）= yes（デフォルト）とフェールオーバーの場合、両方のサーバーのISCエージェントが中断時に接続している必要があります。 この状況は、キャッシュの予定外の障害、キャッシュの予定された再起動、OSの予定された再起動の場合に可能です。 したがって、このモードでは、他のすべての場合、自動フェイルオーバーは発生しません！

AgentContactRequiredForFailover = no

ミラーリングのこの動作モードにより、サーバーエージェント間のオンライン接続がなくてもフェールオーバーを実行できます。 このモードは、プライマリサーバーとの接続がない場合に、プライマリサーバーの電源オフ、ネットワークアダプターまたはサーバー間のネットワーク自体の障害などの状況をカバーするために必要になる場合があります。 このモードでは、バックアップサーバーをプライマリサーバーの状態に自動的に切り替える決定は、領域（％SYS）にあるZMIRRORプログラムのユーザー機能によって決定されます。

試験結果

もちろん、フェイルオーバーソリューションを構築する場合、ほとんどの状況で障害を自動的に克服することが期待されます。 現在、Cachéミラーは、考えられるほぼすべてのシナリオを自動的に処理できます。

ACRF値が異なるいくつかの典型的なシナリオで、ミラーがどのように動作するかをテストしました。

現在、Caché2012.2 RCの最新バージョンをテストしました。 はい-このシナリオの自動フェイルオーバーを意味します。

N	シナリオ	ACRF =はい	ACRF =いいえ
1	プライマリでのCachéDBMSの計画的または緊急の再起動、シャットダウン	はい	はい
2	OSのスケジュールされた再起動	はい	はい
3	OSの緊急停止、リセット、電源オフ	いや	はい
4	プライマリのネットワークインターフェイスを無効にする	いや	はい
5	プライマリとバックアップを同時にオフにし、最初にプライマリを起動します	はい	はい
6	プライマリとバックアップを同時にオフにしてから、最初のバックアップを起動します	いや	いや

テスト結果によると、判明しました-不快なシナリオは、ネットワークインターフェイスを無効にすることです（4）。 したがって、ミラーサーバー間に冗長ネットワークリンクを確立することをお勧めします。

サーバー構成の例：



両方のサーバーで同時に障害が発生した場合（シナリオ5〜6（電源​​の長時間の中断など）、コミッショニングシーケンスを遵守することが重要です。プライマリサーバーを最初にアクティブ化する必要があります。 それ以外の場合、バックアップサーバーはプライマリになり、前のプライマリサーバーの起動後、スプリットブレインの結果として、2つのサーバーが存在します。



表からわかるように、ACRF = yes（既定値）のCaché同期ミラーは、クラスターサーバー間のネットワークが「アクティブ」である場合にのみ、緊急事態を提供します。

他の状況では、ACRF = noモードがあります。管理者は、自己の責任において、ユーザープログラムZMIRRORを作成して、プライマリサーバーに障害が発生したかどうかを判断します。

Zmirror

ミラーの最終インストール用にこのようなハードウェアとソフトウェアのシステムを構築することは理論的に可能です。どのシナリオでも、プライマリサーバーの状態をソフトウェア状態で一意に判断できる場合です。

サーバーでこの状況が発生した場合は、モードをACRF = noに設定することをお勧めします。 その後、ブレークが発生し、ISCエージェントプライマリサーバーとの通信がない場合、システムは関数$$ IsOtherNodeDown ^ ZMIRROR（）を呼び出します。 関数は1または0を返します。関数がない場合、または関数が0を返す場合、自動フェールオーバープロセスは終了します。

$$ IsOtherNodeDown ^ ZMIRROR（）関数のカスタム実装を記述するとき、プログラマーのタスクは、プライマリサーバーが実際に失敗し、この場合1を返すことを確実に確認することです。







免責事項！ このコードを使用しても、ACRF =いいえの実稼働構成での自動フェイルオーバーは保証されません。 このモードを実際に使用するには、構成ごとに徹底的なフェールオーバーテストが個別に必要です。

ミラーのヒント

InterSystemsデータベースミラーリングエクスペリエンスからのいくつかの推奨事項



「手動で「バックアップサーバーがオフになっている場合、プライマリサーバーのログをクリアすることはできません」」

確かに、そうしてもバックアップサーバーが必要なログを取得できなかった場合は、バックアップサーバーを再度作成できます。



「プライマリサーバーの実行中は、バックアップサーバーを長時間オフにすることはできません」

この場合、同期されていないログのオーバーフローにより、プライマリサーバーのディスク領域が不足する可能性があります。



「サーバーの時刻を同期する必要があります」

これは単純な条件ですが、満たす必要があります。 それ以外の場合、たとえば数時間の同期解除中に、バックアップサーバーはログの関連性と「混乱」します。 その結果、バックアップサーバーを再度作成します。



「サーバー間のネットワークをアンロードする必要があります」

ネットワークを介して、ログは常にプライマリサーバーからバックアップに転送されます。 サーバー間のネットワークがまだビジー状態であるか、チャネルがデータ転送に十分でない場合、プライマリサーバーは「スローダウン」を開始し、ISユーザーが入力したデータを転送する時間がありません。



「システム構成設定、マッピング、ロールおよびユーザー設定は手動で同期する必要があります」

グローバル、クラス、パッケージのマッピングの設定、およびプライマリサーバーとバックアップサーバーの役割、ユーザー、システム構成のすべての設定も同期する必要があります。 ミラーは、ミラーリング用に選択されたデータベースのみを同期します。 したがって、ミラー管理者は同じ構成、マッピング、およびユーザーセキュリティポリシーを持ち、プライマリサーバーとバックアップサーバーのこの状態を維持する必要があります。

運用特性

フェールオーバーに必要なエージェントコンタクトの自動フェールオーバーの平均実行時間= yesは10〜20秒です。 10〜20秒の一時停止は、アプリケーションが新しいサーバーで引き続き動作する時間です。 この場合、接続が再接続する（サーバーへの直接接続があった場合）か、作業がECP接続を介して行われた場合、単に動作を継続します。

ACRF = noの場合、一時停止は平均35〜40秒です。 この場合、ECPクライアントは接続を失います。 ECPのデフォルトのタイムアウト= 30秒。 SYSTEM ^％ZSTARTのECPクライアントサーバーでECPとACRF = noのミラーを使用するシステムの場合、ECPタイムアウトを増加させるコードを作成することをお勧めします。



$ system .ECPを実行し ます。 SetProperty （ "ECPRecoveryTimout" 、90）

一番下の行または「それが必要」？

この質問に答えて、「はい」と言います。 「すぐに使用できる」もの、つまりACRF = yesモードを使用しても、OS、Caché、ハードウェアなどの更新に関するスケジュールされた作業を実行できます。 情報システムのノンストップ操作、およびCachéDBMSの障害の自動克服。 残りのシナリオは、必要な数の「小数点以下9」のハードウェアフェールオーバークラスターと無停電電源システムの助けを借りて、既知の手段でカバーできます。