Systems and methods for intelligent system profile unique data management

Systems and methods are provided that may be implemented to manage machine-specific System Profile Unique Data (SPUD) information for one or more information handling systems. Such SPUD information may be managed and transported through in-band and/or out-of-band processing and communications, and may be employed to make restoration of machine-specific data possible either through network data communications and/or local system data communications.

FIELD OF THE INVENTION

This invention relates generally to information handling systems and, more particularly, to system profile unique data management for information handling systems.

BACKGROUND OF THE INVENTION

Information handling systems are typically provided with machine-specific information that is unique to each given information handling system. Examples of such machine-specific information includes Linux KickStart files, ini files, configuration files, and autorun files, batch files, etc. Specific examples of information handling systems include remote servers that are employed in a cloud computing environment to deliver computing resources (e.g., applications, data storage, processing) over the Internet to local information handling systems. In such a cloud computing environment, moving workload images from one server system to another server system has become a routine task. During movement of such information, machine specific information can hinder a system from operating properly if blindly cloned to other systems. In a heterogeneous environment having both virtual and physical operating characteristics, the conventional handling of such machine-specific information is mainly through agents running on the operating systems or virtual machines of individual information handling systems. In any case, in-band operating system (OS) involvement is required to remove machine-specific information from a given system and to reinstall machine-specific information to the same system when a new workload image is installed to the given system. This conventional practice typically leads to “agent-sprout”, i.e., required steps of installing agent, running agent, updating agent, un-installing agent, etc.

SUMMARY OF THE INVENTION

Disclosed herein are systems and methods that may be implemented to manage (e.g., including transfer) machine-specific System Profile Unique Data (SPUD) information for one or more information handling systems. Using the disclosed systems and methods, SPUD information may be managed and transported through in-band and/or out-of-band processing and communications, and may be employed in one embodiment to make restoration of machine-specific data possible either through network data communications and/or local system data communications. In another embodiment, SPUD information may be comprehensive in content so as to allow all machine-specific information to be restored in one shot or operation.

In the practice of the disclosed systems and methods, machine-specific SPUD information includes information that is unique to a given information handling system and that is required by the given information handling system in order for the given system to properly operate to perform one or more assigned information handling tasks. In this regard, such machine-specific SPUD information for a given information handling system is different from SPUD information required by other information handling systems in order for these other systems to properly operate to perform one or more of their assigned tasks, including to perform the same or similar information handling tasks as performed by the given information handling system. Examples of machine-specific SPUD information includes, but is not limited to, unique system data such as system service tag information, static hostname, system MAC address/es, system storage map/s, system IP address/es, static IP address/es, storage configuration, hardware information including system-specific hardware configuration information, software license/s, user account and login information, information regarding BIOS type and BIOS setting/s, BIOS firmware, network interface card (NIC) firmware, etc.

In one embodiment, the disclosed systems and methods may be employed to deploy workload images to one or more information handling systems (e.g., servers) while at the same time preserving the unique SPUD for each individual information handing system. In one embodiment, such workload images may be further characterized as in-band workload images that include information or data configured for in-band processing by an information handling system. Using the disclosed systems and methods, workload images may be deployed in one embodiment in an out-of-band manner to a single information handling system or to a plurality of information handling systems (e.g., servers) while at the same time preserving the unique SPUD for each individual information handing system. In one embodiment, the SPUD information may be so managed without any in-band operating system (e.g., OS agent) involvement being required other than for operating system (OS) activation. In such an exemplary embodiment of the disclosed systems and methods, the entire spectrum (e.g., hardware layer and application images) may be deployed in an out-of-band manner. Moreover, in one exemplary embodiment out-of-band deployment of workload images may be performed in a heterogeneous environment having both virtual and physical operating system characteristics.

Thus, in one exemplary embodiment, the disclosed systems and methods may be implemented to provide a seamless solution to deploy images to a plurality of information handling systems with the capability of maintaining each system's particular SPUD. Such a capability may be employed to allow a workload image to be migrated from one information handling system to another target information handling system, while at the same time preserving the relationship between SPUD information components of the given target system, e.g., such as bonding between software licenses and individual service tag of a specific target system. In a further embodiment, this image deployment may be out-of-band and may cover the entire spectrum from hardware layer to the application.

In one respect, disclosed herein is an information handling system, including: at least one in-band processing device; at least one out-of-band processing device; and persistent storage coupled to the out-of-band processing device and to the in-band processing device. The out-of-band processing device may be configured to manage System Profile Unique Data (SPUD) stored on the persistent storage for the information handling system, the SPUD including machine-specific information that is unique to the information handling system.

In another respect, disclosed herein is a method of managing System Profile Unique Data (SPUD) for one or more in information handling systems. The method may include providing an information handling system that itself includes at least one in-band processing device, at least one out-of-band processing device, and persistent storage coupled to the out-of-band processing device and to the in-band processing device. The method may also include: using the out-of-band processing device to manage SPUD stored on the persistent storage for the information handling system, the SPUD including machine-specific information that is unique to the information handling system.

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

FIG. 1is a block diagram of an information handling system104(e.g., such as a cloud computing server) as it may be configured according to one exemplary embodiment to perform SPUD management. As shown, system104may include one or more in-band processors106, one or more buses or communication media103, video/graphics hardware109, storage118, memory121, input/output (I/O)112, peripherals115, and a remote access controller (RAC)125having one or more out-of-band processors110and memory111. In this embodiment, out-of-band processor110is provided with an out-of-band SPUD manager module108that is configured to perform out-of-band spud management tasks in a manner as described further herein.

Still referring toFIG. 1, bus103provides a mechanism for the various components of system104to communicate and couple with one another. In-band processor106may include a Host processor (e.g., CPU) running a host operating system (OS) for system104, and out-of-band processor110may be a service processor, embedded processor, etc. Video/graphics109, storage118, memory121, I/O112and peripherals115may have the structure, and perform the functions known to those of skill in the art. Besides memory121(e.g., RAM), processor106may include cache memory for storage of frequently accessed data, and storage118may include extended memory for processor106. It will be understood that the embodiment ofFIG. 1is exemplary only, and that an information handling system may be provided with one or more processing devices that may perform the functions of processor106, processor110, remote access controller125, and other optional processing devices. Examples of such processing devices include, but are not limited to, central processing units (CPUs), embedded controllers, microcontrollers, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc. It will also be understood that the particular configuration ofFIG. 1is exemplary only, and that other information handling system architectures may be employed in the practice of the disclosed systems and methods that are suitable for performing the out-of-band SPUD management tasks described herein, e.g., system architectures those having one or more different components and/or fewer or greater number of system components.

The disclosed systems and methods may be implemented in one exemplary embodiment using a plug-in architecture framework to allow extension of SPUD management functionalities (e.g., using Dell unified server configuration (“USC”) server management functionalities available from Dell Products L.P. of Round Rock, Tex.) in a unified extension firmware interface (“UEFI”) environment by leveraging available remote access controller core or optional flash memory space. Further information on implementation of USC functionalities in a UEFI environment may be found, for example, in U.S. patent application Ser. No. 12/587,001 filed Sep. 30, 2009, and incorporated herein by reference in its entirety for all purposes. Among other things, the disclosed systems and methods may be implemented to provide a hardware and software interface to allow use of a plug-in framework in the embedded system management that may be run under the BIOS firmware and the UEFI environment. The disclosed systems and methods may also be implemented to provide a USC server management architecture that may be modified and enhanced over time, and/or that may also be employed to extend availability of the USC server management framework to remote users128.

Still referring toFIG. 1, remote access controller125provides access to a plurality of remote users128A-128C, although access may be provided to a single user128in other embodiments. In this regard, remote access controller125allows remote users to manage, administer, use, and/or access various resources of information handling system104(e.g., either native or virtual) from a remote location. However, remote or local access may be provided to information handling system104using any other configuration suitable for accomplishing the out-of-band SPUD management tasks as described further herein.

In the exemplary embodiment ofFIG. 1, remote users128A-128C may have in-band or out-of-band access to system104as desired. For example, remote users128A-128C may have wired and/or wireless access through a local area network (LAN), wide area network (WAN), wireless local area network (WLAN), wireless wide area network (WWAN), dial-up modem, etc. In one embodiment, remote access controller (RAC)125may be an integrated Dell Remote Access Controller (iDRAC) available from Dell Products L.P. of Round Rock, Tex. Further information on such a remote access controller may be found in United States Patent Application Publication Number 2006/0212143 and United States Patent Application Publication Number 2006/0190532, each of which is incorporated herein by reference in its entirety. However, it will be understood that other configuration of remote access controllers may be suitably employed in other embodiments.

As further shown, remote access controller125is coupled to remote access controller persistent storage140(e.g., non-volatile random access memory “NVRAM” such as embedded and partitioned flash memory, Electrically Erasable Programmable Read Only Memory—EEPROM, etc.), upon which one or more server management applications forming part of a USC framework may be stored in addition to one or more components or applications forming part of an embedded SPUD management configuration framework142and other functions, e.g., BIOS, unified extensible firmware interface (“UEFI”) modules, etc. In the embodiment ofFIG. 1, persistent storage140is managed by remote access controller125and may be utilized for out-of-band SPUD configuration management. In one exemplary embodiment, persistent storage140may be embedded in the system motherboard and may be, for example, about 1 GB in size.

FIG. 2illustrates one exemplary embodiment200for deployment of a depersonalized workload image202(e.g., a “gold image”) from a designated source information handling system104ato a plurality of target information handling systems104b1to104bN. Such a workload image202may be deployed in this manner, for example, to re-image an existing target system104bfrom which a previous workload image has been erased or otherwise removed or disabled, or to provide an initial image for a new target system104bwhich has never had a workload image202previously installed. In this regard, the disclosed systems and methods may be implemented to accomplish full or partial (subset) configuration updates of existing systems104, or may be alternatively be implemented to accomplish the initial deployment of workload images for a new set of target systems104, e.g., such as initial imaging a plurality of blank information handling systems104during initial deployment of the systems104as a set of servers. Whatever the case, a workload image202may include system non-unique information and data such as application software, operating system software, virtual machine and/or hypervisor software, stored data and/or database information, etc. In one embodiment, a workload image202may be further characterized as being an in-band workload image that includes information or data configured for in-band processing by information handling system104.

In the embodiment ofFIG. 2, a deployment of image202may be accomplished using any communication link/s between source system104aand the multiple target systems104b1-104bN, for example, using a network such as the Internet or corporate intranet or any other suitable inter-system data communication link. It will be understood that althoughFIG. 2illustrates deployment of a workload image202from a single source system104a, a workload image202maybe similarly deployed from one or more source systems104ato a single target system104bor to two or more target systems104b. In the embodiment ofFIG. 2, each of source system104aand each of target systems104b1-104bNmay be configured, for example, with components according to the exemplary embodiment ofFIG. 1, e.g., such that any given information handling system104is capable of serving the role as a source system104aor target system104b.

Still referring toFIG. 2, each given one of target systems104b1-104bNis shown including a respective out-of-band (OOB) persistent storage140b1-140bNon which SPUD information corresponding to the given target system104bmay be stored during re-imaging or initial imaging of the given target system104b. Such SPUD may include information that is unique to each given target information handling system104b, e.g., such as unique system data such as system service tag information, static hostname, system MAC address/es, system storage map/s, system IP address/es, static IP address/es, storage configuration, hardware information including system-specific hardware configuration information, software license/s, user account and login information, information regarding BIOS type and BIOS setting/s, BIOS firmware, network interface card (NIC) firmware, etc. Where a target system104bis being re-imaged with workload image202, such SPUD may be transferred from in-band components (e.g., storage118) to corresponding OOB persistent storage140bof each target system104bprior to removing or disabling any pre-existing workload image that may exist on the corresponding target system104b(e.g., on storage118). For new (non-imaged) target systems104b, SPUD may be imported into OOB persistent storage140of a given target system104bfrom another information handling system104, e.g., across a network or other suitable communication link. Further, in one exemplary embodiment SPUD stored on persistent storage140may be edited (e.g., for purposes of customization and identifications) by local or remote input via provided user interfaces.

FIGS. 3 and 4illustrate methodology that may be employed in one exemplary embodiment for generating SPUD and deploying a new workload image202from a source system104aand the generated SPUD to one or more target systems104b. In this regard, the system image (e.g., including system software and firmware) of each given system104may be separated into machine-generic workload image content (e.g., such as operating systems, applications, firmware, drivers, etc.) and machine-specific SPUD content (e.g., such as licenses, system-specific configurations, etc.) as appropriate depending on whether the given system is a source system104aor target system104b. In this regard, a system inventory of software may be collected using any suitable technique for gathering an inventory of system software and firmware, e.g., at system restart using Collect System Inventory On Restart (CSIOR) utility available from Dell Products L.P. of Round Rock, Tex. Such an inventory may include all software and firmware stored on system storage, e.g., system storage118, persistent storage140, etc. Collected SPUD may be selected from the collected system image information (e.g., including a set of licenses and configurations) and packaged into a SPUD format that is stored in persistent storage140for each target system104b. A workload image (e.g., machine generic image selected from the collected system image information of a source system104a) may then be deployed to each of the target system/s104b. Each target system104bmay then use its unique identifier (e.g., such as service tag identifier) to fetch its respective SPUD from persistent storage140. The information in the fetched SPUD may then be used to auto generate a license set for the corresponding target system104b. In this way, the hardware of each target system104bmay be setup with a new workload image together with a snapshot of the workflow and particularized SPUD configurations and licenses for the given target system104b. In one embodiment, all steps ofFIG. 3and some steps ofFIG. 4may be performed by on one or more target system/s104bin an out-of-band manner using out-of-band SPUD manager108executing on out-of-band processing device110, i.e., separately from and without requiring interaction with, or operation of, in-band processing device/s106and the associated operating system of system104.

Specifically referring toFIG. 3, SPUD is first generated in step302of methodology300for a target system104band then stored in step304to a persistent location of target system104bsuch as persistent storage140ofFIG. 1. In this regard, SPUD may be generated and stored in any suitable manner, including in a completely out-of-band manner using out-of-band processing device110without the in-band operating system executing on in-band processing device106. Alternatively, SPUD may be additionally or alternatively generated using an operating system (OS) agent while system104bis fully booted up and running, for example, if particular OS-related SPUD such as OS license information is required to be collected in an in-band manner.

In one exemplary embodiment, SPUD may be generated for a system104bhaving pre-existing SPUD stored thereon together with workload image information that is to be replaced. For example, the existing SPUD may be fetched and stored using an automatic out-of-band module that collects the SPUD in step302and saves the collected SPUD to persistent storage140in step304during system boot-up. Alternatively, SPUD may be additionally or alternatively collected and saved in steps302and304in a similar manner using an operating system (OS) agent while system104bis fully booted up and running, e.g., if particular OS-related SPUD such as OS license information is required to be collected. In one exemplary embodiment, pre-existing SPUD may be fetched and saved using an out-of-band utility such as out-of-band SPUD manager108executing on out-of-band processor110in conjunction with firmware and data storage of SPUD management configuration framework142. In one embodiment, out-of-band SPUD manager108may identify and fetch SPUD for system104bin step302from data locations such as network storage and local media. It will also be understood that SPUD may be generated from scratch in step302and entered by a user into persistent storage140in step304via out-of-band SPUD manager108in cases where system104bis new or otherwise blank and has no pre-existing SPUD stored thereon.

Still referring toFIG. 3, methodology300proceeds according to step306depending on whether a full restore of system104bis to be performed, or whether a central deployment of SPUD data from system104bto other information handling systems is to be pursued. If no full restore or central deployment is to be performed, then methodology300proceeds to step308where the target system104bis ready to receive the workload image202from a source system104a, e.g., as described and illustrated with regard toFIG. 2. However if a full restore or central deployment is to be performed, then methodology300proceeds to step310where collected SPUD is exported to an external location such as removable storage, e.g., across a network such as Internet or corporate intranet, or other suitable data communications media. In the case of a full system restore of the system104b, all storage of the target system104bmay be reformatted (wiped of data) after step310.

If the final destination for the SPUD is a new target system104bthat is different from the system from which the SPUD was originally generated in step302(e.g., the system104bhas no existing machine-specific SPUD and/or other image loaded thereon), then a SPUD template may be edited in step314with the exported SPUD of step310by the appropriate user interfaces for the new target system. Such a SPUD template may be a configuration file and database schema in appropriate SPUD format with or without specific system data. Thereafter, the edited SPUD may be imported to persistent storage140of the target system104bin step316. If the final destination for the SPUD is not a new target system104b(i.e., the target system104bis the same system from which the SPUD was generated), then methodology300may proceed as shown from step312to step315where the data (including SPUD) is erased or removed from the target system104b, and then to step316where the SPUD is imported back to persistent storage140of the target system104b. In step315, storage of target system104bmay be reformatted or all data otherwise removed from system storage118of the target system104b, and optionally further removed from persistent storage140in case of full restore of system104b. After step316, the target system104bis ready to receive the workload image202. Although exported SPUD may be edited while stored on an external location as described above, it will be understood that in another exemplary embodiment SPUD stored on local persistent storage of the target system104bmay also be edited if desired or needed.

FIG. 4illustrates one embodiment of a methodology400for generating and deploying a new workload image202from a source system104ato a target system104b. Methodology400starts in step402where any system specific information (e.g., SPUD such as such as service tag, MAC address, IP address, user accounts, etc.) is removed from the source system104a. Next, in step404, a workload image (e.g., “gold image”) is captured from the source machine104a, e.g., by using out-of-band SPUD manager108that executes in an out-of-band manner on out-of-band processing device110. In one exemplary embodiment out-of-band SPUD manager108may be configured with the generic capability for both roles of capturing images on a source system/s104aand for deploying images on target system/s104b. However, it will be understood that in other embodiments, source system-specific and target system-specific out-of-band SPUD managers are also possible, such that a source system out-of-band SPUD manager is provided on the source machine that is only capable of capturing images and/or such that a target system out-of-band SPUD manager is provided on a target machine that is only capable of deploying images.

Next, the given SPUD corresponding to each target system104bis retrieved by out-of-band SPUD manager108from persistent storage140of the respective target system104band applied (i.e., extracted and installed) by out-of-band storage manager108in step406to appropriate storage locations, e.g., on system storage118. Then, in step408any appropriate licenses may be generated (i.e., bound to the specific system104b) from the installed and extracted SPUD now present on each given target system104b. Thereafter, the workload image is deployed in step410from the source system104ato the target system/s104b.

In the embodiment ofFIG. 4, steps406to410may be performed on target system/s104bin an out-of-band manner, i.e., without requiring interaction with, or operation of, in-band processing device/s106. However, where certain licenses are present that require operating system participation to regenerate the licenses (i.e., to bind the licenses to the given system104b), an in-band processing device106on the given target system104bmay be employed to execute the operating system to perform in-band generation and activation of the appropriate licenses and/or to otherwise join the operating system and SPUD data on the target system104b. Such in-band license generation and/or in-band license activation on target system104bmay be performed in one embodiment the next time that the operating system is booted, e.g., from a “seed” or other data indicator and information installed on system storage118by out-of-band processing device110during step406.

It will be understood that methodology300ofFIG. 3and methodology400ofFIG. 4are each exemplary only and that fewer, additional, or alternative steps may be alternatively implemented in other embodiments. For example, it is possible that a “gold image” or other workload image202may be first imported to a target system104b, and then afterwards the SPUD applied to the system104b, e.g., from persistent storage140. However, in an alternative embodiment SPUD may be first applied (e.g., from persistent storage140to a designated location) to target system104b, and afterwards a “gold image” or other workload image202deployed to the target system104b. In such a case, when the workload image202is loaded and next executed, it will automatically recognize the SPUD, e.g., an autoscript may operate to merge the workload image202(including in-band operating system) with the appropriate recognized SPUD.

FIG. 5illustrates one exemplary embodiment500for cross-band license management as it may be implemented for a given target information handling system104busing the disclosed systems and methods. As shown inFIG. 5, information handling system includes combined SPUD and workload information590that is contained in in-band software and hardware layers of a given target system104. Examples of such information includes applications502a-502bof an application layer, guest operating systems504aand504bof an operating system layer, virtual machine/hypervisor508of a virtual machine layer, and in-band hardware510(e.g., CPU106, storage118, memory121, and network information) of a hardware layer. Also illustrated inFIG. 5is out-of-band (OOB) hardware layer512that includes out-of-band processor110, persistent storage140, memory111, and network information.

FIG. 5also illustrates in-band license manager and configuration (LM/CFG) utilities506a,506band506cthat are resident on respective operating system and virtual machine layers of system104as shown. LM/CFG utilities communicate from virtual machine layer508across IPMI network520as shown with out-of-band LM/CFG manager516(e.g., out-of-band SPUD manager module108) on out-of-band processor110of system104b, and with LM/CFG storage514(e.g., of embedded SPUD management configuration framework142) that may be maintained on persistent storage140of system104b. In this regard, out-of-band LM/CFG manager516may be configured to perform out-of-band license management with a persistent process and persistent store.

In one exemplary embodiment, each of LM/CFG utilities506may operate in an in-band manner to create SPUD information (e.g., licenses, service tag, MAC addresses, storage maps, IP addresses, user account and login information, etc.) for system104b, e.g., such as in step302ofFIG. 3. In-band LM/CFG utilities506may also retrieve, import, export, validate, and re-generate licenses by interacting with out-of-band LM/CFG manager516across IPMI network520. Examples of tasks include, but are not limited to, steps ofFIGS. 3 and 4described herein. In one embodiment, once SPUD is generated and stored on persistent storage140by LM/CFG utilities506and out-of-band LM/CFG manager516, then the pre-existing combined SPUD and workload information590of a given target system104bmay be removed (wiped) from the system104b. When a new workload image (e.g., gold image) is deployed on the given target system104b, LM/CFG utilities506and out-of-band LM/CFG manager516may also be employed to apply stored SPUD to the given target system104b, e.g., in the manner described in steps406and410ofFIG. 4. Re-generation of licenses from the SPUD may be performed by LM/CFG utilities506and out-of-band LM/CFG manager516, e.g., as described in step408ofFIG. 4.

FIG. 6illustrates one exemplary embodiment600showing possible types of SPUD information602(e.g., licenses and configuration information) that may be present, for example, on an information handling system104. As shown, SPUD602may include the indicated location instances604and606, as well as Emb.1608and licenses610. Emb.1608may include NIC.2616with InfoSet628(e.g., NIC firmware, drivers, network, IP and MAC addresses, etc.), and remote access controller (RAC)618with InfoSet630(e.g., version, generation, type, licenses, etc.). Licenses610may include system specific multiple license instances620and622as shown. Location instance604may include Bios612and InfoSet624. Location instance606may include redundant array of independent disks (RAID)614and InfoSet626(type of RAID controller, RAID controller password, disk identification, supported RAID levels such as RAID 1, RAID 2, etc.).

It will be understood that the configuration of the particular embodiments illustrated inFIGS. 1 and 2, and inFIGS. 5 and 6is also exemplary, and that other configurations are possible.

It will be understood that one or more of the tasks, functions, or methodologies described herein may be implemented, for example, as firmware or other computer program of instructions embodied in a non-transitory tangible computer readable medium that is executed by a CPU, controller, microcontroller, processor, microprocessor, FPGA, ASIC, or other suitable processing device.