Unstacking software components for migration to virtualized environments

Techniques for unstacking software components are provided. The techniques include discovering a plurality of software components and one or more dependencies between the software components in a computer system, designing a plurality of unstacking options for unstacking said components, and selecting one of said unstacking options to unstack said components.

FIELD OF THE INVENTION

The present invention relates to the electrical, electronic and computer arts, and, more particularly, to information technology (IT) and the like.

BACKGROUND OF THE INVENTION

Most existing migration and server consolidation considers entire images, that is, all software running on a physical server or in a virtual partition or virtual machine as a whole. Such approaches aim to deploy these images on fewer servers, typically virtualized, while fulfilling the resource requirements of all of the images. An image may contain one or more key software components. A key software component can include, for example, a web server, an application server, a database server, the individual code modules in the application server, the individual databases in the database server, etc. An image may also be used in one or more enterprise applications. An enterprise application might include, for example, a travel expense application, a product web catalogue, a computer-aided manufacturing application, etc. (that is, a larger IT entity, including one or more interacting software components, that fulfils overall requirements and has to be operational as a whole). Existing approaches, however, lack techniques for migration and other transformation cases to split up different software components that were running on one image (this is also referred to herein as unstacking).

SUMMARY OF THE INVENTION

Principles of the invention provide techniques for unstacking software components, typically for migration to virtualized environments. In one aspect, an exemplary method includes the steps of discovering a plurality of software components and one or more dependencies between the software components in a computer system, designing a plurality of unstacking options for unstacking said components, and selecting one of said unstacking options to unstack said components.

As used herein, “facilitating” an action includes performing the action, making the action easier, helping to carry the action out, or causing the action to be performed. Thus, by way of example and not limitation, instructions executing on one processor might facilitate an action carried out by instructions executing on a remote processor, by sending appropriate data or commands to cause or aid the action to be performed.

One or more embodiments of the invention or elements thereof can be implemented in the form of a computer product including a computer readable storage medium with computer usable program code for performing the method steps indicated. Furthermore, one or more embodiments of the invention or elements thereof can be implemented in the form of an apparatus including a memory and at least one processor that is coupled to the memory and operative to perform exemplary method steps. Yet further, in another aspect, one or more embodiments of the invention or elements thereof can be implemented in the form of means for carrying out one or more of the method steps described herein; the means can include (i) hardware module(s), (ii) software module(s) executing on one or more hardware processors, or (iii) a combination of hardware and software modules; any of (i)-(iii) implement the specific techniques set forth herein, and the software modules are stored in a computer readable storage medium (or multiple such media).

One or more embodiments of the invention may offer one or more of the following technical benefits:more uniform images after unstacking, by ending up with one key software component per image;simpler management after unstacking, by ending up with one key software component per image;future changes are easier on images with single software components (for example, further migration, in particular in live-migration scenarios);increasing the range of client environments that can be migrated to efficient cloud usage; andseparating software components by enterprise applications (for example, for when a company splits up, or when a company wants to separate its enterprise applications for financial, auditing, regulatory compliance, or security reasons).

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Principles of the present invention include providing enterprise support as a service. As used herein, “stacked” software components indicate several software components that are running on the same server or virtual image. The stacked software components may support one or more enterprise applications. For instance, several databases hosted in the same database server instance may belong to different enterprise applications, or different enterprise java beans hosted in the same application server may belong to different enterprise applications. As also used herein, “unstacking” indicates taking such software components apart so that they no longer run on the same server or virtual image. One typical goal of unstacking, for example, is to separate the software components according to the enterprise application, that is, after the unstacking, each server or virtual image will serve only one enterprise application. Another typical goal of unstacking is to separate the software components so that after unstacking there is only one key software installation or instance on each server or virtual image.

As described herein, one or more embodiments of the invention result in producing one key software component per image. This is of particular benefit if a cloud is a potential goal of the migration or transformation, as clouds gain much of their cost efficiencies from uniformity of images. Additionally, platform-as-a-service clouds can even come with a set of preconfigured images with one or a small number of software components.

Additionally, one or more embodiments of the invention include facilitating simpler management after unstacking because of achieving one key software component per image. For instance, such an image can be managed primarily as a database server, or an application server. Consequently, all users and security settings on this image belong to just this key software component, and all storage or performance problems are likely due to that software component, etc. Accordingly, such management tasks can be more easily handled. Simpler user and security management may also result, for example, if one unstacks by enterprise application rather than by software components.

As noted, in traditional migration, a typical approach is to migrate individual operating system images, and the goal is either to simply move them (for example, to newer hardware) or to consolidate them, typically by virtualization and putting several images on the same physical server.

One or more embodiments address a migration use case wherein initially several software components are stacked on one operating system image, and the goal is to separate them and put each one, or certain subsets of them, on different physical or virtual machines. This is referred to herein as “unstacking.” It is believed that unstacking may be particularly suitable for use in connection with cloud computing. Advantages of unstacking, which may be realized in one or more embodiments, include more uniform images, simpler management, and that future changes are easier on unstacked images (for example, further migration, in particular in live-migration scenarios).

Applicability of unstacking has arisen with the advent of virtualization and clouds. In the past, with physical servers, stacking software often made the best use of hardware, because there are relatively few available hardware sizes and fully utilizing existing servers was a key cost driver. Also, in early times of virtualization, server utilization was still a key driver and corresponding migration focused on physical-to-virtual transformation and putting several entire images onto one physical server. Now, that server utilization has largely become optimized due to virtualization, in particular with novel cloud environments, and the management cost and simplicity become a quite significant factor. Furthermore, IT management costs have generally become a dominant cost type in overall IT costs.

In existing approaches, migration is essentially always a one-to-one mapping or a consolidation, n-to-one. In one or more instances addressed by one or more embodiments of the invention, there are many servers, logical partitions (LPARs), and virtual machine images that contain several software components (for example, both IBM WEBSPHERE APPLICATION SERVER (WAS) software and IBM DB2 database software (both available from International Business Machines Corporation, Armonk, N.Y., USA)), or several database installs or instances belonging to different enterprise applications. This type of arrangement is referred to as “stacked.” Note that the specific IBM software mentioned is purely for purposes of illustration and not limitation. An LPAR is a subset of computer's hardware resources, virtualized as a separate computer (as will be appreciated by the skilled artisan), and a physical machine can be partitioned into multiple LPARs, each housing a separate operating system.

With the increasing flexibility of image sizes and placement as offered by virtualization and in particular cloud computing, it may be beneficial to separate such software components again, because management of images with many software components, often belonging to more than one enterprise application, is typically considerably more challenging than managing simpler images. This aspect is referred to herein as “unstack.”

Advantageously, one or more embodiments of the invention provide techniques for automated unstacking methods or systems, and are not limited to treating entire images. In one or more embodiments, unstacking techniques make use of module-level dependency discovery. By way of example only, carrying out such discoveries can be performed using techniques such as those detailed in, Joukov et al., “ITBVM: IT Business Value Modeler,” IEEE International Conference on Services Computing (SCC 2009), Bangalore, September 2009, and in Joukov et al., “Application-Storage Discovery,” SYSTOR 2010, Haifa, May 2010, and in U.S. patent application Ser. No. 12/511,506, filed on Jul. 29, 2009 and U.S. patent application Ser. No. 12/553,486, filed on Sep. 3, 2009.

One or more embodiments advantageously significantly increase the range of client environments that can be migrated to efficient cloud usage. In at least some instances of the invention, it is expected that a migration request for a stacked image will also lead to unstacked proposals.

Reference should now be had toFIG. 1, which provides a non-limiting example of stacked applications that can be addressed by one or more embodiments of the invention. There are two servers, Server S, numbered102, and Server T, numbered104. A web server106and an application server installation (APS)108are stacked on Server S. A database (DB) installation110and the file system (FS)112supporting the actual data are stacked on Server T. Web server106hosts uniform resource locators (URLs)114,116,118,120, and122, also designated as u, v, w, x, and y, respectively. Multiple application servers (App server A, numbered124, and App server B, numbered130) are stacked on APS108. App server A includes modules126and128, while App server B includes module132. Multiple database instances134,138are stacked in the database installation110in Server T. Instance134includes database a, numbered136, while instance138includes database b, numbered140, and database c, numbered142.

URLs114,118, and122, Module1numbered126, Module3numbered132, and database a numbered136and database c numbered142represent a first enterprise application. URLs116and120, Module2numbered128, and database b numbered140represent a second, different enterprise application. Thus, it can be said that in one dimension, these two enterprise applications are stacked on Servers S and T. In another dimension, it can be said that a web server106and an application server (APS) installation108are stacked on server S, and that a database (DB) installation110and the file system112supporting the actual data are stacked on Server T. It can also be said that multiple application servers124,130are stacked in Server S, and multiple database instances134,138in Server T.

As detailed herein, taking software components apart is at least an option in unstacking migration, in accordance with one or more embodiments of the invention.FIGS. 2 through 5depict examples of unstacking options (using many of the same numbered components as depicted inFIG. 1).

InFIG. 2, unstacking is done along the dimension of key software components (which are further described herein). Thus, web server106, application server installation APS108, DB install110, and files system112each run on a different image (typically virtual) after the unstacking. These images are denoted Server S102, Server U103, Server T104, Server V105inFIG. 2. Note that all servers will still have some file systems, but this particular example considered only those parts of the overall file systems to be key software components that hold the key application data, which are stored in the databases.

Retaining the names and numbers of servers S102and T104(and thus indicating that these are the same servers as in the pre-migration state inFIG. 1) is only one example of realizing unstacking in the dimension of key software components. It indicates that the application server installation APS108and the file system112may be removed from these servers or virtual images and moved to new servers or virtual images. Alternatively, new servers or images may also be used for the web server106and for the DB install110, for instance, because one may also want to virtualize them, use a smaller image, or newer hardware.

InFIG. 3, unstacking is done along the dimension of enterprise applications. By way of illustration, in the example of a travel application, and considering the “white” enterprise application inFIG. 1, the two URLs might be the URLs for the traveler and the approver, respectively, where the application server Module2handles the approval workflow logic, and the database DB b contains current and past travel applications as well as general information such as preferred airlines and maximum allowed prices. InFIG. 3, the “white” enterprise application and the “grey” enterprise application are moved to different servers, which are denoted inFIG. 3as S-white102, T-white104, S-grey107, and T-grey109(which includes, for example, file system grey113). Note that at the level of detail of knowledge shown about the software components and what enterprise applications they support, the uniform resource locators (URLs), application-server modules, and databases each belonged to one enterprise application only, while the file system112supported both enterprise applications. Hence, separating the file system required further analysis (for example, into individual mount points or even directories or files supporting the different databases b140and a and c136and142, respectively).

In one or more embodiments of the invention, this can be performed using, for example, the technologies for module-level dependency discovery detailed herein. Also note that this type of unstacking requires duplicating the outer levels of software components (that is, there are two web servers, two application server installations, etc. now, and also the application server A124and the database instance138have been duplicated, while application server B130and database instance134were only needed in the grey enterprise application).

FIG. 4depicts an example of further simplification of the software components for the grey enterprise application (that is, extending the design fromFIG. 3). Here, Module1and Module3, numbered126and132, are moved into the same application server instance A124, and the databases a136and c142are moved into the same DB instance134. This can be referred to as stacking rather than unstacking, but may be considered as an option at the same time if the goal is simple standardized images. By way of example and not limitation, in such an instance as described above, settings in App server A124and DB instance134may need to be compared with those of former App ServerB130and DB instance138, respectively and/or changed to accommodate additional modules. By way of example, such settings can include server and instance owners, ports on which the software listens for connections, backup schedules of the databases, etc. If they are not the same initially, standardization may be desired; in particular as it is known that they belong to the same enterprise application now.

FIG. 5depicts an example of unstacking along both the dimension of software components and the dimension of enterprise applications, here for the “white” enterprise application. Note that after the unstacking, if the resulting servers are virtual, some of them may still be placed on the same physical servers according, for example, to their resource consumption. Placing virtual images on physical servers by their resource consumption includes techniques that should be known to one skilled in the art.

Reference should now be had toFIG. 6, which presents a flow chart600of exemplary method steps, according to an aspect of the invention. In step602, discover one or more software components as well as their dependencies.FIG. 1is an example of the result of such a discovery in a graphical form, corresponding closely to actual results that can be produced with module-level dependency discovery as described herein, except that there would be no distinction of different enterprise applications, such as the white and the grey ones inFIG. 1, after this step. One or more embodiments of the invention can include using a module-level automated discovery tool (as described herein) for this step because software components and their dependencies are very rarely known at this level of detail in enterprises.

Also, the plurality of software components can include, for example, an installation component, wherein the installation component includes executable code of a product as installed on at least one of an image and a physical server. Also, the software components can include a service component, for example, an application server component and/or a database instance component, wherein those components comprise running code and typically listen for connections from other software components. A services component must belong to an installation component. The software components can additionally include one or more individually manageable components inside the service components; for example, individual applications in an application server component or individual databases in a database instance component.

The graphical form of output is only one example; for the automation of the following steps, there can also be an output format better suitable to automated processing, such as, for example, a component-and-dependency database or an extensible markup language (XML) file containing the components and their dependencies. This data structure will contain both the relation shown as box inclusions inFIG. 1, corresponding to one software component being implemented in an environment or on an abstraction provided by another software component (such as a module in the environment of an application server), and those shown by arrows which typically correspond to interaction.

With regard to dependencies, note that, typically, programs can be obtained by assembling various components at runtime. Dependencies refer to the external resources on which a program may depend. As used herein, “external resources” are defined as any resources available outside of a given program that a program reads, looks up, interacts with, or writes to during its operation.

In optional but preferred step604, trace enterprise applications via the dependencies discovered in step602. In this case, the first and second enterprise applications as mentioned above (for example, “white” and “grey” in the figures) would be traced. This can be needed, for example, because it is not known in advance which software components belong to which enterprise application. In particular, when enterprise applications share servers or software components, the details of what belongs to what are rarely fully documented. Typically, however, at least something about the enterprise applications is known, in particular how users interact with them. Thus, in the example ofFIG. 1, it is typically known which URLs belong to which enterprise applications. Here u, w, and y belong to the grey application and v, x belong to the white application.

From there on, following the directed graph of dependencies can yield all other components that contribute to this enterprise application. For instance, following the dependency from URL u114, one sees that Module1, numbered126, belongs to the grey enterprise application, and next following the dependency from Module1, numbered126, shows that database a136also belongs to the grey enterprise application. Algorithms for such tracing of dependencies in graphs (also referred to as transitive closure) are known by one skilled in the art.

Additional details for a special case where dependencies can be defined at different levels of component inclusion are described in Joukov et al., ITBVM: IT Business Value Modeler; IEEE International Conference on Services Computing (SCC 2009), Bangalore, September 2009. This aspect is not shown inFIG. 1, but, for example, the dependency of Module3, numbered132, to database c142, might actually be defined on Application server B130. If, similarly, the dependencies of Module1and Module2were defined as configurations of application Server A124, then this technique would not be able to separate that database a136is only used in the grey enterprise application while database b is only used in the white enterprise application (thus allowing unstacking of them as show inFIG. 3). In this case, a more detailed code analysis can be used on these modules to determine which of them uses which of the configurations of the application server A and, thus, ultimately, which of the databases a and b. Additional details for these techniques can be found, for example, in U.S. patent application Ser. No. 12/511,506, filed Jul. 29, 2009, and U.S. patent application Ser. No. 12/553,486, filed Sep. 3, 2009.

Step606includes designing one or more unstacking options. One example option is unstacking along the dimension of key software components as exemplified inFIG. 2, in particular if a benefit sought is more uniform images, simpler management, or migration to cloud. One or more embodiments of the invention include considering all software installations on the images that were analyzed (all boxes in the example figures that are directly inside a Server box), and classifying them into “key software component” and others. This classification can be performed in advance. For example, one or more embodiments of the invention include classifying all database installations, application servers, web servers, and packaged applications as “key software components,” while compilers, script interpreters, browsers, office software, and infrastructure management applications such as storage management agents, virus checkers, and the like are classified as “non-key.”

Additionally, an example unstacking option includes splitting up the plurality of software components such that each image serves only one enterprise application. Another example unstacking option can include splitting up the plurality of software components such that each image contains only one key software component and/or a set of two or more key software components as the two or more key software components exist on a cloud image. An example unstacking option can also include splitting up the plurality of software components and duplicating one or more of the plurality of software components. Further, another example unstacking option can include joining one or more software components after an initial splitting up of the plurality of software components. Yet another example unstacking option includes splitting up data in a database according to affinity of the data to an enterprise application.

In a case wherein an image contains a software installation that has not been pre-classified, a user interface may show it and ask the user to input the classification. The design can contain one image per key software installation identified (such as the four servers102to105inFIG. 2). As to the non-key software, one or more embodiments of the invention can include replicating the non-key software on each image, as it may play general helper roles on each image. If an installation type is identified as non-key, but it is part of the software components whose dependencies can be tracked in detail, then this software might also be distributed with the key software it serves. For instance, if file systems were not classified as key software components, and one file system was used by multiple key software components, then detailed tracing of dependencies to mount points might show what parts of this file system would go on the same server as each of these key software components.

If a goal includes migration to cloud, then the detailed design for unstacking along the dimension of key software components will be strongly influenced by images that the cloud offers. By way of example, this can include platform-as-a-service clouds, where images with certain software installations are available in an image catalogue. For instance, if the cloud catalogue contains an image with a web server alone and an image with an application server alone, then unstacking the web server106and the APS install108onto two different images, as inFIG. 2, enables one to use these cloud images without installing additional key software on them. Also, for example, installing additional key software may even be disallowed by cloud management standards in certain enterprise environments.

Another unstacking design option is along the dimension of enterprise applications, as shown inFIG. 3. This is a typical design option, for example, if a goal includes separating enterprise applications for company split-up or for simpler accounting, auditing, security management, and the like. As described herein (for example, in the description ofFIG. 3), a design method can be to separate software components at the first level of granularity where each component only serves one enterprise application, and to replicate containing software components if they contained inner software components from more than one enterprise application. WhileFIG. 3depicts an example where URLs, modules, and databases were the first level of granularity that serves only one enterprise application, it is to be appreciated that there can be other situations. For instance, it may turn out that an entire web server, or application server, or database instance, or even application server install or database install is only used by one enterprise application.

Additionally, in many cases, this procedure can sufficiently separate the enterprise applications. In particular, it may be rare that one application server module serves several enterprise applications (for example, because during the design phase of an enterprise application, one will try to keep its modules separate, precisely for modularity). Common databases, however, may be more common (for example, an employee or customer database). If discovery at the finest available level of detail (for example, database tables) of the primary discovery tool does not separate this software component (for example, some or all tables are used by more than one enterprise application), one design option of one or more embodiments of the invention can include leaving this specific software component as a joint component.

In situations where a reason for unstacking includes simpler accounting or security management or the like, one or more embodiments of the invention can still achieve significant advantages by unstacking the other software components. This unstacking of the other software components can also assist in achieving the same goals on the database, because usage and access will be easier to trace when the accessing applications are well distinguished. By way of example and not limitation, one or more embodiments of the invention can include duplicating the component (for example, if one of the enterprise applications only reads the data, it might get a read-only replica of the database, or if a company splits up, both parts may, from now on, get independent customer databases, both initialized with the content of the current customer database).

In yet other cases, one or more additional embodiments of the invention can include separating a database by rows (for example, when splitting up an employee database for a company split-up). This can require analysis of which employees belong to which new company, which will typically be possible, for example, via a SELECT-query on the current owning enterprise units, which is likely to be a column in a table of the same employee database.

In the outer software components that get replicated (such as App server A124and DB instance138inFIG. 3), one or more embodiments of the invention can include attempting to reduce or split configuration settings, corresponding to the fewer contained software components after the unstacking, in particular if any resource reservations are made at that level and individual resource needs of contained components are known. Another change to plan can include, for example, that of owners and users, if they are configured at that level, and if the unstacking is done for reasons of stricter security, auditing and the like or for a split-up of companies.

Optional step608includes carrying out a quantitative analysis (for example, a return-on-investment (ROI) analysis) to compare the unstacking options. This step can include evaluating the costs of the various designs. In one or more embodiments of the invention, this can be carried out for a larger set of images and applications together, because certain costs, like software management costs, can have economies of scale. The costs that may be considered can include, for example, the cost for hosting the resulting images (for example, somewhat more storage will be needed if outer software components are duplicated), costs for cloud images if those can be used, costs of software licenses (depending on the number of installations and other factors prescribed in the vendors' licensing terms), costs of software management (depending on the number of different types of software as well as the number of components), and transformation costs (that is, the costs to produce the designed new images). Also, in one or more embodiments of the invention, the transformation costs are initially estimated, and subsequently are based on statistics of prior unstacking projects.

Step610includes choosing an appropriate one of the unstacking options designed in step606. By way of example, if a goal includes separation of enterprise applications, one will only choose (and possibly only make in the first place) designs that do indeed separate enterprise applications (for example, the designs depicted inFIGS. 3,4, and5, but not the design shown inFIG. 2). If a quantitative analysis, such as an ROI analysis, has been performed in step608, then one or more embodiments of the invention can include, for example, choosing the design with the lowest cost; in one or more embodiments of the invention, this can be done automatically. In one or more additional embodiments of the invention, this step can include a qualitative estimation, for example, based on how many different images one gets with various unstacking options if a goal includes management simplicity; in one or more embodiments of the invention, such choices can also be automated (for example, as a rule-based decision system).

Step612includes migrating the computer system of interest to the new, unstacked configuration selected in step610. Depending on the software components and whether entire software installations are migrated, or individual applications, database instances and the like, or even individual URLs, modules, and databases and the like, various techniques can be used to aid in this step. By way of example and not limitation, a vendor may provide tools to migrate entire product installations from one image or server to another. In other cases, binary migration of the product and its data is possible. In yet other cases, special migration tools, such as those described, for example, in U.S. patent application Ser. No. 12/608,609, filed Oct. 29, 2009, can be used.

FIG. 7is a block diagram illustrating an example embodiment, according to an aspect of the invention. In conjunction with the techniques described herein,FIG. 7depicts software modules used to carry out one or more embodiments of the invention. By way of illustration, raw data720is obtained from source images and provided to discovery module710to generate a model of discovered software components and dependencies722. The model, as well as initial input about enterprise application components723, is provided to an enterprise application tracing module712to generate an augmented model of software components and dependencies724. The augmented model, as well as cloud standards725, is provided to an unstacking option design module714to generate models of unstacking design options726.

The models of unstacking design options are provided to an ROI analysis module716to generate models of unstacking design options with ROI726, which are then provided to an unstacking option choice module718. From module718, a model of a chosen unstacking design option726is provided to a migration module728.

One or more embodiments of the invention, or elements thereof, can be implemented in the form of an apparatus including a memory and at least one processor that is coupled to the memory and operative to perform exemplary method steps.

Input/output or I/O devices (including but not limited to keyboards808, displays806, pointing devices, and the like) can be coupled to the system either directly (such as via bus810) or through intervening I/O controllers (omitted for clarity).

As used herein, including the claims, a “server” includes a physical data processing system (for example, system812as shown inFIG. 8) running a server program. It will be understood that such a physical server may or may not include a display and keyboard. A virtual server running on a physical server will be designated as such.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. One or more embodiments preferably employ a scripting language such as Perl. Furthermore, in addition to object oriented and procedural languages, some embodiments might employ functional languages (for example, Lisp, ML) and/or logical languages (for example, Prolog). The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

It should be noted that any of the methods described herein can include an additional step of providing a system comprising distinct software modules embodied on a computer readable storage medium; the modules can include, for example, any or all of the elements depicted in the diagrams and corresponding descriptions herein; by way of example and not limitation, a discovery module, an unstacking design module that prepares unstacking options according to multiple criteria, and a selection module that selects among the unstacking options. The method steps can then be carried out using the distinct software modules and/or sub-modules of the system, as described above, executing on one or more hardware processors802. Further, a computer program product can include a computer-readable storage medium with code adapted to be implemented to carry out one or more method steps described herein, including the provision of the system with the distinct software modules.