7.3

If demand decreases, you can scale the deployment in. The newest machines and software components
are destroyed first, and your networking and security components are updated so that your deployed
application isn't using any unnecessary resources.
Table 2‑9. Support for Scalable Components
Component Type
Support
ed Notes
Machine components Yes Scale out provisions additional instances of your machines, and scale in destroys
machines in last in, first out order.
Software components Yes Software components are provisioned or destroyed along with machines that are
scaled, and the update life cycle scripts are run for any software components that
depend on the scaled machine components.
Networking and security
components
Yes Networking and security components, including NSX load balancers, security
groups and security tags, are updated for the new deployment configuration.
Scaling impacts the network and security, including load balancer, settings for the
deployment. When you scale in or scale out a deployment that contains one or
more nodes, the associated NSX networking components are updated. For
example, if there is an on-demand NAT networking component associated with the
deployment, the NAT rules are updated in accordance with the scaling request.
When you scale in or scale out a deployment that contains an associated load
balancer, the load balancer is automatically configured to include newly added
machines or to stop load balancing machines that are targeted for tear down.
When you scale out a deployment that contains a load balancer, secondary IP
addresses are added to the load balancer. Depending on whether you scale in or
scale out, virtual machines are added or removed from the load balancer and
saved or removed in the IaaS database.
XaaS components No XaaS components are not scalable and are not updated during a scale operation.
If you are using XaaS components in your blueprint, you could create a resource
action for users to run after a scale operation, which could either scale or update
your XaaS components as required. Alternatively, you could disable scale by
configuring exactly the number of instances you want to allow for each machine
component.
Nested blueprints Yes Supported components in nested blueprints might only update if you create explicit
dependencies to scaled machine components. You create explicit dependencies
by drawing dependency lines on the design canvas.
When you scale out a deployment, vRealize Automation allocates the requested resources on the current
reservation before proceeding. If the scale is partially successful, and fails to provision one or more items
against those allocated resources, the resources are not deallocated and do not become available for
new requests. Resources that are allocated but unused because of a scale failure are known as dangling
resources. You can try to repair partially successful scale operations by attempting to scale the
deployment again. However, you cannot scale a deployment to its current size, and fixing a partially
successful scale this way does not deallocate the dangling resources. You can view the request execution
details screen and find out which tasks failed on which nodes to help you decide whether to fix the
partially successful scale with another scale operation. Failed and partially successful scale operations do
not impact the functionality of your original deployment, and you can continue to use your catalog items
while you troubleshoot any failures.
Foundations and Concepts
VMware, Inc. 40