The design decisions determine the deployment configuration, resource sizing, and automation support of vRealize Automation in the SDDC.
Deployment Specification
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CFG-001 |
Deploy vRealize Automation as a cluster of three nodes in the default management vSphere cluster. |
vRealize Automation can manage one or more VMware Cloud Foundation instances from a single implementation. The vRealize Automation deployment can also manage VMware Cloud on AWS and public cloud instances, if network access is permitted. |
|
PCA-VRA-CFG-002 |
Deploy vRealize Automation in a vRealize Suite Lifecycle Manager logical environment in VMware Cloud Foundation mode. |
|
|
PCA-VRA-CFG-003 |
Protect the vRealize Automation cluster virtual machines by using vSphere High Availability. |
Supports the availability objectives for vRealize Automation without requiring manual intervention during an ESXi host failure event. |
None. |
PCA-VRA-CFG-004 |
Apply vSphere Distributed Resource Scheduler anti-affinity rules for the vRealize Automation cluster virtual machines. |
vSphere Distributed Resource Scheduler prevents the vRealize Automation cluster virtual machines from residing on the same ESXi host and risking the high availability of the deployment. |
|
PCA-VRA-CFG-005 |
Add a VM group for the vRealize Automation cluster virtual machines and set a VM rule to restart the Workspace ONE Access VM group before the vRealize Automation VM group. |
You can define the startup order of virtual machines regarding the service dependency. The startup order ensures that vSphere High Availability powers on the virtual machines for vRealize Automation in an order that respects product dependencies. |
You must manage the VM group and VM rules for the vRealize Automation cluster virtual machines. |
PCA-VRA-CFG-006 |
Place the vRealize Automation cluster virtual machines in a designated virtual machine folder. |
Provides the organization of the vRealize Automation cluster virtual machines in the management domain vSphere inventory. |
You must create the virtual machine folder during or after the deployment. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CFG-007 |
When using two availability zones, add the vRealize Automation cluster virtual machines to the VM group for the first availability zone. |
Ensures that, by default, the vRealize Automation cluster virtual machines are powered on in the primary availability zone hosts group. |
|
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CFG-008 |
Deploy the vRealize Automation cluster nodes as medium-size or larger appliances. |
A medium-size vRealize Automation appliance is typically sufficient, but can be scaled-up for increased workload scalability. |
|
Network Design
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-NET-001 |
Place the vRealize Automation cluster nodes on the cross-instance NSX network segment. |
Provides a consistent deployment model for management applications and a potential to extend to a second VMware Cloud Foundation instance for disaster recovery. |
You must use an implementation of NSX-T Data Center to support this networking configuration. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-NET-002 |
Allocate statically assigned IP addresses from the cross-instance NSX segment to the vRealize Automation cluster nodes and the NSX load balancer virtual server. |
Using statically assigned IP addresses ensures stability of the deployment and makes it simpler to maintain and easier to track. |
Requires precise IP address management. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-NET-003 |
Configure forward and reverse DNS records for each vRealize Automation cluster node IP address and for the NSX load balancer virtual server IP address. |
vRealize Automation is accessible by using a fully qualified domain name instead of by using IP addresses only. |
|
PCA-VRA-NET-004 |
Configure DNS servers for each vRealize Automation cluster node. |
Ensures that vRealize Automation has accurate name resolution on which its services are dependent. |
|
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-NET-005 |
Use the small-size NSX load balancer that is configured by SDDC Manager on the dedicated NSX Tier-1 gateway in the management domain to load balance the clustered Workspace ONE Access deployment, to also load balance the connections across the vRealize Automation cluster nodes. |
|
You must use the NSX load balancer that is configured by SDDC Manager and the integration with vRealize Suite Lifecycle Manager to support this network configuration. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-NET-006 |
Configure NTP servers for each vRealize Automation cluster node. |
|
|
Life Cycle Management
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-LCM-001 |
|
|
|
PCA-VRA-LCM-002 |
Use vRealize Suite Lifecycle Manager to apply vRealize Automation patches and hot fixes. |
Patches, updates, and hot fixes for vRealize Automation are not managed by SDDC Manager. |
Before applying the updates to vRealize Automation, you must use vRealize Suite Lifecycle Manager to automate the download or manually upload the product binaries to vRealize Suite Lifecycle Manager. |
Cloud Assembly Design
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CA-CFG-001 |
Establish and publish a well-defined strategy, implementation, and taxonomy for the tagging of cloud resources. |
With capability and constraint tags, you can organize and activate cloud resources and profiles for resource consumption by using the declarative nature of cloud templates to define deployment configurations. |
Your strategy must account for external tags, for example, vSphere and NSX-T Data Center tags, and internal user-defined tags managed through Cloud Assembly. |
PCA-VRA-CA-CFG-002 |
Apply constraint tags to the cloud template YAML structure. |
During a provisioning operation, capabilities are matched with constraints, each expressed as tags, in cloud templates and images to determine the deployment configuration. |
You must manage the capability tags on your cloud resources, such as cloud zones, storage and storage profiles, networks and network profiles. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CA-CFG-003 |
Add a cloud account for the vCenter Server instance for each VI workload domain in each VMware Cloud Foundation instance. |
You can integrate the vCenter Server instance for each VI workload domains with vRealize Automation for provisioning. |
|
PCA-VRA-CA-CFG-004 |
Add a cloud account for the NSX Manager cluster for each VI workload domain in each VMware Cloud Foundation instance.
Note:
For an environment with NSX Federation, add a cloud account for each VI workload domain NSX Local Manager cluster. |
You can integrate the NSX Manager cluster for one or more VI workload domains with vRealize Automation for provisioning. |
|
PCA-VRA-CA-CFG-005 |
Use the default |
|
None. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CA-CFG-006 |
Create a cloud zone for each VI workload domain. |
Provides provisioning on a specific workload domain. |
None. |
PCA-VRA-CA-CFG-007 |
Add tags to each cloud zone. |
Ensures that deployments can be targeted for a designated cloud account region. |
|
PCA-VRA-CA-CFG-008 |
For each cluster added to a VI workload domain, add tags to the vSphere cluster. |
|
|
PCA-VRA-CA-CFG-009 |
Add a workload folder in the vCenter Server data center for each VI workload domain. |
Ensures that cloud templates that do not include the |
Note:
The destination folder, where the cloud templates are deployed, must exist. The destination folder cannot be created by Cloud Assembly without extensibility. |
PCA-VRA-CA-CFG-010 |
Use the |
|
Does not provide advanced workload placement across cloud zones and the related cloud accounts. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CA-CFG-011 |
Use the default integration to the vRealize Orchestrator cluster that is embedded in vRealize Automation. |
The use of the embedded vRealize Orchestrator cluster has the following advantages over the use of an external vRealize Orchestrator instance:
Using the embedded instance of vRealize Orchestrator is applicable in most use cases. For information about the use cases for using the external vRealize Orchestrator, refer to the product documentation. |
It might be less efficient to run a workflow in a multi-instance deployment from a centralized cluster. However, it is simpler to manage. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CA-CFG-012 |
For each project, add one or more cloud zones based on the project requirements and allowed cloud resources. |
Provides one or more cloud zones and their resources for project consumption. |
None. |
PCA-VRA-CA-CFG-013 |
For each project, set a provisioning priority for each cloud zone based on your deployment prioritization. |
Prioritizes one cloud zone over another within a project. The default priority is 0 (highest priority). |
You must manage the provisioning priority for each cloud zone in each project. |
PCA-VRA-CA-CFG-014 |
For each project, set limits for the project cloud zones as required. |
Sets the maximum number of workload instances and resources provisioned in the cloud zone for the project. The default limit is 0 (unlimited). |
If a value greater than 0 (unlimited) is used for the instance or resource limit, you must manage the limit for each cloud zone in each project when requirements change. |
PCA-VRA-CA-CFG-015 |
For each project, specify network, storage, and extensibility constraints that must be applied to all requests in the project. |
Ensures proper placement of the workloads in a project and its cloud zones. |
If the same constraint or the same constraint category is specified in both the project, for example, |
PCA-VRA-CA-CFG-016 |
For each project, add one or more custom properties, for example, |
Custom properties can be used for provisioning or capturing additional metadata. For example, for reporting or extensibility actions. |
If the same custom property is specified in both the project, for example, |
PCA-VRA-CA-CFG-017 |
For each project, add a custom naming template to be used for virtual machine names provisioned in the project. |
The template provides a custom virtual machine name and does not affect the host name of the virtual machine.
Note:
Custom naming can also be managed using extensibility. |
The template substitutes auto-generated virtual machine names by using available properties, such as resource properties, custom properties, endpoint properties, project properties, and a random number with a specified number of digits. You must ensure that the template generates unique names for this project and between other projects. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CA-CFG-018 |
Create standardized flavor mappings based on a common taxonomy and deployment intent. |
Provides a simple, natural language naming to define common deployment size specifications. |
You must publish and communicate the updates to cloud template developers and consumers. |
PCA-VRA-CA-CFG-019 |
For each flavor mapping, add all applicable account regions. |
Provides a simple, natural language naming to define common deployment size specifications when used in a specific account region. |
You must maintain the mapping for any image mapping create or update operation. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CA-CFG-020 |
Use the vSphere content library to synchronize machine images across VI workload domains and VMware Cloud Foundation instances. |
|
|
PCA-VRA-CA-CFG-021 |
Create standardized image mappings based on similar operating systems, functional deployment intent, and cloud zone availability. |
You can create a simple taxonomy to map images to cloud templates. |
You must publish and communicate the image-mapping standards and updates to cloud template developers. |
PCA-VRA-CA-CFG-022 |
For each machine image in an image mapping, add a constraint tag, if applicable. |
Refines the machine image selection in an image mapping by matching constraints. |
You must manage multiple machine images in each account region based on the use of constraint tags in your organization. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CA-CFG-023 |
For each account region, add one or more network profiles based on network characteristics available for consumption. |
You can add networks with predefined characteristics that can be consumed during a deployment process. |
You must manage network profiles for each account region as updated across VMware Cloud Foundation instances. |
PCA-VRA-CA-CFG-024 |
For each network in a network profile, add one or more capability tags. |
You use capability tags to manage the workload network placement logic during the deployment process. |
You must manage capability tagging on each network profile for workflow placement selection during a deployment process. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CA-CFG-025 |
For each account region, add one or more storage profiles based on storage characteristics available for consumption. |
You can add storage with defined characteristics that can be consumed during a deployment process. |
You must manage storage profiles for each account region as storage is added, removed, and updated across VMware Cloud Foundation instances. |
PCA-VRA-CA-CFG-026 |
For each storage profile, add one or more capability tags. |
You use capability tags to manage the workload storage placement logic during the deployment process. |
You must manage capability tagging on each storage profile for the workflow placement logic during a deployment process. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-CA-CFG-027 |
Use the embedded on-premises functions-as-a-service (FaaS) provider in vRealize Automation for action-based extensibility. |
You can use the native vRealize Automation functions-as-a-service provider for the execution of lightweight actions through event subscriptions without the requirement for a public cloud account provider, such as Amazon Web Services Lambda or Microsoft Azure Functions. |
The use of action-based extensibility requires the vRealize Automation instance to have outbound access to the Internet to pull container images from publicly available Internet repositories, for example, to resolve any dependencies included in the actions. If vRealize Automation is deployed on an isolated network that does not allow outbound traffic to the Internet, an HTTP proxy must be configured and applied using the vracli proxy command option. |
Service Broker Design
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-SB-CFG-001 |
Add a cloud template content source for each Cloud Assembly project where cloud templates are authored and released. |
Provides the ability to share released cloud templates with project members or other projects. |
None. |
PCA-VRA-SB-CFG-002 |
Add an extensibility actions content source for each Cloud Assembly project where actions are authored and released. |
Provides the ability to share released actions with project members. |
None. |
PCA-VRA-SB-CFG-003 |
Add a vRealize Orchestrator workflows content source for each Cloud Assembly project, as required. |
Provides the ability to share specific workflows with project members. |
None. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-SB-CFG-004 |
For each shared content item, customize the form based on the catalog item and user experience requirements. |
You can create an intuitive user experience by using simple and discoverable forms that capture additional user inputs and in-form validations. |
Requires customization of request forms per catalog item. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-SB-CFG-005 |
Identify and apply goals for your organization and each project based on the applicability of available policy types. |
By understanding how the policies are processed, you can meet organizational goals without creating an excessive and unmanageable number of policies. |
For each policy type, you must determine the applicability and your organizational goals to design policy enforcement and scope that results in the desired effective policy. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-SB-CFG-006 |
Configure Service Broker to use an outbound (SMTP) mail server to route notifications for system events. |
vRealize Automation event notifications are provided by email for an enhanced user experience. |
You must configure an SMTP server to relay messages from vRealize Automation. |
vRealize Orchestrator Design
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-VRO-CFG-001 |
Register each VI workload domain vCenter Server instance with the embedded vRealize Orchestrator instance. Do not use per session authentication. |
Required for communication from the embedded vRealize Orchestrator to the VI workload domain vCenter Server instances. |
|
Information Security and Access Control Design
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-SEC-001 |
Limit the use of the local accounts for both interactive or API access and solution integration. |
Local accounts are not specific to user identity and do not offer complete auditing from an endpoint back to the user identity. |
You must define and manage service accounts, security groups, group membership, and security controls in Active Directory. |
PCA-VRA-SEC-002 |
Limit the scope and privileges for accounts used for both interactive or API access and solution integration. |
The principle of least privilege is a critical aspect of access management and must be part of a comprehensive defense-in-depth security strategy. |
You might need to define and manage custom roles and security controls to limit the scope and privileges used for interactive access or solution integration. |
PCA-VRA-SEC-003 |
Assign Active Directory user accounts to security groups following your organization's access policies |
Allows Active Directory security groups to be assigned to roles in SDDC components for streamlined management of access and administrative privileges. |
You must define and manage security groups, group membership, and security controls in Active Directory. |
PCA-VRA-SEC-004 |
Assign Active Directory security groups to default or custom roles, as applicable, for interactive or API access to solution components based on your organization's business and security requirements. |
|
|
PCA-VRA-SEC-005 |
Activate vRealize Automation integration with Active Directory by using the clustered Workspace ONE Access deployment. |
|
|
PCA-VRA-SEC-006 |
Assign vRealize Automation organization service and project roles to designated Active Directory. security groups synchronized to the clustered Workspace ONE Access deployment. |
By assigning Active Directory security groups to organization and service roles, you can simplify and manage user access to vRealize Automation based on the Active Directory security group membership. |
You must define and manage the security groups, group membership, and security controls in Active Directory for those directory services objects used by vRealize Automation. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-SEC-007 |
Define a custom vCenter Server role for vRealize Automation that has minimum privileges required to support a vCenter Server cloud account. |
vRealize Automation integrates with VI workload domain vCenter Server instances in VMware Cloud Foundation instances using the minimum set of privileges and permissions scope required to support the cloud account. |
|
PCA-VRA-SEC-008 |
For each VMware Cloud Foundation instance, use an Active Directory user account as a service account for each vCenter Server for application-to-application communication from vRealize Automation to vCenter Server. |
Provides the following access control features:
|
|
PCA-VRA-SEC-009 |
Assign vCenter Server global permissions for the vRealize Automation-to-vCenter Server integration accounts for each VMware Cloud Foundation instance. |
vRealize Automation accesses VI workload domain vCenter Server instances with the minimum set of permissions that are required to support a vCenter Server cloud account. |
|
PCA-VRA-SEC-010 |
Use an Active Directory user account as an integration account for each NSX Manager cluster for application-to-application communication from vRealize Automation to NSX-T Data Center. |
Provides the following access control features:
|
Important:
This solution is based on the use of Active Directory over LDAP with SSL used as the identity provider using Workspace ONE Access. If Active Directory Federation Services (ADFS) is used as an identity provider for NSX Manager, vRealize Automation cannot authenticate to an NSX Manager. A limitation exists where API-based logins to a system that uses a third-party identity provider, for example, ADFS with Workspace ONE Access. The username and password cannot be sent over SAML to the identity provider for authentication. |
PCA-VRA-SEC-011 |
Assign the NSX Manager Enterprise admin role to the vRealize Automation-to-NSX-T Data Center integration accounts for VI workload domains. |
vRealize Automation accesses designated VI workload domain NSX Manager clusters in VMware Cloud Foundation instances with the minimum set of permissions that are required to support NSX-T Data Center in the NSX Manager cloud accounts. |
You must configure and manage the integration of Workspace ONE Access with NSX-T Data Center.
Important:
This solution is based on the use of Active Directory over LDAP with SSL used as the identity provider using Workspace ONE Access. If Active Directory Federation Services (ADFS) is used as an identity provider for NSX Manager, vRealize Automation cannot authenticate to NSX Manager. A limitation exists where API-based logins to a system that uses a third-party identity provider, for example, ADFS with Workspace ONE Access. The user name and password cannot be sent over SAML to the identity provider for authentication. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-SEC-012 |
For each VMware Cloud Foundation instance, use an Active Directory user account as a service account for each VI workload domain vCenter Server for application-to-application communication from vRealize Orchestrator to vCenter Server. |
Provides the following access control features:
|
|
PCA-VRA-SEC-013 |
|
Allows only accounts defined in the Active Directory security group membership to administer the vRealize Orchestrator instance. |
You must define and manage security groups, group membership, and security controls in Active Directory. |
PCA-VRA-SEC-014 |
Create and apply a custom vSphere role for the service account used to add VI workload domain vCenter Server instances to the vRealize Orchestrator configuration. |
vRealize Orchestrator integrates with VI workload domain vCenter Servers instances using the minimum set of privileges required to support the vCenter Server registration. |
|
PCA-VRA-SEC-015 |
Assign vCenter Server global permissions for the vRealize Orchestrator-to-vCenter Server integration accounts for VMware Cloud Foundation instance workload domains. |
|
|
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-SEC-016 |
Change the vRealize Automationroot password on a recurring or event-initiated schedule by using the SDDC Manager user interface or API. |
|
By using SDDC Manager, you manage the password change or automation password rotation schedule for the vRealize Automationroot account in accordance with your organizational policies and regulatory standards. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-SEC-017 |
Use a certificate authority signed certificate containing the FQDNs of the vRealize Automation cluster nodes and the virtual server FQDN in the SAN attributes, when deploying vRealize Automation. |
Ensures that all communications to the externally facing vRealize Automation browser-based UI and API, and between the components, are encrypted. |
|
PCA-VRA-SEC-018 |
Use a SHA-2 or higher algorithm for certificate signing. |
The SHA-1 algorithm is considered less secure and has been deprecated. |
Not all certificate authorities support SHA-2 or higher. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-SEC-019 |
Import the certificate authority root certificate to the embedded vRealize Orchestrator instance in vRealize Automation. |
|
If the certificate authority certificate is reissued, you must import an updated certificate to the embedded vRealize Orchestrator instance in vRealize Automation. |
Solution Interoperability Design
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-MON-001 |
Configure the vRealize Automation integration in vRealize Operations Manager. |
|
You must manage the password life cycle of this endpoint. |
PCA-VRA-MON-002 |
Configure the vRealize Automation integration in vRealize Operations Manager to use the default collector group. |
Cross-instance components are configured to use the default collector group. |
The load on the analytics cluster, though minimal, increases. |
PCA-VRA-MON-003 |
Add an integration in Cloud Assembly for vRealize Operations Manager deployment. |
|
|
PCA-VRA-MON-004 |
Use the |
By default, the workload placement evaluation uses the vRealize Operations Manager recommendation. |
|
PCA-VRA-MON-005 |
Add a Ping adapter for the vRealize Automation cluster nodes. |
Provides metrics on the availability of vRealize Automation nodes. |
You must add the adapter instances manually. |
Design Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-MON-006 |
Assign the Organization Owner default role and the Cloud Assembly administrator service role to an enterprise directory service account user for the application-to-application communication from vRealize Operations to vRealize Automation. |
Provides the following access control features:
|
None. |
PCA-VRA-MON-007 |
Assign the ReadOnly role to an Active Directory user account as an integration account for the application-to-application communication from vRealize Automation to vRealize Operations Manager. |
Provides the following access control features:
|
Important:
This solution is based on the use of Active Directory over LDAP with SSL used as the identity provider using Workspace ONE Access. If Active Directory Federation Services (ADFS) is used as an identity provider for vRealize Operations Manager, vRealize Automation cannot authenticate to vRealize Operations Manager. A limitation exists where API-based logins to a system that uses a third-party identity provider, for example, ADFS with Workspace ONE Access. The user name and password cannot be sent over SAML to the identity provider for authentication. |
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VRA-LOG-001 |
Use the vRealize Log Insight content pack for vRealize Automation. |
|
None. |
PCA-VRA-LOG-002 |
Use the default configuration to transmit logs from vRealize Automation to the adjacent vRealize Log Insight in the VMware Cloud Foundation instance using the vRealize Log Insight ingestion API, |
|
The default configuration is unencrypted. To ensure that the transmission of logs between vRealize Automation and vRealize Log Insight is encrypted using SSL, you must update the default configuration for vRealize Automation to send logs to vRealize Log Insight using the ingestion API, For example, on the primary vRealize Automation cluster node, run the command See Configuring Log Forwarding to vRealize Log Insight in the vRealize Automation documentation. |
PCA-VRA-LOG-003 |
Use the vRealize Log Insight content pack for vRealize Orchestrator. |
|
None. |
PCA-VRA-LOG-004 |
Configure a dedicated agent group in the vRealize Log Insight cluster to include all FQDNs of the vRealize Automation cluster nodes. |
|
Adds minimal load to vRealize Log Insight. |