ディザスター リカバリーの概要

役割

現在のサイトの災害復旧の役割

ロールは、アクティブ、スタンバイ、またはスタンドアロンにできます。

フェールオーバー

最後に発生したフェイルオーバーのタイプ

フェイルオーバーがまだ発生していない場合は、値をactive_to_standby、standby_to_active、または空にすることができます。

–

コア

リモート サイト ノードの詳細を含むコア ディザスター リカバリー構成

リモートサイトのロードバランサーのピアVip

adminPass - リモートサイトの暗号化された管理者パスワード。複数のエントリーはコンマで区切られます。

scpTimeout - サイト間のSCP転送障害を検出するために使用されるタイムアウト値

peerLoadBalancerNodes – リモート サイトのロード バランサー ノードのノード IP アドレス。複数のエントリーはコンマで区切られます。

ピアBusinessLogicNodes - リモートサイトのJBossノードのノードIPアドレス。複数のエントリーはコンマで区切られます。

peerDeviceMgtIps - リモートサイトのデバイス管理IPアドレス。複数のエントリーはコンマで区切られます。

{ 
"core": {
  "peerVip": "10.155.90.210",
  "adminPass": "ABCDE12345",
  "scpTimeout": 120,
  "peerLoadBalancerNodes": "10.155.90.211",
   "peerBusinessLogicNodes": "10.155.90.211",
   "peerDeviceMgtIps": "10.155.90.211"}
}

Mysql

リモート サイトの MySQL データベースに関連するディザスター リカバリー設定

hasDedicatedDb – リモート サイトに専用データベース ノードが含まれているかどうか

リモートサイトの MySQL ノードのピアVip-VIP(通常ノードまたは専用データベース ノード)

peerNodes - リモート サイトの MySQL ノードのノード IP アドレス(通常のノードまたは専用 DB ノードのいずれか)。複数のエントリーはコンマで区切られます。

{ "mysql": {
   "hasDedicatedDb": false,
   "peerVip": "10.155.90.210",
   "peerNodes": "10.155.90.211"
   }
}

Pgsql

リモートサイトの PgSQL データベースに関連するディザスター リカバリー設定

hasFmpm - リモート サイトに特殊な FMPM ノードが含まれているかどうか

peerFmpmVip リモート サイトの PostgreSQL ノードの VIP(通常ノードまたは FM/PM 専用ノード)

peerNodes - リモート サイトの PostgreSQL ノードのノード IP アドレス(通常ノードまたは FM/PM 専用ノードのいずれか)。複数のエントリーはコンマで区切られます。

{ "psql": {
  "hasFmpm": false,
  "peerFmpmVip": "10.155.90.210",
  "peerNodes": "10.155.90.211"
  }
}

ファイル

リモート サイトでの設定と RRD ファイル関連の災害復旧設定

backup.maxCount - 保持するバックアップ ファイルの最大数

backup.hoursOfDay – ファイルをバックアップするのに1日の時間

backup.daysOfWeek – ファイルをバックアップする曜日

restore.hoursOfDay – アクティブなサイトからファイルをポーリングする日の時間

restore.daysOfweek – アクティブサイトからファイルをポーリングする曜日

{ "file": {
  "backup": {
    "maxCount": 3,
    "hoursOfDay": "*",
    "daysOfWeek": "*" },
  "restore": {
    "hoursOfDay": "*",
"daysOfWeek": "*" }
  }
}

ウォッチドッグ

現在のサイトのディザスター リカバリー ウォッチドッグに関連するディザスター リカバリー構成

ハートビート.再試行 - ハートビート メッセージを再試行する回数

ハートビート.タイムアウト - 各ハートビート メッセージのタイムアウト(秒)

ハートビート.interval - サイト間のハートビート メッセージ間隔(秒)

notification.email - サービスの問題を報告するために、電子メール アドレスに問い合わせる

通知.interval - 影響を受けるサービスに関する電子メールを受信するまでの減衰間隔

failureDetection.isCustom – リモート サイトがカスタム障害検知を使用しているかどうか

failureDetection.script – 障害検知スクリプトのパス

failureDetection.threshold.failover – フェールオーバーをトリガーするしきい値の割合

failureDetection.threshold.adjust管理デバイスの割合を調整するための管理しきい値の割合

failureDetection.threshold.warning – 障害回復サイトがより多くの監視デバイスに到達し、デバイスアービトレーション アルゴリズムの精度を向上させるために警告を送信するしきい値の割合

failureDetection.waitDuration – 両方のサイトがスタンバイになると、元のアクティブなサイトが再びアクティブになることを許可する猶予期間

failureDetection.arbiters - アービター デバイスのリスト

{ "watchdog": {
  "heartbeat": {
"retries": 4,
"timeout": 5,
"interval": 30 },
  "notification": {
    "email": "abc@example.com",
    "interval": 3600 },
  "failureDetection": {
"isCustom": false,
"script": "/var/cache/jmp-geo/watchdog/bin/arbitration",
    "threshold": {
      "failover": 0.5,
      "adjustManaged": 0.5,
      "warning": 0.7 },
      "waitDuration": "8h",
      "arbiters": [{
        "username": "user1",
        "password": "xxx",
        "host": "10.155.69.114",
        "port": 22,
        "privateKey": ""
      }]
}
  }
}

デバイス管理

リモート サイトのデバイス管理 IP アドレス

peerNodes - リモートサイトのデバイス管理IPアドレス。複数のエントリーはコンマで区切られます。

ノード - 現在のサイトのデバイス管理IPアドレス。複数のエントリーはコンマで区切られます。

ip- このノード(コマンドが実行されるノード)上の jmp-dr api v1 config --list デバイス管理IPアドレスとインターフェイス

{ "deviceManagement": {
   "peerNodes": "10.155.90.211",
   "nodes": "10.155.90.222",
”ip”: “10.155.90.228,eth0”
 }
}

状態

現在のサイトにある災害復旧ウォッチドッグサービスのランタイム情報。このサイトでディザスターリカバリーウォッチドッグが実行されなかった場合、このセクションは利用できません。障害回復ウォッチドッグが停止した場合、このセクションの情報は古いものです。

–

{ "states": {
    "arbiterMonitor": {
      "progress": "idle",
      "msg": {
        "service": "arbiterMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:18:55+00:00"
      },
"service": {}
   },

    "configMonitor": {
      "progress": "idle",
      "msg": {
        "service": "configMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:19:15+00:00"
      },"service": {}
    },

    "fileMonitor": {
      "progress": "idle",
      "msg": {
        "service": "fileMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:18:59+00:00"
      },
"service": {}
    },

    "heartbeat": {
      "progress": "unknown",
      "msg": {
        "service": "heartbeat",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "localFailover": false
        },
        "time": "2015-07-18T22:17:49+00:00"
      },
"service": {
        "booting": false,
        "bootEndTime": null,
        "waitTime": null,
        "automaticFailover": false,
        "automaticFailoverEndTime": "2015-07-18T07:41:41+00:00"
      }
    },

"mysqlMonitor": {
      "progress": "idle",
      "msg": {
        "service": "mysqlMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:19:09+00:00"
      },
"service": {}
    },

    "pgsqlMonitor": {
      "progress": "unknown",
      "msg": {
        "service": "pgsqlMonitor",
        "description": "Master node pgsql in active or standby site maybe CRASHED. Pgsql replication is in bad status. Please manually check Postgresql-9.4 status.",
        "state": false,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 1098
        },
        "time": "2015-07-18T22:18:27+00:00"
      },"service": {}
    },

 
    "serviceMonitor": {
      "progress": "running",
      "msg": {
        "service": "serviceMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:19:30+00:00"
      },
      

"service": {}
    }
  }
}                                      

状態

このサイトの現在の障害回復ロール

文字列

アクティブ

スタンバイ

必須

空の文字列は使用できません。

アクション

ディザスター・リカバリー・ウォッチドッグが実行しなければならないアクション

文字列

beActive - ロールをアクティブに変更します。

beStandby - ロールをスタンバイに変更します。

役割を変更しないでください。

wait – ペイロードで指定された時間を現在のロールで待機します。waitTime プロパティ。

必須

空の文字列は使用できません。

説明

アクション フィールドの説明と電子メール通知で送信されるメッセージ

文字列

–

必須

空の文字列が許可されます。

ペイロード.waitTime

両サイトがスタンバイ状態になった猶予期間の終了時間

文字列(日付)

YYYY-MM-DD、UTC 時刻(HH:MM+00:00 形式)

必須

空の文字列が許可されます。

このプロパティーは、待機としてアクションの値を指定する場合に使用されます。

ペイロード詳細

スクリプトのデバッグに使用できるユーザーカスタマイズ情報

–

JSON オブジェクト

オプション

空の文字列は使用できません。

jmp-dr init

両方のサイトで障害回復構成ファイルを初期化します。

コマンドでプロンプトが表示されるパラメータの値を入力する必要があります。

データを複製し、災害復旧サイト全体の複製を監視するために必要な MySQL および PgSQL のユーザーとパスワードを作成します。以下のユーザーが作成されます。

• デフォルトユーザー名を持つユーザー repUser およびパスワード repPass for MySQL データベースレプリケーション。

• 既定のユーザー名を持つユーザー repAdmin およびパスワード repAdminPass を使用して、MySQL データベースレプリケーションの正常性とフェイルオーバーを監視します。

• PgSQLレプリケーション用のデフォルトのユーザー名レプリケーションとパスワードレプリケーションを持つユーザー。

• PgSQLレプリケーションの状態とフェイルオーバーを監視するためのデフォルトのユーザー名postgresとパスワードpostgresを持つユーザー。

-a– 災害時リカバリー構成ファイルは、アクティブ・サイトでのみ初期化します。

-s– スタンバイ・サイトでのみ障害回復構成ファイルを初期化します。

jmp-dr start

両方のサイトで障害回復プロセスを開始します。

このコマンドは、アクティブサイトの VIP ノードで実行する必要があります。アクティブサイトは、スタンバイサイトへのSSH接続を確立し、スタンバイサイトで コマンドを実行 jmp-dr start します。

このコマンドを実行すると、MySQL データベースと PgSQL データベースの複製と設定、スタンバイ サイトへの RRD ファイルのバックアップが開始されます。

次のコマンドを実行します。

• 最初にディザスター リカバリー プロセスを開始するには

• Junos Space セットアップのアップグレード プロセスを停止した後にディザスター リカバリー プロセスを再開するには、

-a– 障害回復プロセスは、アクティブなサイトでのみ開始します。

-s– 障害回復プロセスはスタンバイ・サイトでのみ開始します。

jmp-dr toolkit config update

オプションなしで コマンドを実行すると、 コマンドは次のようになります。

• サイトで変更されたクラスタ設定を表示し、ローカル サイトで更新します。

• リモート サイトで変更されたクラスタ設定を受け入れ、更新します。

コマンドは、以下の順序で実行する必要があります。

1. 両方のサイトで、クラスタ設定の変更を受け入れて更新します。

2. ロードバランサの変更を更新し、両方のサイトでSCPタイムアウト設定を変更および更新します。

3. その他の災害復旧設定パラメータを変更および更新します。

このコマンドは、ローカル・サイトの VIP ノードで実行し、構成を変更し、変更された構成を受け入れるリモート・サイトの VIP ノードで行う必要があります。

これらのオプションを使用して、サイトの障害回復構成を変更し、ピア・サイトで変更を更新します。

-user-coreVIPアドレス、パスワード、SCPタイムアウト設定を変更します。

-user-file-backup設定とRRDファイルのバックアップ設定を変更します。

-user-file-restore構成を変更し、RRD ファイルの複製をスタンバイ サイトの設定に変更します。

-user-watchdog-heartbeat– 災害復旧ウォッチドッグのハートビート設定を変更します。

-user-watchdog-notification電子メール通知の設定を変更します.

-user-watchdog-failureDetection– 障害検知設定を変更します。

jmp-dr health

障害回復プロセスのステータスを確認します。

このコマンドは、MySQL データベースと PgSQL データベースが複製され、設定と RRD ファイルがバックアップされるかどうかをチェックし、ディザスター リカバリー ウォッチドッグのステータスを検証し、エラーを報告します。

–

jmp-dr stop

サイト間の障害回復プロセスを停止します。

このコマンドを実行すると、MySQLとPgSQLデータベースの複製と設定、サイト間のRRDファイルのバックアップが停止します。ディザスター リカバリー データ ファイルは削除されません。JBoss、OpenNMS、Apache などのサービスのステータスは変わりません。

–

jmp-dr reset

ディザスター リカバリー プロセスを停止し、サイトからディザスター リカバリー データ ファイルを削除します。このサイトは、スタンドアロンクラスタとしてサービスを開始します。

このコマンドは、両方のサイトの VIP ノードで実行して、障害回復プロセスを完全に停止し、両方のサイトから災害時リカバリー・データ・ファイルを削除する必要があります。

–

jmp-dr manualFailover

スタンバイ サイトに手動でフェールオーバーします。

このコマンドを実行すると、スタンバイ サイトは新しいアクティブ サイトになり、アクティブ サイトは新しいスタンバイ サイトになります。

-a手動でサイトのロールをアクティブに変更します。

-s手動でサイトの役割をスタンバイに変更します。

jmp-dr toolkit watchdog status [options]

スタンバイ サイトへの自動フェールオーバーを有効にする、または指定した期間のスタンバイ サイトへの自動フェールオーバーを無効にします。

–enable-automatic-failoverスタンバイサイトへの自動フェイルオーバーを有効にします。

–disable-automatic-failover durationスタンバイサイトへの自動フェイルオーバーを指定時間無効にします。時間を数時間または分で入力します。例えば、1hまたは30m。「h」または「m」を値(例えば、2)と一緒に入力しない場合、デフォルトの期間は時間単位で計算されます。ゼロと入力すると、自動フェイルオーバーは永続的に無効になります。

jmp-dr api v1 config

災害復旧の構成とランタイム情報を JSON 形式で表示します。

--list– 災害復旧ウォッチドッグサービスの災害復旧構成とステータスの特定のセクションを表示します。 表 1 は、セクション名を示しています。

–-include<sections>– カスタム障害検知スクリプトに、災害復旧の構成と災害復旧ウォッチドッグサービスのステータスの特定のセクションを含めます。複数のセクション名をコンマで区切ります。

このコマンドをカスタム障害検知スクリプトに含めると、コマンドは災害復旧監視犬サービスの災害復旧構成とステータスを取得し、スクリプト内のロジックを実行します。