Hybrid decentralized PBFT Blockchain Framework for OpenStack message queue

Cloud computing based on OpenStack is widely used as a distributed computing platform. OpenStack has progressed at a rapid pace, incorporating a variety of service modules; it is supported by many companies, has a community of active developers, and a diverse user base. OpenStack uses message queue to coordinate and exchange operation and status information between services. OpenStack supports various message queue services including RabbitMQ, Qpid, and ZeroMQ, whereas its distribution architecture uses RabbitMQ. As an OpenStack’s message queue service, RabbitMQ runs on a controller node as a centralized service. In case of the centralized service, increased usage may cause slowed response times and security vulnerability. This paper proposes a Hybrid decentralized Practical byzantine fault tolerance Blockchain Framework with two-step verification for OpenStack message queue service. When compared to existing OpenStack message queue service, OpenStack with the proposed framework demonstrates identical reliability a faster response time by approximately 46.75% with a two-step verification process and decentralization approach. Additionally, a reduction in the security vulnerability in the OpenStack message queue information with saving the message queue information into each node by blockchain-based decentralized data duplication approach.

The OpenStack message queue service based on RabbitMQ, which is a centralized approach service, has to cope with performance degradation problem as all the information is saved in the message queue of the controller node; additionally, the requests for checking, exchanging, and coordinating information related to the operation and status of the components are present in the message queue server of the controller node.
Blockchain [9], a decentralization approach, can be used to improve the performance speed by distributing requests for checking, exchanging and coordination that comprise the OpenStack message queue service, while reducing the security risk with the data duplication approach [10]. However, this approach has difficulty processing the information that is updated in real time; this is because of the transactions problem [11] that occurs due to the overhead of the consensus algorithm of the blockchain technology.
The OpenStack message queue service based on a Hybrid decentralized Practical byzantine fault tolerance Blockchain Framework (HdPBF) with a two-step verification approach is proposed in order to improve the processing speed of the OpenStack message queue service, by distributing requests using blockchain and reducing the security risks with the data duplication approach. The practical byzantine fault tolerance (PBFT) Blockchain Framework is based on the PBFT algorithm [12], which is an asynchronous [13] algorithm among the consensus algorithms of the blockchain approach, to efficiently process transactions and ensure reliability by double-checking the information with the message queue server. Despite the quick processing speed of the PBFT algorithm, delay in results may occur due to large volumes of requests and delay in real-time syncing of the blockchain peer.
The proposed scheme can ensure reliability of the message queue service, which is a basic component of OpenStack, through a two-step verification approach, which is a combination of the centralization and blockchain-based decentralization approach. The first step is performing the decentralization approach query; this query checks the information with the HdPBF peer, and in case there is no information, centralization query is performed to check the information with the message queue server as the second step. This method improves the performance by distributing requests for the message queue information to each node through the blockchain based decentralization approach and reduces the security risk associated with the message queue information by saving the message queue information into each node.

OpenStack message queue service
The concept of the message queue operation, which is a centralization approach service, is shown in Fig. 1 [14].
The publisher creates exchanges of Direct, Topic or Fanout, and the consumer creates individual queues for use, which are binding to the exchange.
The structure of the OpenStack message queue service and the OpenStack services based on the RabbitMQ, which is the default message queue service of OpenStack distributions, is shown in Fig. 2 [15].
Services such as Nova, Cinder, Glance etc., which are OpenStack services, check, exchange and coordinate the information related to operation and status of services through the message queue associated with each service.
The entire composition and flow of the OpenStack services and message queue service based on the RabbitMQ is shown in Fig. 3 [16].
If a request from a client using the OpenStack was generated, after the process of authorization of the OpenStack is completed, the resource of nodes through the API of each service is used, and each service and node checks, exchanges, and coordinates information related to the operation and status through the message queue [17].   One of primary operating procedures of Nova, which is a core component of the OpenStack service, is the message queue service based on the RabbitMQ of the Open-Stack, with an example that an OpenStack user requests the vnc-console of the instance that is already created, is shown in Fig. 4.
The operating procedure of the message queue service based on the RabbitMQ of the OpenStack in Fig. 4 is described below in steps 1 to 7.

1.
A client requests the vnc-console of the instance. 2. The nova-api makes the RPC call through the nova-rpcapi. 3. The nova-rpcapi sends the RPC call to execute the get-vnc-console at the novacompute that has the requested instance and becomes a block status until the return value of the connect_info is received. 4. The RPC call message of the nova-rpcapi is delivered to the nova-compute through the RabbitMQ. 5. The nova-compute returns the result of execution through the RabbitMQ. 6. The nova-rpcapi returns the connect_info to the nova-api. 7. The nova-api returns the connect_info to the client.
When a user issues a request to the vnc-console of the instance, the nova-api makes a request to the nova-rpcapi for the RPC call, and the nova-rpcapi issues the get-vncconsole call message into the message queue, and waits for the result. The nova-compute returns the connect_info of the message queue, which is the result of executing the getvnc-console to the nova-rpcapi, and the nova-api returns the connect_info to the client.
Based on the operating procedure shown in Fig. 4, requests for checking, exchanging and coordinating the operating related information and the status information of services through the message queue are present on the message queue server, which is a centralized approach service. A performance degradation problem is experienced in case a large volume of requests are generated.

PBFT Blockchain Framework
The Blockchain Framework in this paper divided version 0.6 of the Hyperledger Fabric based on PBFT and upgraded the RocksDB [18], which is the backend to the version 5.17.2, and realized the PBFT Blockchain Framework that upgraded Go [19], which is  The peer of the PBFT Blockchain Framework is divided into one leader that is elected from the validating peers and non-validating peers, and the validating network follows a procedure similar to the block creation based on the existing PBFT Algorithm comprising validating peers and a leader that participate in the agreement process of Fig. 5, while the non-validating peer is excluded from the agreement process [20].

HdPBF for OpenStack message queue
The entire structure and flow of the OpenStack service and the message queue service containing the HdPBF realized on the basis of the PBFT Blockchain Framework is shown in Fig. 6.
Crucial Information for operation within the message queue is saved into the HdPBF peer, and each node that is the individual HdPBF peer synchronizes the saved information with the HdPBF peers. The detailed structure and flow is shown in Fig. 7.
In case of a large volume of requests for information, synchronization between HdPBF peers may be delayed due to overhead based on the consensus algorithm of the blockchain approach. In such cases, the information is checked by local query to the HdPBF peer as the first step, and in case there is no result, the information is checked by query to the centralized message queue server as the second step. The same reliability as the one from the existing message queue service can be ensured through this two-step verification approach. In case an OpenStack client sends a request initially, the information that is not synchronized with HdPBF peer comprising HdPBF is created in the message queue of the OpenStack. For the information created only in the OpenStack message queue and not synchronized, the HdPBF ensures reliability by performing the two-step verification. The HdPBF peers are synchronized for the corresponding information. The operating procedure of the OpenStack message queue service, which comprises HdPBF is shown in Fig. 8. As one of principal operating procedures of Nova, the twostep verification is executed, with an example of the case that a user of the OpenStack requests the vnc-console from the instance of the information that is already created initially and synchronization between HdPBF peers is completed.
The operating procedure of the OpenStack message queue service comprising HdPBF that executes the two-step verification shown in Fig. 8 is described below from steps 1 to 7. In case of no returned information, 2c is executed. 2c. The information on connect_info is requested to the nova-compute through the nova-rpcapi, which is the RPC API. 3. The nova-rpcapi sends the RPC call to execute the get-vnc-console to the nova-compute that has the requested instance and assumes a block status until the connect_ info is returned. 4. The RPC call message of the nova-rpcapi is delivered to the nova-compute through the RabbitMQ. 5a. The nova-compute synchronizes the result of execution through HdPBF. 5b.
The nova-compute returns the result of execution through the RabbitMQ. 6. The nova-rpcapi returns the connect_info to API. 7. The nova-api returns the connect_info to the client.
In the case of a first time request sent by an OpenStack client, the operating procedure of the OpenStack message queue service comprising HdPBF is shown in Fig. 9, with an example of the case in which connect_info is created based on the initial call made by a user of the OpenStack, on the condition that the information between HdPBF peers is synchronized after completing the procedure in Fig. 8 and the vnc-console of the instance that is already created is requested again.
The operating procedure of the OpenStack message queue service comprising HdPBF shown in Fig. 9, in which the nova-api checks the information with itself as the HdPBF peer based on the request of a client is described below in steps 1 to 4. In cases of the connect_info, which is the core information for operation of Nova, if the information is created upon initial execution, it performs the two-step verification as shown in Fig. 8; synchronization between HdPBF peers is made, and only the 1 step Query in Fig. 9 is executed after synchronization.
The two-step verification is executed only when an initial request for the information is created at the message queue of the OpenStack service. Subsequently, only the first step query is executed, and as further repetitive requests for the identical instance are made, there are fewer cases for the two-step verification to be carried out.
The performance is maximized by minimizing the execution of query to the centralized message queue server through the network by a local query to the HdPBF peer. To this end, synchronization of the core information of the OpenStack message queue is performed as the first step. To ensure the authenticity of the information comparable Fig. 9 Operating procedure of HdPBF for synchronized information to the message queue service of the basic composition of the OpenStack, a query is performed on the centralized message queue server as the second step only for the information that may be generated due to overhead of the consensus algorithm, and it is updated in real time but not yet synched with HdPBF peer. The security risk associated with the message queue information can be reduced as the core information for operation of Nova at the message queue is synched with each node that is the HdPBF peer and identically saved in each Node with the data duplication approach.

Environment of experiment
As shown in Fig. 10, the set up comprising controller node and compute node, which are basic components of the OpenStack, similar to the actual environment and the storage node, was set up to create the instance to be used for the experiment.
The hardware and software composition of the experiment in Fig. 10 are shown in Table 1.
If a client requests the vnc-console from the instance, the controller node requests the get-vnc-console from the corresponding compute node, and the connect_info is created at the message queue, if the get-vnc-console is called initially on the instance that is already created. After that, every occurrence of calling the get-vnc-console, the con-nect_info from the message queue is brought and used.
After creating 6 instances in advance in a method similar to the actual environment, the initial vnc-console request is made in sequence for each instance, and the get-vncconsole is called 6 times for one instance, then the call is made 5 times for the first instance and a new instance followed by another 5-time call for the existing 2 instances  and a new instance, then another 5-time call for the existing 3 instances and a new instance, followed by another 5-time call for the existing 4 instances and a new instance and then lastly, the get-vnc-console is called 4 times on all the 6 instances, which creates a total of 100 call requests such that synchronization between HdPBF peers due to the creation of the connect_info can be made in sequence in the process of the experiment. The shell script created for the experiment is shown in Fig. 11. In the configuration of the OpenStack message queue based on RabbitMQ of the existing OpenStack, the results of verifying the response time by executing the script of Fig. 11 defining the environment of an experiment is shown in Fig. 12.
The average response time for the experiment performed 100 times is 11.0026 ms.
In the configuration of the HdPBF integrated OpenStack message queue based on the two-step verification approach, the results of verifying the response time by executing the script in Fig. 11 defining the environment of an experiment is shown in Fig. 13.
The average response time for experiment performed 100 times is 5.8539 ms. The comparison of response times from the configuration of the OpenStack message queue based on the RabbitMQ of the existing OpenStack with the configuration of the Fig. 11 Shell script for the experiment HdPBF integrated OpenStack message queue based on the two-step verification approach is shown in Fig. 14.
The results of the comparison in Fig. 14 are outlined in Table 2.
Based on the results of the experiment, it was confirmed that the average response time of the HdPBF integrated OpenStack message queue service based on the two-step verification approach has reduced by approximately 46.75% when compared to the OpenStack message queue service based on the existing RabbitMQ.