System and method for updating add-in card firmware and collecting hardware information on any server or bare metal server with any OS installed

Abstract

The systems and methods described herein relate to upgrading one or more of additional firmware and disk firmware of a server, and may include: connecting a port of the server to an isolated network, the isolated network being dedicated to firmware upgrades of the server; caching an operating system received through the isolated network into a cache memory of the server; booting the operating system on the server from the cache memory; performing a Network File System (NFS) mount on the server to determine hardware information associated with upgrading one or more of the additional firmware and the disk firmware; and upgrading one or more of the additional firmware and the disk firmware based on the hardware information.

Description

Technical Field

[0001] The present disclosure relates to data centers, and more particularly, to facilitating updates to firmware of add-in cards and disks in servers in a data center. Background Art

[0002] In data centers, servers have different vendors, models, and configurations. In many cases, servers are configured with many add-in cards, such as different network interface controllers (NICs), host bus adapters (HBAs), disk controllers, etc. Maintaining the firmware (FW) versions of such add-in cards to match different versions of operating system (OS) types (e.g., CentOS, RedHat LINUX, MS Windows, VMWare ESXi, etc.) is a very expensive task. System administrators need to use a specific utility provided by the add-in card vendor to update the FW. However, the utility provided from the add-in card vendor is only available for limited OS.

[0003] In the implementation of the prior art, the system administrator needs to manually reboot each server to a specific OS supported by the card vendor and apply the add-on card utility to apply the FW update process. In addition, the system administrator needs to find the hardware information of the server before the FW update process can be started. Collecting hardware information on different platforms with different OS types can be challenging. In a data center, system administrators can often face such problems, and can involve a data center with hundreds of servers. Summary of the invention

[0004] Prior art implementations utilize baseboard management controller (BMC) virtual media to reboot servers with add-on card vendor-supported OS and perform FW updates. However, such implementations may be server vendor-specific and require an application programming interface (API) from the vendor or tool to create a virtual media mount for PC reboots to different OSes. Another prior art implementation involves utilizing a pre-boot execution environment (PXE) boot to allow selected servers to reboot to a specific OS for FW updates. Such a solution can address the limitations of vendor-specific servers, but creates another problem of conflicts between production PXE servers and Dynamic Host Configuration Protocol (DHCP) servers. Prior art implementations add additional NICs to isolate the DHCP server and PXE, which increases the complexity and operating costs of the network.

[0005] Example implementations described herein relate to systems and methods for a set of API endpoints that allow any application to integrate with a deployment manager to seamlessly perform hardware information collection and add-in card FW updates.

[0006] Aspects of the present disclosure may include a method for upgrading one or more of additional firmware and disk firmware of a server, the method comprising: connecting a port of the server to an isolated network; caching an operating system received through the isolated network into a cache memory of the server; starting the operating system on the server from the cache memory; performing a Network File System (NFS) mount on the server to determine hardware information associated with an upgrade of one or more of the additional firmware and the disk firmware; and upgrading one or more of the additional firmware and the disk firmware based on the hardware information.

[0007] Aspects of the present disclosure may also include a computer program storing instructions for upgrading one or more of the additional firmware and the disk firmware of the server, the instructions including: connecting a port of the server to an isolated network; caching an operating system received through the isolated network to a cache memory of the server; booting the operating system on the server from the cache memory; performing a network file system (NFS) mount on the server to determine hardware information associated with upgrading one or more of the additional firmware and the disk firmware; and upgrading one or more of the additional firmware and the disk firmware based on the hardware information. The instructions may be stored on a non-transitory computer-readable medium and configured to be executed by one or more processors.

[0008] Aspects of the present disclosure may also include a management node configured to upgrade one or more of the additional firmware and disk firmware of a server, the management node including a processor, the processor configured to: connect a port of the server to an isolated network; cache an operating system received through the isolated network to a cache memory of the server; start the operating system on the server from the cache memory; perform a network file system (NFS) mount on the server to determine hardware information associated with an upgrade of one or more of the additional firmware and the disk firmware; and upgrade one or more of the additional firmware and the disk firmware based on the hardware information.

[0009] Aspects of the present disclosure may also include a system for upgrading one or more of additional firmware and disk firmware of a server, the system comprising: a device for connecting a port of a server to an isolated network; a device for caching an operating system received through the isolated network onto a cache memory of the server; a device for starting the operating system on the server from the cache memory; a device for performing a network file system (NFS) mount on the server to determine hardware information associated with an upgrade of one or more of the additional firmware and the disk firmware; and a device for upgrading one or more of the additional firmware and the disk firmware based on the hardware information. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1( a ) illustrates an example configuration of a firmware update network according to an example implementation.

[0011] FIG. 1( b ) illustrates an example system according to an example implementation.

[0012] FIG. 2( a ) shows an example overall flow of an add-on card / disk firmware update performed by a management node according to an example implementation.

[0013] FIG. 2( b ) shows an example flow in which the example implementation may be applied.

[0014] Figure 3 An example topology in a production environment according to an example implementation is shown.

[0015] Figure 4 An exemplary computing environment is shown with exemplary computer devices suitable for use in some exemplary implementations. DETAILED DESCRIPTION

[0016] The following detailed description provides details of the drawings and example implementations of the present application. For clarity, the reference numerals and descriptions of redundant elements between the drawings are omitted. The terms used throughout the specification are provided as examples and are not restrictive. For example, according to the desired implementation of a person of ordinary skill in the art who practices the implementation of the present application, the use of the term "automatic" may involve fully automatic or semi-automatic implementations involving user or administrator control of certain aspects of the implementation. The selection may be made by the user through a user interface or other input means, or may be implemented by a desired algorithm. The exemplary implementations described herein may be utilized individually or in combination, and the functionality of the exemplary implementations may be implemented by any means according to the desired implementation.

[0017] Today's system administrators face a difficult task of maintaining production servers with supported / certified latest software, FW for server hardware and FW for add-on devices (i.e., NICs, HBAs, disk controllers, and disks) to meet reliability, performance, and security requirements. Updating the FW of add-on cards is not straight forward. It involves finding the right upgrade path and using appropriate utilities provided by the add-on card vendors. These utilities can be used only on a small list of supported OS. This solution provides a server vendor agnostic automatic mechanism to perform seamless add-on card FW updates. In this solution, a dedicated Firmware Update Network (FUN) will be automatically created in the Layer 2 network, only a single port on the switch will be configured with a specific native VLAN ID for the FUN, and when the add-on card FW update is completed, it will be restored to the original settings. A customized PXE image booted from a dedicated PXE server using an NFS root volume (highly modified CentOS with a small footprint) resides in a dedicated deployment manager. The combination of PXE boot and the root volume mounted via NFS allows us to update the add-on card FW bundle without having to create any ISO images for PXE boot, allowing us to dynamically change the FW and process. IPMI tools and the RedFish protocol will be used to control the boot order on the selected servers for the FW update, and hardware information will also be collected during the process. To further secure the communication between the server being updated and the Deployment Manager, the server's unique MAC address will be registered with the Deployment Manager DHCP on the PXE server. The Deployment Manager PXE server will only answer to the registered MAC address. This PXE server is managed by the Deployment Manager in a docker container to reduce overhead and enhance security.

[0018] The example implementation involves an automated process for constructing a dedicated firmware update network (FUN) for add-on card FW updates and hardware information collection. This network provides a secure layer 2 network environment to eliminate disruption to the production environment. Since all changes are done in the layer 2 network, it makes the solution highly scalable and server vendor agnostic. In addition, the PXE server in FUN is one of many docker containers with a deployment manager (DM), which provides tightly integrated microservices to reduce overhead. With all these measures, the example implementation described in this article facilitates a highly secure and non-disruptive solution with a production PXE server and DHCP server.

[0019] With the example implementations described herein, any server connected to the network can undergo appropriate add-in card / disk FW upgrades, allowing data centers to be vendor agnostic with respect to connected servers. The example implementations can be applied to any server, regardless of the underlying configuration, and do not require any additional equipment to facilitate add-in card / disk FW upgrades.

[0020] The example implementation also facilitates APIs such as Network File System (NFS) mounts that facilitate hardware information collection and add-in card / disk FW updates. In one example, the NFS mount API can facilitate hardware information collection, such as but not limited to the type of add-in card in the server, the type of disk drive, the type of server, the server configuration (e.g., the processor or memory used), the slots in the server, etc., depending on the desired implementation.

[0021] The example implementation utilizes an isolated network to facilitate firmware updates, as will be described herein. By utilizing an isolated network that is separated from the production network, the example implementation thereby protects the deployment manager PXE server and DHCP server in the production environment from being affected by the allocation of undesirable Internet Protocol addresses to the production environment. In addition, the isolated network maintains security by protecting the PXE operating system used to boot the server and by restricting access to the deployment manager through the management node to perform additional card / disk FW updates, and the management node manages access to the docker container. In the example implementation as described herein, the PXE server will be facilitated by the docker container to provide portability, security and reduce dedicated resource overhead. In the example implementation involving a cluster of a production environment, multiple instances of the docker container as described herein can be generated for each cluster to facilitate the desired implementation.

[0022] Example implementations may be applied to single server updates (eg, a single server in a production environment to avoid significant downtime) or multiple servers updating simultaneously (eg, a non-production environment rapid deployment).

[0023] Figure 1(a) shows an example configuration of a firmware update network according to an example implementation. In the example of Figure 1(a), a server running in a production environment is being updated. Through the DM interface, a user can select a server that needs to be updated. Since this is a production server, the server will first be placed in maintenance mode to avoid a complete outage of its corresponding cluster. DM automatically begins configuring FUN in the background. During the process of configuring FUN, DM establishes a secure shell (SSH) to a switch (e.g., in this example, a switch manufactured by VendorX), makes a backup of the paired port configuration, changes the default virtual local area network (VLAN) on the port, and then creates a VLAN. Figure 1(a) shows an example of configuring FUN with VLAN ID 7.

[0024] FIG. 1( b) shows an example system according to an example implementation. In an example implementation, there is a server 100 or multiple servers that have firmware updates for add-on cards or disks. Such a server is connected to a switch 103 and can be connected to a production network 101 and interact with a DHCP server 104 of a production environment. When the management node 130 is instructed to perform a firmware update, the management node 130 initiates a configuration as shown in FIG. 1( a) to create a FUN 102 that connects the server 100 to a PXE boot server 120. The PXE boot server 120 may involve one or more containers 110, which may include a DHCP server 111, a Trivial File Transfer Protocol (TFTP) server 112, a Network File System (NFS) server 113, and a Hypertext Transfer Protocol (HTTP) server for the FUN 102. Depending on the desired implementation, each of the one or more containers 110 may correspond to a specific server cluster in a production environment managed by the switch 103 or another switch. The management node 130 executes DM to configure the switch 103, as shown in FIG. 1( a). Depending on the desired implementation, the PXE boot server 120 and the container 110 may be provided via a virtual machine (VM) across multiple servers on the cloud. In such an example implementation, both the VM and the DM may be managed by a management node 130.

[0025] After creating the FUN 102, the DM will discover the corresponding paired media access control (MAC) address of the NIC of the server selected for the firmware update and register the MAC with the DHCP server 111 in the PXE boot server 120 to ensure that the DHCP server 111 does not provide Internet Protocol (IP) addresses to any production servers that are not intended to be involved in the add-in card FW update. The DM then initiates a reset (e.g., such as an ESXi reset) using an Intelligent Platform Management Interface (IPMI) tool. Once the target server 100 is restarted and active, the DM will begin the add-in card update process.

[0026] When the whole process is completed, the DM will restore the port configuration in the switch 103.

[0027] 2(a) shows an example overall flow of an add-on card / disk firmware update performed by the management node 130 according to an example implementation. First, at 201, the management node 130 detects a server (e.g., server 100) that requires an add-on card / disk FW update. At 202, the management node 130 configures the switch 103 to create a dedicated FUN 102 between the server 100, the switch 103, the management node 130, and the VM / PXE server 120.

[0028] At 203, the management node 130 uses the selected server's unique NIC MAC registered on the PXE boot server 120 to start the docker container of the PXE boot server 120 to avoid conflicts with the production PXE server. At 204, the management node 130 reconfigures the boot sequence on the selected server 100 and initiates a reboot to allow the server to boot with the customized PXE-LiveOS.

[0029] At 205, after the server 100 completes the boot process, the management node 130 starts the process of collecting hardware information about the server 100 and the corresponding additional card / disk FW update process. The update process is performed through a customized PXE-LiveOS. The management node 130 collects hardware information and determines what version of firmware will be used for the update.

[0030] At 206, when the add-on card FW update process is completed, the management node 130 restarts the server 100 with the original boot sequence. At 207, the management node 130 restores the network configuration on the switch port of the switch 103 configured in the FUN. Then, the process ends, and the management node 130 can provide a report on the completed add-on card / disk FW update and hardware information.

[0031] FIG. 2( b) illustrates an example flow to which an example implementation may be applied. First, at 210, the administrator selects a server for add-on card / disk FW update and HW information collection through the deployment manager interface. At 211, the user is required to provide a FUN VLAN ID. Once the FUN VLAN ID is provided at 212, a check is performed to determine whether the compute switch port connected to the management node is configured with "trunk mode" 212. If so (yes), the process proceeds to 214 to add the FUN VLAN ID to the trunk 214, otherwise (no) the process proceeds to 213 to reconfigure the port to "trunk mode" and reconfigure the FUN VLAN ID to the trunk 213. At 215, the process finds the MAC address of the NIC, which will be used on the selected server to boot from FUN 215.

[0032] At 216, the process checks if there is a matching MAC on the compute switch port. If not (No), the process provides an interface for the user to provide the switch port number at 217. Otherwise (Yes), the process proceeds to 218 to back up the switch port configuration. At 219, the process resets the switch port with the default VLAN to the FUN VLAN ID 219. At 220, the process adds the FUN VLAN ID to the deployment manager VM.

[0033] At 221, the process starts the PXE server docker container on the deployment manager VM. At 222, the deployment manager VM configures the selected server to PXE boot from the NIC configured in FUN.

[0034] At 223, the process checks whether the server is powered on. If so (yes), the process proceeds to 224 to perform a power reset on the server. Otherwise (no), the process proceeds to 225 to power on the server.

[0035] At 226, the process checks the server startup status. If the server is to be started (Up), the process proceeds to 227, otherwise (not started) the process proceeds to 232 to restore the switch port configuration, and proceeds to 233 to report that a failure has occurred and end the process.

[0036] At 227, the process continues to collect HW information. At 228, the process starts the add-on card / disk FW update and provides a report on the progress. At 229, the process continues to monitor and report the progress of the FW update. At 230, a check is performed to determine whether the update is complete. If it is completed, the process proceeds to 231, otherwise, the process proceeds to 232.

[0037] At 231 , the process restores the switch port configuration 231 and proceeds to 234 to report a successful FW update and restart the server in a normal boot sequence.

[0038] Figure 3 An example topology in a production environment according to an example implementation is shown. In the example implementation, the production network 101 is managed by a computing switch 301. The server 100 in this example is a computing node. At 310, the management node 130 instructs the computing switch 310 that manages the production network to temporarily change the default local VLAN to the VLAN ID of FUN. Thus, the FUN VLAN connects the server 100 to the PXE server so that a server PXE boot can be performed to perform an additional card / disk FW update. As shown in 212 in Figure 2(b), the computing switch 301 will be configured in relay mode to add the FUN VLAN ID. FUN is an isolated network that allows the computing switch 301 to have a port to the server 100 that is isolated from the production network 101, thereby eliminating the problem of interference with the PXE or DHCP server in the production environment.

[0039] The deployment manager VM executes on the management node 130 which provides a docker container as a PXE server and facilitates add-on card / FW updates.

[0040] The example implementation described in this article uses isolated and dedicated FUN to control the selected server to boot from a dedicated and highly secure PXE server as a docker container managed by the management node. The PXE server provides a highly customized operating system, such as CentOS PXE-LiveOS, to perform add-on card or disk FW updates. Through such an example implementation, add-on card / disk FW updates and hardware management can be simplified regardless of the underlying server configuration.

[0041] Figure 4 An example computing environment with example computer devices suitable for use in some example implementations, such as FIG. 1( b) and FIG. Figure 3 The management node shown is to facilitate the functions of the deployment manager. The computer device 405 in the computing environment 400 may include one or more processing units, cores or processors 410, memory 415 (e.g., RAM, ROM, etc.), internal memory 420 (e.g., magnetic, optical, solid-state memory and / or organic memory) and / or I / O interface 425, any of which may be coupled to a communication mechanism or bus 430 for communicating information or embedded in the computer device 605. The I / O interface 425 is also configured to receive images from a camera or provide images to a projector or display according to the desired implementation.

[0042] Computer device 405 can be communicatively coupled to input / user interface 435 and output device / interface 440. Any one or both of input / user interface 435 and output device / interface 440 can be a wired or wireless interface and can be detachable. Input / user interface 435 can include any physical or virtual device, component, sensor or interface (e.g., button, touch screen interface, keyboard, pointing / cursor control, microphone, camera, Braille, motion sensor, optical reader, etc.) that can be used to provide input. Output device / interface 440 can include display, television, monitor, printer, speaker, Braille, etc. In some exemplary implementations, input / user interface 435 and output device / interface 440 can be embedded or physically coupled to computer device 405. In other example implementations, other computer devices can be used as or provide the functions of input / user interface 435 and output device / interface 440 of computer device 405.

[0043] Examples of computer devices 405 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by people and animals, etc.), mobile devices (e.g., tablet computers, notebooks, laptops, personal computers, portable televisions, radios, etc.), and devices that are not designed for mobility (e.g., desktop computers, other computers, kiosks, televisions, radios, etc. having one or more processors embedded therein and / or coupled thereto).

[0044] Computer device 405 may be communicatively coupled (e.g., via I / O interface 425) to external storage 445 and network 450 for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configurations. Computer device 405 or any connected computer device may function as, provide services for, or be referred to as, a server, client, a thin server, a general purpose machine, a special purpose machine, or another label.

[0045] I / O interface 425 may include, but is not limited to, wired and / or wireless interfaces using any communication or I / O protocol or standard (e.g., Ethernet 802.11x, universal system bus, WiMax, modems, cellular network protocols, etc.) for communicating information to and / or from at least all connected components, devices, and networks in computing environment 400. Network 450 may be any network or combination of networks (e.g., the Internet, a local area network, a wide area network, a telephone network, a cellular network, a satellite network, etc.).

[0046] Computer device 405 may use and / or communicate using computer-usable or computer-readable media (including both transient and non-transient media). Transient media include transmission media (e.g., metal cables, optical fibers), signals, carrier waves, etc. Non-transient media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROMs, digital video disks, Blu-ray disks), solid-state media (e.g., RAM, ROM, flash memory, solid-state memory), and other non-volatile storage devices or memories.

[0047] In some example computing environments, computer device 405 may be used to implement techniques, methods, applications, processes, or computer executable instructions. Computer executable instructions may be retrieved from a temporary medium and stored on and retrieved from a non-temporary medium. Executable instructions may be derived from one or more of any programming, scripting, and machine languages ​​(e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, etc.).

[0048] Processor 410 can be executed under any operating system (OS) (not shown) in a local or virtual environment. One or more applications can be deployed, which include logic unit 460, application programming interface (API) unit 465, input unit 470, output unit 475 and inter-unit communication mechanism 495, for different units to communicate with each other, communicate with OS and communicate with other applications (not shown). The described units and elements can change in design, function, configuration or implementation, and are not limited to the description provided. Processor 410 can be in the form of a hardware processor, such as a central processing unit (CPU), or a combination of hardware units and software units.

[0049] In some example implementations, when the API unit 465 receives information or executes instructions, it may be transmitted to one or more other units (e.g., the logic unit 460, the input unit 470, the output unit 475). In some instances, in some example implementations described above, the logic unit 460 may be configured to control the flow of information between the units and initiate services provided by the API unit 465, the input unit 470, and the output unit 475. For example, the flow of one or more processes or implementations may be controlled by the logic unit 460 alone or in conjunction with the API unit 465. The input unit 470 may be configured to obtain input for the calculations described in the example implementations, and the output unit 475 may be configured to provide output based on the calculations described in the example implementations.

[0050] The processor 410 can be configured to facilitate upgrading one or more of the server's additional firmware and disk firmware by: connecting the server port to an isolated network (e.g., FUN) as shown in 212-214 in Figure 2(b); caching an operating system received through the isolated network in a cache memory of the server as part of 221 and 22 in Figure 2(b); booting the operating system on the server from the cache memory as shown in 223-226 in Figure 2(b); performing a network file system (NFS) mount on the server to determine hardware information associated with upgrading one or more of the additional firmware and disk firmware as shown in 227 and 228 in Figure 2(b); and upgrading one or more of the additional firmware and disk firmware based on the hardware information as shown in 229-231 in Figure 2(b).

[0051] In an example implementation, booting the operating system involves performing a pre-boot execution environment (PXE) boot as shown in Figure 2(b) at 222. The PXE boot can be a traditional PXE and / or a modern iPXE to facilitate the desired implementation.

[0052] As shown in Figure 1(a) and Figure 3As indicated, generating an isolated network involves changing the local virtual local area network (VLAN) of the associated switch port. After the upgrade is complete, the associated switch port can be changed back to the native VLAN to connect the server back to the production environment.

[0053] The processor 410 may be configured to register a media access control (MAC) address of the server with a pre-boot execution environment (PXE) server, as shown in FIG. 1( b) and FIG. Figure 3 As shown, after generating the isolated network, an Internet Protocol (IP) address is assigned to the registered MAC address of the server, as shown in 215 to 220 in FIG. 2( b). The sharing of container 110 includes the API of DHCP server 1111, the API of TFTP server 112, and the API of NFS server 113 for NFS mounting, which is then limited to the assigned IP address. Thus, the hardware information of the server can be generated from the NFS mounting through the API.

[0054] Processor 410 can be configured to upgrade one or more of the additional firmware and disk firmware based on the hardware information by comparing the hardware information with a previous bundle of one or more of the additional firmware and disk firmware provided by the deployment manager. In an example implementation, the management node manages the version status of all add-on cards and disk firmware of all servers connected to the production environment in the memory 405. In such an example implementation, the servers in the production network can be upgraded in a sequential manner until all servers have appropriate upgrades. The example implementation can thus track what bundles are deployed for a specific cluster of servers, and then compare the hardware information of the server with the bundle applied to the specific cluster. Such an example implementation can be facilitated in any manner known to those of ordinary skill in the art.

[0055] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a defined series of steps leading to a desired end state or result. In an exemplary implementation, the steps performed require physical manipulation of tangible quantities to achieve tangible results.

[0056] Unless otherwise indicated, it will be apparent from the discussion that throughout the specification, discussions utilizing terms such as "processing," "computing," "calculating," "determining," "displaying," etc., may include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission, or display devices.

[0057] Exemplary implementations may also relate to devices for performing the operations herein. The device may be specially constructed for the desired purpose, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such a computer program may be stored in a computer-readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may include tangible media, such as, but not limited to, optical disks, disks, read-only memories, random access memories, solid-state devices and drives, or any other type of tangible or non-temporary media suitable for storing electronic information. A computer-readable signal medium may include a medium such as a carrier wave. The algorithms and displays presented herein are not inherently related to any particular computer or other device. A computer program may relate to a pure software implementation, which relates to instructions for performing the operations desired to be implemented.

[0058] According to the examples herein, various general purpose systems may be used with the programs and modules, or it may prove convenient to construct more specialized devices to perform the desired method steps. In addition, the exemplary implementations are described without reference to any particular programming language. It should be understood that the teachings of the exemplary implementations described herein may be implemented using various programming languages. The instructions of the programming language may be executed by one or more processing devices (e.g., a central processing unit (CPU), a processor, or a controller).

[0059] As known in the art, the above operations can be performed by some combination of hardware, software or software and hardware. Various aspects of the exemplary implementation can be implemented using circuits and logic devices (hardware), while other aspects can be implemented using instructions stored on a machine-readable medium (software), which, if executed by a processor, will cause the processor to perform the method for performing the implementation of the present application. In addition, some exemplary implementations of the present application can be performed only in hardware, while other exemplary implementations can be performed only in software. In addition, the various functions described can be performed in a single unit, or can be distributed on multiple components in any number of ways. When executed by software, a method is performed by a processor (such as a general-purpose computer) based on instructions stored on a computer-readable medium. If necessary, instructions can be stored on the medium in a compressed and / or encrypted format.

[0060] In addition, by considering the specification and teaching practice of the present application, other implementations of the present application will be apparent to those skilled in the art. Each aspect and / or component of the described exemplary implementations may be used alone or in any combination. It is intended that the specification and exemplary implementations are considered to be examples only, and the true scope and spirit of the present application are indicated by the appended claims.

Claims

1. A method for upgrading one or more of additional firmware and disk firmware of a server, the server being connected to a production network, the server being configured to interact with a Dynamic Host Configuration Protocol (DHCP) server of the production network, the method comprising the following steps: Generate an isolated network separated from the production network through a management node; And through the management node, using the unique network interface controller media access control NIC MAC of the selected server registered on the pre-boot execution environment PXE boot server, to start the docker container of the server; Connect the server's port to the isolated network; caching the operating system received via the isolated network in a cache memory of the server; reconfiguring the boot sequence on the selected server through the management node and initiating a reboot so that the server boots with the customized PXE-LiveOS to boot the operating system on the server from the cache memory; By means of the management node, a process of collecting hardware information about the server and a corresponding add-on card / disk firmware update process is started, and a network file system NFS mount is performed on the server to determine hardware information associated with an upgrade of one or more of the add-on firmware and the disk firmware, the hardware information including a type of an add-on card in the server, a type of a disk drive, a type of the server, a server configuration, or a slot in the server, wherein the management node collects the hardware information and determines what version of firmware will be used for the update; upgrading one or more of the additional firmware and the disk firmware based on the hardware information by comparing the hardware information with a previous bundle of the one or more of the additional firmware and the disk firmware provided by a deployment manager; as well as When the update process is completed, the server is restarted with the original boot sequence by the management node, and the network configuration on the associated switch port of the switch configured in the isolated network is restored by the management node.

2. The method according to claim 1, wherein: Starting the operating system includes: executing the pre-boot execution environment (PXE) boot.

3. The method according to claim 1, wherein: Generating the isolated network includes: changing the local virtual local area network VLAN of the associated switch port.

4. The method according to claim 3, further comprising: After the upgrade, the associated switch port is changed back to the local virtual local area network VLAN.

5. The method according to claim 3, further comprising: Registering a media access control (MAC) address of the server to a pre-boot execution environment (PXE) server, and after generating the isolated network, assigning an Internet Protocol (IP) address to the registered MAC address of the server; The NFS share used when performing the NFS mount is limited to the allocated IP address.

6. The method according to claim 1, wherein: The hardware information is generated from the NFS mount by an application programming interface (API).

7. A non-transitory computer readable medium storing instructions for upgrading one or more of additional firmware and disk firmware of a server, the server being connected to a production network, the server being configured to interact with a Dynamic Host Configuration Protocol (DHCP) server of the production network, the instructions comprising: Generate an isolated network separated from the production network through a management node; And through the management node, using the unique network interface controller media access control NIC MAC of the selected server registered on the pre-boot execution environment PXE boot server, to start the docker container of the server; Connecting a port of the server to the isolated network; caching the operating system received via the isolated network in a cache memory of the server; reconfiguring the boot sequence on the selected server through the management node and initiating a reboot so that the server boots with the customized PXE-LiveOS to boot the operating system on the server from the cache memory; By means of the management node, a process of collecting hardware information about the server and a corresponding add-on card / disk firmware update process is started, and a network file system NFS mount is performed on the server to determine hardware information associated with an upgrade of one or more of the add-on firmware and the disk firmware, the hardware information including a type of an add-on card in the server, a type of a disk drive, a type of the server, a server configuration, or a slot in the server, wherein the management node collects the hardware information and determines what version of firmware will be used for the update; upgrading one or more of the additional firmware and the disk firmware based on the hardware information by comparing the hardware information with a previous bundle of the one or more of the additional firmware and the disk firmware provided by a deployment manager; as well as When the update process is completed, the server is restarted with the original boot sequence by the management node, and the network configuration on the associated switch port of the switch configured in the isolated network is restored by the management node.

8. The non-transitory computer readable medium of claim 7, wherein: Starting the operating system includes executing the pre-boot execution environment (PXE) boot.

9. The non-transitory computer readable medium of claim 7, wherein: Generating the isolated network includes: changing the local virtual local area network VLAN of the associated switch port.

10. The non-transitory computer readable medium of claim 9, the instructions further comprising: After the upgrade, the associated switch port is changed back to the local virtual local area network VLAN.

11. The non-transitory computer readable medium of claim 9, the instructions further comprising: Registering a media access control (MAC) address of the server to a pre-boot execution environment (PXE) server, and after generating the isolated network, assigning an Internet Protocol (IP) address to the registered MAC address of the server; The NFS share used when performing the NFS mount is limited to the allocated IP address.

12. The non-transitory computer readable medium of claim 7, wherein: The hardware information is generated from the NFS mount by an application programming interface (API).

13. A management node configured to upgrade one or more of an additional firmware and a disk firmware of a server, the server being connected to a production network, the server being used to interact with a Dynamic Host Configuration Protocol (DHCP) server of the production network, the management node comprising: A processor configured to: Generate an isolated network separated from the production network through a management node; And through the management node, using the unique network interface controller media access control NIC MAC of the selected server registered on the pre-boot execution environment PXE boot server, to start the docker container of the server; Connecting a port of the server to the isolated network; caching the operating system received via the isolated network in a cache memory of the server; reconfiguring the boot sequence on the selected server through the management node and initiating a reboot so that the server boots with the customized PXE-LiveOS to boot the operating system on the server from the cache memory; By means of the management node, a process of collecting hardware information about the server and a corresponding add-on card / disk firmware update process is started, and a network file system NFS mount is performed on the server to determine hardware information associated with an upgrade of one or more of the add-on firmware and the disk firmware, the hardware information including a type of an add-on card in the server, a type of a disk drive, a type of the server, a server configuration, or a slot in the server, wherein the management node collects the hardware information and determines what version of firmware will be used for the update; upgrading one or more of the additional firmware and the disk firmware based on the hardware information by comparing the hardware information with a previous bundle of the one or more of the additional firmware and the disk firmware provided by a deployment manager; as well as When the update process is completed, the server is restarted with the original boot sequence by the management node, and the network configuration on the associated switch port of the switch configured in the isolated network is restored by the management node.

Images