A method for building a private cloud and a private cloud system

Abstract

The present invention provides a method for building a private cloud and a private cloud system. The method includes: a private cloud central node applies for registration to an adjacent central server based on its own ID, and the central server assigns a private cloud domain name to the private cloud central node according to the private cloud central node ID, and each central server jointly forms a DHT network; a private cloud ordinary node obtains the private cloud domain name requested by a user to join, resolves the private cloud central node ID through Internet DNS query according to the private cloud domain name, and establishes a physical connection with the private cloud central node through dynamic addressing based on the private cloud central node ID; based on the physical connection between the private cloud ordinary node and the private cloud central node, 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 network IP address of other nodes through the virtual public network IP. Through this solution, while realizing cloud services, it is not only possible to ensure the availability of cloud servers, but also to ensure data privacy and security.

Description

Technical Field

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

[0002] In the field of cloud computing, a private cloud can not only achieve efficient management and utilization of resources, but also ensure the data security and privacy of users. However, there is a core problem with traditional private clouds (especially in the home broadband environment), that is, the poor accessibility of private clouds, which are vulnerable to the limitations of the manufacturer's infrastructure.

[0003] Currently, private clouds are either completely offline and cannot be accessed through the Internet, or rely on a centralized infrastructure for certain transit. The former cannot bring a good cloud service experience, and the latter heavily relies on a centralized facility, which is vulnerable to the control of enterprises or organizations. Disbanding of the organization or failure of the facility, etc., are likely to lead to the unavailability of cloud services. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method for building a private cloud and a private cloud system, which are used to solve the problem that current private clouds are vulnerable to the impact of centralized facility failures while realizing cloud services.

[0005] In the first aspect of the embodiments of the present invention, a method for building a private cloud is provided, including:

[0006] The private cloud central node applies for registration to the adjacent central server based on its own ID, and the central server assigns a private cloud domain name to the private cloud central node according to the private cloud central node ID;

[0007] Among them, each central server jointly forms a DHT network;

[0008] The private cloud ordinary node obtains the private cloud domain name requested by the user to join, resolves the private cloud central node ID through Internet DNS query according to the private cloud domain name, and establishes a physical connection with the private cloud central node through dynamic addressing based on the private cloud central node ID;

[0009] Based on the physical connection between the private cloud ordinary node and the private cloud central node, 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 network IP address of other nodes through the virtual public network IP.

[0010] In the second aspect of the embodiments of the present invention, a private cloud system is provided, including:

[0011] A central server, which is used to allocate a private cloud domain name for a private cloud central node according to the private cloud central node ID, 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 from a private cloud ordinary node and feedback the available temporary address of the private cloud central node;

[0012] Among them, each central server jointly forms a DHT network;

[0013] A private cloud central node, which is used to apply for registration to an adjacent central server based on its own ID, and create a virtual network based on the physical connection between the private cloud ordinary node and the private cloud central node, so that within the same private cloud, any node can directly establish a TCP / UDP connection with the virtual public network IP address of other nodes through the virtual public network IP;

[0014] A private cloud ordinary node, which is used to obtain the private cloud domain name requested by the user to join, resolve the private cloud central node ID through Internet DNS query according to the private cloud domain name, and establish a physical connection with the private cloud central node through dynamic addressing based on the private cloud central node ID.

[0015] In the third aspect of the embodiments of the present invention, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the method described in the first aspect of the embodiments of the present invention are implemented.

[0016] In the fourth aspect of the embodiments of the present invention, a computer-readable storage medium is provided. 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 embodiments of the present invention are implemented.

[0017] In the embodiments of the present invention, based on the central servers participating in the same DHT network, a private cloud domain name is allocated for the private cloud central node, and a DNS query request from the private cloud ordinary node is received, and the private cloud central node ID and the corresponding dynamic address are fed back to establish a connection between the private cloud ordinary node and the central node, and a virtual network is created in the private cloud, so that not only can the online cloud service of the private cloud be realized, but also the availability and data privacy security of the private cloud can be effectively guaranteed. At the same time, based on the virtual network mechanism, two-way access to node data within the private cloud can be realized. Description of the Drawings

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce 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 those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0019] Figure 1 A schematic flowchart of a method for building a private cloud provided by an embodiment of the present invention;

[0020] Figure 2 Another schematic flowchart of a method for building a private cloud provided by an embodiment of the present invention;

[0021] Figure 3 A schematic structural diagram of a private cloud system provided by an embodiment of the present invention. Detailed implementation manners

[0022] In order to make the object, features, and advantages of the present invention more obvious and understandable, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described below are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the protection scope of the present invention.

[0023] 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 mean covering non-exclusive inclusion. For example, 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 and are not used to describe a specific order.

[0024] Please refer to Figure 1 , a schematic flowchart of a method for building a private cloud provided by an embodiment of the present invention, including:

[0025] S101. The private cloud central node applies for registration to the adjacent central server based on its own ID, and the central server assigns a private cloud domain name to the private cloud central node according to the private cloud central node ID;

[0026] The private cloud central node refers to the central device in the area, which can generally be a home desktop computer or an enterprise small server, etc. The central server is a lightweight centralized server deployed in the Internet network environment, that is, a public cloud server, which has a public IP and has functions such as connection address management, domain name control, and relay. The private cloud ordinary node is generally an ordinary terminal device, such as a mobile phone, a tablet computer, a laptop computer, etc.

[0027] 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 stores a small part of the data, thereby realizing the addressing and storage of the entire DHT network.

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

[0029] Specifically, the private cloud central node transmits its own ID (i.e., PeerID) and the private cloud name (BoxName) to the central server, and the central server assigns a private cloud domain name of BoxName.CenterDomain to the private cloud central node. Subsequently, the central server can perform authentication based on the PeerID to securely proxy any operations of the private cloud central node on BoxName.CenterDomain.

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

[0031] The private cloud central node records its own PeerID in the TXT record of BoxName.CenterDomain (so that other nodes can resolve the PeerID of the central node in the way of 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 virtual IP address of the central node in the way of BoxName).

[0032] S102. The private cloud ordinary node obtains the private cloud domain name requested by the user to join, resolves the private cloud central node ID through Internet DNS query according to the private cloud domain name, and establishes a physical connection with the private cloud central node through dynamic addressing based on the private cloud central node ID;

[0033] When a general node of a private cloud expects to join the private cloud to which the central node belongs, the general node of the private cloud will obtain the private cloud domain name provided by the user, and based on the private cloud domain name (such as BoxName.CenterDomain), query the TXT record in the domain name (i.e., BoxName.CenterDomain) through the Internet DNS (Domain Name System), and resolve the private cloud central node ID (i.e., PeerID).

[0034] Based on the private cloud central node ID, find the private cloud central node ID (PeerID) and the corresponding dynamic address set through dynamic addressing, and establish a bottom-layer physical connection based on the private cloud central node address.

[0035] It can be understood that the Internet DNS system is distributed, not controlled by a specific manufacturer, and has good decentralization characteristics. Based on this characteristic of DNS, the ordinary domain name of the home private cloud is converted into a unique private cloud ID, so as to realize the positioning of the private cloud network without additional deployment.

[0036] S103. Based on the physical connection between the general node of the private cloud and the central node of the private cloud, create a virtual network so that any node in the same private cloud can directly establish a TCP / UDP connection with the virtual public network IP address of other nodes through the virtual public network IP.

[0037] When a bottom-layer physical connection (whether directly connected or established through a relay method) is successfully established between the general node of the private cloud and the central node of the private cloud, the physical connection can be multiplexed to create a virtual network layer. The virtual network layer means that any node can directly establish a TCP / UDP connection with the virtual public network IP address of other nodes in the same private cloud using its own virtual public network IP address (normally this is a private address within a local area network).

[0038] After the virtual network layer is established, the general node of the private cloud can use the Internet DNS system to normally access any service provided by the central node of the private cloud.

[0039] In this embodiment, by establishing a virtual network, other ordinary programs (such as browsers) on the operating system where the node is located 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 to communicate without modifying the code.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] In this embodiment, there is a lightweight centralized node. The central server only needs to serve the private cloud central nodes and ordinary nodes within its region. The cost of the central server is low, and small organizations or even individuals can operate independently and join the DHT network to enhance the availability of the entire central server;

[0044] It can protect data privacy. The communication data between private cloud nodes can adopt end-to-end encryption. The relevant keys are generated offline separately, and no other nodes can obtain them. Thus, while taking advantage of the convenience of the public cloud, data privacy is ensured from being damaged;

[0045] It has good availability. When a certain central server fails or stops operating, a centralized server can be deployed by itself or switched to another centralized server, and the data and account information within the private cloud are not affected, effectively ensuring the availability of the private cloud without being restricted by manufacturers;

[0046] It can achieve two-way resource access. Based on the virtual network mechanism, ordinary private cloud nodes can act as servers to provide accessible services for central nodes. For example, ordinary nodes can share the photo albums, files, and device status on mobile phones with programs on central nodes for access, forming a resource access architecture that goes beyond traditional public clouds and can implement pure-backend applications. Ordinary nodes can only provide resource-class APIs, and the business logic can be executed on central nodes with stronger computing power;

[0047] Rich independent IP resources. Each node has tens of thousands of available IPs, and an independent IP can be assigned to each service on the central node, enabling each service to use a complete TCP / UDP port list. Generally, public clouds only have 1 IP address, and cloud services can only be shunted at the HTTP level, and shunting cannot be achieved for non-80 / 443 port protocols.

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

[0049] The private cloud central node will apply to the affiliated central server for a relay address and add the relay address to the temporary address of the central node. After the private cloud ordinary node queries the address of the central node, if it cannot directly connect (that is, the two are not in the same local area network, and the central node does not have an available public network address or is a non-NAT1 address), the relay address is used for connection.

[0050] After the private cloud ordinary node is relayed and connected to the private cloud central node, the private cloud ordinary node initiates a direct connection upgrade request. Direct connection upgrade means that at the network level, the "relay" channel is upgraded to a direct connection between two nodes. Each node (mobile phone, tablet, computer) within the private cloud itself has Internet services, so the traditional "hole punching" mechanism can be used to attempt to upgrade from the relay channel to the direct connection channel.

[0051] The private cloud ordinary node sends a direct connection upgrade request 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 node and the central node have already established a connection and can be autonomously controlled on the previous relay channel. If the direct connection upgrade cannot be achieved, according to the service level configuration of the private cloud central node by the central server, mechanisms such as speed limiting and flow limiting can be selected to control the resource utilization rate. Or, the private cloud central node can build an additional relay solution by itself and add it to the temporary address.

[0052] In one embodiment, listen for the available temporary addresses of the private cloud central node and store the available temporary addresses in the central server. The temporary addresses include local area network addresses, addresses after NAT, UPNP application addresses, the public network address of the node itself, and relay addresses.

[0053] Further, as Figure 2 shown, the establishment of a physical connection with the private cloud central node through dynamic addressing in S102 includes:

[0054] In step S201, after the central server listens and obtains the available temporary addresses of the private cloud central node; in step S202, the private cloud ordinary node requests the available temporary addresses from the central server; in step S203, if the adjacent central server does not return the available temporary addresses of the target private cloud central node, broadcast a query to other central servers through the adjacent central server; in step S204, if the adjacent central server does not return the available temporary addresses of the target private cloud central node, the private cloud ordinary node establishes a physical connection with the private cloud central node based on this temporary address.

[0055] The central server can listen for the available temporary addresses of the private cloud central node. When the temporary address of the central node changes, it will inform the central server, and the central server will store the corresponding relationship between the central node and the temporary address.

[0056] When a private cloud ordinary node initiates a query request, it will send the query request to the nearest public cloud central server. In most cases, the private cloud ordinary node and the private cloud central node belong to the same central server. At this time, the central server can directly return the recorded temporary address information; when the private cloud ordinary node and the private cloud central node do not belong to the same central server, that is, the local central server fails to query the temporary address, the local central server will broadcast the query to other central servers.

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

[0058] 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, and private cloud ordinary nodes are generally mobile devices such as mobile phones and tablets, and may cross different regions.

[0059] In the case of cross-central servers, for example, a private cloud ordinary node may switch to a foreign central server when traveling abroad. The advantage 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. Thus, not only can the user experience be improved, but also the impact of a single central server failure on the entire system can be weakened to a certain extent.

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

[0061] The private cloud ordinary node and the private cloud central node establish a virtual network on this underlying physical connection, which can be through the tun mechanism or the SOCKS proxy, etc. The tun mechanism captures and redirects all outbound network traffic by creating a virtual network interface in the operating system, and can achieve custom network behavior without modifying the actual network hardware or driver. Socks is a proxy program. The domain name request of the client will be resolved and communicated by the socks proxy. Based on this feature, the socks proxy can forward the traffic through the virtual network when detecting the private cloud domain name, thus achieving a similar effect 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.

[0062] 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, and the nodes in the private cloud can directly connect to this server, which has the following interface functions:

[0063] Connection address management function: Responsible for storing and querying all connection addresses of private cloud nodes, which cover various types of information such as LAN IPs and IPs after NAT (Network Address Translation). In this way, the server can comprehensively master the connection status of private cloud nodes in different network environments, providing basic data support for subsequent network communication and management.

[0064] Domain name related function: Each centralized server has a domain name (hereinafter referred to as centerDomain) that it has control over. The server can assign the domain name of centerDomain to multiple nodes in the private cloud, and moreover, for each sub-domain name, the centralized server can, after authentication, set the DNS record of the sub-domain name on behalf of the node.

[0065] Relay function: During network communication, when two nodes cannot directly establish a connection due to certain reasons, 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 with each other to perform a "hole punching" operation, thereby upgrading to a direct connection state. This relay function effectively solves the possible connection obstacle problems between nodes and improves the network connectivity and communication efficiency.

[0066] It should be understood that the sequence numbers of the steps in the above embodiments do not mean the order of execution. The execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

[0067] Figure 3 The following is a schematic structural diagram of a private cloud system provided by an embodiment of the present invention. The system includes:

[0068] A central server 310, which is used to allocate a private cloud domain name to the private cloud central node according to the private cloud central node ID, 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 ordinary node and feedback the available temporary address of the private cloud central node;

[0069] Among them, each central server jointly forms a DHT network;

[0070] The private cloud central node 320 is used to apply for registration with the neighboring central server based on its own ID, and create a virtual network based on the physical connection between the private cloud ordinary node and the private cloud central node, so that within the same private cloud, any node can directly establish a TCP / UDP connection with the virtual public network IP address of other nodes through the virtual public network IP;

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

[0072] Among them, the virtual network is constructed through the tun mechanism or the socks proxy.

[0073] The private cloud ordinary node 330 is used to obtain the private cloud domain name requested by the user to join, resolve the private cloud central node ID through Internet DNS query according to the private cloud domain name, and establish a physical connection with the private cloud central node through dynamic addressing based on the private cloud central node ID.

[0074] In some embodiments, the private cloud central node 320 applies for a relay address from the central server 310 and adds the obtained relay address to the temporary address of the private cloud central node 320;

[0075] When the private cloud ordinary node 330 and the private cloud central node 320 cannot be directly connected, a relay connection is established based on the relay address.

[0076] In one embodiment, the central server 310 listens to the available temporary addresses of the private cloud central node 320 and stores the available temporary addresses in the central server 310. The temporary addresses include the local area network address, the address after NAT, the UPNP application address, the public network address of the node itself, and the relay address;

[0077] Optionally, after the private cloud ordinary node 330 sends a query request to the neighboring central server 310, if the neighboring central server 310 does not return the available temporary address of the target private cloud central node 320, a broadcast query is sent to other central servers through the neighboring central server 310.

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

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

[0080] Those of ordinary skill in the art can understand that all or part of the steps in the above-described method of the embodiments can be implemented by an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed, it implements part or all of the processes in steps S101 to S103.

[0081] Those of ordinary skill in the art can also understand that all or part of the steps in the above-described method of the embodiments can be completed by a program instructing relevant hardware. 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. The storage medium includes, for example, ROM / RAM, etc. In the above embodiments, the descriptions of the various embodiments have their respective emphases. For parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0082] 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, devices, and modules can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0083] In the above embodiments, the descriptions of the various embodiments have their respective emphases. For parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0084] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended 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 of the technical features. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various 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; Among them, the private cloud center node applies for a relay address from the central server, and adds the relay address obtained in the application 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; 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 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.

4. The method according to claim 3, 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.

5. 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.

6. 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; Among them, the private cloud center node applies for a relay address from the central server, and adds the relay address obtained in the application 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; 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.

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

8. 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 5 are implemented.

9. 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 5 are implemented.

Images