ETSI API を使用した仮想ネットワーク機能の修復
ESC は、ライフサイクル管理の一環として、障害が発生すると VNF を修復します。展開中に指定したリカバリポリシーがリカバリを制御します。ESC は、ポリシー主導型のフレームワークを使用したリカバリをサポートしています。 『Cisco Elastic Services Controller User Guide』の「Configuring a Recovery Policy Using the Policy-driven Framework」を参照してください。
修復パラメータは、VNF を修復する通知をトリガーするためにモニタする動作を定義します。これらのパラメータは、ルールとともに VNFD の各コンピューティングノードの KPI セクションで設定されます。ルールでは、VNF を修復するためにこれらの KPI 条件の結果として実行されるアクション(トリガーされるイベントを含む)を定義します。
ESC ETSI は、次の 2 つのセクションを使用してモニタリングを設定します。
-
kpi_data:モニタリングのタイプ、イベント、ポーリング間隔、およびその他のパラメータを定義します。
-
admin_rules:KPI モニタリングイベントがトリガーされたときのアクションを定義します。
例:
vdu1:
type: cisco.nodes.nfv.Vdu.Compute
properties:
name: Example VDU1
description: Example VDU
...
kpi_data:
VM_ALIVE-1:
event_name: 'VM_ALIVE-1'
metric_value: 1
metric_cond: 'GT'
metric_type: 'UINT32'
metric_occurrences_true: 1
metric_occurrences_false: 30
metric_collector:
type: 'ICMPPing'
nicid: 1
poll_frequency: 10
polling_unit: 'seconds'
continuous_alarm: false
admin_rules:
VM_ALIVE-1:
event_name: 'VM_ALIVE-1'
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」を参照してください。
インスタンスに注意が必要なことを示すイベントを受信した場合、タイマーが期限切れになった、または手動のリカバリ要求を受信した場合のリカバリには、3 種類のアクションがあります。修復のワークフローは次のようになります。
-
REBOOT_THEN_REDEPLOY:最初に、影響を受けた VNFC の再起動を試みます。これが失敗した場合、影響を受けた VNFC の再展開(同じホスト上で)を試みます
-
REBOOT_ONLY:VM の再起動のみを試みます
-
REDEPLOY_ONLY:VM の再展開のみを試みます
リカバリポリシーは VNF レベルで設定され、そこに含まれる VNFC ごとに適用されます。モニタリングエージェントが各 VNFC をモニタし、リカバリ状況になると、メッセージがアラームに変換され、登録されたコンシューマ(NFVO または Element Manager)に送信されます。
VNF インスタンスで自動修復が有効になっている場合、ESC は展開時に設定されたリカバリポリシーに基づいて VNF のリカバリを自動的に試みます。これは、VNFD で設定、またはインスタンス化の前に VNF インスタンスにおいて変更できます。
VNF のリカバリは、影響を受けた VNFC に対するアクションを要求することです。初期展開操作がタイムアウトした後、ESC が定義されたポリシーを使用してサービスを回復できない場合、サービスが展開に失敗すると、ライフサイクル管理操作は失敗します。
自動修復フラグ(isAutohealEnable)VNF インスタンスリソースを変更するには、仮想ネットワーク機能の変更を参照してください。
自動修復が有効でない場合、アラームのみがすべてのサブスクライバにディスパッチされます。サブスクライバは手動の HealVnfRequest を開始できます。データ構造は、あらゆる VNF 固有のアクションに使用できます。必須パラメータはありません。
SOL003 の例:
Request Payload (ETSI data structure: HealVNFRequest)
POST /vnf_instances/{vnfInstanceId}/heal
{
"cause": "b9909dde-e21e-45ec-9cc0-9e9ae413eee0",
}
SOL002 の例:
POST /vnf_instance/{vnfInstanceId}/heal
{
"vnfcInstanceId": ["b9909dde-e21e-45ec-9cc0-9e9ae413eee0"],
"cause": "b9909dde-e21e-45ec-9cc0-9e9ae413eee0",
"healScript": "REBOOT_ONLY"
}
healScript は有効なリカバリポリシー名の列挙として実装されます。これにより、展開データモデルで設定されたポリシーを上書きできます。vnfcInstanceId のリストは、必要な VNFC が影響を受けることを許可しますが、このリストがない場合、要求は VNF 全体に適用されます。
追加のパラメータを使用して、展開時に設定されたポリシーに関係なく、上書きするリカバリポリシーを指定できます。
リカバリポリシーは、追加のパラメータを使用して VNFC レベルで指定できます。これにより、VNF レベルで設定された値が上書きされます。リカバリポリシーが VNFC レベルで指定されていない場合、ESC は VNF レベルのリカバリポリシーからプロパティを継承します。
オプションの追加パラメータが cisco.datatypes.nfv.VnfcAdditionalConfigurableProperties データタイプに追加され、VNFC レベルのリカバリをサポートします。
cisco.datatypes.nfv.VnfcAdditionalConfigurableProperties:
derived_from: tosca.datatypes.nfv.VnfcAdditionalConfigurableProperties
properties:
...
is_vnfc_autoheal_enabled:
type: boolean
description: It permits to enable (TRUE)/disable (FALSE) the auto-healing functionality. If the properties is not present for configuring, then VNF-level property is used instead
required: false
recovery_action:
type: string
required: false
constraints:
- valid_values: [ REBOOT_THEN_REDEPLOY, REDEPLOY_ONLY, REBOOT_ONLY ]
モニタリングの詳細については、ETSI API を使用した仮想ネットワーク機能のモニタリングを参照してください