Method, system and device for deploying operating system, and electronic apparatus

HK40038791BActive Publication Date: 2026-07-10TENCENT TECHNOLOGY (SHENZHEN) CO LTD

Patent Information

Authority / Receiving Office
HK · HK
Patent Type
Patents
Current Assignee / Owner
TENCENT TECHNOLOGY (SHENZHEN) CO LTD
Filing Date
2021-03-31
Publication Date
2026-07-10

AI Technical Summary

Technical Problem

In cloud scenarios, existing technologies require manual configuration of data forwarding rules on the switch side to isolate different installed systems, resulting in high maintenance difficulty and high labor costs, and reconfiguration is required when switching devices.

Method used

By acquiring installation registration information corresponding to multiple installation systems, matching device identifiers, and assigning network addresses and operating system deployment file locations, unified management and automated operating system deployment can be achieved.

Benefits of technology

It simplifies the operating system deployment process, reduces the difficulty of operation and maintenance and the consumption of human resources, and supports rapid and seamless switching of installed systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

The application provides a deployment method, system and device of an operating system, electronic equipment and a computer readable storage medium, and relates to network and routing technologies in the field of cloud technologies; the method comprises the following steps: acquiring installation registration information corresponding to a plurality of installed systems respectively; when receiving an address request sent by a device to be deployed, matching the device identifier in the address request with the device identifiers in the installation registration information, so as to determine target installation registration information; assigning the network address corresponding to the device identifier matched successfully in the target installation registration information to the device to be deployed; and sending the file location in the target installation registration information to the network address assigned to the device to be deployed, so that the device to be deployed accesses the file location according to the assigned network address, and deploys the operating system according to the operating system deployment file obtained by the access. Through the application, the operation and maintenance difficulty of deploying the operating system can be effectively reduced, and the consumption of human resources can be reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to computer technology and network technology, and in particular to a method for deploying an operating system, a system, an apparatus, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In scenarios where cloud technology is applied (such as private cloud scenarios), multiple installation systems are often used to adapt to different devices. That is, different operating systems need to be deployed for different devices. Therefore, multiple installation systems working together is a classic requirement in cloud scenarios.

[0003] To avoid conflicts between different installation systems, the solutions provided by related technologies typically isolate different installation systems at the physical network level. For example, each installation system is installed in an environment corresponding to a different switch, the device to be deployed is manually connected to the switch corresponding to a certain installation system, and data forwarding rules are configured on the switch side so that the requests sent by the device to be deployed can successfully reach the corresponding installation system.

[0004] However, the configuration on the switch side is quite cumbersome, and when the device is moved from one installation system to another for management, it needs to be reconfigured on the switch side. In other words, the solutions provided by the relevant technologies are difficult to maintain and can easily consume a lot of manpower. Summary of the Invention

[0005] This application provides a method, system, device, electronic device, and computer-readable storage medium for deploying an operating system, which can reduce the difficulty of operating system deployment and maintenance and reduce the consumption of human resources.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] This application provides a method for deploying an operating system, including:

[0008] Obtain installation registration information corresponding to multiple installation systems, wherein the installation registration information includes the device identifier of the device managed by the installation system, the network address assigned to the device managed by the installation system, and the file location of the operating system deployment file corresponding to the installation system;

[0009] When an address request is received from a device to be deployed, the device identifier in the address request is matched with the device identifiers in multiple installation registration information.

[0010] The installation registration information containing the successfully matched device identifier is used as the target installation registration information, and the network address corresponding to the successfully matched device identifier in the target installation registration information is assigned to the device to be deployed;

[0011] The file location in the target installation registration information is sent to the network address assigned to the device to be deployed, so that the device to be deployed can access the file location according to the assigned network address and deploy the operating system according to the accessed operating system deployment file.

[0012] This application provides an operating system deployment system, including a shared system, multiple installation systems, and devices to be deployed;

[0013] The shared system stores installation registration information corresponding to each installation system; the installation registration information registers the device identifier of the device managed by the installation system, the network address assigned to the device managed by the installation system, and the file location of the operating system deployment file corresponding to the installation system;

[0014] The installation system is used to control the managed devices to send address requests;

[0015] The shared system is used for:

[0016] When an address request is received from the device to be deployed, the device identifier in the address request is matched with the device identifiers in multiple installation registration information.

[0017] The installation registration information containing the successfully matched device identifier is used as the target installation registration information, and the network address corresponding to the successfully matched device identifier in the target installation registration information is assigned to the device to be deployed;

[0018] Send the file location in the target installation registration information to the network address assigned to the device to be deployed;

[0019] The device to be deployed is used to access the file location based on the assigned network address, and deploy the operating system based on the accessed operating system deployment file.

[0020] This application provides an operating system deployment apparatus, comprising:

[0021] The acquisition module is used to acquire installation registration information corresponding to multiple installation systems respectively. The installation registration information includes the device identifier of the device managed by the installation system, the network address assigned to the device managed by the installation system, and the file location of the operating system deployment file corresponding to the installation system.

[0022] The matching module is used to match the device identifier in the address request with the device identifiers in multiple installation registration information when it receives an address request sent by the device to be deployed;

[0023] The address allocation module is used to take the installation registration information where the successfully matched device identifier is located as the target installation registration information, and allocate the network address in the target installation registration information corresponding to the successfully matched device identifier to the device to be deployed;

[0024] The location sending module is used to send the file location in the target installation registration information to the network address assigned to the device to be deployed, so that the device to be deployed can access the file location according to the assigned network address and deploy the operating system according to the accessed operating system deployment file.

[0025] This application provides an electronic device, including:

[0026] Memory, used to store executable instructions;

[0027] The processor, when executing executable instructions stored in the memory, implements the operating system deployment method provided in the embodiments of this application.

[0028] This application provides a computer-readable storage medium storing executable instructions for implementing the operating system deployment method provided in this application when executed by a processor.

[0029] The embodiments of this application have the following beneficial effects:

[0030] By uniformly managing the installation registration information of multiple installation systems and allocating network addresses and sending operating system deployment files based on the installation registration information, the operating system can be deployed on the device. Since only the installation registration information needs to be configured during the deployment process, the operation and maintenance process of deploying the operating system can be effectively simplified, saving related computing and human resources. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the architecture of the operating system deployment system provided in the embodiments of this application;

[0032] Figure 2 This is a schematic diagram of the architecture of an electronic device provided in an embodiment of this application;

[0033] Figure 3A This is a flowchart illustrating an operating system deployment method provided in an embodiment of this application;

[0034] Figure 3B This is a flowchart illustrating an operating system deployment method provided in an embodiment of this application;

[0035] Figure 3CThis is a flowchart illustrating an operating system deployment method provided in an embodiment of this application;

[0036] Figure 3D This is a schematic diagram of a process for automatically registering device identifiers provided in an embodiment of this application;

[0037] Figure 4 This is a schematic diagram of the deployment system of the operating system provided in the embodiments of this application;

[0038] Figure 5 This is a flowchart illustrating an operating system deployment method provided in an embodiment of this application;

[0039] Figure 6 This is a schematic diagram of out-of-band management provided in an embodiment of this application;

[0040] Figure 7 This is a functional diagram of the management interface in the shared system provided in this application embodiment. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0042] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0043] In the following description, the terms "first," "second," and "third" are used merely to distinguish similar objects and do not represent a specific ordering of the objects. It is understood that "first," "second," and "third" may be interchanged in a specific order or sequence where permissible, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein. In the following description, the term "multiple" refers to at least two.

[0044] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0045] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0046] 1) Installation system: Used to install operating systems on managed devices in an automated (unattended) manner. Each installation system corresponds to one operating system, and different installation systems may use the same or different operating systems. In this embodiment, the number of devices managed by the installation system is not limited.

[0047] 2) Installation Registration Information: Each installation system corresponds to an installation registration information. The installation registration information has two aspects. The first aspect is the file location of the operating system deployment files corresponding to the installation system. The second aspect is the information of the devices managed by the installation system, which may include device identifiers and assigned network addresses.

[0048] 3) Operating System Deployment Files: Files used to deploy (install) the operating system. The content of these files is not limited; any file capable of effectively deploying the operating system can be used in this embodiment. For example, for a Linux operating system, the operating system deployment files may include boot files (such as the BootLoader file), the operating system kernel, and the root file system.

[0049] 4) Device Identifier: Identification information used to distinguish different devices. For example, a device identifier may include at least one of a Media Access Control (MAC) address and a Serial Number (SN). It is worth noting that a MAC address is used to uniquely identify a network interface card (NIC) on a network. A device may have one or more NICs, and each NIC has a unique MAC address.

[0050] 5) Preboot Execution Environment (PXE): A mechanism for booting devices using a network interface. This mechanism allows devices to boot without relying on local data storage devices, deploying the operating system via network transmission. During operating system deployment, the device typically downloads a boot package from a remote location into its local memory for execution. This boot package completes the device's basic local software setup; this boot package is the boot file, also known as the PXE boot file.

[0051] 6) Virtual Local Area Network (VLAN): A VLAN is a logical segmentation of network users connected to a Layer 2 switch port. It is not limited by the physical location of network users and can segment the network according to user needs. A VLAN can be implemented on a single switch or across multiple switches.

[0052] 7) In-Band Management Mode: This refers to the transmission of device control information and user network service information (such as operating system deployment files and their locations) through the same logical channel. In this embodiment, two types of networks (subnets) can be defined, and the transmission of operating system deployment files and their locations can be achieved by applying the in-band management mode network.

[0053] 8) Out-of-band management mode: This refers to using a separate logical channel to transmit device control information in order to control the device. In the embodiments of this application, control information transmission can be achieved through a network using out-of-band management mode.

[0054] 9) Control information: Used to control the device. For example, the device's control information may include at least one of the device's network address and authentication information, wherein the authentication information may include a username and password.

[0055] 10) Cloud technology: refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computing, storage, processing, and sharing. Cloud technology enables various applications, such as: Private Cloud, which creates cloud infrastructure and hardware / software resources within a firewall for various departments within an organization or enterprise to share data center resources; Public Cloud, which refers to a cloud provided by a third-party provider to users, typically accessible via the internet and may be free or inexpensive; and Private Cloud, which is customized for cloud users (such as organizations or enterprises) based on public cloud, where cloud service providers offer independent virtualized resources, which users utilize through time-sharing leasing or other models.

[0056] This application provides a method, system, device, electronic device, and computer-readable storage medium for deploying an operating system, which can reduce the operational and maintenance difficulty of the deployment process and reduce the consumption of human resources.

[0057] The following describes exemplary applications of the electronic device provided in the embodiments of this application. The electronic device provided in the embodiments of this application can be implemented as a server. See also Figure 1 , Figure 1This is a schematic diagram of the architecture of an operating system deployment system 100 provided in an embodiment of this application. The operating system deployment system 100 includes a shared system 200, an installation system 300-1, an installation system 300-2, a device to be deployed 400-1, and a device 400-2. The shared system 200 includes a server 210, the installation system 300-1 includes a server 310-1, and the installation system 300-2 includes a server 310-2. For ease of understanding... Figure 1 The device to be deployed is represented as a server, but this does not constitute a limitation on the embodiments of this application. For example, the device to be deployed could also be a terminal device. It is worth noting that the network 500 between the shared system, the installation system, and the device to be deployed can be a wide area network (WAN), a local area network (LAN), or a combination of both. Furthermore... Figure 1 The network 500 example is just an example; in reality, many different types of networks can be used to deploy operating systems.

[0058] exist Figure 1 In this example, we will use device 400-1, managed by installation system 300-1, and device 400-2, managed by installation system 300-2, as examples. Shared system 200 stores the installation registration information corresponding to installation system 300-1, including the device identifier of device 400-1, the network address assigned to device 400-1, and the file location of the operating system deployment files corresponding to installation system 300-1. Shared system 200 also stores the installation registration information corresponding to installation system 300-2, including the device identifier of device 400-2, the network address assigned to device 400-2, and the file location of the operating system deployment files corresponding to installation system 300-2. Here, the installation registration information can be obtained through manual configuration or automatically configured according to specific rules.

[0059] Next, the process of deploying the operating system for device 400-1 is described. First, device 400-1 sends an address request to shared system 200, for example, via broadcast on network 500. Upon receiving the address request from device 400-1, shared system 200 obtains the device identifier carried in the address request and matches this device identifier with device identifiers in multiple stored installation registration information entries. It then determines that the installation registration information containing the successfully matching device identifier corresponds to the installation registration information for installation system 300-1. Next, shared system 200 assigns the network address from the installation registration information for installation system 300-1 to device 400-1, enabling device 400-1 to use the assigned network address. Shared system 200 also sends the file location from the installation registration information for installation system 300-1 to the network address assigned to device 400-1.

[0060] The operating system deployment file corresponding to the installation system 300-1 can be stored in the installation system 300-1 or in the shared system 200; the former is used as an example here. After receiving the file location, the device 400-1 accesses the file location according to the assigned network address to obtain the operating system deployment file stored in the installation system 300-1. Then, the device 400-1 deploys the operating system according to the obtained operating system deployment file. After the operating system is deployed, the device 400-1 can run services under the user's control or according to pre-set rules, and can also present the results of the service operation to the user. This embodiment of the application does not limit the type of service run by the device 400-1; for example, it can be data computing services in government affairs, banking, insurance, or financial scenarios.

[0061] exist Figure 1 The process of deploying an operating system for device 400-2 is similar to that of deploying an operating system for device 400-1. The difference is that device 400-2 is a device managed by the installation system 300-2, which will not be elaborated here.

[0062] In some embodiments, the servers included in the shared system can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The same applies to the servers included in the installation system and the devices to be deployed. It is worth noting that the devices to be deployed can be implemented not only as servers, but also as various terminal devices such as smartphones, tablets, laptops, desktop computers, smart TVs, smart speakers, and smartwatches, but are not limited to these. The shared system, the installation system, and the devices to be deployed can be directly or indirectly connected via wired or wireless communication methods, which is not limited in this embodiment.

[0063] See Figure 2 , Figure 2 The electronic device 600 provided in this embodiment of the invention (for example, may be...) Figure 1 The diagram shows the architecture of server 210. Figure 2 The illustrated electronic device 600 includes at least one processor 610, a memory 640, and at least one network interface 620. The various components in the electronic device 600 are coupled together via a bus system 630. It is understood that the bus system 630 is used to implement communication between these components. In addition to a data bus, the bus system 630 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2The general labeled all buses as Bus System 630.

[0064] The processor 610 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0065] The memory 640 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 640 may optionally include one or more storage devices physically located away from the processor 610.

[0066] The memory 640 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 640 described in this embodiment is intended to include any suitable type of memory.

[0067] In some embodiments, memory 640 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0068] Operating system 641 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, for implementing various basic business functions and handling hardware-based tasks.

[0069] The network communication module 642 is used to reach other computing devices via one or more (wired or wireless) network interfaces 620, exemplary network interfaces 620 including Bluetooth, WiFi, and Universal Serial Bus (USB).

[0070] In some embodiments, the apparatus provided in this invention can be implemented in software. Figure 2A deployment device 643 for an operating system stored in memory 640 is shown. This operating system can be software in the form of programs and plug-ins, and includes the following software modules: an acquisition module 6431, a matching module 6432, an address allocation module 6433, and a location sending module 6434. These modules are logically linked and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.

[0071] The deployment method of the operating system provided in this application will be described in conjunction with exemplary applications and implementations of the electronic devices provided in the embodiments of this application.

[0072] See Figure 3A , Figure 3A This is a flowchart illustrating an operating system deployment method provided in an embodiment of this application, which will be combined with... Figure 3A The steps shown are explained below. For ease of understanding, in... Figure 3A The example described uses the interaction process with one installation system as an example. In actual application scenarios, there are often multiple installation systems.

[0073] In step 101, the sharing system obtains installation registration information corresponding to multiple installation systems. The installation registration information includes the device identifier of the device managed by the installation system, the network address assigned to the device managed by the installation system, and the file location of the operating system deployment file corresponding to the installation system.

[0074] In many application scenarios, such as cloud environments, it is often necessary to deploy different operating systems for different devices. For example, device A within an organization might run services that control embedded devices, which have relatively low complexity and require a lightweight operating system. Device B within the same organization might run services that process large volumes of control data, which have high complexity and require a more complex Linux operating system to fully utilize device B's hardware resources and ensure the smooth operation of services handling large volumes of control data. In this embodiment, multiple installation systems are used to meet the operating system requirements of different devices, and a shared system is used to achieve unified management and control. The operating system deployment files for different installation systems can be different.

[0075] First, the shared system, acting as a unified management and control terminal, obtains the installation registration information corresponding to each of the multiple installation systems. This installation registration information includes two aspects: the file location of the operating system deployment files corresponding to the installation system, and information about the devices managed by the installation system, including device identifiers and network addresses assigned to the devices. Here, "assignment" refers to the network address being set for a device in the installation registration information by a person or according to specific rules. That is, in step 101, the network address assigned to a device is only stored in the installation registration information; the device does not actually possess the assigned network address. It is worth noting that the devices managed by the installation system can be terminal devices, physical servers, or virtual servers, etc., without limitation.

[0076] Installation registration information can be pre-set. For example, users of the shared system can manually enter installation registration information according to actual needs. Alternatively, the shared system can obtain the registration information automatically, as will be explained in detail later. To distinguish them from users of the installation system, users of the shared system will be referred to as administrators. The devices managed by the installation system can be pre-set or automatically assigned, depending on the actual application scenario. For example, based on the geographical distribution of devices, installation system A can be pre-set to manage devices in area A, and installation system B can be pre-set to manage devices in area B. Different installation systems will manage different devices.

[0077] The device identifier in the installation registration information is used to distinguish different devices, and may specifically include at least one of a MAC address and a serial number. The network address in the installation registration information can be manually set by the administrator, or it can be obtained according to a set selection policy, such as randomly selecting one from an available network address pool as the network address assigned to the device. Different network addresses are assigned to different devices.

[0078] In some embodiments, before step 101, the process further includes performing any of the following: the shared system stores the operating system deployment file corresponding to the installation system to obtain the file location of the operating system deployment file; the shared system obtains the file location of the operating system deployment file sent by the installation system; wherein the operating system deployment file is stored in the installation system.

[0079] This application provides two storage modes for operating system deployment files. The first mode involves the shared system storing the operating system deployment file corresponding to the installation system, thus obtaining the file location. The second mode involves the installation system storing the corresponding operating system deployment file and sending its file location to the installation system, so that the shared system can register this file location in the installation registration information corresponding to that installation system. It is worth noting that the file location can consist of two parts: the network address of the server storing the operating system deployment file, and the file path (or storage path, storage directory, etc.) of the operating system deployment file on the server. These methods improve the flexibility of file storage, allowing the appropriate storage mode to be selected based on the needs of the actual application scenario.

[0080] In step 102, the device to be deployed sends an address request to the shared system.

[0081] In this embodiment, the operating system is deployed to the device to be deployed via a network. First, the device to be deployed sends an address request to the shared system. This address request includes the device's own device identifier. For example, if the device to be deployed is equipped with a PXE network card (i.e., a network card with PXE functionality), after the device restarts, it sends an address request to the network through the PXE network card. Here, the address request can be sent in the form of a broadcast.

[0082] In step 103, when an address request is received from a device to be deployed, the sharing system matches the device identifier in the address request with the device identifiers in multiple installation registration information.

[0083] When the sharing system receives an address request from a device to be deployed, it matches the device identifier carried in the address request with the device identifiers in multiple installation registration information stored in the sharing system.

[0084] In some embodiments, the number of devices to be deployed includes multiple devices, and the device identifiers of the multiple devices to be deployed are respectively registered in the installation registration information corresponding to different installation systems; the above-mentioned shared system can be implemented in such a way that the device identifier in the address request is matched with the device identifier in the multiple installation registration information: when the device identifier in any installation registration information is the same as the device identifier in the address request, the device registration information is taken as the target installation registration information.

[0085] This document provides an application scenario based on an embodiment of this application, where multiple devices are to be deployed, and the device identifiers of these devices are registered in the installation registration information corresponding to different installation systems. In other words, the sharing system has already grouped the multiple devices to be deployed. When the sharing system receives an address request, it checks among all the installation registration information to determine if any installation registration information contains a device identifier that matches the device identifier in the address request. If a device identifier in a certain installation registration information matches the device identifier in the address request, i.e., a successful match, that installation registration information is used as the target installation registration information.

[0086] It's worth noting that the device registration information may include multiple types of device identifiers, while the address request may only include some types. For example, the device registration information may include a serial number and a MAC address, while the address request may only include the MAC address. In this case, matching is performed based on the device identifiers included in the address request. That is, if the MAC address included in a device registration information is the same as the MAC address included in the address request, then that device registration information is used as the target device registration information.

[0087] In step 104, the sharing system uses the installation registration information of the successfully matched device identifier as the target installation registration information, and assigns the network address corresponding to the successfully matched device identifier in the target installation registration information to the device to be deployed.

[0088] In the device registration information, there is a one-to-one correspondence between device identifiers and network addresses. Therefore, after determining the target device registration information, the sharing system assigns the network address corresponding to the successfully matched device identifier from the target device registration information to the device to be deployed. This allows the device to communicate with the sharing system and the device registration system via the assigned network address. For example, the device to be deployed can bind the assigned network address to its own network card (such as a PXE network card).

[0089] In step 105, the sharing system sends the file location from the target installation registration information to the network address assigned to the device to be deployed.

[0090] Here, the sharing system sends the file location from the target installation registration information to the network address assigned to the device to be deployed. In this way, the device to be deployed using the assigned network address can successfully obtain the file location sent by the sharing system.

[0091] In step 106, the device to be deployed accesses the file location based on the assigned network address and obtains the operating system deployment file.

[0092] Here, the file location in the target installation registration information can be either a location on the shared system or a location on the installation system. Figure 3A The latter scenario will be illustrated with an example. After the device to be deployed accesses the file location based on the assigned network address, it can obtain the operating system deployment files.

[0093] In step 107, the device to be deployed deploys the operating system according to the accessed operating system deployment file.

[0094] Here, the device to be deployed deploys (or installs) the operating system according to the obtained operating system deployment file. This application embodiment does not limit the type of operating system, such as Linux or Windows operating system.

[0095] In some embodiments, the operating system deployment file includes a boot file, an operating system kernel, and a root file system. The above-mentioned deployment of the operating system based on the accessed operating system deployment file can be achieved in the following way: the device to be deployed runs the boot file; during the execution of the boot file, the root file system is loaded into memory and mounted through the operating system kernel to obtain the deployed operating system.

[0096] This application does not limit the content of the operating system deployment file in its embodiments. Any content that enables operating system deployment can be applied to these embodiments. For ease of understanding, the operating system is described using Linux as an example, where the operating system deployment file includes a boot file, an operating system kernel, and a root file system. First, the device to be deployed runs the boot file. During the boot file's execution, the root file system is loaded into memory, and its memory address is sent to the operating system kernel. Thus, the operating system kernel can mount the root file system during runtime, completing the operating system deployment. Mounting refers to the process of making files or directories accessible within the operating system. For example, the boot file can be a BootLoader file, and the root file system can be an Initrd file. Initrd is an initial root file system mounted before the actual root file system is available, loaded along with the operating system kernel as part of the operating system kernel boot process. In some cases, Initrd can also be the final root file system used. Through the above method, effective operating system deployment can be achieved. It is worth noting that the above deployment process does not constitute a limitation on the embodiments of this application. Depending on the operating system deployment file, different methods can be used to deploy the operating system on the device.

[0097] like Figure 3AAs shown, this embodiment of the application effectively reduces the operational and maintenance difficulty of operating system deployment and the consumption of human resources by uniformly managing the installation registration information of multiple installation systems through a shared system and deploying the operating system for the devices to be deployed based on the installation registration information. When it is necessary to switch the management of a device from one installation system to another, only the installation registration information needs to be modified, which can achieve a fast and seamless switch.

[0098] In some embodiments, see Figure 3B , Figure 3B This is a flowchart illustrating an operating system deployment method provided in an embodiment of this application, based on... Figure 3A Before step 101, in step 201, the sharing system may obtain control information of the device to be deployed in the first network; wherein, the first network is used to transmit control information.

[0099] In this embodiment, the control of the device to be deployed can be achieved by dividing the network into two types. For ease of understanding, they are named the first network and the second network. The first network is a network that uses out-of-band management mode to transmit control information and realize out-of-band management of the device to be deployed; the second network is a network that uses in-band management mode to transmit operating system deployment files and the operating system. The two networks are isolated from each other.

[0100] First, the sharing system obtains the control information of the device to be deployed in the first network. The content of the control information is not limited in this application embodiment. As long as it can realize the control of the device to be deployed, it can be applied in this application embodiment. For example, the control information may be the network address of the device to be deployed in the first network (named the first network address for easy distinction), and may also include authentication information and serial number, etc. The authentication information may include username and password, or a specific token.

[0101] The control information of the device to be deployed in the first network can be preset or obtained automatically through specific methods. For example, the sharing system can obtain the first network address assigned to the device to be deployed from historical address allocation records, or it can use a specific network scanning tool to scan multiple network segments of the first network to obtain the first network address assigned to the device to be deployed. As another example, since the usernames and passwords of devices manufactured by the same company are usually fixed (i.e., default), the company can obtain the manufacturer of the device to be deployed, thereby determining the username and password of the device to be deployed.

[0102] exist Figure 3B In China, based on Figure 3AAfter step 101, in step 202, the shared system can send the control information of the equipment managed by the installation system to the installation system.

[0103] In practical applications, out-of-band management is often handled by the installation system. Therefore, after obtaining the installation registration information for multiple installation systems, the sharing system sends the control information of the devices managed by each installation system to that system. The sharing system can pre-establish a communication connection with the installation systems, such as in a first network, to facilitate the transmission of control information.

[0104] In step 203, the installation system controls the managed devices to send address requests in the second network according to the control information; wherein, the second network is used to transmit operating system deployment files.

[0105] After receiving control information from the managed devices, the installation system can control the managed devices to send address requests in the second network based on the control information. For example, if the managed devices are equipped with PXE network cards, the installation system can send a restart request to the device based on the control information. After restarting, the device will enter PXE mode, and the PXE network card will automatically send address requests in the second network, such as in the form of broadcast.

[0106] exist Figure 3B middle, Figure 3A The step 104 shown can be updated to step 204. In step 204, the sharing system uses the installation registration information of the successfully matched device identifier as the target installation registration information, and assigns the second network address corresponding to the successfully matched device identifier in the target installation registration information to the device to be deployed.

[0107] Given the division into a first network and a second network, the network address registered in the installation registration information is the network address in the second network, and for ease of distinction, it is named the second network address. After determining the target installation registration information, the sharing system assigns the second network address, corresponding to the successfully matched device identifier in the target installation registration information, to the device that sent the address request, i.e., the device to be deployed. The device to be deployed can bind the received second network address to the network card that sent the address request, such as the PXE network card mentioned above, and subsequently access the file location in the target installation registration information based on this second network address.

[0108] In some embodiments, the sharing system can allocate the second network address corresponding to the successfully matched device identifier in the target installation registration information to the device to be deployed in the following manner: The sharing system generates an address provision request based on the second network address corresponding to the successfully matched device identifier in the target installation registration information; the sharing system sends the address provision request to the device to be deployed through the second network; when the device to be deployed receives the address provision request, it sends a confirmation request including the second network address in the second network; when the second network address in the received confirmation request is the same as the second network address in the target installation registration information, the sharing system sends a confirmation request to the device to be deployed through the second network; when the device to be deployed receives the confirmation request, it applies the second network address in the confirmation request.

[0109] Here, the process of allocating the second network address is described in steps:

[0110] 1) The sharing system generates an address provision request based on the second network address corresponding to the successfully matched device identifier in the target installation registration information, and then sends the address provision request including the second network address to the device to be deployed, for example, by broadcasting it to the second network.

[0111] 2) When the device to be deployed receives an address provision request, it sends a pending confirmation request, including the address of the second network, in the second network in response, for example, by broadcasting.

[0112] 3) When the sharing system receives a confirmation request, it compares the second network address in the confirmation request with the second network address in the target installation registration information (here, the second network address corresponding to the successfully matched device identifier). If the two are the same, the sharing system sends the confirmation request to the device to be deployed through the second network, for example, by broadcasting.

[0113] 4) When the device to be deployed receives an acknowledgment request, it applies the second network address from the acknowledgment request. For example, it binds the second network address from the acknowledgment request to the network card that sent the address request. In this way, the device to be deployed can conduct point-to-point network communication with the shared system based on the applied second network address. During the above allocation process, to facilitate the identification of the device to be deployed, parameters for identifying the device can be added to the address provision request, the acknowledgment request, and the acknowledgment request, such as the device identifier mentioned above. This method enables accurate allocation of the second network address, improving the reliability of operating system deployment. It is worth noting that the above method of allocating the second network address also applies to scenarios where a first and second network are not distinguished.

[0114] like Figure 3BAs shown, this embodiment of the application achieves the isolation between device control and file transfer by dividing the first network and the second network, which facilitates the installation system to effectively control the devices to be deployed.

[0115] In some embodiments, see Figure 3C , Figure 3C This is a flowchart illustrating an operating system deployment method provided in an embodiment of this application, based on... Figure 3B After step 201, in step 301, the sharing system can control the device to be deployed to send an address request in the second network based on the control information of the device to be deployed.

[0116] In this embodiment, besides obtaining the pre-defined device identifier of the device to be deployed, various types of device identifiers, such as serial numbers and MAC addresses, can be actively collected based on control information. For example, the sharing system controls the device to be deployed to send an address request in the second network based on the control information of the device to be deployed. This address request includes some types of device identifiers, such as only including the MAC address.

[0117] In some embodiments, the control information of the device to be deployed includes a first network address and authentication information in the first network. The shared system can control the device to be deployed to send an address request in the second network based on the control information of the device to be deployed: the shared system sends a restart request to the first network address; when the device to be deployed successfully authenticates the authentication information in the restart request, it performs a restart operation and sends an address request in the second network.

[0118] This explanation assumes the control information of the device to be deployed includes a first network address in the first network and authentication information. First, the sharing system sends a restart request, including authentication information, to the first network address assigned to the device to be deployed. The device then authenticates the authentication information in the restart request. For example, when the authentication information includes a username and password, the device can check if the username and password sent by the sharing system match those stored locally on the device. If they match, authentication is successful. The same applies if the authentication information is a token. If the device fails to authenticate the information in the restart request, it does not respond to the restart request; if authentication is successful, it performs a restart operation and sends an address request in the second network after restarting. The authentication information effectively ensures the security and reliability of out-of-band management.

[0119] In some embodiments, the authentication information includes a username and a password; after the sharing system obtains the control information of the device to be deployed in the first network, it further includes: when receiving an update operation for the password of the device to be deployed, the sharing system sends the updated password to the device to be deployed so that the device to be deployed applies the updated password.

[0120] When authentication information includes a username and password, the sharing system can proactively modify the password. For example, when the sharing system receives a password update request for a device to be deployed, it sends the updated password to the device via a first network, causing the device to replace its locally stored password with the updated one. This method satisfies the password setting requirements in real-world application scenarios and improves applicability to scenarios with varying security requirements.

[0121] It is worth noting that in some scenarios with high security requirements, the devices to be deployed can be configured to only use the updated password sent by the shared system. If the devices to be deployed receive the updated password sent by the installation system, they will not be processed. In other words, only the shared system has the authority to update the password.

[0122] In some embodiments, the authentication information includes a username and password; after the sharing system sends the control information of the devices managed by the installation system to the installation system, the system further includes: when it receives an update operation for the password of the devices managed by the installation system, the sharing system sends the updated password to the installation system; the installation system controls the managed devices to send address requests in the second network according to the received updated password.

[0123] When authentication information includes username and password, the sharing system can also synchronize the updated password to the installation system. For example, when it receives an update operation for the password of a device managed by the installation system, the sharing system sends the updated password to the installation system, for example, via the first network. Upon receiving the updated password, the installation system replaces the locally stored password with the updated password. Thus, the installation system can control the managed devices to send address requests in the second network based on the updated password. This method achieves timely password synchronization and prevents the installation system from failing to control the managed devices.

[0124] In step 302, when an address request is received from the device to be deployed, the sharing system assigns a temporary network address randomly selected from the second network to the device to be deployed.

[0125] When the sharing system receives an address request from a device to be deployed, it randomly selects a temporary network address from the available address pool of the second network and assigns the temporary network address to the device so that the device can use the temporary network address. Of course, the temporary network address can also be pre-set.

[0126] In step 303, the shared system sends the public file location of the public operating system deployment files to a temporary network address.

[0127] Here, the shared system stores common operating system deployment files, and the corresponding common operating system is used to collect various types of device identifiers from the devices. The shared system sends the file location of the common operating system deployment files (named "common file location" for easy distinction) to a temporary network address assigned to the device to be deployed. It is worth noting that the common operating system deployment files in the shared system are available to all devices to be deployed.

[0128] In step 304, the device to be deployed accesses the public file location based on the temporary network address.

[0129] Here, when the device to be deployed receives the public file location, it accesses the public file location based on the temporary network address.

[0130] In step 305, the device to be deployed deploys the public operating system based on the public operating system deployment file obtained through access.

[0131] Here, after obtaining the public operating system deployment files, the device to be deployed deploys the corresponding public operating system.

[0132] In step 306, the device to be deployed sends various types of device identifiers to the shared system through the common operating system.

[0133] After the deployment of the common operating system, the devices to be deployed collect various types of device identifiers from these devices and control the devices to send these identifiers to the shared system based on temporary network addresses. In this way, the shared system obtains accurate and comprehensive device identifiers. The common operating system can collect these device identifiers using specific scripts or clients; there are no restrictions on this. Upon obtaining the various device identifiers, the shared system can release the temporary network address, effectively disconnecting the communication connection with the devices to be deployed in the second network.

[0134] It is worth noting that if the address request sent by the device to be deployed includes all types of device identifiers (e.g., the device identifier includes only the MAC address), the sharing system can also obtain the device identifier of the device to be deployed through steps 301 to 306, which can effectively ensure the accuracy of the device identifier obtained by the sharing system.

[0135] like Figure 3C As shown, by deploying a common operating system to the devices to be deployed, the shared system enables the common operating system to collect and send various types of device identifiers, ensuring the integrity and accuracy of the device identifiers obtained by the shared system.

[0136] In some embodiments, see Figure 3D , Figure 3D This is a schematic diagram of a process for automatically registering device identifiers provided in an embodiment of this application. Figure 3D The steps shown can be found in Figure 3A Execution between any of the steps shown will combine Figure 3D The steps shown are explained.

[0137] In step 401, the shared system obtains the target service type of the service to be run on the device to be deployed.

[0138] In this embodiment, automatic registration of device identifiers, i.e., automatic grouping of devices to be deployed, can be achieved through service type matching. Here, the target service type of the service to be run by the device to be deployed can be preset. This can be done by pre-storing the target service type in the shared system, or by having the device to be deployed send the target service type to the shared system. Figure 3D The latter case is used as an example. This application does not limit the classification method of business operations. For example, they can be classified into government affairs, banking, insurance, and financial business types. They can also be classified according to computational load, such as low computational load and high computational load business types.

[0139] In step 402, the shared system matches the target service type with the service types supported by multiple installation systems, and selects the installation system that supports the successfully matched service type as the target installation system.

[0140] Here, the service types supported by each installation system can also be pre-defined. The supported service types can be determined based on the actual situation of the operating system corresponding to each installation system (such as space usage, complexity, etc.). For example, if the service types are divided into low-computation and high-computation types, and the operating system corresponding to installation system A is a lightweight operating system with low complexity and small space usage, then the service type supported by installation system A is determined to be the low-computation service type; the operating system corresponding to installation system B is a more complex operating system with a larger space usage, then the service type supported by installation system B is determined to be the high-computation service type.

[0141] Similarly, the service types supported by the installation system can be pre-stored in the shared system, or the installation system can send the supported service types to the shared system. When the shared system obtains the target service type corresponding to the device to be deployed, it matches the target service type with the service types supported by multiple installation systems. If the target service type is the same as the service type supported by a certain installation system, the match is successful, and that installation system is selected as the target installation system.

[0142] In step 403, the sharing system registers the device identifier of the device to be deployed to the installation registration information corresponding to the target installation system, so as to treat the device to be deployed as a device managed by the target installation system.

[0143] Here, the shared system automatically registers the device identifier of the device to be deployed, that is, registers it to the installation registration information corresponding to the target installation system. From another perspective, it also treats the device to be deployed as a device managed by the target installation system, thus completing the automatic grouping of the device to be deployed.

[0144] In some embodiments, the shared system can register the device identifier of the device to be deployed to the installation registration information corresponding to the target installation system in the following manner: when there are multiple target installation systems, the shared system filters the multiple target installation systems according to the file parameters of the operating system deployment file corresponding to the target installation system; and registers the device identifier of the device to be deployed to the installation registration information corresponding to one of the target installation systems obtained after the filtering process; wherein, the file parameters of the operating system deployment file include at least one of update time and occupied space.

[0145] Here, when there are multiple target installation systems, further filtering can be performed on these systems. For example, the shared system obtains file parameters of the operating system deployment files corresponding to each of the multiple target installation systems. These file parameters include at least one of update time and disk space usage. Then, the multiple target installation systems are filtered based on these file parameters. For instance, when the file parameter is update time, the system with the most recent update time can be selected to improve the real-time performance of the operating system deployed to the device. When the file parameter is disk space usage, the system with the smallest disk space usage is selected to facilitate rapid operating system deployment. When the file parameters include both update time and disk space usage, a weighted sum of update time and disk space usage can be used to obtain a weighted parameter, and the system with the smallest (or largest, depending on the weighting rules) weighted parameter can be selected. Finally, the device identifier of the device to be deployed is registered in the installation registration information corresponding to the selected target installation system. Through this method, the devices to be deployed can be grouped into the optimal group while meeting the business requirements of the devices.

[0146] like Figure 3D As shown, the embodiments of this application can realize the automatic registration of device identifiers, that is, the automatic grouping of devices to be deployed, which can further save labor costs.

[0147] The following describes an exemplary application of the embodiments of this application in a real-world application scenario. In a private cloud scenario, several installation systems are often used to adapt to physical machines (physical machines are physical servers, corresponding to the devices to be deployed mentioned above) from different vendors. Therefore, the joint operation of multiple installation systems is a classic requirement in private clouds. Taking the case where the installation system includes a Dynamic Host Configuration Protocol (DHCP) server as an example, in order to achieve the deployment of operating systems on different physical machines, the relevant technologies mainly provide the following two solutions:

[0148] 1) Each installation system operates independently. The deployment network (i.e., the network using in-band management mode, corresponding to the second network mentioned above) and out-of-band network (i.e., the network using out-of-band management mode, corresponding to the first network mentioned above) of each installation system are isolated through VLANs to avoid conflicts between DH CP servers in different installation systems. In this solution, it is necessary to manually assign the physical machine's network to the correct VLAN.

[0149] 2) Each installation system is installed in an environment corresponding to a different switch. The physical machine needs to be manually connected to the switch environment corresponding to a certain installation system, and DHCP Relay, i.e., data forwarding rules, needs to be configured on the switch side to ensure that the DHCP broadcast packets sent by the physical machine can reach the DHCP server of the corresponding installation system.

[0150] Of the two solutions provided by the relevant technologies, at least the following problems exist:

[0151] 1) The deployment networks and out-of-band networks of different installed systems are isolated at the physical network level. If the deployment network or out-of-band network of a physical machine is not configured to the correct VLAN or the correct DHCP Relay on the switch side, the DHCP packets sent by the network card of that physical machine may reach the wrong DHCP server, causing the operating system deployment to fail. In addition, the physical machine may also fail to obtain the correct out-of-band IP address.

[0152] 2) Each installation system operates independently. If a physical machine is switched from one installation system to another for management, manual configuration at the switch side is required. In summary, the solutions provided by these technologies are difficult to maintain, prone to errors, and consume significant manpower.

[0153] To address this, embodiments of this application provide a shared component (corresponding to the shared system mentioned above) to manage all physical machines, while each installation system manages its corresponding physical machine. Through the collaborative work of the shared component and the installation system, the deployment of the operating system on the physical machine is achieved, i.e., the installation of the physical machine is realized. As an example, embodiments of this application provide the following... Figure 4 The diagram shown illustrates the deployment system of the operating system. Figure 4 The diagram illustrates shared components, installation system A, installation system B, and multiple physical machines requiring operating systems to be deployed. The user roles for operating the shared components and installation systems are typically different. Figure 4 The distinction is made between administrators and regular users (such as user A and user B). It's worth noting that... Figure 4 System A and System B in the examples are just examples; in actual application scenarios, there may be many more system installations.

[0154] In this embodiment of the application, the main functions of the shared component are: 1) automatically discovering physical machines; 2) running a shared DHCP server; and 3) realizing unified out-of-band management.

[0155] For each installation system, the included DHCP server is not started, or the installation system itself does not include a DHCP server. Each installation system includes an independent Trivial File Transfer Protocol (TFTP) server and an installation module. The TFTP server included in the installation system is used to store the operating system deployment files corresponding to the installation system, such as PXE boot files, operating system kernel, and initrd files. The installation system may also include other servers, such as Hypertext Transfer Protocol (HTTP) servers or Nginx, to store other files needed during the installation process, such as the operating system image source, kickstart script files, and some tools used during the installation process. Of course, these files can also be stored on the TFTP server. In addition, the installation system can provide various ways to interact with users, facilitating user interaction and operation. For example, the system may include a web server providing a web browser for user access. It can also offer Application Programming Interfaces (APIs), such as APIs based on Representational State Transfer (REST) ​​software architecture, and can be operated via a command prompt (CMD). For instance, the system can expose the APIs of its internal TFTP or HTTP servers to the web server, allowing users to access the web server through a web browser to modify files on the TFTP or HTTP server or manually control the installation process on the physical machine.

[0156] Next, we will explain the functions of the shared components and the installation system using a practical workflow. The shared components can achieve the following functions:

[0157] 1) The shared component can initiate automatic discovery of physical machines based on the physical machine's out-of-band network, default out-of-band username, and out-of-band password. It obtains the out-of-band IP address (corresponding to the first network address mentioned above), serial number, and MAC address of all physical machines and stores the mapping relationship between these three in the database. Since the out-of-band username and password corresponding to the manufacturer are usually default (i.e., fixed), the out-of-band username and password of the physical machine can be determined by obtaining the physical machine's manufacturer information.

[0158] 2) Shared components can define a name (i.e., domain name) for each physical machine, which improves the recognizability of physical machines and the differentiation between different physical machines, reducing the management difficulty for administrators or other personnel. Shared components can manage the mapping between the name of each physical machine and its deployment IP address (corresponding to the second network address mentioned above) through the Domain Name System (DNS).

[0159] 3) Shared components can create groups in the DHCP server (corresponding to the installation registration information above), with each installation system corresponding to one group. For any installation system, the next-server (i.e., the address of the server it points to) in the corresponding group is the deployment IP address of the TFTP server of that installation system (and may also include the deployment IP addresses of other servers in the installation system, such as the HTTP server), and the filename (i.e., the file path on the server it points to) in the group is the file path of the operating system deployment files corresponding to that installation system.

[0160] 4) For the physical machines managed by the installation system, the shared component registers the name, MAC address, and deployment IP address of the physical machine to the group corresponding to the installation system in the DHCP server.

[0161] 5) Shared components can update the out-of-band password of physical machines, for example, it can be updated under the operation of an administrator.

[0162] The installation system can perform the following functions:

[0163] 1) The installation system can obtain information such as the out-of-band IP address, out-of-band username, out-of-band password, serial number, MAC address, and deployment IP address of the physical machines it manages from the shared components, and initialize the physical machine locally on the installation system. Initializing the physical machine refers to adding the obtained physical machine information to the installation system's database.

[0164] 2) The installation system can initiate an installation via the installation module, i.e., by restarting the power supply of the managed physical machines through out-of-band network control. After the physical machine restarts, the deployment network card in the physical machine sends a DHCP broadcast to the deployment network. When the shared component receives this DHCP broadcast, it obtains the MAC address carried in the DHCP broadcast and looks up the deployment IP address corresponding to this MAC address from the stored group as a response to the DHCP broadcast. The shared component assigns the found deployment IP address to the physical machine and sends the next-server and filename from the group where the deployment IP address belongs to the physical machine. The group where the deployment IP address belongs corresponds to the target installation registration information mentioned above. In this way, the physical machine can obtain the operating system deployment file pointed to by filename from the installation system pointed to by next-server according to the assigned deployment IP address. For example, filename may include the file path of PXE boot files (such as the Bootloader file) and boot templates (such as the file path of the operating system kernel and Initrd). The boot template is also called a PXE template. After the physical machine loads the PXE boot file, it downloads the operating system kernel and initrd according to the file paths in the PXE template, and then enters the formal automated installation process. Once the physical machine enters the formal automated installation process, the installation system can determine subsequent tasks based on the installation status. This can be achieved through… Figure 4 The core modules shown determine the installation status. These core modules are the functional modules in the installation system used to control the installation process, such as state machines. Subsequent tasks determined by the installation system can include tasks such as performing installation according to the kickstart script file, formatting the disk, mounting the root file system, downloading and installing the operating system image, and executing post-scripts.

[0165] As an example, embodiments of this application provide, for instance, the following: Figure 5 This is a flowchart illustrating the deployment method of the operating system. (Combined with...) Figure 5 This section explains the workflow of the automatic physical machine discovery module in the shared components:

[0166] 1) Shared components restart the physical machine's power supply via out-of-band management modules.

[0167] 2) After the physical machine reboots and enters PXE, it downloads the public operating system deployment files from the shared components. These files may include PXE boot files, the operating system kernel, and a diskless image (e.g., an Initrd). This diskless image includes specific scripts or a built-in client (agent) to collect the physical machine's hardware information, such as its MAC address and serial number. Here, the shared component's DHC P server can randomly assign a temporary deployment IP address (corresponding to the temporary network address mentioned above) to establish a network connection with the physical machine, facilitating the download of the public operating system deployment files.

[0168] 3) After the physical machine loads the obtained PXE boot file, operating system kernel, and diskless image, the script or built-in agent in the diskless image will collect the physical machine's MAC address and serial number and send them to the daemon process in the core controller of the shared components.

[0169] 4) For each physical machine, the shared component establishes a mapping relationship between the physical machine's MAC address and its deployment IP address, and registers it with a specific group included in the DHCP server. Simultaneously, it can store the mapping relationship between the MAC address and the deployment IP address in a database. After completing the registration and storage of the physical machine's MAC address and deployment IP address, it can return a success message to the physical machine.

[0170] in addition, Figure 5 The installation process for the Chinese physical machine can be found above and will not be repeated here. It is worth noting that... Figure 4 and Figure 5 The examples used here all exemplify the scenario where the installation system stores the corresponding operating system deployment files. In some embodiments, each installation system can also migrate its own TFTP server or HTTP server to the shared component, meaning that the operating system deployment files corresponding to each installation system are stored in the shared component. In this case, the next-server in the group included in the DHCP server of the shared component points to the TFTP server or HTTP server in the shared component. For the installation system, it only needs to be responsible for the out-of-band management of the physical machine.

[0171] As an example, embodiments of this application also provide, for example, Figure 6 The diagram shown illustrates out-of-band management. Figure 6In this system, the shared component can store the out-of-band information (corresponding to the control information mentioned above) of each physical machine in its database. This out-of-band information can include serial numbers, out-of-band IP addresses, out-of-band usernames, and out-of-band passwords. This information can be preset or obtained by scanning the out-of-band network using specific tools. The shared component can update the out-of-band passwords and send the updated passwords to the physical machines so that they can apply the updated passwords.

[0172] exist Figure 6 In this system, the installation system has a client installed. The client includes a synchronous out-of-band interface for interacting with shared components, used to synchronize out-of-band information. When a physical machine needs to be brought under management, the installation system initiates the management of the physical machine by calling the synchronous out-of-band interface in the client to obtain the out-of-band information of the physical machine managed by the installation system from the shared components and store it in the installation system's own database. The installation system can then use the obtained out-of-band information to perform out-of-band operations on the corresponding physical machine, such as controlling the physical machine's power restart. It's worth noting that since the shared components also store the out-of-band information of the physical machines, they can also perform out-of-band operations on the physical machines. However, in practical applications, the installation system is often the direct manager of the physical machines; therefore, during the installation process, out-of-band operations are primarily performed by the installation system.

[0173] As an example, embodiments of this application also provide, for example, Figure 7 The diagram shows a schematic of the DHCP management interface in the shared component. In this embodiment, the shared component can provide a shared DHCP server and a DHCP management interface for the DHCP server to each installed system. This DHCP management interface also corresponds to... Figure 4 The DHCP management interface is used for registering physical machines. Administrators of shared components or individual installed systems can call the DHCP management interface to implement different functions. The functions that the DHCP management interface can perform include:

[0174] 1) Network Management: In the network environment of this application embodiment, there are out-of-band networks and deployed networks in the form of subnets. The out-of-band networks and deployed networks can be added, modified and deleted through the DHCP management interface.

[0175] 2) DHCP Configuration Management: Used to create, modify, and delete DHCP configurations; create (register), modify, and delete groups corresponding to each installed system; register and delete physical machines in the DHCP server, including batch registration and deletion.

[0176] The embodiments of this application can achieve at least the following technical effects:

[0177] 1) Multiple installation systems share a DHCP server in a shared component. The customized DHCP server can find the corresponding TFTP server of the installation system for the physical machine, thereby guiding the physical machine to find the correct operating system deployment file and realizing automated installation. That is, in this embodiment, it is not necessary to modify the switch configuration to isolate the networks of each installation system, which can reduce the difficulty of operation and maintenance and reduce the consumption of human resources. At the same time, each installation system can keep its own installation process unchanged, the system integration cost is low, and it is suitable for various cloud scenarios, such as private cloud scenarios.

[0178] 2) By using a unified DHCP server within the shared components, conflicts caused by multiple DHCP servers in the same network environment can be effectively avoided. Each installation system can flexibly register and delete the physical machines it manages in the DHCP server of the shared components through APIs (such as the DHCP management interface). When switching a physical machine from one installation system to another for management, no modification to the switch-side configuration is required, enabling a fast and seamless switchover.

[0179] The following continues to describe an exemplary structure of the operating system deployment apparatus 643 provided in the embodiments of this application, implemented as a software module. In some embodiments, such as... Figure 2 As shown, the software modules in the operating system deployment device 643 stored in the memory 640 may include: an acquisition module 6431, used to acquire installation registration information corresponding to multiple installation systems respectively; wherein, the installation registration information registers the device identifier of the device managed by the installation system, the network address assigned to the device managed by the installation system, and the file location of the operating system deployment file corresponding to the installation system; a matching module 6432, used to match the device identifier in the address request with the device identifier in the multiple installation registration information when receiving an address request sent by the device to be deployed; an address allocation module 6433, used to take the installation registration information where the successfully matched device identifier is located as the target installation registration information, and allocate the network address corresponding to the successfully matched device identifier in the target installation registration information to the device to be deployed; and a location sending module 6434, used to send the file location in the target installation registration information to the network address allocated to the device to be deployed, so that the device to be deployed can access the file location according to the allocated network address and deploy the operating system according to the accessed operating system deployment file.

[0180] In some embodiments, the operating system deployment apparatus 643 further includes: a control information sending module, configured to send control information of the devices managed by the installation system in a first network to the installation system, so that the installation system controls the managed devices to send address requests in a second network according to the control information; wherein, the first network is used to transmit control information; and the second network is used to transmit operating system deployment files.

[0181] In some embodiments, the operating system deployment apparatus 643 further includes: a shared control module, configured to control the device to be deployed to send an address request in a second network according to the control information of the device to be deployed; a temporary address allocation module, configured to allocate a randomly selected temporary network address in the second network to the device to be deployed when an address request is received from the device to be deployed; a public sending module, configured to send the public file location of the public operating system deployment file to the temporary network address, so that the device to be deployed can access the public file location according to the temporary network address and deploy the public operating system according to the accessed public operating system deployment file; and an identifier acquisition module, configured to acquire a device identifier sent by the device to be deployed controlled by the public operating system.

[0182] In some embodiments, the control information of the device to be deployed includes a first network address and authentication information in the first network; the shared control module is further configured to: send a restart request to the first network address so that the device to be deployed performs a restart operation when the authentication information in the restart request is successfully authenticated, and send an address request in the second network.

[0183] In some embodiments, the authentication information includes a username and a password; the operating system deployment device 643 further includes: a first synchronization module, configured to send the updated password to the device to be deployed when an update operation for the password of the device to be deployed is received, so that the device to be deployed applies the updated password; and a second synchronization module, configured to send the updated password to the installation system when an update operation for the password of the device managed by the installation system is received, so that the installation system controls the managed device to send an address request in the second network according to the updated password.

[0184] In some embodiments, the address allocation module 6433 is further configured to: generate an address provision request based on the second network address corresponding to the successfully matched device identifier in the target installation registration information; wherein the second network address is located in a second network; send the address provision request to the device to be deployed through the second network, so that the device to be deployed, upon receiving the address provision request, sends a confirmation request including the second network address in the second network; when the second network address in the received confirmation request is the same as the second network address in the target installation registration information, send a confirmation request to the device to be deployed through the second network, so that the device to be deployed, upon receiving the confirmation request, applies the second network address in the confirmation request.

[0185] In some embodiments, the operating system deployment apparatus 643 further includes: a type acquisition module, configured to acquire the target service type of the service to be run by the device to be deployed; a type matching module, configured to match the target service type with the service types supported by multiple installation systems respectively, and to use the installation system that supports the successfully matched service type as the target installation system; and an automatic registration module, configured to register the device identifier of the device to be deployed to the installation registration information corresponding to the target installation system, so as to use the device to be deployed as a device managed by the target installation system.

[0186] In some embodiments, the automatic registration module is further configured to: when the number of target installation systems includes multiple systems, filter the multiple target installation systems according to the file parameters of the operating system deployment file corresponding to the target installation system; register the device identifier of the device to be deployed to the installation registration information corresponding to one target installation system obtained by the filtering process; wherein, the file parameters of the operating system deployment file include at least one of update time and space occupied.

[0187] In some embodiments, the operating system deployment apparatus 643 further includes a storage module for performing any of the following processes: storing an operating system deployment file corresponding to the installation system, obtaining the file location of the operating system deployment file; obtaining the file location of the operating system deployment file sent by the installation system; wherein the operating system deployment file is stored in the installation system.

[0188] In some embodiments, the number of devices to be deployed includes multiple devices, and the device identifiers of multiple devices to be deployed are respectively registered in the installation registration information corresponding to different installation systems; the matching module 6432 is further configured to use any one of the installation registration information as the target installation registration information when the device identifier in any one of the installation registration information is the same as the device identifier in the address request.

[0189] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the operating system deployment method described above in this application.

[0190] This application provides a computer-readable storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to perform the method provided in this application, for example... Figure 3A , Figure 3B and Figure 3C The operating system deployment method is shown.

[0191] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EP ROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0192] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0193] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0194] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0195] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for deploying an operating system, characterized in that, The method includes: Obtain installation registration information corresponding to multiple installation systems, wherein the installation registration information includes the device identifier of the device managed by the installation system, the network address assigned to the device managed by the installation system, and the file location of the operating system deployment file corresponding to the installation system; When an address request is received from a device to be deployed, the device identifier in the address request is matched with the device identifiers in multiple installation registration information. The installation registration information containing the successfully matched device identifier is used as the target installation registration information, and the network address corresponding to the successfully matched device identifier in the target installation registration information is assigned to the device to be deployed; The file location in the target installation registration information is sent to the network address assigned to the device to be deployed, so that the device to be deployed can access the file location according to the assigned network address and deploy the operating system according to the accessed operating system deployment file.

2. The method according to claim 1, characterized in that, After obtaining the installation registration information corresponding to multiple installation systems, the process further includes: The control information of the devices managed by the installation system in the first network is sent to the installation system, so that the installation system controls the managed devices to send address requests in the second network according to the control information; The first network is used to transmit the control information; the second network is used to transmit the operating system deployment file.

3. The method according to claim 2, characterized in that, Before obtaining the installation registration information corresponding to each of the multiple installation systems, the process also includes: Based on the control information of the device to be deployed, control the device to be deployed to send an address request in the second network; When an address request is received from the device to be deployed, a temporary network address randomly selected from the second network is assigned to the device to be deployed. The public file location of the public operating system deployment file is sent to the temporary network address, so that the device to be deployed can access the public file location according to the temporary network address and deploy the public operating system according to the public operating system deployment file obtained from the access; Obtain the device identifier sent by the device to be deployed, which is controlled by the public operating system.

4. The method according to claim 3, characterized in that, The control information of the device to be deployed includes the first network address and authentication information in the first network; The step of controlling the device to be deployed to send an address request in the second network based on the control information of the device to be deployed includes: A restart request is sent to the first network address so that the device to be deployed performs a restart operation when the authentication information in the restart request is successfully authenticated, and sends an address request in the second network.

5. The method according to claim 4, characterized in that, The authentication information includes the username and password; The method further includes: When an update operation for the password of the device to be deployed is received, the updated password is sent to the device to be deployed so that the device to be deployed applies the updated password.

6. The method according to claim 4, characterized in that, The authentication information includes the username and password; After sending the control information of the devices managed by the installation system in the first network to the installation system, the method further includes: When an update operation is received for the password of a device managed by the installation system, the updated password is sent to the installation system so that the installation system can control the managed device to send an address request in the second network based on the updated password.

7. The method according to claim 2, characterized in that, Assigning the network address corresponding to the successfully matched device identifier in the target installation registration information to the device to be deployed includes: An address provision request is generated based on the second network address corresponding to the successfully matched device identifier in the target installation registration information; wherein the second network address is located in the second network; The address provision request is sent to the device to be deployed via the second network, so that when the device to be deployed receives the address provision request, it sends a confirmation request including the address of the second network in the second network; When the second network address in the received confirmation request is the same as the second network address in the target installation registration information, the confirmation request is sent to the device to be deployed through the second network, so that the device to be deployed applies the second network address in the confirmation request when it receives the confirmation request.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Obtain the target service type of the service to be run on the device to be deployed; The target service type is matched with the service types supported by the multiple installation systems, and the installation system that supports the successfully matched service type is taken as the target installation system. The device identifier of the device to be deployed is registered in the installation registration information corresponding to the target installation system, so that the device to be deployed is treated as a device managed by the target installation system.

9. The method according to claim 8, characterized in that, The step of registering the device identifier of the device to be deployed to the installation registration information corresponding to the target installation system includes: When the number of target installation systems includes multiple systems, the multiple target installation systems are filtered according to the file parameters of the operating system deployment files corresponding to the target installation systems. Register the device identifier of the device to be deployed into the installation registration information corresponding to the target installation system obtained through the filtering process; The file parameters of the operating system deployment file include at least one of the following: update time and space occupied.

10. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Perform any of the following processes: Store the operating system deployment file corresponding to the installed system, and obtain the file location of the operating system deployment file; Obtain the file location of the operating system deployment file sent by the installation system; wherein the operating system deployment file is stored in the installation system.

11. A deployment system for an operating system, characterized in that, This includes shared systems, multiple installed systems, and equipment to be deployed; The shared system stores installation registration information corresponding to each installation system; the installation registration information registers the device identifier of the device managed by the installation system, the network address assigned to the device managed by the installation system, and the file location of the operating system deployment file corresponding to the installation system; The installation system is used to control the managed devices to send address requests; The shared system is used for: When an address request is received from the device to be deployed, the device identifier in the address request is matched with the device identifiers in multiple installation registration information. The installation registration information containing the successfully matched device identifier is used as the target installation registration information, and the network address corresponding to the successfully matched device identifier in the target installation registration information is assigned to the device to be deployed; Send the file location in the target installation registration information to the network address assigned to the device to be deployed; The device to be deployed is used to access the file location based on the assigned network address, and deploy the operating system based on the accessed operating system deployment file.

12. The system according to claim 11, characterized in that, The operating system deployment files include boot files, the operating system kernel, and the root file system; The device to be deployed is also used for: Run the boot file; During the execution of the boot file, the root file system is loaded into memory and mounted by the operating system kernel to obtain the deployed operating system.

13. An operating system deployment apparatus, characterized in that, include: The acquisition module is used to acquire installation registration information corresponding to multiple installation systems, wherein the installation registration information includes the device identifier of the device managed by the installation system, the network address assigned to the device managed by the installation system, and the file location of the operating system deployment file corresponding to the installation system; The matching module is used to match the device identifier in the address request with the device identifiers in multiple installation registration information when it receives an address request sent by the device to be deployed; The address allocation module is used to take the installation registration information where the successfully matched device identifier is located as the target installation registration information, and allocate the network address in the target installation registration information corresponding to the successfully matched device identifier to the device to be deployed; The location sending module is used to send the file location in the target installation registration information to the network address assigned to the device to be deployed, so that the device to be deployed can access the file location according to the assigned network address and deploy the operating system according to the accessed operating system deployment file.

14. An electronic device, characterized in that, include: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the deployment method of the operating system according to any one of claims 1 to 10.

15. A computer-readable storage medium, characterized in that, It stores executable instructions for implementing the deployment method of the operating system according to any one of claims 1 to 10 when executed by a processor.