diff --git a/specs/rocky/vdu-affinity-policy.rst b/specs/rocky/vdu-affinity-policy.rst new file mode 100755 index 00000000..86ccd940 --- /dev/null +++ b/specs/rocky/vdu-affinity-policy.rst @@ -0,0 +1,330 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + + +======================================== +Affinity/Anti-affinity policies for VDUs +======================================== + +https://blueprints.launchpad.net/tacker/+spec/vdu-affinity-policy + +This proposal describes the plan to introduce Affinity/Anti-affinity +policies for VDUs into VNFD template. The Tacker administrator enables +the Affinity policy to place VDUs into the same Compute node and enables +Anti-affinity policy to force-place VDUs into different Compute nodes. + +Problem description +=================== + +Deployers sometimes want to control the placement of instances. For +example, they want to place the instances into the same compute node in +order to reduce communication overhead and traffics between instances, +e.g. a web server and a database. They may also wants to ensure that the +instances are deployed into different compute nodes to avoid failure at +the same time by a hardware fault. Especially, it's important to achive +severe SLA such that requires 99.999% availability. + +Currently, the only way to control the placement is using availability +zone. But, creating availability zones requires admin priviledge and it +has no flexibility. + +For example, considering this scenario, when there is a need to place +VDUs into the same compute node using availability zones. An +administrator creates availability zones for each compute node. An +operator finds appropriate compute node and specify corresponding +availability zone for each deployment. It has no merit of the cloud and +to make matters worse, operators have to recover VDUs manually if the +deployed compute node fails. + +Dispersing VDUs into different compute nodes also has concerns. The +availability zones need to split into the maximum number of VDUs in +expected VNFs. It decreases utilization efficiency and there are some +cases that are unable to split, e.g. the operators use an infrastructure +provided by other organization, a split of availability zones violates +an infrastructure design policy and so on. + +Proposed change +=============== + +Introduce a new policy ``tosca.policies.tacker.Placement`` into VNFD. +It provides affinity/anti-affinity placement for the target VDUs. + +This feature is designed to satisfy a requirement defined in ETSI GS +NFV-IFA 011 [#f1]_. + +An example VNFD assuming Active/Standby is shown below. This example +defines anti-affinity placement to primary VDU and secondary VDU. + +.. code-block:: yaml + + :caption: Example VNFD + tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0 + description: placement policy for VDUs + topology_templete: + node_templates: + VDU_Primary: + type: tosca.nodes.nfv.VDU.Tacker + # ...snip... + VDU_Secondary: + type: tosca.nodes.nfv.VDU.Tacker + # ....snip... + policies: + - anti_affinity_placement_policy + type: tosca.policies.tacker.Placement + properties: + policy: anti-affinity + strict: true + targets: [ VDU_Primary, VDU_Secondary ] + +This placement policy supports "affinity", "anti-affinity", +"soft-affinity", "soft-anti-affinity" in terms of Nova ServerGroup. + +Mapping these ServerGroup policies to our placement policy type, +``policy`` property specifies "affinity" or "anti-affinity" as a +fundamental policy and ``strict`` property controls "soft-" prefix. + +The base policy ``tosca.policies.Placement`` is already implemented on +tosca-parser [#f2]_. Current heat-translator implements the placement +policy using ``OS::Nova::ServerGroup`` resource which supports both of +affinity and anti-affinity but current heat-translator always specifies +"affinity" as the policy parameter of the resource. + +This feature extends ``tosca.policies.Placement`` in heat-translator to +support additional properties. This plan follows other existing node +types. For example, when heat-translator translates +``tosca.policies.tacker.Scaling`` derived from +``tosca.policies.Scaling``, it uses the translator for +``tosca.policies.Scaling``, but heat-translator has an issue which is +policies derived from tosca.policies.Placement are not +translated [#f3]_. The issue must be solved before +we implement the feature. + +Tacker itself needs no change excepting for the policy definition. The +policy will be defined in ``tacker_defs.yaml``. + +This feature doesn't support Kubernetes until Node affinity becomes +stable. According to Kubernetes Configuration / Node affinity [#f4]_, it +was marked as beta at the time Rocky PTG was held. + +Alternatives +------------ + +Implementing this feature has another option. + +**Implement as a policy described in NSD** + +This feature can also be modeled with a policy in NSD. + +Example NSD including policies are shown below. + +.. code-block:: yaml + + :caption: Example NSD + + tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0 + description: placement policy for VNFs + imports: + - VNFD_Primary + - VNFD_Secondary + topology_template: + node_templates: + VNF_Primary: + type: tosca.nodes.nfv.VNF_Primary + VNF_Secondary: + type: tosca.nodes.nfv.VNF_Secondary + + policies: + - anti_affinity_policy: + type: tosca.policies.tacker.Placement + description: Apply my placement policy to my application servers + targets: [ VNF_Primary, VNF_Secondary ] + properties: + policy: anti-affinity + strict: true + +With the above example, VNF_Primary and VNF_Secondary will be placed +into different compute nodes. + +This model respects to ETSI GS NFV-IFA 014 [#f5]_, the policy corresponds to +NsDf.affinityOrAntiAffinityGroup. + +Adopting this model requires a large scope of changes. It is due to +calling Tacker APIs from a Mitral workflow to create VNF instances that +constitute a NS instance. To implement this model, the following +changes will be required. + +* Changes to NS feature + + * Add a support for policies section of NSD to "NS Create API". + + * Add a policy processor which understand the policies and reflect + the policy to generated workflow. + + * The workflow needs to create a ServerGroup and pass the created + resource to each VNF creation task. And the workflow need to + return the resource as a part of its result. + + * VNF creation + tasks need to generate and pass policies to "VNF Creation" API. + + * The policy processors should be isolated for each policy type + + * It seems to be hard to design a module that can be applied to + general cases. + + * Save and use additional resource information + + * When Tacker creates NS, Tacker saves additional resources' + information generated by a mistral workflow + + * The policies also need to be saved if we give policies as an API + parameter. + + * When Tacker deletes NS, Tacker deletes additional resources' bound + to the NS. + + * When Tacker updates NS, Tacker might take into account policies + and additional resources. + +* Changes to VNF feature + + * Add API parameter "policies" that allows users to add or override the policies. + + * Given policies have to be saved with other VNF attributes + + * Implement "tosca.policies.tacker.Placement.ServerGroup" which put + all VDUs contained in the VNF to a specified ServerGroup. + +TOSCA parser impact +------------------- + +This feature needs to add a policy type named +``tosca.policies.tacker.Placement``. + +.. csv-table:: tosca.policies.tacker.Placement (derived from tosca.policies.Placement) + :header: Property Name,Type,Required,Default,Constraints,Description + + policy,string,false,'affinity',"'affinity', + 'anti-affinity'",Placement policy for target VDUs + strict,boolean,false,'false',"'true', 'false'","If the policy is not + strict, it is allowed to continue even if the scheduler fails to + assign hosts under the policy." + +Data model impact +----------------- + +None + +REST API impact +--------------- + +None + +Security impact +--------------- + +None + +Notifications impact +-------------------- + +None + +Other end user impact +--------------------- + +None + +Performance Impact +------------------ + +VDU deployment time will be a little bit longer since Nova filters +applicable compute nodes for given VDUs. + +Other deployer impact +--------------------- + +This feature requires heat-translator which supports +`tosca.policies.tacker.Placement` type. + +Developer impact +---------------- + +This feature depends on a change of heat-translator which is developed +by other project. We need to discuss with heat-translator guys and to +contribute their project. + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + Dinesh Bhor + +Other contributors: + Hiroyuki Jo + + Masataka Saito + + Tushar Patil + + Nitesh Vanarase + +Work Items +---------- + +* Contribute to Heat-translator on `tosca.policies.Placement` +* Add TOSCA type definitions +* Unit Tests +* Functional Tests +* Feature documentation in doc/source/user/placement_usage_guide.rst + +Dependencies +============ + +This feature depends on next items. + +* VDU Level recovery + + * Current Tacker respawns the whole the VNF when it detects a failure + on a VDU + + * If a user wants to use this feature to improve availability of his + VNF which has redundant architecture, Tacker needs to support VDU + level respawn action. + + * This issue should be solved in another blueprint. + +* Improvement of Placement policy on Heat-translator + + * Current implementation only supports affinity policy. + + * We need to add support for the properties defined above. + +* `Policies derived from tosca.policies.Placement are not translated `_ + +Testing +======= + +add unit test + +Documentation Impact +==================== + +* update VNFD template guide, adding a guide of + tosca.policies.tacker.Placement + +References +========== + +.. [#f1] http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/010/02.01.01_60/gs_NFV-IFA011v020101p.pdf +.. [#f2] https://github.com/openstack/tosca-parser/blob/f208175e69f05b5723c6cd2b0f56512b0bd3caa3/toscaparser/elements/TOSCA_definition_1_0.yaml#L931 +.. [#f3] https://bugs.launchpad.net/heat-translator/+bug/1755433 +.. [#f4] https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity +.. [#f5] http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.04.01_60/gs_NFV-IFA014v020401p.pdf +