CN107533482B - Combine operating system volumes - Google Patents

Abstract

Some examples provide a system including an adjacent computing device, the adjacent computing device including a deployed operating system (OS) volume, and a corresponding adjacent bit table corresponding to the deployed OS volume. The system may include a target computing device, the target computing device including a target operating system (OS) volume. The target computing device may determine a target bit table corresponding to the target OS volume. Each bit in the target bit table indicates whether a data block of the target OS volume is different relative to a base OS volume. The target computing device may determine a first set of data blocks that is equivalent to a second set of data blocks of the deployed OS volume based on the bit table. The target computing device may receive at least one data block from the second set of data blocks from the adjacent computing device and assemble a target OS.

Description

Combine operating system volumes

Background technique

A computing device may execute an operating system. The operating system may manage the utilization of the resources of the computing device.

Description of drawings

In the following detailed description, and with reference to the accompanying drawings, some examples are described, in which:

Figure 1 is a conceptual diagram of an example computing system that can combine operating system volumes:

2 is another conceptual diagram of an example computing system that can combine operating system volumes.

3 is another conceptual diagram of an example computing system that can combine operating system volumes;

4 is a flowchart of an example method for combining operating system volumes:

5 is a flowchart of an example method for combining operating system volumes; and

6 is a block diagram of an example for combining operating system volumes.

Detailed ways

A data center may include multiple computing devices, eg, servers. Each of the servers executes an operating system (OS). Each operating system must be installed before the server's resources can be used. In some environments, a target computing device (eg, a server that must be preallocated) may request OS media (eg, an OS volume) to install the operating system. A pre-allocated computing device (eg, a media server) may transfer the volume to the target computing device via a link (eg, a network link, etc.).

In response to receiving the request for the request or command, the media server may stream the OS image including the target OS volume for the target computing device from the media server to the target computing device. The target computing device can receive and install the OS image from the media server.

However, streaming media from a media server is relatively slow, which can lead to lengthy OS installation times. A media server may be streaming OS images slowly due to various factors. For example, a media server may be limited in throughput based on available network bandwidth. The pre-allocated number of simultaneous connections between computing devices and media servers further divides the already constrained network bandwidth. The OS pre-allocation speed of the media server may also be limited by the maximum number of input-output operations (IOPS) pre-allocated to the media server. Like network bandwidth, the IOPS of the media server is divided between each of the computing devices that the media server currently pre-allocates.

The present disclosure relates to rapidly pre-allocating an OS volume of a target computing device (eg, a server) and reducing the load on the media server during pre-allocation. According to the present disclosure, a target computing device determines a target operating system volume to preallocate. Based on the target OS volume, the target computing device generates a bit table. Each bit in the bit table indicates whether multiple blocks of the target OS volume are different relative to the base OS volume.

The target server determines neighboring computing devices and requests bit tables for neighboring computing devices. Neighboring computing devices may include, for example, VMs on the same blade, computing in the same enclosure, in the same interconnect, in the same rack, and/or at the same switch level as the target computing device equipment. The adjacent computing device also has the same operating system version as the target OS volume to be preallocated.

By comparing the corresponding bits in the target bit table and the adjacent bit table, the target server determines a set of data blocks in the adjacent server's adjacent OS volumes and which correspond to a set of data blocks in the target OS volume. The target server then requests at least some of the data blocks from neighboring computing devices, and combines the target OS volumes.

To assemble the target OS volume, the target computing device receives the requested block and stores it in random access memory (RAM) of the target computing device, and copies the data block from the RAM to coupled with the target computing device, eg, based on a memory map storage device.

With multi-threading, multiple simultaneous network connections, and/or multiple high-speed interconnects, a target computing device can receive blocks of data from multiple adjacent computing devices simultaneously, the techniques of the present disclosure can rapidly reduce OS pre-allocation time, i.e., in Time spent mounting and executing the OS volume on the target computing device. As an example, the techniques of the present disclosure can reduce OS pre-allocation time from 45 minutes or more to less than a minute, and can allow concurrent pre-allocation of large numbers of servers (eg, thousands of servers).

1 is a conceptual diagram of an example computing system that can combine operating system volumes. Computing system 100 is shown in FIG. 1 . Computing system 100 includes a target computing device 102 and a plurality of neighboring computing devices 108A- 108N (collectively "neighboring computing devices 108"), where N is any number. In various examples, target computing device 102 and neighboring computing devices 108 may include servers.

Target computing device 102 and adjacent computing device 108 may be located in the same enclosure, eg, in the same blade server, in the same rack, or may be connected to the same switch. In the example of FIG. 1 , target computing device 102 and neighboring computing device 108 are connected via interconnect 106 . Interconnects 106 may include any number of system-level interconnects, eg, blade servers, and/or network connections. In various examples, interconnect 106 may provide extremely high throughput, eg, 40 or 60 gigabits per second (gbps) or higher.

Each of the neighboring computing devices 108 includes a corresponding deployed OS volume 116A-116N (deployed OS volume 116). In the example of FIG. 1, the deployed OS volumes 116 may all include the same OS version. For example, same version of Windows, virtual machine host, Linux, etc.

Each of the deployed OS volumes 116 includes a corresponding data block 118A-118N (collectively "data blocks 118"). In various examples, data block 118 may comprise a single data block (eg, 4 kilobytes (4KB) in size) or multiple blocks of an OS volume.

Based on the respective sets of data blocks 118A-118N, adjacent computing devices 108A-108N may generate adjacent bit tables 110A-110N ("adjacent bit tables 110"). Each of the adjacent bit tables 110 includes a corresponding plurality of bits. Each of these bits indicates whether the multiple data blocks are different relative to the corresponding multiple data blocks of the base OS volume (eg, base OS volume 104). Each neighboring computing device may generate a corresponding neighboring bit table by comparing the corresponding data block of the deployed OS volume with the corresponding data block of the base OS volume 104 .

As an example, neighbor computing device 108A may generate neighbor bit table 110A. Each "0" bit in bit table 110A indicates that the corresponding plurality of data blocks 118A are different from the corresponding plurality of blocks of the base OS volume 104 . Each "1" bit in bit table 110A indicates that the corresponding plurality of data blocks 118A are not different from the corresponding plurality of blocks of the base OS volume 104 .

The adjacent bit table 110A has the value "01111110". It should be understood that the bit table 110A may be significantly shorter than the actual bit table for purposes of illustration and example. The first and last bits of bit table 110A are equal to zero. Therefore, the plurality of data blocks 118A corresponding to the first 0 bits and the plurality of data blocks 118A corresponding to the last 0 bits are different from the corresponding plurality of data blocks of the base OS volume 104 . The plurality of data blocks 118A corresponding to the "1" bit in the adjacent bit table 110A are no different from the corresponding plurality of blocks of the base OS volume 104 .

Target computing device 102 may similarly determine target bit table 112 for target OS volume 114 to be deployed. Similar to the process described above with respect to the neighboring computing device 108 , the target computing device 102 may determine the target bit table based on whether the corresponding plurality of data blocks of the target OS volume 114 are different from the corresponding plurality of data blocks of the base OS volume 104 112.

Target computing device 102 may determine which computing devices include neighboring computing devices 108 based on indications received from a pre-allocated computing device (eg, a media server or a pre-allocation apparatus). Neighboring computing device 108 has the same operating system version as the operating system of target OS volume 114 . Neighboring computing device 108 may include a virtual machine on the same blade, a computing device connected to the same switch level, same interconnect, and/or located in the same enclosure as target computing device 102 .

The target computing device 102 requests the neighbor bit table 108 from the neighbor computing device 108 . Neighbor computing device 108 may send neighbor bit table 110 to target computing device 102 via interconnect 106 . Target computing device 102 compares the bits in target bit table 112 to corresponding bits in each of the adjacent bit tables.

If the corresponding bits in the target bit table and the adjacent bit table are equal to 1, then the target computing device 102 determines that the corresponding plurality of data blocks of the target OS volume 114 are not different from the corresponding data blocks of the base OS volume 104 . Thus, for a bit in target bit table 112 equal to "1" and a corresponding bit in adjacent bit table 110 having a corresponding bit equal to 1, the data block of target bit table 112 and the corresponding data of deployed OS volume 116 Blocks are equivalent. Because the corresponding data blocks of target OS volume 114 and deployed OS volume 116 are equivalent, target computing device 102 may use corresponding data blocks received from neighboring computing devices 108 to combine target OS volume 114 .

In an example in which the corresponding bits in the target bit table 112 and one of the adjacent bit tables in the adjacent bit table 110 are not equal, the corresponding data blocks of the target OS volume 114 are not equivalent to the corresponding data blocks of the deployed OS volume 116 , and the target computing device 102 does not request or combine the target OS volume 114 based on these blocks.

The target computing device 102 determines that the corresponding plurality of data blocks of the target OS volume 114 are different from the corresponding data blocks of the base OS volume 104 if the corresponding bits in the target bit table and the adjacent bit table are equal to zero. For chunks that are different from the base OS volume 104, the target computing device 102 requests chunks from a media server (eg, media server 218). Computing device 102 may assemble target OS volume 114 based on the received data blocks.

Since the corresponding data blocks of target OS volume 114 and deployed OS volume 116 are equivalent, target computing device 102 may use corresponding data blocks received from neighboring computing devices 108 to combine target OS volume 114 . The target computing device 102 may request at least one of these equivalent blocks from one or more neighboring computing devices 108 .

As a specific example, the last bit in the target bit table 112 is equal to "1". Based on bit table 110, target computing device 102 determines that the corresponding last bit in adjacent bit table 110B and the corresponding last bit in adjacent bit table 110N are also equal to "1". Based on determining that the corresponding last bit in adjacent bit table 110B and the corresponding last bit in adjacent bit table 110N are equal to 1, target computing device 102 may request data in blocks 118B and 118N of deployed OS volumes 116B and 116N of at least some. Target computing device 102 may compare corresponding bits in target bit table 112 with corresponding bits in bit table 110 to determine a second set of data blocks that target computer 102 may request from neighboring computing devices 108 . The target computing device 102 may request at least one chunk from the second set of chunks available from the neighboring computing device 108 .

Accordingly, computing system 100 is an example of a computing system that includes a plurality of adjacent computing devices 108 , where each of the adjacent computing devices includes: Operating system (OS) volumes (eg, 116A-116N) are deployed, and corresponding adjacent bit tables 110 corresponding to the corresponding deployed OS volumes, wherein bits in the corresponding adjacent bit table 110 indicate the corresponding deployed Whether the OS volume 116 is different from the base OS volume (eg, base OS volume 104).

Computing system 100 includes target computing device 102 , which includes target OS volume 114 . Target computing device 102 may determine target bit table 112 corresponding to target OS volume 114 . Each bit in the target bit table 112 corresponds to a data block in the first set of data blocks of the target OS volume 114 and indicates whether the data blocks of the target OS volume 114 are different relative to the base OS volume 104 .

The target computing device 102 may request, from each of the neighboring computing devices 108 , a respective neighbor bit table 110 associated with each of the respective deployed OS volumes 116 . The target computing device 102 may determine the second set of data blocks 120 that the target OS volume 114 includes. The second group of blocks is determined based on whether corresponding bits in adjacent bit table 110 and target bit table 112 are equal.

The target computing device 102 requests at least one data block in the second set of data blocks 110 from the neighboring computing device 108 , receives the requested at least one data block in the second set of data blocks 122 from the neighboring computing device 108 , and The target OS volume 114 is assembled based on at least one data block in the second set of data blocks received from the adjacent computing device 108 .

2 is another conceptual diagram of an example computing system that may perform composition of operating system volumes. FIG. 2 shows computing system 200 . Computing system 200 includes media server 218 , target computing device 102 , and neighboring computing devices 108 . Media server 218 , target computing device 102 , and neighboring computing devices 108 may be connected via interconnect 106 .

In the example of FIG. 2 , target computing device 102 includes network interface 214 , target OS volume 114 , random access memory (RAM) 204 , target bit table 112 , memory map 208 , and storage 212 . Storage 212 may include storage coupled to target computing device 102 .

To assemble the target OS volume 114 , the target computing device 102 receives the requested block of data from the neighboring computing device 108 , and the target computing device stores the received block in the RAM 204 . Target computing device 102 may store the received at least one block of data in RAM 204 using a rolling window memory map. In a rolling window memory map, received blocks of data are stored in RAM 204 in a rolling fashion, ie, to sequential memory addresses as blocks are received. Once the maximum addressable amount of RAM 204 is written, the block at the beginning of RAM 204 is overwritten. Periodically (eg, every 2 milliseconds), target computing device 102 may copy at least one block of data stored in RAM 204 to a corresponding block of storage 212 based on memory map 208 . The memory map 208 may be stored in the RAM 204 and indicates the mapping between the received data block of the target OS volume 114 stored at a particular address in the RAM 204 and the corresponding block address in the storage device 212 for the data block.

Target computing device 102 may use network interface 214 to receive data blocks. Network interface 214 may include any number and/or different interfaces capable of communicating with interconnect 106 . The target computing device 102 may use the plurality of network interfaces 214 to receive the requested data blocks, eg, data blocks in the second set of data blocks 122 . In various examples, the target computing device 102 may initiate a separate connection with each of the neighboring computing devices 108 and/or the media server 218 from which the target computing device 102 received data chunks. In various examples, target computing device 102 executes a separate thread for each connection of network interface 214 for receiving data blocks.

In response to receiving the request to send the data block 118 of the deployed OS volume 116, the media server 218 may determine the resource utilization of the neighboring computing devices 108, eg, central processing unit (CPU) usage, IO utilization (eg, IOPS), network Bandwidth, Network Interface Card (NIC) usage, memory usage, etc. Based on the determined resource utilization, the media server 218 may instruct and/or the target computing device 102 may determine the number of the second set of data blocks to request from the neighboring computing device 108 . In various examples, neighboring computing devices 108 with higher resource utilization may send fewer blocks of data. Accordingly, the neighboring computing devices 108 may transmit at least one block of the second set of data blocks 122 based on the resource utilization of the neighboring computing devices 108 .

The media server 218 may store the base OS volume 104 and may send information related to the base OS volume 104 (eg, a bit table of the base OS volume 104 ) to the target computing device 102 . In various examples, target computing device 102 may determine the data of target OS volume 114 based on whether a bit in bit table 112 is not equal to any of the corresponding bits of each adjacent bit table in adjacent bit table 110 Blocks are not available from neighboring computing devices 108 . In response to determining that the data chunk is not available, the target computing device 102 may request the unavailable data chunk from the media server 218 . Target computing device 102 may receive the requested data block from media server 218 and assemble target OS volume 114 based on the received data block.

In various examples, media server 218 may determine neighboring computing devices 108 . The media server 218 may determine the neighboring computing device 108 based on whether the computing device is a VM on the same blade as the target computing device 102 and/or whether the computing device is in the same enclosure, the same interconnect as the target computing device 102 , and/or in the same rack, and/or at the same switch level as the target computing device 102 . The media server 218 may also determine that a computing device is a neighboring computing device based on whether the computing device has the same operating system version as the pre-allocated target OS volume 114 .

The media server 218 may determine which of the neighboring computing devices 108 is closest (ie, has the highest volume transfer throughput) to the ranking of the target computing device 102 . The media server 218 may generate an indication of the ranking and send the ranking to the target computing device 102 . The media server 218 may also generate an indication of the number of chunks that the target computing device 102 is to obtain from neighboring computing devices 108 based on the resource utilization described above.

3 is a conceptual diagram that may illustrate examples of data blocks, bitmaps, and bit tables. FIG. 3 shows computing system 300 . Computing system 300 includes OS data block 302 . OS data blocks 302 may include data blocks as described in this disclosure. In various examples, OS data block 302 may include operating system information, and may exclude information where computing devices differ significantly from one another, eg, application data. Each of the OS data blocks 302 may include 4 kilobyte blocks, which are logically addressable by the computing device.

Based on each of the OS data blocks 302 , a computing device (eg, target computing device, media server 218 , and/or neighboring computing devices 108 ) may generate a cluster bitmap 304 . Each bit in cluster bitmap 304 corresponds to a data block of OS data block 302 . Each bit in the cluster bitmap 304 also indicates whether the corresponding data block is different relative to the base OS volume (eg, base OS volume 104). Each of neighboring computing devices 108, target computing device 102, and/or media server 218 determines a corresponding bit table (eg, bit table 306) based on the corresponding cluster bitmap (eg, cluster bitmap 304). In various examples, bit table 306 may include 16-byte values. In various examples, the computing may allocate dedicated network ports for other computing devices to query bit tables and/or cluster bitmaps.

As an example of determining a cluster bitmap, a computing device (eg, neighboring computing device 108A) may compute each bit in bit table 306 based on a plurality of corresponding bits in cluster bitmap 304 based on set/crossover logic. For example, if all multiple corresponding bits in cluster bitmap 304 are equal to "1", then the first (leftmost) bit of bit table 306 is equal to "1". However, if any of the corresponding plurality of bits in cluster bitmap 304 is equal to zero, then the corresponding bit in bit table 306 is equal to zero.

In various examples, an IO subsystem of a computing device (eg, one of neighboring computing devices 108 ) may determine when a block of an OS volume (eg, one of data blocks 118 ) changes. The IO subsystem can detect that a write to an address associated with a data block of the operating system has occurred. Based on the detected writes, the IO subsystem may determine whether to update the corresponding bits in the cluster bitmap 304 based on whether the written data blocks are different relative to the base OS volume. The IO subsystem may also determine whether to update the corresponding bit in the bit table 306 based on the corresponding bit in the cluster bitmap 304 .

4 is a flowchart of an example method for combining operating system volumes. FIG. 4 includes method 400 . Method 400 may be described below as being implemented or performed by a system (eg, computing system 100 (FIG. 1) or computing system 200 (FIG. 2)). In various examples, method 400 may be performed by hardware, software, firmware, or any combination thereof. Other suitable systems and/or computing devices may also be used. The method 400 may be implemented in the form of executable instructions stored on at least one machine-readable storage medium of the system and executed by at least one processor of the system. In various examples, the machine-readable storage medium is non-transitory. Alternatively or additionally, method 400 may be implemented in the form of electronic circuitry (eg, hardware). In alternate examples of the present disclosure, one or more blocks of method 400 may be performed substantially concurrently or in an order different from that shown in FIG. 4 . In alternate examples of the present disclosure, method 400 may include more or fewer blocks than those shown in FIG. 4 . In some examples, one or more of the blocks of method 400 may continue at certain times and/or may be repeated.

Method 400 may begin at block 402, at which point a computing device of a computing system (eg, target computing device 102 ) may receive a deployed operating system (OS) corresponding to a neighboring computing device (eg, neighboring computing device 108A) ) volume (eg, deployed OS volume 116A) adjacent bit table (eg, adjacent bit table 110A), wherein each bit in adjacent bit table 110A corresponds to a data block of deployed OS volume 116A, and Indicates whether the data blocks of the deployed OS volume are different relative to the base OS volume (eg, base OS volume 104).

Method 400 may continue to block 404, at which point target computing device 102 may determine a target bit table (eg, target bit table 112 ) that corresponds to a target OS volume of target computing device 102 (eg, target OS volume 114 ) ), where each bit in the target bit table 112 corresponds to a data block in the first set of data blocks 120 of the target OS volume 114 and indicates whether the data blocks of the target OS volume 114 are different relative to the base OS volume 104 .

The method 400 may proceed to block 406, where the target computing device 102 may proceed to determine the second set of data blocks 122 of the target OS volume 114 included by the deployed OS volume 116A. Determining the second set of data blocks 122 may be based on whether corresponding bits in the adjacent bit table 110A and the target bit table 112 are equal. The second set of data blocks 122 is a subset of the first set of data blocks 120 .

The method 400 may continue to block 408, where the target computing device 102 may request at least one data block of the second set of data blocks 122 from the neighboring computing device 108A. The method 400 may further proceed to block 410, where the target computing device 102 may receive at least one data block of the second set of data blocks 122 from the neighboring computing device 108A. The method 400 may continue to block 412 where the target computing device 102 may combine the target OS volume 114 based on at least one data block in the second set of data blocks 122 received from the adjacent computing device 108A.

5 is a flowchart of an example method for combining operating system volumes. FIG. 5 shows method 500 . Method 500 may be described below as being implemented or performed by a system (eg, computing system 100 (FIG. 1) or computing system 200 (FIG. 2)). Other suitable systems and/or computing devices may also be used. The method 500 may be implemented in the form of executable instructions stored on at least one machine-readable storage medium of the system and executed by at least one processor of the system. Method 500 may be implemented by hardware, software, firmware, or any combination thereof.

Alternatively or additionally, method 500 may be implemented in the form of electronic circuitry (eg, hardware). In alternate examples of the present disclosure, one or more blocks of method 500 may be performed substantially concurrently or in a different order than that shown in FIG. 5 . In alternate examples of the present disclosure, method 500 may include more or fewer blocks than those shown in FIG. 5 . In some examples, one or more of the blocks of method 500 may continue at certain times and/or may be repeated.

In various examples, method 500 may begin at block 502, at which point a computing device of a computing system (eg, target computing device 102 ) may receive data corresponding to a neighboring computing device (eg, neighboring computing device 108A) A neighbor bit table (eg, neighbor bit table 110A) of a deployed operating system (OS) volume (eg, deployed OS volume 116A), where each bit in neighbor bit table 110A corresponds to the deployed OS volume 116A and indicates whether the data blocks of the deployed OS volume are different relative to the base OS volume (eg, base OS volume 104).

Method 500 may continue to block 504, at which point target computing device 102 may determine a target bit table (eg, target bit table 112 ) that corresponds to a target OS volume of target computing device 102 (eg, target OS volume 114 ) ), where each bit in the target bit table 112 corresponds to a data block in the first set of data blocks 120 of the target OS volume 114 . Each bit in the target bit table 112 also indicates whether the corresponding data block of the target OS volume 114 is different relative to the base OS volume.

The method 500 may continue to block 506, where the target computing device 102 may determine neighboring computing devices (eg, neighboring computing devices 108N). To determine whether a computing device is a neighboring computing device, the target computing device 102 or the media server 218 may determine whether the computing device is located in at least one of: the same rack as the target computing device 102, the same enclosure as the target computing device 102 , and/or connected to the same switch as the target computing device 102 . If the computing device also has the same operating system version as the target computing device 102, the target computing device 102 or the media server 218 may further determine that the computing device is a neighboring computing device.

The method 500 may proceed to block 508, where the target computing device 102 may proceed to determine the second set of data blocks 122 of the target OS volume 114 included by the deployed OS volume 116A. The second set of data blocks 122 may be a subset of the first set of data blocks 120 . Determining the second group of blocks is based on whether corresponding bits in adjacent bit table 110A and target bit table 112 are equal.

The method 500 may continue to block 510, where the target computing device 102 may request at least one data block of the second set of data blocks 122 from the neighboring computing device 108A. The method 500 may further proceed to block 512, where the target computing device 102 may receive at least one data block of the second set of data blocks 122 from the neighboring computing device 108A.

Method 500 may proceed to block 514, where target computing device 102 may determine a third set of data blocks that are not in the In the second set of data blocks of the deployed OS volume. The method 500 may continue to block 516, at which point the target computing device 102 may request at least one data chunk of the third set of data chunks 216 from a media server (eg, media server 218). The method 500 may continue to block 518 , at which point the target computing device 102 may receive at least one data chunk from the third set of data chunks 216 from the media server 218 .

The method 500 may continue to block 520, where the target computing device 102 may combine the target OS volume 114 based on at least one data block in the second set of data blocks 122 received from the adjacent computing device 108A. In some examples, to combine target OS volume 114 , target computing device 102 may store at least one data block in second set of data blocks 122 in RAM 204 of target computing device 102 . To store at least one data block in the second set of data blocks, the target computing device 102 may use a rolling window memory map. To combine target OS volume 114, target computing device 102 may also copy at least one data block of target OS stored in RAM 204 to a corresponding block of target computing device 102's storage device (eg, storage 212) based on the memory map.

6 is a block diagram of an example for combining operating system volumes. In the example of FIG. 6 , system 600 includes processor 610 and machine-readable storage medium 620 . Although the following description refers to a single processor and a single machine-readable storage medium, the description may also apply to systems having multiple processors and multiple machine-readable storage media. In such examples, instructions may be distributed (eg, stored) across various machine-readable storage media, and instructions may be distributed (eg, executed by multiple processors) across multiple processors.

Processor 610 may be one or more central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieving and executing instructions stored in machine-readable storage medium 620 . In the particular example shown in FIG. 6, processor 610 may fetch, decode, and execute instructions 622, 624, 626, 628 to assemble operating system volumes.

As an alternative or in addition to retrieving and executing instructions, processor 610 may include one or more electronic circuits that include a plurality of functions for performing the functions of one or more of the instructions in machine-readable storage medium 620 electronic components. With regard to the representations of executable instructions (eg, blocks) described and illustrated herein, it should be understood that the executable instructions included within a block and/or some or all of the electronic circuitry may be included in the figures in alternative examples Different blocks shown or included in different blocks not shown.

Machine-readable storage medium 620 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, the machine-readable storage medium 620 may be, for example, random access memory (RAM), electrically erasable programmable read only memory (EEPROM), storage drives, optical disks, and the like. Machine-readable storage medium 620 may be disposed within system 600 as shown in FIG. 6 . In various examples, machine-readable medium 620 is non-transitory. In this case, the executable instructions may be "installed" on system 600 . Alternatively, machine-readable storage medium 620 may be a portable, external, or remote storage medium that, for example, allows system 600 to download instructions from the portable/external/remote storage medium.

6, cluster bitmap instructions 622, when executed by a processor (eg, processor 610), may cause processor 610 to determine the cluster bitmap of FIG. 2 (eg, by a computing device (eg, neighboring computing device 108A, etc.) , cluster bitmap 304), where each bit in the cluster bitmap indicates a data block (eg, OS data block 302 or data block) of the computing device's deployed operating system (OS) volume (eg, deployed OS volume 116A) Block 118A) is different from the base operating system volume (eg, base OS volume 104).

Bit table instructions 624, when executed, may cause processor 610 to determine a bit table (eg, bit table 306 shown in FIG. 3 or bit table 110A shown in FIG. 1 ) based on the cluster bitmap. Each bit in the bit table indicates whether the corresponding plurality of data blocks of the deployed OS volume (eg, OS data block 302 shown in FIG. 3 or data block 118A shown in FIG. 1 ) are different from the base OS volume. Each bit in the bit table may correspond to multiple bits in the cluster bitmap.

In various examples, bit table instructions 624 may include instructions that, when executed, may cause processor 610 to modify data blocks of the deployed OS volume, detect by the IO subsystem of the computing device that the data blocks of the volume are relative to The base OS volume has changed, the bit in the cluster bitmap corresponding to the address of the modified data block is modified by the IO subsystem to indicate that the cluster has changed relative to the base OS volume, and the IO subsystem modifies the bit in the bitmap The bits corresponding to the modified data block of the deployed volume.

Bit table request instructions 626, when executed, may cause processor 610 to receive a request for a bit table from a requesting computing device (eg, target computing device 102), and bit table send instructions 628, when executed, may cause processor 610 to The bit table is sent to the requesting computing device.

7 is a block diagram of an example for combining operating system volumes. In the example of FIG. 7 , system 700 includes processor 710 and machine-readable storage medium 720 . Although the following description refers to a single processor and a single type of machine-readable storage medium, the description may also apply to systems having multiple processors and multiple machine-readable storage media. In various examples, machine-readable storage medium 720 is non-transitory. In such examples, instructions may be distributed (eg, stored) across various machine-readable storage media, and instructions may be distributed (eg, executed by multiple processors) across multiple processors.

Processor 710 may be one or more central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieving and executing instructions stored in machine-readable storage medium 720 . In the particular example shown in FIG. 7, processor 710 may fetch, decode, and execute instructions 722, 724, 726, 728, 730, 732 to assemble operating system volumes.

As an alternative or in addition to retrieving and executing instructions, processor 710 may include one or more electronic circuits that include a plurality of functions for performing the functions of one or more of the instructions in machine-readable storage medium 720 electronic components. With regard to the representations of executable instructions (eg, blocks) described and illustrated herein, it should be understood that the executable instructions included within a block and/or some or all of the electronic circuitry may be included in the figures in alternative examples Different blocks shown or included in different blocks not shown.

Machine-readable storage medium 720 may be electronic, magnetic, optical, or other physical memory that stores executable instructions. Thus, the machine-readable storage medium 720 may be, for example, random access memory (RAM), electrically erasable programmable read only memory (EEPROM), storage drives, optical disks, and the like. Machine-readable storage medium 720 may be disposed within system 700 as shown in FIG. 7 . In this case, the executable instructions may be "installed" on system 700 . Alternatively, machine-readable storage medium 720 may be a portable, external, or remote storage medium that, for example, allows system 700 to download instructions from the portable/external/remote storage medium.

7, cluster bitmap instructions 722, when executed by a processor (eg, processor 710), may cause processor 710 to determine, by a computing device (eg, neighboring computing device 108A, etc.), the cluster bitmap of FIG. 2 (eg, cluster bitmap 304), wherein each bit in the cluster bitmap indicates a data block (eg, OS data block 302 or a data block) of the computing device's deployed operating system (OS) volume (eg, deployed OS volume 117A) 118A) is different from the base OS volume (eg, base OS volume 104).

Bit table instructions 724, when executed, may cause processor 710 to determine a bit table (eg, bit table 306 shown in FIG. 3 or bit table 110A shown in FIG. 1 ) based on the cluster bitmap. Each bit in the bit table indicates whether the corresponding plurality of data blocks of the deployed OS volume (eg, OS data block 302 shown in FIG. 3 or data block 118A shown in FIG. 1 ) are different from the base OS volume. Each bit in the bit table may correspond to multiple bits in the cluster bitmap.

Bit table request instructions 726, when executed, may cause processor 710 to receive a request for a bit table from a requesting computing device (eg, target computing device 102), and bit table send instructions 728, when executed, may cause processor 710 to The bit table is sent to the requesting computing device.

In various examples, machine-readable storage medium 720 may include resource utilization instructions 730 and/or data block sending instructions 732 . The resource utilization instructions 730, when executed, may cause the processor 710 to determine, with the computing device, the resource utilization of the computing device (eg, the load of the neighboring computing device 108A). In various examples, the processor 710 may execute block send instructions 732 that, when executed, cause the processor 710 to send, through the computing device, a plurality of requested blocks of data to a requesting computing device (eg, target computing device 102 ) , where the number of data blocks sent is based on the resource utilization of the computing device.

Claims (12)

1. A method for combining operating system volumes, comprising: receiving, by a computing device, an adjacent bit table corresponding to a deployed operating system volume of a neighboring computing device, wherein each bit in the adjacent bit table corresponds to the deployed operating system volume and indicating whether the data blocks of the deployed operating system volume are different from the base operating system volume; A target bit table is determined by the computing device, the target bit table corresponding to a target operating system volume of the computing device, wherein each bit in the target bit table corresponds to a first bit of the target operating system volume a data block in a group of data blocks, and indicating whether the data blocks of the target operating system volume are different relative to the base operating system volume; determining, by the computing device, a second set of data blocks of the target operating system volume included by the deployed operating system, wherein the determining is based on correspondence in the neighbor bit table and the target bit table whether the bits are equal, and the second set of data blocks is a subset of the first set of data blocks; requesting, by the computing device, at least one data block in the second set of data blocks from the neighboring computing device; receiving at the computing device at least one block of data from the neighboring computing device; combining, by the computing device, the target operating system volume based on at least one data block received from the adjacent computing device; determining, by the computing device and based on whether corresponding bits in the neighbor bit table and the target bit table are equal, a third set of data blocks that are not in the second set of data blocks of the deployed operating system volume ; requesting, by the computing device and from a media server, at least one data chunk of the third set of data chunks; and At least one data block of the third set of data blocks is received by the computing device and from the media server. 2. The method of claim 1, wherein combining the target operating system volumes comprises: storing, by the computing device, at least one data block of the second set of data blocks received from the neighboring computing device in random access memory RAM of the target computing device using a rolling window memory map; and At least one data block of the target operating system volume stored in the RAM is copied by the computing device and based on the rolling window memory map to a corresponding block of a storage device of the target computing device. 3. The method of claim 1, comprising: It is determined by the computing device that the neighboring computing device is located in at least one of: the same rack as the target computing device, the same enclosure as the target computing device, or connected at the same switch level as the target computing device; and It is determined by the computing device that the neighboring computing device has the same operating system version as the target operating system volume. 4. A computing system comprising: A plurality of adjacent computing devices, wherein each of the adjacent computing devices includes: a corresponding deployed operating system volume associated with one of the adjacent computing devices; and A corresponding adjacent bit table corresponding to the corresponding deployed operating system volume, wherein bits in the corresponding adjacent bit table indicate whether the corresponding deployed operating system volume is relative to the base operating system volume different; Target computing devices, including: target OS volume; The target computing device is used to: determining a target bit table corresponding to the target operating system volume, wherein each bit in the target bit table corresponds to a data block in a first set of data blocks of the target operating system volume, and indicates the target Whether the data blocks of the operating system volume are different from the basic operating system volume; requesting the corresponding adjacent bit table from the adjacent computing device; determining a second set of data blocks of the target operating system volume comprised by the deployed operating system volume, wherein determining the second set of data blocks is based on corresponding bits in the adjacent bit table and the target Whether the bits in the bit table are equal; requesting at least one data block in the second set of data blocks from the neighboring computing device; receiving the requested at least one data block from the neighboring computing device: and combining the target operating system volume based on at least one data block received from the adjacent computing device, wherein each of the adjacent computing devices includes: cluster bitmap, wherein each bit in the cluster bitmap corresponds to a data block of one of the corresponding deployed operating system volumes, and wherein each bit in the cluster bitmap indicates whether a corresponding data block of a deployed operating system volume in the corresponding deployed operating system volumes is different from the base operating system volume, Each of the plurality of adjacent computing devices is used to: A corresponding one of the bit tables is determined based on a corresponding one of the cluster bitmaps. 5. The computing system of claim 4, wherein the target computing device comprises random access memory RAM; Wherein, the target operating system volume is assembled based on the received at least one data block, and the target computing device is used to: using a rolling window memory map to store at least one data block in the received second set of data blocks in the RAM; and The at least one data block stored in the RAM is copied to a corresponding cluster of the target operating system volume based on a memory map associated with the target operating system bit table. 6. The computing system of claim 4, wherein the target computing device includes a plurality of network interfaces, the target computing device for: At least one of the requested second set of data blocks is received using the plurality of network interfaces. 7. The computing system of claim 4, the adjacent computing devices for: At least one data block of the second set of data blocks of the deployed operating system volume is sent based on resource utilization of the neighboring computing device. 8. The computing system of claim 4, wherein the adjacent computing device is in the same rack as the target computing device, in the same enclosure as the target computing device, or connected at the same switch level as the target computing device; and Wherein, the adjacent computing device has the same operating system version as the target operating system volume. 9. The computing system of claim 4, comprising: Media server: Wherein, the target computing device is used for: Based on whether a bit in the target bit table is not equal to any of the corresponding bits in the corresponding adjacent bit table, it is determined that the data block of the target operating system volume is not available from the plurality of adjacent computing devices obtained by each of the adjacent computing devices; and in response to determining that the data block is not available, requesting the unavailable data block from the media server; receiving, from the media server, the data block requested from the media server; and The target operating system volume is assembled based on the data blocks received from the media server. 10. A non-transitory machine-readable storage medium encoded with instructions that, when executed, cause a processor to: determining, by the computing device, a cluster bitmap, wherein each bit in the cluster bitmap indicates whether a data block of the computing device's deployed operating system volume is different from the base operating system volume; determining a bit table by the computing device and based on the cluster bitmap, wherein each bit in the bit table indicates whether the corresponding plurality of data blocks of the deployed operating system volume are different from the base operating system volume, and wherein each bit in the bit table corresponds to Multiple bits in the cluster bitmap: receiving, by the computing device, a request for the bit table from a requesting computing device; and sending, by the computing device, the bit table to the requesting computing device, wherein the instructions that cause the processor to determine the bitmap include instructions that, when executed, cause the processor to: modifying, by the computing device, data blocks of the deployed operating system volume; detecting, by the IO subsystem of the computing device, that data blocks of the volume have changed relative to the base operating system volume; modifying, by the IO subsystem, bits in the cluster bitmap corresponding to addresses of modified data blocks to indicate that the cluster has changed relative to the base operating system volume; and Bits in the bit table corresponding to modified data blocks of the deployed volume are modified by the IO subsystem. 11. The non-transitory machine-readable storage medium of claim 10, comprising instructions that, when executed, cause the processor to: In response to receiving the request for the data block of the operating system volume, the requested data block of the operating system volume is sent to the requesting computing device. 12. The non-transitory machine-readable storage medium of claim 10, comprising instructions that, when executed, cause the processor to: determining, by the computing device, resource utilization of the computing device; and A plurality of requested data chunks are sent by the computing device to the requesting computing device, wherein the number of data chunks sent is based on resource utilization of the computing device.

Images