USPatent applicationPatented

Computer configuration chronology generator

Granted 13 Apr 2010 · 3 office actions

Current assignee: Hewlett-Packard Development Company, L.P. · originally Hewlett Packard Enterprise

Law firm: Law firm · Log in to unlock

Attorney: Attorney · Log in to unlock

Inventors: Robert E. Campbell, Keith R. Buck, John R. Diamant, Shane Unruh +1 · Examiner: Thomas Lee · AU 2115 · TC 2100

Application· this page
11/409,754
filed 24 Apr 2006
Publication
Not published
not published
Patent
US 7,698,545
granted 13 Apr 2010

Life of the application

15 dated events
⤢ drag to zoom20062008201020122014201620182020202220242026ProsecutionOwnershipTerm & fees
ProsecutionOwnershipTerm & feeshover for detail · click to open

Abstract

The present invention provides a computer system with a chronology generator for generating a chronology for a series of computer configurations.

Description

6 parts
›BACKGROUND OF THE INVENTION

Herein, related art is discussed to aid in understanding the invention. Related art labeled “prior art” is admitted prior art; related art not labeled “prior art” is not admitted prior art.

Due to ever increasing and changing demands for computer resources, computer systems are often reconfigured, e.g., rearranged or expanded. In complex server environments, changes to server configurations must be carefully planned. Some server administrators manually prepare documents that represent the current configuration and use these to plan changes. However, such documents take a lot of time to create, are prone to mistakes, can easily become out of date, and may be difficult to locate when they are needed to return to a previous configuration.

The problems in tracking configuration changes are even more complex when the configuration changes involve virtual machines. A virtual machine can be used in exactly the same manner as a physical computer, but it also allows for powerful models in which it is created for a limited duration to accomplish a specific task and is then discarded like a paper cup. In this model, traditional systems analysis runs into two problems: 1) the target system may not exist by the time analysis is complete; 2) the issues found in the target system may have been passed onto children that did not exist when analysis was initiated.

›BRIEF DESCRIPTION OF THE DRAWINGS

The following drawings are of embodiments/implementations of the invention and not of the invention itself.

FIG. 1 is a schematic illustration of a computer system in accordance an embodiment of the invention. The pluses in FIG. 1 indicate virtual machine updates.

FIG. 2 is a block diagram showing hierarchical relations among components of a server of the system of FIG. 1 .

FIG. 3 is a block diagram of a sample genealogy for the system of FIG. 1 . Note that the sample genealogy shown in FIG. 3 is related to but not the same as a sample genealogy shown in FIG. 1 .

FIG. 4 is a flow chart of a method in accordance with an embodiment of the invention.

FIG. 5 is a schematic illustration of a second computer system in accordance with an embodiment of the invention.

FIG. 6 is a flow chart of a second method in accordance with an embodiment of the invention.

›DETAILED DESCRIPTION · 1 of 4

A server environment AP 1 in accordance with the invention includes two servers S 1 and S 2 , a manager workstation 11 , and a network infrastructure 13 communicatively connecting the foregoing servers to each other, as shown in FIG. 1 . Each server S 1 , S 2 hosts virtual machines, the number, characters, and configurations of which can change over time. For example, at time T 1 , server S 1 hosts virtual machines A 11 , B 21 , and B 31 , while server S 2 hosts virtual machines C 11 , D 11 , and E 11 . At time T 2 , server S 1 hosts virtual machines A 11 , A 12 , and B 41 , while server S 2 hosts virtual machines B 51 and D 21 . At time T 3 , server S 1 hosts virtual machines A 21 , A 31 , and B 41 , while server S 2 hosts virtual machines B 61 , D 31 , and E 12 .

Virtual machines A 11 , B 11 , C 11 , D 11 , E 11 , and E 12 were generated from media, e.g., installation disks or images. Virtual machines A 12 and B 51 were generated by cloning virtual machines A 11 and B 31 , respectively. Virtual machines A 21 , A 31 , B 61 , D 21 , and D 31 were generated by applying updates to their respective parent virtual machines.

Server S 1 has a host operating system H 1 , that hosts virtual machines, e.g., virtual machines A 11 , B 21 , and B 31 at time T 1 . Each virtual machine can run a client operating system, e.g., client operating system C 1 runs on virtual machine A 11 , client operating system C 2 runs on virtual machine B 11 , and client operating system C 3 runs on virtual machine B 21 , as shown in FIG. 2 . Each client operating system can host one or more application programs, e.g., client operating system C 1 hosts application programs A 1 and A 2 , client operating system C 2 hosts application program A 3 , and client operating system C 3 hosts application program A 4 . Also, host operating system H 1 can support application programs, e.g., application program A 5 , directly.

The invention provides for single and multiple server environments. Each server can be unpartitioned (have a single partition) or can be divided into plural hard partitions. A server or server partition can host zero, one, or plural virtual machines. A master change control program can run on a separate workstation, as in server environment AP 1 , or on a partition of one of the servers being chronicled. The host operating system is typically provided by the server manufacturer, while the client operating systems are often chosen for their compatibility with the application programs the customer desires to run; the virtual machines are chosen to interface the client operating systems with the host operating system.

Host operating system H 1 of server S 1 maintains configuration files CF 1 , which collectively specify the current configuration of server S 1 , including hardware and software resources, information such as processor type and power modes, the name and version number of operating system H 1 , specifications for any hard partitions, including what resources they include, specifications for virtual machines including their resource requirements, client operating systems, operating parameters, application program versions and patch levels. In the case of virtual machines, the date of the most recent installation or cloning and some current configuration data are represented in configuration files CF 1 . For example, configuration data reflecting features that can affect resource utilization are represented in configuration files CF 1 , while some less impacting configuration changes, e.g., color schemes, are not. Data regarding clone ancestors and descendants are maintained.

Server change control (SCC) SC 1 controls configuration changes and stores configurations as a function of time, both on a scheduled basis and in response to configuration change events. Server change control SC 1 monitors configuration files CF 1 , and makes a log of any changes to them. Also, server change control SC 1 records the data in configuration files as a function of time periodically. In addition to information obtained from configuration files CF 1 , server change control can poll hardware and software entities for their configuration information. The series of configurations and events is stored in chronology database CD 1 .

Server change control SC 1 can read the configuration of the server S 1 from configuration files CF 1 and store its configuration in chronology database CD 1 . A time (e.g., date) and a revision number are assigned to each configuration stored. In alternative embodiments, a serial number can be assigned in lieu of a time stamp.

Any stored configuration can be tagged with one or more descriptive names. Each name can be used to refer to that configuration in the same way that the revision number or date can be used. Changes can be made to any stored configuration without changing the actual configuration of the server. These changed configurations can be stored in chronology database CD 1 with their own tags, version numbers, and dates. Anything that can be done to a stored configuration that came from the server's configuration can also be done to these modified configurations. Server change control SC 1 can be configured to query the server at set times and compare the current configuration to a stored configuration. If they differ it can notify the administrators of the server.

Server change control SC 1 can display the differences between any two previously stored configurations. It can do this based on date or revision number. It can also display the differences between the current configuration of the server and any previously stored configuration. It can take any previously stored configuration and restore the server to that configuration, provided that all the hardware and software that was present when the configuration was first stored is still present. In some cases, e.g., where there is hardware or software missing, where an earlier configuration cannot be restored automatically, server change control SC 1 provides directions on how an administrator can restore the system. Host H 2 , server change control SC 2 , configuration files CF 2 , and chronology database CD 2 have analogous roles with respect to server S 2 .

›DETAILED DESCRIPTION · 2 of 4

Manager workstation 11 runs a master server change control program 15 that maintains a master chronology database 17 for server environment AP 1 . Master change control 15 performs a function with respect to server environment AP 1 that is in many ways analogous to the functions of server change controls SC 1 and SC 2 with respect to their respective servers. Server change controller 15 periodically poles server change controls SC 1 and SC 2 over network 13 for updates to chronology databases CD 1 and CD 2 , respectively.

Master change control 15 uses the data so obtained to update master chronology database 17 . In addition, master change control 15 records environment wide configuration and other configuration changes, including the addition and removal of servers, changes in partitioning, etc. Change controls 15 , SC 1 , and SC 2 provide for automatic saving of the current configuration, discovery of unplanned changes, for convenient determination of the differences between two configurations, and automatic or guided restoration of prior configurations.

Server change controllers SC 1 , and SC 2 generate virtual machine genealogies like those shown for servers S 1 and S 2 in FIG. 1 . Master change control 15 generates virtual machine genealogies that span servers S 1 and S 2 , as shown in FIG. 1 as a whole. Some portions of a genealogy are discussed below.

At time T 1 , virtual machine A 11 is on server S 1 . It is also present at time T 2 , but now has a clone A 12 . The original is reconfigured to yield virtual machine A 21 at time T 3 . In the meantime, clone A 12 is updated (e.g., with a manufacturer-distributed patch) to yield virtual machine A 31 . This is a very useful genealogy pattern. It allows virtual machine A 11 to continue running while a clone is updated and tested before assuming the task virtual machine A 11 was handling. Examining the chronology for descendants of virtual machine A 11 , it is easy to see that two different versions of the virtual machine coexist. If further instances of this virtual machine are to be generated, it will make a difference whether A 21 or A 31 is cloned.

The future for virtual machines A 21 and A 31 can be similar to the illustrated genealogical segment for virtual machines B 21 and B 31 on server S 1 at time T 1 . Virtual machine B 31 is an update of a clone of the virtual machine B 21 . Once virtual machine B 31 is validated, the task and configuration for virtual machine B 21 is transferred to virtual machine B 31 , yielding virtual machine B 41 . (The dashed arrow from virtual machine B 21 to virtual machine B 41 indicates a transfer of configuration data and task). Virtual machine B 41 persists through time T 3 , while virtual machine B 21 has been inactivated by time T 2 .

Virtual machine B 31 also spawns a clone, virtual machine B 51 , on server S 2 at time T 2 . This clone is updated on server S 2 at time T 3 to yield virtual machine B 61 . Possibly the task performed by virtual machine B 41 on server S 1 will be transferred to virtual machine B 61 on server S 2 in accordance with a resource reallocation event. Upon such a transfer, virtual machine B 41 can be inactivated, saving computing resources on server S 1 .

Server S 2 hosts a virtual machine C 11 at time T 1 , but this virtual machine is terminated before time T 2 , e.g., because the task it was responsible for had been completed. Server S 2 also hosts a virtual machine D 11 , which is updated to virtual machine D 21 at time T 2 , and then again to virtual machine D 31 at time T 3 . Server S 2 hosts a virtual machine E 11 at time T 1 , but that virtual machine is terminated by time T 2 . However, it is reactivated so as to yield virtual machine E 12 at time T 3 ; a different identity is assigned to indicate the intervening discontinuity. The dotted line between virtual machines E 11 and E 12 shows that the configuration of virtual machine E 11 is transferred to virtual machine E 12 .

FIG. 3 shows an extended genealogy 19 from virtual machine A 11 that extends beyond the time frame represented in FIG. 1 . In this genealogy, vertical downward lines represent updates or configuration changes; while diagonal solid lines indicate clones, and dashed oblique lines indicate configuration transfers from one virtual machine to another. Thus, FIG. 3 shows a couple of clones that are upgraded and tested before tasks run by ancestors are transferred to descendants. In particular, virtual machine A 51 is generated by cloning A 31 , while virtual machine A 31 becomes virtual machine A 41 when it adopts the configuration of virtual machine A 21 . After virtual machine A 51 is validated, it assumes the configuration of virtual machine A 41 , yielding virtual machine A 61 .

FIG. 3 also illustrates a metric for measuring diversity among different families of software entities such as virtual machines. The circled numbers are counts from virtual machine A 21 to virtual machine A 61 . The counts are along connected pairs of virtual machines. As these two virtual machines are farther apart than other pair in FIG. 3 , the measure of their separation serves as a measure of diversity for the entire family of virtual machines in FIG. 3 . Alternatively, the sum of the separations of all pairs in a family can serve as a metric, as can a sum of squares of the separations. Also, a diversity metric can employ various weighting schemes, Hemming distances, etc. Note that the diversity metric for unrelated entities can be considered infinite.

This diversity metric has a number of uses. For example, in a tightly controlled production environment, a high diversity value might indicate more diversity than is desired. For example, distantly related members of a family are less likely to have been updated in the same way. Accordingly, a genetic algorithm could be used to indicate when members of a virtual machine family need to be checked for conformity. If family members are confirmed to be “out-of-sync”, a favored virtual machine can be picked and its clones can replace more distant family members.

›DETAILED DESCRIPTION · 3 of 4

In some contexts, a high diversity value can be preferred. For example, during stability testing of new software, clones can be generated and reconfigured. The diversity measure can be used to ensure that a sufficient number of different configurations have been tested for reliability to be confirmed. Similarly, diversity can be helpful in tuning kernel parameters. Another use for a diversity measure applies where multiple variations of a program or virtual machine are used to better withstand attack from a non-mutating virus by replacing infected virtual machines with clones of surviving virtual machines.

From a display of the genealogy of FIG. 3 , it is also possible to generate comparisons and restorations of virtual machines, even between siblings and cousins. With access to the genealogy, analysis can be performed on the behalf of an ancestor virtual machine with the results causing actions to be taken across all descendants. In the “traditional” model this might be the installation of a patch, and in the “disposable virtual machine” or “paper cup” world each virtual machine in a family would transfer its tasks to a virtual machine belonging to a new “family” and then expire. The use of this family tree could also be used to identify equivalent sources for use in cloning busy virtual machines.

While the genealogical analysis will typically apply to descendant clones, the analysis can also be applied to a characterization of a parent of a clone based on an analysis of the child clone. For example, an administrator might be responsible for performing a detailed security analysis of production level machines. It may be due to load and or due to data security concerns that the administrator is not allowed access to the production nodes. A child node could be created for the purpose of the analysis where the “true” target was the parent and all cousins.

A method M 1 of the invention is flow-charted in FIG. 4 . A configuration change is detected at method segment MS 1 . Of course, if the server change control function directs the configuration change, the detection is automatic. However, if another entity directs the configuration change, it can inform the server change control function of the change. Also, the server change control function samples configurations periodically (e.g., hourly) so that it can detect configuration changes even without such notice. At method segment MS 2 , the new configuration is recorded in the chronology database, which contains configuration descriptions and time-stamp data to indicate their relative order in the chronology.

At method segment MS 3 , information regarding one or more configurations is displayed, e.g., on a computer monitor. From this display, a user can request a comparison of a configuration with its predecessor or between any two selected configurations at method segment MS 4 . Alternatively, at method segment MS 5 , by right clicking on graphical or textual representations of non-current configurations and selecting “restore” from a pop-up menu (or other selection means), a user can cause the selected configuration to be restored. The restoration can be automatic if all the enabling software and hardware is in place. Otherwise, the server change control function can generate instructions for restoring the earlier configuration. With alternative embodiments, e.g., with other user interfaces, users may avail themselves of other facilities for inputting commands.

The present invention provides the ability to manage a family of dynamic, cloned virtual machines as a group rather than as a set of individual systems. Each node is identified by name and time-stamp of the last reconfiguration. Each reconfiguration is identified as a change to installed software or to configurable parameters. This approach provides a valid analysis even when: 1) the target system may not exist by the time analysis is complete; and 2) the issues found in the target system may have been passed onto children that did not exist when analysis was initiated.

The data can be stored under two different models. A central repository can be maintained on the non-virtual server as in chronology databases CD 1 and CD 2 . In an alternative embodiment, each virtual machine can record and update a local database. In either case, full data for descendants and cousins are recorded.

A second computer system AP 2 in accordance with an embodiment of the present invention is shown in FIG. 5 . Computer system AP 2 includes a set of computer 501 that undergoes a series of configuration changes from a 1 st configuration to an nth configuration. A chronology generator 503 records the configuration changes in a chronology 505 in computer readable media 507 . Flow-charted in FIG. 6 is an associated method M 2 in accordance with an embodiment of the invention, a method segment M 21 involves detecting 1 st through nth computer configurations. In method segment M 22 , respective descriptions of the configurations are generated and recorded in the chronology.

Herein, a “computer system” is a set of interconnected computers. A “computer” is a machine for manipulating data according to a list of instructions, known as a “program”. A “partition” is all or part of a computer that can itself function as a computer, e.g., run its own instance of an operating system. If the partition results from configuring hardware into separate partitions, it is a “hard partition”. If the partition results from software allocating computing resources it is a “soft partition”. Herein, an unqualified “partition” can be hard or virtual.

A “virtual machine” is software that creates an environment between the computer platform and the end user in which the end user can operate application software. In other words, a “virtual machine” is software that runs on a host operating system that runs on hardware and on which a client operating system can run. Thus, a “virtual machine” allows an application to be run on an otherwise incompatible software/hardware platform.

›DETAILED DESCRIPTION · 4 of 4

“Clone” refers to the process of duplicating an existing data set or object. There are two typical types of cloning. Shallow cloning is a simple copy of the original maintaining references to the original data set or object's references. Changes to a shallow clone will affect both the orignial and the clone. Deep cloning is a full and independent duplication of the original which will remain unchanged if the original is changed following the cloning process. While the preceding discussion emphasizes “deep cloning”, the invention also provides for recording the results of shallow cloning. “Restoring” refers to returning to a previous state.

Herein, “Configuration” refers to a persistent but changeable arrangement of functional units according to their nature, number, and chief characteristics. Often, configuration pertains to the choice of hardware, software, firmware, and documentation. “Configuration” is a relatively persistent type of state, e.g., as opposed to the contents of an instruction pipeline that can change millions of times per second. Herein, “functional unit” refers to servers, hard and virtual partitions, secure and other resource partitions, containers, bochs, separate servers using ignite or other bare metal provisioning technology, vmware, Wine (“Wine Is Not an Emulator” for running Windows software under Linux), separate physical servers using a storage area network (SAN), dynamic root disks (DRD) that provide one or more additional copies of the operating system image that will take effect upon a reboot, full disk images (dd), or other provisioning, virtualization, or partitioning scheme.

A “chronology” is an arrangement of states, from either earliest to latest or from latest to earliest; the “arrangement” can be indicated by time stamps or serial numbers. “Computer-readable media” is any media that can be read by a computer, typically solid-state memory and disk-based memory. A “representation” is something that represents something else, as a graphic element can stand for a computer component for method segment.

While the emphasis herein has been on servers and virtual machines, genealogical information can be gathered regarding computers generally and regarding other clonable software, including application programs. Herein, “cloned software” encompasses both source and target of a cloning operations. Other configuration changes can be controlled, monitored, and represented in the chronology databases. These include changes to physical and virtual partitions, changes to the host operating system, and changes in application programs. These and other variations upon and modification to the illustrated embodiments are provided for by the present invention, the scope of which is defined by the appended claims.

Claims as granted

8 claims

Log in to read the claims of this application.

Log in to unlock

Classifications

5 codes
IPC · International Patent Classification
Section G — Physics
  • G06F15/177
USPC · US Patent Classification
713/1709/224709/223709/221

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this application are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoomJul 2006Jan 2007Jul 2007Jan 2008Jul 2008Jan 2009Jul 2009Jan 2010Jul 2010USPTOApplicantNon-final rejectionNon-final rejectionFinal rejection
USPTOApplicanthover for detail · click to open
Pendency
4.0 y
1,450 days filing → grant
Office actions
3
non-final + final
Responses
3
no RCE
Examiner
Thomas Lee
art unit 2115 · TC 2100
Citations: 13 back · 57 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Documents

Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.

Log in to unlock

Chain of title

⤢ drag to zoom20062008201020122014201620182020202220242026Owner 1Owner 2Owner 3liens, releases & corrections
TitleLienhover for detail · click to open

See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.

Log in to unlock