When you increase the volume of workloads and extend the compute and software-defined network infrastructure to accommodate this volume, you must consider how the operations and cloud management elements of the environment will scale to support this new topology.

Scaling vRealize Log Insight

When scaling vRealize Log Insight, consider the following items:

  • You should size your initial vRealize Log Insight deployment after a detailed analysis of the expected events-per-second.

  • You must use the calculator for vRealize Log Insight in VMware Knowledge Base article 60355 for configuring your system according to the analysis result.

  • As you scale the number of workloads and supporting physical infrastructure, the volume of events being sent to vRealize Log Insight will increase significantly. Consider using vRealize Log Insight forwarders in key locations to filter and forward events to the vRealize Log Insight cluster in the management domain.

    • Such locations might be at the cluster level, the workload domain level, or region level.

    • Include these forwarders in your building block design so that the ratio of forwarders to workloads remains the same as you expand.

  • This architecture supports full log analysis at the site of the vRealize Log Insight forwarders while still maintaining an aggregated view of the logs from the vRealize Log Insight cluster in the management domain.

  • Scaling the vRealize Log Insight architecture in this way minimizes the need to truncate data (or expand storage regularly) on the cluster located in the management domain because you forward only important filtered events to that cluster.

  • vRealize Log Insight can have a maximum of 10 forwarders.

  • A vRealize Log Insight aggregation cluster in the management domain can scale to a maximum of 12 nodes, that is, 1 primary and 11 worker nodes, and can be attached to a maximum of 15 vCenter Server instances per node.

  • A vRealize Log Insight node can ingest a maximum of 15000 events-per-second.

Scaling vRealize Operations Manager

When scaling vRealize Operations Manager, consider the following items:

  • As you scale the number of workloads and workload domains in your environment consider using additional vRealize Operations Manager remote collectors to scale in a predictable manner. Include these collectors in your building block design so that they extend in the same ratio as the workloads you deploy.

  • A Standard vRealize Operations Manager remote collector can manage metrics for 6,000 objects or workloads. At this point, you have the choice to change the specification of the remote collector, or to increase the number of collectors. If you increase the specification of the remote collector to 4 CPU and 16 GB RAM, then the collector can manage metrics for 32,000 objects.

  • Before increasing the specification of a remote collector, you must consider whether the infrastructure that the collector is running on can handle that extra traffic or whether to distribute the load among different collectors placed in individual workload domains.

  • You can configure vRealize Operations Manager collector groups to address only specified workload domains making it possible to extend the vRealize Operations Manager infrastructure in a predictable way by deploying new collectors for every workload domain you deploy.

  • You can link up to 60 remote collectors to a vRealize Operations Manager analytics cluster.

  • The default deployment of VMware Validated Design uses 3 analytics nodes of Medium specification supporting a total of 25,500 objects.

  • That cluster can expand to 8 nodes in size with a maximum of 68,000 objects. However, the best practice is to scale up before you scale out your analytics cluster because this is the most CPU efficient way of scaling the vRealize Operations Manager configuration.

  • Moving to 3 nodes of Large specification supports up to 49,500 objects and 3 nodes of Extra Large specification supports up to 120,000 objects.

Scaling vRealize Business

When scaling vRealize Business, consider the following items:

  • As you scale the number of workloads and workload domains in your environment, consider using remote data collectors to increase the number of workloads domains that vRealize Business can work with.

  • Data Collectors are suitable for remote regions because collection should be done by using an appliance on the same local network as the vCenter Server instance it is collecting from. Include such collectors in your building block construct for both local and remote scaling so that the collection performance for each workload domain you deploy is predictable.

  • The default deployment of a vRealize Business server uses 8 GB RAM and supports up to 10,000 workloads.

  • By increasing the memory available to a vRealize Business server to 12 GB, vRealize Business can support of up to 20,000 workloads.

  • By increasing the memory available to a vRealize Business server to 16 GB, vRealize Business can support of up to 30,000 workloads

  • Because vRealize Business is a reporting tool, churn rate (the rate at which workloads are provisioned and decommissioned within the environment) impacts the number of workloads that vRealize Business must be sized for.