Abstract:
Services that support recovery of a data center require collecting information concerning the service customer&#39;s physical and virtual infrastructure, and specifically the configuration of their operating systems such as UNIX operating systems. Here an automatic discovery tool executes within the context of a secure browser program. Once a user is authenticated, a JavaScript or HTML program seamlessly retrieves a file that is specific to the type and version of the UNIX operating system on the host; the file contains commands and parsing logic for the commands to retrieve configuration data. Once parsed, the program forwards that data to a database so that the replication service provider may then correctly provision recovery systems.

Description:
CROSS REFERENCE TO RELATED APPLICATION(S) 
     This application is related to a co-pending U.S. patent application entitled “BROWSER BASED RECOVERY DISCOVERY” filed Mar. 16, 2012 and given Ser. No. 13/422,084, the contents of which are hereby incorporated by reference in their entirety. 
     BACKGROUND OF THE INVENTION 
     Replication of data processing systems to maintain operational continuity is now required almost everywhere. The costs incurred during downtime when information technology equipment and services are not available can be significant, and sometimes even cause an enterprise to halt operations completely. Replication may be used for many purposes such as assuring data availability upon equipment failure, site disaster recovery or planned maintenance operations. 
     Replication may be directed to either the physical or virtual processing environment and/or different abstraction levels. For example, one may undertake to replicate each physical machine exactly as it exists at a given time. However, replication processes may also be architected along virtual data processing lines, with corresponding virtual replication processes, with the end result being to remove the physical boundaries and limitations associated with particular physical machines. 
     Use of a replication service as provided by a remote or hosted external service provider can have numerous advantages. Replication services can provide continuous availability and failover capabilities that are more cost effective than an approach which has the data center operator owning, operating and maintaining a complete suite of duplicate machines at its own data center. With such replication services, physical or virtual machine infrastructure is replicated at a remote and secure data center. 
     A database file is typically developed with an entry for the critical data processor in the production environment. The database file may contain configuration information so that in the event of a disaster, replica(s) of the customer&#39;s production environment can be brought live at the remote and secure data center. Applications and data can then be accessed on the remote data center, enabling the service customer to continue operating from the “cloud” while recovering from a disaster. From the perspective of the service customer, the replication service provider thus offers a Recover to Cloud (R2C) service that is provided as an on-demand utility (much like the electricity grid) over a network (typically the Internet). This enables a data center operator to replicate critical servers and applications in his production environment to the cloud. 
     SUMMARY 
     Problem Statement 
     Thus there is a need to discover aspects of the configuration of various infrastructure elements in a customer&#39;s production environment in order to support disaster recovery. The infrastructure elements of the production environment may include, servers, databases, work stations and each of these may directed to physical and/or virtual processing machines. 
     It is possible to discover this information manually, such as by providing a series of questions to be answered by an administrative user. However this approach can be tedious, slow to implement, and is prone to errors. 
     Of particular interest is to discover detailed aspects of the operating systems (OS) in use in the production environment. It would be ideal, for example, to discover details of the particular UNIX-compatible operating systems that are deployed, and to do so automatically, securely, remotely, and without the use of agents. 
     Certain administrative UNIX commands are known to produce information of interest, such as processor configuration and installed package information. However the output from these commands is text-heavy, complex, and diverse. Furthermore, the output from a given command may differ depending upon the specific variant of UNIX installed (i.e., Linux, Solaris, BSD, etc.). This makes it difficult to design a generic solution that will work for all UNIX distributions. 
     SUMMARY OF AN EMBODIMENT 
     In general, the present disclosure is directed to a tool for automating the discovery of configuration information in connection with provisioning a recovery system, and in particular, automating the discovery of UNIX configuration information. In one implementation, a Configuration Management System (or CMS) assists human operators with collecting configuration data. One of the functions performed by the CMS is to periodically obtain configuration information concerning the customer&#39;s production environment which may include a number of data processing infrastructure elements such as, but not limited to physical machines, virtual machines, storage sub-systems, database servers, and other data processors which are running a UNIX-based or UNIX-like operating system. The infrastructure elements thus have a live, running UNIX configuration state that is exposed to and can be queried automatically via executable files and associated information distributed by the CMS. 
     The CMS implements the automatic query using one or more commands that are expected to produce configuration information as output. Each command has an associated parsing logic specification as well. The command/parsing logic pairs can be stored in a convenient machine and human readable format such as an .XML file. A single .XML file may contain all of the commands/parsing logic pairs necessary to characterize a particular UNIX distribution. Thus, there would typically be an .XML file created for each UNIX distribution and/or version that is expected to be found in the production environment. 
     The CMS further implements the automatic query by forwarding an executable file to the production environment. 
     In operation, once the type of UNIX operating system is identified, the corresponding executable and .XML files are located and forwarded to run in the production environment such as via a secure shell (SSH) connection. The executable reads a first command from the .XML file and executes the command, such as via a UNIX command, on the associated physical or virtual machine in the production environment. 
     The output from the command is captured by the executable. The associated parsing logic is applied to the command output by the executable to determine configuration information of interest. The process then repeats for each command/parsing logic pair in the .XML file. 
     The executable first stores the resulting configuration information locally in the production environment, such as in a local file or database. This stored information can next be made available for review by an administrative user responsible for the production environment. Once that user is satisfied with the information to be shared with the replication service provider, the information can be forwarded to the CMS. 
     The CMS can then store this configuration information in a configuration survey database for later retrieval and later use in configuring a recovery environment to be brought on line in the event of a failure of the customer&#39;s production environment. The automatically discovered information may be augmented with manually entered information. 
     In one implementation, the UNIX executable may invoke further functions in the production environment. For example, host name(s) and login credential(s) for one or more data processors in the customer&#39;s production environment are collected to enable access to the physical and/or virtual machines to be queried. 
     For example, the executable code may use the host name and login credentials to automatically connect to each machine in the production environment via a secure shell (SSH), and collect configuration information such as manufacturer, model, physical memory, UNIX operating system (OS) type and OS version installed applications and so forth that are necessary to replicate the machine. The code may then locate the correct .XML file to use for that particular UNIX installation, and then process the .XML file as described above to obtain further configuration information about the particular UNIX operating system installation. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present invention. 
         FIG. 1  is a diagram of a replication service environment operating a recover to cloud service for multiple customers, and a specific customer production environment. 
         FIG. 2  is a more detailed flow diagram showing the environment of a configuration discovery process according to the teachings herein. 
         FIG. 3  is an example process flow for an executable file implementing the configuration discovery process. 
         FIG. 4  is a listing for one implementation of an .XML file that has a set of commands and associated parsing logic to obtain the UNIX operating system configuration information. 
     
    
    
     DETAILED DESCRIPTION 
     A description of example embodiments follows. 
       FIG. 1  is a high level block diagram of an environment in which apparatus, systems, and methods for discovering respective configuration information for physical and virtual machines that are running a UNIX operating system in a production environment. This operating system configuration information may be automatically discovered in connection with offering a Managed Recovery Program (MRP), Recover to Cloud (R2C) service, or other service. 
     As shown, a production side environment  110  (that is, the customer&#39;s side from the perspective of a replication service provider) includes a number of data processing machines such as servers  101 ,  102 , . . . ,  104 . The production servers may be physical machines  101  . . .  104  or virtual machines (VMs)  102  . . .  103 . An administrator node  150  provides access to an administrator to access a browser-based configuration discovery tool as described below in more detail. 
     The production servers  101  . . .  104  may implement any sort of data processing function, such as a web server, database server, application server, media server, etc.—the specific end use of the servers is typically not important. An example physical machine  101  is a server that has an application program  101 - 1 , operating system  101 - 2 , memory  101 - 3 , local storage  101 - 4 , and other resources  101 - 5  such as network connections, etc. An example VM  102  may also include an application  102 - 1 , operating system  102 - 2 , memory  102 - 3 , local data  102 - 4  and other resources  102 - 5 . 
     One or more of the production servers  101  . . .  104  may include a replication agent process (not shown in  FIG. 1 ) that performs replication operations. The replication agents detect changes in the production environment  110  and reports them to a replication service environment  190 . More specifically, the production servers  101  . . .  104  are connected to a wide area network (WAN) connection  300  such as provided by the Internet, a private network or other network to a replication service environment  190  that provides one or more data centers as a recovery environment  350 . The service customer does not really care where or how the recovery environment is implemented, and so from the customer&#39;s perspective, is are located at the service provider environment  190  and accessible in the network  300  cloud. 
     The recovery environment may make extensive use of virtual machines to replicate the physical and virtual machines in the production environment  110 . In such a virtualized computing environment with virtual machines operating in a cloud recovery environment  350 , multiple computation stacks, including operating system, middleware, and applications, can operate together in a single server or set of servers. The cloud system(s) are therefore virtualized environments where virtual machines can elastically and dynamically scale to match the load or performance demands, where access to the cloud service is through a public network, and where the number and capability of virtual machines can be measured by the cloud provider and made available to the specifications of the customer using the cloud according to Service Level Agreements or other contractual arrangements. 
     At a time of disaster (ATOD) (or at time of disaster test (ATOT)), one or more configuration files are retrieved from a configuration database  310  by a Configuration Management System (CMS)  250  and are transferred to one or more on-demand active physical machines  360  or active virtual machines  370  in a failover or recovery environment  350  forming part of the replication service environment  190 . The environment  350  is also accessible to the customer via the cloud  300 , preferably through a secure network connection such as may be provided by firewalls  361  or secure Viritual Local Area Networks (VLANs)  362 . 
     The specific mechanism(s) for replication and disaster recovery are not of particular importance to the present disclosure. It should also be understood that there may be a number of additional data processors and other elements of a commercial replication service such as recovery systems, storage systems, monitoring and management tools that are not shown in detail in  FIG. 1 , which are not needed to be specified in detail to understand the present embodiments. 
     In order to determine the attributes of the physical  360  and virtual  370  machines in the failover or recovery environment  350 , a survey tool may run on administrative node  150  and automatically discover at least some configuration information for the elements of the production environment  110 . The configuration information may include identification of server(s), Operating Systems (OSs), applications, storage, security and network device information for production environment  110 . The discovered configuration information is then sent to the CMS  250  and stored in database  310  for use in bringing the recovery environment on line. 
     In one embodiment, an administrative user  140  uses an administrative node  150  which is typically located within the customer production environment  110 . The administrative user invokes a program to run a configuration discovery tool on node  150 . This may be provided by a secure application server website, hosted by CMS  250  in the replication service environment  190 . The discovery tool then automatically collects configuration information from the machines  101  . . .  104  in the customers production environment  110 . 
     Information collected by the configuration discovery tool is then forwarded back to the CMS  250 . As explained above, the CMS  250  includes a storage device for storing this information, preferably taking the form of a configuration database  310 . The database  310  stores several different types of information concerning the customer production environment  110  used to create the replication environment  250 . Of particular interest here is that the database  310  stores configuration snapshots consisting of live configuration information taken from and relating to the various infrastructure elements in the customer production environment  110 . 
     The CMS  250  may itself be located in the same physical location as the recovery environment  350 , elsewhere the premises of the service provider, at the premises of the customer production environment  110 , or remotely located and securely accessing through either a private network or the Internet  112 . 
     A specific implementation of the discovery tool is shown in more detail in  FIG. 2 . Here the administrative user  140  at customer production environment  110  makes a request of the CMS  250  in the replication service environment  190  This results in access to an application server  502  that is within the confines of the CMS  250  operated by the replication service provider  190 . In one example, the user sends a request to connect to a specific Uniform Resource Locator (URL) for the application server  502  using HyperText Transfer Protocol Secure (https) over the Internet  300 . 
     The administrative user may next be asked to authenticate with the application server  502  using login credentials. Upon successful authentication, the application server  502  then returns several things to the customer production environment  110 —one or more executable programs  410  (such as UNIX executable programs) and one or more corresponding data files  412  (such as XML files). over the secure connection. The executable program(s)  410  then run, contacting one or more servers  101 - 1 ,  101 - 2 ,  101 - 3 , . . . ,  101 - w  in the production environment  110 , obtains configuration information from them, and stores it in database  310 . In this process, the executable program may select and use .XML files  480  that contain commands and parsing logic. 
       FIG. 3  illustrates a sequence of steps performed by the executable(s)  410 . A first step  501  is to connect to one of the hosts  101  in the production environment using an appropriate access mechanism such as a Secure Shell (SSH) connection. This access may be obtained by the administrative user  140  entering an Internet Protocol (IP) address, user name, and password information for each such remote host machine  101 ; or this access information may have been previously collected and securely stored in the CMS  250  or database  310  and forwarded with the executable program  410 . 
     In a next step  502 , the host operating system (OS) type and version are determined. For example, the executable code  410  may use the host name and login credentials supplied by the user to automatically connect to each machine  101  in the production environment, and retrieve configuration information such as manufacturer, model, physical memory, UNIX operating system (OS) type and OS version installed applications and so forth. In another arrangement, the user may enter the OS and version information manually. 
     Next, in step  505  the executable code  410  may then determine the correct .XML file to use for that particular UNIX installation. For example, the database  310  may include a number of different .XML files  480 , one for each type of UNIX operating system. For example, there may be an .XML file for “Fedora 12”, another for “Ubuntu 13.04” and still another for “FreeBSD 8.3”. 
     (It should be understood that there may be other machines that run other non-UNIX operating systems, such as Microsoft Windows 8 (e.g., machine  101 -W)—other provisions are provided for accessing configuration information for Windows machines is typically not in this manner, but rather as per the existing patent application referenced above.) 
     Each of the .XML files  480  includes one or more commands and an associated parsing logic for each such command. The parsing logic typically reads a new line in the .XML file for each command. An example .XML file for “Fedora 12” is shown in  FIG. 4 . A first command may be a “cat/prox/cpuinfo” command which is know to return information about the CPU (such as a processor number, model name, cache size, physical identifier, siblings, core identifier and number of CPU cores). A next line in the .XML file contains parsing logic for this command&#39;s output (e.g., the “:” character is used as a delimiter and a token length is “2”). The executable can then read this command and parsing logic, submit the command to the machine  101 - 1 , and then extract configuration information from the command output using the parsing logic. The parsed information is then stored in a persistent data store  450  that is local to the customer production environment. 
     A second command in the .XML file may be a “rpm-fq” command that queries the Fedora 12 installation  101 - 1  to list installed software packages. 
     The subsequent line in the .XML file contains logic needed to parse the output of the rpm command. Still other commands, such as additional “rpm” commands can retrieve still further information, such as further information concerning the installed software packages, which will then also be stored in the local database  450 . 
     It is now understood that all of the command/parsing logic pairs to obtain the configuration information needed for machine  101 - 1  can be stored in a convenient machine and human readable format such as a single .XML file, but that such a file would be created typically for each expected type of UNIX operating system and version. 
     In any event, returning to  FIG. 3 , the correct .XML file is located for the particular OS and version in use by host  101 - 1 . If the correct .XML file cannot be found, the process exits is step  507 . 
     Next in step  511 , a first command is retrieved from the .XML file. The command is then executed on the remote host  101 - 1  in step  515 , and the parsing logic is read and applied to the command output in step  517  to retrieve the configuration information of interest. 
     The CMS  250  can store this configuration information obtained from the parsing logic in a configuration survey database  310  for later retrieval and later use in configuring a recovery environment to be brought on line in the event of a failure of the customer&#39;s production environment. This automatically discovered information may later be augmented in the database  450  with manually entered information. In a final step  518 , the .XML file is checked for additional commands, and the process loops back to step  511  until all commands associated with the particular OS are executed. 
     After the configuration information is collected by the executable  410  and stored in the local database  450 , the configuration information can next be made available for review by an administrative user  140  responsible for the customer production environment  110 . Once that user  140  is satisfied with the information to be shared with the replication service provider  190 , the information can be forwarded to the CMS  250  and stored in the database  310  there. The automatically discovered information may be augmented with manually entered information. 
     The CMS  250  can then use this configuration information as stored in configuration survey database  310  for later retrieval and later use in configuring a recovery environment  350  to be brought on line in the event of a failure of the customer&#39;s production environment  110 . 
     It should be understood that the example embodiments described above may be implemented in many different ways. In some instances, the various “data processors” described herein may each be implemented by a physical or virtual general purpose computer having a central processor, memory, disk or other mass storage, communication interface(s), input/output (I/O) device(s), and other peripherals. The general purpose computer is transformed into the processors and executes the processes described above, for example, by loading software instructions into the processor, and then causing execution of the instructions to carry out the functions described. As is known in the art, such a computer may contain a system bus, where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system. The bus or busses are essentially shared conduit(s) that connect different elements of the computer system (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) that enables the transfer of information between the elements. One or more central processor units are attached to the system bus and provide for the execution of computer instructions. Also attached to system bus are typically I/O device interfaces for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer. Network interface(s) allow the computer to connect to various other devices attached to a network. Memory provides volatile storage for computer software instructions and data used to implement an embodiment. Disk or other mass storage provides non-volatile storage for computer software instructions and data used to implement, for example, the various procedures described herein. 
     Embodiments may therefore typically be implemented in hardware, firmware, software, or any combination thereof. 
     The computers that execute the processes described above may be deployed in a cloud computing arrangement that makes available one or more physical and/or virtual data processing machines via a convenient, on-demand network access model to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Such cloud computing deployments are relevant and typically preferred as they allow multiple users to access computing resources as part of a shared marketplace. By aggregating demand from multiple users in central locations, cloud computing environments can be built in data centers that use the best and newest technology, located in the sustainable and/or centralized locations and designed to achieve the greatest per-unit efficiency possible. 
     In certain embodiments, the procedures, devices, and processes described herein are a computer program product, including a computer readable medium (e.g., a removable storage medium such as one or more DVD-ROM&#39;s, CD-ROM&#39;s, diskettes, tapes, etc.) that provides at least a portion of the software instructions for the system. Such a computer program product can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection. 
     Embodiments may also be implemented as instructions stored on a non-transient machine-readable medium, which may be read and executed by one or more procedures. A non-transient machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a non-transient machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; and others. 
     Furthermore, firmware, software, routines, or instructions may be described herein as performing certain actions and/or functions. However, it should be appreciated that such descriptions contained herein are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc. 
     It also should be understood that the block and network diagrams may include more or fewer elements, be arranged differently, or be represented differently. But it further should be understood that certain implementations may dictate the block and network diagrams and the number of block and network diagrams illustrating the execution of the embodiments be implemented in a particular way. 
     Accordingly, further embodiments may also be implemented in a variety of computer architectures, physical, virtual, cloud computers, and/or some combination thereof, and thus the computer systems described herein are intended for purposes of illustration only and not as a limitation of the embodiments. 
     Thus, while this invention has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention as encompassed by the appended claims. 
     While this invention has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.