障害回復の概要

役割

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

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

–

フェールオーバー

最後に発生したフェールオーバーの種類

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

–

コア

リモート・サイト・ノードの詳細を含むコア災害復旧構成

peerVip–リモートサイトのロードバランサーのVIP

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

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

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

peerBusinessLogicNodes - リモートサイトの 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 ノード (通常ノードまたは専用データベースノード) の peerVip–VIP

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

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

Pgsql

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

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

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

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

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

ファイル

リモート・サイトでの構成およびRRDファイル関連の災害復旧構成

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

backup.hoursOfDay - ファイルをバックアップする時刻

backup.daysOfWeek - ファイルをバックアップするための曜日

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

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

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

ウォッチドッグ

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

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

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

heartbeat.interval:サイト間のハートビートメッセージ間隔(秒単位)

notification.email–サービスの問題を報告するために電子メールアドレスに連絡する

通知間隔 - 影響を受けるサービスに関する電子メールを受信する間隔を減衰させます。

failureDetection.isCustom - リモート サイトでカスタム障害検出を使用するかどうか

failureDetection.script - 障害検出スクリプトのパス

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

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

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アドレス

peerNode - リモートサイトのデバイス管理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–現在のロールで、payload.waitTimeプロパティで指定された時間待機します。

必須

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

説明

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

文字列

–

必須

空の文字列を使用できます。

ペイロード.待機時間

両方のサイトがスタンバイになる猶予期間の終了時刻

文字列 (日付)

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

必須

空の文字列を使用できます。

このプロパティは、アクションの値を wait に指定した場合に使用されます。

ペイロード.詳細

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

–

JSON オブジェクト

オプション

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

jmp-dr init

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

コマンドによってプロンプトが出されるパラメーターの値を入力する必要があります。

データをレプリケートし、ディザスター リカバリー サイト間でレプリケーションを監視するために必要な MySQL および PgSQL ユーザーとパスワードを作成します。次のユーザーが作成されます。

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

• デフォルトのユーザー名 repAdmin とパスワード repAdminPass を持つユーザーが、MySQL データベースのレプリケーションの正常性とフェイルオーバーを監視します。

• PgSQL レプリケーションの既定のユーザー名レプリケーションとパスワード レプリケーションを使用するユーザー。

• 既定のユーザー名 postgres とパスワード postgres を持つユーザーが、PgSQL レプリケーションの正常性とフェールオーバーを監視します。

-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-core–VIPアドレス、パスワード、および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–指定した期間、スタンバイサイトへの自動フェールオーバーを無効にします。期間を時間または分単位で入力します。たとえば、1時間または30分です。値と共に "h" または "m" を入力しない場合 (2 など)、既定の期間は時間単位で計算されます。0 を入力すると、自動フェールオーバーは完全に無効になります。

jmp-dr api v1 config

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

--list–ディザスタリカバリ構成の特定のセクションとディザスタリカバリウォッチドッグサービスのステータスを表示します。 表 1 に、セクション名を示します。

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

カスタム障害検出スクリプトにこのコマンドを含めると、コマンドはディザスタリカバリ設定とディザスタリカバリウォッチドッグサービスのステータスを取得し、スクリプト内のロジックを実行します。