FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: CLONING ENVIRONMENTS IN DATA CENTRES
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Ninnal Building, 9th Floor, Nariman Point,
SERVICES LIMITED Mumbai, Maharashtra 400021, India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
The subject matter described herein, in general, relates to cloned environments in
a data center and, in particular, relates to systems and methods for handling requests associated with the cloned environment.
BACKGROUND
For various computational, business, and economic needs, organizations may
centralize their operations through implementation of data centers. Each data center may contain servers, networking devices, storage systems, and all other hardware and software resources required by an organization for functioning. There is a high degree of dependency on these data centers for proper functioning and operations of the organization. In certain cases, the organization may have more than one data center for implementing various functionalities. Further, the data centers may include a plurality of sub-networks, or a collection of servers and computers, which are referred to as environments in the data center. A data center may have more than one environment within itself.
Generally, a main environment referred to as a production environment is
implemented for the main functions of the organization. However, in scenarios where the
production environment cannot be used, a cloned environment is implemented. Cloning an
environment helps in dividing tasks between the production environment and the cloned
environment.
Cloned environments are useful where the production environment cannot be used
for specific purposes. For example, in case of training, the production environment is typically
not used, as when the users undergoing training use the production environment, their actions are
likely to affect the functionality of the production environment and the integrity of the
production data. In another example, in case of a disaster, due to complete failure of the
production environment in the data center, the operations of the enterprise are continued through
a cloned disaster recovery environment implemented in the same or a physically different data
center.
As mentioned before, to provide cloned environments in a data center, the entire
production environment in the data center is replicated onto a dedicated environment referred to

as the cloned environment, which may be implemented as a physically separate environment within the same data center or in a different data center. In order to clone the production environment, all the data in the production environment along with a plurality of network address data and other metadata are replicated onto the cloned environment. For providing similar functionalities as the production environment, it is desired that network entities in the cloned environment perform and communicate with each other in a similar manner as done in the production environment.
SUMMARY
The subject matter described herein relates to system and methods for handling
requests associated with a cloned environment, which is further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
Methods and systems for handling requests within a cloned environment are
described herein. In one implementation, a metadata associated with a requested network entity in a production environment based on a received request, is automatically identified. Further, the received request is automatically redirected within the cloned environment to a metadata associated with a network entity in the cloned environment corresponding to the identified metadata associated with the requested network entity in the production environment.
BRIEF DESCRIPTION OF THE DRAWINGS
The detailed description is described with reference to the accompanying figures.
In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
Fig. 1 illustrates an exemplary network environment implementing a cloned
environment in a data center, in accordance with an implementation of the present subject matter.
Fig. 2 illustrates a network entity of the cloned environment, in accordance with
an implementation of the present subject matter.

Fig. 3 illustrates an exemplary method of handling requests at the cloned
environment in the data center, in accordance with an implementation of the present subject matter.
DETAILED DESCRIPTION
Systems and methods for handling requests within a cloned environment in a data
center of an organization are described. In one implementation, such systems and methods can be implemented in a variety of computing environments, such as servers, desktop computers, notebooks, or mobile computing environments like a smart phone, a personal digital assistant (PDA) or other such mobile devices.
Generally, a data center includes a plurality of sub-networks that further include
multiple devices for providing a plurality of functionalities such as data presentation, application processing and data management. In one example, the devices can be network entities, such as web servers, application servers, database servers, network devices, software components, etc. The sub-networks are also referred to as environments in the data center. An example of an environment in the data center is a production environment. Typically, the production environment is a normal operating environment in which processes and tasks being executed are integral and critical to the organization's productivity and operational stability. The various network entities in the production environment communicate with each other to process a request at the production environment, say a request for accessing or processing data from one network entity to another.
Typically, in such an environment, the request for accessing or processing the
data is handled by establishing a suitable communication link between the network entities within the production environment. In such cases, the network entity, with which communication is to be made and which is supposed to service the received request after the communication is made, can be determined based on metadata associated with the network entity. For example, the metadata may include an internet protocol (IP) addresses and/or ports of the various network entities, such as the web server, application server, database server, etc., in the production environment. The metadata can be stored at the production environment in the form of flat files in a file system of the production environment, or may be embedded in software program codes, or may be in the form of database records at the production environment of the data center.

In certain cases, such as for providing training to an employee of an organization,
the production environment is not utilized for the sake of maintaining the integrity of the data stored in the production environment. In such cases, the data or applications present within the production environment can be cloned or replicated onto another environment. The cloned data or applications can then be accessed by individuals without affecting data integrity on the production environment.
Another situation, where such a cloned environment finds an application is in the
field of disaster recover}'. As will be known to a person skilled in the art, the production environment, which in most cases forms the basis for carrying out business or other functionalities, may cease to operate in case of a disaster, for example system-based disaster or a natural disaster. In such cases, non-availability of the production environment will affect the business and may lead to loss of critical data and processes. Further, cloned environments can also be used in various other scenarios such as universal acceptance testing (UAT) or HotFix for
In such cases, the activities and functionalities of the production environment can
be switched over to the cloned environment. For example, the user-requests for services or data
can be redirected to the cloned environment instead of the production environment.
Typically, in order to implement cloned environments, the data at the production
environment is periodically replicated and stored within the cloned environment. As part of such replication, the metadata associated with the each of the network entity is also replicated from the production environment and stored within the cloned environment.
In order to fully replicate the functionalities of the production environment, the
metadata replicated onto the cloned environment is updated in accordance with the network entities within the cloned environment. As will be understood, a web server in the cloned environment interacts with a plurality of application software running on an application server(s) in the cloned environment in a similar manner as done in the production environment. For this, the web server requires metadata, such as an IP address of the application server(s) in the cloned environment. Therefore, any user request for an application process is redirected to the relevant application server within the cloned environment. Simply, the application server(s) communicates with a. database server in the cloned environment for which the application server requires the IP address of the database server in the cloned environment.

As will be understood by a person skilled in the art, the IP addresses of the
network entities in the cloned environment are different from that of the corresponding network
entities in the production environment as the production environment and the cloned
environment are implemented within a same network. Therefore, in the cloned environment, the
network entities require the IP address of the other network entities in the cloned environment in
order to communicate with each other as done in the production environment.
As explained earlier, for communicating within the cloned environment, the
network entities require the IP addresses of the other network entities in the cloned environment.
However, the metadata which provides the IP address for communication is generally replicated
in its original form. Therefore, in order to implement the cloned environment in the data center,
IP addresses of the network entities in the production environment are searched manually in the
replicated metadata, in order to identify the form in which the IP addresses are stored. Further,
the IP addresses are manually updated with the IP addresses of the corresponding network
entities in the cloned environment by a data center administrator. Hence, for every IP address of
the network entity in the production environment, the administrator needs to manually update the
IP address of the corresponding network entity in the cloned environment, so that the network
entities in the cloned environment can communicate suitably as in the production environment.
However, in case of huge data centers and a huge number of servers and other
network entities in an environment of the data center, manually searching the form of storage of the IP addresses and manually updating them in the cloned environment is a tedious and a complex task. Additionally, if the IP addresses are embedded in the software program code at the production environment, then the entire software program code is to be rewritten with the updated IP address (i.e.. the IP address of the network entity in the cloned environment) and deployed again with the updated IP address at the cloned environment. This again can be a time consuming and a very complex task.
To this end, systems and methods for handling requests within a cloned
environment in a data center are disclosed herein. The cloned environment implements a 3-tier network architecture. A 3-tier network architecture can be understood as a client-server architecture where each of presentation, application processing and data management is a separate process. The 3-tier network architecture includes a plurality of devices for providing

such functionalities. In one implementation, the devices can be network entities such as a web
server, a plurality of application servers and a plurality of database servers.
In one implementation, a user makes a request to login to a web page through the
web server which is the first network entity in the cloned environment. Further, the web server in
the cloned environment communicates with subsequent network entity such as the application
server in the cloned environment. Therefore, the requested IP address of the requested
application server is identified. By default, with as-is replication of metadata, the requested IP
address of the application server is the IP address of the application server in the production
environment. Therefore, as soon as the IP address of the application server in the production
environment is identified, the request is redirected to the IP address of the corresponding
network entity in the cloned environment (in this case, the IP address of the application server
replicated within the cloned environment). Similarly, the requested IP address of the subsequent
requested network entities in the production environment are identified and the request is
automatically redirected to the IP address of the corresponding network entity in the cloned
environment.
In one implementation, the requests are redirected within the cloned environment
based at least on predefined mapping information. For example, a data center administrator
defines a mapping of the IP addresses of the network entities in the production environment to
the IP addresses of the corresponding network entities in the cloned environment.
The cloned environment as implemented in the present invention eliminates the
requirement of manually searching and updating the metadata of the network entities in the
cloned environment, thus minimizing human intervention. Additionally, the cloned environment
as disclosed herein provides an improved quality of cloned environments in data centers that are
free from human errors.
The manner in which the methods and systems for handling of requests in a cloned
environment are implemented shall be explained in detail with respect to the Figs. 1-3. While
aspects of systems and methods can be implemented in any number of different computing
systems, environments, and/or configurations, the embodiments are described in the context of
the following exemplary system architecture(s).
Fig. 1 illustrates an exemplary cloned environment 100 in a data center in
accordance with an implementation of the present subject matter. In one implementation, the

cloned environment 100 includes a plurality of devices for providing various functionalities. In one implementation, the devices can be network entities 102-1, 102-2... 102-N, collectively referred to as cloned network entities 102. The cloned network entities 102 are cloned from their corresponding network entities in a production environment (not shown in the figure). The production environment may or may not be in the same data center as that of the cloned environment 100. In one implementation, the cloned network entities 102 in the cloned environment 100 communicate with each other within a network 103.
The network 103 can be implemented as a wireless network, wired network or a
combination thereof The network 103 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, etc. The network 103 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc.. to communicate with each other. Further, the network 103 may include network devices, such as network switches, hubs, routers, host bus adaptors (HBAs), for providing a communication link between the cloned network entities 102. In one implementation, the cloned environment 100 may implement a 3-tier network architecture including the network entities 102. The 3-tier network architecture is a client server architecture in which the presentation, application processing and data management are different processes. Therefore, in 3-tier architecture, the cloned network entities 102 can be a web server 102-3, an application server 102-2, and a database server 102-3.
In operation, when the cloned environment 100 is implemented, the production
environment, is not the intended recipient for one or more requests received from a user. Instead, the cloned environment 100 receives the requests from the user, and subsequently the cloned network entities 102 communicate with each other to process the received requests in a manner similar to the corresponding network entities in the production environment. In one implementation, the cloned environment 100 may be implemented in an event of disaster, or for training purposes without disturbing the operations at the production environment, or for any other similar purposes.
As explained earlier, data at the production environment is periodically replicated
onto the cloned environment 100. In one implementation, the data is replicated in real time from

the production environment to the cloned environment 100. Additionally, a plurality of metadata associated with the data and the network entities in the production environment are also replicated onto the cloned environment 100. For example, the metadata may include the IP addresses of the network entities in the production environment that are replicated onto the cloned environment 100. It will be understood by a person skilled in the art. that the metadata can include other forms such as ports of the network entities in an environment. Typically, the metadata associated with the network entities in the production environment are replicated in its original form onto the cloned environment 100. For example, the IP addresses of the network entities in the production environment are copied to represent corresponding cloned network entities 102.
It can be understood, as the production environment and the cloned environment
100 are implemented within a common network, the IP addresses of the network entities in the
production environment are different from the corresponding cloned network entities 102 in the
cloned environment 100. For example, the IP address of the web server in the production
environment is different from the IP address of the web server 102-1 in the cloned environment
100. Similarly, the IP address of the application server(s) and the database server(s) in the
production environment is different from the application server(s) 102-2 and the database
server(s) 102-3 in the cloned environment 100. Therefore, the metadata is updated at the cloned
environment 100 in order to reflect the IP addresses of the cloned network entities 102 in the
cloned environment 100. As explained previously, conventionally the metadata is updated
manually say by a data center administrator which can be a tedious and time consuming task.
In one implementation, when the cloned environment 100 is implemented in a 3-
tier network architecture, a network entity 102, for example the web server 102-1 in the cloned environment 100 receives at least one request from a user. The user may send the request through a user interface running on the web server 102-1 in the cloned environment 100. In one implementation, the web server 102-1 determines whether the request is to be communicated to a subsequent cloned network entity 102 in the cloned environment 100. For example, if a user wishes to view an image, then the web server 102-1 determines that the request is to be processed by the application server 102-2 and thus communicates the request to the application server 102-2. However, if a request is made to login to a bank account, then the web server 102-1 determines that the request is to be processed by the application server 102-2 for opening the

bank account web page, as well as the database server 102-3 for accessing the account information stored therein.
If the web server 102-1 determines that the request is to be communicated to a
subsequent network entity 102, then a communication link is established between the web server 102-1 and the subsequent network entity 102-2 in the cloned environment. For this, the web server 102-1 identifies the metadata associated with an originally intended recipient network entity in the production environment, which was originally intended for processing the request. hereinafter referred to as the original network entity. In one implementation, the metadata includes the IP address of the network entity in the production environment. Based on the metadata, the web server 102-1 identifies the original network entity, i.e., the application server in the production environment. However, with the cloned environment 100 in place, the request is now to be handled by the application server 102-2 in the cloned environment 100 instead of the original network entity in the production environment.
In said implementation, each of the cloned network entities 102 further include a
redirecting module, viz., redirecting module 104-1, 104-2, 104-3...104-N, collectively referred to as the redirecting module(s) 104, for redirecting the received request to another cloned network entity 102 within the cloned environment 100. For the above example, the redirecting module 104-1 of the web server 102-1 in the cloned environment 100 redirects the received request to the application server 102-2 in the cloned environment 100 for further processing. As stated above, the original network entity is identified and based on the identified original network entity for the received request, the request is redirected to the corresponding cloned network entity 102 in the cloned environment 100. This means, the redirecting module 104-1 automatically redirects the received request to the IP address of the application server 102-2 in the cloned environment 100.
Similarly, the redirecting module 104-2 of the application server 102-2 in the
cloned environment 100 redirects the request received from the web server 102-1 to the subsequent network entity 102, in this case, the database server 102-3, in the cloned environment 100. In said implementation, the received request is communicated amongst the cloned network entities 102 within the cloned environment 100 in a similar manner i.e., by the implementation of redirecting module 104, as explained above. Once the request is received by the database server

102-3 in the cloned environment 100, the database sever 102-3 processes the request and provides the requested information to the user.
In one implementation, the requests are redirected from one cloned network entity
102 to another within the cloned environment 100, based on predefined mapping information. For example, the predefined mapping information includes a mapping of the metadata associated with the network entities in the production environment to the metadata of the corresponding network entities in the cloned environment 100. It will be understood that the description is made for IP addresses, however, there may be other form of metadata such as ports of the network entities in environments. For example, the IP address of the application server in the production environment is mapped to the IP address of the corresponding application server in the cloned environment 100. Similarly, the IP address of the database server in the production environment is mapped to the IP address of the corresponding database server in the cloned environment 100. Similarly, ali the IP addresses of the network entities in the production environment are mapped to the IP addresses of the corresponding network entities 102 in the cloned environment 100. In one implementation, the predefined mapping is done automatically by the redirecting module 104 implemented at the cloned network entity 102. Further, this predefined mapping information is used by the redirecting modules 104 to redirect the requests to the cloned network entities 102 within the cloned environment 100. Therefore, as soon as the IP address of a network entity in the production environment is identified at the network entities cloned in the cloned environment 100, the redirecting module 104 redirects the request to the IP address of the corresponding network entity in the cloned environment 100.
In said implementation, the predefined mapping is done using the iptables rules of
the LINUX based systems. A network address translation (NAT) feature of the iptables is used to define the mapping of the source IP address to the destination IP address. For this, the following code is implemented at every cloned network entity 102 in the cloned environment 100:
iptables -A OUTPUT -t nat -p tcp -dst 172.18.1.1-j DNAT -to-destination
192.168.200.1
The first IP address, i.e., 172.18.1.1, is the IP address of a network entity such as
the web server in the production environment. The second IP address, i.e., 192.168.200.1 is the destination IP address of the corresponding network entity 102 i.e., the web server 102-1 in the cloned environment 100. As will be understood, the implementation of the above mentioned

code at the cloned network entities 102 in the cloned environment 100, redirects the request from the source IP address to the destination IP address. Therefore, in this case, the request is redirected to the IP address of the corresponding cloned network entity 102 in the cloned environment 100. whenever an IP address of the network entity in the production environment is identified.
The cloned environment cloned network entities 102 are further described in Fig.
2. Fig. 2 illustrates exemplary components of the cloned network entity 102 in a cloned environment 100, in accordance with an implementation of the present subject matter. The cloned network entity 102, from amongst the cloned network entities 102 in the cloned environment 100, may include one or more processor(s) 202, one or more I/O interface(s) 204, and a memory 206. The processor(s) 202 may include microprocessors, microcomputers, nicrocontrollers, digital signal processors, central processing units, state machines, logic circuitries and/or any devices that manipulate signals and data based on operational instructions. Among other capabilities, the processor(s) 202 is configured to fetch and execute computer-readable instructions stored in the memory 206.
The I/O interface(s) 204 may include a variety of software and hardware
interfaces, for example, interface for peripheral device(s). such as data input/output devices, storage devices, network devices, etc. The I/O interface(s) may include Universal Serial Bus (USB) ports, Ethernet ports, Host Bus Adaptors, etc., and their corresponding device drivers. The I/O interface(s) 204, amongst other things, facilitate communication with the users and the cloned network entities 102 in the cloned environment 100 as well as with the network entities in the production environment.
The memory 206 can include any computer-readable medium known in the art
including, for example, volatile memory (e.g., RAM) and/or non-volatile memory (e.g., flash.
etc.). The memory 206 further includes module(s) 208 and data 210. In one implementation, the
modules 208 include the redirecting module 104, an identification module 212, and other
module(s) 214. The data 210, on the other hand, serves at least as a repository for storing
information associated with the modules 208. In said implementation, the data 210 includes
primary data 216, network address mapping data 218, and other data 220.
As mentioned before, the cloned environment 100 implements a 3-tier web
architecture having, for example, three cloned network entities 102, such as a web server 102-1,

an application server 102-2, and a database server 102-3. When a user sends a request to access information, then by default, the original intended recipient of the request is a network entity in the production environment. However, in a case where the cloned environment 100 is implemented, such a request is received or redirected to the cloned environment 100. In one implementation, the identification module 212 receives a request from a user through a web page running at the web server 102-1 in the cloned environment 100.
To implement the cloned environment 100, the production environment is
periodically replicated onto the cloned environment 100. For this the data at the production
environment is replicated onto the cloned environment 100. Additionally, a plurality of metadata,
such as the network addresses in the form of IP addresses associated with the network entities in
the production environment, are also replicated onto the cloned environment 100.
In one implementation, the other module 214 stores the production environment
data and the metadata in the production environment as primary data 216. Furthermore, the
primary data 2)6 is subsequently used by the cloned network entity 102 in the cloned
environment 100 for processing the received requests at the cloned environment 100.
In operation, the identification module 212 of the cloned network entity 102
receives the request at the cloned network entity 102 in the cloned environment 100. As explained earlier, in case of training purposes, the requests from employees undergoing training may not be processed at the production environment, therefore, these requests are redirected to the cloned environment 100. In another example, in an event of disaster, where the production environment fails, the requests received at the production environment are redirected to the cloned environment 100. In one implementation, the identification module 212 receives the redirected requests through a user interface running at the web server 102-1 in the cloned environment 100. Once the request is received at the cloned network entity 102 in the cloned environment 100, the identification module 212 identifies the metadata associated with the originally intended recipient network entity in the production environment. In one implementation, the metadata includes the IP address associated with the originally intended recipient network entity in the production environment. For example, a request is by default directed to the IP address of the network entity in the production environment. For example, in the request, the originally intended recipient network entity in the production environment is the application server. Therefore, the identification module 212 will identify the IP address

associated with the application server in the production environment. Similarly, if the requested network entity in the production environment is the database server in the received request, then the identification module 212 identifies the IP address of the database server in the production environment.
Subsequently, the identification module 212 communicates the identified IP
address of the requested network entity in the production environment to the redirecting module 104 of the network entities 102. In one implementation, the redirecting module 104 uses the identified IP addresses of the requested network entities in the production environment and redirects the received request to an IP address of the corresponding cloned network entity 102 in the cloned environment 100. In the above mentioned example, when the identified requested network entity in the production environment is the application server then the identification module 212 identifies the IP address of the application server in the production environment. Therefore, the redirecting module 104 uses the identified IP address of the application server in the production environment and redirects the received request to the IP address of the corresponding application server 102-2 in the cloned environment 100. In one implementation, the redirecting module 104 redirects the request based on a pre-defined mapping information stored as the network address mapping 218.
In an implementation, a data center administrator defines mapping information for
mapping the IP addresses of the network entities in the production environment with the IP addresses of the corresponding cloned network entities 102 in the cloned environment 100. In another implementation, this predefined mapping is done automatically by the redirecting module 104 in the cloned network entity 102. This mapping information eliminates the need of manually searching the form of IP address storage and then manually configuring the IP addresses in the cloned environment 100. For example, as soon as an IP address of a network entity in the production environment is identified in a request, the request is automatically redirected to the IP address of the corresponding network entity in the cloned environment 100. Therefore, a data center administrator does not need to manually update each and every cloned network entity 102 in the cloned environment 100. every time when there is a change at the production environment. For example, if an IP address is embedded in a software program code running at the application server in the production environment then for the new IP address of the network entity in the cloned environment 100, the administrator does not need to compile the

entire code manually at the cloned environment 100 and deploy it again with the new IP address of the cloned network entity 102 in the cloned environment.
As the request is received by the application server 102-2 in the cloned
environment 100. the request is further communicated to the database server 102-3 in a similar manner as explained earlier. Further, each cloned network entity 102 may include a request processing module (not shown in the figure) to process the received request. In one implementation, once the request reaches the database server 102-3 in the cloned environment 100, the request is processed to extract information as requested by the user from the database in the database server 102-3 in the cloned environment.
Fig. 3 illustrates an exemplar}' method 300 of handling requests in the cloned
environment 100. The method 300 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines. programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method 300 may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communication network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
The order in which the method 300 is described is not intended to be construed as
a limitation, and any number of the described method blocks can be combined in any order to implement the method 300, or an alternative method. Additionally, individual blocks may be deleted from the method 300 without departing from the spirit and scope of the subject matter described herein. Furthermore, the method 300 can be implemented in any suitable hardware, software, firmware, or combination thereof. The method 300 is presently provided for handling requests in the cloned environment 100. It will be apparent that the method 300 may be implemented for the cloned environment 100 based on other parameters with modifications as known by those skilled in the art.
When the cloned environment 100 is implemented, the requests to access network
entities and data in the production environment are handled by the cloned environment 100. As the entire production environment data is replicated onto the cloned environment 100, therefore, the requested access to functions provided by the network entities and the data in the production

environment is provided at the cloned environment 100 by creating clones or copies of the network entities and data in the production environment.
At block 302. a user request is received by a cloned network entity 102 in the
cloned environment 100. In said implementation, the cloned environment 100 implements a 3-tier web architecture that includes network entities 102, such as a web server 102-1, an application server 102-2, and a database server 102-3, running within the cloned environment 100. In one implementation, a cloned network entity 102, say the web server 102-1, receives the user request through a user interface running on the web server 102-2 in the cloned environment 100. For example, the cloned environment 100 may be implemented in an event of disaster, where the production environment is impaired and the requests received at the production environment are handled by the cloned environment 100. In another example, the cloned environment 100 may be implemented for training purposes where the training requests are received at the cloned environment 100 as the production environment is not to be disturbed. Therefore, in this case, the requests are not redirected but received directly by the cloned environment 100.
Further, at block 304, it is automatically identified whether the received request is
intended to be communicated to a subsequent cloned network entity 102 within the cloned environment 100. For example, the web server 102-1 identifies whether the request is to be communicated to the application server 102-2 in the cloned environment. Thus, at every cloned network entity 102, it is determined whether the request is to be communicated to the subsequent network entity 102. For example, if a user wishes to view an image, then the web server 102-1 determines that the request is to be processed by the application server 102-2. and thus bommunicates the request to the application server 102-2. However, if a request is made to login to a bank account web page, then the web server 102-1 determines that the request is to be processed by the application server 102-2 for opening the bank account web page, as well as the database server 102-3 for accessing the account information stored therein. If it is determined that the request is not to be communicated to the subsequent network entity ("No" path at block 304), then the request is processed at the y and the results are provided to the users at block 310. For example, as the request reaches the database server 102-3, then the database server 102-3 does not communicate the request further, but processes the request within itself.

Furthermore, at block 304, if it is determined that the request is to be
communicated to the further cloned network entity 102 in the cloned environment 100 ("Yes" path at block 304). then at block 306, the metadata associated with an originally intended recipient network entity of the request in the production environment is automatically identified. In one implementation, the metadata, includes an IP address associated with an originally intended and requested network entity in the production environment. In one implementation, an identification module 212 of the cloned network entity 102 identifies the IP address of the originally intended and requested network entity in the production environment. For example, by default, a requested network entity is the network entity in the production environment, which may be a web server, or an application server or a database server. Therefore, the IP address associated with the network entity in the production environment, say the application server, is identified.
Further, at block 308, the received requests are redirected to an IP address
associated with a corresponding network entity in the cloned environment 100, based at least on
the identified IP address at block 306. For example, if at block 306, it is determined that the
requested IP address associated with the original intended recipient network entity of the request
is the IP address of the application server in the production environment, then the request is
redirected to the IP address of the application server 102-2 in the cloned environment 100. In one
implementation, a redirecting module 104 in the cloned network entity 102 redirects the requests
to the IP address of the corresponding cloned network entity 102 in the cloned environment 100.
In said implementation, the redirecting is based at least on predefined mapping
information. For example, a data center administrator may define mapping information that maps the metadata associated with the network entities in the production environment to the metadata associated with the corresponding network entities 102 in the cloned environment 100. In one implementation, the metadata includes the IP addresses and / or ports of the network entities in the production environment as well as the cloned environment 100. In one implementation, the predefined mapping can be done automatically by the redirecting module 104 running in the cloned network entity 102.
In one implementation, the predefined mapping is done using the iptables rules of
the LINUX based systems. A network address translation (NAT) feature of the iptables is used to

define the mapping of a source IP address to a destination IP address. For this, the following code can be implemented at every cloned network entity 102 in the cloned environment 100:
iptables -A OUTPUT -t nat -p tcp -dst 172.18.1.1-j DNAT -to-destination
192.168.200.1
In the above mentioned code, the first IP address, i.e., 172.18.1.1, is the IP
address of a network entity in the production environment. However, the second IP address, i.e., 192.168.200.1 is the destination IP address of the corresponding network entity 102 in the cloned environment 100. As will be understood by a person skilled in the art, the implementation of the above mentioned code at the cloned network entities 102 in the cloned environment 100, redirects the request from the source IP address to the destination IP address. Therefore, in this case, the request is redirected to the IP address of the corresponding cloned network entity 102 in the cloned environment 100, whenever an IP address of the network entity in the production environment is identified.
The requests are communicated from one network entity to another within the
cloned environment 100 in a similar manner as explained above, by the identification module(s)
212 and the redirecting module(s) 104 running at the cloned network entities 102.
Furthermore, once the requests are received at the cloned network entities 102 and
are not to be communicated further in the cloned environment 100, then at block 310. the
requests are processed to provide the requested information to the user at the cloned environment
100. For example, a dedicated processing module in the cloned network entities 102 processes
the received request for providing the appropriate results to the requesting users.
Although embodiments for handling requests associated with the cloned
environment 100 in a data center have been described in language specific to structural features and/or methods, it is to be understood that the invention is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary embodiments for handling requests at the cloned environment 100 in a data center, and the methods.

I/We Claim:
1. A method for handling requests by a device (102) within a cloned environment (100). the
method comprising:
automatically identifying metadata associated with a requested network entity in a production environment based at least in part on a received request; and
redirecting the received request within the cloned environment (100) to metadata associated with a network entity in the cloned environment (100) corresponding to the identified metadata associated with the requested network entity in the production environment, based at least on a pre-defined mapping information.
2. The method as claimed in claim 1 further comprises replicating data and metadata from the production environment onto the cloned environment (100).
3. The method as claimed in claim 1. wherein the redirecting further includes mapping of metadata associated with the network entity in the production environment with the metadata associated with the corresponding network entity in the cloned environment (100).
4. The method as claimed in claim 1, wherein the metadata is at least one of an IP address and a port of the network entity in the production environment and the cloned environment (100).
5. A device (102) for handling requests within a cloned environment (100), the device (102) comprising:
a processor (202); and
a memory (206) coupled to the processor (202), the memory (206) comprising,
an identification module (212) configured to automatically identify metadata associated with a network entity in a production environment, based in part on a received user request; and
a redirecting module (104) configured to redirect the received request to metadata associated with a corresponding network entity (102) in the cloned environment (100) based in part on the identified metadata of the requested network entity in the production environment.

6. The device (102) as claimed in claim 5, wherein the cloned environment (100) is a disaster recovery system.
7. The device (102) as claimed in claim 5, wherein the metadata is at least one of an IP address and a port of the network entity in the production environment and the cloned environment (100).
8. The device (102) as claimed in claim 5, wherein the redirecting module (104) is configured to redirect the received request based at least on predefined mapping information.
9. The device (102) as claimed in claim 8, wherein the redirecting module (104) defines mapping information indicative of a. mapping of the metadata of the network entities in the production environment with the metadata of the corresponding network entities in the cloned environment (100).
10. A computer readable medium having computer executable instructions which when executed implement a method comprising:
automatically identifying metadata associated with a requested network entity in a production environment based at least in part on a received request; and
redirecting the received request within the cloned environment (100) to metadata associated with a network entity in the cloned environment (100) corresponding to the identified metadata associated with the requested network entity in the production environment; based at least on a pre-defined mapping information.