.. 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] https://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/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