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

役割

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

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

フェイルオーバー

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

値は、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 - リモートサイトに専用データベースノードが含まれているかどうか

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

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

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

pgsqlの

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

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

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

peerNodes - リモート サイトの PostgreSQL ノード(通常のノードまたは FM/PM 専用ノード)のノード 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 – サービスの問題を報告するための連絡先メールアドレス

notification.interval:影響を受けるサービスに関する電子メールの受信間隔を減衰させます。

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

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 - ロールを active に変更します。

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

nothing:ロールを変更しません。

wait - payload.waitTime プロパティで指定された時間だけ、現在のロールで待機します。

必須

空の文字列は許可されません。

形容

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

糸

–

必須

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

ペイロード.waitTime

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

文字列 (日付)

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

必須

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

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

ペイロード.詳細

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

–

JSON オブジェクト

随意

空の文字列は許可されません。

jmp-dr init

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

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

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

• デフォルトのユーザー名 repUser とパスワード repPass を持つユーザー(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– 指定した期間、スタンバイ サイトへの自動フェールオーバーをディセーブルにします。期間を時間または分で入力します。たとえば、1h や 30m などです。値とともに「h」または「m」を入力しない場合(例:2)、デフォルトの所要時間は時間単位で計算されます。0 を入力すると、自動フェールオーバーは永続的に無効になります。

jmp-dr api v1 config

ディザスタリカバリの設定とランタイム情報をJSON形式で表示します。

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

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

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