HTTPS Support for BVQ Server and Grafana

With this release native HTTPS support has been added to the BVQ Server and Grafana to secure all common communication.

The HTTP(S) settings are configured during the installation process and allows the following setups:

1. Plain HTTP without encryption
2. HTTPS with self-signed certificate (browsers may complain about untrusted connection)
3. HTTPS with own company certificate

HTTPS setup instructions

New Platform: Kubernetes (2023.H1.1)

Brief description

BVQ now supports a "Kubernetes system" (K8s) as a new platform. 

For the first release allows the use of all BVQ features to:

• • Find and monitor performance issues for nodes and workloads
  • Analyze End to End views with VMware, NetApp and Kubernetes. (More will be added)
  • View configurations for different components
  • Flexible Alerting for performance and configuration issues

Licensing

The Kubernetes plattform is licensed based on node RAM size.

If the cluster ist virtualized on VMware and the vCenter ist already licensed, no additional costs are charged for the Kubernetes platform.

See BVQ° License Entitlements

Information gathering

To collect all relevant information bvq uses two different sources:

1. Kubernetes API 
   Used to collect topology information
2. Prometheus with node exporter
   Used to collect performance data an additional topology information.
   Therefor a minimal, custom prometheus has to be depolyed into the cluster

Which information is collected?

• Topology configuration information
  • collected every 15 minutes (default)
  • 44 object types containing a total of ~750 attributes
• Performance statistics
  • collected every  minute (default)
  • 7 objects types containing a total of ~150 performance statistics

Additional information:

• See Supported Kubernetes versions  for more information about which versions are supported.
• Kubernetes preparation
• See Scanner for more information about BVQ Scanner configuration.

Object types

Several new object types come along with the BVQ Kubernetes platform. The following table provides an overview of those new object types, their meaning and whether they offer performance information:

Group	BVQ Name	Description	Perf OT?
Cluster wide	K8s Cluster	The BVQ Cluster object is the master grouping object. It is created from a Custom Resource Definition (CRD) to identify the Kubernetes cluster.
	K8s Namespace	Namespaces provides a mechanism for isolating groups of resources within a single cluster.
	K8s Node	Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the control plane and contains the services necessary to run Pods.
	K8s Node role	Object to specify the role a node has. A node can have multiple roles at once.
	K8s Node Disk	Node storage volume
	K8s Node filesystem	Node filesystem
	K8s Node logical CPU	Logical processor in a Kubernetes node
	K8s Node network adapter	Virtual or physical node network adpater
	K8s Image	Container images stored on at least one node
Workload	K8s Workload	BVQ object to group ReplicaSet, StatefulSet, DaemonSet and Jobs for a more general view
	K8s Deployment	A Deployment provides declarative updates for Pods and ReplicaSets.
	K8s ReplicaSet	A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.
	K8s StatefulSet	Manages the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods. Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of its Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
	K8s DaemonSet	A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.
	K8s Job	A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate
	K8s CronJob	A CronJob creates Jobs on a repeating schedule.
	K8s Pod	Pods are the smallest deployable units of computing that you can create and manage in Kubernetes. A Pod is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers
	K8s Pod network adapter	Pod network adapter
	K8s Container	Smallest workload instance controlled by a Pod.
	K8s Container disk	Virtual disk, accessable from the container
	K8s Container port	Network port to access the container
Configuration	K8s ConfigMap	Object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume. A ConfigMap allows you to decouple environment-specific configuration from your container images, so that your applications are easily portable.
	K8s Secret	Object that contains a small amount of sensitive data such as a password, a token, or a key
Storage	K8s Storage class	Provides a way for administrators to describe the "classes" of storage they offer. Different classes might map to quality-of-service levels, or to backup policies, or to arbitrary policies determined by the cluster administrators
	K8s Persistent volume	A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV.
	K8s Persistent volume claim	A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes.
	K8s Volume	A Volume represents a directory with data that is accessible across multiple containers in a Pod.
	K8s Volume mount	Represents how a volume is mounted to a specific container
	K8s CSI Driver	The Container Storage Interface (CSI) for exposing arbitrary block and file storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes
	K8s CSI node driver	Object which CSI driver is available on which node
	K8s PV attatchment	Volume Attachment captures the intent to attach or detach the specified volume to/from the specified node.
Service	K8s Ingress	Object that manages external access to the services in a cluster, typically HTTP
	K8s Ingress rule	Object for special routing details.
	K8s Ingress rule path	Object to represent the path defined for a Ingress rule
	K8s Ingress TLS	K8s Ingress TLS
	K8s Service	A Service is a method for exposing a network application that is running as one or more Pods in your cluster.
	K8s Service port	Represents the port mappings for a service
	K8s Endpoint slice	An EndpointSlice contains references to a set of network endpoints. The control plane automatically creates EndpointSlices for any Kubernetes Service that has a selector specified. These EndpointSlices include references to all the Pods that match the Service selector. EndpointSlices group network endpoints together by unique combinations of protocol, port number, and Service name
	K8s Endpoint	An Endpoint defines a list of network endpoints, typically referenced by a Service to define which Pods the traffic can be sent to.
Policy	K8s Ressource quota	A resource quota provides constraints that limit aggregate resource consumption per namespace. It can limit the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that namespace.
	K8s Limit range	A LimitRange is a policy to constrain the resource allocations (limits and requests) that you can specify for each applicable object kind in a namespace.
	K8s Limit range entry	Represents the individual constrains defined in a Limit range

Object relations

The following graphs show the Kubernetes object types and their connections to existing BVQ platforms:

Predefined Web Dashboards

State 2023.H1.1

With the GA Release a set of 6 Kubernetes dashboards will be available for different use cases:

Predefined reports

Coming soon... Not yet available (2023.H1.1)

Refined Brocade SAN

Background

Virtual fabrics is a Brocade feature that is widely used. With the previous implementation of Brocade in BVQ, one scanner per virtual fabric had to be configured. Every scanner opens (and closes) its own SSH session to the scanned switches. Since the number of SSH sessions is limited to 3 by default (but can be increased up to 10), this often caused temporary data collection issues. With the new implementation all virtual fabrics in a SAN are discovered in a single scanner configuration preventing this issue from happening.

Impact

During the upgrade to BVQ 2023.H1.0, all data related to Brocade (BNA & REST) will be deleted without further notice. 

The following data will be lost after the upgrade:

• Brocade scanner configurations
• Brocade topology and performance data
• Brocade alert rule results

Required Actions

After upgrade to BVQ 2023.H.1.0 or higher, Brocade scanners need to be configured again.

While previously one scanner per Virtual Fabric had to be configured, now only one scanner per SAN is required. A SAN defines all Brocade switches that are in the same fabric or are reachable by any virtual fabrics that might exist.

Example:

• SAN A consists of switch1, switch2 and switch3. Switch1 and switch2 have two virtual fabrics configured →  all 3 switches including their virtual fabrics are covered in one scanner configuration

Note: 
If predefined Brocade alert rules were enabled prior to the BVQ update, they will be automatically enabled again after the new Brocade scanner configurations are saved and successfully persisted for the first time. 

HMC Group scanner

Background

Typically, HMCs are configured redundant which means that there are two consoles managing the (more or less) same set of IBM Power Systems. Up to this release, BVQ only supported to collect data from one of those HMCs. This means, in case of a failure or planned downtime of this HMC, no more data could be collected.

In BVQ 2023.H1.0 it is now supported to add both HMCs to the same scanner configuration. The one that is defined first acts as the primary data collector, the one that is defined secondary takes over in case the primary fails.

Impact

During the upgrade to BVQ 2023.H1.0 or higher, all data related to PowerVM will be deleted without further notice. 

The following data will be lost after the upgrade:

• PowerVM scanner configurations
• PowerVM topology and performance data
• PowerVM alert rule results

Required Actions

After upgrade to BVQ 2023.H.1.0 or higher, PowerVM scanners need to be configured again.

VMware LAN integration

To complete the VMware vSphere plattform, the vLAN stack was added.

Which information is collected?

• Topology configuration information
  • collected every 60 minutes (default)
  • 5 new object types containing appr. 120 attributes
• Performance statistics
  • collected every five minutes (default)
  • 1 new object type containing appr. 20 performance metrics
• 20 new alert rules are predefined

New object Types

Object model

Scanner notifications

In case of problems with a scanner configurations, BVQ is no longer able to collect data from the specified system(s). Up to now, those issues went unoticed unless an administrator logged into BVQ and noticed the problem. In this release of BVQ, the already existing notification feature has been enhanced and now allows the monitoring of scanner configurations.

To create a scanner notification, open the corresponding scanner configuration. Each one has a new section where optionally notifications can be configured:

• Choose a notification type. These are the ones that are configured in Administration > Notifications
• Configure the frequency of the notifications

Go to Administration > Notifications to see a list of scanner configurations that have notifications enabled and configured.

Scanner notifications can be edited or disabled in two ways:

• Go to Scanner, open the scanner configuration that needs to be edited and change/disable notifications
• Go to Administration > Notifications, navigate to Scanner Configuration Notifications and edit or pause the notification

Latex based BVQ Reporting layout

The transition from the AsciiDoc-based reporting engine to a LaTeX backend in BVQ brings several significant advantages. By leveraging LaTeX, the reports in BVQ gain a fresh and modern layout, resulting in an improved visual experience for users.

LaTeX is widely recognized and used in scientific and technical document communication and publication. Its extensive feature set and cross-platform capabilities enhance the quality and versatility of the reports generated by BVQ.

One key benefit of this transition is that the report snippet system has been retained, allowing customers to seamlessly continue using their custom reports. This ensures compatibility with existing reports created using AsciiDoc, preserving the investment made in building custom reports. At the same time, users can take advantage of the enhanced capabilities and flexibility offered by LaTeX.

Therefore a couple of new features are now available:

• HTML output format has been replaced with a zip file. This zip file contains the report in the tex format, making it easy for users to edit and render it into a PDF. This zip file also includes all the necessary images in svg format, streamlining the report generation process.

• Now you can add your own company’s logo to the report, simply by uploading the image in the reporting configuration section.
  

• A new snippet type "LaTeX code" has been added to insert raw LaTeX code

To simplify the setup process, the BVQ installer now includes the installation of MiKTeX and Inkscape. This eliminates the need for users to install any additional software, making the setup more convenient and straightforward.

Overall, the transition to LaTeX in BVQ empowers users to create more visually appealing and customizable reports while benefiting from the extensive capabilities of LaTeX as a standard in scientific and technical documentation.

RAM based Compute layer licensing

See BVQ° License Entitlements