Photo by Michaela Filipcikova on Unsplash

Photo by Michaela Filipcikova on Unsplash

OpenStack observability with Sovereign Cloud Stack

Guard Duty

Article from ADMIN 72/2022
By
Operators of an OpenStack environment need to know whether the environment is working and quickly pinpoint problems. We look at the basics of OpenStack observability in the Sovereign Cloud Stack.

The Open Source Business Alliance (OSBA) Sovereign Cloud Stack (SCS) project was launched in 2019 to enable federation-capable cloud environments. In close collaboration between the community and OSBA's SCS team, the project uses an agile approach to create the appropriate standards and a reference implementation. SCS [1] is an open, federation-capable modular cloud and container platform based on open source software. It builds on proven open source components such as OpenStack and Kubernetes in the reference implementation (Figure 1). As a platform, SCS provides the foundations for creating offerings that deliver full digital sovereignty.

Figure 1: Visualization of the relationships between Sovereign Cloud Stack components.

SCS Community

The community comprises a wide variety of cloud service providers (CSPs) and their employees, people from the OpenStack community, and companies working on deliverables that are awarded through open tenders. Collaboration between the different providers creates a level of cooperation that rarely exists elsewhere. Various teams and special interest groups (SIGs) work together on the topics, coordinating standards and requirements in terms of content. The primary goals of SCS are for teams to take an active part in the respective upstream projects, to be involved in the creation of content, and not to allow a parallel world to develop.

The first such group to be formed out of the Operations and Identity and Access Management team was the Monitoring SIG, which is dedicated to the topics of monitoring and observability.

Observability

Observability does not just mean plain vanilla state analysis (i.e., information on whether or not a service feature is available). Monitoring in line with contemporary standards also includes collecting, storing, and visualizing metrics and aggregating log messages. The overall system enables the operator to get a comprehensive picture of their system to locate problems, their origins, and causes quickly.

In the CSP environment, additional requirements to delete accruing data are based on appropriate specifications. Additionally, for compliance reasons, certain system messages need to be logged or billing data generated from the metrics that occur.

Architecture

When the SIG was founded a year ago, it first collected the requirements of the participating CSPs and contrasted them with the individual components already covered in the reference implementation.

To avoid getting lost in discussions relating only to the tool right from the outset, the first step was to take a tool-agnostic look at the architecture. Figure 2 shows the intended architecture. First, the various roles were defined. The SCS Operator is the system operator (e.g., the CSP), whereas the SCS Integrator describes the companies that assist the operator in setting up and commissioning the system, if needed.

Figure 2: The tool-agnostic architecture of SCS.

For several reasons, the developers made a deliberate decision to ignore the container layer in the first step and focus instead on the infrastructure-as-a-service (IaaS) layer. On the one hand, this approach reduced complexity and the number of decisions. On the other hand, observability was part of an award package that was not scheduled until 2022. At the IaaS level, the focus is on OpenStack with its various components (Figure 3).

Figure 3: The IaaS monitoring components of SCS.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Bare metal deployment with OpenStack
    Automating processes in the age of the cloud is not just a preference, but a necessity, especially as it applies to the installation and initial setup of compute nodes. OpenStack helps with built-in resources.
  • Combining containers and OpenStack
    The OpenStack cosmos cannot ignore the trend toward containers. If you want to combine both technologies, projects like Magnum, Kolla, and Zun come into play. Which one?
  • The state of OpenStack in 2022
    The unprecedented hype surrounding OpenStack 10 years ago changed to disillusionment, which has nevertheless had a positive effect: OpenStack is still evolving and is now mainly deployed where it actually makes sense to do so.
  • Questions about the present and future of OpenStack
    OpenStack has been on the market for 12 years and is generally considered one of the great open source projects. Thierry Carrez and Jeremy Stanley both work on the software and provide information about problems, innovations, and future plans.
  • Alternative virtualization solutions when OpenStack is too much
    OpenStack is considered the industry standard for building private clouds, but the solution is still far too complex and too difficult to maintain and operate for many applications. What causes OpenStack projects to fail, and what alternatives do administrators have?
comments powered by Disqus