Unsupported content

   

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Scaling an existing network pod

You can update a pod after it has been onboarded. This capability enables you to scale a pod when necessary. This topic discusses scaling an existing network pod and contains the following sections:

The following BMC Communities video (3:02) describes how to scale pod-level networks and use them in BMC Cloud Lifecycle Management. This involves adding resources to a BMC Network Automation pod and then synchronizing the pod (and sometimes a virtual cluster) in BMC Cloud Lifecycle Management.

https://youtu.be/gWvBa1ck-DU

Use case for synchronizing

For example, a pod might be running out of virtual ports for virtual machine (VM) provisioning because the pod was originally configured with one vswitch and a maximum of 120 virtual ports. You can update the pod with an additional access switch, which will provide more virtual ports for any new network containers that are created for the pod. You might want to add pod-level networks to existing pods to add more capacity.

Other scenarios for updating a pod include adding new load balancer nodes, firewalls, pod-level VLANs, or pod-level management networks into the pod.

Adding resources to the pod in BMC Network Automation

To add resources to a pod, you can simply update the pod in BMC Network Automation. (See Editing a pod in TrueSight Network Automation.)

You can add components to the pod, or you can remove nodes (Switch, Firewall, or Loadbalancer) from the pod that are no longer being used. Prior to removal, ensure that the node is not referenced in any network container.

If you are removing a hypervisor switch node from a pod and it is the only hypervisor switch being referenced by an onboarded cluster, then the pod synchronization operation will fail in BMC Cloud Lifecycle Management. To remove a hypervisor switch node from the pod, there must be one or more alternate switches common between the pod and the on-boarded cluster; otherwise, the pod synchronization fails to remove the switch from BMC Cloud Lifecycle Management.

Synchronizing the pod in BMC Cloud Lifecycle Management

  1. From the BMC Cloud Lifecycle Management Administration Console, click the vertical Workspaces menu on the left side of the window and select Resources.
  2. Under Quick Links on the left, click Pods under the General section.
  3. Select the pod you want to synchronize.
  4. Click the Synchronize Pod icon to synchronize the network pod with any changes to the pod since it was onboarded.
    When you add a new pod-level management network to an existing pod, synchronizing the pod only adds the new network to the CloudDB. You must create a new network container to use the newly created management network. For more information, see Extending the network on hypervisor nodes in the POD (version 4.6.03 and later) below.

  5. After the pod is synchronized, the associated virtual cluster must also be synchronized, as described in the section below.

Synchronizing the virtual cluster in BMC Cloud Lifecycle Management

To update the virtual hosts, virtual resource pools, and virtual disk repositories associated with a virtual cluster, complete the following steps:

  1. Under Quick Links on the left, click Resources under the Compute section.
  2. Select the virtual cluster you want to refresh from the table.
  3. Click the Synchronize Virtual Cluster icon .
  4. (Applicable for 4.6.07.003 and later) For VMware, if you want to update the Server Automation cache with all the infrastructure changes, click the Sync BSA Cache option. By default, this option is not selected. 
    If you select this option, the Server Automation cache is updated with all the infrastructure changes for the Virtual Center or Virtual Infrastructure Manager to which the selected Virtual Cluster belongs. The changes are not updated only for the selected Virtual Cluster. Examples of infrastructure changes include addition or modification of Virtual Cluster, Resource Pool, Virtual Host, or Virtual Disk Repository. When you select this option, you get the latest data from TrueSight Server Automation.

  5. Once the activity is marked as complete, click the Refresh icon in the upper-right corner of the window to refresh the Resources table so that the newly onboarded resources appear in the table.

Note

The Virtual Cluster onboard  or synchronization operation will fail unless there is at least one hypervisor switch that is common between the virtual cluster and the pod. In the case of a physical server, there should be at least one matching switch and switch port combination common between the pod and physical server NIC in BMC Server Automation.


Extending the network on hypervisor nodes in the POD (version 4.6.03 and later)

Before version 4.6.03, when you added a new pod-level management or customer network to an existing pod, synchronizing the pod only added the new network to the cloud database. But, to use the newly created management network, you had to create a new network container. You could not synchronize a pod for existing networks to extend a network of existing nodes.

With version 4.6.03 or later, you can extend the existing network on new or existing hypervisor nodes in the POD by adding a new port type onto the nodes and synchronizing the pod in BMC Cloud Lifecycle Management. After you synchronize a pod, newly added networks are available to new network containers and existing network containers. (This functionality is supported for virtual machines only, not physical servers.)

To enable this functionality, the AttributeValue line for propagateNetworkChangesToContainers in the provider.json file is set to true by default. (This provider.json file is located in the CLMInstallationFolder\Platform_Manager\configuration folder.) For example:

"cloudClass" : "com.bmc.cloud.model.beans.AccessAttributeValue",
"accessAttribute" : {
     "cloudClass" : "com.bmc.cloud.model.beans.AccessAttribute",
     "datatype" : "BOOLEAN",
     "description" : "If flag is set to true, POD synch changes like addition of new POD network, are propagated to all associated containers.Default value is true",
     "guid" : "f520a1c8-ea13-41cb-b01f-ef8df104a04f",
     "isOptional" : true,
     "isPassword" : false,
    "modifiableWithoutRestart" : false,
     "name" : "propagateNetworkChangesToContainers"
},
"attributeValue" : "true",
"guid" : "5b44f92e-2599-4890-9608-ae5c99591f96",
"name" : "propagateNetworkChangesToContainers"

When AttributeValue is set to false, newly added networks are available to new network containers for use after a POD is synchronized. Consequently, when AttributeValue is set to false, the same networks are visible to existing network containers, but you cannot use these new networks on the existing network containers.

Important: When using this functionality, make sure that the port type name (which is in the Name Within Switch field in the BMC Network Automation pod) is pre-created on the device before you synchronize the pod in BMC Cloud Lifecycle Management. 

If one or more port types are defined on the nodes for the existing network, the selection of port type will be in random during service provisioning.

Related topic

Creating a NIC segment without a VLAN


Was this page helpful? Yes No Submitting... Thank you

Comments