OpenStack Series Chapter4: Identifying shared services and VNC

Shared Services Overview

Service	Description
MariaDB	A relational database.
Redis	An in-memory key-value data store.
memcached	A distributed memory cache.
Pacemaker	Clustering software.
Ceph MON and MDS	The Ceph cluster monitor, and Metadata Server.
NoVNC and Spice	Both provide a remote console for instances.

MariaDB

MariaDB is an open-source edition SQL database and it’s compatible with MySQL database.

It allows all components to store information.

In the controller node, the method is MariaDB Galera. It provides multi-master replication mode to confirm the stable status, all nodes are the master.

+----------+     +----------+     +----------+
|  Node A  | <-->|  Node B  | <-->|  Node C  |
+----------+     +----------+     +----------+
      ^                              ^
      |                              |
      +-------- Client -------------+

The Features of MariaDB Galera:

• Multi-Master Replication

  • All nodes can perform read and write operations simultaneously.

  • Real-time data synchronisation (synchronous replication, not asynchronous) ensures strong consistency.

• Strong Consistency (Synchronous Replication)

  • Uses write-set replication: a write operation is considered successful only after all nodes have reached consensus.

• Automatic Membership Management and Failover

  • Nodes can automatically join or leave the cluster.

  • A single node failure does not render the entire database unavailable.

• No Single Point of Failure (Theoretically)

  • As long as the majority of nodes (typically N/2 + 1) remain operational, the cluster can continue to function.

  • All nodes act as primary nodes, with strong data synchronisation between them.

Type	Synchronous	Granularity	Characteristics	Common Use Cases
Statement-based (SBR)	Asynchronous	SQL statements	Fast but may lead to inconsistencies	MySQL
Row-based (RBR)	Asynchronous	Row-level	Good consistency, high data volume	MySQL
Mixed-based	Asynchronous	Auto-switching	A compromise between SBR and RBR	MySQL
Write-set	Synchronous	Transaction write-set	Strong consistency, multi-master	Galera Cluster
Logical	Sync/Async	Table/statement-level	Highly flexible	PostgreSQL
Physical	Synchronous	Binary data	High performance but less flexible	PostgreSQL, Oracle, etc.

Redis

Redis is a high-performance in-memory key-value data store.

It can store several types of data structures, such as strings, lists, sets, sorted sets, and hashes.

Compared with traditional database, Redis uses memory to store data. Therefore, keeping all data in memory increases performance.

What’s more, Redis supports to save data to disk as well.

Memcached

Memcached is similar to Redis, it provides an in-memory cache for ephemeral data.

However, Memcached does not support the persistent storage in disk, it does not support various kinds of data structure(only key-value string).

It’s used more in keystone, nova, oslo and so on.

Pacemaker

Pacemaker service manages core containers and services, such as Galera, RabbitMQ, Redis, and HAProxy.

It could monitor services as well as allocate the defected services to an available node, switch to a new node or restart the service.

Ceph MON and MDS

MON and MDS are two core components for Ceph.

MON is responsible for monitorting the status of the whole ceph cluster.

MDS looks like a map which manages and stores the meta data, it records the configuration information.

NoVNC and SPICE

OpenStack supports two protocols for providing remote virtual console access: VNC(Virtual Network Computer) and SPICE(Simple Protocol for Independent Computing Environments).

• noVNC

  noVNC is comprised of a JavaScript library and an application that runs in desktop and mobile browsers using HTML5 and WebSockets.

  It is a VNC client based on web, it is convenient for users to visit the virtual machine desktop by browser.

• SPICE

  SPICE provides more advanced features than existing VNC clients.(audio or vedio)

  Red Hat recommends that you use a standalone SPICE client to access OpenStack instances from the private management network.

Using VNC to Access an Instance Console

Because all virtual machines are generated on the compute node, each compute node runs a vncserver process, listening on the internal API network on one or more ports, starting at 5900 and increasing, depending on the number of instances deployed on that compute node.

Each controller node runs a novncproxy process, listening on port 6080 on the same internal API network.

The remaining services belong to the Compute Service (Nova) with components on both the controller and compute nodes.

VNC Process Flow for Accessing an Instance Console:

1. Users make a request from browser.

   Users open a browser and use the NoVNC plugin, call the nova-api (the main controller of OpenStack, residing on the controller node and listening on port 8774) to connect to the virtual machine. At this point, OpenStack’s Dashboard (the management interface) forwards the request via HAProxy (a highly capable traffic coordinator located on the controller node, using port 80).

2. Nova API passes the request.

   Nova-api passes a get_vnc_console request to nova-compute (compute, internal_API,AMQP).

3. Nova-compute ask libvirt.

   nova-compute passes the get_vnc_console request to libvirt (compute) to locate the VM’s attributes.

4. libvirt generates a token.

   libvirt generates a token from the VM’s UUID and returns the token to nova-compute (compute, internal_API, AMQP).

   The token is like the ID-card of the VMs.

5. Nova-compute returns the token to Nova API.

   nova-compute returns the generated token and a connect_info object to nova-api (controller, internal API, AMQP).

6. Nova API asks Nova-consoleauth to authorize.

   nova-api passes an authorize_console request to nova-consoleauth (compute, internal API, AMQP), which caches the connect_info object, using the token as the index, for future use when the actual connection request occurs.

7. Nova API tells the browser.

   nova-api also returns a nova-novncproxy URL and the instance-specific token to the browser (workstation, external).

8. Browser visit the nova-novncproxy by haproxy.

   The browser (workstation, external) connects to the URL, proxied by the dashboard haproxy (controller, external, port 6080) to reach nova-novncproxy (controller, internal API, port 6080).

9. Nova-novncproxy parses the token.

   nova-novncproxy obtains the request and then it parses the token and instance ID from the URL and passes it to nova-consoleauth (controller, internal API, AMQP) to verify.

10. Nova-consoleauth gives the feedback.

    Using the token, nova-consoleauth retrieves the connect_info object from the cache and returns it to nova-novncproxy (controller, internal API).

11. Nova-novncproxy connects to the VNC server.

    nova-novncproxy connects directly to vncserver (compute, internal API, 5900+) at the port designated for the requested VM and creates a reverse proxy configuration by using connect_info.

12. The graphic web UI will be sent to the browser.

    nova-novncproxy sends the console graphics back through the dashboard haproxy to the user’s browser (workstation, external).