ESC には、VNF の展開時に指定できる次の VM リカバリタイプがあります。
ESC は、ポリシー主導型フレームワークを使用したリカバリをサポートしています。詳細については、「Configuring a Recovery Policy Using the Policy-driven Framework」を参照してください。
展開データモデルで指定できる VM リカバリには、次の 3 種類のアクションがあります。
-
REBOOT_THEN_REDEPLOY(デフォルト):VM ダウンイベントを受信するか、タイマーが期限切れになると、修復ワークフローは最初に VM の再起動を試行し、再起動に失敗すると、同じホストで VM の再展開を試行します。
-
REBOOT_ONLY:VM ダウンイベントを受信するか、タイマーが期限切れになると、修復ワークフローは VM の再起動のみを試行します。
-
REDEPLOY_ONLY:VM ダウンイベントを受信するか、タイマーが期限切れになると、修復ワークフローは VM の再展開のみを試行します。
(注) |
VM を再展開する REBOOT_THEN_REDEPLOY および REDEPLOY_ONLY がポリシーに含まれ、配置ポリシーが適用されていない場合、VIM は VM を再展開するホストを決定します。
|
(注) |
ESC は、vCloud Director の手動リカバリと自動リカバリの両方をサポートしています。3 種類のリカバリアクションはすべて、vCloud Director に適用されます。REBOOT_THEN_REDEPLOY がデフォルトのリカバリアクションです。vCD
の展開については、VMware vCloud Director(vCD)での仮想ネットワーク機能の展開を参照してください。
VM の再展開を伴うリカバリアクションでは、障害があるか、削除された ESC 管理対象のエフェメラルポートとボリュームが自動的に再作成および接続され、リカバリが成功することを確認します。
|
自動回復
自動回復では、リカバリタイプパラメータは [自動(Auto)] に設定されます。ESC は、リカバリポリシーで指定された <action-on-recovery> 値により、VM を自動的に回復させます。ユーザがリカバリタイプを選択しない場合、リカバリタイプはデフォルトで自動になります。
<recovery_policy>
<recovery_type>AUTO</recovery_type>
<action_on_recovery>REBOOT_THEN_REDEPLOY</action_on_recovery>
<max_retries>3</max_retries>
</recovery_policy>
手動回復
VM の手動回復
手動回復では、ESC は VM_MANUAL_RECOVERY_NEEDED 通知をノースバウンド(NB)に送信し、NB から回復のための指示を待ちます。ESC は、NB からリカバリ指示を受信すると、リカバリを実行します。展開全体の手動回復については、以下を参照してください。
展開の手動回復
ESC は、リカバリポリシーの action-on-recovery パラメータを使用して、単一のリクエストベースでのアクションのオーバーライドもサポートします。前述の 3 つのリカバリアクションに加えて、次の 2 つのリカバリアクションを利用できます。
-
RESET_STATE_THEN_REBOOT:VM を再起動する前に、VM の状態がリセットされ、リカバリのために VIM が VM を再起動できるようになります。これは OpenStack にのみ適用されます。
-
DISASTER_RECOVERY:VNF が展開されている VIM が使用できなくなり、サービスを継続するために VNF を新しい VIM に移動する必要がある場合、このアクションを呼び出して VNF(個々の VM ではなくサービス全体)を新しい VIM に再展開できます。
このアクションを使用するには、VIM ロケータを更新するモデル専用サービス更新を先に実行する必要があります。この手順を実行しないと、リカバリリクエストが失敗します。このタイプのサービス更新を実行する方法の詳細については、以下を参照してください(REST
API 経由のみ)。
元の VNF は削除されません。このリカバリアクションの使用は、オーケストレーション スタックから VNF に到達できないことを意味し、VIM 自体がリカバリされたときに、古い展開を手動でクリーンアップする必要があると想定されるためです。
手動リカバリポリシーのデータモデルは次のとおりです。
<vm_group>
...
<recovery_policy>
<recovery_type>MANUAL</recovery_type>
<action_on_recovery>REBOOT_THEN_REDEPLOY</action_on_recovery>
<max_retries>3</max_retries>
</recovery_policy>
...
</vm_group
データモデルのリカバリポリシーパラメータの詳細については、Elastic Services Controller 展開属性 [英語] を参照してください。ESC ポータル(VMware のみ)でのリカバリポリシーの設定の詳細については、「ESCポータルを使用した VMware vCenter での VNF の展開」を参照してください。
VM_MANUAL_RECOVERY_NEEDED 通知は次のとおりです。
===== SEND NOTIFICATION STARTS =====
WARN Type: VM_MANUAL_RECOVERY_NEEDED
WARN Status: SUCCESS
WARN Status Code: 200
WARN Status Msg: Recovery event for VM [manual-recover_error-g1_0_7d96ad0b-4f27-4a5a-bdf7-ec830e93d07e] triggered.
WARN Tenant: manual-recovery-tenant
WARN Service ID: NULL
WARN Deployment ID: 08491863-846a-4294-b305-c0002b9e8daf
WARN Deployment name: dep-error
WARN VM group name: error-g1
WARN VM Source:
WARN VM ID: ffea079d-0ea2-4d47-ba31-26a08e6dff22
WARN Host ID: 3a5351dc4bb7df0ee25e238a8ebbd6c6fcdf225aebcb9dff6ba10249
WARN Host Name: my-server-27
WARN [DEBUG-ONLY] VM IP: 192.168.0.3;
WARN ===== SEND NOTIFICATION ENDS =====
VM の手動回復用 API
Confd API と REST API を使用して手動リカバリを実行できます。手動回復要求は、事前定義されたリカバリアクションを任意のアクションに上書きするように設定できます。
Netconf API recovery-vm-action DO generated vm name [xmlfile]
API を使用してリカバリを実行するには、esc_nc_cli にログインし、次のコマンドを実行します。
$ esc_nc_cli --user <username> --password <password> recovery-vm-action DO [xmlfile]
リカバリが実行され、リカバリ通知が NB に送信されます。
(注) |
リカバリ(recovery-vm-action DO <VM-NAME> )は、VM が動作し、サービスがアクティブになった後に実行できます。展開が不完全な場合は、リカバリを実行する前に展開を完了する必要があります。
設定可能な手動回復中にフェールオーバーが発生した場合、手動回復は事前定義されたリカバリアクションで再開されます。
展開の移行では、常にデフォルトのリカバリポリシーを使用する必要があります。LCS ベースのリカバリでは、VM / VNF 手動回復のリカバリアクションを指定しないでください。モニタの有効化オプションと設定可能な手動回復オプションを同時に使用することはできません。
|
REST API
http://ip:8080/ESCAPI/#!/Recovery_VM_Operations/handleOperation
POST /v0/{internal_tenant_id}/deployments/recovery-vm/{vm_name}
リカバリ VM 操作ペイロード:
{
"operation":"recovery_do",
"properties":{
"property":[
{
"name":"action",
"value":"REDEPLOY_ONLY"
}
]
}
}
モデル専用サービス更新を実行するには、新しいパラメータを edit-config API に提供して、VIM でアクションが実行されないようにし、更新を ESC データモデルのみに制限します。これにより、VIM で展開を更新する準備が整うまでに、データモデルの準備を完了できます。
http://ip:8080/ESCManager/v0/conf/edit-config?modelOnly=true
たとえば、<action-on-recovery> として DISASTER_RECOVERY
を使用してリカバリ API を呼び出す前に、VIM ロケータを更新します。
<?xml version="1.0" encoding="UTF-8"?>
<esc_datamodel xmlns="http://www.cisco.com/esc/esc" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:ns1="urn:ietf:params:xml:ns:netconf:notification:1.0">
<tenants>
<tenant>
<name>admin-tenant</name>
<deployments>
<deployment>
<name>test-deploy</name>
<networks>
<network>
<name>test-network</name>
<locator>
<vim_id>my-ucs-59</vim_id>
<vim_project>admin</vim_project>
</locator>
</network>
</networks>
<vm_group>
<name>g1</name>
<locator>
<vim_id>my-ucs-59</vim_id>
<vim_project>admin</vim_project>
</locator>
<bootup_time>120</bootup_time>
</vm_group>
</deployment>
</deployments>
</tenant>
</tenants>
</esc_datamodel>
(注) |
VIM が再び使用可能になったら、ディザスタリカバリシナリオで古い展開を削除する必要があることを忘れないでください。
|
この API のさらなる用途は、前述のリカバリ API を介した VM の再起動前に実行する永続ボリュームの UUID の更新です。これには、以前のバージョンの ESC のように、VM グループを削除して再度追加する必要がないという利点があります。ペイロードの例を次に示します。
<esc_datamodel xmlns="http://www.cisco.com/esc/esc" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:ns1="urn:ietf:params:xml:ns:netconf:notification:1.0">
<tenants>
<tenant>
<name>my-tenant</name>
<deployments>
<deployment>
<name>my-dep</name>
<vm_group>
<name>my-vm</name>
<bootup_time>1800</bootup_time>
<volumes>
<volume>
<name>new-volume</name>
<volid>1</volid>
<bus>ide</bus>
<type>lvm</type>
</volume>
<volume nc:operation="delete">
<name>old-volume</name>
<volid>1</volid>
</volume>
</volumes>
</vm_group>
</deployment>
</deployments>
</tenant>
</tenants>
</esc_datamodel>
VM の手動回復でサポートされる VM の状態とサービスの組み合わせ
recovery-vm-action の API は、自動と手動の両方のリカバリタイプに適用されますが、特定の VM の状態とサービスに限ります。次のテーブルに詳細を示します。一般に、展開、サービス更新、展開解除、およびリカバリの間は、ESC
は手動リカバリアクションを拒否します。
VM 状態
|
サービス ステート
|
recovery-vm-action
|
動作中(Alive)
|
ACTIVE
|
サポート対象
|
接続中(Alive)
|
ERROR
|
サポート対象
|
ERROR
|
ERROR
|
サポート対象
|
展開の手動回復
モニタリングパラメータを使用しないリカバリ ESC は、サービスレベルでの VM の手動回復、つまり展開全体の回復をサポートします。サービスが正常に展開された後、VM の障害が原因でサービスがエラー状態に移行することがあります。ESC は、障害が発生したこれらの VM を手動で回復することも、展開回復要求によって展開全体を回復することもできます。VM
単独の手動回復については、手動回復を参照してください。
展開の手動回復用 API
NETCONF API と REST API を使用して手動リカバリを実行できます。
手動回復要求は、事前定義されたリカバリアクションを任意のアクションに上書きするように設定できます。
(注) |
展開回復後のサービスアクティブ通知はありません。展開のサービス状態がアクティブかどうかを確認するには、esc_nc_cli --user <username> --password <password> get esc_datamodel などのクエリを実行する必要があります。
設定可能な手動回復中にフェールオーバーが発生した場合、手動回復は事前定義されたリカバリアクションで再開されます。
展開の移行では、常にデフォルトのリカバリポリシーを使用する必要があります。LCS ベースのリカバリでは、VM/VNF 手動リカバリのリカバリアクションを指定しないでください。モニターの有効化オプションと設定可能な手動リカバリオプションは同時に使用できません。
|
NETCONF API
svc-action RECOVER tenant-name deployment-name [xmlfile]
API を使用してリカバリを実行するには、esc_nc_cli
にログインします。
REST API
POST /v0/{internal_tenant_id}/deployments/service/{internal_deployment_id}
Content-Type: application/xml
Accept: application/json
Callback: http://172.16.0.1:9010/
Callback-ESC-Events: http://172.16.0.1:9010/
<service_operation xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<operation>recover</operation>
</service_operation>
値は次のとおりです。
internal_tenant_id:システム管理者のテナント ID またはテナント名。
internal_deployment_id:展開名。
展開の手動回復でサポートされる VM の状態とサービスの組み合わせ
svc-action RECOVER の API は、自動と手動の両方のリカバリタイプに適用されますが、特定の VM の状態とサービスに限ります。次のテーブルに詳細を示します。一般に、展開、サービスの更新、展開解除、およびリカバリの間は、ESC
は手動回復アクションを拒否します。
(注) |
サービスがアクティブまたはエラー状態の場合、ESC は VM レベルのリカバリ要求を受け入れます。
サービスリカバリ要求後にすべての VM が動作状態になっている場合、NB に通知は送信されません。
|
VM 状態
|
サービス ステート
|
svc-action RECOVER
|
ERROR
|
ERROR
|
サポート対象
|
ERROR
|
ERROR
|
サポート対象
|
モニタリングパラメータによるリカバリの有効化 手動回復では、モニタリングパラメータに応じて VM をリカバリできます。VM がエラー状態の場合は、エラー状態の VM を動作状態に戻すためのモニタリングパラメータを設定します。VM が回復すると、ESC は RECOVERY_CANCELLED
通知を送信します。VM が動作状態に復帰しない場合、リカバリプロセスがトリガーされます。詳細については、「手動回復」を参照してください。
NETCONF APIsvc-action SET_MONITOR_AND_RECOVER <tenant-name> <dep-name>
リカバリ通知:
===== SEND NOTIFICATION STARTS =====
WARN Type: VM_RECOVERY_INIT
WARN Status: SUCCESS
WARN Status Code: 200
WARN Status Msg: Recovery with enabling monitor first event for VM Generated ID [dep-resource_g1_0_74132737-d0a4-4ef0-bd9e-86465c1017bf] triggered.
(注) |
モニタリングパラメータで有効化されるリカバリは、サービスレベルでの手動回復専用です。
|
monitor_on_error パラメータにより、エラー状態にある VM の継続的なモニタリングが設定されます。
<recovery_policy>
<recovery_type>AUTO</recovery_type>
<action_on_recovery>REBOOT_ONLY</action_on_recovery>
<max_retries>1</max_retries>
<monitor_on_error>true</monitor_on_error>
</recovery_policy>
デフォルト値は false です。
false を指定すると、エラー状態にある VM のモニタリングは設定解除されます。
true を指定すると、エラー状態にある VM のモニタリングは設定されます。後から VM 稼働イベントが発生した場合(VM_RECOVERY_COMPLETE の後)、VM は稼働状態に戻ります。