Private cloud construction method and private cloud system

Abstract

The invention provides a private cloud construction method and a private cloud system, and the method comprises the steps: a private cloud center node applies for registration to an adjacent center server based on the ID of the private cloud center node, the center server distributes a private cloud domain name for the private cloud center node according to the ID of the private cloud center node, and all the center servers jointly construct a DHT network; the private cloud common node obtains a private cloud domain name which a user requests to join, queries and analyzes a private cloud center node ID through an internet DNS according to the private cloud domain name, and establishes a physical connection with the private cloud center node through dynamic addressing based on the private cloud center node ID; and creating a virtual network based on the physical connection between the private cloud common node and the private cloud center node, so that any node directly establishes TCP / UDP connection with the virtual public network IP addresses of other nodes through the virtual public network IP in the same private cloud. According to the scheme, the availability of the cloud server can be ensured while the cloud service is realized, and the data privacy security can be ensured.

Description

Technical Field

[0001] The present invention belongs to the technical field of cloud computing, and in particular relates to a private cloud construction method and a private cloud system. Background Art

[0002] In the field of cloud computing, private clouds can not only achieve efficient management and utilization of resources, but also protect the data security and privacy of users. However, traditional private clouds (especially in home broadband environments) have a core problem, that is, private clouds have poor accessibility and are easily restricted by vendor infrastructure.

[0003] Currently, private clouds are either completely offline and inaccessible through the Internet, or rely on a centralized infrastructure for certain transfers. The former cannot bring a good cloud service experience, and the latter heavily relies on a centralized facility, which is easily controlled by enterprises or organizations. Organization dissolution or facility failure can easily lead to cloud service unavailability. Summary of the invention

[0004] In view of this, an embodiment of the present invention provides a private cloud construction method and a private cloud system, which are used to solve the problem that the current private cloud is easily affected by the failure of centralized facilities while realizing cloud services.

[0005] In a first aspect of an embodiment of the present invention, a private cloud construction method is provided, including: The private cloud center node applies for registration with the adjacent central server based on its own ID, and the central server allocates a private cloud domain name to the private cloud center node based on the private cloud center node ID; Among them, each central server jointly forms a DHT network; The common node of the private cloud obtains the private cloud domain name requested by the user, resolves the private cloud center node ID through Internet DNS query based on the private cloud domain name, and establishes a physical connection with the private cloud center node through dynamic addressing based on the private cloud center node ID; Based on the physical connection between the ordinary nodes of the private cloud and the central nodes of the private cloud, a virtual network is created so that within the same private cloud, any node can directly establish a TCP / UDP connection with the virtual public IP addresses of other nodes through the virtual public IP.

[0006] In a second aspect of an embodiment of the present invention, a private cloud system is provided, including: The central server is used to allocate a private cloud domain name to the private cloud central node according to the private cloud central node ID, and record the correspondence between the private cloud central node ID and the available temporary address of the private cloud central node, and receive the DNS query request of the private cloud common node and feedback the available temporary address of the private cloud central node; Among them, each central server jointly forms a DHT network; The private cloud center node is used to apply for registration with the adjacent central server based on its own ID, and to create a virtual network based on the physical connection between the private cloud ordinary node and the private cloud center node, so that any node in the same private cloud can directly establish a TCP / UDP connection with the virtual public IP address of other nodes through the virtual public IP; A common node of a private cloud is used to obtain the domain name of the private cloud that the user requests to join, resolve the private cloud center node ID through Internet DNS query based on the private cloud domain name, and establish a physical connection with the private cloud center node through dynamic addressing based on the private cloud center node ID.

[0007] In a third aspect of an embodiment of the present invention, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method described in the first aspect of the embodiment of the present invention when executing the computer program.

[0008] In a fourth aspect of an embodiment of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method provided in the first aspect of the embodiment of the present invention are implemented.

[0009] In the embodiment of the present invention, a central server participating in the same DHT network allocates a private cloud domain name to a private cloud central node, receives a DNS query request from a private cloud ordinary node, and feeds back a private cloud central node ID and a corresponding dynamic address to establish a connection between a private cloud ordinary node and a central node, and creates a virtual network in the private cloud. This not only enables the online cloud service of the private cloud, but also effectively guarantees the availability and data privacy security of the private cloud. At the same time, based on the virtual network mechanism, two-way access to node data within the private cloud can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0011] Figure 1 A flowchart of a private cloud construction method provided by an embodiment of the present invention; Figure 2 Another schematic diagram of a process for building a private cloud provided by an embodiment of the present invention; Figure 3A schematic diagram of the structure of a private cloud system provided for one embodiment of the present invention. DETAILED DESCRIPTION

[0012] In order to make the purpose, features and advantages of the present invention more obvious and easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0013] It should be understood that the term "including" and other similar expressions in the specification or claims of the present invention and the above-mentioned drawings are intended to cover non-exclusive inclusions, such as a process, method, system, or device including a series of steps or units is not limited to the listed steps or units. In addition, "first" and "second" are used to distinguish different objects, not to describe a specific order.

[0014] See also Figure 1 , a flowchart of a private cloud construction method provided by an embodiment of the present invention includes: S101, the private cloud central node applies for registration to the adjacent central server based on its own ID, and the central server allocates a private cloud domain name to the private cloud central node according to the private cloud central node ID; The central node of a private cloud refers to the central device of a region, which can generally be a home desktop computer or a small enterprise server. The central server is a lightweight centralized server deployed in the Internet network environment, that is, a public cloud server, which has a public network IP and has functions such as connection address management, domain name control and relay. Ordinary nodes of a private cloud are generally ordinary terminal devices, such as mobile phones, tablet computers, laptops, etc.

[0015] Among them, each central server jointly forms a DHT (Distributed Hash Table Network) network. The DHT network is a distributed storage method. Each client is responsible for a small range of routing and is responsible for storing a small part of data, thereby realizing the addressing and storage of the entire DHT network.

[0016] The private cloud center node uses its own ID (i.e. PeerID) to apply to the neighboring central server to register a private cloud name and realize the registration of the private cloud center node. After the registration is completed, the central server will assign a private cloud domain name to the private cloud center node, which is a public network domain name.

[0017] Specifically, the private cloud center node passes its own ID (i.e. PeerID) and private cloud name (BoxName) to the central server, and the central server assigns a private cloud domain name BoxName.CenterDomain to the private cloud center node. The central server can then authenticate based on PeerID and securely proxy any operations of the private cloud center node on BoxName.CenterDomain.

[0018] Among them, the private cloud center node records its own ID and its first available virtual IP in the private cloud domain name.

[0019] The private cloud center node records its own PeerID in the TXT record of BoxName.CenterDomain (so that other nodes can resolve the center node's PeerID by BoxName). The first available IP in its own virtual IP is recorded in the AAAA record of BoxName.CenterDomain (so that other nodes can resolve the center node's virtual IP address by BoxName).

[0020] S102, the private cloud common node obtains the private cloud domain name requested by the user to join, resolves the private cloud center node ID through Internet DNS query according to the private cloud domain name, and establishes a physical connection with the private cloud center node through dynamic addressing based on the private cloud center node ID; When a private cloud ordinary node wishes to join the private cloud to which the central node belongs, the private cloud ordinary node obtains the private cloud domain name provided by the user, and queries the TXT record in the domain name (i.e. BoxName.CenterDomain) through the Internet DNS (Domain Name System) based on the private cloud domain name (e.g. BoxName.CenterDomain), and resolves the private cloud central node ID (i.e. PeerID).

[0021] Based on the private cloud center node ID, the private cloud center node ID (PeerID) and the corresponding dynamic address set are found through dynamic addressing, and the underlying physical connection is established based on the private cloud center node address.

[0022] It is understandable that the Internet DNS system is distributed, not controlled by a specific manufacturer, and has good decentralization characteristics. Based on this feature of DNS, the ordinary domain name of the home private cloud is converted into a unique private cloud ID, thereby realizing the positioning of the private cloud network without the need for additional deployment.

[0023] S103. Create a virtual network based on the physical connection between the ordinary nodes of the private cloud and the central nodes of the private cloud, so that any node in the same private cloud can directly establish a TCP / UDP connection with the virtual public IP addresses of other nodes through the virtual public IP.

[0024] When a private cloud common node successfully establishes an underlying physical connection with a private cloud central node (either directly or through a relay), the physical connection can be multiplexed to create a virtual network layer. The virtual network layer means that any node can use its own virtual public IP address (normally this is a private address within a local area network) to directly establish a TCP / UDP connection with the virtual public IP address of other nodes in the same private cloud.

[0025] Once the virtual network layer is established, ordinary nodes of the private cloud can use the Internet DNS system to normally access any service provided by the private cloud central node.

[0026] In this embodiment, by establishing a virtual network, other common programs (such as browsers) on the operating system of the node can communicate through the virtual IP of the private network. For example, the HTTP server on the node can listen on the virtual IP, and the browser on the node can also use the virtual IP of the node for communication without modifying the code.

[0027] Compared with the traditional private cloud, the private cloud of this embodiment is smaller in scale, and the number of nodes is usually less than 100. This feature makes the private cloud system relatively simple in terms of management complexity and resource allocation, and is very suitable for small network application scenarios such as home environments. There is a key central node in the private cloud, which plays a core role in the entire private cloud architecture. Any other node that wants to join this private cloud must be authenticated and authorized by the central node. This mechanism strictly controls the access of nodes while ensuring network security and user privacy. The deployment cost is low, and only one central node needs to be purchased and placed at home. There is no other additional cost, so that ordinary home users can easily build and use private cloud systems to meet the needs of internal home data storage, sharing, etc. Based on the node public and private key and authoritative ID mechanism, each private cloud node will independently generate a pair of public and private keys offline, and derive an authoritative ID based on the public key. Other nodes communicate with each other through the authoritative ID. The authoritative ID is unique and cannot be forged, thereby further ensuring the security of communication and the identifiability of nodes.

[0028] It can be understood that the virtual public IP algorithm can utilize the rich address space of IPv6 private addresses. Each private cloud is isolated from each other, and the internal nodes of the private cloud independently allocate their own IP ranges within the virtual IPv6 ULA address segment according to the offline algorithm. This is an algorithm agreed upon by the nodes of the private cloud. The core of the algorithm needs to ensure the following: Independence principle: When generating an IP range, each node does not communicate with other nodes, and completes the generation process completely independently to ensure the autonomy of each node; Conflict minimization: The allocated IP address range should try to avoid conflicts with other nodes. Considering that the number of nodes in a private cloud is usually small, and there is no mutual communication between different private clouds, even if the probability of a conflict is small, this small probability conflict will not cause substantial problems; Multi-IP support capability: The node needs to support the allocation of one or more IP addresses so that a unique IP can be independently allocated to different services in the node, which enables each service to have an independent network identity, which is convenient for accurate identification and communication in the network environment.

[0029] Virtual public IP can use a fixed prefix, such as fc01:2:3:4:: / 40, and then concatenate the 32-bit MAC address of the node's own network card to form its own IP address space. This method utilizes the uniqueness of the network card MAC address, and to a certain extent, guarantees the uniqueness of the IP address assigned to each node, while also meeting the need to assign independent IPs to different services.

[0030] In this embodiment, there are lightweight centralized nodes. The central server only needs to serve the private cloud central nodes and ordinary nodes in the region. The central server has low cost. Small organizations or even individuals can operate independently and join the DHT network to enhance the availability of the entire central server. Data privacy can be protected. Communication data between private cloud nodes can be encrypted end-to-end. The relevant keys are generated offline and cannot be obtained by any other node. This ensures that data privacy is not compromised while taking advantage of the convenience of the public cloud. With good availability, when a central server fails or stops operating, you can deploy a centralized server or switch to other centralized servers, and the data and account information in the private cloud will not be affected, which effectively guarantees the availability of the private cloud and is not restricted by manufacturers; It can realize two-way resource access. Based on the virtual network mechanism, ordinary nodes of the private cloud can act as servers to provide accessible services for the central node. For example, ordinary nodes can share the albums, files, and device status on the mobile phone with the programs on the central node for access, forming a resource access architecture that goes beyond the traditional public cloud and can realize pure backend applications. Ordinary nodes can only provide resource APIs, and business logic can be executed on the central node with stronger computing power. Rich independent IP resources, each node has tens of thousands of available IPs, and can allocate an independent IP to each service on the central node, so that each service can use the complete TCP / UDP port list. General public clouds only have 1 IP address, and cloud services can only be diverted at the HTTP level. Diversion is not possible for non-80 / 443 port protocols.

[0031] In one embodiment, the private cloud central node applies for a relay address from the central server and adds the applied relay address to the temporary address of the private cloud central node; when the private cloud ordinary node and the private cloud central node cannot be directly connected, a relay connection is established based on the relay address.

[0032] The private cloud center node will apply for a relay address from the central server to which it belongs, and add the relay address to the temporary address of the central node. After the private cloud common node queries the address of the central node, if it cannot connect directly (that is, the two are not in the same LAN, and the central node has no available public network address or is a non-NAT1 address), it will use the relay address to connect.

[0033] After the private cloud common node is connected to the private cloud central node through relay, the private cloud common node initiates a direct connection upgrade request. Direct connection upgrade means upgrading the "relay" channel to a direct connection between two nodes at the network level. Each node in the private cloud (mobile phone, tablet, computer) has Internet service, so the traditional "hole punching" mechanism can be used to try to upgrade from the relay channel to the direct connection channel.

[0034] The ordinary nodes of the private cloud initiate direct connection upgrade requests to the central node. The request process is similar to the general hole punching mechanism. The special thing is that no additional traditional hole punching coordination control server is required, because the ordinary nodes and the central node have established a connection and can be autonomously controlled on the previous relay channel. If direct connection upgrade cannot be achieved, based on the service level configuration of the central server for the private cloud central node, you can choose speed limit, flow limit and other mechanisms to control resource utilization, or the private cloud central node can build additional relay solutions by itself and add them to the temporary address.

[0035] In one embodiment, the temporary addresses available at the private cloud central node are monitored and stored in the central server. The temporary addresses include the LAN address, the address after NAT, the UPNP application address, the node's own public network address and the relay address.

[0036] Further, such as Figure 2 As shown, establishing a physical connection with the private cloud center node through dynamic addressing in S102 includes: In step S201, the monitoring central server obtains the temporary address available to the private cloud central node; in step S202, the private cloud ordinary node requests the available temporary address from the central server; in step S203, if the neighboring central server does not return the temporary address available to the target private cloud central node, the query is broadcast to other central servers through the neighboring central server; in step S204, if the neighboring central server does not return the temporary address available to the target private cloud central node, the private cloud ordinary node establishes a physical connection with the private cloud central node based on the temporary address.

[0037] The central server can monitor the temporary addresses available to the private cloud central node. When the temporary address of the central node changes, the central server will be informed, and the central server will store the corresponding relationship between the central node and the temporary address.

[0038] When a private cloud common node initiates a query request, it will initiate a query request to the nearest public cloud central server. In most cases, the private cloud common node and the private cloud central node belong to the same central server, and the central server can directly return the recorded temporary address information; when the private cloud common node and the private cloud central node do not belong to the same central server, that is, the local central server does not query the temporary address, the local central server will broadcast the query to other central servers.

[0039] Preferably, the local central server broadcast algorithm adopts a DHT (Distributed Hash Table) algorithm. All central servers participate in the same DHT network and store their respective temporary address information in the DHT.

[0040] Each private cloud central node has one and only one corresponding central server. A private cloud ordinary node may be connected to two different private cloud central nodes at the same time. Private cloud ordinary nodes are generally mobile devices such as mobile phones and tablets, and may cross different regions.

[0041] In the case of cross-central servers, for example, when a private cloud ordinary node is traveling abroad, it may switch to a foreign central server. The benefit of all central servers jointly forming a DHT network is that no matter how the private cloud ordinary node roams in the network, it can use the central server closest to the ordinary node for communication. This not only improves the user experience, but also weakens the impact of a single central server failure on the entire system to a certain extent.

[0042] In one embodiment, a virtual network is constructed through a tun mechanism or a socks proxy.

[0043] The common nodes of the private cloud and the central nodes of the private cloud establish a virtual network on top of this underlying physical connection, which can be achieved through the tun mechanism or SOCKS proxy. The tun mechanism is to capture and redirect all outbound network traffic by creating a virtual network interface in the operating system, and can implement customized network behavior without modifying the actual network hardware or driver. socks is a proxy program, and the client's domain name request will be parsed and communicated by the socks proxy. Based on this feature, the socks proxy can forward traffic through the virtual network when detecting the private cloud domain name, thereby achieving an effect similar to the tun mechanism. Based on the virtual network, the virtual IP to which the node belongs can be routed to the correct service of the correct target node.

[0044] It can be understood that the central server is deployed in a normal Internet network environment and has a public IP. Each central server forms a DHT network. The nodes in the private cloud can directly connect to the server, which has the following interface functions: Connection address management function: responsible for storing and querying all connection addresses of private cloud nodes, which include various types of information such as LAN IP, IP after NAT (network address translation), etc. In this way, the server can fully grasp the connection status of private cloud nodes in different network environments, and provide basic data support for subsequent network communication and management.

[0045] Domain name related functions: Each centralized server has a domain name that it controls (hereinafter referred to as centerDomain). The server can assign the domain name of centerDomain to multiple nodes in the private cloud. Moreover, for each subdomain, the centralized server can set the DNS record of the subdomain on behalf of the node after authentication.

[0046] Relay function: During network communication, when two nodes cannot establish a direct connection for some reason, they can use the temporary relay service provided by the centralized node to achieve communication. After establishing a relay connection through the centralized node, the two nodes can further coordinate to perform "hole punching" operations, thereby upgrading to a direct connection state. This relay function can effectively solve the problem of possible connection barriers between nodes and improve the connectivity and communication efficiency of the network.

[0047] It should be understood that the serial numbers of the steps in the above embodiments do not imply a sequence of execution, and the execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0048] Figure 3 A schematic diagram of the structure of a private cloud system provided in an embodiment of the present invention, the system includes: The central server 310 is used to allocate a private cloud domain name to the private cloud central node according to the private cloud central node ID, and record the correspondence between the private cloud central node ID and the available temporary address of the private cloud central node, and receive a DNS query request of a private cloud common node, and feedback the available temporary address of the private cloud central node; Among them, each central server jointly forms a DHT network; The private cloud central node 320 is used to apply for registration with the adjacent central server based on its own ID, and to create a virtual network based on the physical connection between the private cloud common node and the private cloud central node, so that any node in the same private cloud can directly establish a TCP / UDP connection with the virtual public IP address of other nodes through the virtual public IP; The private cloud central node 320 records its own ID and its first available virtual IP in the private cloud domain name.

[0049] Among them, a virtual network is built through the tun mechanism or socks proxy.

[0050] The private cloud common node 330 is used to obtain the private cloud domain name that the user requests to join, resolve the private cloud center node ID through Internet DNS query according to the private cloud domain name, and establish a physical connection with the private cloud center node through dynamic addressing based on the private cloud center node ID.

[0051] In some embodiments, the private cloud central node 320 applies for a relay address from the central server 310 and adds the applied relay address to the temporary address of the private cloud central node 320; When the private cloud common node 330 and the private cloud central node 320 cannot be directly connected, a relay connection is established based on the relay address.

[0052] In one embodiment, the central server 310 monitors the temporary addresses available for the private cloud central node 320 and stores the available temporary addresses to the central server 310, wherein the temporary addresses include the local area network address, the address after NAT, the UPNP application address, the node's own public network address and the relay address; Optionally, when the private cloud ordinary node 330 initiates a query request to the neighboring central server 310 , if the neighboring central server 310 does not return an available temporary address of the target private cloud central node 320 , the query is broadcast to other central servers through the neighboring central server 310 .

[0053] It can be understood that the public cloud operates through multiple nodes with the same functions but deployed independently; each public cloud node only needs to provide very few functions and resources, so the cost is very low; because of the low cost, ordinary users can deploy a public cloud node (i.e. central server) for their own private cloud, thereby not relying on the services of a specific organization.

[0054] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described systems and modules can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.

[0055] A person of ordinary skill in the art can understand that all or part of the steps in the above-mentioned embodiment method can be implemented by an electronic device, wherein the electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed, part or all of the processes in steps S101 to S103 are implemented.

[0056] Those skilled in the art may also understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it implements part or all of the processes in steps S101 to S103, and the storage medium includes ROM / RAM, etc. In the above-mentioned embodiments, the description of each embodiment has its own emphasis. For the part that is not described or recorded in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0057] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0058] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0059] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for building a private cloud, characterized in that: include: The private cloud center node applies for registration with the adjacent central server based on its own ID, and the central server allocates a private cloud domain name to the private cloud center node based on the private cloud center node ID; Among them, each central server jointly forms a DHT network; The common node of the private cloud obtains the private cloud domain name requested by the user, resolves the private cloud center node ID through Internet DNS query based on the private cloud domain name, and establishes a physical connection with the private cloud center node through dynamic addressing based on the private cloud center node ID; Based on the physical connection between the ordinary nodes of the private cloud and the central nodes of the private cloud, a virtual network is created so that within the same private cloud, any node can directly establish a TCP / UDP connection with the virtual public IP addresses of other nodes through the virtual public IP.

2. The method according to claim 1, characterized in that The central server assigns a private cloud domain name to the private cloud central node according to the private cloud central node ID, and further includes: The private cloud center node records its own ID and its first available virtual IP in the private cloud domain name.

3. The method according to claim 1, characterized in that The central server assigns a private cloud domain name to the private cloud central node according to the private cloud central node ID, and further includes: The private cloud center node applies for a relay address from the central server, and adds the relay address obtained to the temporary address of the private cloud center node; When the private cloud common node and the private cloud central node cannot be directly connected, a relay connection is established based on the relay address.

4. The method according to claim 3, characterized in that The establishing of a physical connection with the private cloud center node through dynamic addressing based on the private cloud center node ID includes: Monitor the temporary addresses available at the private cloud center node and store the available temporary addresses to the central server. The temporary addresses include the LAN address, the address after NAT, the UPNP application address, the node's own public network address and the relay address.

5. The method according to claim 4, characterized in that The storing of the available temporary addresses to the central server comprises: When a private cloud common node initiates a query request to a neighboring central server, if the neighboring central server does not return an available temporary address of the target private cloud central node, the query is broadcast to other central servers through the neighboring central server.

6. The method according to claim 1, characterized in that The step of creating a virtual network based on the physical connection between the ordinary nodes of the private cloud and the central nodes of the private cloud includes: Build a virtual network through the tun mechanism or socks proxy.

7. A private cloud system, characterized in that: include: The central server is used to allocate a private cloud domain name to the private cloud central node according to the private cloud central node ID, and record the correspondence between the private cloud central node ID and the available temporary address of the private cloud central node, and receive the DNS query request of the private cloud common node and feedback the available temporary address of the private cloud central node; Among them, each central server jointly forms a DHT network; The private cloud center node is used to apply for registration with the adjacent central server based on its own ID, and to create a virtual network based on the physical connection between the private cloud ordinary node and the private cloud center node, so that any node in the same private cloud can directly establish a TCP / UDP connection with the virtual public IP address of other nodes through the virtual public IP; A common node of a private cloud is used to obtain the domain name of the private cloud that the user requests to join, resolve the private cloud center node ID through Internet DNS query based on the private cloud domain name, and establish a physical connection with the private cloud center node through dynamic addressing based on the private cloud center node ID.

8. The system according to claim 7, characterized in that The private cloud central node records its own ID and its first available virtual IP in the private cloud domain name.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of a private cloud construction method as described in any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed, the steps of a private cloud construction method as described in any one of claims 1 to 6 are implemented.

Images