ETSI API を使用した仮想ネットワーク機能の修復
ESC は、ライフサイクル管理の一環として、障害が発生すると VNF を修復します。展開中に指定したリカバリポリシーがリカバリを制御します。ESC は、ポリシー主導型のフレームワークを使用したリカバリをサポートしています。詳細についは、『Cisco Elastic Services Controller User Guide』の「Configuring a Recovery Policy Using the Policy-driven Framework」を参照してください。
修復パラメータは、VNF を修復する通知をトリガーするためにモニタする動作を定義します。これらのパラメータは、ルールを使用して VNFD の各コンピューティングノードの KPI セクションで構成されます。ルールは、これらの KPI 条件の結果として、VNF を修復するアクションを定義します。
ETSI VNFM は、次の 2 つのセクションを使用してモニタリングを設定します。
-
kpi_data:モニタリングのタイプ、イベント、ポーリング間隔、およびその他のパラメータを定義します。
-
admin_rules:KPI モニタリングイベントがトリガーされたときのアクションを定義します。
例:
vdu1:
type: cisco.nodes.nfv.Vdu.Compute
properties:
name: Example VDU1
description: Example VDU
...
configurable_properties:
additional_vnfc_configurable_properties:
vim_flavor: { get_input: VIM_FLAVOR }
bootup_time: { get_input: BOOTUP_TIME }
vm_name_override: { get_input: VDU1_VM_NAME}
recovery_action: REBOOT_THEN_REDEPLOY
recovery_wait_time: 1
kpi_data:
VM_ALIVE-1:
event_name: 'VM_ALIVE'
metric_value: 1
metric_cond: 'GT'
metric_type: 'UINT32'
metric_occurrences_true: 1
metric_occurrences_false: 30
metric_collector:
type: 'ICMPPing'
nicid: 1
address_id: 0
poll_frequency: 10
polling_unit: 'seconds'
continuous_alarm: false
admin_rules:
VM_ALIVE:
event_name: 'VM_ALIVE'
action:
- 'ALWAYS log'
- 'FALSE recover autohealing'
- 'TRUE esc_vm_alive_notification'
前の例は、デフォルトの KPI と、ESC での展開を完了するために必要なサービスアライブ通知をサポートするルールを示しています。VNFD で公開される KPI、ルール、および基盤となるデータモデルの詳細については、『Cisco Elastic Services Controller User Guide』の「KPIs、Rules and Metrics」を参照してください。
VNF のリカバリは、初期導入時またはリカバリ要求で定義されたリカバリポリシーによって決定された、影響を受ける VNFC に対するアクションを要求することです。
リカバリには 4 種類のアクションがあります。インスタンスに注意が必要であることを示すイベントが受信されると、タイマーが期限切れになるか、手動のリカバリ要求が受信されます。修復ワークフローは、デフォルトで、VNF レベルまたは VNFD 内の VNFC レベルで設定されたリカバリポリシーを使用します。サポートされているポリシーは次の通りです。
-
REBOOT_THEN_REDEPLOY:最初に、影響を受けた VNFC の再起動を試みます。これが失敗した場合、影響を受けた VNFC の再展開(同じホスト上で)を試みます
-
REBOOT_ONLY:VM の再起動のみを試みます
-
RESET_THEN_REBOOT — VM の状態をリセットして (Openstack のみ)、VM の再起動を試みます。
-
REDEPLOY_ONLY:VM の再展開のみを試みます
リカバリポリシーが VNF レベルで設定されている場合、ポリシーは各構成要素 VNFC に適用されます。VNFC レベルで指定されている場合は、そのポリシーが優先されます。モニタリングエージェントが各 VNFC をモニタし、リカバリ状況になると、メッセージがアラームに変換され、登録されたコンシューマ(NFVO または Element Manager)に送信されます。
HealVnfRequest には、リカバリ要求の処理中に VNFM 内でさまざまな動作をトリガーする原因パラメータが含まれています。原因が VNFM でサポートされている値の 1 つである場合(およびサポートされている原因として展開の VNFD にリストされている場合)、次の表に示すように、特定の追加の Params キーがアクティブ化されて、必要なリカバリアクションをサポートします。NFVO が原因をサポートしている場合、許可は additionalParams を受け取り、リカバリ要求を実行する前に入力を変更できるようにします。
原因が ESC でサポートされているオーバーライドの原因の 1 つでない場合、提供された値は単なるメタデータであると見なされ、無視されます。 VNFM は、展開時に構成されたリカバリポリシーを使用します。原因が ESC によってサポートされていても、VNFD にリストされていない場合、要求は拒否されます。
原因 |
additionalParams キー |
リカバリ動作 |
||
---|---|---|---|---|
APPLICATION_FAILURE |
オプション vnfcInstanceId |
これらの VNFC のみにリカバリを制限する VNFC インスタンスの有効な識別子のリストが
|
||
VIRTUALISATION_FAILURE |
オプション
|
さらに、同じ要求で置換される永続ボリュームがある場合、複数の要求を回避するために、VNFD および VIM 内のボリュームの識別子が提供されます。ただし、ボリュームが接続されている VNFC においては、修復される VNFC のリストに含まれている必要があります。この永続ボリュームの更新は、Openstack VIM にのみ適用されます。 障害があるかまたは削除された VNFM によって管理される一時的なポートおよびボリュームは、再作成されて接続され、リカバリが確実に成功するようにします。 |
||
APPLICATION_OR_VIRTUALISATION_FAILURE |
オプション vnfcInstanceId |
|
||
INVALID_VM_STATE |
オプション vnfcInstanceId |
|
||
PERSISTENT_VOLUME_FAILURE |
必須:
オプション vnfcInstanceId |
|
||
CHANGE_PERSISTENT_VOLUME |
必須:
|
必須キーを使用すると、VM を再展開することなく、新しい永続ボリューム(multi-attach を含む)で既存のボリュームを置き換えることができます。データモデルが更新され、ボリュームが置き換えられると、VM が再起動されます。これは、Openstack VIM にのみ適用されます。 |
||
VIM_FAILURE |
なし |
|
VNF インスタンスで自動修復が有効になっている場合、ESC は展開時に設定されたリカバリポリシーに基づいて VNF のリカバリを自動的に試みます。これは、VNFD で構成するか、インスタンス化の前に VNF インスタンスに対して変更することができます。
自動修復フラグ(isAutohealEnable)VNF インスタンスリソースを変更するには、仮想ネットワーク機能の変更を参照してください。
自動修復が有効でない場合、アラームのみがすべてのサブスクライバにディスパッチされます。サブスクライバーは、次の例に従って、手動の HealVnfRequest を開始できます。パラメータはデフォルトではオプションですが、さまざまな原因について表 9 のルールが適用されます。
SOL003 の例:
メソッドタイプ:
POST
VNFM エンドポイント:
/vnf_instances/{vnfInstanceId}/heal
HTTP 要求ヘッダー:
Content-Type:application/json
要求ペイロード(ETSI データ構造:HealVnfRequest)
{
"cause":"VIRTUALISATION_FAILURE",
"additionalParams": {
"virtualStorageDescId": "cf-cdr1-vol",
"resourceId": " d8771acb-a32f-66dg-7bc2-8f4ec333ccb8"
},
"vnfcInstanceId": [b9909dde-e21e-45ec-9cc0-9e9ae413eee0"]
}
SOL002 の例:
POST /vnf_instance/{vnfInstanceId}/heal
{
"vnfcInstanceId": ["b9909dde-e21e-45ec-9cc0-9e9ae413eee0"],
"cause": "b9909dde-e21e-45ec-9cc0-9e9ae413eee0"
}
vnfcInstanceIds
のリストは、リカバリを必要な VNFC に制限します。ただし、このリストがないということは、要求が VNF 全体に適用されることを意味します。
SOL002 HealVnfRequest の原因は、SOL003 API と同じ動作をします。
モニタリングの詳細については、ETSI API を使用した仮想ネットワーク機能のモニタリングを参照してください