7.1
Table Of Contents
- Foundations and Concepts
- Contents
- Foundations and Concepts
- Using Scenarios
- Using the Goal Navigator
- Introducing vRealize Automation
- Tenancy and User Roles
- Service Catalog
- Infrastructure as a Service
- XaaS Blueprints and Resource Actions
- Common Components
- Life Cycle Extensibility
- vRealize Automation Extensibility Options
- Leveraging Existing and Future Infrastructure
- Configuring Business-Relevant Services
- Extending vRealize Automation with Event-Based Workflows
- Integrating with Third-Party Management Systems
- Adding New IT Services and Creating New Actions
- Calling vRealize Automation Services from External Applications
- Distributed Execution
- Index
Scaling and Reconfiguring Deployments
You can scale provisioned deployments to adjust to changing workload demands. You use the scale in or
scale out actions for horizontal scale, and the machine recongure action for vertical scale. You govern scale
and recongure actions by using entitlements, approval policies, or by designing constraints directly into
blueprints.
Scale In or Scale Out
After you provision a deployment, you can adjust to changing workload demands by increasing or
decreasing the number of instances of virtual or cloud machines in your deployment. For example, you
deployed a three-tiered banking application with a clustered application server node, a database node, and a
load balancer node. Demand increases, and you nd that the two instances of your application server node
cannot handle all the trac. Because your blueprint supports up to ten instances of the application server,
and you are entitled to scale actions, you can scale out your application. You navigate to your provisioned
banking application item in vRealize Automation and select the scale out action to add another instance of
your application server node to the deployment. vRealize Automation provisions a new machine, installs
the application software component, and updates your load balancer so your banking application can
handle the increased demands.
If demand later decreases, you can scale the deployment back in. The newest machines and software
components are destroyed rst, and your networking and security components are updated so your
banking application isn't using any unnecessary resources.
Table 9. Support for Scalable Components
Component Type
Suppor
ted Notes
Machine components Yes Scale out provisions additional instances of your machines, and scale in
destroys machines in last in, rst 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 and
security groups, are updated for the new deployment conguration.
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 conguring 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 aempting to scale the deployment again.
However, you cannot scale a deployment to its current size, and xing a partially successful scale this way
does not deallocate the dangling resources. You can view the request execution details screen and nd out
which tasks failed on which nodes to help you decide whether to x 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
30 VMware, Inc.