Month: July 2020

vRealize Operations and Logging via CFAPI and Syslog

Without any doubt configuring vRealize Operations to send log messages to a vRealize Log Insight instance is the best way to collect, parse and display structured and structured log information.

In this post I will explain the major differences between CFAPI and Syslog as the protocol used to forward log messages to a log server like vRealize Log Insight.

The configuration of the log forwarding in vRealize Operations is straight forward. Under “Administration” –> “Management” –> “Log Forwarding” you will find all options to quickly configure vRLI as target for the selected log files.

The following figure shows how to configure vRealize Operations to send all log messages to vRealize Log Insight using the CFAPI protocol via HTTP.

Figure 1: Log Forwarding configuration

The CFAPI protocol, over HTTP or HTTPS, used by the vRealize Log Insight agent provides additional information used by the vROps Content Pack. The extracted information flows into the various dashboards and alert definitions delivered through the Content Pack. Following picture shows one of the available dashboards populated with available data when using CFAPI and vRLI.

Figure 02: vROps Content Pack

In case you (for whatever strange reason) cannot use CFAPI, you can configure vROps to use Syslog. It is as simple as selecting Syslog as the protocol option in the configuration page shown in the following picture.

Figure 03: Syslog as configured protocol

The drawback of using Syslog here is that the additional information parsed by the agent and used by the content pack will no longer be available and you will need to create your own extracted fields in vRLI to parse data from the log messages.

In the next both pictures you can see the empty dashboards and log messages without any vROps specific fields in the interactive analytics .

Figure 04: Empty dashboards when using Syslog
Figure 05: Missing vROps specific fields when using Syslog

It is important to know that vROps is using Syslog over TCP when configured via UI as shown in figure 03.

But what if you are forced to use Syslog over UDP?

There is no such option in the UI but since vROps is using the regular vRLI agent, there has to be a way to configure it to use UDP instead of TCP.

The vRLI config file explains how to set the according option:

Figure 06: liagent.ini config file

You can just replace

proto = syslog

with

proto = syslog_udp

restart the agent

service liagentd restart

and your vROps nodes starts to forward log messages to your log server using UDP.

I have setup a fake log server listening on 514 UDP using netcat:

Figure 07: Syslog over UDP in NC

If you configure the vRLI agent in vROps directly via the config file, please keep in mind:

  • that you are using a function which is not officially supported by VMware
  • you will need to make such manual changes on every node
  • you will need to monitor any changes to that file which can be triggered via the UI or vROps updates

Stay safe.

Thomas – https://twitter.com/ThomasKopton

ESXi Cluster (non-HCI) Rightsizing using vRealize Operations

vRealize Operations with its four main pillars:

  • Optimize Performance
  • Optimize Capacity
  • Troubleshoot
  • Manage Configuration

provides a perfect solution to manage complex SDDC environments.

The “Optimize Performance” part of vRealize Operations provides a wide range of features like workload optimization to ensure consistent performance in your datacenters or VM rightsizing to reduce bottlenecks and ensure best possible performance of your workloads.

The vROps capability to identify over- and undersized VMs and conduct the required operations to adjust the configuration of VMs is one of the well-known features, accessible directly form the UI.

Figure 1: VM Rightsizing

But what if you would like to rightsize your ESXi Clusters? What information and features is vRealize Operations providing in this area?

What-If Analysis for Clusters

The What-If Analysis feature in the “Optimize Capacity” area is a quick and simple way to check the impact additional workloads or removing of workloads will have in the capacity of an ESXi traditional or HCI cluster.

You can also run infrastructure centric scenarios, like removing or adding hosts from/to clusters.

Figure 2: What-If Scenarios

These are all great features supporting proper capacity and performance management.

But how can you determine if your clusters are configured correctly from the available capacity point of view? What if you have a significant number of clusters? You probably do not want to run the scenarios for every and each cluster over and over again to get updated information.

vRealize Operations is providing all needed information to have a quick and up-to-date insight into your environment allowing you take all necessary actions to adjust the sizing of your ESXi clusters and optimize your SDDC.

Recommended CPU, Memory and Disk Space Metrics

vRealize Operations is constantly calculating recommended values for CPU, Memory and Disk Space based on the configured capacity models, Demand and Allocation if activated. The recommended capacity calculation takes into account vROps Buffers, allocation ratios and Admission Control settings giving you a fairly reliable indication on how to size your clusters.

Figure 3: Recommended Size Metrics

These metrics can be used to calculate the actual number of ESXi host which could be safely removed from the cluster or how many hosts need to be added to cope with the projected demand.

Cluster Rightsizing Dashboard

The Dashboard and all required components can be downloaded from VMware Code page:

https://code.vmware.com/samples?id=7407#

My simple dashboard will give you detailed insights into the utilization and capacity of your clusters.

It will also provide recommendations regarding the optimal size of the cluster, which will help improve the efficiency of your environment.

This first version of the dashboard is limited to traditional clusters (non-HCI like vSAN clusters).

Even if it shows all clusters (a filter will be added in the next version), please do not shrink vSAN clusters using information provided by this dashboard.

Only CPU and Memory Demand metrics are processed to conduct the rightsizing.

Before removing ESXi host from a cluster I highly recommend putting them into maintenance mode for some period of time and assess performance of the workloads. Additional What-If analysis based on the numbers provided by the dashboard helps get confidence in uncertain situations.

In addition to the metrics provided out-of-the-box we need few Super Metrics to calculate the actual number of hosts to add/remove. It is important to note that the calculation is working properly for uniform clusters. That means same sizing of ESXi host within a cluster, same CPU speed and number of cores, same memory configuration.

Figure 4: Super Metrics

The list view used in the dashboard displays all clusters in the selected vSphere Datacenter.

In the last column you will see the number of ESXi host you either should add to the cluster to ensure sufficient capacity or you could potentially remove from the cluster.

Figure 5: Simple Cluster-Rightsizing Dashboard

Before you start removing hosts from clusters, you can also run a What-If scenario to check the remaining capacity and the capacity projection.

In my example the dashboard is indicating that I could remove one host from the wdcc02 cluster.

Figure 6: What-If scenario settings

If we run the scenario, we see that from the demand perspective the cluster is still providing sufficient capacity to run the current workloads.

Figure 7: Scenario results

Happy rightsizing and stay safe.

Thomas – https://twitter.com/ThomasKopton