The VNFs with the same VM group can be deployed on the same host.

During deployment, ESC deploys the first VM as an anchor VM for affinity. All the other VMs that follow the same affinity rule will be deployed to the same host as the anchor VM. The anchor VM deployment helps to optimize the resource usage.

Example for Intra Group Affinity Policy:

…
<vm_group>
<name>vm-gp</name>
…
<placement>
<type>zone_host</type>
<enforcement>strict</enforcement>
<zone>cluster1</zone>
</placement>
<placement>
<type>affinity</type>
<enforcement>strict</enforcement>
</placement>
…

Note	Only strict attribute is supported for enforcement.

Note	Affinity and anti-affinity policy with a host placement policy is incorrect and may cause deployment failure. Host placement alone (without affinity and anti-affinity placement policy within a VM group) can be used to achieve intra group affinity.

The VNFs with the same VM group can be deployed in different hosts. During deployment ESC deploys VNFs with the same VM group one after the other. At the end of each VNF deployment, ESC records its host to a list. At the beginning of each VNF’s deployment, ESC deploys the VNF to a computing-host that is not in the list. If all the available computing-host(s) are in the list, ESC fails the whole deployment.

Example for Intra Group Anti-Affinity Policy:

…
<vm_group>
<name>vm-gp</name>
…
<placement>
<type>zone_host</type>
<enforcement>strict</enforcement>
<zone>cluster1</zone>
</placement>
<placement>
<type>anti_affinity</type>
<enforcement>strict</enforcement>
</placement>

All VMs in a VM group can be deployed to a cluster. For example, all VMs in a vm group CSR-gp1 can be deployed to cluster dc-cluster2.

Note	The VMware vCenter cluster must be created by the administrator.

Example for cluster placement:

<name>CSR-gp1</name>
	         <placement>
		             <type>zone_host</type>
		             <enforcement>strict</enforcement>
		             <zone>dc-cluster2</zone>
           </placement>

All VMS in a VM group can be deployed to a host. For example, all VMs in the vm group CSR-gp1 will be deployed to host 10.2.0.2.

<name>CSR-gp1</name>
           <placement>
             <type>zone_host</type>
	            <enforcement>strict</enforcement>
	             <host>10.2.0.2</host>
            </placement> 

The VMs in different VM groups can be deployed to the same host. For example, all VMs in the VM group ASA-gp1 can be deployed to the same host as the VMs in the VM group CSR-gp1.

During deployment ESC deploys the first VM as an anchor VM. All other VMs that follow the same affinity rule will be deployed to the same host as the anchor VM.

Note	To ensure that the inter-group affinity rules are applied within a single cluster, verify that all VM groups in a deployment are specified to the same cluster (<zone> in esc data_model).

Example for Inter Group Affinity Policy:

<deployment>
<deployment>
<name>test-affinity-2groups</name>
<policies>
<placement>
<target_vm_group_ref>CSR-gp1</target_vm_group_ref>
<type>affinity</type>
<vm_group_ref>CSR-gp2</vm_group_ref>
<vm_group_ref>ASA-gp1</vm_group_ref>
<enforcement>strict</enforcement>
</placement>
</policies>

The VNFs in the same deployment but different VM Groups can be explicitly deployed in different hosts. For example back-up VNFs or High-availability VNFs. Multiple VM groups can follow this policy by adding the vm_group_ref tag, and providing the VM group name as the value.

Note

You can only use one <target_vm_group_ref> tag, type tag and enforcement tag under the placement tag. The host or zone cannot be specified.You can use multiple <vm_group_ref> tags, however the anti-affinity policy only applies between each <vm_group_ref> and their <target_vm_group_ref>, which means that 2 or more <vm_group_ref> can be deployed on the same host, as long as each of them are deployed on a different host from their <target_vm_group_ref> that is acceptable.

Example for Inter Group anti-affinity Policy:

<deployments>
           <deployment>
            <name>intergroup-anti_affinity-dep</name>
             <policies>
              <placement>
                  <target_vm_group_ref>affinity-test-gp1</target_vm_group_ref>
                  <type>anti_affinity</type>
                  <vm_group_ref>affinity-test-gp2</vm_group_ref>
                  <enforcement>strict</enforcement>
               </placement>
          </policies>
…

In a multiple VIM deployment, the VM groups of a placement policy must belong to the same VIM. That is, the VIM connector must be the same for the VM groups (specified in the vim_id attribute in the locator tag of the VM group). ESC rejects a deployment if the affinity and anti-affinity policies between VM groups are on different VIMs. For more details on deploying VMs on multiple deployments, see "Deploying VNFs onMultiple OpenStack VIMs".

A placement group tag is added under policies. Each <placement_group> contains the following:

• name—name unique per deployment.

• type—affinity or anti_affinity

• enforcement—strict

• vm_group—the content of each vm_group must be a vm group name listed under the same deployment.

The placement group tag is placed within the placement policy. The placement policy describes the relationship between the target vm group and the vm group members. The placement_group policy describes mutual relationship among all vm group members. The placement group policy is not applicable for target vm group.

The datamodel is as follows:

<policies>
	<placement_group>
		<name>placement-affinity-1</name>
		<type>affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g1</vm_group>
		<vm_group>t1g2</vm_group>
		<vm_group>t1g7</vm_group>
	</placement_group>
	<placement_group>
		<name>placement-affinity-2</name>
		<type>affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g3</vm_group>
		<vm_group>t1g4</vm_group>
	</placement_group>
	<placement_group>
		<name>placement-affinity-3</name>
		<type>affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g5</vm_group>
		<vm_group>t1g6</vm_group>
	</placement_group>
	<placement_group>
		<name>placement-anti-affinity-1</name>
		<type>anti_affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g1</vm_group>
		<vm_group>t1g3</vm_group>
		<vm_group>t1g5</vm_group>
	</placement_group>
</policies>

Note

In the new placement group tag under policies, the <target_vm_group_ref> and <vm_group_ref> are replaced with <vm_group>. The ref based affinity and antiaffinity tags are deprecated. The placement group policy is applicable for inter group affinity and anti-affinity policies only. You cannot use both placement and placement group tags together in the inter group affinity and anti-affinity policies. The placement group name tag must be unique for each placement group policy.

Following are the limitations when affinity and anti-affinity rules are applied on VMware vCenter:

• All Affinity rules defined on VMware vCenter are implemented in a cluster.

• DPM, HA and vMotion must be turned off.

• VM deployment and recovery are managed by ESC.

• DRS must be set to manual mode if it is turned on.

• To leverage DRS deployment, shared storage is required.

• Supported value for <enforcement> tag should be 'strict'.

• <zone_host> must be used for any VM group.