An OpenStack cloud resource cross-domain fusion method and system

Abstract

An embodiment of the present invention discloses an OpenStack cloud resource cross-domain fusion method, including: establishing a remote network between a data center and remote sites in different regions; connecting the original OpenStack of each remote site to the data center through each remote network; deploying a new OpenStack and connecting the new OpenStack to the data center; creating tenants for different regions in the new OpenStack; and enabling the tenants in each region and the original OpenStack in each region to jointly use cloud resources through the data center. This embodiment realizes the cross-region fusion of cloud resources.

Description

Technical Field

[0001] The embodiments of the present invention relate to the technical field of cloud resource virtualization, and in particular, to a method and system for cross-domain integration of OpenStack cloud resources. Background Art

[0002] With the rapid development of cloud computing technology, OpenStack, as an open-source cloud computing management platform, is widely used in private cloud and hybrid cloud scenarios. However, when sharing and managing OpenStack resources between multiple remote sites, challenges such as network isolation, resource scheduling, and permission control are faced.

[0003] In the prior art, when performing cross-domain scheduling of cloud resources in different regions, since the deployed OpenStack versions in each region are different, it is necessary to adapt different versions of OpenStack, and the adaptation difficulty and workload are very large. Summary of the Invention

[0004] The embodiments of the present invention provide a method and system for cross-domain integration of OpenStack cloud resources to solve the above technical problems.

[0005] In a first aspect, the embodiments of the present invention provide a method for cross-domain integration of OpenStack cloud resources, including:

[0006] Establish a remote network between the data center and remote sites in different regions;

[0007] Connect the original OpenStack of each remote site to the data center through each remote network;

[0008] Deploy a new OpenStack and connect the new OpenStack to the data center;

[0009] Create tenants for different regions in the new OpenStack;

[0010] The tenants in each region and the original OpenStack in each region use cloud resources in coordination through the data center.

[0011] In a second aspect, the embodiments of the present invention provide a system for cross-domain integration of OpenStack cloud resources, characterized by including: a data center and remote sites in different regions;

[0012] Wherein, a remote network is established between the data center and each remote site;

[0013] The original OpenStack of each remote site is connected to the data center through each remote network;

[0014] Tenants in different regions are created in the new OpenStack, and the new OpenStack is also connected to the data center;

[0015] Tenants in each region and the original OpenStack in each region use cloud resources collaboratively through the data center.

[0016] In summary, the embodiments of the present invention provide a method and system for cross-domain integration of OpenStack cloud resources. First, a stable and efficient cloud platform infrastructure is constructed, on which the OpenStack open-source cloud computing management platform is deployed to integrate cross-domain resources, improving the utilization rate of cross-domain networks and resources and the operation and maintenance efficiency in terms of the overall structure; and by establishing a data center, cross-domain resources are uniformly managed through openstack, improving the co-management and co-utilization ability of resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0018] Figure 1 is a flowchart of a method for cross-domain integration of OpenStack cloud resources provided by an embodiment of the present invention;

[0019] Figure 2 is a schematic diagram of a system for cross-domain integration of OpenStack cloud resources provided by an embodiment of the present invention;

[0020] Figure 3 An architecture diagram of a system for cross-domain integration of OpenStack cloud resources provided by this embodiment;

[0021] Figure 4 Another architecture diagram of a system for cross-domain integration of OpenStack cloud resources provided by this embodiment. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0022] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts fall within the scope of protection of the present invention.

[0023] In the description of the present invention, it should be noted that the orientation or positional relationship indicated by the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. is based on the orientation or positional relationship shown in the drawings. It is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation to the present invention. In addition, the terms "first", "second", "third" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance.

[0024] In the description of the present invention, it should also be noted that unless otherwise clearly specified and limited, the terms "installed", "connected", "connected" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be directly connected or indirectly connected through an intermediate medium, and it can be the communication inside two elements. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific situations.

[0025] The embodiment of the present invention provides a method for cross-domain fusion of OpenStack cloud resources. To illustrate this method, the main technical difficulties faced in realizing the cross-domain fusion of OpenStack cloud resources are introduced first. Generally speaking, in the process of collaborative sharing of openstack resources in this embodiment, a technical architecture of "logically integrated and physically distributed" resource co-management and co-utilization is mainly constructed around the establishment of data centers, the connection of cross-domain networks, dynamic deployment, efficient operation and maintenance, and real-time monitoring.

[0026] At the present stage, with the rapid development of cloud computing technology, data centers are gradually developing towards large-scale, highly available, and easy-to-manage directions. As an open-source cloud computing management platform, OpenStack is widely used in private cloud and hybrid cloud scenarios. However, when sharing and managing OpenStack resources between multiple data centers or remote sites, challenges such as network isolation, resource scheduling, and permission control are faced.

[0027] Currently, in the cross-domain fusion operation and maintenance solution for OpenStack cloud resource collaborative management, in terms of data resources, a unified data center needs to be established for cross-domain management of resources, and scalability and compatibility also face challenges. When connecting cross-domain networks during cross-domain management, network complexity, performance bottlenecks, and security issues may be encountered. The dynamic deployment process is relatively complex, the degree of automation needs to be improved, and at the same time, it is necessary to ensure that new resources can be quickly and stably integrated into the existing system. In terms of efficient operation and maintenance, the operation and maintenance cost and technical threshold are relatively high, and the difficulty of monitoring and fault troubleshooting cannot be ignored. These defects need to be continuously improved and optimized in practical applications to ensure the stable operation and efficient operation and maintenance of the OpenStack system.

[0028] Based on the above technical difficulties, Figure 1 is a flowchart of a method for cross - domain fusion of OpenStack cloud resources provided by an embodiment of the present invention. This method is applicable to the situation of cross - domain management and scheduling of OpenStack cloud resources in different regions, such as Figure 1 As shown, the method specifically includes:

[0029] S110. Establish a remote network between the data center and remote sites in different regions.

[0030] Different regions may refer to different areas, different cities, etc. Remote sites refer to cloud resource sites located in different regions. This step uses virtual private networks, including but not limited to VPN (Virtual Private Network) or EVPN (Ethernet Virtual Private Network) + VXLAN (Virtual Extensible LAN), etc., to achieve cross - regional, secure and reliable network interconnection, ensuring unobstructed and secure isolation of data flow.

[0031] Optionally, taking VPN as an example, the construction of the virtual network may include the following steps: First, deploy VPN devices between the data center and each remote site to establish an encrypted tunnel connection; then, configure VPN tunnel parameters to ensure that network bandwidth, latency, and security meet business requirements; finally, implement QoS (Quality of Service) policies on the VPN tunnel to optimize data transmission performance.

[0032] In addition, this embodiment can also establish a blockchain - enhanced SDN intelligent routing and security audit system for the virtual private network. Optionally, the consensus mechanism of the blockchain (such as DPoS, for the efficiency of large - scale networks) can be deeply integrated with the intelligent routing algorithm of SDN. Blockchain nodes not only participate in the data verification and consensus process, but also act as part of the routing decision. They receive network status information through smart contracts, jointly calculate and verify the optimal routing path, significantly improving the reliability and security of routing. At the same time, a comprehensive security audit system is constructed, and all network traffic data, routing decision records, and key network events are encrypted and stored on the blockchain. Utilizing the immutable feature of the blockchain to ensure the authenticity and integrity of audit data, providing a solid data foundation for network fault troubleshooting, performance optimization, and compliance inspection.

[0033] In a specific implementation manner, the establishment of the blockchain - enhanced SDN intelligent routing and security audit system may include the following steps:

[0034] Step 1. Develop a dedicated SDN controller plugin to achieve seamless integration with blockchain nodes. This plugin is responsible for forwarding the routing decision requests of the SDN control plane to the blockchain network and receiving the decision results returned by the blockchain.

[0035] Step 2: Write a smart contract to define the logic and rules for routing decisions. The smart contract receives network status data from the SDN controller, combines the voting or weight information of the blockchain nodes, and calculates and returns the optimal routing path. Optionally, the SDN controller can be accessed through a VPN tunnel between the data center and remote sites in different regions, and the smart contract can be configured in the SDN controller.

[0036] Step 3: Design an efficient blockchain storage architecture to support the rapid processing and query of large-scale network traffic data. Adopt distributed storage technology and indexing mechanisms to ensure the rapid access and efficient management of data.

[0037] S120: Connect the original OpenStack of each remote site to the data center through each remote network.

[0038] Remote sites in different regions may have already deployed the OpenStack cloud resource management platform and are running. The versions of these OpenStacks may vary. In this embodiment, the original OpenStack is retained unchanged, and only through the remote network is it made to interact with the data center.

[0039] S130: Deploy a new OpenStack and connect the new OpenStack to the data center.

[0040] In this embodiment, on the basis of keeping the original OpenStack of each remote site unchanged, a new OpenStack platform is established, and the cloud resources in subsequent different regions are managed and scheduled through the new OpenStack platform. Similarly, the new OpenStack platform also needs to be connected to the data center, and the data center uniformly manages and schedules each original OpenStack and the new OpenStack.

[0041] In a specific embodiment, Kubernetes can be used to deploy the new OpenStack. Specifically, this process can include the following steps:

[0042] Step 1: Deploy Kubernetes clusters in the data center and each remote site, and deploy new OpenStack components. Optionally, OpenStack Helm Chart or a custom Operator can be installed for containerized deployment of OpenStack components.

[0043] Step 2: Use the persistent volume of Kubernetes to provide storage support for the new OpenStack to ensure the persistence of data and configurations.

[0044] Step 3: Configure the Kubernetes network plugin (such as Calico) to ensure network communication between Kubernetes and the new OpenStack.

[0045] In addition, in this embodiment, a blockchain-assisted resource scheduling and cross-platform trust mechanism can also be established in the integration of Kubernetes and OpenStack. Optionally, a blockchain is introduced between Kubernetes and OpenStack as the core record system for resource allocation and scheduling. All operations of resource requests, allocations, and releases are recorded and verified through the blockchain to ensure the transparency and fairness of resource management. At the same time, a trust chain between Kubernetes and OpenStack is established using the smart contracts of the blockchain. Through the smart contracts, automated verification and confirmation of cross-platform resource requests and responses are achieved, reducing manual intervention, lowering the error rate, and improving the efficiency and accuracy of resource scheduling.

[0046] In a specific embodiment, the establishment of the blockchain-assisted resource scheduling and cross-platform trust mechanism may include the following steps:

[0047] Step 1: Through a cross-platform blockchain client, realize the interaction between Kubernetes and the new OpenStack and the blockchain, where the blockchain is used to record and verify the resource scheduling situation of the new OpenStack. Optionally, develop a cross-platform blockchain client or proxy to support the interaction between Kubernetes and OpenStack and the blockchain network. The client is responsible for encrypting and sending resource request and response information to the blockchain network and receiving the verification results returned by the blockchain.

[0048] Step 2: Through smart contracts, establish a signature and verification mechanism between Kubernetes and the new OpenStack. Optionally, design a blockchain-based resource scheduling algorithm to make intelligent resource scheduling decisions based on the resource allocation records and resource demand predictions on the blockchain. The algorithm considers various factors, such as resource utilization, load balancing, cost-effectiveness, etc., to ensure the optimal allocation of resources.

[0049] Step 3: Establish a blockchain signature and verification mechanism for cross-platform resource requests. The resource request is signed with a private key before being sent, and the recipient verifies it with a public key to ensure the authenticity and non-repudiation of the request.

[0050] S140: Create tenants for different regions in the new OpenStack.

[0051] This step realizes the co - management and shared use of resources. In the case of using Kubernetes to deploy the new OpenStack, the co - management and shared use of resources can be achieved in the following ways:

[0052] Step 1: Create multiple namespaces in Kubernetes, and each namespace corresponds to an OpenStack tenant in each region.

[0053] Step 2: Implement role - based access control policies to ensure that each tenant can only access the resources authorized to it.

[0054] Step 3: Utilize the scheduler and load balancer of Kubernetes to optimize the allocation and use of OpenStack resources.

[0055] In addition, this embodiment can also establish a blockchain - driven resource sharing and incentive mechanism. Optionally, build a blockchain - based decentralized resource sharing platform that allows different projects, teams, or business units to freely publish and request resources on the platform. The platform realizes the automatic matching and allocation of resources through smart contracts, improving the flexibility and utilization rate of resources. At the same time, use the smart contracts of the blockchain to design an incentive mechanism for resource use. According to factors such as the usage amount, duration, and quality of resources, rewards are automatically calculated and allocated. The incentive mechanism encourages users to actively share resources, promoting the efficient use and recycling of resources.

[0056] In a specific implementation manner, the establishment of the blockchain - driven resource sharing and incentive mechanism may include the following steps:

[0057] Step 1: Deploy a blockchain - based resource sharing API for each tenant. The resource sharing API is used to publish, request, match, and confirm resources to the blockchain. Optionally, develop a blockchain - based resource sharing API that supports operations such as resource publishing, requesting, matching, and confirmation. The API provides a unified interface specification, facilitating the integration and interoperability between different systems and platforms.

[0058] Step 2: Deploy smart contract templates and parameterized configuration tools for each tenant for users to customize incentive mechanisms and rules. Optionally, smart contract templates and parameterized configuration tools can be designed to allow users to customize incentive mechanisms and rules according to actual needs. Users can achieve complex incentive mechanism designs through simple configurations, improving the flexibility and scalability of the system.

[0059] Step 3: Perform blockchain storage and real - time analysis of resource usage data. Ensure the authenticity and integrity of data through blockchain storage, and provide data support for the incentive mechanism through real - time analysis. The analysis results can be used to optimize resource allocation strategies, improve resource utilization efficiency, etc.

[0060] S150. Tenants in each region and the original OpenStack in each region jointly use cloud resources through the data center.

[0061] After the operations of S110 - S140 are completed, the cloud resources of the tenants in the new OpenStack in each region and the original OpenStack in each region can be uniformly managed and scheduled in the data center.

[0062] Specifically, the tenants in each region and the original OpenStack in each region send their respective cloud resource holdings and usage situations to the data center. If a user requests resource usage from a tenant in the new OpenStack or the original OpenStack in a certain region, the tenant or the original OpenStack will initiate a resource call request to the data center. After receiving the resource call request, the data center allocates cloud resources to the requesting user according to the overall cloud resource holdings and usage situations, thereby realizing the collaborative management and use of cloud resources without changing the original OpenStack.

[0063] Furthermore, to ensure the stable operation and efficient management of the cloud environment, based on the cross - domain integration of the above - mentioned OpenStack cloud resources, it is also necessary to monitor and maintain the entire cloud environment. To achieve automated monitoring and maintenance, tools such as Helm or Ansible can be used to realize the automated deployment and configuration of OpenStack and Kubernetes; monitoring tools such as Prometheus and Grafana are deployed to monitor the running status in real time; and a log collection and analysis system such as ELK Stack (Elasticsearch, Logstash, Kibana) is configured for log management and auditing.

[0064] In addition, this embodiment can also establish an operation and maintenance monitoring and fault recovery system empowered by blockchain. Optionally, by utilizing the characteristics of blockchain such as immutability, transparency, and traceability, all key operation and maintenance logs, performance indicators (KPIs), system events, etc. are encrypted and stored on the blockchain to ensure the authenticity and integrity of the data. This not only provides a reliable data basis for fault troubleshooting and performance optimization but also enhances the security and compliance of the system. At the same time, an automatic fault recovery mechanism based on blockchain smart contracts can be designed. The smart contract can monitor the monitoring data on the blockchain and immediately trigger the corresponding fault recovery process once it detects a preset fault condition or abnormal event. These processes may include automatically restarting services, switching to backup resources, notifying operation and maintenance personnel, etc., thus greatly reducing human intervention and recovery time and improving the stability and availability of the system.

[0065] In a specific embodiment, the establishment of an operation and maintenance monitoring and fault recovery system empowered by blockchain may include the following steps:

[0066] Step 1: Deploy an operation and maintenance monitoring plugin based on blockchain and write monitoring data into the blockchain in real time. Optionally, an operation and maintenance monitoring plugin or middleware based on blockchain can be developed to write monitoring data into the blockchain in real time.

[0067] Step 2: Define fault detection, diagnosis, and recovery rules through smart contracts, which are used to automatically execute corresponding recovery strategies during a fault and record the recovery results back to the blockchain. Optionally, a smart contract can be written to define the logic and rules for fault detection, diagnosis, and recovery. The smart contract needs to be able to parse the monitoring data on the blockchain and judge the system status according to preset thresholds or conditions. Once a fault is detected, the smart contract will automatically execute the corresponding recovery strategy and record the recovery results back to the blockchain.

[0068] Step 3: Integrate and link the blockchain monitoring plugin with existing operation and maintenance tools. The blockchain monitoring plugin can be integrated into existing operation and maintenance monitoring systems, such as Prometheus, Grafana, etc., to achieve seamless docking and transmission of data. Through methods such as API interfaces or message queues, the monitoring data and fault recovery information on the blockchain are synchronized to the operation and maintenance tools in real time to ensure that operation and maintenance personnel can timely understand the system status and take corresponding measures.

[0069] Step 4: Conduct permission management and access control. Implement strict permission management and access control mechanisms in the blockchain network to ensure that only authorized operation and maintenance personnel or systems can access and modify the monitoring data and smart contracts on the blockchain. This helps protect the sensitive information of the system and prevent unauthorized access and tampering.

[0070] Figure 2 It is a schematic diagram of an OpenStack cloud resource cross-domain fusion system provided by an embodiment of the present invention. As Figure 2 shown, the system includes a data center and remote sites in different regions.

[0071] Among them, a remote network is established between the data center and each remote site; the original OpenStack of each remote site accesses the data center through each remote network; different-region tenants are created in the new OpenStack, and the new OpenStack also accesses the data center; the tenants in each region and the original OpenStack in each region use cloud resources collaboratively through the data center. Among them, Figure 2The remote site 1 and remote site 2 originally had OpenStack deployed. In this embodiment, the original OpenStack is kept unchanged, and the original cloud resources within the sites continue to be managed. At the same time, tenants are created for these two sites in the new OpenStack to manage the newly added cloud resources within the sites. For the remote site N - 1 and remote site N which originally did not have OpenStack deployed, combinations are directly created for them in the new OpenStack, and all cloud resources within the sites are managed.

[0072] Figure 3 and Figure 4 are respectively the architecture diagrams of the OpenStack cloud resource cross - domain fusion system provided by this embodiment, which show the architecture process of the system from different perspectives. Combining Figure 3 with this, the system includes an infrastructure layer, a virtualization and containerization layer, a security policy and planning layer, a monitoring and log management layer, and a user interface and API access layer.

[0073] Among them, the infrastructure layer and the virtualization and container layer together constitute the basic platform architecture of the system. Its main parts include the basic network environment and the k8s basic base. The basic platform architecture is firmly built on an efficient network environment and the Kubernetes (k8s) base. This architecture uses virtual private networks to achieve cross - regional, secure and reliable network interconnection, ensuring unobstructed data flow and secure isolation. As the core base, k8s provides elastic scaling, automated deployment and management capabilities, supports the efficient operation of the microservices architecture, and accelerates application iteration and delivery. The overall design aims to create a flexible, scalable and easy - to - maintain cloud platform foundation, laying a solid foundation for upper - layer application services.

[0074] In the cloud infrastructure layer, the system deploys the open - source cloud computing management platform OpenStack based on the above - mentioned basic platform architecture to further enhance the flexibility and scalability of cloud services. OpenStack supports the comprehensive management of computing resources, storage resources and network resources through rich API interfaces and modular design, realizing the dynamic allocation and efficient utilization of resources.

[0075] In the security policy and compliance layer, the system formulates and implements security policies for the cloud environment, including network isolation, data encryption, identity authentication and authorization, etc., to ensure the security and compliance of cloud resources and services. By formulating and implementing a series of security policies, covering multiple dimensions such as network isolation, data encryption, identity authentication and authorization. Through strict network isolation measures, the secure isolation of data between different tenants is ensured; advanced data encryption technology is adopted to protect the confidentiality of data during transmission and storage; a strong identity authentication and authorization mechanism is implemented to ensure that only legitimate users can access authorized resources.

[0076] In the monitoring and logging management layer, to ensure the stable operation and efficient management of the cloud environment, the system makes full use of Kubernetes' monitoring and logging management tools, such as Prometheus for performance monitoring, Grafana for visualization, and Elasticsearch for centralized storage and analysis of log data. These tools work together to monitor key metrics of the cloud environment in real time, such as CPU usage, memory occupancy, network traffic, etc., while collecting and analyzing system and application logs to help the operations and maintenance team quickly locate and solve problems.

[0077] In the user interface and API layer, the system provides an easy-to-use user interface (such as Dashboard) and rich API interfaces, facilitating users and administrators to access and manage cloud resources and services. By integrating visualization of cloud resources, one-click operation, and management functions, users and administrators can easily access, monitor, and manage cloud resources and services. At the same time, rich API interfaces are provided, supporting multiple protocols such as RESTful and GraphQL to meet the flexible call requirements of developers and automation tools for cloud resources. These API interfaces not only cover basic services such as computing, storage, and networking, but also extend to advanced functions such as monitoring, logging, and security, providing users with powerful and flexible cloud environment management capabilities.

[0078] Figure 4 is Figure 3 A specific implementation manner of the above OpenStack cloud resource cross-domain fusion system divides the system into multiple subsystems from the perspective of technical implementation: a network architecture design system, a Kubernetes and OpenStack integration system, a resource co-management and co-usage system, and an operations and maintenance and automation system. Among them, the network architecture design system can be deployed and implemented in the manner described in S110 and S120 of the above method embodiments, the Kubernetes and OpenStack integration system can be deployed and implemented in the manner described in S130, the resource co-management and co-usage system can be deployed and implemented in the manner described in S140, and the operations and maintenance and automation system can be deployed and implemented in the manner regarding operations and maintenance and automation in the above method embodiments. All subsystems jointly ensure the normal operation of the OpenStack cloud resource cross-domain fusion system.

[0079] In summary, the embodiments of the present invention provide an OpenStack cloud resource cross - domain integration method and system. First, a stable and efficient cloud platform infrastructure is constructed, with Kubernetes as the core base, combined with advanced network technologies such as VPN, EVPN + VXLAN, to achieve cross - regional secure network interconnection and flexible resource scheduling. On this basis, the OpenStack open - source cloud computing management platform is deployed. Through its rich API interfaces and modular design, it comprehensively manages computing, storage, and network resources, ensuring dynamic resource allocation and efficient utilization. At the same time, strict security policies are implemented, including network isolation, data encryption, identity authentication, and authorization, to ensure the security and compliance of the cloud environment. Tools such as Prometheus, Grafana, and Elasticsearch are used to achieve intelligent performance monitoring and log management of the cloud environment, ensuring the stable operation of the system. In addition, an intuitive and easy - to - use user interface and comprehensive API interfaces are provided, supporting multiple protocols such as RESTful and GraphQL. This not only simplifies the operation processes of users and administrators but also meets the flexible call requirements of developers and automation tools for cloud resources, laying a solid, flexible, and easy - to - maintain foundation for upper - layer application services. This method and system adopt the OpenStack cloud resource collaborative management and cross - domain integration method, integrating cross - domain resources, improving the utilization rate of cross - domain networks and resources as well as the operation and maintenance efficiency from the overall structure; and by establishing a data center, the cross - domain resources are uniformly managed through OpenStack, improving the co - management and co - utilization ability of resources.

[0080] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention, not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some or all of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the technical solutions of the embodiments of the present invention.

Claims

1. A method for cross-domain integration of OpenStack cloud resources, characterized in that: include: Establish a remote network between the data center and remote sites in different regions; specifically, establish a remote network using a virtual private network, and establish a blockchain-enhanced SDN intelligent routing and security audit system for the virtual private network; Connecting the original OpenStack of each remote site to the data center through each remote network; Deploy a new OpenStack using Kubernetes, and connect the new OpenStack to the data center; Creating tenants for different regions in the new OpenStack; Tenants in various regions and existing OpenStack in various regions collaboratively use cloud resources through the data center.

2. The method according to claim 1, characterized in that The remote network is established between the data center and remote sites in different regions, including: Establish VPN tunnels between data centers and remote sites in different regions; The SDN controller is logged in through the VPN tunnel, and a smart contract is configured in the SDN controller. The smart contract is used to calculate the optimal routing path according to the network status data from the SDN controller and the voting or weight information of the blockchain node.

3. The method according to claim 1, characterized in that Deploying a new OpenStack includes: Deploy Kubernetes clusters in the data center and at each remote site, and deploy new OpenStack components; Use Kubernetes persistent volumes to provide storage support for the new OpenStack; Configure the Kubernetes network plug-in to ensure network communication between Kubernetes and the new OpenStack.

4. The method according to claim 3, characterized in that The deployment of the new OpenStack also includes: Through a cross-platform blockchain client, the interaction between Kubernetes and the new OpenStack and the blockchain is realized, and the blockchain is used to record and verify the resource scheduling of the new OpenStack; Through smart contracts, a signature and verification mechanism is established between Kubernetes and the new OpenStack.

5. The method according to claim 3, characterized in that: The step of creating tenants for different regions in the new OpenStack includes: Create multiple namespaces in Kubernetes, each corresponding to an OpenStack tenant in a different region; Implement role-based access control policies to ensure that each tenant can only access authorized resources; Use Kubernetes' scheduler and load balancer to optimize the allocation and use of OpenStack resources.

6. The method according to claim 3, characterized in that Kubernetes and the new OpenStack record and verify the resource scheduling of the new OpenStack through blockchain; Accordingly, after creating tenants for different regions in the new OpenStack, the following steps are also included: Deploy a blockchain-based resource sharing API for each tenant, which is used to publish, request, match and confirm resources to the blockchain; Smart contract templates and parameterized configuration tools are deployed on each tenant to allow users to customize incentive mechanisms and rules.

7. The method according to claim 3, characterized in that Kubernetes and the new OpenStack record and verify the resource scheduling of the new OpenStack through blockchain; The method further comprises: Deploy a blockchain-based operation and maintenance monitoring plug-in to write monitoring data into the blockchain in real time; Fault detection, diagnosis and response rules are defined through smart contracts to automatically execute corresponding recovery strategies and record the response results back to the blockchain when a fault occurs.

8. The method according to claim 7, characterized in that Also includes: Deploy Prometheus and Grafana monitoring tools to monitor the operating status of OpenStack and Kubernetes in real time; Through API interfaces or message queues, the monitoring data on the blockchain is synchronized in real time to the Prometheus and Grafana monitoring tools.

9. The method according to claim 1, characterized in that: The tenants in each region and the existing OpenStack in each region use cloud resources in a collaborative manner through the data center, including: Tenants in each region and the original OpenStack in each region send their respective cloud resource usage information to the data center; In response to resource usage requirements, tenants in various regions or existing OpenStacks in various regions initiate resource call requests to the data center; In response to the resource call request, the data center performs unified cloud resource scheduling according to the overall cloud resource usage.

10. An OpenStack cloud resource cross-domain fusion system, characterized in that: include: Data centers and remote sites in different regions; Wherein, a remote network is established between the data center and each remote site; specifically, a virtual private network is used to establish the remote network, and a blockchain-enhanced SDN intelligent routing and security audit system is established for the virtual private network; The existing OpenStack at each remote site is connected to the data center through each remote network; Tenants in different regions are created in a new OpenStack deployed by using Kubernetes, and the new OpenStack is also connected to the data center; Tenants in various regions and existing OpenStack in various regions collaboratively use cloud resources through the data center.

Images