Method, First Computing Node, and Storage Medium for Sharing Image Installation Image Streams

Abstract

The present disclosure relates to shared image installation image streams. A technique includes: a first compute node in a node cluster receives a communication from a cluster maintenance node in the cluster, the communication instructing the first compute node to provide an installation image received by the first compute node to a second compute node in the cluster. The first node and the second node are peers. The technique includes sharing a first installation stream that transmits the image to the first compute node. Sharing the first installation stream includes: while the first compute node is receiving the first installation stream, the first compute node provides a second installation stream to transmit portions of the image received via the first installation stream to the second compute node.

Description

Technical Field

[0001] The present disclosure generally relates to shared image installation image streaming. Background Art

[0002] A computing node may have a root file system. Typically, the root file system includes files and directories used to boot the computing node into a normal, usable state. Other file systems may be installed on top of the root file system. When stored in a persistent storage device of the computing node, the root file system can survive after the computing node is powered off or reset. Therefore, the root file system can survive each time the computing node is booted. A computing node may store its root file system in a non-persistent storage device (e.g., random access memory (RAM)), such as in the case of a diskless computing node. The root file system of such a computing node cannot survive after the computing node is powered off or reset, and therefore, each boot of the computing node involves installing the root file system on the computing node. For this purpose, an installation image containing the root file system is transferred to the computing node. In both cases (persistent storage device and non-persistent storage device), the installation image can be transferred to the computing node. However, in the case of a non-persistent storage device, a root file system is configured at each boot. Summary of the Invention

[0003] According to one aspect of the present disclosure, a method for sharing an image installation image stream is provided, comprising: a first computing node in a cluster of nodes receiving a communication from an installation server of the cluster, the communication instructing the first computing node to provide an installation image received by the first computing node to a second computing node in the cluster, wherein the first computing node and the second node are peers and the installation image includes data representing a root file system for starting the first computing node and the second computing node; receiving a first installation stream to transmit the installation image to the first computing node; and sharing the first installation stream, wherein sharing the first installation stream comprises: while the first computing node is receiving the first installation stream, the first computing node provides a second installation stream to transmit portions of the installation image received via the first installation stream to the second computing node.

[0004] According to another aspect of the present disclosure, a first computing node is provided, comprising: a processor; and a memory for storing instructions, which, when executed by the processor, cause the processor to: identify a plurality of auxiliary computing nodes for receiving a plurality of installation streams, wherein each of the plurality of auxiliary computing nodes receives a corresponding installation stream from the plurality of installation streams to install a root file system on the auxiliary computing node; instruct a given auxiliary computing node from the plurality of auxiliary computing nodes to share the corresponding installation stream received by the given auxiliary computing node with a corresponding set of peer computing nodes; and transmit the plurality of installation streams to the plurality of auxiliary nodes.

[0005] According to another aspect of the present disclosure, a non-transitory machine-readable storage medium is provided for storing instructions that, when executed by a first computing node in a cluster of computing nodes, cause the first computing node to: receive communications from an installation server in the cluster to instruct the first computing node to share a first installation image received by the first computing node with a plurality of second computing nodes in the cluster, wherein the first installation image includes data representing a root file system for starting the first computing node and the plurality of second computing nodes; and receive a first installation stream, and share the first installation stream with the plurality of second computing nodes while the first computing node is receiving the first installation stream. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 is a schematic diagram of a cluster of computing nodes according to an example embodiment.

[0007] Figure 2 is an illustration of a setup for installation stream sharing of a cluster according to an example embodiment.

[0008] Figure 3 is an illustration of installation flow sharing according to an example embodiment.

[0009] Figure 4 is a flow diagram depicting a process for sharing an installation flow for delivering an installation image according to an example implementation.

[0010] Figure 5 is a diagram of a compute node indicating a secondary compute node sharing an installation image according to an example embodiment.

[0011] Figure 6 is an illustration of a non-transitory machine-readable storage medium storing executable instructions for causing a machine to share an installation image with another computing node according to an example embodiment. DETAILED DESCRIPTION

[0012] A cluster can have a relatively large number (e.g., hundreds to thousands or even tens of thousands) of compute nodes (e.g., diskless compute nodes) that store their respective root file systems on non-persistent storage. When such a cluster is restarted, it can be challenging to start the compute nodes in a timely manner due to the large amount of network traffic involved in reinstalling the root file system on the compute nodes. More specifically, when a compute node in a cluster (also referred to herein as a "client compute node") is started, the client compute node submits a boot request, and a maintenance compute node in the cluster transmits a boot image to the client compute node in response to the request. The boot image establishes a node installation environment (e.g., a shrunken miniature root file system) on the client compute node, and the node installation environment handles the installation of the root file system on the client compute node. As part of the installation of the root file system on the client compute node, the node installation environment of the client compute node requests and receives the installation image.

[0013] In this context, an "installation image" generally refers to a collection of data representing a root file system. For example, an installation image may include data representing a directory structure containing files such as files corresponding to the operating system kernel, executable files, configuration files, and the operating system boot loader.

[0014] The installation image can be relatively large (e.g., the size of the installation image can be from one gigabyte (GB) to forty GB, if not larger). For a cluster with a relatively large number (e.g., thousands, if not tens of thousands) of client compute nodes, the corresponding relatively large number of installation image transfers at cluster startup can saturate the cluster's network, extend client compute node startup time, and limit the overall compute node scalability of the cluster if appropriate measures are not taken.

[0015] There are a number of potential ways to transfer the installation image to the client compute nodes in the cluster. For example, a file synchronization-based transfer (e.g., using a Linux operating system utility called "rsync") is one potential way to transfer the installation image to the client compute nodes. Utilizing a file synchronization-based transfer, the entire transfer of the installation image occurs between the server and the client compute nodes. A challenge with this type of transfer is that, due to network saturation constraints, a given server may be limited to providing the installation image to a relatively small number (e.g., ten to twenty) of client compute nodes.

[0016] Another potential way to transfer the installation image to the client compute nodes is by using a peer-to-peer file sharing protocol (e.g., the BitTorrent protocol). With a peer-to-peer file sharing protocol, the installation image is represented by a single archive file (e.g., a tape archive (TAR) file), and the single archive file is transferred to the client compute nodes in out-of-order chunks, where each client compute node transfers the chunks to the other client compute nodes. Because the installation image is stored as a single archive file, any changes in the installation image during the installation cycle may create a version disconnect, which means that some client compute nodes may not be able to complete downloading the installation image. In addition, because all client compute nodes are dependent on each other, network constraints such as network switch to network switch links may starve portions of the network; and controlling network usage flow using a peer-to-peer file sharing protocol may generally be challenging.

[0017] Another potential way to transmit the installation image to client compute nodes is through the use of a multicast network transport mechanism. However, challenges can arise in configuring and maintaining proper operation of network switches for multicast transmission. Not all network switches can properly pass network traffic, and separating client compute nodes into various virtual networks can impose high management overhead when maintaining and updating network switches corresponding to different vendors and with different environments.

[0018] According to the example embodiments described herein, the cluster uses installation stream sharing to transmit the installation stream from the installation server to the client computing node. In this context, "installation stream" is transmitted between the provider node and the client computing node and refers to the data time sequence of transmitting the installation image as a whole. The "provider node" can be an installation server or another client computing node (referred to as "secondary computing node" herein). "Installation stream sharing" refers to the action taken by the secondary computing node to copy the installation stream received by the secondary computing node and provide the copied installation stream to other peer client computing nodes. In this way, according to the example embodiments, a given secondary computing node is a client computing node, and the client computing node provides the installation stream to at least one other client computing node in the cluster when the given secondary computing node receives the installation stream from the installation server. As described herein, according to the example embodiments, the secondary computing node and other client computing nodes that receive the installation stream from the secondary computing node are selected in a manner that minimizes network congestion.

[0019] Using the installation stream sharing described herein, even for clusters containing a large number of compute nodes (e.g., thousands or tens of thousands of compute nodes) and even for relatively large (e.g., one GB to forty GB, if not larger) installation images, the compute nodes in the cluster can be started in a relatively short time. Installation stream sharing is robust and tolerant of the heterogeneity of network switches. Installation stream sharing can avoid elaborate network link layer protocols such as multicast protocols; installation stream sharing can avoid the complexity of file block list sharing (e.g., seeders, trackers, and associated infrastructure). Furthermore, using installation stream sharing, the number of client compute nodes used in a cluster can be scaled up without saturating the cluster's network and without significantly affecting the client compute node startup time.

[0020] refer to Figure 1 As a more specific example, in accordance with some embodiments, cluster 100 includes client compute nodes 150 that store their root file systems in volatile memory. For example, in accordance with some embodiments, each client compute node 150 may have a root file system (e.g., a temporary file system (TMPFS) file system) stored in volatile memory (e.g., RAM) of client compute node 150. Because the root file system of client compute node 150 is stored in volatile memory, the root file system is reinstalled each time client compute node 150 is booted. In this context, a "boot" or "reboot" of client compute node 150 generally refers to a boot sequence of client compute node 150 that occurs in response to powering on or resetting client compute node 150.

[0021] According to another example embodiment, one or more client computing nodes 150 may have persistent storage and may store their respective root file systems in the persistent storage. Although such client computing nodes 150 may not reinstall their root file systems each time they boot, when the client computing nodes 150 install their root file systems, the mount stream sharing described herein may be used to transfer the installation image to these client computing nodes 150.

[0022] According to an example embodiment, in addition to client compute nodes 150, cluster 100 also includes maintenance compute nodes 110, such as head compute node 114 and leader compute node 130. Maintenance compute nodes 110 generally manage client compute nodes 150, including provisioning installation images for client compute nodes 150. According to an example embodiment, this provisioning includes instructing certain client compute nodes 150 (referred to herein as "secondary compute nodes 154") to share their received installation streams with other client compute nodes 150; and provisioning includes instructing some client compute nodes 150 to receive their installation streams from secondary compute nodes 154 rather than from an installation server.

[0023] According to an example embodiment, head compute node 114 is the primary or primary maintenance compute node of cluster 100. Typically, leader compute node 130 is an additional maintenance compute node 110 of cluster network 100 that is delegated management responsibilities to prevent overloading of head compute node 114.

[0024] According to an example embodiment, the head computing node 114 can be formed by an actual physical machine made of actual software and actual hardware. For example, the head computing node 114 may include one or more processors 118 (e.g., central processing units (CPUs), CPU processing cores, etc.) and memory 122. As an example, the memory 122 can store machine executable instructions that form a cluster manager 126 when executed by (multiple) processors 118. The memory 122 is typically a non-transitory storage medium that can be formed by a semiconductor memory device, a memristor-based memory device, a magnetic memory device, a phase change memory device, a combination of one or more of these memory technologies, and the like. In addition, the memory 122 can represent a combination of different storage types, such as volatile memory and / or non-volatile memory. The physical machine can take one of many different forms, such as one or more rack-mounted modules, desktop computers, laptop computers, tablet computers, smart phones, wearable computers, and the like. Depending on the specific embodiment, the head computing node 114 can be formed by the entire actual physical machine or a portion thereof. Furthermore, according to some embodiments, the head computing node 114 may include and / or correspond to one or more virtual components of an actual physical machine, such as one or more virtual machines, one or more containers, and the like.

[0025] In a similar manner, according to example embodiments, other computing nodes in cluster 100 (such as leader computing node 130 and client computing node 150) may also be formed by corresponding actual physical machines; may or may not correspond to the entirety of their corresponding physical machines; and may include and / or correspond to one or more virtual components of their corresponding physical machines. Although maintenance computing node 110 stores its corresponding root file system in a persistent storage device as noted above, according to example embodiments, client computing node 150 does not store its corresponding root file system in a persistent storage device.

[0026] According to an example embodiment, when the cluster 100 is started, one or more installation servers 116 in the cluster configure the cluster 100 to be used for installation stream sharing, including specifying certain computing nodes 150 for certain roles in the installation stream sharing and serving installation images. According to an example embodiment, a given installation server 116 can be formed by all or part of an actual physical machine including actual software and actual hardware. For example, according to some embodiments, the installation server 116 can correspond to a specific maintenance computing node 110 (i.e., the head computing node 114 or the leader computing node 130) and can serve one or more installation streams. According to another embodiment, the installation server 116 can be a dedicated physical machine. According to some embodiments, the installation server 116 can be a virtual server (e.g., a container, a virtual machine, etc.) hosted on a physical machine. According to an example embodiment, the installation server 116 can be on the head computing node 114 and / or the leader computing node 130, i.e., the head computing node and / or the leader computing node 130 can act as the installation server 116.

[0027] More specifically, according to example embodiments, as part of an installation stream sharing arrangement, install server 116 may designate certain client computing nodes 150 as "secondary computing nodes 154." According to example embodiments, each of the remaining client computing nodes 150 (referred to herein as "client computing nodes 158") is configured to receive its installation stream from either install server 116 or a secondary computing node 154. As further described herein, one or more install servers 116 provide installation streams to secondary computing nodes 154, each of which delivers an installation image. Each secondary computing node 154, in turn, provides its received installation stream to one or more of client computing nodes 158. Typically, according to example embodiments, secondary computing nodes 154 are client computing nodes 150 that received the installation stream and have been directed by install server 116 to share the received installation stream with one or more other client computing nodes 158. Furthermore, one or more install servers 116 may provide one or more installation streams directly to one or more of client computing nodes 158, and in these cases, installation stream sharing is not used.

[0028] like Figure 1 As depicted, according to an example embodiment, head compute node 114, leader compute node 130, installation server 116, secondary compute node 154, and peer compute node 158 communicate with each other via a network fabric 140. Generally, network fabric 140 may include components associated with and use protocols for one or more types of communication networks, such as, for example, a Fibre Channel network, an iSCSI network, an ATA over Ethernet (AoE) network, a HyperSCSI network, a Gen-Z fabric, a dedicated management network, a local area network (LAN), a wide area network (WAN), a global network (e.g., the Internet), a wireless network, or any combination thereof. Further, according to an example embodiment, network fabric 140 includes network switches 141, and a minimum of some of network switches 141 may be connected to each via network cabling (e.g., Ethernet cables). As further described herein, for purposes of configuring installation flow sharing, potential network saturation bottlenecks due to network switch to network switch cabling are considered and avoided.

[0029] According to some embodiments, cluster network 100 may include a cluster manager database 127. Although Figure 1 1 as being accessible via the network fabric 140, but according to other embodiments, the cluster manager database 127 may be stored locally in a storage device on one of the maintenance compute nodes 110, such as the head compute node 110. Furthermore, according to other example embodiments, the cluster manager database 127 may be distributed over several locations in the cluster 100.

[0030] According to some embodiments, cluster manager database 127 stores data defining the management roles of maintenance compute nodes 110 and the installation flow sharing roles of client compute nodes 150. Furthermore, according to example embodiments, cluster manager database 127 may store data representing network configuration details that may be used to assign installation flow sharing roles.

[0031] According to some embodiments, the cluster manager database 127 may have entries corresponding to respective client compute nodes 150 and contain data representing network-related details of the client compute nodes 150. For example, the entry in the cluster manager database 127 for a given client compute node 150 may contain information identifying the specific network switch 141 and port to which the client compute node 150 is connected. From the information contained in the cluster manager database 127, the cluster manager 126 or a human cluster administrator may identify the installation flow sharing role for the client compute node 150 in a manner that avoids saturating the network infrastructure, as further described herein. According to example embodiments, the cluster manager database 127 may store data entries representing other information, such as the role assignments of the compute nodes of the cluster 100 (e.g., information specifying the role of the maintenance compute node 110, information specifying the role of the auxiliary compute nodes 154, information specifying the role of the installation server 116, etc.) and a list of the compute nodes 158 that each auxiliary compute node 154 serves.

[0032] According to an example embodiment, an installation stream can be piped over a secure shell (SSH) between two SSH connection endpoints. As an example, a given secondary computing node 154 and an installation server 116 can negotiate SSH parameters to set up two corresponding SSH endpoints. In an SSH session conducted over these SSH connections, the installation server 116 can transmit or pipe a tape archive (TAR) file (i.e., an "installation image" for this example) to the secondary computing node 154 as a "TAR stream." Here, a "TAR stream" refers to the contents of a TAR file that is transferred or piped between the SSH connections in a stream (rather than a TAR file that is sent as a single file). That is, according to an example embodiment, a TAR stream is generated at the sending side (e.g., the installation server or secondary computing node 154) while the TRA stream is sent until there are no more files and / or directories to send, at which point the sending of the data representing the files and / or directories is complete. According to an example embodiment, no intermediate files are created in the transmission of the TAR stream.

[0033] As a more specific example, in accordance with some embodiments, " / images / rhel8-compute" can be the directory where the root file system tree representing the root file system of the compute node resides. In accordance with example embodiments, the sender of the installation stream (e.g., installation server 116 or auxiliary compute node 154) does not cause a TAR archive file to come out of " / images / rhel8-compute", but rather the sender initiates the TAR stream such that the sender pipes all data corresponding to " / images / rhel8-compute" via commands as the data leaves the sender. In other words, in accordance with example embodiments, because streaming involves directly sending data representing the root file system until all data has been sent, no actual archive file is created at the sender. In accordance with further embodiments, other data packets and / or data transfer techniques can be used to transfer the installation stream. For example, in accordance with further embodiments, rsync-based file transfers can be used over an SSH pipe.

[0034] As an overview, cluster 100 may be started as follows. Each client compute node 150 transmits a boot request over the cluster network during an initial phase of its startup, and cluster manager 126 responds by causing maintenance compute node 110 (i.e., head compute node 114 or leader compute node 130) to provide a boot image to compute node 150. The boot image configures client compute node 150 to boot into a node installation environment 180 that includes a toolchain of cluster manager 126. As described herein, according to an example embodiment, node installation environment 180 includes a utility or tool referred to as "assistant manager 155" that manages and assists in setting up installation stream sharing for client compute nodes 150 that have been designated as auxiliary compute nodes 154, and node installation environment 180 includes a utility or tool referred to as "peer manager 159" that manages and assists in setting up reception of installation streams for non-auxiliary client compute nodes 158.

[0035] For example embodiments in which client compute node 150 stores its root file system in a volatile in-memory file system that does not survive a power outage or reset of client compute node 150 (e.g., embodiments in which client compute node 150 uses a TMPFS in-memory file system), node installation environment 180 first allocates system memory of client compute node 150 by mounting the in-memory file system. For example embodiments in which client compute node 150 stores its root file system in persistent file storage (e.g., client compute node 150 using a Network File System (NFS)), node installation environment 180 first creates partitions on the disk drives of client compute node 150 and then creates an initial file system to be used with the root file system.

[0036] After the partitions (if any) and file systems are created, the node installation environment 180 of the client computing node 150 issues or provides a mount request. Depending on the particular implementation, the mount request represents a request to transfer the installation image to the initial file system or TMPFS mount point of the client computing node 150. According to an example implementation, the install server 116 responds to the mount request according to one of three scenarios, depending on the role played by the requesting client computing node 150 in the transfer of the installation image.

[0037] For the first case, client compute node 150 has not been designated to participate in installation stream sharing (i.e., auxiliary compute node 154 is not involved), and install server 116 configures client compute node 150 to receive the installation stream directly from install server 116. For example, according to an example embodiment, install server 116 and the client compute node correspond to endpoints of an SSH connection, and install server 116 transmits a TAR stream containing the installation image to client compute node 150 via the SSH connection.

[0038] Combine Figure 1 refer to Figure 2 (Diagram 200 depicting a setup for installation stream sharing), for the second scenario, the client compute node 150 has been designated as a secondary compute node 154, and by using the secondary manager 155, the installation server 116 sends secondary instructions 210 to indicate to the node installation environment 180 that the compute node is a secondary compute node 154 and is to share the installation image received by the compute node in parallel with one or more other peer client compute nodes 158.

[0039] According to an example embodiment, the auxiliary instructions 210 include a list of peer client compute nodes 158 with which the auxiliary compute node 154 will share its installation stream. According to an example embodiment, after the installation stream to the auxiliary compute node 154 is started, installation stream sharing begins with the auxiliary manager 155 starting additional installation stream(s) to the peer compute node(s) 158 on the list. According to an example embodiment, as data bytes in the incoming installation stream are received by the auxiliary compute node 154, the auxiliary compute node 154 sends the data bytes to the peer client compute node(s) 158 on the list in parallel while the auxiliary compute node 154 also writes the data bytes to its own disk drive(s) or TMPFS (depending on the particular implementation).

[0040] For the third scenario, client computing node 150 has been designated as client computing node 158 to be the recipient of the installation stream provided by auxiliary computing node 154. Using peer manager 159 of client computing node 158, install server 116 sends redirection instructions 214. Although, in this scenario, client computing node 158 is not used to share the installation stream it receives with other computing nodes, instructions 214 inform client computing node 158 that install server 116 does not require the assistance of computing node 158, and instructions 214 further inform client computing node 158 that the installation stream will be serviced or provided by a particular auxiliary computing node 154, rather than provided directly by install server 116.

[0041] According to an example embodiment, if a given client computing node 158 is instructed by the installation server 116 to install an image that is being provided by a particular secondary computing node 154, the client computing node 158 waits for an installation session to begin from that particular secondary computing node 154. According to an example embodiment, for security purposes, the peer manager 159 of the client computing node 158 can set a firewall or other mechanism (e.g., SSH configuration) to block all secondary computing nodes 154 except the intended secondary computing node 154 that is to provide the installation image. In this way, the client computing node 158 can limit session and security exposure that could otherwise be exploited by an attacker. In addition, this information allows the client computing node 158 to avoid unwanted installation attempts.

[0042] As mentioned above, the installation stream between the two computing nodes can be transmitted through any of a variety of different delivery mechanisms (such as TAR stream delivered through SSH pipe, rsync delivered through SSH pipe, etc.). Regardless of which delivery mechanism is used, the installation stream is between the two computing nodes (the provider computing node and the recipient computing node); and the installation stream involves the complete transmission of the installation image from the provider computing node to the recipient computing node. After the recipient client computing node 150 receives the installation image and mounts its root file system, the client computing node 150 can then begin booting its operating system, which can include, for example, executing an operating system loader to load the operating system and transferring control of the recipient computing node 150 to the loaded operating system.

[0043] Figure 3 is a diagram 300 depicting installation flow sharing according to an example embodiment. Figure 1 refer to Figure 3 As part of installation stream sharing, a given secondary compute node 154 receives an image installation stream 304 from the install server 116. The secondary compute node 154 shares the image installation stream 304 in parallel with a designated set of peer client compute nodes 158 simultaneously by providing a corresponding installation stream 308 to each of these peer compute nodes 158.

[0044] Return Reference Figure 1 , the network architecture 140 can have multiple layers of network switches 141. When two network switches 141 are connected to extend the network architecture 140, the link between the two network switches 141 can potentially introduce a performance bottleneck for the installation image transfer. More specifically, the network switch to network switch communication can involve network cabling (e.g., Ethernet network cabling extending between the network switches), and unlike backplane communication within the network switches, the network cabling connection can be a relatively low bandwidth connection that can become a point of network saturation. According to example embodiments, the role of the client compute node 150 in the installation flow sharing can be selected to minimize the network switch to switch communication.

[0045] As a more specific example, if client compute nodes n1 through n24 are connected to network switch number one, for example, via a backplane connection, and client compute nodes n25 through n48 are connected to network switch number two via a backplane connection, it may be preferable to designate some of the client compute nodes n1 through n24 as auxiliary compute nodes 154 that share their installation flows with the other ones of nodes n1 through n24. For example, when setting up installation flow sharing, installation server 116 may instruct compute node n1 to assist compute nodes n2 through n13 in installation. Continuing with this example, it may also be preferable to not have client compute nodes n1 through n24 assist with the installation of client nodes n25 through n48. For example, when setting up installation flow sharing, installation server 116 may not have client compute node n1 assist with the installation of client compute node n26 to avoid saturating the link between network switch number one and network switch number two.

[0046] According to example embodiments, the selection of installation flow sharing roles can be determined based on the network hierarchy of the system. For example, if the client compute nodes 150 are named by rack and chassis number, and this naming follows the network topology, then, for example, it can be determined that the compute nodes in rack one and rack two are served by the same network switch. According to some embodiments, the installation server 116 can dynamically determine the installation flow sharing roles of a set of client compute nodes 150 dynamically assigned to the installation server 116. For example, according to some embodiments, the cluster manager 126 can wait for a predetermined number of installation requests and assign the installation server 116 to these requests; and the installation server 116 can assign the roles to the corresponding assigned client compute nodes 150. According to another example embodiment, the cluster manager 126 can determine the installation sharing roles and transmit these roles to the installation server 116. According to another example embodiment, the roles can be pre-specified (e.g., determined by a human administrator) and stored in the cluster manager database 127.

[0047] According to an example embodiment, the installation server 116 waits for an installation request, i.e., a request submitted by the node installation environment of a client computing node 150 to install an image. According to an example embodiment, the installation server 116 has knowledge of the topology of the cluster's network and is prepared to instruct certain client computing nodes 150 to replicate their installation stream or share their installation stream with other peer client computing nodes 150 in the cluster 100. According to an example embodiment, upon receiving the installation request, the installation server 116 sends out an auxiliary instruction 210 ( Figure 2 ) and redirection instruction 214( Figure 2For example, if 288 client computing nodes 150 are requesting installation images, installation server 116 may designate twelve of the client computing nodes 150 as secondary computing nodes 154 and instruct the remaining client computing nodes 150 to receive their installation images directly from these secondary computing nodes 154 or from installation server 116. This avoids network saturation because the number of streams from installation server 116 remains relatively low.

[0048] According to an example embodiment, the installation server 116 determines how many client computing nodes 150 are requesting the installation image and the location of the client computing nodes 150 in the network infrastructure. It should be noted that, depending on the particular implementation, all client computing nodes 150 may be restarted at once, or, according to an example embodiment, the client computing nodes 150 may be started at different times in corresponding batches.

[0049] According to an example embodiment, the actual signaling for the installation request can come from the client computing node 150 as each client computing node 150 begins its node installation environment 180. However, this can present a challenge for the installation server 116, as the installation server 116 should be able to scale the installation. One way for the client computing node 150 to assist in scaling the installation is for the client computing node 150 to contact the installation server 116 when the client computing node 158 performs its network boot. However, the installation server 116 may not know how many client computing nodes 150 will be requesting installation at any one time.

[0050] According to example embodiments, installation server 116 may wait a predetermined period of time for a group of client computing nodes 150 to boot up. For example, according to some embodiments, installation server 116 may wait a predetermined period of time, such as twenty seconds (as an example), after its first installation request before initiating any installation in the corresponding installation session. During these twenty seconds, it is likely that most of the client computing nodes 150 that have rebooted have contacted installation server 116 with installation requests. After the twenty seconds have expired, each installation server 116 may calculate how many client computing nodes 150 are behind each network switch for the group of client computing nodes 150 that have contacted installation server 116; and then, installation server 116 may construct a list that specifies auxiliary computing nodes 154, the client computing nodes 150 with which each auxiliary computing node 154 is to share its installation stream, and the client computing nodes 150 that are to receive their installation stream directly from installation server 116. According to example embodiments, after installation server 116 starts the installation stream, installation server 116 may queue installation requests from additional client computing nodes 150 for the next installation session.

[0051] According to another example embodiment, an installation server push technology can be used. For these embodiments, the system administrator can indicate to the installation server 116 which client computing nodes 150 are to be installed. The installation server 116 can create a list of shared roles for the installation flow in advance, because the installation server 116 has known that the installation server 116 will install each computing node 150 on it at the same time. The installation server 116 waits for all expected client computing nodes 150 to start their node installation environment 180 and check in with the installation server 116. After the expected client computing node 150 has registered, the installation server 116 can then initiate the provision of the installation flow. Because the installation server 116 knows all the client computing nodes 150 that will be started at the same time, the installation server 116 can construct all information to scale the installation in advance rather than dynamically.

[0052] According to an example embodiment, installation server 116 can work together as follows. Leader compute node 130 and head compute node 114 participate in a network shared storage. Therefore, when an image is ready to be installed, it is pushed to the shared storage area, and the exact same content is available to both head compute node 114 and leader compute node 130. This ensures that both head compute node 114 and leader compute node 130 agree on the content of the installation image. For embodiments where installation server 116 is formed by a container, this can also be used directly as part of the container service.

[0053] According to an example embodiment, each client compute node 150 is directed to a specific install server 116 for installation. In this way, according to an example embodiment, each install server 116 handles a subset of the cluster 100, which can significantly minimize network congestion. If all client compute nodes 150 in rack one, for example, are connected to a pair of stacked network switches, the install server 116 serving rack one can create a list of client compute nodes 150 for installation, and most of the network traffic associated with the installation image transfer remains within these stacked switches and does not saturate the network switch-to-switch links. If a second leader compute node 130 serves, for example, rack two, the install server 116 of the client compute nodes 150 on rack two can manage the contents of rack two and therefore will have minimal contact with the client compute nodes 150 in rack one.

[0054] As a more specific example of installation stream sharing for secondary compute node 154, according to some embodiments, secondary compute node 154 may initially execute a scaled-down Linux operating system as part of a "miniroot" or micro root file system that corresponds to a node installation environment 180 of secondary compute node 154. As part of node installation environment 180, secondary compute node 154 may use Linux process replacement. For example, secondary compute node 154 may pipe an input TAR stream (e.g., provided by installation server 116) through a Linux "socat" command and a Linux "tee" command in a manner that may start multiple commands to pass the input to multiple output programs at once. Thus, a single installation stream received by secondary compute node 154 may be copied to multiple output installation streams that are provided by secondary compute node 154 to client compute node 158.

[0055] For example, according to an example embodiment, the installation server 116 may execute or run a management node test script to clear a test directory, connect to the auxiliary computing node 154, and execute or run a computing node assist script that instructs the auxiliary computing node 154 to install itself and send the installation stream to the other client computing nodes 158.

[0056] As an example, the management node test script can be as follows:

[0057] #! / bin / bash

[0058] echo″purging old / tmp / testdir and creating an empty directory″

[0059] pdsh-g su-leader rm-rf / tmp / testdir

[0060] pdsh-g su-leader mkdir-p / tmp / testdir

[0061] echo″starting the TAR session, piped through ssh, to the cnode helper″

[0062] echo″leader1 is the helper, the other leaders are redirected installnodes.″

[0063] time TAR-BS--numeric-owner--one-file-system-C / opt / clmgr / image / images / foo-cf

[0064] -.|ssh leader1 / root / cnode-helper.sh

[0065] echo "Size of / tmp / testdir on the nodes..."

[0066] pdsh-g su-leader du-sh / tmp / testdir

[0067] In the script above, "pdsh" is a command that allows running commands on many compute nodes in parallel, and "su-leader" is the name of a group that contains a list of compute nodes.

[0068] According to an example embodiment, the auxiliary computing node 154 executes a script for receiving an installation stream from the installation server 116 , copying the received installation stream into eight output installation streams, and sending the eight output installation streams to eight corresponding peer client computing nodes 158 .

[0069] An example script that may be executed by the secondary compute node 154 is shown below:

[0070] #! / bin / bash

[0071] #Take stdin TAR stream from the admin node

[0072] #extract the image locally and forward to other nodes

[0073] cat|\

[0074] tee>(socat-EXEC:′ssh leader2.head TAR-BS--numeric-owner--one-file-system--acls--xattrs-C / tmp / testdir-xpf-′)\

[0075] >(socat-EXEC:′ssh leader3.head TAR-B-S--numeric-owner--one-file-system--acls--xattrs-C / tmp / testdir-xpf-′)\

[0076] >(socat-EXEC:′ssh leader4.head TAR-B-S--numeric-owner--one-file-system--acls--xattrs-C / tmp / testdir-xpf-′)\

[0077] >(socat-EXEC:′ssh leader5.head TAR-B-S--numeric-owner--one-file-system--acls--xattrs-C / tmp / testdir-xpf-′)\

[0078] >(socat-EXEC:′ssh leader6.head TAR-B-S--numeric-owner--one-file-system--acls--xattrs-C / tmp / testdir-xpf-′)\

[0079] >(socat-EXEC:′ssh leader7.head″TAR-B-S--numeric-owner--one-file-system--acls--xattrs-C / tmp / testdir-xpf-′)\

[0080] >(socat-EXEC:′ssh leader8.head TAR-B-S--numeric-owner--one-file-system--acls--xattrs-C / tmp / testdir-xpf-′)\

[0081] >(socat-EXEC:′ssh leader9.head TAR-B-S--numeric-owner--one-file-system--acls--xattrs-C / tmp / testdir-xpf-′)\

[0082] |TAR-B-S--numeric-owner--one-file-system--acls--xattrs-C / tmp / testdir-xpf-

[0083] According to further example embodiments, the command for the secondary computing node 154 may be executed by the installation server 116. That is, according to example embodiments, the exact command for the secondary computing node 154 may be fully dictated by the incoming remote SSH command.

[0084] Other embodiments are contemplated within the scope of the appended claims. For example, as described herein, installation stream sharing includes one level of sharing, i.e., secondary compute node 154 shares its installation stream with other compute nodes 158. However, according to other embodiments, there may be multiple levels of installation stream sharing. For example, according to some embodiments, a first client compute node 150 may share its installation stream with a second client compute node 150, and the second client compute node 150 may share its installation stream with a third client compute node 150.

[0085] refer to Figure 4 According to an example embodiment, technique 400 includes, per block 404, a first computing node in a cluster of nodes receiving a communication from a cluster maintenance node in the cluster. The communication instructs the first computing node to provide an installation image received by the first computing node to a second computing node in the cluster. The first node and the second node are peers. Technique 400 includes sharing (block 408) a first installation stream that delivers the image to the first computing node. Sharing the first installation stream includes, while the first computing node is receiving the first installation stream, the first computing node providing a second installation stream to deliver portions of the image received via the first installation stream to the second computing node.

[0086] refer to Figure 5 According to an example embodiment, computing node 500 includes a processor 504 and a memory 508. Memory 508 stores instructions 512 that, when executed by processor 504, cause processor 504 to: identify a plurality of secondary computing nodes that each receive a corresponding installation stream; instruct each secondary computing node to share the installation stream transmitted by the first computing node to a corresponding set of peer computing nodes; and transmit the installation stream to the plurality of secondary nodes.

[0087] refer to Figure 6 According to an example embodiment, a non-transitory machine-readable storage medium 600 stores instructions 604 that, when executed by a first computing node (machine) in a computing node cluster, cause the first computing node to receive an instruction instructing the first computing node to share a first installation stream with a plurality of second computing nodes. When executed by the first computing node, the instructions 604 further cause the first computing node to receive the first installation stream and share the first installation stream with the plurality of second computing nodes.

[0088] According to an example embodiment, sharing the first installation stream further includes, before the first computing node stores, in a storage device of the first computing node, data representing the image received from the first installation session, the first computing node transmitting the data to the second computing node via the second installation stream. A particular advantage is that installation stream sharing can be used to quickly transfer the installation image across the cluster to minimize computing node startup time.

[0089] According to example embodiments, the first computing node may access data representing a list of computing nodes with which the first computing node is to share the first installation flow. A particular advantage is that sharing roles may be specified based on network topology to prevent points of network saturation.

[0090] According to example embodiments, sharing the first installation flow may further include: the first computing node sharing the first installation flow with each computing node in the computing node list. A particular advantage is that sharing roles can be designated based on network topology to prevent points of network saturation.

[0091] According to an example embodiment, a first computing node may request an installation session and a node installation environment, and an installation server may initiate an installation session in response to the request to deliver a first installation stream to the first computing node. A particular advantage is that the installation server may wait a predetermined time for an installation request, allowing image sharing roles to be designated based on the number of installation streams provided by the server and the network topology.

[0092] While the present disclosure has been described with respect to a limited number of embodiments, numerous modifications and variations will become apparent to those skilled in the art having the benefit of this disclosure. It is intended that the appended claims cover all such modifications and variations.

Claims

1. A method for sharing an image installation image stream, comprising: a first compute node in a cluster of nodes receiving a communication from an installation server of the cluster, the communication instructing the first compute node to provide an installation image received by the first compute node to a second compute node in the cluster, wherein the first compute node and the second compute node are peers and the installation image includes data representing a root file system for booting the first compute node and the second compute node; receiving a first installation stream that transfers the installation image to the first computing node; and sharing the first installation stream, wherein sharing the first installation stream comprises: while the first computing node is receiving the first installation stream, the first computing node providing a second installation stream to transfer portions of the installation image received via the first installation stream to the second computing node, The first computing node and the second computing node are allocated by the installation server based on the network topology. Wherein, sharing the first installation flow further includes: The first computing node transmits the data representing the image received by the first computing node to the second computing node via the second installation flow before the data is stored in the storage device of the first computing node.

2. The method of claim 1, further comprising: The first computing node accesses data representing a list of computing nodes with which the first computing node is to share the first installation flow, wherein the list of computing nodes includes the second computing node.

3. The method according to claim 2, wherein: Sharing the first installation flow further includes the first computing node sharing the first installation flow with each computing node in the list of computing nodes.

4. The method of claim 1, further comprising: The first computing node requests an installation session in a node installation environment; as well as The installation server begins an installation session in response to the request to transmit the first installation stream to the first computing node.

5. The method according to claim 1, wherein Sharing the first installation flow includes: the first computing node executing a script, the script being used to establish byte streams corresponding to the first installation flow and the second installation flow and to transmit data between the first installation flow and the second installation flow.

6. The method of claim 1, wherein: Sharing the first installation stream further includes the first computing node executing commands for reading data from the first installation stream and simultaneously writing data to a plurality of other installation streams, wherein the plurality of other installation streams includes the second installation stream.

7. A first computing node, comprising: processor; as well as a memory for storing instructions that, when executed by the processor, cause the processor to: Identifying a plurality of auxiliary computing nodes for receiving a plurality of installation streams, wherein each auxiliary computing node of the plurality of auxiliary computing nodes receives a corresponding installation stream of the plurality of installation streams to install a root file system on the auxiliary computing node; instructing a given secondary computing node of the plurality of secondary computing nodes to share a first installation stream received by the given secondary computing node with a corresponding set of peer computing nodes; and transmitting the plurality of installation streams to the plurality of auxiliary computing nodes, The instructions, when executed by the processor, further cause the processor to identify at least one of the plurality of auxiliary computing nodes and an assignment to the corresponding set of peer computing nodes based on a network topology, wherein instructing a given auxiliary computing node of the plurality of auxiliary computing nodes to share a first installation stream received by the given auxiliary computing node with the corresponding set of peer computing nodes comprises: while the given secondary computing node is receiving the first installation stream, the given secondary computing node providing a plurality of second installation streams to transfer portions of the root file system received via the first installation stream to the corresponding set of peer computing nodes, and Before the given secondary computing node stores the received data representing the root file system in a storage device of the given secondary computing node, the given secondary computing node transmits the data to the corresponding set of peer computing nodes via the plurality of second mount flows.

8. The first computing node according to claim 7, wherein: The instructions, when executed by the processor, further cause the processor to perform at least one of identifying the plurality of auxiliary computing nodes or identifying a corresponding set of peer computing nodes for each of the plurality of auxiliary nodes to minimize network switch to network switch communications.

9. The first computing node according to claim 7, wherein: The instructions, when executed by the processor, further cause the processor to transmit a secure shell (SSH) command to the given secondary computing node to cause the given secondary computing node to perform the sharing.

10. The first computing node according to claim 7, wherein: The first computing node and the plurality of auxiliary computing nodes are part of a cluster, and wherein the instructions, when executed by the processor, further cause the processor to: In response to the cluster being started, delaying for a predetermined period of time to receive an installation request; and Based on the installation request and a network topology, computing nodes in the cluster are designated as the plurality of auxiliary computing nodes and the set of peer computing nodes.

11. The first computing node according to claim 7, wherein: The instructions, when executed by the processor, further cause the processor to: Computing nodes in the cluster are designated as the plurality of auxiliary computing nodes and the set of peer computing nodes based on a predetermined list.

12. A non-transitory machine-readable storage medium storing instructions that, when executed by a first computing node in a cluster of computing nodes, cause the first computing node to: receiving a communication from an installation server in the cluster to instruct the first computing node to share a first installation image received by the first computing node with a plurality of second computing nodes in the cluster, wherein The first installation image includes data representing a root file system for booting the first computing node and the plurality of second computing nodes; as well as receiving a first installation stream and sharing the first installation stream with the plurality of second computing nodes while the first computing node is receiving the first installation stream, wherein the installation server allocates the first computing node and the plurality of second computing nodes based on a network topology; The sharing includes the first computing node providing a plurality of second installation flows, and the instructions, when executed by the first computing node, further cause the first computing node to transmit the first data received from the first installation flow to the plurality of second installation flows before storing the data.

13. The storage medium according to claim 12, wherein: The sharing includes the first computing node providing a plurality of second installation streams, and the instructions, when executed by the first computing node, further cause the first computing node to execute commands for reading data from the first installation stream and simultaneously writing the data to the plurality of second installation streams.

14. The storage medium according to claim 12, wherein: Receiving the installation image includes receiving an archive stream representing a root file system.

15. The storage medium according to claim 12, wherein: The instructions, when executed by the first computing node, further cause the first computing node to receive commands from the installation server to be executed by the first computing node to share the first installation stream.

16. The storage medium according to claim 12, wherein: The instructions, when executed by the first computing node, further cause the first computing node to establish a secure shell (SSH) connection with the plurality of second computing nodes and to transmit a tape archive stream representing a root file directory using each of the SSH connections.

17. The storage medium according to claim 12, wherein: The instructions, when executed by the first computing node, cause the first computing node to execute a script for sharing the installation flow.

Images